l e a n Faulty Assumptions software development How Lean Software Development Reduces Risk

Transcription

1 software development Faulty Assumptions How Lean Software Development Reduces Risk Mary Poppendieck

2 Assumptions Assumption: an unstated belief about how the world is, or will become. At the heart of most disasters we find faulty assumptions in design or operation. Assumptions made are risks accepted and taken. When assumptions are tied to other assumptions, risks quickly magnify. Robert Charette, Challenging the Fundamental Notions of Software Development Examine Your Assumptions 2 It is not what you know that can hurt you. April 12 Copyright 2012 Poppendieck.LLC Will Rodgers It is what you know that is not so.

3 TPS: Just-in-Time Flow Faulty Assumption: Maximum machine productivity = maximum overall productivity 3 April 12 Copyright 2008 Poppendieck.LLC Faulty Assumption: Maximum individual productivity = maximum overall productivity

4 Assumption: Early Specification Reduces Waste Features and Functions Used in a Typical System Often or Always Used: 20% Sometimes 16% Rarely 19% Often 13% Never 45% Standish Group Study Reported at XP2002 by Jim Johnson, Chairman Cop Always 7% April 12 4 Rarely or Never Used: 64%

5 Cost Lean Principle: Eliminate Waste Waste is making the wrong thing or making the thing wrong. Features that will not be used are waste, even if customers asked for them! In any system where technology or market conditions change, an early detailed specification significantly increases waste. Time The Biggest opportunity for increasing Software Development Productivity: Write Less Code! Cop April 12 5

6 TPS: Single Digit Set-up Manufacturing Faulty Assumption: Die changed have a huge overhead Don t change dies very often TPS: Economics requires frequent die change One Digit Exchange of Die Cop March, Software Development Faulty Assumption: Releases have a huge overhead Don t release very often Lean: Economics l requires e many frequent a releases n Continuous Delivery

7 Cop Assumption: The Job of Testing is to Find Defects The job of testing is to prevent defects If you are focused on finding defects you are not focused on preventing them. A quality process builds quality into the code If you routinely find defects during verification your process is defective. Defects are not caused by developers Defects are caused by a system which allows defects. Defects are a management problem. --- W. Edwards Deming April 12 7

8 Lean Principle: Build Quality In Every software development process ever invented has had the same primary goal find and fix defects as early in the development process as possible. If you are finding defects at the end of the development process your process is not working for you. How good are you? When in your release cycle do you try to freeze code and test the system? What percent of the release cycle remains for this hardening? Typical: 30% Top Companies: <10% 8 April 12 Release Cycle Copyright 2012 Poppendieck.LLC Sometimes: 50%

9 Assumption: Releases are Painful! Avoid Releases! Is Your Release Cycle greater than six months? Quick & Dirty Value Stream Map: Need a Feature Need a Feature Design Develop Harden UAT Release Cycle Release Cycle Release Cycle Value-Added Time Total Cycle Total Time Cycle Time Start Average Start End 9 April 12 How can a one week feature take over a year to deliver? Copyright 2012 Poppendieck.LLC

10 Iterate 10 Lean Principle: Learn Constantly For Each Business Capability: 1. Design a. Specify: Discuss and agree on examples of intended behavior. b. Automate: Put the examples into a regression framework (eg. cucumber). 2. Implement a. Develop: TDD + CI (with Contract Tests) b. Refactor: Clean up the code to keep it simple. c. Regression: End-to-End testing with regression framework. 3. Validate a. Test: Exploratory Testing, Performance Testing, Canary Releasing b. Measure Value: A/B Experiments, Cohort Metrics, Interviews, etc. 4. Learn April 12 Copyright 2012 Poppendieck.LLC

11 Reports Metadata BINARIS Reports Metadata BINARIS Reports Metadata Reports BINARIS Metadata Continuous Delivery Design Stage Model Hypothesis SBE Wireframes Source Code & Tests VERSION CONTROL Environment & Application Configuration Scripts Self-Service Deployments Testers UAT Stage Configure Environment Deploy Binaries Smoke Test Manual Testing Develop Stage Design Code & Script Unit Test Refactor Commit Stage Compile Commit Tests Assembly Code Analysis Acceptance Stage Configure Environment Deploy Binaries Smoke Test Run Acceptance Tests Testers Capacity Stage Configure Environment Deploy Binaries Smoke Test Run Capacity Tests Operations Push-Button Releases Production Configure Environment Deploy Binaries Smoke Test 11 April 12 Copyright 2012 Poppendieck.LLC ARTIFACT REPOSITORY

12 Assumption: Organize with Projects Projects Maintenance Completion Start of Project Batch Funding Short Term Thinking 12 April 12 Copyright 2011 Poppendieck.LLC Up-front funding Decompose into Detailed Tasks Schedule Each Task Manage Tasks to Schedule Success = Cost/Schedule/Scope Projects have an end Project Teams Disband

13 Lean Principle: Optimize the Whole System Products Dot upgrade Major Release First Production Release Internal Release Feasibility Concept Beta Release Alpha Release Incremental Funding System Thinking 13 April 12 Copyright 2011 Poppendieck.LLC Incremental funding Scope is expected to evolve Learning is more important than The Plan Manage Workflow, rather than Tasks Success = profit/market share Successful Products don t end Team usually stays with the Product

14 Empire State Building September 22, 1929 Demolition started January 22, 1930 Excavation started March 17, 1930 Construction started November 13, 1930 Exterior completed May 1, 1931 Building opened Exactly on time 18% under budget One Year Earlier: How did they do it? 14 April 12 The key: Focus on FLOW. Copyright 2011 Poppendieck.LLC

15 Steel Schedule We thought of the work as if it were a band marching through the building and out the top. From: Building the Empire State Builders Notebook: Edited by Carol Willis 15 April 12 Copyright 2011 Poppendieck.LLC

16 The Four Pacemakers 1. Structural Steel Construction Completed September 22, 12 days early 2. Concrete Floor Construction Completed October 22, 6 days early 3. Exterior Metal Trim &Windows Completed October 17, 35 days early 4. Exterior Limestone Completed November 13, 17 days early 16 From: Building the Empire State Builders Notebook: Edited by Carol Willis April 12 Copyright 2011 Poppendieck.LLC

17 Key Success Factors 1. Teamwork of owner, architect, and builder Eliminated design loops by consulting experts early. 2. Deeply Experienced Builders Fixed Price Contract! 3. Focus on the key constraint: Material Flow 500 trucks a day no storage on site 4. Decoupling The pacemakers (and other systems) were designed to be independent 5. Cash Flow Thinking Every day of delay cost $10,000 ($120,000 today). 6. Schedule was not laid out based on the details of the building design, the building was designed based on the constraints of the situation. Two acres of land in the middle of New York l City, zoning e ordinances, a n $35,000,000 of capital, the laws of physics, and a May 1, 1931 deadline. 17 April 12 Copyright 2011 Poppendieck.LLC

18 Lessons Design system to meet the real constraints; do not derive constraints from the design. Decouple workflows; break dependencies! Workflows are easier to control & more predictable than schedules. 18 April 12 Copyright 2011 Poppendieck.LLC

19 Iterative Workflow Discovery Delivery Daily Stories & Tests High Level Business Goals 19 or Product Shortly Before Implementation Concept April 12 Ready Ready Copyright 2011 Poppendieck.LLC Every 2-4 Weeks Deployable Software with Test Suites Feedback Done Done

20 Kanban Workflow Weekly Dev SIT Next Discover Ready Dev/Unit Test Ready SIT Deploy orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur FLOW Avg cycle time: 12 days Ready to Design: 1. Vendor time committed 2... Ready to Develop: 1. Wireframes 2. Story Tests 3. Less than 3 days work Ready for system test 1. Story test passed & in regression harness 2. No false negatives 3. Proper environment Ready to Deploy: 1. Regression passed Visualize and Manage Workflow Limit Work in Process Clarify Done for each Column Understand Capacity April 12 Copyright 2011 Poppendieck.LLC

21 Principles of Lean Software Development 1. Eliminate Waste 2. Build Quality In 3. Learn Constantly 4. Deliver Fast 5. Optimize the Whole 6. Engage Everyone 7. Keep Getting Better Cop April Quality Low Cost Speed

22 software development Thank You! More Information: Mary Poppendieck