Update to this blog 2/3/2012. When I wrote this two years ago, Scrum was pretty much positioned in the manner I have described. However, since then, Net Objectives, and several others, have started promoting Scrum with a Lean mindset.  This has had several names - Scrumban, Scrum# and Lean-Scrum.  Taught this way - Scrum practices within the context of Lean-Thinking - Scrum actually is not like your mother in law anymore, because you understand the underlying principles behind it. Unfortunately, in my experience, it is still not taught this way often enough.

Original blog:

I have been doing a lot of seminars and webinars in the last few weeks. People are always asking me to contrast Scrum and Kanban. There are several salient points that come to mind. But one is particularly relevant and I thought I'd just post this quick blog to state it.

Scrum requires a particular structure for it to work. You need cross-functional teams focused on working on one project at a time. Many organizations don't have teams like this in place and have difficulties creating them. This is one of the reasons for Scrum-But. If such an organization creates these teams without solving the underlying problems making such formation a challenge the teams run into significant impediments. Scrum thereby forces an organizational structure on the business that creates tension to modify it to remove the impediments that they are now facing. Unfortunately, Scrum doesn't tell you how to do this. As Ken Schwaber likes to say – "Scrum is like your mother in law telling you what is wrong with you." What he leaves out, however, is, that like your mother in law, this makes you feel bad, like you are doing something wrong and she (like Scrum) doesn't provide guidance for improvement. By the way, in a write up of the 2009 Scrum gathering, Rowan Bunning summarization of Ken's talk stated "Doing Scrumbut is like putting duct tape over your mother-in-law's mouth!" (and who hasn't wanted to do that at some time!).

Kanban works in a different manner. You can start with your existing organizational structure. It creates tension for change by creating visibility into where you product development flow is delayed. It provides guidance (smooth out your flow, decrease your cycle time) to improve your process. In other words, Kanban is like a good partner saying "you are ok as you are – but here is how you can get better."

Scrum is therefore often abrupt and chaotic in nature – both because it requires a significant change to start and because one has to live for a while without understanding the nature of the underlying problem. Kanban, on the other hand, allows you to start where you are and gives you control on your rate of change. Hence, Kanban is less chaotic and is evolutionary in its process improvement.

I find it ironic that many in the Scrum community espouse respecting people and state that Kanban ignores this all important people aspect of agile methods. Yet, the process itself is geared toward creating disharmony and throwing teams into chaos. I prefer allowing teams to work in a manner in which they feel respected and in which they control. I trust them enough to improve their process because they recognize the need to do so. They don't need someone nagging them, they are better off with a coach.

Technorati Tags: Coaching Lean Lean-Agile Scrum

tag with del.icio.us