Kanban: When It Is Hard to Map a Process to a Kanban Board

I was asked for an advice the other day:

“We have a problem with mapping testing stage into our Kanban board. In ideal world we would test a feature once it is developed, and deploy it on client’s testing environment if and only if every bug we find in the feature is fixed and verified. Unfortunately the reality isn’t that nice – pretty often we deploy a feature even though testing isn’t finished or some bugs aren’t fixed. Sometimes the feature passes user acceptance tests (UAT) even though there are known, sometimes even major, bugs on our side. It introduces a mess into the Kanban board as we have features shown as under testing even though they are already deployed so basing on the board it is hard to say what exactly is happening with a specific feature.”

One of answers could be: fix your damn development process and bagger off. However I don’t count it as a good answer really. I mean yes, it is broken process which generates mess so we should work on that as well although it’s a longish discussion and it’s definitely not my point here.

My point basically is: if your process doesn’t suit your Kanban board, adjust the board otherwise every time you look at the board trying to make a decision you will stare at fiction. You don’t want to make decisions basing on fiction, do you?

OK, in this case a starting point looked something like that:

The basic problem was that in reality testing was done throughout testing, deployment and UAT phases. Even worse, given that it’s a client who says the feature passed UAT, meaning the exit criteria is acceptance from the client, it was possible that testing was still ongoing while the feature formally was at the right edge of the board (UAT done).

In short: when looking at the board it was impossible to say which features have been tested, which are being tested and which are yet to be tested.

A question: how to map such situation into linear process, which we usually have on Kanban board? Well, you basically can’t do it. Fortunately, and correct me if I’m wrong, we were never told that we need to map everything into a linear process. Actually we weren’t even told we need a Kanban board. We were just told to visualize workflow.

Coming back to the point, we ended up with a conclusion that in this case testing is an ongoing activity happening concurrently during a big part of the whole process. Digging deeper we decided that basically there are only two types of bugs related to any feature: these which would block us to use the application in production and those which wouldn’t. It doesn’t really matter whether a bug is minor but the client insist on fixing it or an issue wasn’t found by the client but from our perspective it is a major problem – we just wouldn’t push the application with this feature into production.

What struck us at that point was that such information can be easily attached to a feature: we potentially could use a feature safely or not. It’s not a stage of the process – it is a status of a feature. Why shouldn’t we show it as a feature status though? Say, a small red sticky note attached to a feature when it isn’t good to go and a green one when it is.

To be perfectly compliant with Kanban rules we should make the policies explicit – what does it mean that a feature is or is not good to go? At this point, it was pretty easy. A feature isn’t good to go either when its testing wasn’t completed or we have at least one unfixed blocking bug submitted to this feature. In such situation we should have a small red sticky attached to the feature. On the other hand, a feature is good to go when its testing was completed and there are no open blocking bugs. In this case we attach a small green sticky to the feature.

One more tweak which was pretty obvious: as we want to distinguish features which we’ve started testing from those we haven’t, we attach small red sticky exactly at the moment when testing starts.

The board after changes looks like that:

Looking at the board you can tell that feature C went through internal tests and there are no known blocking bugs. On the other hand, feature D which is at the same stage of the process (UAT) isn’t good to go, for whatever reasons. We also have a situation where feature B, which passed user acceptance tests (UAT) have a red sticky attached to it, which means there is still something wrong with it – most likely a bug found internally but the one which is important enough that it has to be fixed before we consider a feature done-done.

We can also easily distinguish features which are being tested from those which aren’t. Features F and H are of the former group and features E and G are of the latter. Note that feature E is on the later stage of the process than feature H and yet is wasn’t touched by a quality engineer even though the feature H was. By the way: it may be perfectly reasonable decision when you have to make constant tradeoffs what is more important and goes first and what is less important and waits for its turn.

To summarize: what we basically did was we came back to roots. When teams start playing with Kanban one of the first things they do is mapping their current process into a Kanban board. It seems this activity isn’t exclusive for the first day only. On occasions we notice that our Kanban boards don’t precisely describe the process we follow and this is exactly the moment to review and improve the board.

Another lesson here is that you shouldn’t try to adjust your process to simple constraints the basic board sets. If your approach is: the reality should suit my board and if it doesn’t so much the worse for reality, your board will quickly become irrelevant and you will get no value from it whatsoever. If the most basic methods can’t help to map your process into the board look for methods which work, even if it takes some more effort and creativity. The board itself is as flexible as it is physically possible. Given that you use the physical board that is. Use this power.

And then, once you solved your own problem, don’t forget to improve constantly. In this case I have at least a couple of ideas for improvements but there’s no point in applying all the new ideas unless you validate the older ones. With the right mindset there will be a lot of occasions to try out new concepts with no doubt.

If you liked the article check out The Kanban Story – a documentary of discovery and implementation of Kanban in one team.

Advertisement: Want to have such nice Kanban boards in your presentations or blog posts as well? Check InfoDiagram Kanban Toolbox. Use pawelBBlog code to get $10 discount.