l e a n - ipacop april 12 5 l e a n yrig ht© 200 6 pop pen diec k.l lc lean principle: eliminate...

l e a n software development

www.poppendieck.com Mary Poppendieck [email protected] [email protected]

Faulty Assumptions

How Lean Software Development Reduces Risk

l e a n

Assumptions

Assumption: an unstated belief about how the world is, or will become.

At the heart of most disasters we find faulty assumptions in design or operation.

Assumptions made are risks accepted and taken. When assumptions are tied to other assumptions, risks quickly magnify.

April 12 Copyright©2012 Poppendieck.LLC 2

Robert Charette, Challenging the Fundamental Notions of Software Development

http://www.itmpi.org/assets/base/images/itmpi/privaterooms/robertcharette/ChallengingtheFundamentalNotions.pdf

It is not what you know that can hurt you.

It is what you know that is not so. Will Rodgers

Examine Your Assumptions

l e a n

TPS: Just-in-Time Flow

Faulty Assumption:

Maximum machine productivity = maximum overall productivity

April 12 3 Copyright©2008 Poppendieck.LLC

Faulty Assumption:

Maximum individual productivity = maximum overall productivity

l e a n April 12 4 Cop

yrig

ht©

200

6

Pop

pen

diec

k.L

LC

Assumption:

Early Specification Reduces Waste

Features and Functions Used in a Typical System

Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

Always

7%

Often

13%

Sometimes

16% Rarely

19%

Never 45%

Rarely or Never

Used: 64%

Often or Always

Used: 20%


yrig

ht©

200

6

Pop

pen

diec

k.L

LC

Lean Principle:

Eliminate Waste

Waste is making the wrong thing or making the thing wrong.

Features that will not be used are waste, even if customers asked for them!

In any system where technology or market conditions change, an early detailed specification significantly increases waste.

The Biggest opportunity for increasing Software Development Productivity: Write Less Code!

Cost

Time

l e a n

TPS: Single Digit Set-up

Manufacturing

Faulty Assumption: Die changed have a huge overhead

Don’t change dies very often

TPS: Economics requires frequent die change

One Digit Exchange of Die

Software Development

Faulty Assumption: Releases have a huge overhead

Don’t release very often

Lean: Economics requires many frequent releases

Continuous Delivery

March, 2003 6 Cop

yrig

nt©

200

3

Pop

pen

diec

k.L

LC


yrig

ht©

200

6

Pop

pen

diec

k.L

LC

Assumption: The Job of

Testing is to Find Defects

The job of testing is to prevent defects

If you are focused on finding defects

– you are not focused on preventing them.

A quality process builds quality into the code

If you routinely find defects during verification

– your process is defective.

Defects are not caused by developers

Defects are caused by a system which allows defects.

– Defects are a management problem. --- W. Edwards Deming

l e a n

Lean Principle:

Build Quality In

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”?

Typical: 30%

Sometimes: 50%

Top Companies: <10%

Release Cycle

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.


l e a n

Total Cycle Time

Assumption: Releases are

Painful! Avoid Releases!

Is Your Release Cycle greater than six months?

Quick & Dirty Value Stream Map:


Release Cycle Release Cycle

Harden Design UAT Develop Need a Feature

Release Cycle

Total Cycle Time Value-Added Time

Average Start End Start

Need a Feature

How can a one week feature

take over a year to deliver?

l e a n

Lean Principle:

Learn Constantly

For Each Business Capability:

1. Design a. Specify: Discuss and agree on

examples of intended behavior.

b. Automate: Put the examples into a regression framework (eg. cucumber).

2. Implement a. Develop: TDD + CI (with Contract Tests)

b. Refactor: Clean up the code to keep it simple.

c. Regression: End-to-End testing with regression framework.

3. Validate a. Test: Exploratory Testing, Performance Testing, Canary Releasing

b. Measure Value: A/B Experiments, Cohort Metrics, Interviews, etc.

4. Learn April 12 Copyright©2012 Poppendieck.LLC 10

Iter

ate

l e a n

Rep

orts

Met

adat

a

Rep

orts

Met

adat

a

BIN

AR

IS

Continuous Delivery

Testers

Self-Service Deployments

Source

Code & Tests

UAT Stage Configure Environment

Deploy Binaries

Smoke Test

Manual Testing

Rep

orts

Met

adat

a

Capacity Stage Configure Environment

Deploy Binaries

Smoke Test

Run Capacity Tests

Operations Push-Button

Releases

Testers

Production Configure Environment

Deploy Binaries

Smoke Test

Acceptance Stage Configure Environment

Deploy Binaries

Smoke Test

Run Acceptance Tests

Commit Stage Compile

Commit Tests

Assembly

Code Analysis

BIN

AR

IS

VERSION CONTROL

ARTIFACT REPOSITORY

Environment

& Application

Configuration

Scripts

BIN

AR

IS

Develop Stage Design

Code & Script

Unit Test

Refactor

Rep

orts

Met

adat

a


Design Stage Model

Hypothesis

SBE

Wireframes

l e a n

Assumption:

Organize with Projects

Up-front funding

Decompose into Detailed Tasks

Schedule Each Task

Manage Tasks to Schedule

Success = Cost/Schedule/Scope

Projects have an “end”

Project Teams Disband

Start of Project

Completion

Maintenance

Batch Funding →

Short Term Thinking


Projects

l e a n

Lean Principle:

Optimize the Whole System

Products

Incremental funding

Scope is expected to evolve

Learning is more important than “The Plan”

Manage Workflow, rather than Tasks

Success = profit/market share

Successful Products don’t “end”

Team usually stays with the Product

Concept Feasibility

Internal Release

Alpha Release

Beta Release

First Production Release

Major Release

Dot upgrade

Incremental Funding

→ System Thinking


l e a n

Empire State Building

September 22, 1929

Demolition started

January 22, 1930

Excavation started

March 17, 1930

Construction started

November 13, 1930

Exterior completed

May 1, 1931

Building opened

Exactly on time

18% under budget

One Year Earlier:

How did they do it? The key: Focus on FLOW. April 12 Copyright©2011 Poppendieck.LLC 14

l e a n

Steel Schedule

We thought of the work as if it

were a band marching through

the building and out the top.

From: “Building the Empire State” Builders Notebook: Edited by Carol Willis


l e a n

The Four Pacemakers

1. Structural Steel Construction

Completed September 22, 12 days early

2. Concrete Floor Construction

Completed October 22, 6 days early

3. Exterior Metal Trim &Windows

Completed October 17, 35 days early

4. Exterior Limestone

Completed November 13, 17 days early

From: “Building the Empire State” Builders Notebook: Edited by Carol Willis


l e a n

Key Success Factors

1. Teamwork of owner, architect, and builder

Eliminated design loops by consulting experts early.

2. Deeply Experienced Builders

Fixed Price Contract!

3. Focus on the key constraint: Material Flow

500 trucks a day – no storage on site

4. Decoupling

The pacemakers (and other systems) were designed to be independent

5. Cash Flow Thinking Every day of delay cost $10,000 ($120,000 today).

6. Schedule was not laid out based on the details of the building design, the building was designed based on the constraints of the situation.

Two acres of land in the middle of New York City, zoning ordinances, $35,000,000 of capital, the laws of physics, and a May 1, 1931 deadline.


l e a n

Lessons

Design system to meet the real constraints;

do not derive constraints from the design.

Workflows are easier to control &

more predictable than schedules.

Decouple workflows;

break dependencies!


l e a n

Iterative Workflow

Concept

Product

or

Business Goals

High Level

Stories

& Tests

Daily

Delivery Discovery

Deployable

Software with

Test Suites

Feedback Ready–Ready

Done–Done

Every 2-4

Weeks

Shortly Before

Implementation


l e a n

Kanban Workflow

Visualize and Manage Workflow Limit Work in Process

Clarify “Done” for each Column Understand Capacity

Discover Dev/Unit Test Deploy orem ipsum dolor sit

amet, co nse ctetur

orem ipsum dolor sit

amet, co nse ctetur


amet, co nse ctetur


amet, co nse ctetur

SIT 5 6 3

FLOW Avg cycle time: days 12


amet, co nse ctetur


amet, co nse ctetur


amet, co nse ctetur

Next 3


amet, co nse ctetur


amet, co nse ctetur

Weekly Dev

Ready

SIT Ready


Ready to Develop:

1. Wireframes

2. Story Tests

3. Less than 3 days work

Ready for system test

1. Story test passed & in

regression harness

2. No false negatives

3. Proper environment

Ready to Design:

1. Vendor time committed

2. ……..

Ready to Deploy:

1. Regression passed

2. ……..


yrig

ht©

200

6

Pop

pen

diec

k.L

LC

Principles of

Lean Software Development

1. Eliminate Waste

2. Build Quality In

3. Learn Constantly

4. Deliver Fast

5. Optimize the Whole

6. Engage Everyone

7. Keep Getting Better

Speed

Quality Low Cost

l e a n software development

www.poppendieck.com Mary Poppendieck [email protected] [email protected]

Thank You!

More Information: www.poppendieck.com

l e a n - ipacop april 12 5 l e a n yrig ht© 200 6 pop pen diec k.l lc lean principle: eliminate...

Documents