Due to the volatility of our developer resource we recently decided to opt-out of Scrum and adopt Kanban. Kanban is an Agile technique that is less prescriptive than Scrum. There are many similarities between the two systems including the use of white-boards and post-it notes to track progress. An important difference is that the white-board is owned by the process not the team. The board makes transparent, the flow of work through the team.
The white-board has similar columns: not done, in-progress, done. The columns have an agreed limit on how many jobs can be in each column. We agreed on up to two per developer.
Kanban does not have any notion of a Sprint. Kanban limits the number of items that can be in-progress by WIP (work in-progress). WIP limit is the key method to tweak and optimise the flow of work.
So the response time (how long it takes to respond to a change of priorities) of a Kanban team is however long it takes for capacity to become available. Capacity is measured by the general principle of “one item out = one item in” (driven by the WIP limits). You don’t have to wait for the next Sprint to progress work and testing, deployment and review are all a continual process. Due to the emphasis on experimentation and the Scrum mentality to ‘Inspect and Adapt’, we decided to include Daily Stand Ups’ in our version of Kanban.
The basic steps we took to complete the adoption were:
1. Agree Kanban adoption with Dev Team Manager
Senior management was concerned about compliance for audit purposes and the possible breakdown of process. We allayed any fears by emphasising the similarities with Scrum process.
2. Agree with Product Owner
The P.O had previous experience of Kanban in a production environment and was therefore happy to adopt the process and added value based on their own experience.
3.Training session and agree column names and WIP limit with team
There was some trepidation and a lot of discussion around WIP limits and whether the whole process offered anything better than ‘just a list’. I emphasized that though Adaptive rather than Prescriptive Kanban offered the opportunity to maintain process and measure flow.
We had a planning meeting and jumped in. The interesting thing is that quite quickly we identified that testing was a bottle-neck. We knew colloquially that this was the case but the Scrum board had never exposed the relationship between testing and deployment. We tended to remove all the jobs at the end of the Sprint and the tasks that had been awaiting test or had been tested and not deployed would be forgotten. We adjusted our working practices and white-board to clearly show whose responsibility it was to test code in Development and in our Main environment.
Our team has become less volatile recently and we have returned to the more familiar territory of Scrum. Utilising Kanban was beneficial and we have reverse engineered some of what we learned back in to our Scrum process.
Have you had any adventures in Kanban?
E-book – kanban v scrum.pdf