WEBINAR: THE AGILE APPROACH TO PROCESS IMPROVEMENT AND ITS IMPACT ON PRODUCTIVITY

Transcription

1 WEBINAR: THE AGILE APPROACH TO PROCESS IMPROVEMENT AND ITS IMPACT ON PRODUCTIVITY Presented by David Consulting Group (DCG) and Computer Aid, Inc. (CAI) 0

2 Michael Harris President David Consulting Group (DCG) David Garmus Principal David Consulting Group (DCG) Michael Milutis Director of Marketing Computer Aid, Inc. (CAI) 1

3 About David Consulting Group (DCG) DCG is an international IT process improvement and measurement company currently managing active engagements with over 20 Fortune 1,000 companies and government agencies around the world. DCG s focus is directed toward practical implementations that measure results, improve IT processes and deliver value. DCG is a recognized world leader in Software Sizing. It s founders wrote the book on Function Point Analysis. DCG consistently promises and delivers positive change in its consulting engagements. DCG makes all of this possible through the expertise and commitment of its consultants who are organized into the following Consulting Practices: Software Process Improvement including CMMI and Six Sigma Software Sizing using IFPUG Function point Counting and other techniques Software Measurement including estimating, benchmarks and outsourcing SLA definition, measurement and monitoring IT Performance Improvement focused on IT Operations through ITIL and IT Governance IT Decisions Coaching helping individuals and teams in IT to increase value by making better decisions. 2

4 About Computer Aid, Inc. (CAI) CAI is a global IT outsourcing firm currently managing active engagements with over 100 Fortune 1,000 companies and government agencies around the world. CAI is a leader in IT Best Practices for legacy support and new development application management. CAI s focus is directed toward practical implementations that track and measure the right activities in software activity management CAI consistently promises and delivers double digit productivity in its outsourcing and consulting engagements. CAI makes all of this possible through the use of: Standard processes Management by metrics SLA compliance management Detailed cost, resource, and time tracking Capacity management Standard estimation A unique, metrics based methodology along with a proprietary, real time data repository and management system (TRACER ). 3

5 Agenda Acknowledgements Lessons for Attendees Context The Agile Manifesto and Declaration of Interdependence Overview of an Agile Process Agile Process Improvement Innovation through Experimentation Continuous Value Delivery Suggested Innovation & Value Delivery Metrics Performance Data on Agile Projects When to Choose Agile Questions 4

6 Acknowledgments [1] Manifesto for Agile Software Development, 2001, Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas ( [2] Declaration of Interdependence (DOI), 2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith and Robert Wysocki ( [4] Schwaber Agile Project Management with Scrum, Microsoft Press, 2004 [5] Schwaber, Beedle Agile Software Development with Scrum, Prentice Hall, 2002 [6] Chrissis, Konrad, Shrum CMMI Guidelines for Process Integration and Product Improvement CMU/SEI Addison Wesley, 2004 [7] Gestalt, LLC llc.com 5

7 Lessons for Attendees How to apply the values of the Agile Manifesto and the Declaration of Interdependence to Process Improvement projects How to create opportunities for innovation through experimentation by using an agile approach to process improvement How an agile approach to process improvement can maximize continuous delivery of value to the organization How to measure that improvement How to choose the right opportunities for the agile approach 6

8 The Philosophies Manifesto for Agile Software Development (2001) We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Declaration of Interdependence (2005) We are a community of project leaders that are highly successful at delivering results. To achieve these results: We increase return on investment by making continuous flow of value our focus. We deliver reliable results by engaging customers in frequent interactions and shared ownership. We expect uncertainty and manage for it through iterations, anticipation and adaptation. We unleash creativity and innovation by recognizing that individuals are the ultimate source of value and creating an environment where they can make a difference. We boost performance through group accountability for results and shared responsibility for team effectiveness. We improve effectiveness and reliability through situationally specific strategies, processes and practices. 7

9 Context Agile Process Improvement an Oxymoron? Increasing experience suggests it is necessary and practical (if not pure) to blend these sets of values, principles and activities Necessary because internal and external business and government customers want agility with discipline and accountability Practical because both Agile and the DOI require process and discipline to be effective Pure is in the eye of the beholder Most Software Process Improvement (SPI) projects are implemented using a waterfall approach How then do we implement SPI projects in an agile software development environment? 8

10 Agile Process Improvement An Oxymoron? The first value statement in the Agile Manifesto leaps off the page at most process oriented individuals and organizations, We value individuals and interactions over processes and tools Many SPI practitioners stop reading the Agile Manifesto right there! The answer to the apparent contradiction is that individuals and interactions ARE more important than processes and tools in ANY process improvement project because process improvement is primarily about changing peoples behavior 9

11 Scrum Development Process (thanks to Gestalt, LLC & the Gestalt Pathfinder TM Development Process) llc.com Roles Artifacts Meetings Process Program Manager: Interfaces to Client Product Owner: Sets Priorities Scrum Master Manages Process, Removes roadblocks Product Backlog List of requirements and issues Owned by Product Owner Everyone can add to it Only the Product Owner prioritizes Sprint Goal One sentence summary Declared by Product Owner Accepted by team Sprint Backlog List of tasks (4 16 hours) Owned by team Only the team can modify it Sprint Planning Inputs: Product Backlog, Current Business Conditions Output: Sprint Backlog Daily Scrum Same time every day Answer: 1) What did you do yesterday? 2) What will you do today? 3) What is in your way? Team updates Sprint Backlog Scrum Master updates Block List Product Product Backlog Backlog Sprint Planning Meeting Daily Scrum Daily Work Increment Increment Sprint Sprint Backlog Backlog Blocks Blocks List List Product Product Sprint: 30 Days Team: Develop Product Block List List of obstacles Owned by Scrum Master Updated daily Sprint Review Team demonstrates increment All discuss; gather feedback Increment Increment Sprint Review Meeting PPQA: Monitor Process Compliance 10 Stakeholders: Observe & Advise Increment Version of the product Shippable function tested, documented, etc Process Imprvmt. Requests Output from Sprint Retrospective Sprint Retrospective Team reviews Sprint Processes All discuss; gather feedback Capture Process Improvement Requests Product Product Backlog Backlog Sprint Retrospective Meeting

12 Agile Process Improvement Customer Customer Planned Priorities Sprint Planned Priorities Sprint Planned Priorities Sprint llc.com New Business Driver New Business Driver Planned Priorities Sprint Planned Sprint Planned Sprint Release Planning Process Area A Process Area B Process Area C 30 Day 30 Day Sprint Sprint Deliverable Deliverable Product Product 30 Day 30 Day Sprint Sprint 30 Day 30 Day Sprint Sprint Release 30 Day 30 Day Sprint Sprint 11 Customer Customer 100% Tested

13 Continuous Value Delivery The Customer for most SPI projects is usually the senior manager, who is paying for it (or seeking to spend the SPI budget on something else!) An agile like approach to SPI projects ensures that the senior management will see value being delivered every sprint If not, they will be right to hold the SPI team accountable and/or change priorities for the next sprint 12

14 Agile Process Improvement What does an Agile SPI project look like? An agile SPI project based on the Scrum methodology might have a 4 week sprint cycle The prioritized goals of the SPI project will form the Product Backlog from which candidate activities will be drawn for each SPI project sprint In a client using Scrum for development, it is extremely important to synchronize the SPI sprint cycle with the project sprint cycle It is likely that the SPI project will require input from development project sprint team members, whose availability and ability to plan will be based entirely on their commitments to the current development sprint Also, in pilot and roll out phase of the projects, it is virtually impossible to introduce a new process in the middle of a development project sprint New processes must be introduced into the sprint planning meeting 13

15 Agile Process Improvement Planning an Agile SPI project The SPI Project Sprints should be organized as follows: Develop, Pilot, Refine, Roll out This approach requires a minimum of four sprints, but in the two organizations where this approach to SPI projects has been implemented, it has proven to be useful to take a flexible approach so that a complex process or one requiring a lot of new process definition might have 2 or 3 Develop sprints before the pilot sprint The rigor of the agile approach must be observed for each sprint, and real value must still be delivered at the end of each Develop sprint 14

16 15 Agile Process Improvement How does an Agile SPI project really work? One of our clients benefited hugely from this when developing and piloting their Configuration Management processes Errors in delivered software builds had caused numerous embarrassments in front of customers despite a high level of customer satisfaction in the software reviewed The company had developed a culture of fire fighting teams to deal with this problem; Process Improvement was difficult because nobody had confidence enough to change the engine of the car while it was speeding along the road to the next urgent deliverable Taking a sprint approach, which piloted CM process changes, large and small, in manageable chunks on a monthly basis has turned this around in four months

17 Innovation through Experimentation Implementing an SPI project in an agile development organization is highly advantageous because, to a large degree, each sprint is an almost complete instance of the development organizations SDLC Hence, pilot opportunities for new processes on new projects occur once per sprint cycle This enables all parts of a process to be tested more quickly and facilitates multiple pilots in parallel or sequentially to refine processes Just as it may be necessary or useful to have multiple Develop sprints for process definition, it can be useful to use multiple instances of the pilot and refine sprint pair either to evolve a weak process definition, to build and test tailoring schemes, or to ensure correctness and acceptance across a widely diversified development group; this is true whether the target software development methodology is agile or not 16

18 Lessons from Agile Software Development: Use Measurement To Enable Comparisons Between Methods QUANTITATIVE QUALITATIVE Measure how you are doing Deliverable Size Effort/Cost Duration Quality Process Methods Skills Tools Environment Identify what you are doing Measured Performance Capability Maturity Standard of performance Baseline of Performance 17

19 Lessons from Agile Software Development: Utilize Measurement Results in Decision Making Improvements resulting from current and future initiatives must be measured The basis for measuring improvements may include: Industry data Organizational baseline data It is necessary for the organization to put a stake in the ground relative to current performance level in order to improve development practices 18

20 Lessons from Agile Software Development: Collecting & Reporting Identify data set (typically project oriented) Collect baseline data Project measures (e.g., effort, size, cost, duration, defects) Project attributes (e.g., skill levels, tools, process, etc.) Analyze data Performance comparisons (identification of process strengths and weaknesses) Industry averages and best practices Performance modeling (identify high impact areas) Report results 19

21 Lessons from Agile Software Development: Using Historical Delivery Rates DEFINITION CAPABILITY EFFORT REQUIREMENT PROJECT SIZE and COMPLEXITY RATE OF DELIVERY Effort Schedule Costs FUNCTION POINT SIZE HOURS per FUNCTION POINT 20

22 Lessons from Agile Software Development: Hours Per Function Point Average Hours/Function Point of Recent Enhancement Projects Across Different Platforms from DCG Database for Small Projects Traditional Agile Client Server Main Frame Web e business Web

23 22 Suggested Innovation & Value Metrics for Agile Process Improvement Innovation Number of Process Change Requests generated at end of Sprint Number of pilot sprints required to achieve Customer Satisfaction Number of Process Change requests after Processes Implemented Value Delivery % improvement in functional value delivered (if agile development used) % improvement in time to market % reduction in defect removal time (if agile development used) % resource time lost to new process education/implementation in sprint

24 Which Methodology Should I Use? Waterfall, Iterative and Spiral Methods Predictive Performance Large Teams Highly Structured Environments Outsourced or Multi sourced Projects High Financial or Safety Risk Significant Hardware Integration Agile/DOI Methods Exploratory Projects Small Teams Participative Environments Experienced Personnel Active Business Partners Software Dominant Projects In sourced Projects High Risk of Unknown Requirements 23

25 Do I Choose Agile or a Hybrid? Initial arguments for selecting a hybrid (traditional) method. High level of risk Large size of project Specified delivery commitment Organizational environment Suggested selection process: Map agile attributes based on organization s tolerance for risk and change Some agile practices can be transplanted to another methodology Leverage best practice processes to augment method chosen 24

26 Conclusions Use of Agile methods affects performance outcomes Choosing the appropriate methodology will maximize your delivery performance Agile performance can be successful 25

27 . Questions? 26

28 Educational Opportunities at CAI CAI Sponsors the IT Metrics Productivity Institute: Clearinghouse repository of best practices: Weekly educational newsletter: / SUBSCRIBE Bi monthly webinars hosted by industry leaders: / WEBINARS June 12th 11:00 AM 12:30 PM Software Sizing and Cost Estimating in 2007 June 27th 9:30 AM 11:00 AM Metrics Based Project Governance Aug. 15th 11:00 AM 12:30 PM Software Project Management in 2007 Aug. 22nd 11:00 AM 12:30 PM Managing with Metrics Aug. 30th 3:30 PM 5:00 PM Using Project History Data to Better Manage IT Sept. 5th 11:00 AM 12:30 PM An Overview of Software Benchmarking Sept. 19th 11:00 AM 12:30 PM Integrating Six Sigma and PMBoK Oct. 2nd 11:00 AM 12:30 PM Agile Legacy Reengineering Oct. 25th 11:00 AM 12:30 PM Test Driven Design An Agile Devleopment Methodology Oct. 30th 11:00 AM 12:30 PM A Primer on Function Points Nov 6th 11:00 AM 12:30 PM IT Outsourcing in China Nov 27th 11:00 AM 12:30 PM Ed Yourdon on Managing Death March Projects Dec. 4th 11:00 AM 12:30 PM Howard Rubin on The Future of IT in

29 Educational Opportunities at CAI Software Best Practices Conferences around the world: June 7 Albany, NY June 14 Jersey City, NJ Aug. 28 San Antonio, TX Sept. 11 Toronto, ON Sept. 13 Atlanta, GA Sept. 18 New York, NY Sept. 27 London, UK Oct. 4 Washington, DC Oct. 11 Detroit, MI Oct. 16 Oct. 18 Oct. 23 Nov. 1 Nov. 8 Nov. 13 Nov. 15 Nov. 15 Nov. 29 Jacksonville, FL Chicago, IL Minneapolis, MN New York, NY Albany, NY Ft. Lauderdale, FL Austin, TX Sydney, Australia Philadelphia, PA 28

30 Michael Harris President David Consulting Group (DCG) David Garmus Principal David Consulting Group (DCG) Michael Milutis Director of Marketing Computer Aid, Inc. (CAI) 29