Intro to Kanban - AgileDayChile2011 Keynote

9,379 views

Published on

Keynote from Dabid J. Anderson (@agilemanager) on AgileDayChile 2011, november 17 2011

Published in: Technology, Business
1 Comment
36 Likes
Statistics
Notes
No Downloads
Views
Total views
9,379
On SlideShare
0
From Embeds
0
Number of Embeds
567
Actions
Shares
0
Downloads
0
Comments
1
Likes
36
Embeds 0
No embeds

No notes for slide
  • 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.
  • Intro to Kanban - AgileDayChile2011 Keynote

    1. An Introduction to Kanban What is it & why would I use it? David J. Anderson David J. Anderson & Associates dja@djandersonassociates.com
    2. Book Published April 2010 A 72,000 word intro to the topic
    3. Germanpublished January, 2011 Translation by Arne Roock & Henning Wolf of IT-Agile
    4. Spanishpublished May 2011 Translated by Masa K Maeda, PhD
    5. Portuguese (Brazilian)published October 2011 Translation by Andrea Pinto Recife, Brazil
    6. http://leankanbanuniversity.comhttp://www.limitedwipsociety.org LinkedIn Groups: Software Kanban Yahoo! Groups: kanbandev Yahoo! Groups: kanbanops
    7. Taiichi Ohno… TPS = JIT + AutonomationKanban is the tool that enables these
    8. What is a kanban (pull) system?
    9. An example of a 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 DaysManagers
    10. We started visualizing these flows on white boards and holding standup meetings in front of it Provides the 1st (team) level of process capability feedback
    11. WIP limits create a 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
    12. Queue Replenishment & delivery run on independently determined cadenceQueueReplenishment Delivery CadenceHow often can we How often canreasonably meet with customers (orbusiness downstream functions)stakeholders? economically take delivery?
    13. 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
    14. We discovered that standup 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.
    15. Major Project with two-tiered kanban board using swim lanes for each development team Swim lanes control WIP limit – Requirement WIP (green) controlled by number of lanes
    16. Monthly Operations Review using quantitativemeasures of capability & demand provides the 2nd (organization) level of process feedback
    17. “After Meetings” after stand-ups to focus on immediate process issues
    18. Why do we pursue process improvements at all?
    19. Goals for improvement initiatives Economically balance capability against demand
    20. Available options Process
    21. Most processgeeks & ITmanagers areoperating overhere Process
    22. Agile methods have been the favorite approach to improving capability in the 21st Century!
    23. However, some people &organizations have resisted adoption of Agile methods!
    24. If not every organization is ready to adopt an Agilemethod, how can we encourage them to become more Lean?
    25. Kanban is the gateway to a Lean organization
    26. So how do we go aboutintroducing Lean into organizations that have failed to adopt an Agile method such as TDD?
    27. The counter-intuitive answer is to use a pull system that limits work-in-progress to catalyze the introduction of other Lean concepts
    28. So What is the Kanban Method?
    29. My motivation for adopting kanban systems was to prevent overburdening, & control variability that affects flow and encourage an evolutionary approach to change
    30. In developing the Kanban Method, achange management approach that uses kanban systems to provoke change, we are enabling the emergence of Lean software development in organizations
    31. How does theKanban Method work?
    32. Kanban is based on 3 principles1. Start with what you do now2. Agree to pursue incremental, evolutionary change3. Initially, respect current roles, responsibilities & job titles
    33. Then… then adopt 5 core practices that are observed to be present in successful Kanban implementations
    34. 5 core practices for successful Kanban adoption Shallow1. Visualize2. Limit Work-in-Progress Depth3. Manage Flow4. Make Process Policies Explicit5. Improve Collaboratively (using models & scientific method) Deep
    35. It‟s not a question of right orwrong … Shallow It‟s a question of shallow or deep! Depth Shallow implementations tend to produce fewer, less dramatic results Deep
    36. When…When all 5 core 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
    37. Visualize Workflow
    38. Limit Work-in-Progress20 3 2 4
    39. Observe Flow (empty test column)
    40. Observe Flow with a 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
    41. From the simple geometry we can observe Little‟s Law WIPThroughput = Lead Time From observed capability
    42. Observe Lead Time with acontrol chart
    43. Observe Flow with a 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 ofMean of 51 days with 98% on-time31 days SLA expectation of 44 days with 85% on-time
    44. Development is a BottleneckThis is an example of using amodel to identify animprovement opportunity
    45. Analysis is overloadedAnalysis suffers from non-instantavailability of subject matterexperts / business owners
    46. Couple observation of non-instant availability of expertisewith visual & quantitativeevidence of muri in flow toencourage better availability
    47. Conversation & Leadership
    48. Leadership is the magicingredient sprinkle liberally over the 5 seed properties
    49. The WIP limit provokes theconversation
    50. Without a WIP limit the Idle &Stuck comments may neveremerge
    51. The team has a choice to breakthe WIP limit and ignore theissues, or face up to the issuesand address them using themodels
    52. The WIP limit simply provokes theconversation.Leadership encourages discussion aboutimprovement. Use of Models and otherevidence leads to an improvementsuggestion and implementation
    53. Big Projects with Kanban
    54. Major Project with two-tiered kanban board using swim lanes for feature sets Swim lanes control WIP limit – Requirement WIP (green) controlled by number of lanes
    55. Kanban daily standup meetings 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
    56. Spontaneous Quality Circles form 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.
    57. Sticky Buddy scheme was 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.
    58. Estimating andplanning major projects
    59. Cumulative Flow and Predictive Modeling with S-Curve Device Management Ike II Cumulative Flow 240 220 200 180 160Features 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
    60. Simulating S-Curve with a Z Device Management Ike II Cumulative Flow 240 220 60% 200 180 160 Slope in middleFeatures 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
    61. Track actual throughput against 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
    62. 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 settingOften velocity exhibits a +/-2x spread of variation As a result velocity cannot be used as a short- term planning tool See following examples
    63. Velocity VariationSouth African Team from 2011plotted per Sprint (2 weekly)Mean 29, UCL (+1 sigma) 43 (+1.5x), LCL (-1 sigma) 15 (- 2x)
    64. DBA Team Velocity908070 Trend6050 Total Velocity Small support tasks403020 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)
    65. Investment Bank, London, Extreme ProgrammingWeekly Mean 10, Max = 16, Min = 6Spread (+/- 1.6x)
    66. Velocity Control Charts Completion Velocity Chart 40 30 UCL 29.2 20 CompletionCompletion 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)
    67. Variability in scope/requirementsIt is also important to realize how much variability there is in the scope/scale or requirementsand how this must be accommodated in our plans
    68. Unplanned Work Report Scope Creep Dark Matter (emergent features) Original ScopeDark matter planned as a 19% expansion over original scopeActual Dark Matter over final original scope is 26%Total scope compared to original commitment is 13% greater
    69. Typical Agile teams using User Stories analysis produce 40-60% dark matterStories are recognized as Epics and broken into more stories. The customer does not consider the scope to have changed
    70. TV/Movie Company in USA 2008Initial Scope is 125 story pointsWithin days this total scope reaches 190 due to dark matter expansionManagement intervened on 4/21 to stop dark matter (deferring future scopeto product backlog)Observed dark matter expansion is 52% but real number was much greater
    71. Original CFD shows same top line Dark matter quotient is 19% Device Management Ike II Cumulative Flow 240 220 200 180 160Features 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
    72. Make a long term plan to build platform replacement Device Management Ike II Cumulative Flow Required throughput (velocity) 240 220 200 180 160Features 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
    73. Little‟s Law Determines staffing levelTarget to achieve plan WIP Throughput = Lead Time From observed capability Treat as Fixed variable
    74. Changing the WIP limit without maintaining the staffing level ratiorepresents a change to the way of working. It is a change to thesystem design. And will produce a change in the observed „common cause‟ capability of the system
    75. Plan based on currently observed capability and current workingpractices. 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
    76. Little‟s Law Determines staffing levelTarget 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
    77. Opportunities for Improvement
    78. Educate the workforce torecognize process problems that affect performance
    79. Manage bottlenecks to increase throughputKnown 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 Schedule1. Identify - Current CCR is System Test – 30 through this system? per month2. Exploit - Testers relieved of all non-essential tasks, extra PMs assigned to complete administrative tasks, analysts assigned to future test plans3. Subordinate - Requirements release restricted to ~30 per month Quality4. Elevate - Plan to recruit temporary testing staff immediately Schedule
    80. 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
    81. Wimbledon comes in on time every year How do event planners do it?Scheduling Wimbledon isn’t an exactscience 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!
    82. Quantity of pink issue 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
    83. Focusing on efficiency produces better cost accounting results for large batch sizes
    84. But there are also coordination costs in knowledge work problems Communication Queue Task W Queue Task WaitSetup Cleanup Queue Task Wait Q Task Wait Time
    85. And in knowledge work 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
    86. Sources of Economic Costs  Transaction Costs  Coordination Costs  Failure Demand
    87. Transaction Coordination Costs Transactioncost Costs Costs Value-added Work Failure Demand time
    88. GoodBad
    89. Conclusions
    90. Limiting work-in-progress cancatalyze incremental changes
    91. respectThe team must the WIP limit and value the conversations it provokes about problems
    92. Leadership is the secretsauce! Encourage it from any team member regardless of position, experience or authority
    93. Enable the team with transparency of process (visualization of invisiblework & process dynamics.) Use models for understanding problems and improvements will occur.
    94. These improvements will providebetter economic and sociological outcomes
    95. Enabling our goal to… Economically balancecapability against demand
    96. Thank you! dja@agilemanagement.nethttp://www.agilemanagement.net/
    97. About…David Anderson is a thought leader inmanaging effective software teams. He leadsa consulting firm dedicated to improvingeconomic performance of knowledge workerbusinesses – improving agility, reducingcycle times, improving productivity andefficiency in technology development.He has 25+ years experience in the softwareindustry starting with computer games in theearly 1980‟s. He has led software teamsdelivering superior productivity and quality usinginnovative agile methods. He developed MSFfor 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 SoftwareEngineering – Applying the Theory ofConstraints for Business Results, introducedmany ideas from Lean and Theory ofConstraints into software engineering.David was a founder of the Lean Software &Systems Consortium, a not for profit dedicatedto promoting better standards of professionalismand effectiveness in software engineering.Email… dja@agilemanagement.net

    ×