l e a n - LASER Foundation

1

l e a nsoftware development

www.poppendieck.comMary [email protected]

Lean Software DevelopmentSpeed – Quality – Low Cost

August 062 Copyright©2006 Poppendieck.LLC

SundayOverview

HistoryPrinciples

Core IdeasValueWaste

Lean Software Development Agenda

MondayProcess

QualityKnowledge

PeopleLeadershipTeams Visible Workspace

TuesdaySpeed

The Synergy of Speed, Quality, & Low CostQueuing Theory

SystemMeasurementThe Journey

2


The Toyota Production System

Taiichi Ohno (1912-1990)

Taiichi OhnoThe Toyota Production System, 1988 (1978)

Eliminate WasteJust-in-Time Flow

Expose Problems Stop-the-Line Culture

Shigeo ShingoStudy Of ‘Toyota’ Production System, 1981

Non-Stock ProductionSingle Digit Setup

Zero InspectionMistake-Proof Every Step

Shigeo Shingo (1909 – 1990)


Don’t Batch & Queue

ListsListsHow long is your defect list?How far apart are your releases?

ChurnChurnIf you have requirements churn, you are specifying too early.If you have test-and-fix cycles, you are testing too late.

3


Don’t Tolerate Defects

Two Kinds of Inspection (Shingo)Inspection to Find Defects

Waste!

Inspection to Prevent DefectsEssential.

Mistake-Proof Every StepDetect defects the moment they occur

Don’t track defects on a listFind them and fix them


Respect People

“Only after American carmakers had exhausted every other explanation for Toyota’s success –an undervalued yen, a docile workforce, Japanese culture, superior automation –were they finally able to admit that Toyota’s real advantage was its ability to harness the intellect of ‘ordinary’ employees.”

“Management Innovation” by Gary Hamel, Harvard Business Review, February, 2006

4


Principles of Lean Software Development

1. Eliminate Waste2. Build Quality In3. Create Knowledge4. Defer Commitment5. Deliver Fast6. Respect People7. Optimize the Whole

Speed

Quality Low Cost


Principle 1: Eliminate Waste

Waste is anything that has been startedbut is not being used in production.

Extra features that are not needed now are waste.Waste is making the wrong thingor making the thing wrong.

Price = Cost + ProfitProfit = Price - Cost

Taiichi Ohno

5


Myth 1: Early Specification Reduces Waste

Features and Functions Used in a Typical System

Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

Always7%

Often13%

Sometimes16% Rarely

19%

Never45%

Rarely or NeverUsed: 64%

Often or AlwaysOften or AlwaysUsed: 20%Used: 20%


The Big BangBig Bang is ObsoleteNo Partial Credit

Sources of RiskUn-coded requirementsUn-tested codeUn-integrated codeCode that has not been used in production

The Best Risk Mitigation is SynchronizationEarly, automated testingContinuous, nested integration

Principle 2:Build Quality In

6


Myth 2: The Job of Testing is to Find Defects

The job of testing is to prevent defectsIf you are focused on finding defects

– you are not doing your job.

A quality process builds quality into the codeIf you routinely find defects during verification

– your process is defective.

Defects are not caused by developersDefects are caused by a system which allows defects.

– Defects are a management problem.


Principle 3: Create Knowledge

One Year Later….

Poor productivityPoor market acceptancePoor expert quality rating

Great market success

Alan MacCormackHarvard Business School

A Tale of Two Projects

Not ConsistentModify Hypothesis

ConsistentPublish Results

New Knowledge

Obser-vations

Predic-tionsTests

Hypothesis

7


Myth 3: Predictions Creates Predictability

The Predictability ParadoxDecreasing the amount of guessing involved in making decisions increases the predictability of the outcomes.

The longer we wait, the more we know and the less we guess.

The most predictable organizations reduce response time so they can respond to events as they unfold.

Minnesota Wedding August 10th

50% Chance of Rain65-95 ºF

Invitations must be sent in June


Principle 4: Defer Commitment

A Pilot from InnsbruckIn Pilot training, we were taught how to make decisions in challenging situations:

1. First decide when the decision will be made2. Don’t make the decision until that time:

That is when you have the most information

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

8


Myth 4: Planning is Commitment

If one sticks to the idea that once set, a plan should not be changed, a business cannot exist for long.

--- Taiichi OhnoIn preparing for battle I have always found that plans are useless, but planning is indispensable.

--- Dwight D. Eisenhower

If plans are commitments, then you commit to operate on guesses rather than data. Measuring conformance to plan is measuring the wrong thing.


Principle 5: Deliver Fast

Competing on the basis of time providesSignificant competitive advantageLarge barrier to entry

Order Processing

Product Development

ShippingManufacturing

Supply Chain Software Development

9


Myth 5: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 ratesIt is impossible to go fast without superb quality.

Acquire a deep customer understandingFast companies can take an experimental approach to product development.

Have a sustainable competitive advantage.


Principle 6: Respect People

Crisis at our Video Cassette PlantCompetition selling cassettes for less than we could make them

Our ResponseJust-in-Time (Lean) Production

The Great Coffee Cup SimulationPlant Manager, Materials Control Manager, IT Manager (me)Add Production General Managers Add General SupervisorsAdd Shift SupervisorsAdd Shift Workers

The Result Entire plant switched to pull scheduling over one weekendPack-out went from 60% to 95% the first weekEmployees said this was the best thing that happened to the plant

10


Myth 6: There is One Best Way

Frederick Winslow TaylorGrandfather of the Process Police

Standardized WorkImposed ProcessesInterchangeable People

Scientific ManagementAffronts human dignity and discourages worker creativity

Toyota Production SystemBetter Thinking; Better Products

Standardized WorkBest Current PracticeConstantly Challenged

Scientific MethodWork teams design experimentsand implement their own ideas


Principle 7: Optimize the Whole

Vicious Cycle #2:Vicious Cycle #2:1. Testing is overloaded with work2. Result: Testing occurs long after coding3. Result: Developers don’t get immediate feedback4. Result: Developers create more defects5. Result: Testing has more work. Systems have more defects.6. Result: Feedback to developers if delayed further. Repeat cycle.

Vicious Cycle #1:Vicious Cycle #1:1. A customer wants some new features yesterday2. Developers hear: Get it done fast, at all costs!3. Result: Sloppy changes are made to the code base4. Result: Complexity of code base increases5. Result: Number of defects in code base increases6. Result: Exponential increase in time to add features

11


Myth 7: Optimize Through Decomposition

DecompositionYou get what you measureYou can’t measure everythingStuff falls between the cracksYou add more measurementsYou get local sub-optimization

ExampleMeasure Cost, Schedule, & Scope

Quality & Customer Satisfaction fall between the cracksMeasure these too!

AggregationYou get what you measureYou can’t measure everythingStuff falls between the cracksYou measure UP one levelYou get global optimization

ExampleMeasure Cost, Schedule, & Scope

Quality & Customer Satisfaction fall between the cracksMeasure Business Case Realization instead!

From to ! From to !


SundayOverview

HistoryPrinciples



MondayProcess

QualityKnowledge


TuesdaySpeed



12


Software Plays a Supporting Role

Software is rather uselessall by itself

All software is embedded In hardwareIn a business processIn an activity (game, search)

The goal of software development is to support The goal of software development is to support the development of a complete product (process) the development of a complete product (process) that helps customers get a job done.that helps customers get a job done.

software

inside


Better Thinking → Better Products

Complete SolutionsSolve my problem completely.Don’t waste my time.Provide exactly what I want.Deliver value exactly where I want it.Supply value exactly when I want it.Reduce the number of decisions I must make to solve my problems.

Whole Team Complete solutions are developed by complete teams

Customers (or Proxy)ChampionProduct ManagerProduct Designers

From Lean Solutions, Womack & Jones, 2005

EngineersDevelopersTestersDBA’s

Technical WritersCustomer SupportOperationsMaintenance

13


Eliminate Waste

Put on Customer Glasses


The Seven WastesThe Seven Wastes of Manufacturing The Seven Wastes of Manufacturing

-- Shigeo ShingoShigeo Shingo

1. Inventory 2. Overproduction3. Extra Processing4. Motion5. Transportation6. Waiting7. Defects

14


The Seven Wastes

1. Partially Done Work2. Extra Features

The 7 Wastes of The 7 Wastes of Software DevelopmentSoftware Development

“Every line of code costs money to write and more money to support. It is better for the developers to be surfing than writing code that won't be needed. If they write code that ultimately is not used, I will be paying for that code for the life of the system, which is typically longer than my professional life. If they went surfing, they would have fun, and I would have a less expensive system and fewer headaches to maintain.”-- Jeff Sutherland, CTO PatientKeeper

The Seven Wastes of Manufacturing The Seven Wastes of Manufacturing -- Shigeo ShingoShigeo Shingo



The Seven WastesThe Seven Wastes of Manufacturing The Seven Wastes of Manufacturing

-- Shigeo ShingoShigeo Shingo


1. Partially Done Work2. Extra Features3. Relearning4. Task Switching


15


The Seven Wastes

1. Partially Done Work2. Extra Features3. Relearning4. Task Switching5. Handoffs6. Delays7. Defects


The Seven Wastes of Manufacturing The Seven Wastes of Manufacturing -- Shigeo ShingoShigeo Shingo



The Value Stream

Cycle TimeAverage end-to-end process time

From problem detectionTo problem solution

Begins and ends with the customerBegins and ends with the customerSoftware Development Cycle Time

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

Problem Solution

Cycle Time

Customer Request Customer Satisfied

16


Value Stream Examples

Example 1

Example 2


Value Stream Examples

Example 3

17


Value Stream ExamplesExample 4

Question: What is really value added? What is the % efficiency?


Value Stream Maps

1. Select a process for creating a Value Stream Map. Decide when the clock starts (eg. customer has a need) and when it stops (need is filled).

2. Current Value Stream MapList / diagram the key stepsList the average time of each step

Does the step add value full time?Is the step ever repeated?

List the average time between steps

3. Calculate Process Cycle Efficiency*

Add up time of each step plus time between steps = Total Cycle TimeAdd up Value Added Time in each step

4. Discuss.

Value Added Time

Total Cycle Time

* See Michael George: Conquering Complexity in Your Business

18


SundayOverview

HistoryPrinciples



MondayProcess

QualityKnowledge


TuesdaySpeed




Build Quality In

1. Organized Workspace5 S’s

2. Standardized InfrastructureArchitectureConventionsTools

Standards Exist to be Changed!

3. Test-Driven DevelopmentAcceptance (Story) TestsUnit Tests

4. Frequent DeploymentSmall Batches

5. SynchronizationConfiguration ManagementOne Click BuildContinuous IntegrationAutomated test harnessesSTOPSTOP if the tests don’t passNested SynchronizationAutomated DeploymentAutomated Installation

6. Continuous ImprovementChallenge the standardsImprove the processRefactor the code base

Building Block DisciplinesBuilding Block Disciplines

19


Organized WorkspaceThe Five S’s

Sort (Seiri) Get rid of everything that is not needed.

Systematize (Seiton) Have a place for everything and put everything in its place.

Shine (Seiso) Clean up – both physical and digital workspaces.

Standardize (Seiketsu) Create standards to keep things organized.

Sustain (Shitsuke)Make it a habit.


Types of Testing

Acceptance Acceptance TestsTests

Business Intent(Design of the Product)

UsabilityUsabilityTesting Testing

ExploratoryExploratoryTestingTesting

Unit Unit TestsTests

Developer Intent(Design of the Code)

PropertyPropertyTestingTestingResponse,SecurityScaling,…

From

Bri

an M

aric

k

Technology Facing

Business Facing

Supp

ort P

rogr

amm

ing

Cri

tique

Pro

duct

Automated Manual

Automated Tool-Based

20


Test Driven Development

Doesn’t cost, it pays!Is a design technique

Cleaner DesignStory Test Driven Design

Matches the design to the structure of the domain

Unit Test Driven DesignSimpler, More Understandable Code

Self-verifyingProtects from unintended consequences

For the life of the code


Nested Synchronization

Synchronized: Integrated, tested, ready to release.STOPSTOP if the tests don’t pass

Every few minutesCheck in code, build and run unit tests

Every dayRun acceptance tests

Every weekRun more complete test suites

Every iterationDeployment-ready code

Every ReleaseDeploy and run in production

21


The Scientific Method

1. Observe phenomenon.2. Formulate a hypothesis to

explain the phenomenon.3. Use the hypothesis to make

a prediction – the existence of other phenomenon or the results of new observations.

4. Perform experiments to see if prediction holds up.

5. If so, the hypothesis may be regarded as a theory.

6. If not, the hypothesis must be rejected or modified.

Not ConsistentModify Hypothesis

ConsistentPublish Results

New Knowledge

Obser-vations

Predic-tionsTests

Hypothesis


1. Frame the problem2. Look for the root cause3. Propose a countermeasure4. Specify expected results5. Perform many rapid experiments6. Capture results in an A3 report7. Implement the best countermeasure8. Verify results9. Change the standard

Using the Scientific Method to Solve Problems

22


The A3 Report

Ground RulesEverything fits on one side of an A3 sheet (two 8.5x11’s). If it doesn’t fit, condense it to an A4 sheet (one 8.5x11)!Use as few words as possible. Use pictures & graphs instead. A3’s are dynamic documents. Obtain feedback & update.

A Problem Solving A3:Summary of the ProblemRoot Cause AnalysisSuggested CountermeasurePlanned ExperimentsMeasurements and Feedback

A Minimum Useful Feature Set A3:Description of customer jobEconomic valueWhat customers will be able to doDiagram of what is and is not includedSystem interaction diagram.Desired timeline

A Knowledge Sharing A3:Identification of specific problem (example: database lockup)List of suspected triggersScatter plot showing instances plotted against suspected triggersTradeoff curve of nested calls plotted against time-spent-in-nest, with a line showing where lockups do/don’t occurDiscussion of additional suspected causes of the problem


Iterative Development

Review Meeting

featuresdesirable

list ofPrioritized

Backlog:

Deployment

Stories

Planning Meeting

Daily

One Iteration Ahead Every 2-4

Weeks

Iteration Execution

Iteration Planning

Deployment- Ready

Software

23


Change Tolerant Software

60-80% of all software is developed after first release to production.

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

Make decisions reversible reversible whenever possible.

Make irreversibleirreversible decisions as late as possible. When do you really need the user interface designed?


Set-Based Design

Point Based DesignSet up a meeting using the point-based model.

Set Based DesignNow set up the meeting by communicating about sets.

A: Uh, already booked. Can you meet at 3:00?

A: I can meet 10:00 - 1:00 or 3:00 - 5:00. Can you make

any of these times?

B: Let’s meet 12:00 -1:00.

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

A: My best time is 10:00. Can you make it?

B: No, I can’t. How about 2:00?

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

?

You already understand this!

24


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 option that will work.The Paradox: This is not waste!

Set-Based

Engineering Resp

onsib

ility

Base

d Con

trol

Design

Leaders

hipExpert

Workforce

Technical CapabilitiesBusiness Logic

Approaches

GUI Alternatives

Acceptable

Analyze & Critique

Modify

ArchitectArchitect

DevelopersDevelopers

TestersTesters

UI UI DesignersDesigners

Product ManagerProduct Manager

DesignSolution

PointPoint--Based Based

SetSet--Based Based


SundayOverview

HistoryPrinciples



MondayProcess

QualityKnowledge


TuesdaySpeed



25


Brilliant Products

Embody a Deep Understanding of:The job that customersneed done

The right technologyto 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 possibleThe ability to see what is essential and what is incidental

Skills:Possesses a deep understanding of the customer and the development teams’ capabilities. Operates from a strong basis of knowledge and confidence. Focuses on delivering superior value to the marketplace.

Martin Cagan, Silicon Valley Product Group; see www.svproduct.com

26


Leadership Roles(How Many People?)

Process LeaderProcess LeaderBuild Block DisciplinesIterative DevelopmentVisible Workspace

Project LeaderProject LeaderFunding(Scheduling)Tracking

Functional LeaderFunctional LeaderStaffingTeachingStandards

Marketing LeaderMarketing LeaderBusiness ResponsibilityCustomer UnderstandingRelease Planning

Technical LeaderTechnical LeaderSystem Architecture

At a high levelWork daily with those developing the details

Technical GuidanceIntegrationTradeoffs


What is a Team?

A team is a group of people who have committed to each other to work together to achieve a common purpose.

A group of people who sum up their individual efforts to meet a goal may be a work group, but they aren’t a team.

27


Case Study: Boeing 777 Working Together

1990 – 1995 Aggressive Deadline – Bet-the-company programThe first Boeing airline with computer controlsAlan Mulally – Chief Engineer

200+ Design-Build TeamsShare Early, Share Often

A schedule of tests to passExpose Conflicts, Fail Fast

Delight CustomersAirlines and Passengers 21st Century Jet: The Building of the 777

1995 Documentary for KCTS/Seattle


Expert Workforce

TPS – Thinking People SystemTraining, management, processes, and IT are designed to support the decisions of workers, not to make decisions for workers.Workers design and improve their own processesFunctional managers act as teachersCompensation system does not force good engineers to move into management80% of an engineer’s time is spent “doing engineering” Set-Based

Engineering Resp

onsib

ility

Base

d Con

trol

Design

Leaders

hipExpert

Workforce

28


Responsibility-Based Planning & Control

Chief Engineer publishes scheduleEngineers decide how to meet the schedule

Are responsible to make dependent tasks happen‘Pull’ knowledge as needed

The schedule is ALWAYS met

Consider Your Daily NewspaperComes together every night no matter whatPage Editors decide how to meet the schedule

Are responsible to fill their pages‘Pull’ stories as needed

Set-Based

Engineering Resp

onsib

ility

Base

d Con

trol

Design

Leaders

hipExpert

Workforce


Make Work Self-Directing

Dispatched

Self-Directing

Dispatched

Self-DirectingStory YY

Login New UserGet PasswordAfal;jdsa;fuwe

Story XXLogin New UserAfal;jdsa;fuwe


Story XXLogin New UserAfal;jdsa;fuwe Story XX

Login New UserAfal;jdsa;fuwe


Story YYLogin New UserGet PasswordAfal;jdsa;fuwe






Tests PassedChecked Out To Do

29


Small team Clear missionShort timeframeNecessary skillsBasic disciplinesProper leadershipResponsibilityRespect

Commitment of all members to team goal

Self-Directing Teams


The Visual Workplace

Kanban What to do next?

Status LightsStop the Line!

Big Visible ChartsHow are we doing?




Story XXLogin New UserAfal;jdsa;fuwe Story XX

Login New UserAfal;jdsa;fuwe








Tests PassedChecked Out To Do

Time to Complete (in staff-days)

0

100

200

300

400

500

600

700

jan feb mar apr may jun jul aug sep oct nov dec

30


SundayOverview

HistoryPrinciples



MondayProcess

QualityKnowledge


TuesdaySpeed




Stamping Dies

JapanMistakes very expensiveNever-ending changesFocus: Reduce TimeEarly Design – Early CutDesigner makes changes

Faster, Better, Cheaper

USMistakes very expensiveNever-ending changesFocus: Reduce WasteWait to Design – Wait to CutSlow change approval system

Twice the time, twice the cost

31


Slow Processes are Expensive

Slow processes Are error proneAre less productiveCan’t adapt to change

In slow processes:Most of the time is spent waitingMost steps do not add customer valueMost of the effort goes to managing complexity


Time: The Universal Currency

Process problems add time delaysDefectsComplexityLow ProductivityChange IntoleranceBuilding the Wrong ThingToo many Things-in-Process

Focusing on time Pinpoints non-value-adding activitiesExposes development problems earlier

32


Case Study - PatientKeeperSpeed to market

45 cycles while competition does oneMaintenance releases once or twice a weekNew feature releases every monthNew applications released every quarter

Predictable DeliveryNever a late releaseProblems are seen long before the release dateThe company self-organizes around the problems

Pull from DemandPriorities reorganized on a weekly basis by CEO, sales, and account managementCustomer impact and schedule impacts are dealt with at the time of the decision

No Abnormalities because rapid cycle time:Eliminates buggy software because you die if you don't fix this Fixes the install process because you have to install 45 releases a yearImproves the upgrade process because of a constant flow of mandatory upgrades It forces standardization of software via new features rather than customization

Jeff SutherlandCTO PatientKeeper


Cycle Time

Cycle TimeAverage end-to-end process time

From problem detectionTo problem solution

Begins and ends with the customerBegins and ends with the customerSoftware Development Cycle Time

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

Problem Solution

Cycle Time

Customer Request Customer Satisfied

33


Little’s Law

Total Cycle Time =Number of Things in Process

Average Completion Rate


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%

Cyc

le T

ime

(hou

rs)

Small Batches Medium BatchesLarge Batches

*This assumes batch size is proportional to variability.

34


Reducing Software Development Cycle Time

1. Even out the Arrival of Work2. Minimize the Number

of Things In Process3. Minimize the Size

of Things In Process4. Establish a Regular Cadence5. Limit Work to Capacity6. Use Pull Scheduling

Queuing Theory


Case Study:Use Pull Scheduling

Large Financial InstitutionFull day every 2 weeks ‘discussing’priorities

Recommendation:

Manage the QueuesPull from Queues to limit work to capacityKeep Queues small to decrease cycle time

.

.

.

Pull

Pull

Pull

Impl

emen

tatio

n Ba

cklo

g

Desir

able

Capa

bilitie

s

Good

RO

I

35


Release Planning

Timebox CapabilitiesNever miss a deadlineDevelop highest priority firstAdjust scope at the beginning of every iteration


SundayOverview

HistoryPrinciples



MondayProcess

QualityKnowledge


TuesdaySpeed



36


Case Study: Dysfunctional Measurements

Case 1: Fujitsu took over help desk of BMI (airline) in 2001Analyzed calls

Found the problems behind the callsTracked the time to fix the problemsMeasured impact on business of the problem

26% of calls were for printersCould not print boarding passes / luggage tags

Fujitsu convinced management to get better printersPrinter calls were down 80% in 18 monthsTotal calls were down 40% in 18 monthsMajor savings in flight operations

What’s Wrong With This Picture?Most call centers are paid for each call handledFujitsu is paid for each potential caller

From “Lean Consumption”By James P. Womack & Daniel T. JonesHarvard Business Review, March 2005


A Financial Model

Software by Number by Mark Denne and Jane Cleland-HuangSelf-Funding

Breakeven

Inve

stm

ent

Payb

ack

Pro

fit

Time

Cos

t

37


Staged Releases

Time

Cos

tRelease 1 ProfitRelease 2 Profit

Total Profit


Increased Profit

Time

Cos

t

Profit

Investment

Bre

akev

en

Single Release

Self-

Fund

ing

Bre

akev

en

Software by Number by Mark Denne and Jane Cleland-Huang

StagedReleases

38


Case StudyThe Business Case

Used car holding companyNeeded re-write of used car management software

Consultants proposed ScrumSaid that customer could end contract at end of any month if the weren’t satisfiedConsulting firm management was not pleased

Consultants looked for ways to delight customerDiscovered that reducing car holding time was worth many £’sFocused development on this goal

Result: Very happy customer More work for consulting firmConsulting firm management very pleased


Every product development team has an accountantFull team develops P&L as part of its daily work

Team trade-off decisions are based on P&L impact

P&L drives management approval decisions at gatesAre the margins adequateAre they believable?Has the team done its homework?

P&L’s are usually used for investment decisionsThe best use may be as a financial model for development teams to make trade-off decisions

Case Study3M Product Development

39


2.2. The Business CaseThe Business CaseP&L ROIGoal of Investment

3.3. Customer SatisfactionCustomer SatisfactionNet Promoter Score

Would you recommend our product to a friend?NPS = %Yes – %No Correlated to market share and long term growth

Measure UP

1.1. Average Cycle TimeAverage Cycle TimeFrom Product ConceptTo First Release

or

From Feature RequestTo Feature Deployment

or

From DefectTo Patch

Three Holistic Measurements

oror

Fred Reichheld, The Ultimate Question


The Journey 1. Begin where you are

How do you create value and make a profit?2. Find your biggest constraint

What is the biggest problem limiting your ability to create value and make a profit?3. Envision your biggest threat

What is the biggest threat to your ability to continue creating value and making a profit over the long-term?4. Evaluate your culture

Establish and reinforce a culture of deep respect for front-line workers and for partners. Remove barriers that get in the way of pride in workmanship.

5. TrainTrain team leads, supervisors and managers how to lead, how to teach, and how to help workers use a disciplined approach to improving work processes.

6. Solve the Biggest ProblemTurn the biggest constraint over to work teams. Expect many quick experiments that will eventually uncover a path to a solution.

7. Remove accommodationsUncover the rules that made it possible to live with the constraint. Decide what the new rules should be.

8. MeasureSee if end-to-end cycle time, true profitability, and real customer satisfaction have improved.

9. ImplementAdopt changes supported by results.

10. Repeat the cycleWith the biggest problem addressed, something else will become your biggest problem. Find it and repeat the cycle.

40


A Short List of Books

1. Taiichi Ohno – Toyota Production System2. Mary & Tom Poppendieck – Lean Software Development3. Michael Kennedy – Product Development in the Lean Enterprise4. Mike Cohn – Agile Estimating and Planning5. Mugridge & Cunningham – Fit for Developing Software6. Poppendieck – Implementing Lean Software Development

l e a nsoftware development

www.poppendieck.comMary [email protected]

Thank You!More Information: www.poppendieck.com

l e a n - LASER Foundation

Documents

Transcript of l e a n - LASER Foundation