Making Kanban Work For You

I think Kanban (see Wikipedia or the book Kanban: Successful Evolutionary Change for Your Technology Business ) is a very good idea. I’ve seen it transform bored, miserable developers into highly motivated Post-It moving fanatics. I’ve also seen it turn bored, miserable developers into bored, miserable developers who also move Post-its, when they remember. Therefore, here are some thoughts on making Kanban work for you. Your Kanban board should always mirror exactly what your process is at the moment, but I’ll suggest one for you so that I have something to reference. It should be fairly typical* —

The numbers in brackets are fairly arbitrary limits, based on a team of five developers, two QA people and two people who can do releases (note that some people are allowed more than one job, so this could be a team of just five). Dashed lines are those that you are allowed to ‘push’ post-its over (i.e. you can walk away from a Post-it after moving it, rather than having to then do something with it). Once you’ve got your board, follow these simple rules:

1. Never move a Post-it backwards — if things in progress need to be changed then create a new Post-it detailing the changes and add it to ‘To Develop’.
2. Never move a Post-it off the board before it’s reached the last column.
3. If a Post-it can’t move forward, draw a red box around it and write the reason alongside.
4. Adhere to limits like your life depends on it.

Pretty soon, you’ll probably find that lots of red ink appears and nothing is being done because you’ve hit one or more limits (you are Kanbanned**). This is Kanban telling you that your process is broken. You probably already knew that, but now you know exactly why. It’s written for you in red on the board and sticking to your limits means that now your developers can’t do anything other than fix these problems. Keep doing this a few times and before you know it you’ll be developing at remarkable speed and impressing all your friends.

Note that fixing the blocks might involve modifying the board, but it probably doesn’t.

Some guidance for the tempted

If you absolutely can’t clear a block without moving the post-it off the board early, think hard about why. Are you too reliant on outsourcing that lets you down? Are your specifications too vague or unrealistic? Are you priorities shifting too quickly? These are all issues that can and should be addressed. Also remember that your limits are not set in stone. You can change them with good reason, but make sure everyone knows why.

If you find that it’s hard to get priority work through the system quickly and you’re tempted to bypass the process, introduce triage. Divide the work to be done into a few different types and assign a relative priority to each. Use different coloured Post-its to represent different types. Developers looking for their next task must select a ticket of the highest priority in ‘To Develop’ at that time.

Refining the process

• Remember it’s your Kanban board — change it if you don’t like it, but keep following the rules.
• Show off your success — have a ‘finished’ column and when it fills up, celebrate by turning the Post-its into confetti. Be sure the recycle them afterwards, though.
• Don’t try to encapsulate too much. Generally, anything that comes before ‘To Develop’ is not suitable for a process as linear as Kanban — ideas here need to be iterated on and refined.
• Use a physical board — software is simply not as effective at visualising what’s going on, and not flexible enough when you need it to be.
• Do, however, use issue tracking software and write issues numbers on the Post-its that represent them. As much as possible, mirror the columns on your board as issue states in your software. Many issue tracking packages will allow you to report on your throughput, so that you can see it rise as you refine your process.
• If you find most of your Post-its are on the floor, use Super Sticky Post-its and clean your whiteboard regularly. Post-it glue will eventually let go, but it takes a long time. If things are still falling off then perhaps they aren’t being dealt with in a timely manner — are your limits too high?

In Conclusion

Kanban might the answer to all your woes, but you have to play by its rules and give it time to work its magic.

~

* You might not have a QA step, in which case you can leave that column out. You should do some form of quality assurance, though, even if it’s just someone who didn’t develop the feature looking at the software and making sure it does what’s written on the post-it. You might also be pre-release, in which case the ‘Releasing’ column is probably redundant, but it’s worth considering that merging features into mainline/trunk/master is a genuine task to be done.

** Not a real term, something I made up.

Jez Halford is a software development coach helping teams in the UK to be more agile, scale better and automate more. Visit jezhalford.com to find out more.