Agile Porfolio Management Denver Apln Mar 2009

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
3/19/2009
More from Dean Leffingwell
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)
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
WHY THE WATERFALL MILESTONE/GOVERNANCE MODEL OF SOFTWARE DEVELOPMENT DOESNT WORK

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
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!
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
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
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
11
Insert Your Own Waterfall Defect Chart Here
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
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
14
3/19/2009
AGILE DEVELOPMENT OVERVIEW

15
Agile Process Movement
Yahoo, Google, BTI, BMC, Nokia, DTE Energy, Cisco, Citrix, HP, JP Morgan, AOL Boeing, Comcast, PayPal, EDS, Emerson, Fidelity
16
3/19/2009
What's Different About Agile?
17
What Paradigms Are We Breaking?
18
3/19/2009
Agile Kills the Box
19
Helps Avoid the Death March
Slide by David Wood
20
10
3/19/2009
Reduces Risk
Slide by David Wood
21
Starts Delivering ROI Immediately
$$$$$ in $$$$ in $$$ in $$ in
$ in
Waterfall $$$$$ start here if you are lucky and on time
22
11
3/19/2009
Delivers Better Fit for Purpose
Measure of waterfall customer dissatisfaction
Slide by David Wood
23
What Is Enterprise Software Agility?
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
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
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
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
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
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

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
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
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
34
17
3/19/2009
AGILE PORTFOLIO MANAGEMENT: RETHINKING INVESTMENT FUNDING

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

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
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
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)
40
20
3/19/2009
AGILE PORTFOLIO MANAGEMENT: RETHINKING CHANGE MANAGEMENT

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
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
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?
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?
45
AGILE PORTFOLIO MANAGEMENT: RETHINKING GOVERNANCE AND OVERSIGHT

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
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
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?
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
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
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
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
53
27

Agile Porfolio Management Denver Apln Mar 2009

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Agile Porfolio Management Denver Apln Mar 2009

Diunggah oleh

Hak Cipta:

Format Tersedia

3/19/2009

Scaling Software Agility: Agile Portfolio Management

Copyright 2009, Leffingwell, LLC.

Dean Leffingwells Background

Copyright 2009, Leffingwell, LLC.

More from Dean Leffingwell

Copyright 2009, Leffingwell, LLC.

Copyright 2009, Leffingwell, LLC.

Copyright 2009, Leffingwell, LLC.

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

The Waterfall Model of

Copyright 2009, Leffingwell, LLC.

The Box We Build for Ourselves

Copyright 2009, Leffingwell, LLC.

Assumptions Behind the Box

Copyright 2009, Leffingwell, LLC.

What Really Happens

Design Coding and Unit Test

Copyright 2009, Leffingwell, LLC.

What Happens in the Box?

Copyright 2009, Leffingwell, LLC.

Insert Your Own Waterfall Defect Chart Here

Copyright 2009, Leffingwell, LLC.

Copyright 2009, Leffingwell, LLC.

Looking Backwards - Conclusion

Copyright 2009, Leffingwell, LLC.

AGILE DEVELOPMENT OVERVIEW

Agile Process Movement

Copyright 2009, Leffingwell, LLC.

What's Different About Agile?

Copyright 2009, Leffingwell, LLC.

What Paradigms Are We Breaking?

Copyright 2009, Leffingwell, LLC.

Agile Kills the Box

Copyright 2009, Leffingwell, LLC.

Helps Avoid the Death March

Slide by David Wood

Copyright 2009, Leffingwell, LLC.

Slide by David Wood

Copyright 2009, Leffingwell, LLC.

Starts Delivering ROI Immediately

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

Copyright 2009, Leffingwell, LLC.

Delivers Better Fit for Purpose

Measure of waterfall customer dissatisfaction

Slide by David Wood

Copyright 2009, Leffingwell, LLC.

What Is Enterprise Software Agility?

Copyright 2009, Leffingwell, LLC.

That empowers teams to:

Copyright 2009, Leffingwell, LLC.

Achieving Team Agility

Copyright 2009, Leffingwell, LLC.

Achieving Enterprise Agility

4. Managing Highly Distributed Development

Copyright 2009, Leffingwell, LLC.

For discussion, see www.scalingsoftwareagility.wordpress.com

2009 Leffingwell, LLC.

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

Agile Enterprise Adoption: Observed Anti-patterns

Copyright 2009, Leffingwell, LLC.

PERSPECTIVE ON AGILE PORTFOLIO MANAGEMENT: DTE ENERGY CASE STUDY

Legacy Thinking - Investment Funding