l e a nsoftware development
www.poppendieck.comMary [email protected]@poppendieck.com
The Scaling DilemmaIt’s Not About Agile
l e a n
If Agile is GoodScaled Agile Must be Better
How do we Scale Agile?
How do we convince executives to invest in agile? How do we ensure teams work on the right stuff? How does agile work with a big legacy code base? How do waterfall and agile teams work together? What is the role of managers?
December 14 Copyright©2014 Poppendieck.LLC2
These are the Wrong Questions!
l e a n
Focus on Business Problems
HP LaserJet Firmware - 2008
1. Costs out of control
2. Could not add people fast enough
3. FW was the bottleneck for new products
Code Integration
10%
Detailed Planning
20%
Porting Code25%
Current Product Support
25%
Manual Testing
15%
Capacity for Innovation
5%
December 143 Copyright©2014 Poppendieck.LLC
l e a n
Ask the Right Questions
December 14 Copyright©2014 Poppendieck.LLC4
What if we used the same chip for all printers?How can we integrate early and often?
How can we create code that is always releasable?How can we re-engineer our planning process
to do it with minimal investment?
Simplified ArchitectureRapid Feedback to DevelopersIncreased Marketing Flexibility
l e a n
Measure Business Results
HP LaserJet Firmware - 2011
1. ~70% reduction in FW development cost per program
2. 50% reduction in FW headcount
3. FW moved from bottleneck to brand enabler: “Future Smart”
Code Integration2%
Agile Planning 5%
One Main
Branch15%
One Branch CPE 5%
Most Testing Automated
5%Continouus Delivery
Infrastructure23%
Capacity for Innovation >40%
December 145 Copyright©2014 Poppendieck.LLC
l e a n
Theory of Constraints
Every system has a bottleneck.
Value cannot flow through the system any faster than it flows through that bottleneck.
So the best way to improve the system flow is to improve the rate at which value flows through the bottleneck.
December 14 Copyright©2014 Poppendieck.LLC6
l e a n
Constraint #1
The Integration Problem% of Release Cycle Spent “Hardening”
December 14 Copyright©2014 Poppendieck.LLC7
Typical: 30%
Sometimes: 50%
Release Cycle
Top Companies: What is a Release Cycle?
l e a n
Constraint #2
Cost of Complexity
December 14 Copyright©2014 Poppendieck.LLC8
Deciding What to Build
Cost
Time
Features / Functions Used in a Custom System
Standish Group Study Reported at XP2002 by Jim Johnson, Chairman
Always 7%
Often 13%
Sometimes16%
Rarely 19%
Never 45%
Rarely / NeverUsed: 64%
Often / AlwaysUsed: 20%
50% of features requested by product managers do not deliver the expected results.
l e a n
Constraint #3
December 14 Copyright©2014 Poppendieck.LLC9
In the Beginning Success HappensGetting Teams to Work Together
l e a n
Constraint #4
December 14 Copyright©2014 Poppendieck.LLC10
The Time, Energy, and Initiative of Bright, Creative People
37%
17%
14%
21%
11%
20%
18%
4%
49%
9%
Mechanical
Electrical
Civil
Software
Chemical
Engineering Jobs Engineering Major Choices
~30%
~50%
~20%
EngagedNot EngagedActively Disengaged
l e a n
Solve for:
1. System Complexity2. Organizational Mindset3. Multi-team Cooperation4. Challenging Work
December 14 Copyright©2014 Poppendieck.LLC11
l e a n
One Thing We Know for Sure
For Complex SystemsThis does not work
December 14 Copyright©2014 Poppendieck.LLC12
l e a n
One Thing We Know for Sure
For Complex SystemsThis works
December 14 Copyright©2014 Poppendieck.LLC13
l e a n
The First Step to Stable Large Scale Systems
December 14 Copyright©2014 Poppendieck.LLC14
Acceptance test driven development processTight collaboration between business and delivery teamsCross-functional teams include QA and operationsAutomated build, testing, db migration, and deployment Incremental development on mainline with continuous integrationSoftware always production readyReleases tied to business needs, not operational constraints
Credit: Jez Humble
l e a n
Branches are Evil
Why Develop on the Trunk? + Keep Large Code Bases Stable+ Make Experiments Easy to Run+ Give Rapid Feedback to Developers+ Reduce the Cost of Finding and Fixing Problems+ Increase Business Flexibility and Responsiveness─ Teams that Release Together Must Work Together─ Staging Pipeline Requires New Thinking and Tools─ Keeping the Trunk Production-ready is Top Priority
December 14 Copyright©2014 Poppendieck.LLC15
l e a n
Solve for:
1. System Complexity2. Organizational Mindset3. Multi-team Cooperation4. Challenging Work
December 14 Copyright©2014 Poppendieck.LLC16
l e a n
Scaling is an Organizational Problem
The Product MindsetEntrepreneurial LeaderResponsible Engineering TeamSuccess = Delighted CustomersTough Tradeoffs are Made
Based on Market RealitiesProfit Center Mentality:
Reinvest Profit in the Product
The IT Mindset“The Business”Order-taking Development TeamSuccess = Cost, Schedule, ScopeTough Tradeoffs are Made
During the Planning ProcessCost Center Mentality:
Constantly Reduce Costs
December 1417 Copyright©2014 Poppendieck.LLC
In a Competitive EnvironmentWhich Mindset will Win?
l e a n
Structure the Organization to Match System ArchitectureShared Code Base? One Team
Teams too Large?Break Dependencies
Shared System Test? One Group
Groups too Large?Change the Architecture
December 1418 Copyright©2014 Poppendieck.LLC
Stop Digging
l e a n
Capacity
Use Capacity AllocationFor Portfolio Management
PortfolioIdea
ROMBusiness Case
ApprovalQueue of Approved Ideas
Project StartedDevelopment
Wait for ReleaseIntegration
Test the Idea
Product
December 1419 Copyright©2014 Poppendieck.LLC
20% Product Line 120% Product Line 210% Product Line 320% Tool Set 110% Tool Set 220% Infrastructure
l e a n
Replace GovernanceWith Product Management
Magic happens when engineers, designers and technology savvy product managers interact directly with customers in their native habitat.
-- Marty Cagan
December 14 Copyright©2014 Poppendieck.LLC20
Valuable
Feasible
Useable
http://www.svproduct.com/articles/
G rea tP roduct s
l e a n
Solve for:
1. System Complexity2. Organizational Mindset3. Multi-team Cooperation4. Challenging Work
December 14 Copyright©2014 Poppendieck.LLC21
l e a n
Cooperation requires accommodation.Accommodation has a cost.If the cost of accommodation is born by one
party, resentment arises and cooperation fails.Monopolies (by definition) don’t have to accommodate.
Monopolies destroy cooperation.Examples of Monopolies:Departments everyone loves to hate “Autonomous” Teams
December 1422 Copyright©2014 Poppendieck.LLC
AutonomyCooperation
Six Simple Rules: How to Manage Complexity without Getting Complicated Yves Morieux / Peter Tollman
l e a n
Cooperating Teams
Getting Teams to Work
Small (7+/-2)AutonomousShared Goal
Getting Teams to Work Together
At Pixar, it takes a team of ~200 people to turn out a great film; half creative, half technical.
“Everyone is invested in helping everyone else turn out their best work.”
December 1423 Copyright©2014 Poppendieck.LLC
Gary Gruver
One Team. Multiple Sub-teams. One Shared Goal. Sub-teams do not succeed unless the Team succeeds.
CooperationAutonomy
-- Ed Catmull
l e a n
Shared Responsibility
“The Business”“The Product Owner”“The Other Teams”
“We Work Together”“Nobody Succeeds Unless
Everyone Succeeds”
December 1424 Copyright©2014 Poppendieck.LLCNot Me All of Us
Who is Responsible for Delivering Value?
l e a n
The Military Model
Understand Command IntentTwo Levels Up
Command Intent:A concise expression of the purpose of the campaign, the desired results, and the expected team progress toward achieving the desired end state.
Maintain Situational AwarenessOne Level Up
1. Collaborative Planning2. Situational awareness of the
progress of other squads/platoons3. Adapt to make sure the
company reaches the end state
December 1425 Copyright©2014 Poppendieck.LLC
l e a n
Solve for:
1. System Complexity2. Organizational Mindset3. Multi-team Cooperation4. Challenging Work
December 14 Copyright©2014 Poppendieck.LLC26
l e a n
Change Delivery Teams To Problem Solving Teams
Delivery Problem Solving
December 1427 Copyright©2014 Poppendieck.LLC
l e a n
Impact-driven Development
December 14 Copyright©2014 Poppendieck.LLC28
1. Start with WHY – Purpose, Problem
2. Understand the desired impact:a. Who cares about the impact of potential solutions?b. How will these people measure the impact of outcomes? c. What changes can create outcomes that move the metrics
– in the right direction – enough to matter?
3. Prove that the impact is being achieved:a. Experiment: Prototype the most promising changes.
b. Implement a change only if its impact is validated.
c. Iterate rapidly until the desired impact is achieved.
Work Backward from Impact
Tom & Kai Gilb
l e a n
Case Study:Government
Case: British National Health Service, Electronic Patient Records, 2002 – 2011, £10bn.
In Response: Gov.UK.
Delivery team charter: service vision quantifiable goals [impacts] key performance indicators [metrics]
that show how they will meet user needs
December 14 Copyright©2014 Poppendieck.LLC29
4-8 weeks 6-8 weeks A few months, then iterate
See: https://www.gov.uk/transformation
Governance Principles: Don’t slow down delivery Decisions when they’re needed,
at the right level Do it with the right people Go see for yourself Only do it if it adds value Trust and verify
l e a nsoftware development
www.poppendieck.comMary [email protected]@poppendieck.com
Thank You!More Information: www.poppendieck.com