The document provides guidance on building quality into software development through defect prevention rather than defect removal. It discusses how the best companies aim to freeze code and test within 10% of the release cycle, rather than leaving 30-50% for "hardening". An effective process matches tests to specifications and code, rather than introducing defects first. It also advocates optimizing throughput over utilization by limiting work, leveling the workload, and shortening deployment cycles.

1. Keynote
First Build the Right Thing
Then Build the Thing Right
Mary Poppendieck

2. lsoftware development
e a n
First Build the Right Thing
There is surely nothing quite so useless as doing
with great efficiently what should not be done at all.
– Peter Drucker
mary@poppendieck.com Mary Poppendieck www.poppendieck.com

3. The Shrinking World
“The fact is that because of the
cloud, today a young upstart
can take market share without
an incumbent having time to
react.” – Werner Vogles, Amazon.com
Successful Innovation:
Make a little.
Sell a little.
3 September 11 Copyright©2011 Poppendieck.LLC l e a n
Learn a little.

4. Solve the Right Problem
Most product failures are caused by
a lack of Customers.
“Many businesses disappear Think Like a Customer
because the founder-entrepreneur
insists that he or she knows better
than the market.” – Peter Drucker
“Don’t to what customers say they
want, understand their problems
and solve them.”– Per Haug Kogstad,
4
founder, Tandberg (now Cisco)
September 11 Copyrignt©2011 Poppendieck.LLC l e a n

5. Design the Experience
5 September 11 Copyrignt©2011 Poppendieck.LLC l e a n
Simulates the Flying Experience – Not the Buying Experience

6. What is Design Thinking?
Assemble a Diverse Team
Framing
 Observe the Situation
 Conceptualize the Problem
Reframe*
Ideation
 Obtain Customer Insights
Iterate
 Visualize/Prototype Ideas
Experimentation
 Try Tentative Solutions
*Pivot
6
 Refine Mental Models
September 11 Copyright©2011 Poppendieck.LLC l e a n

7. Requirements are Design
Control projects with the critical-few results that define value.
Give developers the freedom to discover how to deliver those results.
The worst scenario I can imagine is when we allow real customers, users, and
our own salespeople to dictate ‘functions and features’ to the developers,
carefully disguised as ‘customer requirements’. Maybe conveyed by our product
owners. If you go slightly below the surface of these false ‘requirements’ you
will find that they are not really requirements. They are really bad amateur
design for the ‘real’ requirements. From: Value-Driven Development Principles and
Values by Tom Gilb, –Agile Record, July 2010
Not this: But this:
P
R
I
O
R
I
T
I
Z
l e a n
E
D
!
7 September 11 Copyright©2011 Poppendieck.LLC

8. Don’t Divorce Design
From Implementation
Domain Experience Concurrent Engineering
Designers and implementers Implementers
work at the job they are intimately
are automating. involved in the
(Canadian Air Traffic design process.
Control System.)
Cross-Functional Teams Incremental Development
The team includes and Iterative Delivery
people from every Build a minimum-function
function necessary
for success, and has
version that works and
direct contact with give it to users. Get
users from the onset.
8 September 11 Copyright©2011 Poppendieck.LLC l e a n
feedback. Repeat.
See Fred Brooks: The Design of Design

9. The Fastest Lerner Wins
OODA Loop: Developed by USAF strategist John Boyd
Orient
“It is not the
strongest of a Observe
species that
survives,
Act Decide
but the one
nor the that is the most
responsive to change.”
most intelligent,
9 September 11 Copyright©2011 Poppendieck.LLC l e a n – Charles Darwin

10. 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
On-Site Customer “Get Out Of The Building”
Iteration Build-Measure-Learn Loop
Iteration Review Persevere or Pivot
Backlog “To Learn” List
User Story Hypothesis
Acceptance Test Split Test
Definition of Done Validated Learning
†https://elearning.industrial Continuous Integration Continuous Deployment
logic.com/gh/submit?Action
=PageAction&album=blog200 Customer Feedback Cohort-based Metrics
9&path=blog2009/2011/agil
eVsLeanStartup&devLangua Product Owner Entrepreneur
l e a n
ge=Java
CSM (Certified Scrum Master) CSM (Customer Success Manager)
10 September 11 Copyright©2011 Poppendieck.LLC

11. lsoftware development
e a n
Then Build the Thing Right
If you want more effective programmers, you will discover
that they should not waste their time debugging – they
should not introduce bugs to start with. – Edsger Dijkstra
mary@poppendieck.com Mary Poppendieck www.poppendieck.com

12. 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%
12 September 11
Release Cycle
Copyright©2011 Poppendieck.LLC l e a n

13. A Defect Injection Process
Specifications
Tests Code
Match?
13 September 11 Copyright©2011 Poppendieck.LLC l e a n

14. A Defect Prevention Process
Specifications
Tests
Code
14 September 11 Copyright©2011 Poppendieck.LLC l e a n

15. Observe Orient
Increase the Pace
Act Decide
Optimize Throughput – Not Utilization
 One Thing at a Time
 Take Small Steps
Limit Work To Capacity
 Timebox – Don’t Scopebox
 Pull – Don’t Push
Level the Workload
 Manage the Flow of Work
Queuing Theory 101
 Shorten the Deployment Cycle
15 September 11 Copyright©2011 Poppendieck.LLC l e a n

16. Release Cycle Observe Orient
6 Months Act Decide
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
16 September 11 Copyright©2011 Poppendieck.LLC l e a n

17. Observe Orient
Release Cadence Act Decide
6 Months Quarterly
Request
Features
Select
Features
Develop
Features Harden UAT
 Specification by Example
 Automated integration testing
 2-4 week iterations that produce
Release Cycle Release Cycle
Value-Added Time
integration-testable code
Total Cycle Time
 Business issues: Re-think public
Average Start End
release sales & support policies
Monthly Weekly/Daily/
 Cross Functional Team
Continuous
 Iterations become irrelevant
 Short Daily Meetings
 Estimating is largely unnecessary
 Visualization  Kanban works well here
 Business Issues: Software as a Service 
l e a n
Business Issues: Usually limited to
(SaaS) works best at this cadence. SaaS or internal releases
17 September 11 Copyright©2011 Poppendieck.LLC Thanks to Kent Beck for these ideas.

18. Innovation = 1% Inspiration
+ 99% Perspiration
1. Significant, focused technical expertise
 A decade of deliberate practice.
2. Deep understanding of an important problem
 What annoys people?
3. Passion, engagement, dedication
 Obsessed with growing the idea.
4. Experimental approach
 Build to learn. Learn to Pivot.
18 September 11 Copyrignt©2011 Poppendieck.LLC l e a n

19. lsoftware development
e a n
Thank You!
More Information: www.poppendieck.com
mary@poppendieck.com Mary Poppendieck www.poppendieck.com