Você está na página 1de 27

3/19/2009

Scaling Software Agility: Agile Portfolio Management


Presentation to Denver Chapters of the International Institute of Business Analysis (IIBA) and Agile Project Leadership Network (APLN) By Dean Leffingwell March 17, 2009

Copyright 2009, Leffingwell, LLC.

Dean Leffingwells Background

Copyright 2009, Leffingwell, LLC.

3/19/2009

More from Dean Leffingwell

Copyright 2009, Leffingwell, LLC.

Plans change very easily. Worldly affairs do not always go according to a plan and orders have to change rapidly in response to a change in circumstances. If one sticks to the idea that once set, a plan should not be changed, a business cannot exist for long.
-- Taiichi Ohno, Toyota Production System. (the father of lean methods)

Copyright 2009, Leffingwell, LLC.

3/19/2009

Agenda

1. Orientation and Overview Why the waterfall/milestone governance model of software development doesnt work Perspectives on Agile Portfolio Management: DTE Energy Case Study 3. Rethinking Investment Funding 4. Rethinking Change Management 5. Rethinking Governance and Oversight

Copyright 2009, Leffingwell, LLC.

WHY THE WATERFALL MILESTONE/GOVERNANCE MODEL OF SOFTWARE DEVELOPMENT DOESNT WORK


Copyright 2009, Leffingwell, LLC.
6

3/19/2009

Waterfall/milestone governance doesnt work because the development model doesnt work
Requirements

The Waterfall Model of


Design Coding and Unit Test

Application Development
System Integration Operation and Maintenance

Why, When I was your age, sometimes Ive believed in six impossible things before breakfast The Queen to Alice in Wonderland

There is probably no job on earth for which an ability to believe six impossible things before breakfast is more of a requirement than Software Project Management DeMarco and Lister - Waltzing with Bears: Managing Risks in Software Projects

Copyright 2009, Leffingwell, LLC.

The Box We Build for Ourselves


2) We have to estimate every task and resource well need over the whole time!

r
Fixed scope (requirements)

r r r r r r r r r r r

rr
r

r r r

r r

r r

Fixed time
1) In order to give a professional estimate, we have to analyze and estimate even this one before time even begins!

Copyright 2009, Leffingwell, LLC.

3/19/2009

Assumptions Behind the Box

There exists a reasonably well defined set of requirements, if we only took the time to define them
We can limit change or it will be small and manageable System integration is a stage in the lifecycle and we can predict how that will go Software research and development can be done on a predictable schedule and budget

Copyright 2009, Leffingwell, LLC.

What Really Happens


Most software projects are 50-100% late (Standish Group) At deadline time, nothing works completely What do we do now? Take Action
Requirements System Integration Operation and Maintenance
0 6 12

Design Coding and Unit Test

Promote the non-participants Scope triage Create a new plan Reduce testing time Cut back on quality Extend delivery date Repeat failed process

Copyright 2009, Leffingwell, LLC.

10

3/19/2009

What Happens in the Box?

The teams are not on plan bad plan (blame planning) or bad team (blame development team)? They are under enormous pressure to deliver the promised functionality in the box In order to complete the committed work, the teams must actively resist any further change They are about of time and they have only one variable left under their control Solution: Sacrifice QUALITY

Copyright 2009, Leffingwell, LLC.

11

Insert Your Own Waterfall Defect Chart Here

Copyright 2009, Leffingwell, LLC.

12

3/19/2009

Wait, it gets worseThe buggy solution we don't quite have is a poor fit to current requirements

100%

75%

Fidelity Gap
50%

25% 0 3 6 9 12 15 18 21 24

Copyright 2009, Leffingwell, LLC.

13

Looking Backwards - Conclusion


We failed to deliver the application as intended to the customer in the predicted time frame Quality is compromised- what we have is buggy We now understand that the solution that we have in process is off the mark. (requirements decay) We likely dont have anything holistic to ship to the hold the customers confidence We havent even driven the risk out of the project, because integration is not complete

Copyright 2009, Leffingwell, LLC.

14

3/19/2009

AGILE DEVELOPMENT OVERVIEW


Copyright 2009, Leffingwell, LLC.
15

Agile Process Movement

Yahoo, Google, BTI, BMC, Nokia, DTE Energy, Cisco, Citrix, HP, JP Morgan, AOL Boeing, Comcast, PayPal, EDS, Emerson, Fidelity

Copyright 2009, Leffingwell, LLC.

16

3/19/2009

What's Different About Agile?

Copyright 2009, Leffingwell, LLC.

17

What Paradigms Are We Breaking?

Copyright 2009, Leffingwell, LLC.

18

3/19/2009

Agile Kills the Box

Copyright 2009, Leffingwell, LLC.

19

Helps Avoid the Death March

Slide by David Wood

Copyright 2009, Leffingwell, LLC.

20

10

3/19/2009

Reduces Risk

Slide by David Wood

Copyright 2009, Leffingwell, LLC.

21

Starts Delivering ROI Immediately

$$$$$ in $$$$ in $$$ in $$ in

$ in
Waterfall $$$$$ start here if you are lucky and on time

Copyright 2009, Leffingwell, LLC.

22

11

3/19/2009

Delivers Better Fit for Purpose

Measure of waterfall customer dissatisfaction

Slide by David Wood

Copyright 2009, Leffingwell, LLC.

23

What Is Enterprise Software Agility?

Copyright 2009, Leffingwell, LLC.

24

12

3/19/2009

Team Agility

A disciplined set of
enhanced software engineering practices empirical software project management practices modified social behaviors

That empowers teams to:


more rapidly deliver quality software explicitly driven by intimate and immediate customer feedback

Copyright 2009, Leffingwell, LLC.

25

Achieving Team Agility

1. The Define/Build/Test Team 2. Mastering the Iteration 3. Smaller, More Frequent Releases

4. Two-level Planning
5. Concurrent Testing 6. Continuous Integration 7. Regular Reflection and Adaptation

Copyright 2009, Leffingwell, LLC.

26

13

3/19/2009

Enterprise Agility

A set of organizational best practices beliefs core values That harness large numbers of agile teams to build and release quality enterprise enterprise-class software more rapidly than ever before Explicitly driven by intimate and immediate customer feedback
Copyright 2009, Leffingwell, LLC.
27

Achieving Enterprise Agility

1. Intentional Architecture 2. Lean Requirements at Scale 3. Systems of Systems and the Agile Release Train

4. Managing Highly Distributed Development


5. Changing the Organization 6. Impact on Customers and Operations 7. Measuring Business Performance

Copyright 2009, Leffingwell, LLC.

28

14

3/19/2009

For discussion, see www.scalingsoftwareagility.wordpress.com

2009 Leffingwell, LLC.

Inspired by collaboration Leffingwell, LLC. & Symbian Software Ltd.

Agile Enterprise Adoption: Observed Anti-patterns


Insufficient refactoring of testing organizations, testing skills (TDD), test automation
Lack of basic team proficiency in agile technical practices Insufficient depth/competency in the product owner role Inadequate coordination of vision and delivery strategies Waterscrumming - Agile development in a non-agile portfolio/governance model

Copyright 2009, Leffingwell, LLC.

30

15

3/19/2009

The following slides are abstracted from a case study Establishing an Agile Portfolio to Align IT Investments with Business Needs -- Thomas and Baker, DTE Energy presented at Agile 2008, by DTE Energy. DTE Energy, a Fortune 300 is a diversified energy company involved in the development and management of energy related businesses and services nationwide with $9 billon in annual revenue and 11,000 employees. DTE Energys Information Technology Services (ITS) organization, now consisting of over 900 people, provides leadership, oversight, delivery, and support on all aspects of information technology (IT) across the enterprise. They have been implementing an extending agile practices since 1998.

PERSPECTIVE ON AGILE PORTFOLIO MANAGEMENT: DTE ENERGY CASE STUDY


Copyright 2009, Leffingwell, LLC.
31

Legacy Thinking - Investment Funding

Mindset
widget engineering

Manifestation
-Fixed schedule, functionality planning -Big Up Front Design/Analysis (BUFD) -Do what you are told -We are the boss of you

Problems
- Long range plans - Resources committed year in advance - Analysis paralysis -False agreements. No buy in. -Misses innovation contribution from IT -Failure to meet expectations mistrust -No empowerment, lower motivation

order taker mentality

Copyright 2009, Leffingwell, LLC.

32

16

3/19/2009

Legacy Thinking Change Management

Mindset Maximize utilization

Manifestation
-Resources committed long range -100% allocation before what if - Key resources assigned to multiple projects

Problems
- No time to think or innovate - Dedicate resources to task or lose resources - Thrashing productivity lost of most valuable resources - Exhaustion, burnout - Deferred recognition of plan vs. actual - Late discovery and renegotiation - Loss of credibility, mistrust

Get it done

Belief that best case plans must succeed

Copyright 2009, Leffingwell, LLC.

33

Legacy Thinking Governance and Oversight


Mindset
Control through data we can plan out a full year of projects

Manifestation
- Fine grain reporting and overhead - Detailed wbs, earned value metrics ,fully loaded Gantt charts

Problems
- Reporting overhead - Annoying the team - Metrics dont reflect actual progress -Could not assess new agile projects with old metrics - Plans are obsolete, but not treated that way

Copyright 2009, Leffingwell, LLC.

34

17

3/19/2009

AGILE PORTFOLIO MANAGEMENT: RETHINKING INVESTMENT FUNDING


Copyright 2009, Leffingwell, LLC.
35

From: too many projects to Continuous Content Delivery


From Traditional
Getting anything done (new feature or epic) requires creation of a new project Projects have significant overhead, planning, resourcing, execution, closure Once started, projects take on a life of their own. They develop antibodies to change and closure. Many small projects cause people to multiplex between projects

Each project switch takes 20% overhead Working on three projects means people only deliver value 40% of the time While switching to agile, one company diagnosed the failures of the first 5 teams first few iterations. Conclusion: No one worked on the project long enough to accomplish anything!

To Agile Portfolio
Dedicated teams stop multiplexing no one works on more than one team Project overhead is replaced by standard iteration and release cadence New initiatives appear as new content and are prioritized at each iteration/release boundary Work in an iteration/release is fixed Team resources are adjusted only at periodic release boundaries

Project, portfolio mix: Size, risk, reward

Agile Release Train with content management

Copyright 2009, Leffingwell, LLC.

36

18

3/19/2009

To: Agile Velocity and Constraint-based Planning and Estimating


From WBS Estimating and Planning
Traditional project estimates tasks at the lowest leaf Requiring all leafs be identified before estimate is given Forces Big Up Front Analysis and estimates based on false precision Force fits later activities into a flawed WBS

To Agile Estimating and Planning


Agile teams develop and monitor velocity (capacity) based on story points at iteration level Story points can be normalized across teams Standardized estimating by analogous model can also be applied at the level of Epics and Features Epic estimating can be used for gross, portfolio-level planning Feature estimates can be used for release (product) level planning Story points used for iteration planning

Epic Feature Story


Copyright 2009, Leffingwell, LLC.
37

An Agile Requirements Information Model


Epic
Marketable experience ,Used for portfolio estimating May also describe large architectural initiatives

Feature:

feature

Substantive user benefit Used for release planning Features sized to fit in release boundaries System-level, common and non-functional requirements often carried here

story story story story Story:

User value Used for iteration planning Sized to fit in iteration boundaries

Copyright 2009, Leffingwell, LLC.

38

19

3/19/2009

To: Simplified Business Case Proposals


From Traditional , Document-based
Detailed business case justifications become project plans False precision - detailed requirements over-constrain solution implementation May contain redundant schedule, budget, ROI information Investment in the business case causes resistant to changing the case and plan Too much overhead for quarterly update

To Agile Model
1-2 page business case form Not much detail Business cases that make the cut get exploratory iterations funding Easily cancelled if progress not acceptable Fast ROI if it is Updated quarterly changes only

Ipsum lorem

Copyright 2009, Leffingwell, LLC.

39

To: Agile Portfolio Planning

Establish sizing model for epics, features and stories


Prioritize epics at portfolio level Revised business cases quarterly Just prior to release planning boundaries
Break epics into features and size features Prioritize features

At Release Planning
Business case drives vision - which drives features Resources adjusted to address constraints (velocity bottlenecks)

Copyright 2009, Leffingwell, LLC.

40

20

3/19/2009

AGILE PORTFOLIO MANAGEMENT: RETHINKING CHANGE MANAGEMENT


Copyright 2009, Leffingwell, LLC.
41

From PMBOK to Agile Project Management


From Traditional: Performed by the project manager
Work Breakdown Structure estimating

To Agile: Performed by the team


2 pts

High priority feature

4 pts 2 pts

Actual velocity based estimating

Gantt Charts scheduling

Iteration planning

Critical Path analysis

Release planning and roadmap

Reporting

Release/iteration review/retropective

Copyright 2009, Leffingwell, LLC.

42

21

3/19/2009

From Gantt to Asynchronous Sprints to Agile Release Train


From: Gantt
To: Independent, asynchronous, Sprints

To: Agile Release Train


Coordinates sprints Multi- sprint visibility and commitment Teams work out interdependencies on the fly Full system visibility Requires set-based development

Issues: Irrelevant to agile teams Hard to maintain Always obsolete If a team isnt on the plan, is it a bad team or bad plan? Measure paper, not software

Issues: Most agile companies start here Little coordination amongst teams Non-harmonized schedules No visibility beyond the next sprint Little or no system level visibility

Copyright 2009, Leffingwell, LLC.

43

To: Enterprise Release Planning


Collaborative, face-to-face, multi-level, multi-iteration
State of the business Objectives for upcoming periods Executives PMs Objectives for release Prioritized feature set

architects

Teams plan stories for iterations Work out dependencies Architects and PMs, POs circulate
Product managers/ Product Owners

|1 |2 |3 |4 |1 |2 |3 |4

Each team presents plans to group Issues/impediments noted

Issues/impediments assigned Eng mgrs Release commitment vote?

Copyright 2009, Leffingwell, LLC.

44

22

3/19/2009

To: Rolling Wave Plan-of-Intent Roadmap


An updated, themed, and prioritized plan of intent Updated quarterly High confidence next release, lower confidence next+1 Owned by teams. Maintained by PMO?
May 15, 08 May 22, 08 July 08

+Plus: A commitment from the team to the next release

Road Rage Ported (part I) Brickyard port started (stretch goal to complete) Distributed platform demo ALL GUIs for both games demonstrable New features (see prioritized list) Demo of Beemer game

Road Rage Completed (single user) Brickyard Ported (single user) Road Rage multiuser demonstrable First multiuser game feature for Road Rage New features (see prioritized list) Beemer game in Alpha

Multiuser Road Rage first release Brickyard Ported multiuser demo New features for both games (see prioritized list) Beemer game to E3 Tradeshow?

Copyright 2009, Leffingwell, LLC.

45

AGILE PORTFOLIO MANAGEMENT: RETHINKING GOVERNANCE AND OVERSIGHT


Copyright 2009, Leffingwell, LLC.
46

23

3/19/2009

From Milestone-based to Knowledgebased Governance.


From Traditional Milestone based
Teams report milestones with document based reviews Subjective, milestone reports do not correlate to actual project status Teams report to project office (leader as conductor/boss) Teams cannot proceed until and unless they pass milestones (start-wait-start-wait waste cycle) Scheduling delays and overhead Process changes dictated by those who know best

To Agile Knowledge based


Milestones are iterations and incremental releases of working code Status and quality are quantitative, not subjective Project office comes to teams (enabling leadership model) Teams default model is to proceed unless stopped by business case (no process driven delays/waste) No scheduling delays and overhead Process changes applied and harvested from teams retrospectives

Copyright 2009, Leffingwell, LLC.

47

With Value Stream Mapping


Pick a feature level item from a real project and perform value stream mapping from concept to cash

Identify all steps from customer request to customer delivery Focus on steps and time, not costs Look for places to eliminate one of the seven wastes Gather stakeholders and take 1-2 hrs to draw a map and discuss it Take the time to gather and refine missing data Meet again, revise the map and discuss implications Pick the biggest delays and longest cues and take action Repeat
Delivery

How to go about it:


Customer request/market feature

Value time Waiting/waste time Source: Implementing Lean Software Development: From Concept to Cash. Poppendiecks

Copyright 2009, Leffingwell, LLC.

48

24

3/19/2009

To: PMO Drives Release Planning, Reviews, Retrospectives


Release planning is a routine, major enterprise event

Requires: coordination, cooperation, logistics, facilitation, planning, discipline, metrics


Difficult for teams themselves to coordinate this across teams-ofteams function. Resource adjustment (change management) happens at these boundaries! May be inappropriate for them to change their own resources Question: who has the skills and discipline necessary to institutionalize this critical agile best practice? Answer: PMO?

Copyright 2009, Leffingwell, LLC.

49

From: Waterfall-based Milestones To: Driving Incremental Delivery


If (you must have them) Then (they must drive incremental delivery) Else (you dont need them)

Program Approved

2.1 - 2.n
Incremental releases

Commit to Maintenance

Quality/GA Firewall

1.1 - 1.n
Potentially shippable Increments

Copyright 2009, Leffingwell, LLC.

50

25

3/19/2009

To: Standardized Iteration and Release Metrics


Release Evaluation Did we achieve the release? Demo and objective evaluation

Iteration Metrics Stories achieved. defects, unit tests, test automation,

Release Metrics Features completed vs. plan Total velocity Quality

Copyright 2009, Leffingwell, LLC.

51

Summary - The Agile PMO New Mission: Enable, Empower, Ensure


PMO enables, fosters, and promotes agile practices 1. Leads value chain analysis 2. Educate project managers in lean and agile 3. Adopt agile estimating and portfolio planning 4. Implement Agile Release Train best practices 5. Implement common agile metrics: iteration, release & process sets 6. Join Agile Project Management Leadership Network

Copyright 2009, Leffingwell, LLC.

52

26

3/19/2009

Sources and Resources

Agile Portfolio Management -- Jochen Krebs, 2008, Microsoft Press Agile Project Management Leadership Network, http://apln.org/ Establishing an Agile Portfolio to Align IT Investments with Business Needs, -- Thomas and Baker, DTE Energy, Proceedings of Agile 2008 Implementing Lean Software Development: From Concept to Cash -- Poppendieck, 2007. Addison-Wesley Scaling Software Agility: Best Practices for Large Enterprises -- Leffingwell, 2007. Addison-Wesley The Software Project Managers Bridge to Agility -- Sliger and Broderick, 2008. Addison Wesley

Copyright 2009, Leffingwell, LLC.

53

27