What I learned from … “Lean Software Development” (by Mary & Tom Poppendieck) by Mike Williams

What I learned from … “Lean Software Development” (by Mary & Tom Poppendieck) by Mike Williams <mdub@dogbiscuit.org> Jan 2004

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”

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

Cost of Delay Self-Determination Motivation Leadership Expertise Perceived Integrity Conceptual Integrity Refactoring Testing Measurements Contracts “Tools” discussed in the book • Seeing Waste • Value Stream Mapping • Feedback • Iterations • Synchronization • Set-Based Development • Options Thinking • The Last Responsible Moment • Making Decisions • Pull Systems • Queuing Theory

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

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!

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

The Lean Principles (again) • Eliminate Waste • Amplify Learning • Decide as Late as Possible • Deliver as Fast as Possible • Empower the Team • Build Integrity In • See the Whole

The Seven Types of Waste • Inventory • Extra Processing • Overproduction • Transportation • Waiting • Motion • Defects

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

Waste: Extra processing • Paperwork • Requirements/Design documents • GANTT charts • Ask yourself: who needs this? • Bureaucracy • Approval/review/signoff processes • Change-control • Bug-tracking systems

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!

Waste: Waiting • … for Information, Resources, Approval • Waiting • delays delivery • reduces utilisation • promotes context-switching • Long turnaround times make it harder to delay decisions

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

Waste: Defects • Delay delivery of functionality • Impact of defect = severity X age • older bugs are harder to fix • Find/fix defects ASAP!

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

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)

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

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

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

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

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

Motivation • Belonging • team spirit • Safety • tolerance of mistakes (learning opportunities) • Competence • discipline, confidence • Progress • a feeling of accomplishment • celebrate success

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?

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

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

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!

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

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

What I learned from … “Lean Software Development” (by Mary & Tom Poppendieck) by Mike Williams