Agile Vs. Lean: Yeah Yeah, What’s the Difference?

Been getting a lot of questions lately, so thought I’d take a stab at this…

Lean

Lean comes from Lean Manufacturing and is a set of principles for achieving quality, speed & customer alignment (same as what we’re trying to do with agile development, right?).

Mary & Tom Poppendieck adapted the principles from Lean Manufacturing to fit software development and I believe these ideas actually provide the premises behind why agile works:

In a nutshell, Lean says to relentlessly eliminate anything that isn’t adding value and only work on what we absolutely need to be doing at this moment in time. Eliminating waste means eliminating useless meetings, tasks and documentation. But it also means eliminating time spent building what "we know” we’ll need in the future (things are constantly changing so we often end up not needing them – or if we do, we have to rework them because conditions and our understanding has changed by then). It also means eliminating inefficient ways of working – like multitasking (!) – so we can deliver fast.

Lean also puts a very strong emphasis on what it calls “the system” – that is, the way that the team operates as a whole. We always need to be looking at our work from a top level to ensure we’re optimizing for the whole. For example, many managers want to “optimize” individual developers by ensuring they’re always at 100% – but most of the time, this is actually counter-productive. Let’s not have people coding something that isn’t needed (or fully defined yet) just for the sake of coding, because that actually creates more work for us in the future (see: Why You Should Let Your Developers Surf).

Along those lines, Lean says to respect that the people doing the work are the ones that best know how to do it. Give them what they need to be effective and then trust them to do it. Software development is about learning, so structure the work to ensure we’re continuously learning. And because of that, defer decisions until the last responsible moment (because we’ll know more by then). Finally, develop in a way that builds quality into our product, because there’s no way to continuously deliver fast if we have to keep going back to clean up our messes.

“Organizations that are truly lean have a strong competitive advantage because they respond very rapidly and in a highly disciplined manner to market demand, rather than try to predict the future.” – Mary Poppendieck

Agile

Agile refers to a set of values and principles put forth in the Agile Manifesto. The Manifesto was a reaction against heavyweight methodologies that were popular, yet crippling software projects from actually doing what they needed to do – create software that helped the customer! I believe Agile’s values & principles work because of the science behind Lean and so you’ll see a lot of similar themes repeated in agile.

The Agile Manifesto’s values are:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

And it’s principles are:

Any project that follows these values and principles can rightly be considered to be agile. That said, there are definitely preferred practices that are common for agile teams to follow in order to achieve agility. Most commonly:

• Scrum or Kanban (or a hybrid of the two) for “Management Practices”
• Extreme Programming (XP) for Technical Practices (with new practices becoming popular, largely from Lean Startup – such as Continuous Deployment and Testing in Production)
  
  

A good agile team picks and choses the management & technical practices that best work for them. (a bad one just picks a couple of practices and falsely believes that somehow “makes them agile” – see: Are We Agile Yet?).

In Part II, I’ll post summaries of these agile methods and practices. (stay tuned!)

Photocredits: Contortionist by Amber Kenneson