A while ago I wrote a blogpost about why scrum didn’t work for us. Some of you did suggest me to use the Kanban methodology instead. This would be a much better suit for our team. I did a lot of research of what Kanban really is, what the best practices are and how to implement this in our team. I will tell you in a few steps how we did this..
First of all, what is Kanban? Well, Kanban is a method to visualize the development work flow and the work in progress. Kanban has 5 principles:
- Visualize the workflow
- Limit WIP
- Manage the flow of work
- Make process policies explicit
- Improve collaboration
Using these aspects, you can highlight any bottlenecks in the development process. You have a visual overview of the things which are happening in your team, so you can guide it. Perhaps change the process, change the WIP limits, ..
Kanban is an approach to change management. It isn’t a software development or project management lifecycle or process.
A kanban system is often designed on a big white-board used to reflect the workflow. Different color cards are used to show different types of work. This could be a task, a user story, a bug. There is a more detailed description of the task written on each card.
The first thing I had to do is reflect the development cycle to columns on the whiteboard. Pawel Brodzinski made a very interesting blogpost about that. Using his guide, I created my first-ever Kanban bord. This is how our ‘version 1’ board looks like:
Note that the columns seem to reflect some kind of waterfall style process mapping. Well it isn’t. The Kanban board reflects all phases an item must go through in the development cycle. It encourages small independent user stories to be developed in little pieces. The columns on the Kanban board don’t represent hand-offs between team members but more or less the state of what’s the feature in during that time in its development lifecycle.
As you can see, we also use some Kanban queues. Those are a small inventories between two processes to create the appearance of instant availability.
Some notes on our board
- How did we define the WIP limits? Trial and error.. There is no science which will tell you what’s the best WIP limit number. It depends on your process, your team capacity, ..
- We will not continiously deploy. We keep a list of features/bugfixes in the ‘ready’ column, and the PO decides when there is enough ‘buzz’ to make a commercial feature release/bugfix release.
- High priority is a special ‘swimlane’. If there is an item there, mostly a bug, the developer is obliged to pull that item when he is ready for some new work.
- There will be a montly retrospective meeting. In this meeting we will discuss the board, check if the colums are still good and if there are other remarks.
- The queue will (mostly) be fed by our weekly prioritization meeting.
Why is Kanban better than Scrum (for us)
- First of all, they are both process tools. They both help us to work more effectively.
- The biggest difference is that Scrum is iterative based and Kanban not. This was a problem for us as with Scrum, we never released what was planned in our sprint.
- We went from PO driven development to a combination of PO driven and sales/client driven development.
- We handle critical issues much faster that we used Scrum, where you have to wait till the start of the new sprint.
- We can prioritize our items so important things go first.
- Developers have more motivation (maybe because Kanban is less prescriptive?)
- It’s easier to work on multiple products. If we want, we can even use a different swimlane for each product.
What will change?
- Other (bigger) post-it’s with more information to visualize. The current post-it’s only have a brief description of the ‘todo’, but I want more information on it.
- I also want the start/end date and the time spent on the task visualized. I would like to make some stats to define average lead time (starts when the request is made and ends at delivery) and cycle time (clock starts when work begins on the request and ends when the item is ready for delivery)
- Investigate the possibility of using swimlanes for user stories and the linked user story tasks.
- Kanban cards are now colored by type. Like: a feature, a bug, a task, .. Perhaps we can use the colors tho define which type of work. Like: core development, configuration, design, marketing, .. ? (any suggestions on that are welcome!)
- The outline of the sub-columns needs to be smaller, or maybe dot-lined. Now it’s hard to see the general ‘flow’.
Some interesting links
- Kanban vs Scrum Minibook
- Overview of what Kanban is
- One day in Kanban land
- Noodling on Kaban (4 parts)
- Work in process limits, revisited
- When iterative development causes problems
Thanks for reading and I’ll keep you posted when something changes in our Kanban story!
