A Response to 5 Right Reasons to Apply Kanban

Michael Dubakov has a couple of great posts over at TargetProcess on 5 Wrong Reasons To Apply Kanban and 5 Reasons To Apply Kanban. I started to post this as a comment in response to his 5 Reasons To Apply Kanban, but the size of the comment got a little out of hand, so I thought it would be more appropriate to post here.

Michael’s 5 Reasons

The 5 reasons Michael lists for using Kanban are:

1. Ability to release any time
2. Ability to change priorities on the fly
3. No need in iterations
4. No need in estimates
5. Perfect flow visualization

I think these are certainly good reasons for the specific situations that he’s pointed out. In fact, they are some of the same reasons that I found and started using Kanban. Overall, though, I think there are better reasons for using Kanban, no matter the process and system that you’re currently using. Before I list my 5 reasons for using Kanban, though, I’d like to discuss the reasons that I don’t think these 5 are universally appropriate.

###

My Issues With These Reasons

For #1 and #3, maybe it would be better to say these are 5 reasons why Kanban may be an improvement over time boxed iteration/sprint methodologies. In general, though, Kanban does not say that we have to get rid of these. If they work for a team, and the PO/Customer like the regular intervals of delivery, then why should we remove them? … and remember “iterative” does not mean “time box”. Karl Scotland’s posts on flow and cadence are great illustrations of how we can have iterative work that is not limited to time boxes.

#2 is certainly a good reason, but not exclusive to Kanban. Back in my days of chaos and no formal process, we changed priorities whenever we needed to. Even in my pre-agile days, when we had formal process, we changed priorities when we needed to. We just did it through a change control board or other official process. I’m sure there are other methodologies (agile or not) that don’t lock us in to a specific priority list for a specific time box, as well – for example, Drum-Buffer-Rope from Theory of Constraints.

#4 can be a dangerous or difficult to work with statement. I work on commercial and government contracts through my current employer. Our customers expect estimates of when features will be delivered and how much it will cost, or we don’t get the business. Not every environment can get away with not doing estimates. I wish we could. I hate doing estimates and would rather just work from a prioritized backlog, like Michael talked about. I don’t get that luxury, though. I still do estimates of some form or another with my teams that are doing Kanban. When and how the estimates are done has changed for us, though. I think we are better at doing them and they take less time and create less waste, now.

#5 seems like any other task board the way Michael described it, here. The only implication of anything different is when I combine the previous four items into this board. I realize that he’s not dealing with time boxes, but pulling work through the board as needed. He’s also dealing with queue’s appropriately, and focusing on the flow of work. However, I don’t see those being detailed in the reason, specifically, and have a hard time seeing benefit or difference in the reason listed, over most other forms of agile software development. This is kind of a nit-picky point, though. If we understand the implications of what his reason is, then there certainly is a lot of benefit to a Kanban visualization over a scrum/xp visualization.

My 5 Reasons

For my 5 reasons to use Kanban over other methods, I would list something along these lines:

1. Reduce lead time to deliver features and functionality through limited WIP
2. Decrease cost of features and functionality
3. Reduce rework and improve quality by forcing ourselves to face the issues in our system
4. Reduce waste and improve flow of work, through limited WIP and leading indicators
5. Reduce cost of estimating and planning, through continuous prioritization

I realize that some of these are not necessarily very different from what you’ve said. #5 for example, is very close to your #2. The difference in my perspective and statement is that not everyone can get away from estimates, like i said. but we can reduce the cost of estimation and planning with Kanban, even if we can get away from it.

… anyway… just thinking out loud, here. I have a personal connection to the reasons that Michael listed, as they are the same reasons I ended up with Kanban. I just think that there are better reasons that we can list, that are more universal than improvements over time boxes and estimates.