In 2004 I went to a friend’s house for dinner and she served up what can only be described as “a disgusting mush”. This mush was apparently risotto. From that moment on, I was risotto’s biggest opponent. I fought against it whenever it appeared on menus. It was, in my opinion, a waste of space and should be avoided at all costs. Fortunately, in 2012 I was served risotto in a restaurant (by accident) and found out that it can be one of the most wonderful dishes.
Over the last few years I’ve encountered many people being derogatory about Scrum. However, ever since being introduced to Scrum in the mid-00s by Dave Jensen and Richard Coombes, it’s revolutionised the way I’ve worked. Yes, there have been problems to work through along the way, but we’ve always come out on top. The difference? The bad experiences were the result of half-hearted, uneducated implementations; the good ones were the outcome after spending time and effort understanding the principles and concepts of Scrum.
In the last few months, I’ve had a similarly successful experience with Kanban. Again, the team and I have spent time reading about it, listening to others and even going on training courses. However, I’m also hearing about a lot of people who declare that they are starting to use Kanban when they understand little of the guiding principles/ideas. They are, I fear, heading towards Kanban risotto: a horrible mushy mess caused by a lack of understanding; it’s not just about putting WIP limits on your board! [which I confess is what I thought it was before I investigated it properly]
One great aspect of Kanban is that it’s a bunch of ideas/principles/concepts rather than a framework. But this is also its downside: you have to be prepared to think about how you’re going to implement these.
So what is Kanban?
It’s difficult to summarise what Kanban is. If I had to boil it down to one sentence, I’d say that it is about focusing on removing as many variants in your processes so that the flow of work is maximised. It includes ideas such as:
Limit Work In Progress
It has been proven that the more things you try to do at once, the longer everything takes and therefore it’s longer before you start receiving any value. It’s also shown that quality is improved when you limit the amount of work in progress at any one time. So, Kanban encourages you to limit the amount of work in progress (aka “WIP”). How you do this is your call. Many people start by limiting the amount of story cards in each column, but you can also limit WIP across a bunch of columns, the whole board and the whole company.
Manage flow
The main aim of Kanban is to minimise the variable elements in your workflow, so that you have a steady (thus predictable) flow from beginning to end. This starts by only bringing in new work once you ship something out the other end. But you also need to look at trying to limit the different types of work that come in and reduce the unknown variables that we all experience. Examples include managing bugs, features and technical debt, as well as release testing and ad hoc requirements. Tools like Cumulative Flow Diagrams and spectral analysis histograms will help (more about those in another blog post).
Visualise
Work out how best to visualise the team’s progress: how do you identify different types of requirements (new features, bugs, tech debt, etc)? How will you show urgent items? What about different resources? How will you identify blocked items? Etc, etc.
Explicit policies
Following on from visualise, you should be making it clear what policies you have. Setting entry (or exit) criteria so that everyone knows what must happen for stories to move from one column to the next is one way. Having a clear definition of ‘Done’ is another. Setting SLAs for different types of work: urgent requests, bugs, ongoing code upkeep, etc. Get them agreed and printed up.
Continuous improvement
Kanban isn’t expecting you to revolutionise your processes. In fact, it’s expecting the opposite. The principle of “Kaizen”, or evolutionary change, is encouraged. Like you would make small changes to a website, then evaluate the effect, you should do the same with your processes. Keep the stuff that works and reverse the changes that don’t result in an improvement.