10 Bad reasons to choose Kanban over Scrum

"We're using Kanban instead of Scrum" - a common sentence, Especially since I do SAFe consulting, I hear this one quite frequently. Most reasons provided for this are anywhere between highly and extremely doubtful, and in many cases reveal ignorance both of Kanban and Scrum alike.

So here are my top 10 bad reasons for using Kanban instead of Scrum:

#1 - Our Consultant told us so

There's so much wrong with this sentence that it can't be fit into a single sentence.
First and foremost, if your consultant - after some short observations - knows your process better than you do, then you should seriously question what you're doing.
Also, a team should strive to be autonomous in decision making, and if your best reason for a decision is because someone else told you so, then you have absolutely no valid reason: you haven't understood what is best for your own good!

#2 - We had to choose

"Scrum or Kanban" is a false dichotomy. It's like saying, "Do you want a beverage or lunch?" - why not combine?
You can easily and very well combine Scrum with Kanban, as they address different problem domains. Whereas Scrum's primary concern is the nature of teamwork, Kanban focuses mainly on the flow of work. Especially Scrum.org has been investing significant effort in recent years to put together a "Professional Scrum with Kanban" curriculum which makes exactly this point.

#3 - 1 month is too short

A common argument I hear is that "we can't get anything Done in 4 weeks." 

Sorry to say, if you're not getting anything Done in 4 weeks, chances are you're not doing Kanban either. Kanban is flow optimization, and if you sit back content with a cycle time of more than 30 days when other development professionals can easily do 1 week (or less), you're just being lazy. 

While some organizations are indeed so impedited that everything is moving slowly, working relentlessly to make the problems visible and finding creative solutions to make progress is essential to succeed in the long term.

#4 - Our work is too complex

"We do really complex stuff here, much more complex than anyone else!" - Every team which has ever mentioned this argument to me was applying a "special pleading" fallacy, usually oblivious of what other problem domains look like. 

I will admit that Logistics is complex. As is social media, telco, fintech and science. Scrum is specifically made for complex problem solving, so that's simply not a valid reason.

#5 - Our stories are too big

This argument translates to: "We set up a board and put a sticky on that won't be moving for a month and call this Kanban," Well, I hate to break the news: it isn't. Kanban is about managing the flow of work, and a Kanban board where nothing is moving hides transparency and makes optimization impossible.

I remember working with a corporation where team members adamantly insisted that stories estimated to take 4-6 months were already atomic and impossible to split any further. We took a few items from their backlog into a workshop and a 6-month user story was decomposed into almost 70 workable, individual slices of value. The biggest could be delivered in a few days, some within hours. Unsurprisingly, the entire package of all relevant items estimated to less than one month!

#6 - Requirements from all sides

If this is your reason for not using Scrum, you're defaulting! One of the main reasons for having a Product Owner in Scrum is to solve the problem that everyone thinks their specific problem is Priority 1. Where a requirement comes from doesn't matter - there's always one thing that is the best thing to do right now. Even in Kanban, an understanding of what is the most important thing is extremely helpful in order to "stop starting, start finishing". 

#7 - Maintenance is unplannable

Teams which operate on a live system oftentimes get exposed to unplanned work - bug fixes, support tickets, maintenance and whatever. My first question here is: "Why is maintenance so high?" Could taking time off the busywork treadmill help fix systemic issues reduce the amount of maintenance? I have seen such teams who purposely shifted towards Scrum and taking just a fraction of their capacity to address fundamental issues - they benefitted greatly!

#8 - Requirements change too fast

To me, this begs the question: "Are you getting things finished before the requirements change?"

Usually teams answer, "No", and then I seriously question why you're doing what you're doing. Scrum might help you sort out what's worth taking into account, trashing all whimsical ideas that are forgotten faster than they were proposed.
Just as an added side note, Scrum's sprint plan isn't immutable: There is nothing in Scrum which prevents you from integrating new information and opportunities as they arise.

#9 - Too many meetings

Scrum's events all serve a purpose of inspecting and adapting - not losing focus or track in a changing environment. There is no reason for Scrum events to fill their entire timebox and there's no need to do them in a specific way.
As long as you know why you're doing what, get frequent user feedback, improve your process and outcomes and keep the team synchronized, you're quite compatible with Scrum. If you are missing out on any of these items, your problem isn't the amount of meetings!

#10 - We don't do User Stories

I have no idea where the idea originates that Scrum teams must use User Stories, estimate in Story Points, create Burndown charts or whatnotever. When your reason against Scrum is a practice such as these, the short answer is that Scrum is neutral to practice. Scrum is merely mentioning "backlog items". These can be stories, requirements, bugs, defects, ideas or whatever else floats your boat.
Some teams find value in the User Story approach, others don't. Some estimate in Story Points, others in ideal days, yet others in amount of backlog items. All of these are valid from a Scrum perspective, although some may be more helpful than others.

Wrapping up

The discussion "Scrum or Kanban (or both)" is quite valuable for teams to determine how they want to organize themselves. Unfortunately, the discussion is often not factual and highly biased. It is often led with huge understanding deficits both regarding Kanban and Scrum.

There are a lot more bad reasons for preferring Kanban over Scrum than mentioned in this article, and there are also some good reasons for doing so. When your team mentions any of the items in this post, it's good to be suspicious and ask probing questions. Most likely you will uncover that Scrum is just a pretext and there is something else going on.

Expose the root cause and deal with it, because otherwise, critical problems might linger unaddressed.