what i learned from … “lean software development” (by mary & tom poppendieck) by mike...

What I learned from …

“Lean Software Development”

(by Mary & Tom Poppendieck)

by Mike Williams<[email protected]>

Jan 2004

Mike Williams <[email protected]>

slide 2

About the book

● How to apply “Lean Principles” to Software Development?

● What are the Lean Principles?● How/why do they work?● How to map them to SW development?

● Not a methodology, but a collection of “thinking tools”


slide 3

The Lean Principles

● Eliminate Waste● Amplify Learning● Decide as Late as Possible● Deliver as Fast as Possible● Empower the Team● Build Integrity In● See the Whole


slide 4

“Tools” discussed in the book

1. Seeing Waste

2. Value Stream Mapping

3. Feedback

4. Iterations

5. Synchronization

6. Set-Based Development

7. Options Thinking

8. The Last Responsible Moment

9. Making Decisions

10. Pull Systems

11. Queuing Theory

12. Cost of Delay

13. Self-Determination

14. Motivation

15. Leadership

16. Expertise

17. Perceived Integrity

18. Conceptual Integrity

19. Refactoring

20. Testing

21. Measurements

22. Contracts


slide 5

Traditional Mass-Production

● ala Henry Ford, Frederick Taylor– Experts design processes in detail, ahead of time– Workers do as little (thinking) as possible– Maintain inventory of both raw materials and finished

product

● Problems– Long time-to-market– Change is difficult and expensive– Cost/risk of holding inventory– 350% staff turnover


slide 6

The Toyota Difference

● ala Taiichi Ohno– Just-in-time Delivery: Build-to-Order– Optimise the manufacturing process– Minimise inventory– More respect and responsibility for production-line

workers– Allow decisions to be changed!


slide 7

Other Examples of Lean Thinking

● Dell - assemble PCs to-order

● FedEx (circa 1971) - introduce overnight delivery of packages

● L.L.Bean (1980s) - provide same-day shipping

● eBay – basic functionality developed based on daily feedback from users


slide 8

The Lean Principles (again)



slide 9

The Seven Types of Waste

● Inventory● Extra Processing● Overproduction● Transportation● Waiting● Motion● Defects


slide 10

Waste: Inventory

● Incomplete work: features described, or designed, or even coded, but not yet in production

● Represents investment of time/effort that has not yet paid off

● Risk: business needs may change: features may never be required


slide 11

Waste: Extra processing

● Paperwork– Requirements/Design documents– GANTT charts– Ask yourself: who needs this?

● Bureaucracy– Approval/review/signoff processes– Change-control– Bug-tracking systems


slide 12

Waste: Overproduction

● Extra features– Gold-plating– Crystal-ball gazing

● 45% of features are never used, and only 20% are used often. (source: Standish Group)

● YAGNI!


slide 13

Waste: Waiting

● … for Information, Resources, Approval

● Waiting– delays delivery– reduces utilisation– promotes context-switching

● Long turnaround times make it harder to delay decisions


slide 14

Waste: Transportation/Motion

● Finding information– Is it difficult to get answers to questions?– Interrupting a developer’s “flow” is costly.

● Handoffs: communication is required when passing work on– It’s overhead– Information gets lost


slide 15

Waste: Defects

● Delay delivery of functionality

● Impact of defect = severity X age– older bugs are harder to fix

● Find/fix defects ASAP!


slide 16




slide 17

Amplify Learning

● Maximise learning● Leverage learning to maximum effect

● Attempting to predict/plan everything isn’t practical● Reacting to feedback is more effective● (Short) iterations make this possible

● Synchronize frequently– Continuous Integration● Communicate constraints rather than choices

when negotiating a common approach


slide 18




slide 19

Decide as Late as Possible

● Which means you can ...– make more informed decisions– keep your options open

● e.g. Financial options– Provide the opportunity to capitalise on positive

events, while minimising exposure

● e.g. Microsoft, Cisco– Wait for successful technologies to emerge, then just

acquire them (saves on R&D)


slide 20

The “Last Responsible Moment”

● … after which point, important alternatives are eliminated by default

● Procrastination tactics:– Share incomplete designs– Direct, two-way communication– Investigate multiple options?– Embrace change


slide 21




slide 22

Deliver as Fast as Possible

● Get rapid return-on-investment● Enable early feedback

● Optimise your capacity to deliver– you'll be able to delay decisions longer

● Optimise your capacity to change– bad decisions become less dangerous

● Create models to estimate the Cost of Delay


slide 23

Lessons from Queuing Theory

● Minimise cycle-time

● Small work packages, short iterations● Remove bottlenecks to maintain flow

– Apply resources to problem areas

● Slack - don't overload the system– a highway or computer network doesn't work well at

peak capacity


slide 24




slide 25

Empower the Team

● The critical factor in motivation is not measurement, but empowerment

● “Hire good people, and leave them alone”● Delegate decision-making downwards

– People closer to the coal-face have better information

● Tell people what to do, not how

● Improves Quality, Productivity and Morale


slide 26

The NUMMI Story

● GM closes Freemont plant in 1982– Low productivity– High absenteeism, high union activity

● Reopened in 1984 as a joint venture between Toyota and GM– By 1986, productivity had doubled, absenteeism was

low, job-satisfaction high– 85% of workforce were former employees

● The difference: empowerment


slide 27

Motivation

● Belonging– team spirit

● Safety– tolerance of mistakes (learning opportunities)

● Competence– discipline, confidence

● Progress– a feeling of accomplishment– celebrate success


slide 28

Respected Leaders

● Toyota centre on a “Chief Engineer”● 3M have a “Product Champion”

● For software projects: “Master Developer”, “Architect”, “Tech Lead” ???– different from XP Coach or Project Manager– assumes primary design responsibility– part of the team, daily involvement– an appointed role, or an emergent one?


slide 29




slide 30

Build Integrity In

● Perceptual Integrity– Solution fits with user's mental model

(Principle of Least Surprise)● Conceptual Integrity

– Parts of the system fit together well

● Requires excellent information flow between developers, customer, QA, users, etc.

● Achieve through– Testing, Refactoring, Simplicity– Iteration, to provide feedback


slide 31




slide 32

See the Whole

● Conventional performance measurement– Decompose work into sub-tasks– Standardise each task– Measure individual performance/conformance

● Negative effects: local optimisation– Workers working towards different goals– Disincentive to innovate– Culture of blame


slide 33

Aggregate measurements

● Measure/reward the whole, not the parts– e.g. “one level up” incentives at NUCOR

● team-member's bonus based on team performance● team-leader's bonus based on output of all teams

● Lance Armstrong– Tour-de-France winner every year 1999-2003– but never won more than 4 of the 21 stages!


slide 34

Contracts

● Contracts often inhibit development of trust– Each party has to look out for themselves

(local optimisation at the organisation level)– Fixed-price contracts favour the customer– T&M contracts favour the vendor

● Agile contracts promote trust and co-operation– e.g. Target-cost/schedule, Profit-sharing– Both parties have incentive to reach a common goal


slide 35

Lean Development and XP

● Eliminate Waste● Amplify Learning● Decide as Late as

Possible● Deliver as Fast as

Possible● Empower the Team● Build Integrity In● See the Whole

● Planning Game● Customer Tests● Test-Driven Development● Pairing● Small Releases● Continuous Integration● Simple Design● Design Improvement● Collective Ownership● Metaphor● Coding Standard● Whole Team● Sustainable Pace

what i learned from … “lean software development” (by mary & tom poppendieck) by mike...

Documents