Context:

A message to me on twitter said - "Surely shallow Kanban is arguably equivalent to scrum-but." I understood the logic, but it always bothered me.  Because, at the heart of things the causes of Scrum-but and shallow Kanban seem different to me.  Here's my twitter blog response.

Twitter blog:

I am not sure these are really equivalent for several reasons. These include the motivations for the name, the cause and what it requires to overcome then.

First the motivations for the name.  Scrum-but was coined by Scrum promoters as a both an explanation for failed Scrum & as a somewhat derogatory term for those doing it.

Shallow Kanban was coined as a way to explain that people were ok but they could do more.

These motivations underly the differences between a focus on people or systems thinking.  See http://www.netobjectives.com/blogs/power-systems-thinking

The cause of Scrum-but occurs for several reasons: doesn't fit an organization, may be extremely difficult to implement, people don't understand why it works, people aren't in enough pain to implement, need too much training upfront to get started, aren't motivated enough (ok big tweet ;) )

The cause of shallow Kanban is people aren't in enough pain to implement, aren't motivated enough - nothing takes the place of motivation

One advantage Scrum has going for it is that in many places it often has a much higher bar to implement it.

In particular, if you don't have folks organized as teams Scrum may be hard to start. Kanban starts where you are.

This means that those doing Scrum have already committed themselves to some extent.

I suspect one of the reasons for the growth of Kanban is that those not truly motivated to improve will pick it over Scrum.

But this just makes Kanban's track record all that more impressive.