l e a n software development Introduction to Lean Software Development Speed Quality Low Cost mary@poppendieck.com Mary Poppendieck www.poppendieck.com Principles of Lean Software Development 1. Eliminate Waste Drive out Complexity 2. Focus on Learning Use Feedback-Driven Development 3. Build Quality In Mistake-Proof Every Step 4. Defer Commitment Build Change-Tolerant Code 5. Deliver Fast Don t Batch & Queue 6. Respect People Decide as Low as Possible 7. Optimize the Whole Appreciate the System 2 May 07 Copyright 2006 Poppendieck.LLC Quality Speed Low Cost 1
Put on Customer Glasses Principle 1: Eliminate Waste 3 May 07 Copyright 2006 Poppendieck.LLC The 80-20 Rule Features and Functions Used in a Typical System Often or Always Used: 20% Sometimes 16% Rarely 19% Often 13% Never 45% Always 7% Standish Group Study Reported at XP2002 by Jim Johnson, Chairman Rarely or Never Used: 64% 4 May 07 Copyright 2007 Poppendieck.LLC 2
Principle 2: Focus on Learning Software Development Finding ways to turn over more and more of what we know to computers so that we have more space left in our minds to discover more interesting things. I wonder what I should do next? Consider the Truck-Driving Problem: Program a computer to drive a truck across America unattended, on existing roads, in normal traffic. This is not a one-pass problem. It will be solved one module at a time over many years. Nor is it a software problem. Don t even think about the problem without the truck. In software development We try to solve too many truck driving problems All at once Without access to the truck! 5 May 07 Copyright 2007 Poppendieck.LLC Cycles of Discovery Iteration Planning Iteration Execution Daily Road Map: Prioritized list of desirable One Iteration Ahead Stories & Tests features 6 May 07 Copyright 2007 Poppendieck.LLC Every 2-4 Weeks Feedback Deployment - Ready Software 3
Cadence Benefits 1. Staged Delivery => better cash flow / higher profits. Minimum useful feature sets, highest payback first. 2. Feedback => closer fit to the real customer problem. IKIWISHI: I ll know it when I see it. 3. Velocity => story-points delivered each iteration. Velocity is a measure of the capacity of the team. Dangers 1. Irreversible decisions made too early can be expensive. Defer commitment / maintain options for critical decisions. 2. Lack of systems thinking can lead to sub-optimization. Design for operations and build change-tolerant code. 3. Do not use velocity as a performance measurement. Stable teams in a known domain establish a reliable velocity. 7 May 07 Copyright 2007 Poppendieck.LLC Principle 3: Build Quality In 1920 s: Invention: Looms that detect a broken warp thread when it breaks and stop immediately. 1950 s: Assembly lines where workers pull a cord to stop-the-line the moment a defect is detected. 8 May 07 Copyright 2007 Poppendieck.LLC 4
Don t Tolerate Defects There are Two Kinds of Inspection 1. Inspection to Find Defects WASTE 2. Inspection to Prevent Defects Essential The Role of QA The job of QA is not to swat mosquitoes, The job of QA is to put up screens. A Quality Process Builds Quality In If you routinely find defects during verification your process is defective. 9 May 07 Copyright 2007 Poppendieck.LLC Building Block Disciplines Simplicity Minimum Useful Feature Sets Common Infrastructure Architecture Conventions Tools Refactoring Continuous Improvement of the Code Base No Repetition Mistake-Proofing Configuration Management One Click Build Continuous Integration with Automated Testing Unit Tests Acceptance Tests Production Test Harnesses STOP if the tests don t pass Frequent Deployment Automated Release Packaging Automated Install 10 May 07 Copyright 2007 Poppendieck.LLC 5
Types of Testing Automated: Every Day From Brian Marick Automated: Every Build Support Programming Acceptance Tests Business Intent (Design of the Product) Unit Tests Developer Intent (Design of the Code) Business Facing Technology Facing 11 May 07 Copyright 2007 Poppendieck.LLC Usability Testing Exploratory Testing Property Testing Response, Security, Scaling, Resilience Critique Product Manual: As Early as Practical Tool-Based: As Early as Possible A Pilot from Innsbruck Principle 4: Defer Commitment In Pilot training, we were taught how to make decisions in challenging situations: 1. First decide when the decision will be made 2. 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: Because there are rocks in our clouds. 12 May 07 Copyright 2007 Poppendieck.LLC 6
Change-Tolerant Software Step One: Accept that Change is not the Enemy. 60-80% of all software is developed after first release. Step Two: Invest in Change-Tolerant Practices A development process that anticipates change will result in software that tolerates change. 1. Feedback-Driven Development 2. Options-Based Development 3. Test-Driven Development 13 May 07 Copyright 2007 Poppendieck.LLC Principle 5: Deliver Fast Software Development Product Development (Embedded Software) Software Development Competing on the basis of speed: Significant competitive advantage Large barrier to entry When speed matters You don t want to be left behind 14 May 07 Copyright 2006 Poppendieck.LLC 7
The Flow of Value Churn If you have requirements churn, you are specifying too early. If you have test-and-fix cycles, you are testing too late. Why do early specification and late testing seem like such a good idea? 15 May 07 Copyright 2006 Poppendieck.LLC Don t Batch & Queue Lists How long is your defect list? How far apart are your releases? How many weeks (years?) of work do you have in your backlog? Why do lists & queues seem like a good idea? 16 May 07 Copyright 2006 Poppendieck.LLC 8
Principle 6: Respect People Three Stonecutters were asked: What are you doing? I m cutting stones! I m building a cathedral. I m earning a living. 17 May 07 Copyright 2007 Poppendieck.LLC Move responsibility and decision-making to the lowest possible level. Engaged People Stone Cutters or Cathedral Builders? The Litmus Test: When workers are annoyed by their job Do they complain, ignore it, or fix it? 18 May 07 Copyright 2007 Poppendieck.LLC 9
Principle 7: Optimize the Whole Software is rather useless all by itself Software is embedded In hardware In a process In an activity Appreciate the System Build a complete product Not just Software Look at the whole picture Across the Value Stream For the Entire Lifecycle Software is going to be around for a LONG time. Dev Production Saving money in development at the expense of production makes no sense. 19 May 07 Copyright 2007 Poppendieck.LLC Measure UP Decomposition You get what you measure You can t measure everything Stuff falls between the cracks You add more measurements You get local sub-optimization Example Measure Cost, Schedule, & Scope Quality & Customer Satisfaction fall between the cracks Measure these too! Aggregation You get what you measure You can t measure everything Stuff falls between the cracks You measure UP one level You get global optimization Example Measure Cost, Schedule, & Scope Quality & Customer Satisfaction fall between the cracks Measure Business Case Realization instead! From to! From to! 20 May 07 Copyright 2007 Poppendieck.LLC 10
Three System Measurements Average Cycle Time From Product Concept To First Release or From Feature Request To Feature Deployment or From Defect To Patch The Business Case P&L or ROI or Goal of the Investment Customer Satisfaction A measure of sustainability 21 May 07 Copyright 2007 Poppendieck.LLC l e a n software development Thank You! More Information: www.poppendieck.com mary@poppendieck.com Mary Poppendieck www.poppendieck.com 11