As many folks know, Net Objectives does both Scrum and Kanban. Admittedly, our Scrum is very much like Scrumban (or Scrum done under the context of Lean) but it is still an implementation of Scrum. Scrum, as it normally manifests itself, has several challenges in that it requires teams to learn too much about how to apply it (much is know that hasn't been incorporated into it) and many teams try it when it really isn't the best framework for their situation.
Challenges such as an inability to form true teams, close the gap between coding and testing and the resulting unfinished stories at the end of sprints has many teams abandon the true Scrum practices of cross-functional teams that are truly time-boxed. Some in the Scrum community have called this Scrum-but, a demeaning term which I've always disliked for two reasons. First, it is disrespectful, and second, it hides the fact that most of poorly practiced Scrum is a result of Scrum the lack of most of the Scrum thought leaders not stressing the Lean principles on which Scrum is based and why it works.
The new vogue now is for Scrum teams to drop time-boxing and cross-functional teams and say they are doing Kanban. I suppose the logic is that Kanban doesn't have these. While true, Kanban is not defined by not having iterations or not needing cross-functional teams. It is defined by visibility, managing flow, explicit policies, a white-box process, and continuous improvement with PDCA. Let me be clear - if you have been doing Scrum and have stopped time-boxing and don't have devs and testers working together you are not doing Kanban. You are not even doing a shallow version of Kanban. You are not really doing any well-defined Agile method/framework. END OF STORY. (but not the end of the blog).
This actually reminds me of a company I contracted with over a decade ago. They claimed they did XP, but when I asked them how they did XP, they defined it in terms of what they didn't do: we don't document, we don't do major designs up front, we don't ... Unfortunately, they also didn't pair program, write tests up-front, do continuous integration - bottom line, they did not do XP. Methods are not defined by what you don't do alone. They are defined by what you do and what you don't do. In most cases, when a method/framework doesn't do something, there is something else it does to achieve the intent of what other methods may have practices for. For example, Kanban's explicit policies and managing WIP accomplishes what cross-functional teams and time-boxing purports to do.
What's unfortunate, however, is that many folks don't understand this. This belief, along with, oddly enough, the belief that you should start with Scrum and then move to Kanban, is widely promoted by folks who have never done Kanban but make their living with Scrum. It's not unlike Chevy dealers telling prospective customers what's wrong with Fords. My advice is that when deciding between the two, actually, not a good move, in that you should learn from both. So, perhaps I'll say "when learning about the two" learn from someone who has done both, someone who can tell you what the advantages and disadvantages are. There are lots of these folks around, btw, so I am not saying you should pick us (although that'd be a good thing, I assure you).
Al Shalloway
CEO, Net Objectives
