Lean Software Development Is for Everyone
- 1. LEAN-agile © copyright 2010. Net Objectives, Inc. B E C O M I N G Lean Software For Everyone Ken Pugh Fellow Consultant KP Aug 2014
- 2. • Introduction and Background • Lean as Flow • Lean Software Development • Lean-Agile • Transforming into Lean Outline
- 3. Ken Pugh ken.pugh @netobjectives.com Photo Size: Height: 2.25 Position: from top left corner Horizontal 0.75 Vertical 1. Picture Style: Simple Black Frame No code goes in till the test goes on. A journey of two thousand miles begins with a single step. Fellow Consultant SPC, Lean, Scrum, ATDD, TDD, OOA&D, Design Patterns, Over 2/5 century of software development experience Author of seven books, including: – Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability (2006 Jolt Award) – Interface Oriented Design – Lean Agile Acceptance Test-Driven Development: Better Software Through Collaboration
- 4. Lean Enterprise Business Manag ement Team ASSESSMENTS CONSULTING TRAINING COACHING Lean for Executives Product Portfolio Management Business Product Owner Lean Management Project Management ILAFYT Kanban / Scrum ATDD / TDD / Design Patterns technical process
- 5. Lean Thinking, Jim Womack and Daniel Jones Lean Software Development, Mary and Tom Poppendieck The Principles of Product Development Flow: Second Generation Lean Product Development, Donald Reinertsen Alan Shalloway, http://www.netobjectives.com/blog Resources
- 6. Overall Rule There are exceptions to every statement, except this one 6
- 7. copyright © 2010 Net Objectives Inc. Introduction and Background
- 8. Lean software engineering – Continuous delivery of high quality applications In short
- 9. Toyota Production System – Lean Manufacturing Lean Thinking – Use lean thinking on workflow – Software development is workflow Lean Software Development Creating software is not the same as producing a car Principles derived from Lean Lean Approaches
- 10. Taiichi Ohno, chief engineer Eiji Toyoda (and cousin Kiichiro Toyoda and his father Sakichi Toyoda, (Toyoda Loom Works founder)) Design out overburden (muri) and inconsistency (mura), eliminate waste (muda). Smooth process - design out inconsistency Flexible – without overburden which generates waste Elimination of waste Toyota Production System (TPS)
- 11. Continuous improvement – Kazien Respect for people Long-term philosophy – Not short term goals Right process will produce right results – Stop to fix problems – Visual controls – Use reliable, tested technology Add value to organization by developing your people and partners – Develop exceptional teams Continuously solving root problems drives organizational learning – Decisions by consensus TPS Principles
- 12. Value comes from end customer Value stream – Eliminate steps not creating value Make remaining steps flow in integrated sequence Let customers pull from upstream activity Transparency – Helps eliminate waste – Continuous improvement Lean Thinking
- 13. Eliminate Waste Create Knowledge Build Quality In Defer Commitment Deliver Fast Respect People Improve the System Lean Software Development Principle
- 14. Agile
- 15. copyright © 2010 Net Objectives Inc. Workflow
- 20. concentration
- 22. outcome
- 24. business value trumps Reducing Waste © Warp and Byte Designs, Inc..
- 25. Flow From Concept to Consumption
- 26. Business Value – What Is It? (1) Need to measure business value Deliver best ROI for business value "I can't define it, but I know it when I see it“ Question: What is it to you? 26
- 27. Business Value – What Is It? (2) Business Value can be: – Increased revenue (sales, royalties, fees) ($$) – Decreased expenses ($$) Less resources More efficient use of resources – Customer satisfaction ($$ ??) Promoters / Satisfiers/ Detractors – Staying in business ($$ ??) – Staying out of jail ($$ ??) – Avoiding risk ($$ ??) – Your suggestions? 27
- 28. Business Value Projects Next Project BV = 8 Current Project BV = 13 Previous Project BV= 20
- 30. Transparency To Do Working On Done Next Project Current Project Previous Project
- 31. Deliver – Minimum Marketable Feature (MMF) – Minimum Business Increment (MBI) – Key = Independently Releasable Item (IRI) Develop – Stories – Scenarios Key = Separately Developable Items (SDI) Although may be sequenced dependent Small bites
- 32. Small Pieces To Do Working On Done Current Project Current Part Previous part Still Another Part Another Part Some Part
- 33. Flow
- 34. Business Priority BUSINESS DISCOVERY BUSINESS DELIVERY Business Planning Business Readiness Ready to Pull Incremental Development Incremental Deployment Support & Feedback Decision Is it technically feasible? Decision Is it ready to release? PORTFOLIO Decision Is there enough business value? Flow
- 35. Cycle Time
- 36. Lean Principle Idea to Delivery Support & Feedback Project Approval Project Staffing Project Development Project Deploy- ment Visioning Total cycle time
- 37. Lean Principle Support & Feedback Project Approval Project Staffing Project Development Project Deploy- ment Visioning Support & Feedback Project Development Project Deployment $$$ Cost
- 38. Support & Feedback Project Approval Project Staffing Project Development Project Deploy- ment Visioning Support & Feedback Project Development Project Deployment Project Approval Project Staffing Visioning Lean Principle Opportunity Cost
- 39. Value Stream
- 40. 1. Identify the actions taken in the value stream Approv e Request Reqts Sign Off Review Deploy Analysis Design Code Test
- 41. 0.5 hrs 160 hrs8 hrs 8 hrs 120 hrs 280 hrs 240 hrs 100 hrs 8 hrs2 hrs Approv e Request Reqts Sign Off Review Deploy Analysis Design Code Test 1. Identify the actions taken in the value stream 2. What was the real time from start to finish of the action?
- 42. 0.5 hrs 160 hrs8 hrs 8hrs 120 hrs 280 hrs 240 hrs 100 hrs 8 hrs2 hrs Approve .1 / 7.9 hrs Request 0.5 / 0.0 hr Reqts 60 / 100 hrs Sign Off 1 / 7 hrs Review 2 / 0 hrs Deploy 3 / 5 hrs Analysis 40 / 60 hrs Design 40 / 80 hrs Code 80 / 200 hrs Test 40 / 200 hrs 1. Identify the actions taken in the value stream 2. What was the real time from start to finish of the action? 3. What was the average time working on this vs working on other things?
- 43. 0.5 hrs 160 hrs8 hrs 8hrs 120 hrs 280 hrs 240 hrs 100 hrs 8 hrs2 hrs 320 hrs 80 hrs 320 hrs 80 hrs 80 hrs 160 hrs 80 hrs 80 hrs 80 hrs 1. Identify the actions taken in the value stream 2. What was the real time from start to finish of the action? 3. What was the average time working on this vs working on other things? 4. Identify time between actions Approve .1 / 7.9 hrs Request 0.5 / 0.0 hr Reqts 60 / 100 hrs Sign Off 1 / 7 hrs Review 2 / 0 hrs Deploy 3 / 5 hrs Analysis 40 / 60 hrs Design 40 / 80 hrs Code 80 / 200 hrs Test 40 / 200 hrs
- 44. 16 June 2015 0.5 hrs 160 hrs8 hrs 8hrs 120 hrs 280 hrs 240 hrs 100 hrs 8 hrs2 hrs 320 hrs 80 hrs 320 hrs 80 hrs 160 hrs 80 hrs 80 hrs 80 hrs 1. Identify the actions taken in the value stream 2. What was the real time from start to finish of the action? 3. What was the average time working on this vs working on other things? 4. Identify time between actions 5. Identify any loop backs required 80 hrs 65% defective Repeat 3X 20% rejected Repeat 1X Approve .1 / 7.9 hrs Request 0.5 / 0.0 hr Reqts 60 / 100 hrs Sign Off 1 / 7 hrs Review 2 / 0 hrs Deploy 3 / 5 hrs Analysis 40 / 60 hrs Design 40 / 80 hrs Code 80 / 200 hrs Test 40 / 200 hrs
- 45. 1. Identify the actions taken in the value stream 2. What was the real time from start to finish of the action? 3. What was the average time working on this vs working on other things? 4. Identify time between actions 5. Identify any loop backs required 6. Calculate Process Cycle Efficiency: Approve .1 / 7.9 hrs Request 0.5 / 0.0 hrs Reqts 60 / 100 hrs Sign Off 1 / 7 hrs Review 2 / 0 hrs Deploy 3 / 5 hrs Analysis 40 / 60 hrs Design 40 / 80 hrs Code 80 / 200 hrs Test 40 / 200 hrs 0.5 hrs 160 hrs8 hrs 8hrs 120 hrs 280 hrs 240 hrs 100 hrs 8 hrs2 hrs 320 hrs 80 hrs 320 hrs 80 hrs 160 hrs 80 hrs 80 hrs 80 hrs 65% defective Repeat 3X 20% rejected Repeat 1X 80 hrs Approve .1 / 7.9 hrs Request 0.5 / 0.0 hrs Reqts 60 / 100 hrs Sign Off 1 / 7 hrs Review 2 / 0 hrs Deploy 3 / 5 hrs Analysis 40 / 60 hrs Design 40 / 80 hrs Code 80 / 200 hrs Test 40 / 200 hrs Avg Time Worked Total Cycle Time 0.5 hrs 160 hrs8 hrs 8 hrs 120 hrs 280 hrs 240 hrs 100 hrs 8 hrs2 hrs 320 hrs 80 hrs 320 hrs 80 hrs 160 hrs 80 hrs 80 hrs 65% defective Repeat 3X 20% rejected Repeat 1X 80 hrs 80 hrs PCE = = 14.9% 509 hrs 3433 hrs 509 hrs 3433 hrs Avg Time Worked Total Cycle Time
- 46. Approve .1 / 7.9 hrs Request 0.5 / 0.0 hrs Reqts 60 / 100 hrs Sign Off 1 / 7 hrs Review 2 / 0 hrs Deploy 3 / 5 hrs Analysis 40 / 60 hrs Design 40 / 80 hrs Code 80 / 200 hrs Test 40 / 200 hrs 0.5 hrs 160 hrs8 hrs 8hrs 120 hrs 280 hrs 240 hrs 100 hrs 8 hrs2 hrs 320 hrs 80 hrs 320 hrs 80 hrs 160 hrs 80 hrs 80 hrs 80 hrs 65% defective Repeat 3X 20% rejected Repeat 1X 80 hrs 320 hrs 80 hrs 320 hrs 80 hrs 160 hrs 80 hrs 80 hrs 65% defective Repeat 3X 20% rejected Repeat 1X 80 hrs 80 hrs 3433 – 509 = 2924 Eliminating delays between what you do Getting better at what you do Which gives a better return?
- 47. Cycle Time What’s the cycle time from input to output? How can it be shortened? – Eliminate delays – Eliminate loop-backs – Manage WIP –
- 48. Waste and Delays
- 49. 1. Partially Done Work 2. Paperwork 3. Extra Features 4. Task Switching 5. Handoffs 6. Delays 7. Defects Waste Indicators
- 50. how much of what you do is valuable? rework?
- 51. DELAY IS hand-offs bottlenecks information delay untested code unread requirements transaction related setup/cleanup coordination related assign people finding redoing reworking waiting
- 52. Pull
- 53. PUSH
- 54. Work enters queue When someone needs new work, they pull from queue Work goes through stages When the work done in a stage, it flows to next. Until work is done Pull
- 55. PULL
- 56. BUT LIMIT QUEUES
- 57. Reduce WIP Queuing theory Focus on quality
- 58. Practice
- 59. EXERCISE Part One AGILE IS FUN
- 60. EXERCISE Part Two AGILE IS FUN
- 62. Implement lean across entire value stream – To deliver business value – Not just improve development Optimize the Whole / See the Whole
- 63. Focus on customer value Only start work that can be completed Eliminate Waste
- 64. Move tests forward – Acceptance Test Driven Development Automated testing Write change tolerant code Build Quality In / Build Integrity In
- 65. Small batches Get feedback fast Emphasize cycle time, not utilization Deliver Fast / As Possible
- 66. Use knowledge learned from creating application Cross-functional teams to share knowledge Quick feedback Create Knowledge / Amplify Learning
- 67. Create clear frameworks for decisions Decision making at lowest possible level Empower People / The Team
- 68. Periodic reflections Perform root cause analysis Continually Improve
- 69. Wait till last practical moment to make decision – More information available Defer Commitment / Decide as Late as Possible
- 71. Driving in Germany - picture of autobahn © Warp and Byte Designs, Inc..
- 72. © Warp and Byte Designs, Inc..
- 73. Measurement
- 74. © Warp and Byte Designs,
- 75. Metrics What is important? Customer /user satisfaction Production defects Rate of delivery of business value © Warp and Byte Designs, Inc..
- 76. copyright © 2010 Net Objectives Inc. Lean – Agile
- 77. Apply lean principles/practices to agile processes What lean principles/practices do you see in – Scrum – Kanban Lean Agility
- 78. Thinking l e a n a g i l e WHAT is the most important thing WHEN is it most needed HOW we break down that work HOW we FLOW that work
- 79. Delivering Thinking l e a n a g i l e Breaking work down Creating the best environment to deliver that work Incremental and Iterative development
- 80. Business Value Delivering Thinking l e a n a g i l e
- 81. copyright © 2010 Net Objectives Inc. Beginning the Transformation
- 82. Getting Started Agree to goals – Why change? Map the value stream Determine what process to use – Scrum, Kanban, Scrumban, etc. Agree to transparency – Up and down the line Agree to policies – Done-ness definitions, etc. Agree to operational review – Team and organization Educate the team(s) Start doing it David Anderson. XTC, London 2009, October Getting started with kanban
- 83. Old Status Quo New Status Quo Chaos Transforming Idea Change Model From Virginia Satir
- 84. copyright © 2010 Net Objectives Inc. This is Not an Ending, But a Beginning
- 85. Shorten time to realize values Pay attention to delays Actively manage queues Emphasize cycle time, not utilization Summary - Focus on Flow
- 86. copyright © 2010 Net Objectives Inc. Supplementary
- 87. Roles Purpose
- 88. MAKE • INCREMENTAL DELIVERY • CREATIVELY SOLVING THEIR PROBLEMS • QUALITY BUILT IN technical
- 89. technic al VALUE • PRIORITIZATION • BUSINESS ITERATIONS • RELEASE PLANNING
- 90. FLOW • VALUE STREAM VISUALIZATION • IMPEDIMENT IMPACT • WORKFLOW AS PROCESS technic al WITH ACCOUNTABILITY • MANAGE (LIMIT) QUEUES • VISUAL CONTROLS • MANAGE FLOW (PROCESS)
- 92. Business Value
- 93. Question What percentage of features are never used?
- 94. Waste and the Delay of Value Always 7% Often 13% Sometimes 16% Rarely 19% Never Used 45% Source: Standish Group Study of 2000 projects at 1000 companies Usage of Features and Functions in Typical System _g
- 95. Teams
- 96. © U.S. Army
- 97. © Warp and Byte Designs, In Successful teams Collaborate Shared accountability Shared approach to doing work Shared history
- 98. © Warp and Byte Designs, Inc..
- 99. Feedback
- 100. Agile Feedback – Small Increments 100 No feedback Desired Delivered With feedback Desired Delivered
- 102. Deliver Quickly
- 103. Focus on known, valuable features gives greater certainty produces greater value lowers risk of mis-building and over-building Deliver in Stages when possible
- 104. do the most important half first standard development sequence More important Less important
- 105. do the most important 25% first standard development sequence More important Less important
- 107. First Release Investment Period Payback Period Profit Period Breakeven Cashflow Time economics of responsiveness Mark Denne and Jane Cleland-Huang, Software by Numbers.
- 108. Staged Releases First Release Invest- ment Period Profit Period Pay- back Period Cashflow Time Release 1 Net Return
- 109. Staged Releases Profit Period Second Release Invest- ment Period Pay- back Period Release 2 Net Return Cashflow Time Release 1 Net Return
- 112. Cashflow Breakeven Single Release First Release Time Staged Releases 10 When competition is intense
- 113. Multi-Tasking
- 114. Request 1/Team 1 Request 2/Team 2 Request 3/Team 3 A Harder ProblemSCENARIO B another way to think of it
- 115. Request 1 Request 2 Request 3 A Harder ProblemSCENARIO B try this: quicker feedback
- 116. Project 1 Project 2 Project 3 Month 3Month 2Month 1 Month 4 Three ways to do three projects Do one at a time – may not be politically feasible. Do them all at once, switching between them when delayed waiting for answers Do them guided by Minimal Marketable Features Product Development for the Lean Enterprise by Michael Kennedy. Oaklea Press. 2003 Task-Switching and Schedules
- 117. Capacity Utilization
- 119. Efficiency H o w d o y o u m e a s u r e i t ? K e e p i n g p e o p l e b u s y O r P r o d u c i n g b u s i n e s s v a l u e
- 120. @ throughput vs. utilization Here’s a spot! And another!
- 121. Miscellaneous
- 122. Technical Versus Business Technical Inside – Components –Architect Business – Outside
- 123. Risks – what are there? © Warp and Byte Designs, Inc..
- 124. Observation Anticipation of long delivery cycles encourages piling on of poorly prioritized requirements
- 126. Getting Requirements Testing Programming Design Integration Planning Collaboration Re-doing requirements Working from old requirements “Fixing” bugs “Integration” errors Deployment Building unneeded features Overbuilding frameworks What Work Do You Do? Training Documentation Essentially duplicating components
- 127. Lean-Agile: Evolving Agility Continually evolving Sustaining, not improving DecliningMaturation Lean-Agility Year 1 Year 2 Year 3 Iterative Flow Highest Business Value Low ∞
- 128. Project-based Business Value-based • Scope • Budget • Schedule Defined • Defined without priority Require- ments • Scope • Budget and schedule fixed Limited evolution • Build & deploy at end Big bang deployment • Highest value • Allocate budget Discovery • Prioritized on Business Value • Sequenced on ROI Require- ments • Based on discovery • Budget follows Constant evolution • Build & deploy increments Increments