Kanban Experiment

27 February 2010 by Stuart Cam


What do you do when your development process is in pieces, hundreds of defects are being raised against your code, ad-hoc work requests are piling up, the developers are groaning 'if we only had the time to make these improvements life would be easier' whilst the fixed deadline is looming.

If you find yourself in this situation the simplest and easiest thing to do is walk out the door.

It may be that the project you are working on is so fundamentally broken that even the most talented development team in the world still has no chance of succeeding. Hundreds of decisions are made during the project inception stage and each one can affect the overall chances of success. By the time the developers arrive the problems have solidified, and given their nature (financial, contractual, resourcing, managerial) the developers are, for political reasons or otherwise, unable to tackle them. Another death march begins.

Adding developers to a project with fixed deadlines, fixed deliverables in a fixed price contract rarely produces good software and in the worst case can leave the company responsible for delivery in ruins, perhaps even bankrupt.

I've been contracting long enough to realise that the majority of the problems I face as a software developer are not software development related, but both project management and business related. I'm not saying that all companies are like this, but that some companies are more deadly than others.


If you find yourself on a challenged project and are courageous enough to go the extra mile you can try and introduce some order onto the chaos, patching up the major holes as best you can. A do-it-or-die attitude is required because you'll probably ruffle somebody's feathers in the process.

Given the above situation, I decided go back first principles and implement a Kanban system with the help of my team, in the face of some serious project challenges.


First, you'll need a large wall space, some marker pens, coloured tape, sticky dots and post-its. If walls with whiteboards are in short supply then the back of some borrowed cupboards will suffice.

We loaded the Kanban with our backlog, giving each type of work a different coloured post-it:

Use Case

A large chunk of work which needs to be broken down into smaller tasks. Many tasks go together to form a complete Use Case.


A task for a particular Use Case of sufficient size to be estimated and worked on by a developer(s).


Improvements are internally generated within the development team. An example may be a largish refactoring opportunity, automated process or tools upgrade. The point here is that time spent on an improvement will increase the flow of other post-its across the board.


Raised by the test team on the current release of code. These defects are raised and entered through an external system, the post-its are placed on the Kanban to track the work in progress.


Externally generated work, perhaps as a result of a customer demonstration.


Can be placed on any other post-it to denote that there is an outstanding issue, complete with a description of the problem.

As well as colour coding each card contained the following information:

  • Date the post-it arrived on the board.
  • A description of the work item.
  • Priority denoted with a coloured sticky dot, for defects this dot represented severity.
  • Initials of the current owner.
  • Time spent on the work item. We would dot all items that were in progress every half day.
  • Optional. Date the post-it needs to be completed by.
  • Optional. Identifier from the external system, e.g. Defect Id.

The team were educated on the system in under half a day and by week 4 our Kanban had grown to incorporate another cupboard and many more modifications:

Kanban - Week 4

We cleared the finished section of the board (far right) every week. The board above is telling us that we spent a lot of our time addressing failure demand in the form of defects. The concern here is that the actual estimated and paid for work is represented by the pink post-its on the far left and they didn't move for over a month!


The Good

  • The teams focus was aligned to completing work.
  • Encourages the team to recognise, record and make improvements.
  • Anybody can write up a post-it and add to the backlog, I'd often say "don't tell me, tell the board".
  • Single visualisation of the work backlog, work in progress and work completed.
  • See different types of work at a glance.
  • The team has autonomy over pulling new work, creating a sense of ownership which is lost when work is assigned.
  • Managers can prioritise work in the backlog.
  • Colourful and tactile, giving a sense of fun to the project.
  • Flexible and adoptable. We altered the board as our understanding improved.
  • Simple and cheap. The total cost of implementation was less than £30.
  • Easy to gather metrics about how much work the team can get done.
  • The simplicity of the solution promotes the idea that it is easy to change and customise.

The Bad

  • Doesn't work with distributed development teams for obvious reasons.
  • It's simplicity can be interpreted as amateurish which results in the idea being written off.
  • Easy to forget to mark post-its with key information, particularly dates and owner information.
  • Can be difficult to find a particular post-it, the problem somewhat compounded by using identifiers from external tools.
  • No backup, although conversely it's less likely to crash and lose your data!

The Impact

  • The board showed us that there was more work that needed doing than was planned or imagined.
  • The previous development approach had led to a lot of defects.
  • Developers can self-organise and work honestly if they are given the chance.
  • The role of management is to remove problems (purple post-its) and to optimise the system to improve the flow of work through it.

The Kanban board provided us with a greater level of insight into what was happening on our project. The visualisation of work enabled us to make better decisions about how to utilise our time. By recognising that we have a finite number of resources and a large amount of work, we can make team decisions about how best to proceed.

In some ways the Kanban board affirmed what we already knew, that our project was seriously challenged, but it also gave us a framework to work within. Understanding and learning about your situation is simply the first step in escaping it, without walking through the door!

Tags: , , ,

Categories: Agile | Management

Development Models

31 January 2010 by Stuart Cam

Agile / Iterative Development

Iterative Development

Waterfall / Predictive Development

Predictive Development

Tags: , , ,

Categories: Agile | Management

© Codebrain 2021. All Rights Reserved. Registered in England: 07744920. VAT: GB 119 4078 13