"Lean software development: discovering waste" by Mary Poppendieck

lsoftware development
e a n
Lean Software Development
Discovering Waste

mary@poppendieck.com Mary Poppendieck www.poppendieck.com

Two Kinds of
Software Development
Process Support Product Development
The Application Development Software intensive products.
portion of IT organizations.
If you divide IT into Operations
and Application Development
THEN
Almost never referred to as IT
“Standard” Lean Tools are by the people who do it.
appropriate for IT Operations
Development generally does
Avoid “Standard” Lean Tools for not report to a CIO.
Application Development

l e a n
Accounts for a large and
growing majority of
2 October 11 Copyright©2011 Poppendieck.LLC software developed today

Lean for Development

Old-Fashioned Chocolate Layer Cake
“We baked 130 cakes in search of the perfect wedge.”
What about? Why not?
 Standard work  Learning cycles
 Do it right the first time  Do it wrong lots of times
 Variation  Manage flow, not projects
 5 S’s  Simplicity

l e a n
Operations
Toolkit Development
Toolkit
3 October 11 Copyright©2011 Poppendieck.LLC


1. Build the Right Thing
2. Build the Thing Right
3. Deliver (& Learn) Fast

4 October 11 Copyright©2011 Poppendieck.LLC l e a n

Build the Right Thing

There is nothing so useless as doing efficiently that
which should not be done at all. – Peter Drucker
Most product failures Think Like a Customer
are caused by
a lack of Customers.
“Don’t to what customers say they
want, understand their problems
and solve them.”– Per Haug Kogstad,

l e a n
founder, Tandberg (now Cisco)


What is Design Thinking?
Diverse Design Team
Framing
 Observe the Situation
 Conceptualize the Problem
Reframe*

Ideation
 Obtain Customer Insights
Iterate

 Visualize/Prototype Ideas

Experimentation

l e a n
 Try Tentative Solutions
*Pivot  Refine Mental Models

Waste 1: Extra Features
Features / Functions Used in a Typical System Cost of Complexity
Often / Always Rarely / Never
Used: 20% Used: 64%

Sometimes Rarely 19%
16%

Cost
Often 13%

Always 7%

Never 45%

Standish Group Study Reported at XP2002 by Jim Johnson, Chairman Time

l e a n
The Biggest opportunity for increasing Software
Development Productivity: Write Less Code!

Waste 2: Handovers
A handover occurs whenever we separate:*
 Responsibility − What to do
 Knowledge − How to do it
 Action − Actually doing it
 Feedback − Learning from results
*Alan Ward: Lean Product and Process Development

Not this: But this:
P
R
I
O
R
I
T
I
Z
E

l e a n
D
!


The Lean Startup
Agile Vs. Lean Startup
Adapted from similar
chart posted by Joshua Agile Lean Startup
Kerievsky, Industrial
Logic Blog† August, 2011 Product Roadmap Business Model Canvas
Product Vision Product Market Fit
Release Plan Minimal Viable Product
Iteration Build-Measure-Learn Loop
Iteration Review Persevere or Pivot
Backlog “To Learn” List
User Story Hypothesis
Continuous Integration Continuous Deployment
Definition of Done Validated Learning
†https://elearning.industrial
Acceptance Test Split Test
logic.com/gh/submit?Action
=PageAction&album=blog200 Customer Feedback Cohort-based Metrics

l e a n
9&path=blog2009/2011/agil
eVsLeanStartup&devLangua On-Site Customer “Get Out Of The Building”
ge=Java
Product Owner Entrepreneur

Build Quality In
Every software development process ever invented has had the same
primary goal – find and fix defects as early in the development
process as possible. If you are finding defects at the end of the
development process – your process is not working for you.
How good are you?
When in your release cycle do you try to freeze code and test the system?
What percent of the release cycle remains for this “hardening”?
Top Companies: <10%
Typical: 30%

Sometimes: 50%

11 October 11
Release Cycle
Copyright©2011 Poppendieck.LLC l e a n

Waste 3: Defects

The Longer Defects are Undetected,

l e a n
the Harder They are to Find.


Waste 4: Technical Debt
Technical Debt: Anything that makes code difficult to change
 Sloppy Code
Code reviews  standards, quality, knowledge transfer.

 No Test Harness (=Poka Yoke)
Code without a test harness is Legacy Code.

 Dependencies
A divisible architecture is fundamental.

 Unsynchronized Code Branches
The longer two code branches

l e a n
remain apart, the more difficult
they are to merge together.

A Defect Injection Process

Specifications

Tests Code

l e a n
Match?

A Defect Prevention Process

Specifications

Tests

l e a n
Code

Discipline on Steroids
Environment
VERSION CONTROL & Application
Source
Code & Tests Configuration
Scripts

Self-Service UAT Stage
Deployments Configure Environment
Testers Deploy Binaries
Smoke Test
Manual Testing

Develop Stage Commit Stage Acceptance Stage Capacity Stage
Design Compile Configure Environment Configure Environment
Code & Script Commit Tests Deploy Binaries Testers Deploy Binaries
Unit Test Assembly Smoke Test Smoke Test
Refactor Code Analysis Run Acceptance Tests Run Capacity Tests

BINARIS

Metadata
Metadata
BINARIS

Production

Reports
Metadata

Reports
BINARIS
Metadata

Reports

Configure Environment
Reports

Operations Deploy Binaries
Push-Button Smoke Test
Releases

ARTIFACT REPOSITORY

l e a n

The Fastest Learner Wins

Model Build

Learn Measure


Waste 5: Work in Progress

Work in Progress hides problems.

Lower the Work in Progress gradually;
Expose the biggest problems first.
Shrink the problems one at a
Work in Progress

RISK: Pro
Building the Defects! Not time, biggest problem first.
Technical found until
Wrong Thing.
Risk: Debt: Change Pro
Building the is too integration… Competition
Wrong Thing expensive Too Introduces a
better product. Poor
Slow

l e a n
UI


Waste 6: Task Switching


Waste 7: Delays


Model Build
Release Cycle
6 Months Learn Measure

Quick & Dirty Value Stream Map:

Request Request Select Develop
Features Features Features Features Harden UAT

Release Cycle Release Cycle Release Cycle

Value-Added Time
Total Cycle Time Time
Total Cycle
Start Average Start End

Business Model:
 Software installed at customer site

l e a n
 Support each release
 Avoid releases

Model Build
Release Cycle
Quarterly Learn Measure

Hardening must be  2 weeks.
Typically: 2-4 week iterations
Code from each iteration goes to integration testing
Automated integration testing becomes necessary
Business issues:
How to price and sell releases?
Which releases to support?
Supporting multiple branches

l e a n
can create a support nightmare
Public vs. Private releases?

Model Build
Release Cycle
Monthly Learn Measure

Now you need:
Cross Functional Team
Visualization
Short Daily Meetings
SBE/TDD working!
Hardening  3 days
Business Environment
Works best for:
 Software as a Service (SaaS)

 Internal Software

Model Build
Release Cycle
Weekly/Daily/Continuous Learn Measure

Kanban works well The team is everyone.
Iterations become irrelevant
High discipline is fundamental
Estimating is largely unnecessary
Rapid cycles of learning drive portfolio decisions

DevOps:
Test & deployment automation is essential

l e a n
Business Issues:
Increasingly common in startups

lsoftware development
e a n
Thank You!
More Information: www.poppendieck.com

mary@poppendieck.com Mary Poppendieck www.poppendieck.com

"Lean software development: discovering waste" by Mary Poppendieck

More Related Content

What's hot (20)

Similar to "Lean software development: discovering waste" by Mary Poppendieck (20)

More from Operae Partners (20)

Recently uploaded (20)

"Lean software development: discovering waste" by Mary Poppendieck