WEBINAR: THE AGILE APPROACH TO PROCESS IMPROVEMENT … Presentation ITM… · Continuous Value Delivery • The “Customer” for most SPI projects is usually the senior manager,

0

WEBINAR: THE AGILE APPROACH TO PROCESS

IMPROVEMENT AND ITS IMPACT ON PRODUCTIVITY

Presented by David Consulting Group (DCG) and Computer Aid, Inc. (CAI)

1

Michael Milutis Director of Marketing

Computer Aid, Inc. (CAI) [email protected]

Michael Harris President

David Consulting Group (DCG) [email protected]

David Garmus Principal


2

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.

3

• 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®).

About Computer Aid, Inc. (CAI)

4

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

5

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 (http://agilemanifesto.org/)

[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 (www.pmdoi.org)

[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 – AddisonWesley, 2004

[7] Gestalt, LLC – www.gestaltllc.com

http://agilemanifesto.org/

http://www.pmdoi.org/

6

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

7

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.”

The Philosophies

8

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?

9

Agile Process Improvement – An Oxymoron?

• The first value statement in the Agile Manifesto leaps off the page at most processoriented 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

10

Scrum Development Process (thanks to Gestalt, LLC & the Gestalt Pathfinder TM Development Process)

List of requirements and issues Owned by Product Owner Everyone can add to it Only the Product Owner prioritizes

Product Backlog

One sentence summary Declared by Product Owner Accepted by team

Sprint Goal

List of tasks (416 hours) Owned by team Only the team can modify it

Sprint Backlog

List of obstacles Owned by Scrum Master Updated daily

Block List

Version of the product Shippable function – tested, documented, etc

Increment

Artifacts Roles Meetings Process 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

Sprint Planning Meeting

Sprint Review Meeting

Daily Scrum

Daily Work

Product Backlog Product Backlog

Product Backlog Product Backlog Increment Increment

Increment Increment

Sprint Backlog Sprint Backlog

Blocks List Blocks List

Product Product

Sprint: 30 Days

Product Owner:

Sets Priorities

Scrum Master Manages Process,

Removes roadblocks

Team: Develop Product

Stakeholders: Observe & Advise

Program Manager: Interfaces to

Client

PPQA: Monitor Process Compliance

Sprint Review Team demonstrates increment All discuss; gather feedback

Sprint Retrospective Team reviews Sprint Processes All discuss; gather feedback Capture Process Improvement

Requests

Sprint Retrospective Meeting

Output from Sprint Retrospective Process Imprvmt. Requests

www.gestaltllc.com

11

New Business Driver New Business Driver

Deliverable Product

Deliverable Product

100% Tested

Process Area C

Process Area A

Process Area B

Release Planning Planned Sprint

Planned Sprint

Planned Sprint

Planned Sprint

Planned Sprint

Planned Sprint

30 Day Sprint 30 Day Sprint




Priorities

Customer Customer

Priorities Priorities

Release

Planned Sprint

Planned Sprint

Planned Sprint

Priorities

Customer Customer

Planned Sprint


Priorities Planned Sprint


Priorities Planned Sprint


Priorities

Agile Process Improvement www.gestaltllc.com

12

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 agilelike 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

13

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 rollout 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

14


Planning an Agile SPI project • The SPI Project Sprints should be organized as follows: Develop, Pilot,

Refine, Rollout • 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

15


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

16

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

17

Lessons from Agile Software Development: Use Measurement To Enable Comparisons Between Methods

QUANTITATIVE QUALITATIVE

Deliverable Size Effort/Cost Duration Quality

Process Methods Skills Tools

Environment

Measured Performance

Capability Maturity

Baseline of Performance

Measure how you are doing

Identify what you are doing

Standard of performance

18

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

19

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

20

PROJECT SIZE and COMPLEXITY

RATE OF DELIVERY

DEFINITION CAPABILITY EFFORT

Schedule

Effort Costs

REQUIREMENT

FUNCTION POINT SIZE

Lessons from Agile Software Development: Using Historical Delivery Rates

HOURS per FUNCTION POINT

21

Web 4.8 3.2 ebusiness Web 6.6 5.8

Client Server 6.5 4.2 Main Frame 8.1 7.0

Average Hours/Function Point of Recent Enhancement Projects Across Different Platforms from DCG Database for Small Projects

Lessons from Agile Software Development: Hours Per Function Point

Traditional Agile

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

23

Which Methodology Should I Use?

– Waterfall, Iterative and Spiral Methods • Predictive Performance • Large Teams • Highly Structured Environments

• Outsourced or Multisourced 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 • Insourced Projects • High Risk of Unknown Requirements

24

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

25

Conclusions

• Use of Agile methods affects performance outcomes • Choosing the appropriate methodology will maximize your delivery performance

• Agile performance can be successful

26

Questions?

.

27

CAI Sponsors the IT Metrics Productivity Institute: – Clearinghouse repository of best practices: WWW.ITMPI.ORG – Weekly educational newsletter: WWW.ITMPI.ORG / SUBSCRIBE – Bimonthly webinars hosted by industry leaders:

WWW.ITMPI.ORG / 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 2008

Educational Opportunities at CAI

http://www.itmpi.org/



28

Educational Opportunities at CAI

Software Best Practices Conferences around the world: WWW.ITMPI.ORG/EVENTS

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 Jacksonville, FL Oct. 18 Chicago, IL Oct. 23 Minneapolis, MN Nov. 1 New York, NY Nov. 8 Albany, NY Nov. 13 Ft. Lauderdale, FL Nov. 15 Austin, TX Nov. 15 Sydney, Australia Nov. 29 Philadelphia, PA

29

Michael Milutis Director of Marketing

Computer Aid, Inc. (CAI) [email protected]

Michael Harris President


David Garmus Principal


WEBINAR: THE AGILE APPROACH TO PROCESS IMPROVEMENT … Presentation ITM… · Continuous Value Delivery • The “Customer” for most SPI projects is usually the senior manager,

Documents