Insights from a Kanban Board

Donkey DerbyI was working with a team this week, part of which involved reviewing their kanban board and discussing how it was evolving and what they were learning. There was one aspect in particular which generated a number of insights, and is a good example of how visualising work can help make discoveries that you might not otherwise unearth.

The board had a “On Hold” section, where post-its were collected for work on which some time had been spent, but which was not actively being progressed or had any expectation to be progressed, and which wasn’t blocked in any way. Quite a lot of work had built up in “On Hold”, which made it an obvious talking point, so we explored what that work was, and why it was there. These are the things we learnt:

  1. Some of the work wasn’t really “On Hold”, but were really requests which had been “Assessed” (the first stage in the workflow) and deemed valid and important, but not urgent enough to schedule imminently. This led to a discussion about commitment points, and a better understanding of what the backlog and scheduling policies were. In this case, items were not really “On Hold”, but had been put back on the backlog. In addition, a cadence of cleaning the backlog was created to remove requests that were no longer valid or important.
  2. Some of the work was “On Hold” because while it was valid and important, the urgency was unknown. It was an “Intangible” class of service. As a result it was always de-prioritised in favour of work where the urgency was clearer. For example work to mitigate a security risk wasn’t going to be urgent enough until the risk turned into a genuine issue which needed resolving. To avoid these items building up, and generating even greater risk, a “Donkey Derby” lane was created as a converse of their “Fast Track” lane. Work in this lane would progress more slowly, but at least there would always be at least one “Intangible” items in process.
  3. A very few items were genuinely “On-Hold”, but they were lost amidst the noise of all the other tokens. Thus any discussion about what to do, or what could be learned, was being lost.

In summary, by visualising the “On Hold” work (however imperfect it was), and creating a shared understanding, the team were able to improve their knowledge creation workflow, better manage their risk and increase their ability to learn from their work.

A Model for Creating a Kanban System

This post is a high level overview of the model I use when I think about Kanban Systems. As the saying goes, “all models are wrong, some are useful”. This is what I currently find useful based on working with teams and organisations in recent years.

At the heart of the model is Systems Thinking. Without looking at what we do as part of a system, with a purpose to be met by outcomes, we risk focusing too heavily on the activities and practices we perform. Having a clear understanding of a systems purpose, from a customers perspective, helps us to design a method which serves that purpose.

The model then has three foundational building blocks which underpin an effective process; Flow, Value and Capability.

  • Flow – Keeping the work progressing and avoiding delays by focusing more on the movement of the work, and less on the movement of the worker.
  • Value – Ensuring that the work serves the system’s purpose, satisfying customers and stakeholders and resulting in successful organisations.
  • Capability – Creating knowledge of how well the work serves the system’s purpose in order to maintain and improve the system’s effectiveness over time.

In other words, we want to flow value through capability teams.

Finally, the model has five aspects, from which we can look at a process to help us understand and improve it; Workflow, Visualisation, Work in Process, Cadence and Learning.

  • Workflow – how does the work progress through the system? Understanding workflow helps improve how the work moves from concept to consumption.
  • Visualisation – where is the work in the system? Understanding visualisation helps create a common mental model of the current state of the work.
  • Work in Process – what work is in the system? Understanding Work In Process helps identify bottlenecks and impediments to improving flow.
  • Cadence – when does the work in the system happen? Understanding Cadence helps with co-coordinating the work and improving system reliability.
  • Learning – how does the system continuously improve? Understanding further models with which to view and explore the system ensures the system gets better at serving its purpose.

While this is only a model, and contains no specific practices, I believe that it can be useful in describing why some techniques work in some circumstances, and provide context for applying the right tool to the right job.

Evolving a Workflow

Mary Poppendieck gave a talk on Workflow is Orthogonal to Schedule at Agile2009, during which she very neatly transitioned a schedule-focused view of work, into a flow-focussed view. At least I thought it was neat, so I’m going to try and reproduce the basic elements here, using my favourite agile workflow.

4 Week Time-box Schedule


Here we have a schedule showing an average of 4 features being delivered every 4 week time-box. Each time-box is preceded by 2 weeks understanding the next features, and a release is made every 8 weeks. Its not a bad schedule. There’s a regular release every two months which is better than a lot of projects, but it could be better.

2 Week Time-box Schedule


Now we reduced the time-box to 2 weeks, meaning that we do an average of 2 features in each time-box. This means that the preparation now takes only 1 week. Additionally, we are now releasing at the end of every time-box, which is also reduced to 1 week. Much better.

One Piece Flow


If we continue the evolution we end up working on a single feature at a time and releasing it immediately. Each feature only takes a week to build, and preparation and release times are now down to 1/2 a week. At this point, we don’t really have a schedule anymore, but a natural workflow.

Cumulative Flow Diagrams

One of the things that strikes me about the diagrams above, is that each step in the evolution transforms them more into a smooth Cumulative Flow Diagram. In fact, in the same presentation, Mary showed the following picture taken from Building the Empire State. This is the building schedule from from around 1930, and itself looks remarkably like a CFD. Another example of how we are not inventing anything new, but can learn from other industries and successes.


An Agile Workflow

A common topic of discussion around kanban is whether the workflows or stages in a kanban system are counter to the Agile principles of cross functional and collaborative teams.   Its easy to talk about a feature going through the following flow in a kanban system:

Analysis –> Build –> Test –> Release

which I confess looks very waterfall-ish and I can understand why this can raise warning flags about the suitability of the kanban approach.  This got me thinking about how best to express a typical agile-friendly workflow.

Lets begin with the common basic stages on an agile team’s ‘story-board’.

To Do –> In Progress –> Done

Ideally, ‘Done’ means In Production, but often it means Ready for Release.  From a Lean perspective, features that are ‘Ready for Release’ but not yet ‘In Production’ can be thought of as inventory, and we want to minimise inventory, so visualising that inventory would be useful.  Thus we can change the workflow to:

To Do –> In Progress –> Ready for Release –> In Production

Looking at the start of the workflow, a common practice in Scrum is shaping the backlog, or grooming the backlog.  This is the process of ensuring that the the Product Backlog Items that we take into Sprint Planning are well-formed.  That is, that they are small enough, and understood well enough, for the team to be able to plan and deliver them within the time-box.  I don’t think this is Scrum specific.  There will always be a step of taking a business problem or goal, and transforming into pieces that can delivered incrementally and iteratively.  Sounds like Analysis to me.

To Do –> Analysis –> In Progress –> Ready for Release –> In Production

Features which are ‘To Do’ have not had any significant time invested in them yet but they are generally formed to some extent.  We can say that they Incubate. ‘Analysis’ has baggage associated with it so we can give it a different name. I like the idea that we Illustrate what we need to do as it seems to allow for the notion of using executable requirements or other lightweight, quick feedback techniques.  ‘In Progress’ now really means ‘Build (and Test)’.  We can say that at this stage we Instantiate the illustration.  ‘Ready for Release’ means that we can Demonstrate what we have instantiated.  This could also include any validation or acceptance by the business. Finally, when a feature is ‘In Production’ it should be generating value, so we can say that we Liquidate it.

So for each feature, one by one, we end up with:

Incubate –> Illustrate –> Instantiate –> Demonstrate –> Liquidate

Does that still seem like a waterfall process?

Model workflow stages – not people or roles

A recent discussion on the leanagile list compared Scrum and Kanban with respect to team swarming.  The suggestion was that swarming doesn’t occur in kanban due to the way work flows from role to another.  This is a common misconception, leading to the perception that kanban is more like waterfall than agile.  Here’s my response.


I would say that limiting WIP in a kanban system can encourage swarming because team members have to help each other rather than pick up new work

And then:

The stages in a workflow are not people, or even roles.  Just stages.  So anyone can do them.
It just happens that people tend to specialise their roles to stages.
So kanban allows specialisation, but also encourages people to break out of their specialisation by limiting WIP.

For example, I might have an analysis stage, and Bob, a Business Analysis specialist.
If the kanban system has throttled analysis work, Bob could probably work with developers or testers to help them improve their productivity.
And vice versa.

Its this focus on workflow, while allowing for specialisation, that means that kanban is a suitable technique for teams of all agile maturity.  As teams learn to swarm, then their agility should improve as a result.