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.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs SignalLeaf.com - the amazingly awesome podcast audio hosting service that everyone should be using, and WatchMeCode.net where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in Kanban, Management, Metrics, Productivity, Quality, Theory Of Constraints, Workflow. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • bwtaylor

    Timeboxes are a form of scheduling, where we push out work in batches. This cuts against lean thinking, which perfers pull, single piece flow, and “just in time” delivery. Lean is a journey, so it’s too strong to say you can’t do timeboxing while doing lean, but it’s not a lean practice, either. Implementing lean is a series of kaizens, and eventually you should come to timeboxes and replace them.

    Regarding #4 (estimates): the government wastes billions of dollars on failed software development every year. I wouldn’t cite governement client expectations as proof that estimation is a good practice. Government contract based software development should be studied as a worst practice. The point is the governement should STOP approaching software this way. NOW! You got it right in your #5, that it’s about continuous prioritization (meaning prioritize just enough to fill kanbans when they need it).

    That said, I do like your 5 reasons better than the original.

  • @bwtaylor,

    good insights though I’m not sure I agree that time boxes are “not lean”. In the book “Lean Solutions”, Womack and Jones talk about the “Fundamental Unit Of Consumption” from the consumer’s perspective. It’s pretty easy to extend this idea a little and say that we should be delivering work to the customer in the batch size that they want. If the customer wants a batch size of a 2 week timebox, then we should give them that batch size. Within the two week timebox, though, we can still apply all of the principles of Kanban, flow, pull and limited WIP. We would simply batch up the delivery at the end of the two week period.

    for #4 & estimating for government work – I completely agree. I’ve been more frustrated by government contracts and the lethargic process entailed, than anything else in my career. it was probably not necessary for me to say “commerical & government contracts” in my post. It doesn’t really matter what type of contract I am working on – my customers want estimates, so I give them estimates. Convincing a customer otherwise requires a high level of trust that only comes from extensive collaboration, in my experience. We are working toward that, but it takes time.

  • Towo Toivola

    I have given this Scrum vs Kanban business a fair bit of thought lately. I think the thinking presented in this conversation is very interesting and mostly valid.
    Based on what I read and my experience I’m starting to think that there are a couple of main reasons for moving from Scrum to Kanban.

    1) You are not developing software solutions according to a plan/roadmap but you are responding to requests and changes of priority which are a waste trying to plan ahead. Thus the nature of the work is different.

    2) You _are_ developing software solutions according to a roadmap, but your organization (not only your R&D) and your clients are used to an advanced way of working where trust and understanding prevail over prejudice, tradition and paranoia. At least most of the time.

    My company is not there yet. There are things we can, should, and do do with Kanban, but our main development efforts use a Scrum-like (or scrumbut, if you prefer) method. Why do I think we need all these plannings, iterations, estimates and such?

    #1 Continuous delivery is mostly not an issue, as we have typically more iterations in a project than real customer deliveries. Also, our stakeholders are fairly distant from the actual engineering work, and for them the iteration demos are an excellent way of seeing where we actually are.

    #2 Changing priorities on the fly _are_ an issue here, and that’s why I think we need iterations at least for some time in the future. There is such a thing as ‘ability to work in peace’ that we like. Our guiding stakeholders are sometimes a bit see-saw in their guidance, so we prefer giving them the chance to change direction, but not all the time.

    #3 Iterations also help us in wrapping the thing well together at fairly short intervals. We need to break it in order to put together a better one. Especially when many teams work together on a large codebase the requirement of keeping it top-notch all the time is a very heavy one. This may change somewhat as our engineering practices further improve.
    Iteration planning we find useful. Using 1 day, often less, for planning 2-4 weeks of work is quite efficient for us. We find a lot of value in the plans in many ways, especially that they let us prepare a bit for things which only come up much later in the iteration and could not be completed without the preparation. The planning also often uncovers knowledge that invokes management activity that is very important to prepare for the next iteration planning. This management activity can happily take place while the development teams work in peace to achieve the iteration commitment.

    #4 As I said our guiding stakeholders often do not understand very well the engineering work and the implications of things they want. Thus estimating (roughly) the efforts of rival items often lead to significant reprioritization and rescoping that is vital for us to produce the most value efficiently. Also, we need the ability to predict project outcomes for business who is not always interested in cooperation or understanding the R&D. The estimates provide a hello-meter (view of whether we are going to hell) for the project.

    #5 On this I agree with the previous comments. Scrum implemented well will provide a good view on flow, especially when looked at from a business perspective on multiple teams working on a large project. However, I _guess_ a Kanban board may be superior in this aspect, but I don’t have enough experience on this yet.

    I am glad to have run into this conversation, please continue to enrich the knowledge of the world.