10 lies about Kanban

 

Hello dear readers! 

Today I want to explore with you, something that I found on the way many times: confusion. 

In this case: confusion about Kanban. 

Is not rare to find people that thinks that Kanban is Scrum without sprints. Or maybe they think it is to "just work". 

 Lets go point by point...  

 

 

Kanban is different to Scrum 

In my opinion, the first mistake is to consider that Scrum and Kanban are different concepts, or even "oposite". Not even near... it is not a "versus"

From my perspective, Scrum is Kanban. Scrum is a specific way to Kanbanize a team. 

Here we are not talking about two absolutely different things. And so, to understand both can help you perform better... many people have a lot of problems with the "Scrum strategy", because they don't understand some Kanban principles. 

 

Kanban is better for simple proceses, but not for complex environments 

False. 

 

Both are strategies for complexity. Is how you use it what makes it suitable for complex or complicated contexts. 

Complex: is not predictable. The unknown.

Complicated: you need info to understand it, its not obvious. 

Simple: its self-explanatory. 

Complexity was the "cryptonite" that killed classical management (waterfall, command and control), and one of the basics elements of Kanban (AND) Scrum is the "plan-do-check-act" strategy. 

 

 

Kanban does not have roles (Scrum Master, Product Owner) 

Kanban implements also the "Service Manager" and the "Delivery Manager". 

• The Service Manager, focus to increase the ROI, or value creation. Its like the Product Owner. 
• The Delivery Manager, focus on the flow and deliver, allowing things to get done. It is like the Scrum Master. 

Maybe to understand Kanban roles, may help you to understand Scrum roles... ;) 

 

 

Kanban does not have iterations (Sprints)

Nnnnnnnhhh! False. 

In Kanban the iterations and cycles are called "cadences", and it has more than Scrum. The interesting part of this story, is that Kanban is much more conceived for scalability than Scrum, as Kanban already conceived longer cycles and strategic cycles.  Scrum only defines "sprints" and focus at the "team level".

 

 

Kanban allows you to go faster 

CUACK! 

Typical failure... Kanban is not about VELOCITY, nor either Scrum or Agile... Kanban is about:

• Flow 
• focus on avoiding interruptions
  
• Optimization 
• focus on reducing waste
• Improvement
• focus on finding weak parts of the system 

 

 

Kanban is to do whatever you want 

 To do "whatever you want" you don't even need a method. To have a strategy is to have constraints. But if you want to look or sound professional you can put a name to your "do what you want" ... "method"... 

Let me think... mmm 

Yes... we can call it:

DOYO 2

Then, when someone "important" ask you what method are you using? or what is our strategy? you can answer... 

• We are using a DOYO 2 strategy for risk management and planning. 

That sounds professional.  

 

 

Kanban is Agile

Sorry, I need a break. I feel sick now... this is disgusting...

Ok thanks... 

No my dear friend... let me see how can I explain you... 

Kanban cannot be "agile" because is not a person, is not an homo sapiens. Is a method. 

Tools, methods, cars, boards: Can Not Be Agile. 

Only people can. 

In some "agilized" environments you can read something like this:

• "in our Agile Blog, you can find Agile Posts about Agile games that we can use for our Agile transformation into the Agile Authority PMO, please contact our Agile Officer to be instructed on how to proceed" 

No. Kanban is a method. We could agree that it is "agile friendly", what means, that it could be useful to facilitate and cultivate an "agile culture" among our teams. 

Fair enough. 

But you can be behaving in a an agile way with Kanban, but also is possible to commit war crimes using Kanban.  

Bottlenecks are bad 

In our "project management" (neurotic) culture, we trend to associate bottleneck with "traffic jam", with "going slowly" and many other negative meanings. 

In Theory of Constraints, is said that: bottlenecks are not good or bad, they are just bottlenecks.

What do you think about this bottleneck? 

• Set of "why" questions:
• Why do you think that
• Scrum has only 1 PO?
• Kanban implements wip limits?
• Timeboxes are fixed? 
• We use only 1 Board? 

 

• Why do you think that we work with constraints and restrictions? 
• To optimize the system by reducing waste 
• To reduce complexity 
• and much more...
  

• In Kanban we don't estimate 
• 
  
• Kanban is to do Scrum without Sprints
  

 

•