The more complex your process, and your Kanban board, becomes the more likely it is you’re familiar with the following situation: you work on a task which doesn’t go through each and every stage of the process so you’d like to skip one of two of them.
Consider a very simple board.
What happens when we build a feature (feature E) where there’s nothing to be documented? What to do with a sticky note on the board? Should the process be changed?
What happens when we have research task (feature H), which we don’t know outcome of, and we want to put it on the board? What if after research (development) we decide that it’s not going anywhere to a product? I mean we’re done with development but we don’t plan to do anything more about the task: neither testing, nor documentation, nor deployment.
Before we go further I have another question: does this specific situation happen frequently? If not then don’t even bother. If it is an exception then treat it like exception. You don’t get points for following the process religiously.
However, if it happens at least from time to time you should probably stop and think. One idea is redesigning the board in a way which incorporates such situation. Except you’ll likely end with conclusion that you have two different processes out there: one for regular development and another for research (or no-documentation development). So we come back to a question what to do with that?
Well, you can split tasks into two boards but this way you either loosen your limits, e.g. additional limit for one research task, or you lose some flexibility, e.g. splitting your current limits among two boards. Either way I’m not a fan of the approach.
What we ended up with in such situations was just skipping parts of the process which were irrelevant. No documentation? The sticky note goes directly to documentation done column instead of testing done. No follow-up after research whatsoever? Um, seems like we’re done done with this one so we should probably put the sticky note in the last column.
Again, we don’t get points for being ideally adjusted to the process. The board should reflect the way we really work and it shouldn’t constrain us too much. If this is how things really look like why shouldn’t we just show it?
Skipping parts of the process on the board for specific tasks is an option to consider. One advice though: as with any other movement happening on the board, make transition criteria explicit. If something goes directly from development to done column everyone in the team should be able to tell precisely what it means. And of course the answer should be basically the same each time.
If you liked this story make sure you check the whole Kanban Story series.
Advertisement: Want to have such nice Kanban boards in your presentations as well? Check InfoDiagram Kanban Toolbox. Use pawelBBlog code to get $10 discount.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
9 comments… add one
LOL Pawel, I’ve been through the exact same thing with my teams, and come to the same conclusion through trial and error!
I think such situations happen more oftten when you have your board structure designed up front somehow instead of being result of evolution.
@Michal – First, you always have your board designed up-front to some point. After all you start with more than a blank whiteboard, do you?
Second, it doesn’t really matter whether your board is designed up-front or rather is a result of evolution – the problem here is you deal with different processes within one team/one board. It basically means that if your board is fine-tuned to one process it probably doesn’t work equally well for another.
To summarize: I see a root cause of the problem elsewhere. It’s not about your approach to the board. It’s about adjusting the board to your process – sometimes you just can’t do it in a way which works in every case.
Saying designed up front I mean team has spent sometime trying to “formalize” their current process, to make up (sometimes artificial) phases to be put on board. For me basic board has 3 cols: to do, ongoing, done. This is an evolution base and if team can adjust its board for real process right then skipping phases becomes just an exception.
@Michal – If your process is generalized enough, e.g. to do + ongoing + done, you are always well-adjusted to it. However, a team can see much value in making the process more detailed for vast majority of cases even though it means you have to treat the rest of cases as exceptions.
On the other hand if exception happens once every couple of times or so it means it’s very unlikely the board is designed wrong.
I had the same issue after only 1 month of using Kanban board in a rather complex software project where the board quickly expanded from initial 4 cols (backlog, input queue, in-dev, done) to 9 (backlog, input queue, in-analysis/dev, ready-for-integration buffer, in-integration, ready-for-UA buffer, in-UA, ready-for-submission buffer, submitted/done) (you can equate submission with deployment for the purpose of discussion).
As you say, if this is how things really look like why shouldn’t we just show it? Yes, some items do skip columns from time to time, but that’s how things are. If a decision is made to skip the UA phase of a specific feature, that feature skips the UA phase and goes right into submission. If a decision is made not to proceed with a feature after analysis phase, it goes right across the board into Done.
The challenge I see is that different features may flow through a different set of phases depending on various factors, including outside factors which are outside our control, so the pressure to keep adding various phases which are used only by some features is high. However, there’s of course downside in having too many phases and a board which visualize “the-most-complex-case” flow by default.
So one could say that in some cases, the process isn’t even per-team, it’s per-feature. Something along the lines you’ve wrote about in http://blog.brodzinski.com/2011/11/alternative-kanban-board.html
@Nikita – These posts, the one above and the recent one you mention, approach the same issue, but from different perspectives.
I would decide on my approach depending on how frequently I deal with a special case. If it is just from time to time, I’d probably go with homogeneous process and would skip its irrelevant parts when needed. However, if it happens every now and then I’d probably look for board design which addresses variability of process, so I would tend to choose an alternative board design.
After all the board should reflect the reality.
How do you manage situations where there is a bottleneck between the states you are skipping.
e.g. Your task is going to skip Testing & Doc and go straight from Development to Deployment. If there is a bottleneck in Testing (e.g. the WIP limit is full). Do you wait at Development Done and wait for the bottleneck to clear, or jump is complete and go straight to Deployment.
@Evan – It depends on policies you introduce in your team and the policies should reflect the key goals you want to achieve.
As a default I would probably go with the approach where skipping a column is, well, skipping so it doesn’t matter what is happening in the part of the process you omit. In your example, it wouldn’t matter that there can’t be anything pulled to testing without violating WIP limits, as you don’t pull a specific task into testing but to deployment.
I would however point the situation where you may want to set different policies. If your main goal is to reduce existing work in progress, more aggressive policies may work as an incentive for the team to reduce the number of ongoing tasks and focus on finishing stuff and not starting it.
I wouldn’t however think too much about it. It is likely a rare situation and you can do whatever as it’s not going to hurt. If it happens more often I would think whether the board design really reflects the way you build stuff in reality.