Here at Boost we are always endeavouring to improve our processes and ultimately our outputs. The ‘cycle of continuous improvement’, if you will. This means we actively looking for new ideas to test and where appropriate integrate into our day.
Recently we have been researching the agile process Kanban and how it might integrate with our Scrum processes. Kanban is a less prescriptive agile methodology than Scrum. It concentrates on moving items through the pipeline from formulation to completion. It shares many ideas with Scrum and often Kanban teams adopt Scrum artifacts such as daily standups.
What is Kanban
Kanban is an agile methodology that shares much in common with Scrum, but it also has a number of key differences. For example, where scrum uses sprints to limit work in progress, Kanban limits work in progress by workflow state.
For a given project, a number of states are decided on, for instance backlog, develop, test and deploy. Each of these states can have a limit to the number of items that can be in that state at any given time. In this example, the develop state may have a limit of three while the test state may have a limit of two. Nothing can be moved from one state to the next if that limit has been reached. Some states may not have a limit – the backlog, for instance.
Work flows from backlog -> develop -> test -> deploy. We can measure how long it takes a task to move through the pipeline from beginning development to being deployed. This is called lead (or cycle) time and is Kanban’s key metric.
One day in Kanban land. How a Kanban project might proceed. Thanks to Henrik Kniberg
Where could Kanban be of benefit over Scrum
For Boost there are a couple of situations where I can see an immediate improvement with Kanban.
One situation is when a web application or product is in a maintenance phase. During this time we need to address defects and issues as they arise, as well as implementing new, usually smaller, features. We find that a fixed length sprint can limit our responsiveness to defects as we are reluctant to alter a sprint that is in progress. Kanban would enable us to prioritise issues while still addressing the planned smaller features.
The other situation where we see Kanban working well is when developing content managed websites. In this case it is often difficult to break the work into two week sprints. It often feels as though the work is more of a constant stream of very small features that come together to make the site. Often at the end of the sprint we often don’t have a product increment to demo or deploy, especially in the early stages. Kanban would enable us to deploy and demo when ready rather than on a rigid schedule. Deployments would become more frequent as the project progressed.
I won’t go into too much more detail here. There is an excellent forty page PDF entitled Kanban vs Scrum written by Henrik Kniberg (http://www.crisp.se/henrik.kniberg) that goes into some detail about what Kanban is and how it can work with Scrum.
Would love to hear about your experiences of Kanban!
