Kanban: Thinking Outside The Time Box

KanbanThinking 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?

2Copyright (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

sizes3Copyright (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 4

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


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


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


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


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


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


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


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


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


How to do it the first time


Model&

Visual Control

WIP Limits

Flow: from Engineering Release to Production

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


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


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


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


Why it works


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


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


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


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


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


Advanced techniques

• Cumulative Flow Charts• Statistical Control Charts• Two-tier Boards• Handling Multiple Projects: Swimlanes• Classes of Service• Improvements by governance changes• Feature Injection


Cumulative Flow Charts


Cumulative Flow

Cycle TimeWIP

Statistical Control Charts


Two-tier Boards


Features in Development

Their Stories

Handling Multiple Projects: Swimlanes


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

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?• ...


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


http://www.limitedwipsociety.org/tag/feature-injection/

http://www.infoq.com/articles/real-options-enhance-agility

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


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


5 Core Properties1. Limit WIP2. Visualize process workflow3. Measure & manage flow4. Make process policies

explicit5. Use models** to recognize

improvement opportunities** popular models currently include Theory of

Constraints, Lean Waste, Deming's Theories regarding Variation, & Real Option Theory

5 Emergent Properties1. Prioritize work by

(opportunity) cost of delay2. Optimize value delivery

with classes of service3. Spread risk with capacity

allocation4. Encourage process

innovation5. Manage quantitatively


Kanban : Current Working Definition*

* 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

36Copyright (c) Norbert Winklareth

DISCUSSION


APPENDIX


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)


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


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/


Contact Info

• Norbert Winklareth– [email protected]


Kanban: Thinking Outside The Time Box

Technology

Transcript of Kanban: Thinking Outside The Time Box