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


27 February 2010 06:32 #

Why do you say it doesn't work with distributed development teams? I'm assuming you mean location-distributed?


27 February 2010 07:18 #

@Charles - Yes, distributed as in location-distributed.

Various team members (business analysts, managers, developers...) are scattered across the country. Some work from home, others cluster at their nearest office.

The Kanban was implemented in one of the development offices, ideally the whole project team would have visibility of the board.

Stuart Cam

27 February 2010 09:35 #

I've seen this and similar approaches being implemented at various places...but this specific example has probably been the most successful I have used.

It was inclusive of all parties, and gave a clear at a glance view of the  progress being made. It has certainly pulled us out of a tight spot in a very short space of time, and was extremely effective in doing so.

Daniel Billing

13 July 2010 01:29 #

I was fortunate to take part in the experiment and I can certainly vouch for the success the team experienced.  Previously the "distributed" teams attempted to collaborate using Mingle which proved to be nothing short of a disaster.  There were of accentuating circumstances to this.

Team Members forgetting to update Mingle Cards
Not all work necessarily related to a Mingle Card.

At least with a Board Based Kan ban there was a visible constant reminder to the team of what was required. Team members were subconsciously reminded to keep the board up to date. Project Progress could easily tracked by even the most cursory glance at the board.  The board also prompted interactive conversations amongst team members because everyone could identify which tasks were owned by the respective developer. During the coarse of the experiment was the only time I truly experienced the "Done Done" concept to items of work.

I could see no discernible disadvantage to the Distributed teams continuing collaborating via Mingle and the localized teams continuing to collaborate via their local Kan Ban.

Sadly "the others" couldn't agree.

Gary Woodfine

17 February 2011 10:17 #

I've heard on the Agile Toolkit podcast an interesting applications of Kanban. Hard to disagree with his rather blunt view about estimates. Estimates are lies. They iterated into a system of using three lanes / backlogs; though with minimally functional units instead of user stories.

One of the three was a fire alarm lane get those "we really need it now feature" through the queue and without interrupting the self-organized queues the teams pulled. Though they had to come up with some rules to ensure it wasn't used for every other item as clients often would want.  From memory they got 1 per iteration and if they wanted two then they wouldn't get one for the next iteration, something like that.
Over time they got a fairly consistent MFU velocity. The estimates worked more like a telephone help desk. Current wait time for a new MFU is 6 weeks for instance.
Hard to see anyone selling that system to a new business client. They were working on a long term client where it makes much more sense. Over shorter projects at agencies you never get enough time to start using velocity meaningfully. So you are left with lying Smile

Daniel Gardiner

Leave A Comment

  • Comment
  • Preview

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