The Switch to Kanban

Recently my team have been trialling the use of a Kanban board to manage our work flow and in doing so have dropped time boxing. So the far the switch has been very positive, while it may not be an appropriate transisition for all teams I thought that it might be useful to share our experiences.

In brief, Kanban is an agile development methodology that does not prescribe time boxing (i.e. fortnightly iterations), rather it focusses on limiting work in progress. For each stage of a story’s life span e.g. ‘in progress’ or  ‘ready to deploy’ the team has a maximum amount of work that can exist. As stories are completed the team pull new stories from the project backlog. For more information I would recommend Henrik Knibergs excellent comparison of Scrum and Kanban

Why Kanban?

We originally adopted time boxing about 6 months ago, the key benefits we were looking for included:-

• A sense of rhythm and points to reflect on our working practices.
• Better visibility over tasks that were dragging on.
• A highly visible feedback loop to help improve our estimations.

For the most part the adoption of time boxing was very successful, we’ve certainly improved our abilities to estimate, and generally we have better visibility over our performance. The thing that didn’t work so well was working to the self imposed iteration deadline since it often felt false and sometimes was counter productive.

Any team working to an iteration will occasionally finish early or fail to complete all tasks, it’s not ideal but manageable so long as the team continually refines it’s working practices to minimise occurrences. In my team’s specific case this is especially hard since so much of our work is dependent on our interactions and integrations with companies much larger than ourselves. Experience tells us that it is practically impossible to predict the time spent on an integration and even harder to guess at what point the time will be spent. As a result, despite working in a predictable manner on the majority of our iteration goals it was common that we would under or over shoot.

This is hardly the end of the world though it started to chip away at the sanctity of the iteration and continually raised questions of why the system was pushing us in ways that felt wrong to us i.e. if we finish early then we can take another story from the back log so long as it fits into the time remaining, however ideally, for a given project, we’d want to the story with the greatest risk attached which may or may not fit in the time allotted. It felt that time boxing was nudging us away from this idea.

Furthermore, my company is such that our developers typically have a very good level of product domain knowledge, as such the need for a formal Scrum style Project Owner is reduced. This means that while we would demo our work to interested parties on completion of features, come the end of an iteration it was rare to demo our progress.

It was clear that while providing some benefits we were fighting against time boxing and we needed to find an approach that better described our work flow. What we were aiming for was not so much to complete a set of tasks in a pre-allotted time period, more that we should be able to regularly produce deployable features in a predictable manner. By limiting the work in progress rather than limiting the work per time Kanban presented a viable alternative we felt better reflected how we actually work, while preserving the discipline necessary to deliver working software multiple times a week.

Initial findings

Since mid iteration our practices were already similar to that of Kanban we found that migration to the system caused very little disruption and we did not notice a productivity hit while we got used to the new system.

The migration has brought about subtle but positive changes to how we work, largely due to the fact that by explicitly limiting the amount of current work it forces conversations to be had where we are close to violating the limits.

In addition to making it easier for us to refine our process, the main benefits so far include:-

• Greater flexibility in our work flow, we can respond in days rather than the three weeks a two week iteration promises. This is key, as delivering supplier driven changes quickly provides significant competitive advantage.
• On a related note, we no longer feel that we are fighting our process. It is no longer the case that we regularly take a course of action that violates our process (albeit for perfectly sensible reasons).
• The board provides a highly visible place to display tasks, communicate priorities and highlight bottle necks. These benefits are not Kanban specific however Kanban’s greater emphasis on use of the board (through tracking work in progress limits) means that any benefits are magnified.
• It saves us an iteration meeting – the role of the meeting is covered in stand ups or in project specific design meetings.
• Our stand ups have become much more focussed, this is partly because we do them in front of the board. Again this is not Kanban specific but in Kanban running them anywhere else makes no sense at all. Id’ say that we’ve halved the length of time we devote to stands ups, where further discussion is necessary it is taken outside of the stand up.
• Our retrospectives are no longer coupled to the period of our iteration, currently we still run retrospectives fortnightly, though since our stand ups are now more effective for day to day tweaks we may extend this period.

In terms of cons, thus far we do not feel that we have lost anything by adopting Kanban, the only potential problem that we have encountered is that greater discipline is required in ensuring that all tasks are completed in a timely manner.

The future

So far we are very happy with Kanban and will continue to use it.

In order to measure performance over time Kanban teams track two metrics.

• Throughput
• Lead time – the time it takes for a feature to be delivered after the team has committed to its delivery.

At present we do not have enough data for meaningful results but long term we will maintain something much like this as suggested here.

Further reading

In addition to Scrum vs Kanban comparison referenced above you may find the following useful.

• Implementing Lean Software Development by Mary and Tom Poppendieck.
• The Limit Work in Progress Society Kanban blog
• A guide to incrementally introduce Kanban ideas into a Scrum environment, known as Scrum-ban.

Finally not everyone is as sold as I am on Kanban for some anti Kanban debate see:-

• Against Kanban
• Against Kanban2
• Against Kanban3

I found the comments that follow the posts to be of particular interest.