Your SlideShare is downloading. ×
Kanban: Thinking Outside The Time Box
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Kanban: Thinking Outside The Time Box


Published on

A survey of Kanban, a software development practice, its history, why people are using it, how to start using it, why it works, criticisms of it, advanced techniques, some general advice and a …

A survey of Kanban, a software development practice, its history, why people are using it, how to start using it, why it works, criticisms of it, advanced techniques, some general advice and a selected set of references,

Published in: Technology
1 Comment
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • This is meant to be a overview of what Kanban software development practice is, where it came from, why people are using it, some of the more advanced practices and where to get more information on it. Will not compare it to others, this is meant to give you enough material to know if you want to add it to bag of tools. Discussions about it versus others are for the pub afterwards. I am known for having wordy and dense presentations and I do this so that you can follow it later. I will be making the presentation available.
  • Transcript

    • 1. Kanban Thinking Outside the TimeBox
    • 2. 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
    • 3. 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
    • 4. 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
    • 5. 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
    • 6. 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
    • 7. 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
    • 8. 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
    • 9. 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
    • 10. 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
    • 11. 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
    • 12. 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
    • 13. 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
    • 14. How to do it the first time Copyright (c) Norbert Winklareth Flow: from Engineering Release to Production Model & Visual Control WIP Limits Pull
    • 15. 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
    • 16. 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
    • 17. 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
    • 18. 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
    • 19. 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
    • 20. 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
    • 21. 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
    • 22. 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
    • 23. 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
    • 24. 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
    • 25. 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
    • 26. Cumulative Flow Charts Copyright (c) Norbert Winklareth Cycle Time WIP Cumulative Flow
    • 27. Statistical Control Charts Copyright (c) Norbert Winklareth
    • 28. Two-tier Boards Copyright (c) Norbert Winklareth Features in Development Their Stories
    • 29. Handling Multiple Projects: Swimlanes Copyright (c) Norbert Winklareth
    • 30. 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
    • 31. 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!
    • 32. Feature Injection
      • A way to pull requirements developed by Chris Matts of Real Options fame, this is talk on its own, if interested see:
      • Real Options a very powerful and simple risk management and decision making process, see,
        • The comments on this article contain a lot of good information
      Copyright (c) Norbert Winklareth
    • 33. 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
    • 34. 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
    • 35.
      • 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
    • 36. 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
    • 37. DISCUSSION Copyright (c) Norbert Winklareth
    • 38. APPENDIX Copyright (c) Norbert Winklareth
    • 39. 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,
      • 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
    • 40. Some URLs to get you started
        • This site for trying to build up the value of the underlying principles and have it separate from the brand Kanban
        • A site to make it easy to get started with Kanban
        • Very good and broad introduction to Kanban and the rational for it from an agile product design specialist
        • Very good overview on these three points
        • Good presentation on how Kanban is tool for team based process change
        • David Joyce’s blog about his experiences at BBC
        • David Anderson’s site, unfortunately he is not blogging much these days
        • Videos and presentation from First Kanban conference
      Copyright (c) Norbert Winklareth
    • 41. Credits
      • Talk title from Mark Baker
      • Coin Game created by George Dinwiddie
      • Kanban board pictures used with permission from David Anderson
      • Statistical Control Chart used with permission from David Joyce,
      Copyright (c) Norbert Winklareth
    • 42. Contact Info
      • Norbert Winklareth
        • [email_address]
      Copyright (c) Norbert Winklareth