Kanban, Lean and Scrum Are Not Religions…

IMG_1127

photo credit: criggle1

…but some people tend to treat them that way.

Lately, a lot of agilists are discussing differences, similarities and (in)compatibilities between Kanban, Lean and Scrum. Google is your friend here, search for “scrum vs kanban“, “scrum vs lean” and “lean vs kanban” to get you started. In this post I’ll add my opinion to the discussion.

Scrum is a very popular framework for managing the software development process. It has a small number of roles, artifacts and meetings, which makes it easy to grasp. Scrum gives you some guidance when starting out with an agile development process. It is based on multidisciplinary teams that are authorized to do whatever is necessary to deliver working software to their customer, working in short iterations to enable fast feedback and delivery, regularly inspecting and adapting their process for improvements.

More about Scrum can be read here, here and here.

Lean is a mindset. It is used for production environments (e.g. the Toyota Production System) as well as product development environments. Depending on who you ask or what you read, there are several principles you should adhere to. To quote Womack and Jones, these principles are:

  • Identify value
  • Map the value stream
  • Create flow
  • Establish pull
  • Strive for perfection

The Poppendiecks have translated these principles to software development in their book “Lean Software Development” and added twenty-something tools you can use to create and support a lean software development process. Their book is recommended reading (if you haven’t already).

More on lean can be read here, here and here.

Kanban is very closely related to Lean. When people use the term Kanban, they mostly mean “kanban system”. A kanban is literally a “signal” that can be used to trigger activities in your value chain. In fact, a kanban is a tool to implement lean principles like flow and pull. Every piece of work needs to flow through all activities to create value for the customer. Kanbans are used to make sure that there is not too much work-in-progress and everybody in the value chain focuses on the work at hand. A kanban also points out bottlenecks in your value chain if a certain activity takes unusually long and redirects all efforts in the value chain to elevate the bottleneck.

More on Kanban can be read here and here.

To me, Lean and Kanban are synonymous with respect to software development. The Kanban movement promotes a lean process to deliver software. It lets you think about your value stream, gives you tools to make work flow and lets the customer pull that work. Combined with a regular reflection on process improvement, Kanban equals Lean.

Scrum and Lean are not synonymous. However, they do share common ground in their principles. Scrum has a strong focus on value creation (just as Lean), limits work-in-progress to a “sensible” amount each iteration, puts the customer in control (pull, which is controlled by Sprint Planning) and has regular process improvement meetings (Sprint Retrospective). They mostly differ in how they apply practices and tools to the situation at hand.

Scrum and Kanban are also not synonymous (which follows logically from the previous two paragraphs ;-) ). To me, the biggest difference is whether to use iterations or not. The Kanban movement eliminates the need for iterations, while Scrum makes extensive use of iterations.

The real question is of course not what differences, similarities and compatibilities exist, but what method/framework/mindset to use? The consultant answer here is, “it depends”. Every project, team or organisation has its own context where one or the other may be a better fit. There is no “single best answer”. Generally, I would advise Kanban in a context where priorities tend to change much quicker than the length of an iteration, while Scrum is a better fit if priorities are usually stable throughout the length of an iteration. And I would advise everybody to use lean principles in every problem at hand, no matter what tool you will use to solve it :) .

Share

Possibly related posts (automatically generated):

  1. Final Sprint Looks Like Kanban

  1. [...] I said in my previous post, “Kanban, Lean and Scrum Are Not Religions…”, it depends on your situation what tool suits you best. For almost a year, we used Scrum. For the [...]

Leave a Reply