Last weekend I was fortunate enough to attend a 3 day Kanban coaching workshop with David Anderson. Now that I’ve gotten over the fact that if I’d understood more about Kanban 2 years ago, I would have approached our agile transition at work completely differently, I thought it was time to blog about Kanban and try share how awesome it is
So let me start with what I see as the fundamental differences between Kanban and Scrum.
- Kanban isn’t iteration based. There are no fixed start and end dates like there are for sprints.
- Kanban doesn’t require you to change how you build software. This makes it is easier to implement than Scrum, in an organisation that is not ready embrace a lot of change.
- Kanban requires that you collect data on your process and make quantitative decisions. Before Kanban, I thought Scrum was quantitative, but Scrum is qualitative, based on observation and interpretation.
- Limiting work in progress is key to Kanban. If you aren’t limiting wip you aren’t doing Kanban. For Scrum it seems that limiting the number of stories you work on is a good idea, but not always implemented as a policy.
So how does Kanban work? I can’t hope to provide a complete overview in one page, but here’s a very brief outline which hopefully will interest you enough to read up about it further. Before David’s course I thought Kanban was just about limiting work in progress. I now realise there are a few more key concepts. Here are some of the things you do in Kanban.
- Visualise your workflow
- Limit work in progress
- Make process policies explicit
- Balance demand against throughput
- Identify and exploit bottlenecks
- Use classes of service to prioritise
- Use types to allocate capacity
Visualise your workflow
There are 2 main ways that you can do this. The first is quite similar to Scrum. Setup a taskboard showing what everyone is doing. The difference is that you don’t need to just have To Do, In Progress, and Done. You can have as many different columns as you need to represent your workflow. If you do analysis first, then design, then development, then testing. Your columns would be: To Do, Analysis, Design, Development, Test, Done. For each of the stages you should have an in progress and done column. e.g. Analysis In Progress, Analysis Done. This helps differentiate between an analyst being finished with something, and a developer starting on it. Henrik Kniberg has a nice example of what this could look like.
The second way to visualise your workflow is with Cumulative Flow Diagrams (CFD). This might seem like a scary word, but if you do Scrum you already do one of these. A Product burn-up chart is a simple CFD. The way these work is that you simply mark at regular intervals, how many tasks are in each state. This builds up over time to show you some trends. Once you have these charts you can use them to figure out your cycle time (how long it takes on average for an item to go from start to finish in your process), and your work in progress (the number of items you are working on concurrently). Similarly to a Product Burnup Chart you can then use them to predict if you are on track for a release or not.
Limit work in progress
Once you’ve visualised your workflow with a taskboard you can then explicitly limit work in progress by setting limits on each column. If your limit for analysis is 3 then you can only ever have 3 items in the analysis column, regardless of whether they are in progress or done. If there are 3 items in the analysis column, a developer will need to pick something up from the analysis done column before the analysts can pick up another feature to analyse. This might seem counter-intuitive because in some causes it could mean your analysts are idle. But studies show that limiting work in progress decreases cycle time and improves quality. Obviously it takes a bit of fine tuning to come of with the right limits for each of your columns to get the optimal throughput. The best approach is to take a stab at what you think they should be and then observe what happens and adjust to maximise flow.
Make process policies explicit
Another property of Kanban is to make the policies that govern your process explicit. Things like your work in progress limits can be agreed and then publicly displayed on your task board. The reason for doing this is that it removes emotion from any discussion about work process. Instead of a manager thinking an analyst is lazy because he didn’t pickup another task, the discussion can be focused around what the limit is, and if it is appropriate to maximise the throughput of the team rather than a single individual. Once you add types or classes of services, more on those below, the policies around these can also prevent arguments about why the team should work on some critical item before any other. Instead of the team being swayed by whichever manager asking for a critical feature is more persuasive (or scary), the manager can understand the policy rules and know what that means about whether their item can be worked on or not.
Balance demand against throughput
Once you are doing Kanban, you should start to have a really good idea of your team throughput, the amount of work they are capable of completing in a given period. Once you understand your throughput, you need to take a look at your demand. Everyone should be able to work out that if your demand exceeds your throughput you will never catch up, and will have an ever growing backlog with some items you are just never going to get to.
So if this is the case, wouldn’t it make more sense to eliminate those things from the demand right up front. How many of you have defect systems with hundreds of low priority tickets that are 3 years old and which you expect you will never get to. Well these are just cluttering up your system, and chances are every time you log another low priority ticket you are wasting your time. Instead make a policy decision. Low priority bugs will not be fixed, and remove them from your demand. Or any feature that has been in the backlog for 6 months and never prioritised high enough to get worked on is purged. This is a lot more honest than keeping an item in the queue which you will never do.
Identify and exploit bottlenecks
Kanban is rooted in the theory of constraints. With a visual task board it should start to become apparent where the bottlenecks in the team are. Do tickets all pile up in the test column? This probably means you have a test bottleneck. Alternatively your CFD should show divergent lines on either side of the bottlenecked phase (if you are not yet limiting wip), or an oscillating line in the phase after the bottleneck (if you are limiting wip). Once you’ve identified your bottleneck, you can turn to the theory of constraints to find ways of exploiting your bottleneck. The primary goal is to maximise throughput of any bottleneck. If you team works at the speed of your slowest bottleneck, then logic dictates that you want that bottleneck to be as fast as possible. You never want your bottleneck to be idle.
So how do you exploit a bottleneck. Firstly you probably want to add a queue in front of your bottleneck. This will ensure that the bottleneck is never idle, even if the work before it gets stalled for a few days. A queue is just another column on your task board with it’s own wip limit between development and test. You can call it ‘Ready for Test’. Other options are to add capacity to the bottleneck – hire another tester, or to bifurcate the work to limit the amount of work that needs to flow through the bottleneck. Are there some tasks which testers don’t need to test, either because they are low risk, or because someone else has the skills to test them? Divide the work up into items that must go through test, and those that someone else can test.
Use classes of service to prioritise
What happens when the team is all working towards the next release when suddenly the is a urgent requirement to add a critical change for an important customer and it can’t wait? If you are doing good Scrum you either ask if they can wait until the next sprint, or cancel the current sprint and replan. Well with Kanban it just goes into the input queue as soon as an appropriate slot is available, and gets worked on as soon as possible without sacrificing any of the current work in progress.
The way to do this is to specify different classes of service for items on your Kanban board. You could have ‘Expediate’, ‘and Regular’ as your 2 classes. You then define policies around each of these classes of service, and make these explicit. Something like, there can only be one ‘Expediate’ request in progress at any point in time, but it always gets chosen first when someone is looking for the next thing to work on. You can then gather metrics on your average cycle time for each class of service. Classes of service can be shown on the Kanban board using different coloured stickers or sticky notes.
Use types to allocate capacity
Another technique is to allocate capacity to different items using different types of work items on your Kanban board. What happens if the same team needs to do both development work on the next release and support the current release? If the support work comes in during a sprint and needs to be turned around quickly, you usually can’t plan for this in sprint planning if you are doing Scrum. Some teams just commit to less functionality based on the average number of support tickets they get per sprint. With Kanban you can agree how much of your capacity you want to use for support, and then create two types for your Kanban board: ‘Support Tickets’ and ‘Features’. Then decide how many slots you will have for each in your queue. You can then visualise these as different swim lanes on your task board. Then if a new support ticket comes in, you can add it to the board if there is a slot available in the input queue for type ‘Support Ticket’. In this way you can ensure that both types of work get done, and one doesn’t override the other.
Okay, that’s it for now. David taught us so much, this is just a small taste of it. There is much more on prioritising using cost of delay curves, identifying and removing variability, using types and capacity allocation as a practical implentation on Kano analysis. Hopefully I will share some of those ideas in the future when I try them out.