On my last project we had a play with running a Kanban board. I’ve used Scrum on a number of occasions and am quite comfortable with writing User Stories and Tracking Estimates and Velocity but Kanban was something quite new.
Kanban is a JIT system that has its roots in the Toyota production system circa. 1940/50. It’s based on a simple queuing system that is intended to reduce the overall load of individual resources (designers, developers, testers, etc) by ensuring that packages are supplied to each resource just-in-time, preventing bottlenecks and/or too much slack in the process.
The Agile Extension to the BABOK says:
Kanban is a methodology for managing the flow of work to allow for evolutionary change.
There are 4 key aspects to implementing Kanban, they are:
- Visualise the work
- Limit work in progress (WIP)
- Focus on flow
- Continually Improve
Let’s look at those in a bit more details.
Visualising your workflow involves getting the tasks required for a project or package of work up on a board, as this the interpretation of Kanban (カンバン?), literally meaning “signboard” or “billboard”. There are a number of electronic systems for this, but I find that getting a board up in a space that your team can get around adds great value and a great opportunity for collaboration amongst the team.
The board is divided into swim-lanes and cards or tasks move from left to right until completed. This gives the team, not just the project manager, visibility on where bottlenecks are building on the board.
Different teams will pick different names for their swim lanes but I think the above is a good starting point for lane names.
Limit work in progress (WIP)
Limiting work in progress is the process of determining the maximum number of cards that can be worked on in any swim-lane. In the example shown in Figure 1, we can assume there is a development limit of 2. That is to say that the total number of cards that can be across both Waiting for Dev and Dev can not exceed 2. If we look at testing and assume that the testers have a lane limit of 3 then the following is true:
- Dev can not put anything else in to test until “Generate Receipt” is Done.
- Dev can not ‘pull’ anything else from Analysis until they move at least one card into Testing.
As soon as a task is completed in testing a vacuum is created and test can pull from development, development can pull from analysis and analysis can pull from the backlog.
Once you start to reduce WIP you start a continuous improvement cycle within the process. This allows you to make better decisions on your resourcing profile on the project.
Focus on flow
Flow can be measured using CFDs or Cumulative Flow Diagrams. These diagrams can be really useful when attempting to analyse flow through the board and identifying areas for improvement.
The following diagram shows a simple but accurate example of how a CFD can be used to show the amount of tasks in each lane over the duration of the project. we can see that at the beginning of the project the backlog was large (to-do), the in progress work was very small and there was no work completed. On days 6, 11, 20 and 24 deployments were made pushing work from in progress to done.
The CFD can be used as a tool to show the effects of any changes that you make to the team or your WIP policies throughout the duration of the project. Track if individual changes have a positive or negative effect on the flow through the board. At this stage you should be looking to optimise for more predictable flow.
The following may help for produce improvements:
- Investing in CI tools to help your team deploy more regularly
- Implementing WIP limits and Pull Conditions
- Training developers to write tests for their code. This may improve quality and reduce the amount of time code sits in test
- Increase resources in one of your skill areas
Every team understand its own pressures and resource/investment constraints. However, a CFD will help you optimise your flow within those constraints to produce a predictable flow of delivery.
Kanban is a very powerful tool for helping a team understand where bottlenecks are in production and gives tools to help track the effects changes to the pipeline may effect that bottleneck. Some of the best advice I had from a member of my team who had a lot of experience with Kanban was:
- Start with what you do now
- Agree to make a change
- Respect your core rules (wip limits)
- Get better!