Lean SW as thinking tools for Yahoo

8/4/2019 Lean SW as thinking tools for Yahoo

1/74

l e a nsoftware development

Copyright2006 Poppendieck.LLC

Lean Software Development

Leaders Course


2/74

l e a nSeptember 112 Copyright2006 Poppendieck.LLC

Introduction

History

Eliminate Waste

Value Stream Maps

Optimize the Whole

Leadership

Build Quality In

Technical Debt

Defer Commitment

Set-Based Design

Deliver Fast

Queuing Theory

Respect People

Teams

Create Knowledge

Scientific Method

Conclusion

Some Lean concepts


Agenda


3/74


1800Interchangeable

Parts

France, 1785

Honor Blanc demonstrated

interchangeable gun locks.

USA, 1798 Eli Whitney received a contract

to produce 10,000 guns out of

interchangeable parts.

A New Paradigm Craft: Fit parts as close together as possible

Interchangeable Parts: Fit parts as far apart

as possible while maintaining functionality


4/74


1900Interchangeable People

1913Highland Park

50 Languages

350% Turnover

5 minute job training A car a minute

Frederick Winslow Taylor

Ruthless subdivision of labor

Engineers know bestAssumptions:

Workers will do as little as possible

Workers do not care about quality


5/74


The Toyodas

Sakichi Toyoda (1867-1930) Extraordinary inventor

of automated looms

Crucial Idea: Stop-the-Line

Kiichiro Toyoda (1894-1952) Bet the family fortune on

automotive manufacturing

Crucial Idea: Just-in-Time

Eiji Toyoda (1913-Present)

50 years of Toyota leadership

Championed the development of

The Toyota Production System

Sakichi Toyoda(1867-1930)

Kiichiro Toyoda

(1894-1952)

Eiji Toyoda(1913-Present)
http://images.google.com/imgres?imgurl=http://www.ies-geneve.ch/2000gt/Histoire/Kiichiro_Toyoda.jpg&imgrefurl=http://www.ies-geneve.ch/2000gt/Histoire/Toyota1.html&h=600&w=427&sz=46&tbnid=yqU9lhp3PV8J:&tbnh=133&tbnw=94&hl=en&start=7&prev=/images%3Fq%3DKiichiro%2BToyoda%26svnum%3D100%26hl%3Den%26lr%3D%26rls%3DGGLG,GGLG:2005-29,GGLG:en%26sa%3DNhttp://images.google.com/imgres?imgurl=http://www.ies-geneve.ch/2000gt/Histoire/Sakichi_Toyoda.jpg&imgrefurl=http://www.ies-geneve.ch/2000gt/Histoire/Toyota1.html&h=600&w=427&sz=33&tbnid=eSkbkKh-gggJ:&tbnh=133&tbnw=94&hl=en&start=10&prev=/images%3Fq%3DToyoda%2BSakichi%26svnum%3D100%26hl%3Den%26lr%3D%26rls%3DGGLG,GGLG:2005-29,GGLG:en%26sa%3DN


6/74


The Toyota Production

System

Taiichi Ohno(1912-1990)

Taiichi Ohno

The Toyota Production System, 1988 (1978)

Eliminate Waste

Just-in-Time Flow

Expose Problems

Stop-the-Line Culture

Shigeo Shingo

Study Of Toyota Production System, 1981 Non-Stock Production

Single Digit Setup

Zero Inspection

Mistake-Proof Every Step

Shigeo Shingo(1909 1990)
http://www.amazon.com/exec/obidos/ASIN/0915299143/ref=ase_thenorthwestleanhttp://www.amazon.com/exec/obidos/ASIN/0915299178/ref=ase_thenorthwestlean


7/74l e a nSeptember 117 Copyright2006 Poppendieck.LLC

Just-in-Time Flow

Stop trying to maximize

local productivity.

Pillars of Lean


Find and fix problems the

moment they occur.



Just-in-Time Flow

Lists

How long is your defect list?

How far apart are your releases?

How many weeks (years?) of workdo you have in your backlog?

Churn

If you have requirements churn,you are specifying too early.

If you have test-and-fix cycles,

you are testing too late.




Two Kinds of Inspection Inspection to Find Defects is WASTE

Inspection to Prevent Defects is Essential

The Role of Testing

The job of Testing isnot tofinddefects

The job of Testing is topreventdefects.

A quality process builds quality into the code

If you routinely find defects during verification

your process is defective.



Introduction

History

Eliminate Waste

Value Stream Maps

Optimize the Whole

Leadership

Build Quality In

Technical Debt

Defer Commitment

Set-Based Design

Deliver Fast

Queuing Theory

Respect People

Teams

Create Knowledge

Scientific Method

Conclusion

Some Lean concepts


Agenda



Principle 1:

Eliminate Waste

Waste is anything that has been started

but is not being used in production.

Extra features that are notneedednow are waste.

Waste is making the wrong thing

or making the thing wrong.

Price = Cost + Profit

Profit = Price - Cost

Taiichi Ohno



Learn to See Waste

Put on Customer Glasses



The Seven Wastes

The Seven Wastes of Manufacturing- Shigeo Shingo

1. Inventory

2. Overproduction3. Extra Processing

4. Motion

5. Transportation

6. Waiting

7. Defects



The Seven Wastes

1. Partially Done Work

2. Extra Features

The 7 Wastes ofSoftware Development

Every line of code costs money to writeand more money to support. It is betterfor the developers to be surfing thanwriting code that won't be needed. Ifthey write code that ultimately is not

used, I will be paying for that code forthe life of the system, which is typicallylonger than my professional life. If theywent surfing, they would have fun, and Iwould have a less expensive system andfewer headaches to maintain.-- Jeff Sutherland, CTO PatientKeeper


1. Inventory


4. Motion

5. Transportation

6. Waiting

7. Defects



The Seven Wastes

Task ATask B

Task C

Week 1 Week 2 Week 3 Week 4


1. Inventory


4. Motion

5. Transportation

6. Waiting

7. Defects


2. Extra Features3. Relearning

4. Task Switching




The Seven Wastes


2. Extra Features3. Relearning

4. Task Switching

5. Handoffs

6. Delays

7. Defects



1. Inventory


4. Motion

5. Transportation

6. Waiting

7. Defects



Cycle Time

Cycle Time

Average end-to-end process time

From problem detection

To problem solution

Begins and ends with the customer

Software Development Cycle Time

The speed at which a customer need is reliably andrepeatedly translated into deployed software.

Problem Solution

Cycle Time

Customer Request Customer Satisfied



Value Stream Examples

Request Approve-mail tosupervisor E-mail toTech Lead TechnicalAssessment Code & Test ToVerification Verify ToOpertions Deploy

2 hours5 min 2 hours2 min 1 hour15 min 15 min 10 min2 hours 15 min

AssignDeveloper

5 hours 20 min2 hours 40 min

33% Efficiency8 hour cycle time

3 minwastevalue

Of course there is adeveloper available.

Request Approve &PrioritizeForm sentTo Queue Form sentto Queue TechnicalAssessment Code &Test ToVerificationVerify& Fix ToOpertions Deploy

week5 min 2 weeks2 min 2 weeks15 min 1 week week2 hours 15 min

Form sent toQueue

6 weeks + 4 hrs2 hours 40 minminwastevalue 3 hr 45 min5 min20 min total 4 hours total

Bi-weekly releases means a wait ofan average of 1 week for verificationWait an average of 2weeks for developersWait an average of 2weeks for an architectWeekly review of requests meansan average wait of week

Extra 15 minutes tofill out request form Only 15 minutes of 4 hoursshould be needed to verify

1% Efficiency6 weeks + ~1 day

Example 1

Example 2



Value Stream Examples

Example 3

value

23 - 33%Efficiency

1 week 1 day

1 hour

1 week week

2-3 months tomerge

waste

2 weeks working togetherHow much is

Value? 1 hour

123 hours Value

500-660 HoursTotal Cycle Time

1 hour

Require-ments

Develop Test

Require-ments

Develop Test

QAMarketing

requests NewFeature

ApprovalRequire-ments

Develop Test Deploy

Require-ments

Develop Test

Require-ments

Develop Test



Introduction

History

Eliminate Waste

Value Stream Maps

Optimize the Whole

Leadership

Build Quality In

Technical Debt

Defer Commitment

Set-Based Design

Deliver Fast

Queuing Theory

Respect People

Teams

Create Knowledge

Scientific Method

Conclusion

Some Lean concepts


Agenda



Principle 2:

Optimize the Whole

Software is rather useless

all by itself

All software is embedded

In hardware

In a business process

In an activity (game, search)

The goal of software development is to support

the development of a complete product (process)

that helps customers get a job done.



Think Products, not Projects

Projects Up-front funding

Scope fixed at onset

Success = cost/schedule/scope

Team disbands at completion

Documentation tossed

over-the-wall to maintenance

Products Incremental funding

Scope expected to evolve

Success = profit/market share

Team stays with product

Team uses its own

documentation

Start of Project

Completion

Maintenance

ConceptFeasibility

Internal Release

Alpha Release

Beta Release

First Production Release

Major Release

Dot upgrade

Batch Funding

Batch Thinking

System Thinking



Brilliant Products

Embody a Deep Understanding of:

The job that customers

need done

The right technology

to do that job

UnderstandsThe Business

UnderstandsThe Technology

Mind Meld



Product Champion

Behind every great product is a person with: Great empathy for the customer

Insight into what is technically possible

The ability to see what is essential and what is incidental

Example: Chief Engineer at Toyota Responsible for Business Success

Develops Deep Customer Understanding

Develops the Product Concept

Creates The High Level System Design

Sets the Schedule

Understands what customers will value and conveysthis to the engineers making day-to-day tradeoffs

Arbitrates trade-offs when necessary

Defends the Vision



Product Road Map

Release Planning Ballpark estimates

Minimum useful feature sets

Highest priority / greatest risk first

Aug MaySep Oct Nov Dec Jan Feb Mar Apr

11/1

Release 2Feature Set 2

12/15


2 - 1511

1 - 1513

2 - 1515

1 - 151

2 - 159

16 - 3110

16 - 3112

2 - 155

15 - 304

Aug - Aug2

16 - 316

2/1


16 - 3116

2 - 1517

3/15


9/15

Release 1:Feature Set 1

16 - 308

1 - 157

5/1


16 - 2814

Apr - Apr18

2 - 153

8/1

Start



Architecture

The Role of Systems Design (Architecture):

Provide a foundation for growth

Create a common infrastructure

Enable incremental developmentMinimize dependencies

Modularize potential change

Create space for teams to innovate

Design, code and test are different aspects ofthe same job and must be done concurrently

Leave room for the future

Evolve the architecture over time


27/74l e a nSeptember 1127Copyright2006 Poppendieck.LLC

Leadership Roles

(How Many People?)

Process Leader Build Block Disciplines

Iterative Development

Visible Workspace

Project Leader Funding

(Scheduling)

Tracking

Functional Leader Staffing

Teaching

Standards

Marketing Leader Business Responsibility

Customer Understanding

Release Planning

Tradeoffs

Technical Leader System Architecture

At a high level

Work daily with thosedeveloping the details

Technical Guidance Integration

Tradeoffs



Introduction

History

Eliminate Waste

Value Stream Maps

Optimize the Whole

Leadership

Build Quality In

Technical Debt

Defer Commitment

Set-Based Design

Deliver Fast

Queuing Theory

Respect People

Teams

Create Knowledge

Scientific Method

Conclusion

Some Lean concepts


Agenda



Principle 3:

Build Quality In

Synchronization

Configuration Management

One Click Build

Automated Testing Unit Tests

Acceptance Tests

STOPif the tests dont pass

Continuous Integration Nested Synchronization

Frequent Deployment

Automated Release

Automated Install

Simplicity

Common Infrastructure

Architecture

Conventions Tools

Refactoring

Keep Simplifying the

Design of the Code Base

Building Block

Disciplines



Iterative Development

Review

Meeting

features

desirable

list of

Prioritized

Backlog:

Deployment

Stories

Planning

Meeting

Daily

One Iteration

Ahead Every 2-4Weeks

Iteration

Execution

Iteration

Planning

Deployment

- ReadySoftware



Complexity Kills

The Three Faces of Complexity*

1. WasteAnything that depletes resourcesof time, effort, space, or money

without adding customer valueKeep it Simple

2. InconsistencyUneven, unbalanced, or irregular

Make it Flawless3. Overload

Excessive or unreasonable burden

Let it Flow

Cost

Time

*Matthew May, The Elegant Solution



Technical Debt

Anything that makes code difficult to change

ComplexityThe cost of complexity is exponential.

Regression DeficitEvery time you add new featuresthe regression test grows longer!

Unsynchronized Code BranchesThe longer two code branches remainapart, the more difficult merging will be.

You can pay full price for code when youbuild it or you can incur technical debt.

But interests rates are very high.

f



Refactoring: Continuous

Improvement of the Code Base

Do it Right the First Time Destructive interpretation:

Never Change the Code.

Correct interpretation:

Use Test-Driven Development.

Maintain a Simple, Clean Design No features ahead of their time

No features after their time

No Repetition

Start by Adding Automated Tests You cant refactor without them!

Time to Refactor



TheBig Bang is Obsolete

Sources of Risk

Un-coded requirements Un-tested code

Un-integrated code

Code that has not been used in production The Best Risk Mitigation is Synchronization

Early, automated testing

Continuous, nested integration

Synchronization



NestedSynchronization

Every few minutes

Check in code, build and run unit tests

Every day

Run acceptance tests

Every week

Run more complete test suites

Every iteration Deployment-ready code

Every Release

Deploy and run in production



Types of Testing

AcceptanceTests

Business Intent(Design of the Product)

UsabilityTesting

ExploratoryTesting

Unit

TestsDeveloper Intent

(Design of the Code)

Property

TestingResponse,SecurityScaling,

FromBrianMarick

Technology Facing

Business Facing

SupportProgramm

ing

CritiqueProduc

t

Automate

d Manual

Automate

dTool-

Based

L S f D l



Introduction

History

Eliminate Waste

Value Stream Maps

Optimize the Whole

Leadership

Build Quality In

Technical Debt

Defer Commitment

Set-Based Design

Deliver Fast

Queuing Theory

Respect People

Teams

Create Knowledge

Scientific Method

Conclusion

Some Lean concepts


Agenda

P i i l 4



Principle 4:

Defer Commitment

A Pilot from Innsbruck

In Pilot training, we were taught how to make

decisions in challenging situations:

1. First decide when the decision will be made

2. Dont make the decision until that time:

That is when you have the most information

3. Dont make the decision after that time: Or you may end up flying into a mountain.

M th



Myth:

Plan is Commitment

If one sticks to the idea that once set, a plan should not

be changed, a business cannot exist for long.

--- Taiichi Ohno

In preparing for battle I have always found that plansare useless, but planning is indispensable.

--- Dwight D. Eisenhower

If plans are commitments, then you committo operate on guesses rather than data.

Measuring conformance to plan

is measuring the wrong thing.

Ch T l t



Change Tolerant

Software

60-80% of all software is developed

after first release to production.

A development process that anticipates changewill result in software that tolerates change.

Make decisionsreversible whenever possible.

Make irreversible decisions as late as possible.

When do you really need the user interface designed?



Set-Based Design

Point Based Design

Set up a meeting using thepoint-based model.

Set Based Design

Now set up the meeting bycommunicating about sets.

A: Uh, already booked.

Can you meet at 3:00?

A: I can meet10:00 - 1:00 or3:00 - 5:00.Can you makeany of thesetimes?

B: Lets

meet 12:00 -1:00.

based on dissertation by Durward K. Sobek, II, 1997

A: My best timeis 10:00. Canyou make it?

B: No, I cant.

How about2:00?

B: No, 3:00is bad.9:00?

?

You already understand this!



Set-Based Engineering

Irreversible decisions are

scheduled to be made at the

last responsible moment. Multiple options are prepared

for the decision.

There is always an optionthat will work.

Paradox: This isnot waste!

TechnicalCapabilitiesBusiness Logic

Approaches

GUI Alternatives

Accept

able

Analyze &

Critique

Modify

Architect

Developers

Testers

UI

DesignersProduct Manager

Design

Solution

Point-Based

Set-Based

L S ft D l t



Introduction

History

Eliminate Waste

Value Stream Maps Optimize the Whole

Leadership

Build Quality In

Technical Debt

Defer Commitment

Set-Based Design

Deliver Fast

Queuing Theory

Respect People

Teams Create Knowledge

Scientific Method

Conclusion

Some Lean concepts


Agenda

P i i l 5



Principle 5:

Deliver Fast

Competing on the basis of time provides Significant competitive advantage

Large barrier to entry

Order Processing

Product Development

ShippingManufacturing

Supply ChainSoftware Development
http://www.patientkeeper.com/index.htmlhttp://images.google.com/imgres?imgurl=http://elearning.hbsp.org/demos/cases/zara/images/logo.gif&imgrefurl=http://elearning.hbsp.org/demos/cases/zara.html&h=194&w=184&sz=5&tbnid=CKARUnJLXg4J:&tbnh=98&tbnw=92&hl=en&start=1&prev=/images%3Fq%3Dzara%2Blogo%26svnum%3D100%26hl%3Den%26lr%3D%26rls%3DGGLG,GGLG:2005-29,GGLG:en%26sa%3DN



Myth: Haste Makes Waste

Companies that compete on the basis of speed:

Enjoy a significant cost advantage relative to peers

A 25-30% cost advantage is typical.

Dell claims a 50% cost advantage.

Have extremely low defect rates

It is impossible to go fast without superb quality.

Acquire a deep customer understanding Fast companies can take an experimental approach to

product development.

Have a sustainable competitive advantage.



Littles Law

Total Cycle Time =Number of Things in Process

Average Completion Rate



Pull Scheduling Example

Manage the Queues Pull from Queues to limit work to capacity

Keep Queues small to decrease cycle time

.

.

.

Queue

Best 6

ConceptRoughCost /Benefit

Approve /Reject

ArchitectureReview /

Design / Cost

Develop /Test /

DocumentDeploy

Queue

Best 3

QMax 2

Iterations

Approve /Reject

Pull

Pull

Pull

Repeat

Implem

entation

Backl

og

Desira

ble

Cap

abilitie

s

GoodROI



The Utilization Paradox

Queuing Theory 101

Cycle Time as a Function of Utilization and Batch Size*

0

5

10

15

20

25

30

35

40

45

10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

CycleTime(hou

rs)

Small Batches

Medium Batches

Large Batches

*This assumes batch size is proportional to variability.

Reducing Software



Reducing Software

Development Cycle Time

1. Even out the Arrival of Work

2. Minimize the Number

of Things In Process3. Minimize the Size

of Things In Process

4. Establish a Regular Cadence5. Limit Work to Capacity

6. Use Pull Scheduling

Queuing Theory




Introduction

History

Eliminate Waste


Leadership

Build Quality In

Technical Debt

Defer Commitment

Set-Based Design

Deliver Fast

Queuing Theory

Respect People


Scientific Method

Conclusion

Some Lean concepts


Agenda



1900Industrial Training

Charles R. AllenNew Bedford, Massachusetts

Four Step method of Industrial Training

Preparation, Presentation, Application, and Testing

On-the job training is best

Supervisors know how to do the job

Supervisors need training in how to train

1917War Ships were needed

Allen developed programs for shipbuilding

88,000 people were trained in 2 years

Wrote the bookThe Instructor, the Man and the Job

If the learner hasnt learned, the teacher hasnt taught.



1940Training Within Industry

Wartime Production

Inexperienced Workforce

Used Allens Approach

Training for first line supervisors

Job Instructionhow to train workers

Job Methodshow to improve the way work is done

Job Relationshow to treat workers with respect

Program canceled after the war

Taught in Europe and Japan

Well received, especially in Japan

Modified and still used today in Toyota

1980 Dr W Edwards Deming



1980Dr. W. Edwards Deming

System of Profound Knowledge

Appreciation for the system A systems view was fundamental; never sub-optimize.

Manage the relationship between suppliers, producers, and customers

Knowledge of Variation Most variation is common cause variation inherent in the system.

Trying to eliminate this variation only makes things worse. Systemic problems lie beyond the power of the individual worker.

Deadlines and slogans do nothing to address systemic problems.

Provide leadership in changing the way the system works.

Theory of Knowledge

Use the Scientific Method to improve systems Hypothesis, Experiment, Learn, Incorporate Learning (PDCA)

Psychology When it comes to people, the things that make a difference

are skill, pride, expertise, confidence, and cooperation.



Engaged People

Move responsibility and decision-makingto the lowest possible level

Supervisors / Team Leaders should Know how to do the job they supervise

Receive training on how to Train workers

Improve process

Respect people

People Thrive on Pride

Commitment

Trust

Applause

Global Team



Global Team

Models

1. Small team has memberslocated around the world;they coordinate with eachother daily.

2. Small co-located teamsworking on relativelyindependent subsets of adivisible architecture.

3. A representative on coreteam communicates dailywith and coordinates thework of a remote team.



Reliable Commitment

Reliable delivery of working code with each iteration Small Story Size

Stable Team

Complete Team

No Partial Credit

An intact team working in aknown domain establishes a

Reliable Velocity

Story points per iteration

This establishes thecapacity of the team

And (across intact teams) the capacity of the organization



Make Work Self-Directing

Dispatched

Self-Directing

Dispatched

Self-Directing

Story YY

Login New User

Get Password

Afal;jdsa;fuwe

Story XX

Login New UserAfal;jdsa;fuwe

Story XX

Login New User

Afal;jdsa;fuwe

Story XX

Login New User

Afal;jdsa;fuweStory XX

Login New User

Afal;jdsa;fuwe

Story XX

Login New User

Afal;jdsa;fuwe

Story YY

Login New User

Get Password

Afal;jdsa;fuwe

Story YYLogin New User

Get Password

Afal;jdsa;fuwe

Story YY

Login New User

Get Password

Afal;jdsa;fuwe

Story YY

Login New User

Get Password

Afal;jdsa;fuwe

Story YYLogin New User

Get Password

Afal;jdsa;fuwe

Story XX

Login New User

Afal;jdsa;fuwe

TestsPassedChecked Out

To Do




Introduction

History

Eliminate Waste


Leadership

Build Quality In

Technical Debt

Defer Commitment

Set-Based Design

Deliver Fast

Queuing Theory

Respect People


Scientific Method

Conclusion

Some Lean concepts


Agenda

Principle 7:



Principle 7:

Create Knowledge

The Learning Organization

Everybodys job is to taketheir work to the next level.

Everyone challenges thingsthat annoy them or keep themfrom doing an excellent job.

Teams improve their ownprocesses

Without permission from managers

Or direction from process experts

Not ConsistentModify Hypothesis

ConsistentPublish Results

Observations

Knowledge

Results

Predic-tionsExperiments

Hypothesis

The Scientific Method



Standards

The current best known

way to do a job

The baseline for change

If you believe that standards are written in

stone, you will fail. You have to believe that

standards are there to be changed.** Yoshio Shima, Director, Toyoda Machine Works



Dont Tolerate Work-Arounds

Detect every inconsistency the moment it happens.

Dont fight fires! Stop

Find the root cause. Investigate

Find a better way. Experiment

Change the standard. Learn

Only after American carmakers had exhausted every other explanation for

Toyotas success an undervalued yen, a docile workforce, Japanese culture,

superior automationwere they finally able to admit that Toyotas real advantage

was its ability to harness the intellect of ordinary employees.

Management Innovation by Gary Hamel,

Harvard Business Review, February, 2006



After Action Review

After key events Iteration, Release, etc.

Everyone participates

No fault-finding or blaming

Answer three questions:1. What was supposed to happen?

2. What actually happened?

3. Why were there differences?

Capture the learning Decide what to do with it

(Often called a Retrospective in Software Development)



Capturing Knowledge

Ground Rules

Everything fits on one side of an A3 sheet.

If it doesnt fit, condense it to smaller sheet!

Use as few words as possible. A picture is worth a thousand words.

A3s are dynamic documents.

Obtain feedback and update.

The A3 Report Two sheets of letter paper

A3 reports are concise, useful summaries of knowledge.

They condense findings and capture important results.



Capture in an A3 Document

Coding Standards

Logging Approach

Security Standards

Configuration Management Practices

Problem Under Investigation

High Level Architecture Business Goals of System Under Development

Iteration Goal / Release Goal




Deliver Fast

Queuing Theory

Respect People


Scientific Method

Conclusion

Some Lean concepts

Introduction

History

Eliminate Waste


Leadership

Build Quality In

Technical Debt

Defer Commitment

Set-Based Design


Agenda

Lean Thinking is



Lean Thinking is

Counterintuitive

Balance Sheet Thinking Delay creates quality

Just-in-case is wise

Work-in-process has value

Queues support betterdecisions

Cash Flow Thinking Delay creates waste

Just-in-time is wiser

Work-in-process is waste

Queues gum up the worksand slow things down

In order for organizations to perform

brilliantly, there are two prerequisites:

First, everyone has to agree on what

they want, and second everyone has to

agree on cause and effect.* *The Tools of Cooperation and Change,by Clayton Christensen and co authors,

Harvard Business Review, October 2006.

A b l



Accountability

Span of InfluenceHold people accountable for

what they can influence

Measure at the team level

Fosters collaboration Example

The team includes technical and

business people, and the whole

team assumes responsibility for

business success

Span of ControlHold people accountable for

what they cancontrol

Measure at the individual level

Fosters competition Example

The development team should be

responsible fortechnical success

The product manager should be

responsible forbusiness success

There is no such thing

as Technical SuccessKent Beck, XP 2004

U ili i



Utilization

We need full utilization

of expensive resources.

It is impossible to have

intact teams because this

decreases utilization.

Large queues of work help

keep everyone busy.

It is impossible to move

rapidly without slack.

Intact teams increase

overall productivity by

preserving team learning.

Batch and queue mentality

is the biggest detriment to

system-wide performance.

W k S d d



Work Standards

The purpose of standards

is to make it possible for

any one to do any job.

Standards are initiated byprocess groups.

Written standards are to be

followed, not changed.

The purpose of standards

is to provide a baseline

for the team to change.

If you believe that stan-dards are written in stone,

you will fail. You have to

believe that standards are

there to be changed.*

* Yoshio Shima, Director, Toyoda Machine Works

C f Pl



Conformance to Plan

Planning is indispensable,

but plans are useless.

The most predictable

performance comes from

maintaining options until

we have the most

information.

A Plan is a Commitment

Predictability comes from

conformance to plan.

The plan is always right,

even though it was made

when we had the least

information.

* Dwight Eisenhower

*

M UP



Measure UP

Decomposition You get what you measure

You cant measure everything

Stuff falls between the cracks

You add more measurements

You get local sub-optimization

Example Measure Cost, Schedule, & Scope

Quality & Customer Satisfactionfall between the cracks

Measure these too!

Aggregation You get what you measure

You cant measure everything

Stuff falls between the cracks

You measure UP one level

You get global optimization

Example Measure Cost, Schedule, & Scope

Quality & Customer Satisfactionfall between the cracks

Measure Business CaseRealization instead!

From to ! From to !

Th S M



Three System Measurements

1. Average Cycle Time From Product Concept

To First Releaseor

From Feature Request

To Feature Deploymentor

From Defect

To Patch

2. The Business Case P&L or

ROI or

Goal of Investment

3. Customer Satisfaction Net Promoter Score

(Fred Reichheld, The Ultimate Question)

Would you recommend ourproduct/service to a colleague?

Rate on a scale of 0-10

Promoters = 9-10

Detractors = 0-6

Net Promoter Score =

%Promoters%Detractors

Highly correlated tomarket share and

long term growth


73/74

l e a nsoftware development

Copyright2006 Poppendieck.LLC

Thank You!

A Sh Li f B k


74/74

A Short List of Books

1. Taiichi OhnoToyota Production System

2. Mary & Tom PoppendieckLean Software Development

3. Michael KennedyProduct Development in the Lean Enterprise

4. Mike CohnAgile Estimating and Planning

5. Michael FeathersWorking Effectively with Legacy Code

6. Mugridge & CunninghamFit for Developing Software

7. PoppendieckImplementing Lean Software Development

8. Matthew May - The Elegant Solution
http://www.amazon.com/exec/obidos/ASIN/0915299143/ref=ase_thenorthwestlean

Documents

Lean SW as thinking tools for Yahoo