Kanban in practice

My team has been using a Kanban board to manage our day to day work flow for the past few months having switched from time boxed iterations, what follows is a description of how we use the board in practice. This post concerns itself only with day to day development and does not cover high level planning.

First some context. The team is made up of four developers, a technical lead and myself as project manager. We are responsible for the ongoing development, deployment, support and maintenance of six hosted products that are expected to run continuously. We would expect to release new functionality to the live environment a ‘few’ times a week.

The Board

Our is board is positioned in clear view of the team and we conduct stand ups in front of it.

The board contains 5 sections

We limit work in progress in two places, currently we assign roughly a week’s work for ‘Not Started’ and a further week’s work for the combined total of ‘In Progress’ and ‘Ready to Deploy’.

We do not consider these limits to be ‘hard’ and will from time to time exceed them, however in doing so we will have had a conversation to ensure that we are happy to be exceeding the limit temporarily.

Stories

Stories are represented by post it notes, in addition to a brief description of the story each card is presented in a standard form like so:-

Size

Many lean practitioners view estimation to be a form of waste and therefore something to eliminate. Estimating is still valuable to us as it provides a means to build consensus over what the story entails, this is especially useful for less experienced members of the team who may not have considered all aspects of the story fully.

Project

While each story is a deployable artefact they generally form part of a larger set. By grouping projects in this way the story description can be simpler since the project itself provides context.

Dates

We record the date a story entered the ‘Not Started’ state, the date we began work on it and the date the story was deployed into the live environment. Doing so allows me to answer questions like ‘if we were to start a three point story right now, how long would it take to get it live?’, this in turn allows me to justify spending a fortnight on improving our deployment process as the positive impact is there for all to see.

Description

We try to keep the description as brief as possible, by ensuring that lead time is minimised to a few days it is practical to communicate decisions verbally. For complicated stories we can provide more specific details via a wiki or a tool like agilefant.

Pink Notes

In addition to planned project work we will receive a certain level of support and maintenance requests, that we represent by pink post its. These tasks are large enough to add up, but each one will typically take no more than half a day. Anyone within the team can create a pink note and we ensure that our board has enough slack to accommodate these new tasks.

New pink notes are discussed at stand up, after which there are three outcomes:-

The volume of pink notes is monitored so that more realistic estimates can be made for project completion as well as tracking gradual increases and decreases over time.

Maintenance

Smaller day to day maintenance tasks like reviewing error logs and looking into monitoring alerts/trends are handled by a designated maintainer. One off tasks that will take more than a few hours to complete can be added to the board as a pink note. The role of maintainer switches on a weekly basis amongst the developers and the aim is that the non maintaining developers can focus on project work and/or pink notes.

Performance Tracking

We attempt to track team performance over time so that we provide estimates for project work with greater confidence. It also means that we can track the impact of changes to the team e.g. what is the impact of moving a developer on loan to another team?

To do this we use two different methods. The first draws on Aslak Hellesøy’s work, and measures standard lean metrics such as lead time and WIP. The second provides some supplementary metrics such as finer granularity over what types of work were delivered on a weekly basis and finer granularity of lead time between phases. Aslak’s sheet generates a number of graphics, one being a cumulative flow chart which neatly visualises our recent Christmas change freeze.

A second sheet of my own making produces a chart for velocity, this is an agile rather than a lean metric, but I find it useful to track where we are spending our effort. The yellow ‘Total Velocity’ line saw tooths at about ~ 14 points, suggesting that we work to a fortnightly rather than weekly cadence. It also shows that during late Nov early Dec we spent more time on unplanned pink notes than we did on project work. Much of the pink note load will have come from outside of the team so it’s important that we have a way to make the impact visible.