This week, we started a project using Kanban.
I used it before in teams, but this time, I’m planning to blog about the evolution we’re going through with this team. Especially since we’re planning to roll it out further in the organization if it fits our context (wich is government by the way).
All team members have experience in agile software development, so we don’t start of from scratch.
They’re used to:
- Visualizing their work on a task board.
- Limiting Work In Progress on an iteration basis.
- Continuously trying to improve through scheduled retrospectives.
Today I gave an introduction to Kanban based on the work of David Anderson and material I picked up the previous years.
Books like ‘The Goal’, ‘The Toyota Way’, ‘Lean thinking’, ‘Implementing lean software development’ and ‘Gemba Kaizen’ all contain tons of information about the subject, but it’s not realistic to ask everybody to read them before we start.
So I used the approach Henrik Kniberg uses to explain Kanban by comparing it to Scrum (which they’re all familiar with).
First of all, I tried to give an answer to the most obvious question:
Why for the love of God should we use Kanban?
Well, this is what I came up with for our specific situation:
- We’re evolving to a bigger team that handles multiple projects and systems.
- We will have more specialist roles.
- We’re responsible for development AND support.
- We have to be able to respond to change quicker.
So why not stick to Scum?
- Bigger teams make it harder to hold on to the Scrum framework and meetings like sprint planning.
- Dealing with high priority production issues have a big influence to our sprint commitment.
- We can’t fix a sprint backlog for a couple of weeks. More valuable tasks will come up in the middle.
We mapped our value stream in advance and came up with this:
Notice that we used some buffers like ‘Ready for design’ to absorb variations in our flow which will most likely surface. For now, these buffers have no WIP limits. We decided to start like this to get a feel of the flow and then adjust and add WIP limits to optimize the flow. You know, learn to walk before you run.
In this project, our flow ends in the column ‘Ready for validation’ because this is a new application. After the first release, we will extend it all the way to production.
Notice also that we don’t have a ‘Backlog’ column (yet) at the start of our flow. This is because we have a participating business representative who is available full-time to feed the flow with new features.
Every feature will get estimated as a XL, L, M or S.
Everybody was on board with the introduction and committed to give it a 100%.
The team had most trouble with the concept of using measurements to predict delivery instead of estimates. Instead of having a goal to work towards, won’t this just be a never-ending marathon?
I agreed that it might look like this at first sight. But maybe each feature has a goal on itself, which is to flow as optimal as possible through the flow with minimal obstructions.
Our goal comes in smaller pieces, and we will have the opportunity to optimize our entire system, instead of just looking at one batch of work at a time.
I look forward to the coming weeks, where bottlenecks will pop up, and we can improve the issues we ‘ll run into at a personal and organization level. Looks like interesting times are ahead of us. This is why I love our work so much. Constantly learning and adapting.
I’ll keep you updated.