Uploaded byChileAgil
Intro to Kanban - AgileDayChile2011 Keynote
This document provides an introduction to Kanban, including what it is, why it would be used, and its origins and principles. Kanban is a pull-based system that uses visualization techniques like boards and limits on work-in-progress to regulate flow. It originated from the Toyota Production System and can be overlaid on software development processes. The document outlines how Kanban was implemented at one company and discusses scaling Kanban to larger projects. It also explains how Kanban encourages continuous improvement through evolutionary changes and how these principles form the Kanban Method for adopting Lean practices.
More Related Content
Similar to Intro to Kanban - AgileDayChile2011 Keynote
![Governance, Deployment & Methodologies for Agentic Automation [2/3]](https://cdn.slidesharecdn.com/ss_thumbnails/agenticcommunityseries-day2-251112135038-a386476d-thumbnail.jpg?width=640&height=640&fit=bounds)
Intro to Kanban - AgileDayChile2011 Keynote
- 1. An Introduction toKanban What is it & why would I use it? David J. Anderson David J. Anderson & Associates [email protected]
- 2. Book Published April 2010 A 72,000 word intro to the topic
- 3. German published January, 2011 Translation by Arne Roock & Henning Wolf of IT-Agile
- 4. Spanish published May 2011 Translated by Masa K Maeda, PhD
- 5. Portuguese (Brazilian) published October2011 Translation by Andrea Pinto Recife, Brazil
- 6. http://leankanbanuniversity.com http://www.limitedwipsociety.org LinkedIn Groups:Software Kanban Yahoo! Groups: kanbandev Yahoo! Groups: kanbanops
- 8. Taiichi Ohno… TPS = JIT + Autonomation Kanban is the tool that enables these
- 9. What is akanban (pull) system?
- 10. An example ofa virtual kanban system overlaid on a software development process PTC Eng Mgr Change PM Requests Developers Testers Kanban Kanban 8 cards 8 cards (3 WIP 5 Queue) User Acceptance Test Product Backlog 25 Days Managers
- 11. We started visualizingthese flows on white boards and holding standup meetings in front of it Provides the 1st (team) level of process capability feedback
- 12. WIP limits createa pull system and white board provides visualization of flow WIP Limit – regulates “inventory” at each stage in the process Pull Flow – from Engineering Ready to Release Ready
- 13. Queue Replenishment &delivery run on independently determined cadence Queue Replenishment Delivery Cadence How often can we How often can reasonably meet with customers (or business downstream functions) stakeholders? economically take delivery?
- 14. Colors represent classes of service Expedite Fixed Delivery Date Significant delay incurred on or from a specific date in near future Standard Class (Near) linear cost of delay beginning immediately Intangible Class No tangible cost of delay within reasonable lead time to delivery window
- 15. We discovered thatstandup meetings could be scaled to a large size In this example more than 40 people attend a standup for a large project with 5 concurrent development teams. The meeting is usually completed in approximately 10 minutes. Never more than 15.
- 16. Major Project withtwo-tiered kanban board using swim lanes for each development team Swim lanes control WIP limit – Requirement WIP (green) controlled by number of lanes
- 17. Monthly Operations Reviewusing quantitative measures of capability & demand provides the 2nd (organization) level of process feedback
- 18. “After Meetings” afterstand-ups to focus on immediate process issues
- 19. Why do wepursue process improvements at all?
- 20. Goals for improvementinitiatives Economically balance capability against demand
- 21. Available options Process
- 22. Most process geeks &IT managers are operating over here Process
- 23. Agile methods havebeen the favorite approach to improving capability in the 21st Century!
- 24. However, some people& organizations have resisted adoption of Agile methods!
- 25. If not every organization is ready to adopt an Agile method, how can we encourage them to become more Lean?
- 26. Kanban is thegateway to a Lean organization
- 27. So how dowe go about introducing Lean into organizations that have failed to adopt an Agile method such as TDD?
- 28. The counter-intuitive answeris to use a pull system that limits work-in-progress to catalyze the introduction of other Lean concepts
- 29. So What isthe Kanban Method?
- 30. My motivation for adopting kanban systems was to prevent overburdening, & control variability that affects flow and encourage an evolutionary approach to change
- 31. In developing the Kanban Method, a change management approach that uses kanban systems to provoke change, we are enabling the emergence of Lean software development in organizations
- 32. How does the KanbanMethod work?
- 33. Kanban is basedon 3 principles 1. Start with what you do now 2. Agree to pursue incremental, evolutionary change 3. Initially, respect current roles, responsibilities & job titles
- 34. Then… then adopt 5 core practices that are observed to be present in successful Kanban implementations
- 35. 5 core practicesfor successful Kanban adoption Shallow 1. Visualize 2. Limit Work-in-Progress Depth 3. Manage Flow 4. Make Process Policies Explicit 5. Improve Collaboratively (using models & scientific method) Deep
- 36. It‟s not aquestion of right or wrong … Shallow It‟s a question of shallow or deep! Depth Shallow implementations tend to produce fewer, less dramatic results Deep
- 37. When… When all 5core practices are adopted they form the seed conditions for complex Kanban as a adaptive system that enables a Lean(er) way of working to emerge
- 39.
- 40.
- 41. Observe Flow (emptytest column)
- 42. Observe Flow witha CFD Device Management Ike II Cumulative Flow 240 220 200 180 160 Features 140 120 Avg. Lead Time 100 80 60 WIP Avg. Throughput 40 20 0 ar ar eb eb eb ar ar ar M M -M -M -M -F -F -F 2- 9- 10 17 24 16 23 30 Time Inventory Started Designed Coded Complete
- 43. From the simplegeometry we can observe Little‟s Law WIP Throughput = Lead Time From observed capability
- 44. Observe Lead Timewith a control chart
- 45. Observe Flow witha spectral analysis histogram of lead time Lead Time Distribution 3.5 3 2.5 CRs & Bugs 2 1.5 1 0.5 0 6 3 0 7 4 1 8 1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 10 11 12 12 13 14 14 Days SLA expectation of Mean of 51 days with 98% on-time 31 days SLA expectation of 44 days with 85% on-time
- 46. Development is aBottleneck This is an example of using a model to identify an improvement opportunity
- 47. Analysis is overloaded Analysissuffers from non-instant availability of subject matter experts / business owners
- 48. Couple observation ofnon- instant availability of expertise with visual & quantitative evidence of muri in flow to encourage better availability
- 49.
- 50. Leadership is themagic ingredient sprinkle liberally over the 5 seed properties
- 51. The WIP limitprovokes the conversation
- 52. Without a WIPlimit the Idle & Stuck comments may never emerge
- 53. The team hasa choice to break the WIP limit and ignore the issues, or face up to the issues and address them using the models
- 54. The WIP limitsimply provokes the conversation. Leadership encourages discussion about improvement. Use of Models and other evidence leads to an improvement suggestion and implementation
- 55. Big Projects withKanban
- 56. Major Project withtwo-tiered kanban board using swim lanes for feature sets Swim lanes control WIP limit – Requirement WIP (green) controlled by number of lanes
- 57. Kanban daily standupmeetings can be very large In this example more than 40 people attend a standup for a large project with 5 concurrent development teams. The meeting is usually completed in under 15 minutes
- 58. Spontaneous Quality Circlesform after the standup to focus on immediate process issues Daily standup provides forum for spontaneous association to attack process issues affecting productivity and lead time 3 day freeze on test environ was a transaction cost on release that caused a bottleneck at “build” state. Reduced to 24 hrs. Result was improved smoother flow resulting in higher throughput and shorter lead time.
- 59. Sticky Buddy schemewas instituted to allow remote workers to keep kanban board up-to-date and synchronized with electronic tracking “Cancelled” area With trash can For partially worked Items obe.
- 60. Estimating and planning major projects
- 61. Cumulative Flow and Predictive Modeling with S-Curve Device Management Ike II Cumulative Flow 240 220 200 180 160 Features 140 Typical S-curve 120 100 80 60 40 20 0 ar ar eb eb eb ar ar ar M M -M -M -M -F -F -F 2- 9- 10 17 24 16 23 30 Time Inventory Started Designed Coded Complete
- 62. Simulating S-Curve witha Z Device Management Ike II Cumulative Flow 240 220 60% 200 180 160 Slope in middle Features 140 3.5x - 5x slope 120 100 at ends 5x 80 60 20% 20% 40 20 0 ar ar eb eb eb ar ar ar M M -M -M -M -F -F -F 2- 9- 10 17 24 16 23 30 Time Inventory Started Designed Coded Complete
- 63. Track actual throughputagainst projection Device Management Ike II Cumulative Flow 240 220 200 180 160 Features 140 120 100 80 Track delta between 60 40 planned and actual 20 each day 0 ar ar eb eb eb ar ar ar M M -M -M -M -F -F -F 2- 9- 10 17 24 16 23 30 Time Inventory Started Designed Coded Complete
- 64. Variability in Throughtput(velocity) It is important to understand the role throughput plays in long term planning in Kanban but why it is not useful for short-term goal setting Often velocity exhibits a +/-2x spread of variation As a result velocity cannot be used as a short- term planning tool See following examples
- 65. Velocity Variation South AfricanTeam from 2011plotted per Sprint (2 weekly) Mean 29, UCL (+1 sigma) 43 (+1.5x), LCL (-1 sigma) 15 (- 2x)
- 66. DBA Team Velocity 90 80 70 Trend 60 50 Total Velocity Small support tasks 40 30 20 Trend (not included in total velocity) 10 Week of Christmas 0 Mattias Skarin client based in Paris in 2009/2010, plotted weekly Mean 42, +1 sigma = 55, -1 sigma = 29 (+/- 1.4x)
- 67. Investment Bank, London,Extreme Programming Weekly Mean 10, Max = 16, Min = 6 Spread (+/- 1.6x)
- 68. Velocity Control Charts Completion Velocity Chart 40 30 UCL 29.2 20 Completion Completion Velocity Velocity UCL 10 CL 7.206896552 Sigma +2 +1 Sigma 0 -10 LCL -14.8 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 -20 Date Motorola PCS 2003, FDD project plotted Daily Mean 7.2, +1 sigma = 15, -1 sigma = 0 (+/- 2x) Weekly Mean 36, +1 sigma = 63, -1 sigma = 11 (+ 1.7x, -3.3x)
- 69. Variability in scope/requirements Itis also important to realize how much variability there is in the scope/scale or requirements and how this must be accommodated in our plans
- 70. Unplanned Work Report Scope Creep Dark Matter (emergent features) Original Scope Dark matter planned as a 19% expansion over original scope Actual Dark Matter over final original scope is 26% Total scope compared to original commitment is 13% greater
- 71. Typical Agile teamsusing User Stories analysis produce 40-60% dark matter Stories are recognized as Epics and broken into more stories. The customer does not consider the scope to have changed
- 72. TV/Movie Company inUSA 2008 Initial Scope is 125 story points Within days this total scope reaches 190 due to dark matter expansion Management intervened on 4/21 to stop dark matter (deferring future scope to product backlog) Observed dark matter expansion is 52% but real number was much greater
- 73. Original CFD showssame top line Dark matter quotient is 19% Device Management Ike II Cumulative Flow 240 220 200 180 160 Features 140 120 100 80 Track delta between 60 40 planned and actual 20 each day 0 ar ar eb eb eb ar ar ar M M -M -M -M -F -F -F 2- 9- 10 17 24 16 23 30 Time Inventory Started Designed Coded Complete
- 74. Make a longterm plan to build platform replacement Device Management Ike II Cumulative Flow Required throughput (velocity) 240 220 200 180 160 Features 140 Slope in middle 120 3.5x - 5x slope 100 at ends 5x 80 60 40 20 0 2006 2008 ar ar eb eb eb ar ar ar M M -M -M -M -F -F -F 2- 9- 10 17 24 16 23 30 During the middle 60% of the project schedule Time we need Throughput (velocity) to average 13 Inventory Started Designed Coded Complete features per month
- 75. Little‟s Law Determines staffing level Target to achieve plan WIP Throughput = Lead Time From observed capability Treat as Fixed variable
- 76. Changing the WIPlimit without maintaining the staffing level ratio represents a change to the way of working. It is a change to the system design. And will produce a change in the observed „common cause‟ capability of the system
- 77. Plan based oncurrently observed capability and current working practices. Do not assume process improvements. If changing WIP to reduce undesirable effects (e.g. multitasking), get new sample data (perform a spike) to observe the new capability
- 78. Little‟s Law Determines staffing level Target to achieve plan WIP 13 / month = 0.25 months WIP = 3.25, round up to 4. Might be safe to From observed capability round down to 3. If current working practice is 1 unit WIP per person then 3 people are needed to work this project exclusively
- 79.
- 80. Educate the workforceto recognize process problems that affect performance
- 81. Manage bottlenecks toincrease throughput Known max productivity Idea Analysis Design Code ~90 ~80 ~50 ~50 Error Error Error Working Acceptance System Unit Code Test Test How do I trim 25% Test ~80 ~30 ~40 ~50 off the schedule for Quality a project going Schedule 1. Identify - Current CCR is System Test – 30 through this system? per month 2. Exploit - Testers relieved of all non-essential tasks, extra PMs assigned to complete administrative tasks, analysts assigned to future test plans 3. Subordinate - Requirements release restricted to ~30 per month Quality 4. Elevate - Plan to recruit temporary testing staff immediately Schedule
- 82. Non-instant Availability Looks like a bottleneck Same thinking process applies Management approach is similar but policies will be different depending on type of bottleneck CCR vs NIA
- 83. Wimbledon comes inon time every year How do event planners do it? Scheduling Wimbledon isn’t an exact science Except 2004 when it rained on Sunday and the final was on Monday ;-) Games last different lengths of time and weather conditions can stop play altogether but the Men’s Final always happens on the 2nd Sunday If only we could project manage like this!
- 84. Quantity of pinkissue tickets on board directly indicates flow impacting problems that need attention from management Issues are the exception – attached to work items that are blocked for external reasons and call attention to problems preventing smooth flow
- 85. Focusing on efficiencyproduces better cost accounting results for large batch sizes
- 86. But there arealso coordination costs in knowledge work problems Communication Queue Task W Queue Task Wait Setup Cleanup Queue Task Wait Q Task Wait Time
- 87. And in knowledgework problems, coordination costs grow non-linearly with batch size Communication Queue Task W Queue Task Wait Setup Cleanup Queue Task Wait Q Task Wait Time
- 88. Sources of EconomicCosts Transaction Costs Coordination Costs Failure Demand
- 89. Transaction Coordination Costs Transaction cost Costs Costs Value-added Work Failure Demand time
- 90.
- 91.
- 92. Limiting work-in-progress can catalyzeincremental changes
- 93. respect The team must the WIP limit and value the conversations it provokes about problems
- 94. Leadership is thesecret sauce! Encourage it from any team member regardless of position, experience or authority
- 95. Enable the teamwith transparency of process (visualization of invisible work & process dynamics.) Use models for understanding problems and improvements will occur.
- 96. These improvements willprovide better economic and sociological outcomes
- 97. Enabling our goalto… Economically balance capability against demand
- 99. Thank you! [email protected] http://www.agilemanagement.net/
- 100. About… David Anderson isa thought leader in managing effective software teams. He leads a consulting firm dedicated to improving economic performance of knowledge worker businesses – improving agility, reducing cycle times, improving productivity and efficiency in technology development. He has 25+ years experience in the software industry starting with computer games in the early 1980‟s. He has led software teams delivering superior productivity and quality using innovative agile methods. He developed MSF for CMMI Process Improvement for Microsoft. He is a co-author of the SEI Technical Note, CMMI and Agile: Why not embrace both! David‟s book, Agile Management for Software Engineering – Applying the Theory of Constraints for Business Results, introduced many ideas from Lean and Theory of Constraints into software engineering. David was a founder of the Lean Software & Systems Consortium, a not for profit dedicated to promoting better standards of professionalism and effectiveness in software engineering. Email… [email protected]
Editor's Notes
- #59 Kanban board gives visibility into process issues – ragged flow, transaction costs of releases.Daily standup provides forum for spontaneous association to attack process issues affecting productivity and lead timeFor ex: 3 day freeze on test environment was a transaction cost on release that caused a bottleneck at “build” state. Reduced to 24 hrs. Result was improved smoother flow resulting in higher throughput and shorter lead time.