Kanban: Optimising for Predictability

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.

Visualise Workflow

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.

Kanban Board
Figure 1: Kanban Board. Source: BABOK Agile Extension

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.

Figure 2: CFD. Source: Positive Incline (http://positiveincline.com)

Continually Improve

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:

  1. Start with what you do now
  2. Agree to make a change
  3. Respect your core rules (wip limits)
  4. Get better!

BABOK Agile Extension for Business Analysts

Today the IIBA launched its new Agile Extension to the BABOK® Guide. Get it at iiba.info/AgileExtension.

The BABOK® is the IIBA’s Business Analyst Book of Knowledge that is the first formal approach of defining and documenting what the role of a business analyst does.

The purpose of this extension is to:Watch Full Movie Online Streaming Online and Download

  • Highlight the importance of business analysis practices in an agile context
  • Show how business analysis is performed in agile lifecycles
  • Offer key principles that should guide business analysis practice in agile environments
  • Develop existing business analysis tasks, and existing techniques and show how they are useful in an agile context
  • Give information on new techniques and additional information on existing techniques

As someone that has been working in this space for some time, attempting to adapt my existing skillset and knowledge to an agile environment,

I am really excited. I’m about half way through and I suspect that I’ll read it and re-read it.

It’s exciting to see agile adoption on the increase and this extension book will help BA’s feel equipped to work with developers and clients who are actively using SCRUM, XP or KANBAN.

My hope is to prepare some posts and feedback from what I’ve read in the extension, I’m also keen to see how my own approaches compare to those that have been outlined in the guide.

Good Reasons Not to Follow the Process

This made me smile. We’re starting some new agile projects this week and there has been a lot of interest from people not on the project team. Most of this interest seems to be based on the belief that we’re throwing the rule book out and becoming ‘a bit relaxed’ with our development process. I don’t believe that’s the case but this comic strip sums it up pretty well!

Source: ModernAnalyst.com