On Wednesday, I attended a lecture titled “Kanban – The Hard Way”. The lecture was given by Mike Burrows, a leader in using the kanban management techniques in a variety of organisations.
Going into the lecture, I knew very little about Kanban. However, by the end I had a fairly good knowledge of its implementation and, more importantly, the reasons why it works so well.
I attended the lecture with a friend who made copious amounts of notes (Although it took me until halfway through the lecture to realise he was typing them into his phone, not just texting non-stop). Hopefully he won’t mind too much if I dip into them as I write this..
What is Kanban?
Kanban is a development methodology which emphasises just-in-time delivery and not overloading developers with too much work. It relies heavily on making work and its status highly visible, as well as imposing rules on how work travels through the system and how much can be in progress at any one time.
The core of Kanban is a “limited pull system”. Each “section” (e.g. development, test, ready to release) of the Kanban process has a limit imposed on the number of work items which may be within that section at a given time. Completing an item creates a space for an item from the preceding section to be “pullled” forwards. This has the nice side effect of emphasising completion of tasks rather than starting them (focus on finishing).
The Knowledge Discovery Process
Kanban divides its issue lifecycle into categories, ordered by the level of uncertainty. The goal is to eliminate uncertainty at each step and move towards a full knowledge of the requirements. The key to this working successfully is visualisation of the lifecycle.
The Notice Board
The core of Kanban’s visualisation system is the notice board. This is a board, marked into columns representing sections, and possibly rows representing specific projects or fast-track lanes. The board provides a focal point for making all work instantly visible to the entire team, at any time.
“Tickets” (usually sticky notes) are introduced to the board as work is committed to by the team. The tickets move across the board as the work enters each stage of the process.
The notice board will often have numbers marked on the columns. These numbers impose a maximum on the number of items that can be moved into the column. In addition, each column may impose criteria that a task must meet to move to the next column (e.g. in order to move from development to testing the feature must pass all unit tests and be accepted by the team in a quick demo)
Tickets are colour coded to indicate the type/severity of the task. For instance, extremely urgent tasks may be red, standard tasks may be yellow and improvement tasks (e.g. adding monitoring) may be blue.
In this way, the team can quickly gather aditional information about the state of development ( lots of red tickets may mean a failure in testing )
Tickets can contain any of the following information:
- A brief note describing the work
- The start date
- The end data
- A due date (not always applicable)
- The developer the work was assigned to
Kanban has a “focus on finishing” philosophy. As such, the cycle time (time between starting and finishing a feature) should be as low as possible. Kanban makes use of a Queueing Theory formula known as Little’s law. This states that Cycle Time is directly proportional to Work in Progress divided by throughput.
Using this law, we can establish two potential ways to decrease Cycle Time:
- Lower the Work in Progress
- Raise the Throughput
Raising throughput is generally quite difficult to do (although changes to infrastructure and tools can help) and there is usually an upper limit (for instance, adding team members suffers from the law of diminishing returns)
Therefore the best way to decrease Cycle Time is, counter-intuitively, to reduce the amount of work being done at any one time. By limiting the number of work items allowed in a particular section of the system, we force the work in progress to be low.
A Kanban system is a constantly evolving, changing entity. No Kanban board looks identical to another, and no Kanban board should look the same at the end of the project as it did at the start. The purpose of Kanban is to allow the process to be altered to meet the changing requirements of the project (in much the same way as agile development techniques are designed to facilitate changing requirements in the software).
As an example, if the team is too slow getting features out to customers, the limits on the board can be dropped to further lower the Work in Progress and thus, decrease the Cycle Time. Or it may be decided that testing needs to be split into different phases, causing the testing column to be sub-divided.
The rules of a Kanban board are also down to the team. For instance:
- Section limits
- Criteria for promotion to the next section
- Rules for selection of tickets to work on
The last point is particularly interesting. A good rule is “Topmost, Rightmost”. Assuming developers have put the most pressing issues at the top of the column, this will ensure that the most urgent issue is pushed through to completion as fast as possible.
Because WiP is always low, this also has the side-effect of removing dependencies between issues very quickly (as the blocked issue becomes less important than its dependency, moving the dependency to the top of the column).
Kanban also provides for an interesting set of statistics. By using a cumulative Flow Diagram to track the dates of change of each ticket, it is possible to build up a picture of overall development successes and failures over the lifetime of the project. This can be useful for detecting problems and planning interventions, as well as in the evaluation stages of a project to determine what not to do next time.
As an example, if a CFD showed a large area of the graph devoted to testing, this may indicate a problem in the testing process (as issues are piling up here). Equally, large areas in development with very little testing may indicate a bottleneck in develpment leading to stagnation in later stages.
I can see Kanban being an incredibly effective way to manage time and work, both at a commercial and a personal level (yes, Kanban systems for personal use exist). The system seems to address some of the gaps in the Scrum methodology by being more work-focused than people-focused (indeed, a merging of the two techniques exists called Scrum-ban , focused on getting the best of both worlds).
Hopefully at some point I’ll get the chance to work in this system and analyse its effectiveness from the inside.