the scaling dilemma brisbane - yow! conferences...mary@poppendieck.com mary poppendieck thank you!...

l e a nsoftware development

www.poppendieck.comMary Poppendieckmary@poppendieck.commary@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 Poppendieckmary@poppendieck.commary@poppendieck.com

Thank You!More Information: www.poppendieck.com