Kanban is a software development methodology which is all about limiting work in progress (WIP) items in an attempt to:
- Increase predictability of delivery of these items.
- Improve the quality of the ‘stuff’ being delivered.
- Enable developers to return to the sanity of a 40 hour work week.
Kanban is a ‘pull’ system in which the power lies in the hands of the implementors, who decide, with information from the client or stakeholder, which tasks must be completed first. In a typical Kanban system, the WIP limit is placed on the developer: how many items should the developer be working on at any one time in order to ensure its delivery is predictable and of high quality?
At Alley, however, life isn’t always so simple. We have essentially two types of projects: development projects and maintenance projects. Development projects are site builds or major new features which typically span several weeks. Maintenance projects, on the other hand, are generally already live, and our responsibility is to add some new features, fix bugs, and tackle minor or ongoing projects. For us, development projects often become maintenance projects, and some maintenance projects go back into development for a large new feature or for a platform upgrade.
For our development projects, the typical Kanban mentality works perfectly: the WIP limit is placed upon the developer who will prioritize, or ‘pull’, the work based on the order in which a site needs to be built, often with input from the client as to which features are most important and would ideally be launched first. For maintenance clients, it doesn’t quite make sense to take this approach. The developer no longer has the best information on which work to prioritize—that information is driven by the immediate business needs of each client. So we implemented a second Kanban system to accompany the traditional system for development projects. In this new system for maintenance projects, the WIP limit is placed on the client rather than the developer. This allows us to limit the amount of WIP, but with the client doing the ‘pulling’ into the system, rather than the developer.
This is all fairly complicated, so we built a plugin for Redmine, our project management system, which can handle both methods of WIP prioritization. The result looks something Trello, but that’s a topic for a future post!