How do the Agile, Lean and Kanban methodologies relate? [closed]

Question

I'm basically familiar with Agile methodology and Scrum.

But what is "Lean Software Development" and "Kanban"?

Is it safe to say that Scrum, Lean and Kanban are implementations of Agile methodology? Or are Lean and Kanban different methodologies?

Do Lean and Kanban provide a skeleton/guideline (like Agile) and leave the implementation to an adjacent set of practices, like XP and Scrum?

Answer 1

Actually, neither Agile nor Lean have a precise definition. Both cases are rather about a set of principles and practices – in the former case, basing on Agile Manifesto, whilst the latter is based on the Toyota Production System adapted to software/IT industry.

I would say that both Lean and Agile are two flavours of the same movement in the software industry – focusing on effective delivery of products which customers actually need (this is a vast generalization though). The difference lies in the ways this goal is achieved.

With Agile, the focus is placed on establishing a well-organized process, which allows frequent delivery and enables easy adjustments to the customers` needs during the course of development. Lean focuses more on limiting "waste" (including work in progress which is considered as one of types of waste) and making the production and delivery workflow as efficient as possible.

It is often that agile and lean approaches are put into the same bucket, so you will find all sorts of mixing – Scrum + Kanban is the most significant example; refer to Scrumban for more information. Unless you talk with an orthodox it shouldn't be a problem if you label Kanban as an Agile method.

To make some order in labels: Agile and Lean are general concepts. Scrum and XP are specific implementations of Agile, while Lean Software Development and Kanban are specific implementations of Lean.

At least this is how people usually perceive them. It is definitely possible to mix different approaches, or single practices thereof, into one method. Scrum+XP or Scrum+Kanban are probably the most popular combinations.

If you want to dig deeper, I can recommend a great mini-book which compares Kanban to Scrum: "Kanban and Scrum – Making the most of both". The eBook in PDF form can be downloaded for free.

Answer 2

Agile expert Mary Poppendieck wrote about the principles of Lean. Find her credentials here.

Instead of me writing a lot about Kanban, please read what Swedish advisors Crisp say about it.

The practices of Lean are quite different from the hands-on, practical tasks that programming-centric XP asks you to do in your project ("Automate everything", "Have tests", "Meet daily"). Value-stream analysis could give you some new insights and conceptual tools with which to reason about business and tasks to do.

Hope this helps navigating the process-speak. Best of luck!

Answer 3

At the risk of irritating purists, and from a practical perspective, Lean is the highest level of abstraction whose principles and (most) practices can be applied across the entire enterprise. Your CEO will understand and buy-in to Lean. In my experience, linking Agile at the tactical level to Lean at the enterprise level makes for a much easier sell to executives.

Kanban in manufacturing is an inventory queue management technique. As applied in knowledge work (not just IT) it is a workflow visualization and queue restriction technique designed to focus teams on the smallest batch of work possible at a time to speed flow. It can be as simple as sticky notes on a whiteboard with tape lines marking off process step left to right. Or there are electronic Kanban tools available (standalone or add-ons to all of the main ALM tools)

Kanban can be easily applied as a tool for Scrum teams simply by treating the kanban board as representing your iteration. You (try to) only allow work onto the board at the beginning of the iteration and it needs to be in the done lane by the end of the iteration. And, using horizontal swimlanes, you can effectively segment the board into sections for planned work in the iteration and the (sadly inevitable) operations support work that interrupts even the most disciplined teams. This make it very clear what work was committed and what snuck into the sprint.