We don’t use Lean, we use Agile. Which one is better?

We don't use Lean, we use Agile. Which one is better?

Ah, this is a question I have a love hate relationship with. I hate it because the fact that this question exists, is evidence as to how misused both Lean and Agile can be, but I love it because it is also what keeps me in a job, and I love answering it. Now before I continue, I want to say that all of what you are about to read in this article is my perspective, and I am open for debate on the matter (and you’ll see why later!).

Firstly, for me I like to make the point that I believe there is a distinct difference between Lean as it was intended and Lean as it is typically used, and therefore I believe the same can be applied to Agile. In the context of continuous improvement, Agile and Lean are adjectives, not nouns. The very fact that we use them as nouns (things we use) as opposed to using them as adjectives (things we can become) is very much part of the problem. The original documentation was called "Manifesto for Agile Software Development" (adjective) not "The Agile Manifesto" (noun), a point Dave Thomas makes in his article “Agile is Dead” [1].

If we look at them at the surface methodology level, you may often see comparisons between the two as something like this:

Well... which is better?

I am not saying that I entirely agree with this summary, but it is a typical one seen. At the top-level, they are trying to accomplish the same thing, which is making teams autonomous, taking control of the work that they do, and continuously adapting along the way to maximise productivity, or shorten lead time from order to fulfilment, but they approach this with different methods, that are better for different environments.

From a practical point of view, if you see Lean as a productivity gain method that requires you to standardise all of your processes so that you have a more consistent output, then Agile will absolutely be a significant improvement in the context of releasing small incremental changes to an end-user without having to standardise the work. And Agile is always a significant improvement over Waterfall practices. However, we still have some common problems arise:

• Do these features actually add value to the customer? More features ≠ more value.

• As we make a change, how does this affect the rest of the process/product that we didn’t foresee? And do we hope that we can solve those problems and their nuances later?

• How well do we truly assess the quality of the output being delivered?

• Do people who choose the work they do, take the tasks that have minimal roadblocks or barriers because that is simpler, easier, and more productive?

• Are we Agile, or just waterfall practice in disguise?

In that sense, Agile has solved some problems, and created others. Very much the same way that Lean will when applied with a productivity lens. When seen with a productivity lens, both are fundamentally taking a ‘find a problem and fix it approach.’ This is where it diverges from Agile or Lean as originally intended. Neither are methodologies or tools that you “do,” they are behaviours you follow in order to become them. This is why Dave Thomas has argued we should retire the world ‘Agile’ and instead say we are trying to encourage ‘agility.’

So, when you ask which is better, I will say you’re asking the wrong question. I would sooner ask:

• What core culture, values, and behaviours do we want? See Competing Values Framework [2] and Lean Transformation Framework [3].

• What management approach will enable the behaviours we want?

Let’s compare these learning cycles, one is a take on Dave Thomas' steps for developing agility, the other is the famous plan-do-study-act cycle in Lean:

Agility or PDSA

I’m hoping you’re beginning to see the similarities, and in both, we are effectively cultivating a system of experimentation and learning. Focus on doing rather than excessive planning and learn from the steps you take. When you take Lean as it was intended the reality is we are ‘Managing to Learn’ [4]. That is, trying to make people good learners and problem solvers, not make processes more efficient, that was just the secondary output. Agile as it was intended, I would argue is not much different. However it’s misuse and mistranslation along the way is what has created this beast of a debate.

Now when you ask what behaviours you want to create, this is where I see the two diverge.

Agile focusses on four core values [5]:

• Individuals and interactions over processes and tools.

• Working software over comprehensive documentation.

• Customer collaboration over contract negotiation.

• Responding to change over following a plan.

Give teams the autonomy to make their own decisions, act by collaborating directly with the customer rather than excessively planning, give the customer value early and quickly and respond to changes along the way. As we look at Agile as practiced today; take a step, learn from it, and adapt. This is single loop learning; get better at what you are doing by responding to differences between expected and actual outcomes. This is like having a GPS that calculates the best route to a destination and changes depending on traffic conditions or any alternative turns you make [6].

Same intention, different behaviours

Lean instead, I would argue do not really have values in the same way, but if I were to give it core values, I tend to condense it down to:

• Never pass on a defect.

• Never overproduce. Pull from the customer.

• Never starve the customer (including the next process).

• Create smooth, levelled, uninterrupted flow of value.

• Explore and experiment with deep problem-solving, not solution implementation.

• Go See, Ask Why, Show Respect.

• Maximise value to the customer (see Muri, Mura, Muda).

• Blame the system, not the person.

However, I much prefer James Womack’s and John Shook’s breakdown of Lean focussing on what we call the 3P’s, Purpose, Process, and People [7]

• What is the purpose of the work being done? What problems do your customers face?

• How does the process operate and align to help achieve the purpose of the work?

• How well does the process allow people to achieve the purpose?

• How do the people engage with the process to improve it every day?

• What skills and behaviours do people need to enable the process to succeed?

Fundamentally, Lean is double loop learning; question what you are actually doing, then get better from the challenge. This is like a driver having a destination, but they might pause and ask, is this even the best place to go? Should I take a scenic route instead? Or avoid this city altogether? [6]

Lean thinking starts with standardising the best-known working way so we know what good looks like, identifying when we can’t achieve this through creating abnormality at a glance, and then undertaking a process of deep learning to uncover why. If you are inappropriately using standardised work to force people to become robots by following set and rigid instructions, then I would agree that Agile gives you more flexibility.

When we look at the type of behaviour in Agile, this single loop learning effectively facilitates good behaviours and meta habits by taking steps, giving the customer what they want quickly and iteratively, and responding to issues, changes, or feedback. But this is like tackling the immediate issue in front of you without truly challenging your understanding of the root cause and your underlying assumptions. Lean as intended on the other hand, is trying to facilitate the development of peoples deep thinking and learning capabilities, by knowing what the current ideal state is, and constantly challenging what prevents us from achieving it through thoughtful inquisition and experimentation.

This for me is where they diverge. Both are fundamentally trying to enable people to be more flexible, and both have been misunderstood over time, but one creates Agility in people, the other creates Critical Thinkers. I believe there is perfect room for both, but I also believe that if you are practicing lean as it is intended, it should lead you closer to what the founders of the Manifesto for Agile Software Development initially intended too.

With that, I welcome you to challenge me so I can assess my own assumptions and theories (there it is)!

"Put down your firefighter hat and become an impartial, objective investigator."

John Shook

1. Pragdave.me. (2014). pragdave - Agile is Dead (Long Live Agility). [online] Available at: https://pragdave.me/thoughts/active/2014-03-04-time-to-kill-agile.html.

2. May, E. (2024). The Competing Values Framework Diagram and How to Use It. [online] ICAgile. Available at: https://www.icagile.com/resources/the-competing-values-framework-diagram-and-how-to-use-it.

3. Lean Enterprise Institute (2024). The Lean Transformation Framework. [online] Lean Enterprise Institute. Available at: https://www.lean.org/explore-lean/the-lean-transformation-framework/.

4. Shook, J. (2010). Managing to learn : using the A3 management process to solve problems, gain agreement, mentor and lead. Cambridge, Ma: Lean Enterprise Institute.

5. Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R.C., Mellor, S., Schwaber, K., Sutherland, J. and Thomas, D. (2001). Manifesto for Agile Software Development. [online] Agile Manifesto. Available at: https://agilemanifesto.org/.

6. Argyris, C. (1991). Teaching Smart People How to Learn. [online] Harvard Business Review. Available at: https://hbr.org/1991/05/teaching-smart-people-how-to-learn.

7. Womack, J. (n.d.). The Power of Purpose, Process & People Chairman Lean Enterprise Institute. [online] Available at: https://www.lean.org/wp-content/uploads/2022/05/Womack_Summit_Presentation_2008.pdf.

References