Why Contrasting Scrumban and Kanban Belies a Lack of Understanding of Both

First a new theory is attacked as absurd then it is admitted to be true, but obvious and insignificant; finally it is seen to be so important that its adversaries claim they themselves discovered it. William James

Only taxi drivers, bartenders and barbers are entitled to an opinion on everything. Al Shalloway

In the Lean-Agile development space there is much misinformation being floated around by folks who have never truly used a method they are discussing. This makes it difficult for those unfamiliar with these methods to learn what they are. This misinformation is equally harmful whether it is favorable or unfavorable to the method since it confuses the issue. I recently read a blog comparing Scrumban to Kanban. It struck me as particularly odd, because if one understands both of these, one would never say they liked one over the other in a general way. In a particular instance one might chose one over the other, but one is not generally better than another. Let look at why as a way to better understand both Scrumban and Kanban.

First, we must recognize that there are two ways to consider Scrumban and Kanban. Scrumban was created as a transition method from Scrum to Kanban. However, it has since been suggested that Scrumban is a viable method of Agile team management on its own. With Kanban, the overloading of the term had the reverse sequence. First, it was a Lean-Agile management method using WIP limits to manage flow (Kanban software development) and after a few years a transition method to improve the efficiency of one's process based on Kanban software development was created by David Anderson and labeled the Kanban Method.

The aforementioned blog didn't mention this over-loading of names with the author clearly thinking of Scrumban and Kanban as only software development methods. In this blog, I'll discuss why it misses the point to compare Scrumban and Kanban as either transition methods or as development methods. In doing so, we'll learn a bit more about each..

Comparing Scrumban and Kanban as Transition Methods

Scrumban as originally put forward is a transition method from Scrum to Kanban Software development. The Kanban Method is a transition method from anything to Kanban Software development. The transition methods are reasonably the same, however, except Scrumban always starts with a team doing Scrum and Kanban starts anywhere. Trying to say which you like better is silly. When you are going from Scrum to Kanban, they are the same (so the comparison is meaningless). If you aren't already doing Scrum, then you can't be doing Scrumban and the comparison is still meaningless.

Comparing Scrumban and Kanban as Software Development Methods

Scrumban as a software development process s often thought of as Scrum with Lean practices in it. But that's not what Scrumban is. Scrumban as a software development method has Lean as its foundation. Lean's foundation is quite different from Scrum's foundation. Lean suggests white box process, explicit policies, being inclusive of management, recognizing the laws of flow, amongst other. These are not only not part of the Scrum framework, the counter several fundamental aspects of classic Scrum. Scrumban is managing flow with explicit policies, pull, limiting WIP, creating visibility, and continuous learning while having iterations and being organized around teams. Corey Ladas' brilliant book on Scrumban - Scrumban - Essays on Kanban Systems for Lean Software Development - makes it very clear that Scrumban and the Kanban Software Development process have exactly the same mindset.

Scrumban and Kanban differ as development methods only in that Scrumban is organized around teams and has iterations while Kanban may or may not have teams and does not have iterations. That's it. So if one were to compare the two, one should ask these two questions - 1) are their times I should use iterations and are there times I shouldn't? and 2)can I create a team? The reason we ask about can I create a team instead of should I have a team is because if you can create one you should almost certainly have one.

These would be good questions. But one is not really comparing the methods against each other. Rather, one is asking, for a particular situation, which is better. Comparing the two would be like saying "I like screwdrivers better than hammers." One can only compare screwdrivers and hammers in the situation one is in. Neither are inherently better than the other.

So, since I haven't heard these questions in the comments/blogs I've seen comparing the methods, I'll ask them now.

Is timeboxing useful in this situation?

Inexperienced teams often need the discipline time-boxing brings forth. So, for those new to agile, particularly those unfamiliar with ATDD and TDD, Scrumban has some advantages. The iterations bring about some discipline. However, if you have a team that has integrated testing methods, iterations may not provide more value than their cost. Furthermore, if you are in a maintenance area, iterations provide no value at all as work is typically done piece meal as it comes in. Time-boxing can also be added to Kanban in the form of time-boxing the work items themselves. In other words, if we think something should take 2 days, then we can focus on it happening in 2 days and take action if it gets bogged down. In any event, the establishment of cadence (when teams do reviews, when they look at the product backlog, when they demo to the customer-proxy, ...) is critical. Hence, whether you opt for Scrumban or Kanban has little to do with the methods, but rather to do with your team.

Can I create a cross-functional team?

If you can create cross-functional teams, then with few caveats, you almost certainly should. Cross-functional teams are the best method of getting things done. The main caveat is that you shouldn't do this if doing so removes people from other teams where they are needed (see Successful Pilots Can Sometimes Harm Agile Organizations). Teams are often not needed in support and maintenance areas as well. If you can't create teams effectively, then Kanban is your only choice.

Summary

I guess people are entitled to their own opinions regardless of their experience level with the methods under discussion. Just because someone hasn't made something work doesn't mean it can't work. As has been pointed out by many in the Scrum community, Scrum often fails in certain situations because people aren't really doing it. Contrasting methods based on the results achieved by people doing it incorrectly is just silly or worse.

Scrumban and Kanban are both software development methods and transition methods. As software development methods they are not very different. One would chose one over the other on the basis of the ability to establish teams and on whether iterations were useful. As transition methods, if you're doing Scrum, then they are the same. If you're not, then you can only do Kanban. The issue that seems to be neglected by most in the Lean-Agile space is when/where should I apply a method? Few talk about this.

Comments

First of all I would like to say that I fully agree with your post. The only aspect of your post where I personally see room for improvement is your terminology:

For me Scrumban and Kanban (and also Scrum) are neither software development methods nor software development processes. I see them as project management methods, i.e. methods that people use to manage the work (e.g. software development process activities) that needs to be done in order to generate the required project deliverables.