l e a n The Efficiency Paradox software development Resource Efficiency vs. Flow Efficiency

Transcription

1 software development The Efficiency Paradox Resource Efficiency vs. Flow Efficiency Mary Poppendieck

2 Resource Efficiency Alison 2 Flow Efficiency = 2 hours /1008 hours =0.2% Copyright 2014 Poppendieck.LLC From This Is Lean, by Modig and Åhlström

3 Flow Efficiency 500 Times Faster 3 Flow Efficiency = 80 minutes / 120 minutes = 67% Copyright 2014 Poppendieck.LLC From This Is Lean, by Modig and Åhlström

4 Where is the Camera? On The Resource On The Flow Unit 4 Copyright 2014 Poppendieck.LLC From This Is Lean, by Modig and Åhlström

5 Sources of Inefficiency 1. Long Throughput Times a. New Needs Arise b. Windows of Opportunity Close 2. Many Flow Units a. Handling, Scheduling b. Storing, Finding 3. Many Restarts a. Get-up-to-Speed Time b. Mistakes, Defects 5 From This Is Lean, by Modig and Åhlström Copyright 2014 Poppendieck.LLC

6 Busy Efficient Resource Efficiency is not as efficient as you think Failure Demand Superfluous Work Valuable W ork 6 Copyright 2014 Poppendieck.LLC

7 The Dead Fish Effect Lesson: Stop trying to maximize machine utilization. 7 Copyright 2013 Poppendieck.LLC Lesson: Stop trying to maximize resource utilization.

8 Building the Wrong Thing The Biggest Waste in Software Development Features / Functions Used in a Typical System Often / Always Used: 20% Rarely / Never Used: 64% Cost of Complexity Often 13% Sometimes 16% Rarely 19% Cost Always 7% Never 45% Standish Group Study Reported at XP2002 by Jim Johnson, Chairman 8 Copyright 2014 Poppendieck.LLC Time

9 Defect Injection Process Specifications Code?Match? Test % of Release Cycle Spent Hardening Top Companies: <10% Typical: 30% 9 Release Cycle Copyright 2014 Poppendieck.LLC Sometimes: l 50% e a n

10 The Efficiency Paradox You think you are here. You are probably here. Start with Flow Efficiency. Then add Resource Efficiency. 10 Copyright 2014 Poppendieck.LLC

11 The Real Efficiency Paradox Why do we value resource efficiency over flow efficiency? Chris Argyris 11 Copyright 2014 Poppendieck.LLC What must we believe in order to prefer resource efficiency?

12 Conceptual Model of Cause & Effect Resource Efficiency Low Cost profit Queues more options better choices Flow Efficiency Delighted Customers profit Queues add no value create superfluous work Multi-tasking high utilization greater efficiency 12 Copyright 2014 Poppendieck.LLC Multi-tasking constant thrashing serious inefficiency

13 Queuing Theory Little s Law Time Through the System = Number of Things in Process Average Completion Rate 13 Copyright 2011 Poppendieck.LLC

14 The Utilization Paradox Cycle Time as a Function of Utilization and Batch Size* 45 Cycle Time (hours) Large Batches Medium Batches Small Batches % 20% 30% 40% 50% 60% 70% 80% 90% 100% l Thrashing e a n * This assumes batch size is proportional to variability. Uncertainty also drives of variability. 14 Copyright 2012 Poppendieck.LLC

15 Reducing Cycle Time Optimize Throughput Not Utilization Minimize the Number of Things In Process Minimize the Size of Things In Process Level the Workload Manage Workflows, not Schedules Establish a Regular Cadence Limit Work To Capacity Timebox, Don t Scopebox Pull Don t Push 15 Copyright 2011 Poppendieck.LLC Queuing Theory 101

16 Pull Scheduling Small Requests (Wishful Thinking) Input Flow Output Capacity (Wishful Thinking) Never 16 Copyright 2011 Poppendieck.LLC

17 Organizing for Flow Ericsson Networks Reconfigured the Development Process 1. Manage features, not projects 2. Decouple releases from development 3. Architects and specialists become consultants a) Architectural runway work 4. Leaders decide which features to do next 5. Engineers reassigned from functions to teams a) Small, multi-function feature teams b) Product and technical leadership c) Access to customer engineer d) Determine their own process 6. Teams Assigned Features a) One feature (~3 weeks) at a time b) Date is fixed, team determines content c) Feature is expected to pass release verification d) Figure out how to get it done get help if necessary 17 Copyright 2013 Poppendieck.LLC The past was not good enough for the future. What Happened: Twice the speed Higher hit rate Significantly higher quality More engaged engineers Reciprocity between teams Thanks to Mats Lindén, Ericsson

18 How Flow Creates Predictability Understand how the work works. Ericsson Networks No more point estimates! All estimates must be best-case / worst-case. Manage features, not projects. Fix scope, let deadline vary. Accept uncertainty and learn how to live with it. Thanks to Hendrik Esser, Ericsson 18 Copyright 2013 Poppendieck.LLC l On Time e Deliveries a n Superior Quality

19 Fast Feedback Next Generation Software Development Process Acceptance test driven development process Tight collaboration between business and delivery teams Cross-functional teams include QA and operations Automated build, testing, db migration, and deployment Incremental development on mainline with continuous integration Software always production ready Releases tied to business needs, not operational constraints Next Generation Product Development Process Build a Minimum Viable Product Measure the Response Repeat Learn 19 Copyright 2013 Poppendieck.LLC Customer Development team

20 software development Thank You! More Information: Mary Poppendieck