A Kanban System for Software Development

Prior to September 2007, my team was using traditional Scrum; a t-shirt sized and prioritised Product Backlog, two week Sprints begun with a two hour planning meeting and ended with a two hour review and retrospective meeting, and Sprint Burndown and Velocity as the primary metrics.

However, despite the team completing Product Backlog Items every sprint, and making regular releases, there was dissatisfaction within the team. The Product Owner felt that the development team was under-performing, and the development team felt that the Product Owner was not giving clear and consistent prioritisation and specification of what needed to be done. Despite numerous attempts to adapt the process to try and resolve the issues, including shorting the Sprint length from four weeks, and altering the level at which we did Product Backlog planning and specification, we were unable to improve sufficiently.

The primary issue was that during Sprint planning, the development team were unable to accurately identify and estimate appropriate tasks, usually because while the Product Owner knew what goals he wanted to achieve, the actual solution was often not yet fully understood. This would be highlighted by a poor Sprint Burndown signature, and the result was a trend to slip back into waterfall-style deliverables to functionally and technically specify work before development could begin. In addition there was a tendency for individuals to focus on completing planned tasks and lose sight of completing the larger feature they were part of. Ultimately, this prolonged the lead time to actually complete and release software.

In September 2007, the team agreed to a change in the process inspired by hearing about Kanban systems at the Agile 2007 conference. The goal of a Kanban system is to minimise inventory, or Work in Process, and maximise throughput of value in the system.

Rather than Sprints, with their Sprint Planning meetings, we have moved to a weekly cycle in which we simply refreshed a buffer, or queue, of the immediate priorities to work. The items in this queue are Minimal Marketable Features (MMFs) – the smallest things which can deliver value on their own. This is different from XP User Stories, which might demonstrate progress, but aren’t necessarily valuable in their own right. The queue was initially sized at seven MMFs, but we recently reduced it to five due the fact that we were prioritising items into it unnecessarily early.

MMFs move from the Queue to WIP when the development team begin working on them. The focus is then on getting the MMF “Done” as quickly as possible, where “Done” means that value has been actually delivered and realised, which invariably means that code is deployed and running on the production servers. Currently we are not limiting WIP, which a traditional Kanban system would.

One of the concerns with pulling MMFs in this way, with little forward planning, was that there was little or no visibility of whether the team would, or could, meet any longer term strategic objectives. To address this, we have added a quarterly cycle, which allows us to set up to three high level Goals to guide the selection of MMFs. These Goals are then linked to a number of key MMFs which are t-shirt sized and provisionally forecast to be worked on in particular months. This probably strictly counts as creating inventory, but is done in a way which minimises investment as much as possible, while allowing some basic release planning. The identification of key MMFs also allows tracking of progress using Cumulative Flow Diagrams and a Parking Lot.

The team also continues to hold retrospectives every month in order to keep inspecting, learning and adapting, and also measures monthly Velocity. In addition, the cycle time of each MMF is measures, from the date it is prioritised into the queue until the date it is agreed to be Done. A mean cycle time can then be recorded every month.

Note that this is not to say that traditional Scrum itself is broken, but that Scrum had highlighted a problem quickly and visibly. One solution might have been to ask the team to spend more time planning to ‘groom’ the product backlog in advance of Sprint planning. However, this feels like suggesting that if the planning is failing, then the solution is to do more planning, which seems to be valuing process over people, counter to the values of the Agile Manifesto. Rather, Lean thinking, and Kanban Systems suggest doing less up-front planning, and valuing focussed teamwork over process in order to deliver value quickly.