Kanban: Thinking Outside The Time Box

Kanban Thinking Outside the TimeBox

Puzzle: Looking In From the Outside Two Organizations: Org A: Release every week and every month: 64 times per year Org B: Release every second Wednesday Are they both Agile? Do they use the same or different processes? Does is matter? Copyright (c) Norbert Winklareth

Demo: Setup Need 9 volunteers 1 CEO, 4 Managers, 4 Workers CEO picks the Managers and Workers Management gets the stop watches Workers flip 20 coins Each Manager times their worker The CEO times the entire process The process is run 3 times with different batch sizes Copyright (c) Norbert Winklareth

DEMO First Round – flip all 20 coins and then pass them to the next person Second Round – flip 5 coins and then pass them to the next person, repeat until all coins have been passed Third Round - flip 1 coin and then pass them to the next person, repeat until all coins have been passed Copyright (c) Norbert Winklareth

Usage of the word Kanban From Chinese, meaning to see board Described how Chinese people got their news, posted on boards Japanese used it in manufacturing, to mean: A board with a model of process state on it A card or token used to signal when something is to occur, used to implementation a pull system, or Just-In-Time manufacturing process In Software Development: "kanban" (small "k") - a sign or physical token "kanban system" (small "k") - a token based, WIP limited pull system "Kanban" (big "K") - a change management approach that employs a WIP limited pull system* * The WIP limited pull system can be any of a family including CONWIP, kanban, DBR, CapWIP (or other variants) It is in the Lean family of techniques Copyright (c) Norbert Winklareth

History of Kanban Q3 2004 – Microsoft’s XIT Sustained Engineering Small team Supports over 80 applications (and growing) Engineering responsibilities moved from Redmond (Washington, USA) to Hyderabad (India) in 2004 Hyderabad vendor is CMMI Level 5 and uses TSP/PSP Initial quality is very high Backlog is 80+ and growing about 20 per quarter Lead time is 155 days Customer satisfaction – lowest in Microsoft’s IT department Copyright (c) Norbert Winklareth

History of Kanban, Continued XIT Manager Approaches David Anderson, they create 4 changes based on Drum-Rope-and-Buffer scheduling mechanism By November 2005: Backlog has been decreased to zero Most requests handled in less than 5 days Rated best IT department in Microsoft March 2006 – Bret Dodd and Sterling Mortensen of HP Printer Division report on impact of decreasing WIP Approach used based on talk David gave about initial XIT Team improvements in mid 2005 3.4 times productivity improvement 2 times improvement in Quality Reduced lead time from 9 months to 2 months Same people and no new money and they work 40 hour weeks March 2006, David meets Donald Reinertsen Reinertsen tells him to go all the way to a true pull system Copyright (c) Norbert Winklareth

History of Kanban, Continued September 2006 – David joins Corbis as Senior Director for Software Engineering Situation at Corbis: Interval between major releases was 3 months and growing New major projects were large, some planned to take 18 months Sustaining process was funded by Governance committee providing 10% more headcount in relevant functions Goal was to deliver a minor release (or upgrade) every 2 weeks By early September 2006 there hadn’t been a sustaining release for 2 months A dedicated maintenance team was not viable given the wide range of systems and the specialist nature of business and technical resources required Sustaining effort had to pull from a floating pool of resources working on major projects Sustaining work had to be scheduled around major project work Middle-management needed to show that the 10% funded resources were being utilized on sustaining work Line management, individual contributors and middle managers spent up to 2 weeks negotiating a plan for a release Transaction costs of negotiating scope and developing a schedule for each release was onerous Implication was that 50% capacity was being burned on transaction costs Impact was extending beyond 10% or resources and reducing productivity on major projects Sustaining releases were not happening regularly Copyright (c) Norbert Winklareth

History of Kanban, Continued October 2006, David wants stability so has the team focus on quality, while he learns and figures out his next move They had zero released defects starting January 2007 February 2007 – David introduces Kanban Board and results in: More personal responsibility and accountability Better visual control Enabled more self-organization Less management supervision Better productivity Spontaneous quality circles and frequent Kaizen events March 2007 – David blogs about his approach Copyright (c) Norbert Winklareth

History of Kanban, Continued Agile 2007, Open Space Kanban event attracted 25 people September 2007 – Aaron Sanders of Yahoo discusses his Naked Planning approach to Kanban Used by 3 different teams, on 3 different continents at Yahoo November 2007 – David talks about significantly improved performance and quality, zero released defects June 2008 – I start an XP team using Kanban so that a company critical release can go out on time (Personal Note, not a historically important event) Management needed to respond to changes on a hourly basis, which breaks the sprint commitment January 2009, Corey Ladas published Scrumban a book about transforming a Scrum team into a Kanban one Copyright (c) Norbert Winklareth

History of Kanban, Continued May 2009 – Donald Reinertsen’s latest book is published The Principles of Product Development Flow Shows the science behind Kanban and other development methodologies May 2009 – First annual Lean Kanban Conference held Lots of interesting talks, available from the site. October 2009 – David Joyce posts 3 blogs about improved results of using Kanban at the BBC including use of Statistical Control Charts! November 2009 – Henrik Kniberg and Mattias Skarin release book: Kanban and Scrum: Making the most of both Spring 2010 – David Anderson book to be published: Kanban: Successful Evolutionary Change for Technology Organizations I have read it. It is very good and I recommend it Copyright (c) Norbert Winklareth

Adopters of KanBan BBC is best known adopter with more than 10 teams in London using Kanban Other adopters include: Software Engineering Professionals (Indianapolis), BNP Parisbas (London), IPC Media (London), Robert Bosch Yahoo A small group at Deloitte, here in Ottawa … . In all adopters span 5 continents Copyright (c) Norbert Winklareth

Why people are using it Frustrated with: Having to artificially break stories up to fit into a Sprint Waste associated with Sprint planning and retrospectives, especially for artificial stories Having to create estimates Do not want to make radical organizational changes Cost of change judged to be too high Iterations not a fit for the culture Specialists involved and they cannot be split across teams Business needs: To make changes more quickly than the length of an iteration Better resource planning and usage Copyright (c) Norbert Winklareth

How to do it the first time Copyright (c) Norbert Winklareth Flow: from Engineering Release to Production Model & Visual Control WIP Limits Pull

How to do it the first time, continued Visualize the workflow (Value Stream Mapping) Model of the macro states work goes through in development Columns represent the states Cards represent the work and move through the model Limit WIP (work in progress) assign explicit limits to how many items may be in progress at each workflow state Copyright (c) Norbert Winklareth

What to measure the first time Cycle time Record work item start and end dates Blocked item time When WIP limits are broken Later, add more as your understanding deepens and as needed Copyright (c) Norbert Winklareth

Establish a Release Cadence This is where release is decoupled from development Release and development are asynchronous processes What ever has been completed since the last release is pushed out Provides planning mechanism without the artificialness that iterations imposes Builds customer trust, new value appearing at regular intervals Just as traditional Agile Methodologies do Copyright (c) Norbert Winklareth

Improve Cycle Time Strive to make cycle time predictable, within statistical limits Now work on having the Team shortening it What is being observed is Team members spontaneously doing this They use the visual model to guide their improvement efforts Copyright (c) Norbert Winklareth

Why it works Copyright (c) Norbert Winklareth Tasks to be done. Active Tasks (WIP) Completed Tasks, (the purpose of the system is to complete as many of these as possible per unit of time) Lead Time Cycle Time (CT) Product Development is Queuing System and it works independent of iterations Little’s Law applies and it says LT = WIP / CT Easiest way to reduce LT is to reduce number of Active Tasks, which improves Total Lead Time

Why it works, continued Product Development at the macro level is a Queuing System Queuing systems work independently of whether iterations are used or not Reducing WIP: Reduces waiting time for new work Improves quality , which means less rework, some companies spend upwards of 90% time fixing defects WIP is an instantaneous measure, while cycle time, lead time and velocity are trailing measures Following WIP means one can spot and address dynamically occurring problems Decreasing cycle time, increases amount of throughput Product Development systems are composed of multiple queues Individual WIP limits for these queues provides management mechanism for them Visualization of the System is a feedback mechanism Immediate indication of where a dynamic problem is occurring Supports decentralized command and problem swarming Provides a better way of looking at improvements Copyright (c) Norbert Winklareth

Observations from using Kanban Spontaneous or as needed Kaizen activities by team members On going improvements to the process and models used for visual control Better business discussions and decisions about what should be built and when Improved moral and feeling of ownership by the development team Improved throughput Higher quality Less release plan guesstimating Copyright (c) Norbert Winklareth

Observations from using Kanban JIT feature planning allows decision making process to have gather more information before committing Better risk management Less management involvement in day to day activities More time to focus on larger issues Daily stand up meetings of up to 50 people and finished in 15 minutes Exposes upstream and downstream of development issues that needs to be addressed Non development teams see merit in Kanban Copyright (c) Norbert Winklareth

Criticisms of Kanban It’s not Agile Wrong, organizations are able to deliver value rapidly, in many cases faster than the Agile Methodology they were previously using It’s mini-Waterfall Possibly true, depends on how the organization has specified their process And so what, see point above Too many hand-offs Possibly and the team is free to change and reduce that Remember that whether to have a handoff is a trade-off and therefore a control point Work items are too variable in size and decisions about scheduling them happen too late Variability is a reality and as Reinertsen points out, it is the source of value Many Kanban teams break up big work items into smaller ones to handle this problem, Expansion/Contraction pattern As well complexity theory guarantees that there will be stories that do not fit into an iteration Despite being partitioned, still only releasing a feature So assembly is necessary Copyright (c) Norbert Winklareth

Criticisms of Kanban, continued Retrospectives are not part of the process True, Kanban is a tool for creating processes and most teams using are found to do them as need arises Nothing prevents the organization from scheduling regularly ones It’s Process over People No, it gives people a better means of developing processes that match how they need to work and a better way of working within those processes Any methodology/technique can be abused It does not support self-organizing teams Yes it does, see process over people item above It’s inefficient No its not, from Queuing Theory, and if it is, show me the math or a model that substantiates this claim It does not address the cross-training issue So what, no other methodology explicitly does either This is an organizational issue, you want it, then set a goal for it Copyright (c) Norbert Winklareth

Advanced techniques Cumulative Flow Charts Statistical Control Charts Two-tier Boards Handling Multiple Projects: Swimlanes Classes of Service Improvements by governance changes Feature Injection Copyright (c) Norbert Winklareth

Cumulative Flow Charts Copyright (c) Norbert Winklareth Cycle Time WIP Cumulative Flow

Statistical Control Charts Copyright (c) Norbert Winklareth

Two-tier Boards Copyright (c) Norbert Winklareth Features in Development Their Stories

Handling Multiple Projects: Swimlanes Copyright (c) Norbert Winklareth

Classes of Service Different colour cards indicate different classes of service Each class has its own limits, that must fit into limits of a state That is why more yellow cards then others Business owners decide which class an item goes into Emergency expedite class, means drop everything and do this Never used at Corbis. When they tried the other business owners said cost to their projects was just too great, Silver coloured Post-It note not shown This resulted in better co-operation among business owners on prioritizing development of the different business lines Copyright (c) Norbert Winklareth

Improvements by governance changes Change the WIP limits changes the behaviour: Exposes underlying issues or Requires development of new workflow/practices Require more cross-training Set higher quality standards What to do with blocked items? Defects found in production? Defects found within development process? Cross training? ... Copyright (c) Norbert Winklareth Use them and be frugal, not too many!

Feature Injection A way to pull requirements developed by Chris Matts of Real Options fame, this is talk on its own, if interested see: http://www.limitedwipsociety.org/tag/feature-injection/ Real Options a very powerful and simple risk management and decision making process, see, http://www.infoq.com/articles/real-options-enhance-agility The comments on this article contain a lot of good information Copyright (c) Norbert Winklareth

Some General Observations Don’t try to make the initial model perfect Expect the model and board to change There is a problem if it does not Do not make the model too detailed Introduces too much process and too many paths, arguably cannot be done completely Team members handle this really well without having to make it explicit Pull systems scale differently then Agile ones Typically better WIP limits are your friend Learn to use and understand them well Management needs to enforce the WIP limits Do not allow new work to start if the limit at a stage has been reached Product Development is a dynamic system, there will be randomly occurring bottlenecks They should be solved by the team If not then your WIP limits are too high Be aware that this is natural phenomenon and you cannot solve it Copyright (c) Norbert Winklareth

Why no discussion of Quality Let me repeat, reducing WIP improves quality This is a repeatedly observed phenomenon There are some credible hypothesis and none that have been validated As well, using the Kanban technique really highlights the cost of handling defects to the team and observed behaviour is that they change their work practices to prevent them from occurring Copyright (c) Norbert Winklareth

5 Core Properties Limit WIP Visualize process workflow Measure & manage flow Make process policies explicit Use models** to recognize improvement opportunitie s ** popular models currently include Theory of Constraints, Lean Waste, Deming's Theories regarding Variation, & Real Option Theory 5 Emergent Properties Prioritize work by (opportunity) cost of delay Optimize value delivery with classes of service Spread risk with capacity allocation Encourage process innovation Manage quantitatively Kanban : Current Working Definition* Copyright (c) Norbert Winklareth * Based on posting to Yahoo kanbandev mailing list by David Anderson, 2010/02/08

Puzzle: Answers Two Organizations: Org A: Release every week and every month: 64 times per year PatientKeeper, using Scrum, specfically Class C Scrum Org B: Release every second Wednesday Corbis, using Kanban Are they both Agile? Yes Do they use the same or different processes? Does is matter? Different and to their customers no Copyright (c) Norbert Winklareth

DISCUSSION Copyright (c) Norbert Winklareth

APPENDIX Copyright (c) Norbert Winklareth

Books, some partially, about Kanban Scrumban: Essays on Kanban Systems for Lean Software Development by Cory Ladas Scaling Lean & Agile Development by Craig Larman & Bas Vodde They criticize Kanban for allowing too much variability, other then that it is a pretty good book Kanban and Scrum: making the best of both by Henrik Kniberg & Mattias Skarin, http://www.infoq.com/minibooks/kanbanscrum-minibook Leading Lean Software Development: Results Are not the Point by Mary and Tom Poppendieck Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Jim Trott and Guy Beaver Kanban: Successful Evolutionary Change for Technology Organizations by David Anderson (Not yet published) Copyright (c) Norbert Winklareth

Some URLs to get you started http://www.limitedwipsociety.org/ This site for trying to build up the value of the underlying principles and have it separate from the brand Kanban http://www.kanban101.com/ A site to make it easy to get started with Kanban http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html Very good and broad introduction to Kanban and the rational for it from an agile product design specialist http://availagility.co.uk/2008/10/28/kanban-flow-and-cadence/ Very good overview on these three points http://www.infoq.com/presentations/kanban-at-sep Good presentation on how Kanban is tool for team based process change http://leanandkanban.wordpress.com/ David Joyce’s blog about his experiences at BBC http://www.agilemanagement.net/index.html David Anderson’s site, unfortunately he is not blogging much these days http://miami2009.leanssc.org/speaker-presentations/ Videos and presentation from First Kanban conference Copyright (c) Norbert Winklareth

Credits Talk title from Mark Baker http://www.analecta.com/ Coin Game created by George Dinwiddie Kanban board pictures used with permission from David Anderson http://www.djandersonassociates.com/ Statistical Control Chart used with permission from David Joyce, http://leanandkanban.wordpress.com/ Copyright (c) Norbert Winklareth

Contact Info Norbert Winklareth [email_address] Copyright (c) Norbert Winklareth

Kanban: Thinking Outside The Time Box

More Related Content

What's hot (20)

Similar to Kanban: Thinking Outside The Time Box (20)

Recently uploaded (20)

Kanban: Thinking Outside The Time Box

Editor's Notes