agile porfolio management denver apln mar 2009
TRANSCRIPT
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
1/27
3/19/200
Copyright 2009, Leffingwell, LLC.
Scaling Software Agility:
Agile PortfolioManagement
Presentation to Denver Chapters of the
International Institute of Business Analysis
(IIBA) and Agile Project Leadership Network
(APLN)
By Dean Leffingwell
March 17, 2009
1
Copyright 2009, Leffingwell, LLC.
Dean Leffingwells Background
2
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
2/27
3/19/200
Copyright 2009, Leffingwell, LLC.
More from Dean Leffingwell
3
Copyright 2009, Leffingwell, LLC. 4
-- Taiichi Ohno, Toyota Production System.
(the father of lean methods)
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.
mailto:[email protected]://www.leffingwell.org/http://www.scalingsoftwareagility.wordpress.com/ -
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
3/27
3/19/200
Copyright 2009, Leffingwell, LLC.
Agenda
5
1. Orientation and Overview Why the waterfall/milestone governance model of software
development doesnt workPerspectives on Agile Portfolio Management: DTE Energy
Case Study3. Rethinking Investment Funding4. Rethinking Change Management5. Rethinking Governance and Oversight
Copyright 2009, Leffingwell, LLC.
WHY THE WATERFALLMILESTONE/GOVERNANCE
MODEL OF SOFTWAREDEVELOPMENT DOESNT
WORK
6
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
4/27
3/19/200
Copyright 2009, Leffingwell, LLC.
Waterfall/milestone governance doesnt work
because the development modeldoesnt work
Requirements
Design
Coding andUnit Test
SystemIntegration
Operation andMaintenance
7
The Waterfall Model of
Application
DevelopmentWhy, When I was yourage, sometimes Ive
believed in six impossiblethings before breakfast
The Queen to Alice inWonderland
There is probably no job on earth for which an ability to believe six impossiblethings before breakfast is more of a requirement than Software Project
Management
DeMarco and Lister - Waltzing with Bears: Managing Risks in SoftwareProjects
Copyright 2009, Leffingwell, LLC.
The Box We Build for Ourselves
8
Fixed time
Fixed scope(requirements)
rr
r r r
r
r r
r
rr
r
r
rr
r r
r
r
r
rr
r
r
2) We have to estimate
every task and resource
well need over the whole
time!
1) In order to give a professional estimate, we have to analyze
and estimate even this one before time even begins!
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
5/27
3/19/200
Copyright 2009, Leffingwell, LLC.
Assumptions Behind the Box
There exists a reasonably well defined set ofrequirements, 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 canpredict how that will go
Software research anddevelopmentcan be done on apredictable schedule and budget
9
Copyright 2009, Leffingwell, LLC.
What Really HappensMost software projects are 50-100% late (Standish Group)At deadline time, nothing works completelyWhat do we do now?
Take Action Promote the non-participants
Scope triage
Create a new plan
Reduce testing time
Cut back on quality
Extend delivery date
Repeat failed process
Requirements
Design
Coding andUnit Test
SystemIntegration
Operation andMaintenance
0 126
10
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
6/27
3/19/200
Copyright 2009, Leffingwell, LLC.
What Happens in the Box?
The teams are not on plan bad plan (blameplanning) or bad team (blame development team)?
They are under enormous pressure to deliver thepromised functionality in the box
In order to complete the committed work, the teamsmust actively resistany further change
They are about of time and they have only one
variable left under their control Solution: Sacrifice QUALITY
11
Copyright 2009, Leffingwell, LLC.
Insert Your Own Waterfall Defect Chart
Here
12
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
7/27
3/19/200
Copyright 2009, Leffingwell, LLC.
Wait, it gets worse-
The buggy solution we don't quite have is a poor fitto current requirements
25%
50%
75%
100%
0 3 6 9 12 15 18 21 24
Fidelity Gap
13
Copyright 2009, Leffingwell, LLC.
Looking Backwards - Conclusion
We failed to deliver the application as intended tothe customer in the predicted time frame
Quality is compromised- what we have is buggy
We now understand that the solution that wehave in process is off the mark. (requirementsdecay)
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
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
8/27
3/19/200
Copyright 2009, Leffingwell, LLC.
AGILE DEVELOPMENT
OVERVIEW
15
Copyright 2009, Leffingwell, LLC.
Agile Process Movement
16
Yahoo, Google,BTI, BMC,Nokia, DTEEnergy, Cisco,Citrix, HP, JPMorgan, AOLBoeing,Comcast,PayPal, EDS,Emerson,Fidelity
http://users.evtek.fi/~jaanah/ApplicationD/waterfall.gifhttp://www.extremeprogramming.org/rules/iterative.htmlhttp://images.google.com/imgres?imgurl=http://www.flashline.com/images/content/EUP.gif&imgrefurl=http://www.flashline.com/content/Ambler/reuseRUP.jsp&h=310&w=514&sz=9&tbnid=JUCTbCsxtGQJ:&tbnh=77&tbnw=128&hl=en&ei=qQ4iQ9ClCZCUFoLvnY8D&sig2=gySkwlUwO7j5Ts7s_MxEKw&start=4&prev=/images?q=rational+unified+process&svnum=10&hl=en&lr= -
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
9/27
3/19/200
Copyright 2009, Leffingwell, LLC.
What's Different About
Agile?
17
Copyright 2009, Leffingwell, LLC.
What Paradigms Are We Breaking?
18
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
10/27
3/19/200
Copyright 2009, Leffingwell, LLC.
Agile Kills the Box
19
Copyright 2009, Leffingwell, LLC.
Helps Avoid the Death March
20Slide by David Wood
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
11/27
3/19/200
Copyright 2009, Leffingwell, LLC.
Reduces Risk
21Slide by David Wood
Copyright 2009, Leffingwell, LLC.
Starts Delivering ROI Immediately
22
$ in
$$ in
$$$ in
$$$$ in
$$$$$ in
Waterfall $$$$$start here if youare lucky andon time
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
12/27
3/19/200
Copyright 2009, Leffingwell, LLC.
Delivers Better Fit for Purpose
Measure ofwaterfall customer
dissatisfaction
23Slide by David Wood
Copyright 2009, Leffingwell, LLC.
What Is EnterpriseSoftware Agility?
24
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
13/27
3/19/200
Copyright 2009, Leffingwell, LLC.
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
Copyright 2009, Leffingwell, LLC.
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
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
14/27
3/19/200
Copyright 2009, Leffingwell, LLC.
Enterprise Agility
That harness large numbers of agile teams to buildand release quality enterprise-class software more
rapidly than ever beforeExplicitly driven by intimate and immediate customerfeedback
A set of
organizational best practices
beliefs
core values
27
Copyright 2009, Leffingwell, LLC.
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
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
15/27
3/19/200
H
HH
H
For discussion, see www.scalingsoftwareagility.wordpress.com
Inspired by collaboration
Leffingwell, LLC. & Symbian Software Ltd.
2009 Leffingwell, LLC.
Copyright 2009, Leffingwell, LLC.
Agile Enterprise Adoption:Observed Anti-patterns
Insufficient refactoring of testing organizations, testingskills (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-agileportfolio/governance model
30
http://www.scalingsoftwareagility.wordpress.com/http://www.scalingsoftwareagility.wordpress.com/ -
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
16/27
3/19/200
Copyright 2009, Leffingwell, LLC.
PERSPECTIVE ON AGILE
PORTFOLIO MANAGEMENT:DTE ENERGY CASE STUDY
31
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 thedevelopment and management of energy related businesses and servicesnationwide with $9 billon in annual revenue and 11,000 employees. DTE EnergysInformation Technology Services (ITS) organization, now consisting of over 900people, provides leadership, oversight, delivery, and support on all aspects ofinformation technology (IT) across the enterprise.
They have been implementing an extending agile practices since 1998.
Copyright 2009, Leffingwell, LLC.
Legacy Thinking - Investment Funding
Mindset Manifestation Problems
widget engineering -Fixed schedule,functionality planning-Big Up FrontDesign/Analysis (BUFD)
- Long range plans- Resources committed yearin advance- Analysis paralysis
order taker mentality -Do what you are told-We are the boss of you
-False agreements. No buyin.
-Misses innovationcontribution from IT-Failure to meetexpectationsmistrust-No empowerment, lowermotivation
32
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
17/27
3/19/200
Copyright 2009, Leffingwell, LLC.
Legacy Thinking Change Management
Mindset Manifestation Problems
Maximize utilization -Resources committed longrange-100% allocation beforewhat if- Key resources assigned tomultiple projects
- No time to think or innovate- Dedicate resources to taskor lose resources- Thrashing productivitylost of most valuableresources- Exhaustion, burnout
Get it done Belief that best case plansmust succeed
- Deferred recognition ofplan vs. actual- Late discovery and re-
negotiation- Loss of credibility, mistrust
33
Copyright 2009, Leffingwell, LLC.
Legacy Thinking Governance andOversight
Mindset Manifestation Problems
Control through data
we can plan out a full
year of projects
- Fine grain reporting andoverhead- Detailed wbs, earned valuemetrics ,fully loaded Ganttcharts
- Reporting overhead- Annoying the team- Metrics dont reflect actualprogress-Could not assess new agileprojects with old metrics- Plans are obsolete, but nottreated that way
34
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
18/27
3/19/200
Copyright 2009, Leffingwell, LLC.
AGILE PORTFOLIO
MANAGEMENT:RETHINKING INVESTMENTFUNDING
35
Copyright 2009, Leffingwell, LLC.
From: too many projects to ContinuousContent Delivery
To Agile Portfolio
Dedicated teams stop multiplexing noone works on more than one team
Project overhead is replaced by standarditeration and release cadence
New initiatives appear as new content andare prioritized at each iteration/releaseboundary
Work in an iteration/release is fixed
Team resources are adjusted only atperiodic release boundaries
36
Getting anything done (new feature orepic) requires creation of a new project
Projects have significant overhead,planning, resourcing, execution, closure
Once started, projects take on a life of theirown. They develop antibodies to changeand closure.
Many small projects cause people tomultiplex 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!
From Traditional
Project, portfolio mix:Size, risk, reward
Agile Release Train withcontent management
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
19/27
3/19/200
Copyright 2009, Leffingwell, LLC.
To: Agile Velocity and Constraint-basedPlanning and Estimating
To Agile Estimating and Planning
Agile teams develop and monitor velocity(capacity) based on story points at iterationlevel
Story points can be normalized acrossteams
Standardized estimating by analogousmodel can also be applied at the level ofEpics 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
37
Traditional project estimates tasks at thelowest leaf
Requiring all leafs be identified beforeestimate is given
Forces Big Up Front Analysis andestimates based on false precision
Force fits later activities into a flawed WBS
From WBS Estimating andPlanning
Epic
FeatureStory
Copyright 2009, Leffingwell, LLC.
An Agile Requirements InformationModel
38
Epic
featureFeature:
storystory
storystory
Story:
Marketable experience,Used forportfolio estimating May also describe large architecturalinitiatives
Substantive user benefit Used forrelease planning Features sized to fit in release boundaries System-level, common and non-functional
requirements often carried here
User value Used foriteration planning Sized to fit in iteration boundaries
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
20/27
3/19/200
Copyright 2009, Leffingwell, LLC.
To: Simplified Business Case Proposals
To Agile Model
1-2 page business case form
Not much detail
Business cases that make the cut getexploratory iterations funding
Easily cancelled if progress notacceptable
Fast ROI if it is
Updated quarterly changes only
39
Detailed business case justificationsbecome project plans
False precision - detailedrequirements over-constrain solutionimplementation
May contain redundant schedule,budget, ROI information
Investment in the business casecauses resistant to changing the caseand plan
Too much overhead for quarterlyupdate
From Traditional , Document-based
Ipsum lorem
Copyright 2009, Leffingwell, LLC.
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
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
21/27
3/19/200
Copyright 2009, Leffingwell, LLC.
AGILE PORTFOLIO
MANAGEMENT: RETHINKINGCHANGE MANAGEMENT
41
Copyright 2009, Leffingwell, LLC.
From PMBOK to Agile ProjectManagement
From Traditional: Performed bytheproject manager
To Agile:Performed by the team
42
WorkBreakdownStructureestimating
Gantt Charts
scheduling
Critical Pathanalysis
Reporting
Highpriorityfeature
Iterationplanning
Actual velocitybasedestimating
Releaseplanningandroadmap
Release/iterationreview/retro-pective
2 pts
4 pts
2 pts
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
22/27
3/19/200
Copyright 2009, Leffingwell, LLC.
From Gantt to Asynchronous Sprints to AgileRelease Train
43
From: GanttTo: Independent,asynchronous,Sprints
To: Agile Release Train
Issues:Irrelevant to agile teamsHard to maintainAlways obsoleteIf a team isnt on theplan, is it a bad team orbad plan?
Measurepaper, notsoftware
Issues:Most agile companies start hereLittle coordination amongst teamsNon-harmonized schedulesNo visibility beyond the next sprintLittle or no system level visibility
Coordinates sprintsMulti- sprint visibility and commitmentTeams work out interdependencies onthe flyFull system visibilityRequires set-based development
Copyright 2009, Leffingwell, LLC.
To: Enterprise Release PlanningCollaborative, face-to-face, multi-level, multi-iteration
44
Eng mgrs
State of the business
Objectives for upcoming periods
Objectives for release
Prioritized feature set
Each team presents plans to group
Issues/impediments noted
Issues/impediments assigned
Release commitment vote?
Teams plan stories for iterations
Work out dependencies
Architects and PMs, POs circulate
|1|1
|1|1
|2|2
|2|2
|3|3
|3|3
|4|4
|4|4
architects
Product managers/
Product Owners
PMs
Executives
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
23/27
3/19/200
Copyright 2009, Leffingwell, LLC.
To: Rolling Wave Plan-of-Intent Roadmap
45
May 15,May 15, 0808
Road Rage Ported(part I)
Brickyard port started(stretch goal tocomplete)
Distributed platformdemo
ALL GUIs for bothgames demonstrable
New features (see
prioritized list) Demo of Beemer game
May 22, 08May 22, 08
Road Rage Completed
(single user)
Brickyard Ported (singleuser)
Road Rage multiuserdemonstrable
First multiuser gamefeature for Road Rage
New features (seeprioritized list)
Beemer game in Alpha
JulyJuly 0808
Multiuser Road Rage firstrelease
Brickyard Portedmultiuser demo
New features for bothgames (see prioritizedlist)
Beemer game to E3Tradeshow?
An updated, themed, and prioritized plan of intent Updated quarterly
High confidence next release, lower confidence next+1 Owned by teams. Maintained by PMO?
+Plus:A commitment from theteam to the next release
Copyright 2009, Leffingwell, LLC.
AGILE PORTFOLIOMANAGEMENT: RETHINKINGGOVERNANCE ANDOVERSIGHT
46
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
24/27
3/19/200
Copyright 2009, Leffingwell, LLC.
From Milestone-based to Knowledge-based Governance.
47
Milestones are iterations and incrementalreleases of working code
Status and quality are quantitative, notsubjective
Project office comes to teams (enablingleadership model)
Teams default model is to proceedunlessstopped by business case (no processdriven delays/waste)
No scheduling delays and overhead
Process changes applied and harvested
from teams retrospectives
Teams report milestones with document -based reviews
Subjective, milestone reports do notcorrelate to actual project status
Teams report to project office (leader asconductor/boss)
Teams cannot proceeduntil and unlessthey pass milestones (start-wait-start-waitwaste cycle)
Scheduling delays and overhead
Process changes dictated by those who
know best
From Traditional Milestone based To Agile Knowledge based
Copyright 2009, Leffingwell, LLC.
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
How to go about it:
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
48
Value timeWaiting/waste time
Source: Implementing Lean Software Development: From Concept to Cash. Poppendiecks
Customer
request/market feature
Delivery
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
25/27
3/19/200
Copyright 2009, Leffingwell, LLC.
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-of-teams function.
Resource adjustment (change management) happens at theseboundaries!
May be inappropriate for them to change their own resources
Question: who has the skills and discipline necessary toinstitutionalize this critical agile best practice?
Answer: PMO?
49
Copyright 2009, Leffingwell, LLC.
From: Waterfall-based MilestonesTo: Driving Incremental Delivery
50
Commit toMaintenance
ProgramApproved
1.1 - 1.nPotentially shippable Increments
Quality/GA Firewall
2.1 - 2.nIncremental releases
If (you must have them) Then (they must drive incremental delivery) Else (you dont need them)
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
26/27
3/19/200
Copyright 2009, Leffingwell, LLC.
Iteration Metrics
Stories achieved.
defects, unit tests,test automation,
To: Standardized Iteration and ReleaseMetrics
51
Release Evaluation
Did we achieve therelease?
Demo and objectiveevaluation
Release Metrics
Features completedvs. plan
Total velocity
Quality
Copyright 2009, Leffingwell, LLC.
Summary - The Agile PMONew Mission: Enable, Empower, Ensure
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 practices5. Implement common agile metrics: iteration, release &
process sets
6. Join Agile Project Management Leadership Network
52
PMO enables, fosters, and promotes agilepractices
-
8/3/2019 Agile Porfolio Management Denver Apln Mar 2009
27/27
3/19/200
Copyright 2009, Leffingwell, LLC.
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 BusinessNeeds,-- 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