Downloaded 49 times
More Related Content
Similar to Lean Software Development Is for Everyone
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: fromtop 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 BusinessProduct 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 Thereare exceptions to every statement, except this one 6
- 7. copyright © 2010Net Objectives Inc. Introduction and Background
- 8. Lean softwareengineering – Continuous delivery of high quality applications In short
- 9. Toyota ProductionSystem – 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 comesfrom 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.
- 15. copyright © 2010Net Objectives Inc. Workflow
- 17.
- 20.
- 21.
- 22.
- 24. business value trumps ReducingWaste © Warp and Byte Designs, Inc..
- 25. Flow From Conceptto 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 ProjectBV = 8 Current Project BV = 13 Previous Project BV= 20
- 29.
- 30. Transparency To Do WorkingOn Done Next Project Current Project Previous Project
- 31. Deliver – MinimumMarketable 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 DoWorking On Done Current Project Current Part Previous part Still Another Part Another Part Some Part
- 33.
- 34. Business Priority BUSINESS DISCOVERY BUSINESSDELIVERY 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.
- 36. Lean Principle Idea toDelivery 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.
- 39.
- 40. 1. Identify theactions taken in the value stream Approv e Request Reqts Sign Off Review Deploy Analysis Design Code Test
- 41. 0.5 hrs 160hrs8 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 160hrs8 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 160hrs8 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.5hrs 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 theactions 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.9hrs 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’sthe cycle time from input to output? How can it be shortened? – Eliminate delays – Eliminate loop-backs – Manage WIP –
- 48.
- 49. 1. Partially DoneWork 2. Paperwork 3. Extra Features 4. Task Switching 5. Handoffs 6. Delays 7. Defects Waste Indicators
- 50. how much ofwhat you do is valuable? rework?
- 51. DELAY IS hand-offs bottlenecks informationdelay untested code unread requirements transaction related setup/cleanup coordination related assign people finding redoing reworking waiting
- 52.
- 53.
- 54. Work enters queue Whensomeone 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.
- 56.
- 57. Reduce WIP Queuing theory Focuson quality
- 58.
- 59.
- 60.
- 61.
- 62. Implement leanacross entire value stream – To deliver business value – Not just improve development Optimize the Whole / See the Whole
- 63. Focus oncustomer value Only start work that can be completed Eliminate Waste
- 64. Move testsforward – 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 knowledgelearned from creating application Cross-functional teams to share knowledge Quick feedback Create Knowledge / Amplify Learning
- 67. Create clearframeworks for decisions Decision making at lowest possible level Empower People / The Team
- 68. Periodic reflections Perform root cause analysis Continually Improve
- 69. Wait tilllast practical moment to make decision – More information available Defer Commitment / Decide as Late as Possible
- 70.
- 71. Driving inGermany - picture of autobahn © Warp and Byte Designs, Inc..
- 72. © Warp andByte Designs, Inc..
- 73.
- 74. © Warp andByte Designs,
- 75. Metrics What is important? Customer/user satisfaction Production defects Rate of delivery of business value © Warp and Byte Designs, Inc..
- 76. copyright © 2010Net Objectives Inc. Lean – Agile
- 77. Apply leanprinciples/practices to agile processes What lean principles/practices do you see in – Scrum – Kanban Lean Agility
- 78. Thinking l e an 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 an 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 ea n a g i l e
- 81. copyright © 2010Net Objectives Inc. Beginning the Transformation
- 82. Getting Started Agreeto 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 QuoNew Status Quo Chaos Transforming Idea Change Model From Virginia Satir
- 84. copyright © 2010Net Objectives Inc. This is Not an Ending, But a Beginning
- 85. Shorten timeto realize values Pay attention to delays Actively manage queues Emphasize cycle time, not utilization Summary - Focus on Flow
- 86. copyright © 2010Net Objectives Inc. Supplementary
- 87.
- 88. MAKE • INCREMENTAL DELIVERY •CREATIVELY SOLVING THEIR PROBLEMS • QUALITY BUILT IN technical
- 89. technic al VALUE • PRIORITIZATION • BUSINESSITERATIONS • RELEASE PLANNING
- 90. FLOW • VALUE STREAMVISUALIZATION • IMPEDIMENT IMPACT • WORKFLOW AS PROCESS technic al WITH ACCOUNTABILITY • MANAGE (LIMIT) QUEUES • VISUAL CONTROLS • MANAGE FLOW (PROCESS)
- 92.
- 93. Question What percentageof features are never used?
- 94. Waste and theDelay 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.
- 96.
- 97. © Warp andByte Designs, In Successful teams Collaborate Shared accountability Shared approach to doing work Shared history
- 98. © Warp andByte Designs, Inc..
- 99.
- 100. Agile Feedback –Small Increments 100 No feedback Desired Delivered With feedback Desired Delivered
- 101.
- 102.
- 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 mostimportant half first standard development sequence More important Less important
- 105. do the mostimportant 25% first standard development sequence More important Less important
- 107. First Release Investment Period Payback Period Profit Period Breakeven Cashflow Time economics ofresponsiveness Mark Denne and Jane Cleland-Huang, Software by Numbers.
- 108.
- 109. Staged Releases Profit Period Second Release Invest- ment Period Pay- back Period Release 2Net Return Cashflow Time Release 1 Net Return
- 110.
- 111.
- 112. Cashflow Breakeven Single Release First Release Time Staged Releases 10 Whencompetition is intense
- 113.
- 114. Request 1/Team 1 Request2/Team 2 Request 3/Team 3 A Harder ProblemSCENARIO B another way to think of it
- 115. Request 1 Request 2 Request3 A Harder ProblemSCENARIO B try this: quicker feedback
- 116. Project 1 Project 2 Project3 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.
- 119. Efficiency H o wd 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.
- 122. Technical Versus Business Technical Inside – Components –Architect Business – Outside
- 123. Risks – whatare there? © Warp and Byte Designs, Inc..
- 124. Observation Anticipation oflong 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 Continuallyevolving 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