Paul Cornell : Kanban

Kanban: Scrum-ban

Paul Cornell [MSFT] — Fri, 29 May 2009 20:48:00 GMT

Scrum-ban: http://leansoftwareengineering.com/ksse/scrum-ban/. "The idea of using a simple task board with index cards or sticky notes is as old as Agile itself. A simple variation of this is a task board with a simple Pending -> In Process -> Complete workflow....Names can be associated with the cards to indicate who’s working on what....A problem with the basic index-card task board is that there is nothing to prevent you from accumulating a big pile of work in process....Control the number of cards in circulation. If all of the available cards are already in circulation, then the next person who comes looking for one is just going to have to wait until one returns. This is the very purpose of the kanban system....In our case, we simply write the quantity of kanban in circulation on the task board, and allocate new cards according to that limit....You might have a simple principle like: prefer completing work to starting new work, or you might express that as a rule that says: try to work on only one item at a time, but if you are blocked, then you can work on a second item, but no more....Another enhancement we can make...is to add a ready queue between the backlog and work-in-process. The ready queue contains items that are pending from the backlog, but have high priority...as soon as somebody becomes available, they should take one of these tasks instead of picking something out of the general backlog."

Kanban: More Kanban Resources

Paul Cornell [MSFT] — Tue, 28 Apr 2009 02:34:00 GMT

More kanban resources:

Kanban Systems: http://jamesshore.com/Blog/Kanban-Systems.html. "Typical Agile projects use time-boxed iterations. At the beginning of the iteration, the team meets and chooses stories from their backlog that can be done by the end of the iteration. Over the course of the iteration, they develop those stories, and at the end of the iteration, they ship them. Kanban systems are different. Instead of using time-boxed iterations, Kanban systems focus on a continuous flow of work. The team takes a story from the backlog, develops it, and ships it as soon as it is done. Then they take the next story from the backlog, develop it, and ship that story. Work is shipped as soon as it's ready, and the team only works on one story at a time....The primary work unit for the team is the "minimum marketable feature," or MMF. An MMF is the smallest feature that has value to the market....The team maintains a backlog of MMFs in a queue. This queue is strictly limited in size....If there's an emergency, a support request, or some other urgent need, there's an empty slot on the board marked 'Urgent.' The team can put an MMF in that slot at any time without having to go through the regular backlog queue. The team strives to finish urgent items quickly, and they try to keep the slot empty and available at all times. If the 'Urgent"'slot is full and another urgent item appears, it has to be added to the backlog queue....As with other Agile approaches, the team is expected to fix bugs before the MMF is done. If bugs are found afterwards, the fixes are scheduled with a new MMF. If a bug needs to be fixed immediately, the team uses the 'Urgent' slot."
Kanban in Action: http://www.agilemanagement.net/Articles/Weblog/KanbaninAction.html. "Though we track all [change requests] CRs in Team Foundation Server [TFS]...the day-to-day work is tracked on a white board using Post-IT notes as kanban cards....Each morning the team meets for a standup around the kanban white board to discuss the work-in-progress and how to keep it moving....A red star indicates that the item is severely aged[;]...[t]his allows the 'late' item to be self -expedited without direct management intervention....Blocked CRs have pink sticky notes attached to indicated that there is an open issue in [TFS]...Yellow - customer-valued CR; Blue - customer-valued (and requested) bug (fix); Green - IT maintenance item...Orange - additional (or extra) bug; pink - issue....The kanban limit for the system is 20 cards, divided in to different stages in the process - systems analysis, development, test, build/merge, deployment. In addition, we allow for 3 extra bugs to be anywhere in the system....The kanban system also frees us from the constraints of time-boxed iterations. Even though we are making a release every two weeks, items in the system can take up to 60 days to move through depending on their size and complexity....And finally, the kanban system has freed us from the management overhead of running each iteration like a mini-project."
Naked Planning Explained - Kanban in the Small: http://aaron.sanders.name/agile/naked-planning-explained-kanban-in-the-small. "The idea of the variable length Product Backlog with the need to reorganize priorities and estimate size was replaced with a fixed-length queue placed on a whiteboard for the Product Owner (Customer) to fill with Minimal Marketable Features (MMF), or what in Scrum would be User Stories....The length of the queue is seven, as this is believed...to be about the maximum amount of items any one person can hold in their head at a time....The customer is allowed to rearrange these 7 MMFs as often as is seen fit. When the team is ready to pull a new feature, it is whatever is currently at the top of the stack.....There is one expedite slot for the customer to override [Work In Progres] WIP, anything else has to wait for a slot to open....MMFs are dated when they are placed on the board, and when they are finished to derive the average time of a feature...The engineering team has 4 slots for WIP. This was determined because there are 8 engineers who pair all code....Stand-ups happen multiple times per day and are short. When the team switches pairs they ask if there’s any significant increase of information of note which is not on the board....Every Friday is a trade show of all released MMFs, and is a very jovial time in the office, a celebration of a job well-done."
Managing the Pipeline: http://www.poppendieck.com/pipeline.htm. "Queuing theory gives us six rules for reducing software development cycle time: [1] Limit work to capacity [2] Even out the arrival of work [3] Minimize the number of Things-in-Process [4] Minimize the size of the Things-in-Process [5] Establish a regular cadence [6] Use pull scheduling....One way to estimate the capacity is to look at output....According to Little's law, there are two ways to improve response time: you can spend money to improve the Average Completion Rate, or you can apply intellectual fortitude to reduce the number of Things-in-Process....You will get much faster throughput and higher utilization if you develop ten services one at a time, rather than developing all ten at the same time....An organization that delivers at a regular cadence has established its process capability and can easily measure its capacity....Pull scheduling is the best method to compensate for variation and limit work to capacity. At the beginning of an iteration, the team ‘pulls’ work from a prioritized queue. They pull only the amount of work that they have demonstrated they can complete in an iteration. When a team is first formed or the project is new, it may take a couple of iterations for the team to establish its ‘velocity’ (the amount of work it can complete in an iteration). But once the team hits its stride, it can reliably estimate how much work can be done in an iteration and that is the amount of work it pulls from the queue."
Kanban Process Template for Team Foundation Server: http://www.codeplex.com/KanbanTFS. "A process template for Team Foundation Server that utilizes a Kanban approach. This approach is based on the original series of articles posted on the AgileManagement articles 'A Kanaban system for Sustainable Engineering:' http://www.agilemanagement.net/Articles/Papers/AKanbanSystemforSustainin.html. Also, based on experiences found on Lean Engineering blog: http://leansoftwareengineering.com/ and Eric Landes's blog: http://aspadvice.com/blogs/elandes."

Kanban: Some Kanban Resources

Paul Cornell [MSFT] — Fri, 24 Apr 2009 19:50:00 GMT

Some kanban resources:

Kanban vs. Scrum: http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf. For the basics, read the “Kanban in a nutshell” section on page 3 and the “Summary of Scrum vs Kanban” section on page 25.
Kanban software development resources: http://availagility.wordpress.com/kanban/
Kanban, Flow and Cadence: http://availagility.wordpress.com/2008/10/28/kanban-flow-and-cadence. “Very simply, there is a queue of work, which goes through a number of stages of development until [it’s] done. When work is completed in a stage, it goes into a downstream queue for the next stage. When someone needs new work to do, they pull it from their upstream queue….Queue limits are designed to avoid premature work…..Work In Progress limits are designed to reduce multi-tasking, [maximize] throughput, and enhance teamwork.”
Scrum-ban: http://leansoftwareengineering.com/ksse/scrum-ban/. “…a kanban serves two functions: it is a request to do something in particular, but it is also permission to do something in general….One simple technique that brings us much closer to our kanban definition is to set a multitasking limit for individuals….Another common technique is the late binding of tasks to owners….Another enhancement we can make…is to add a ready queue between the backlog and work-in-process….”
Introducing Kanban Boards and Pipelines: http://www.lostechies.com/blogs/derickbailey/archive/2008/12/08/kanban-in-software-development-part-1-introducing-kanban-boards-and-pipelines.aspx. “[we can create] a pipeline for how our development process works. The work that is done flows through that pipeline based on how often the customer wants to pull features out. As one feature exits the pipeline, another feature can be added into the pipeline.”
Completing the Kanban Board with Queues, Order Points and Limits: http://www.lostechies.com/blogs/derickbailey/archive/2008/12/08/kanban-in-software-development-part-2-completing-the-kanban-board-with-queues-order-points-and-limits.aspx. “To create a more complete kanban board…we need to allow for a fully functional team - developers, analysts, testers, technical writers, and others. We also need to allow the different team members to work on different parts of the system, as work is needed. The end goal is to enable the system to flow through the process and to ensure the work is ‘done done’ before it goes to the customers….We can account for the team makeup and the potential bottlenecks by introducing the concept of order points and limits…and by creating queues and multiple pipelines to be worked.”
A Variation on Queues - Pipelines for WIP and Done: http://www.lostechies.com/blogs/derickbailey/archive/2008/12/15/kanban-in-software-development-part-2-5-a-variation-on-queues-pipelines-for-wip-and-done.aspx. “[How would anyone] know when work in one column is done and ready to be pulled into the next column[?]…To facilitate the visualization of the difference between work in progress and work that is ready to be pulled to the next column, we can use the concept of a pipeline and split our existing queues into a [Work in Progress] WIP and Done step….[But not] every queue needs to be a pipeline.”
Handling Bugs and Emergency Fixes in Kanban: http://www.lostechies.com/blogs/derickbailey/archive/2008/12/19/kanban-in-software-development-part-3-andon-and-jidoka-handling-bugs-and-emergency-fixes-in-kanban.aspx. “[For bugs and fixes, you can engage in] creating an Emergency Fixes pipeline, tacking a smaller bug notice onto an existing card, [or] putting a Bug card in the backlog.”

Kanban: What Is It?

Paul Cornell [MSFT] — Fri, 24 Apr 2009 01:16:00 GMT

A kanban system is a mechanism for controlling work for a project. The origin of kanban is the Toyota Production System. Very simply, there is a queue of work items, which go through a number of stages of work until it's done. When work is completed in a stage, it goes into a downstream queue for the next stage. When someone needs new work to do, they pull it from their upstream queue. For example:

To Do -> Step 1 -> Step 2 -> Step N -> Done

For a software development project for example:

To Do -> Design -> Implement -> Verify -> Release -> Done

Of course, there are likely a few more steps in your projects.

There is one more important element which really defines a kanban system, and that is the concept of limits. There are two types of limits: Queue limits (work that's ready to start on) and Work in Progress (WIP) limits. For example:

To Do -> Step 1 Queue -> Step 1 WIP -> Step 2 Queue -> Step 2 WIP -> Step N Queue -> Step N WIP -> Done

For a software development project for example:

To Do -> Design Queue -> Design WIP -> Implement Queue -> Implement WIP -> Verify Queue -> Verify WIP -> Release Queue -> Release WIP -> Done

Queue limits are designed to avoid premature work. WIP limits are designed to reduce multi-tasking, maximize throughput, and enhance teamwork. Reducing multitasking is beneficial to reduce taskswitching costs and to yield results sooner.

Throughput is also maximized by decreasing WIP. By having less WIP, the team is able to focus more on the larger goals and less on individual tasks, thus encouraging a swarming effect and enhancing teamwork.

Limiting WIP can seem unusual for teams, and there is often a worry that team members will be idle because they have no work to do, but they are unable to pull any new work. Consider the following guidelines:

Can you help progress an existing kanban? Work on that.
Don’t have the right skills? Pull in work from the queue.
Can’t start anything in the queue? Is there any lower priority to start investigating?
There is nothing lower priority? Find other interesting work.

(Summarized from "Kanban, Flow and Cadence" by Karl Scotland: http://availagility.wordpress.com/2008/10/28/kanban-flow-and-cadence/)