A few months ago I was participating in a heated debate on whether lean and agile were compatible. My gut feeling was that they are absolutely compatible! But since the person arguing against me was no less than Michael Ballé himself, THE lean guru, who showed a very deep understanding of agile (as he does with most things…) I had to think harder.

My opinion was not based on nothing. First, the lean and agile communities are quite similar and often have intersections. If you type “lean agile” in Google you will find millions of answers.

Second, the devops movement, an extension of agile beyond the software development team, is visibly based on lean ideas. It regularly refers to concepts such as kaizen and jidoka in the context of features flowing from devs to ops to production. And lean is part of the CALMS acronym used in the devops world which stands for: Culture, Automation, Lean, Measurement, Sharing.

Finally this resonates with my own experience! I was first introduced to agile through Scrum and XP back in 2010. Impressed by how agile was able to create a great working environment while solving most of our project management issues, my co-founder and I were wondering how we could agile-ify everything in the company. Getting more and more involved in the agile community I signed up one day for the “agile open”, not knowing exactly what to expect. The “agile open” was a 2 day giant open-space in the middle of nowhere which is where, the legend says, Patrick Debois came up with the name of devops. And this is where I met Antoine Contal, our first lean coach. I still remember Antoine introducing himself as “an enthusiastic early-adopter of agile who had then been disappointed by some limits in the context of a large organisation and found in lean the answers to these limits”. Antoine introduced us to lean and we did find an approach that was compatible with what we loved in agile but with many more theories, tools and principles that could be applied everywhere in the organisation, not just software development.

So why would Michael Ballé challenge this? His rebuttal is based on two things. First he knows agile works incredibly well in small teams, but challenged me to show him a successful scaled version, true to the agile manifesto. And if the agile manifesto cannot scale, it is incompatible with Lean, a framework designed to work for an organisation as large as Toyota or Amazon. Second the agile manifesto itself: if you look at the four core values of the agile manifesto, none of them are compatible with lean. Lean is heavy on processes, tools, documentation and plans. All things the agile manifesto is rejecting ostensibly!

So why is it that I still believe agile and lean to be compatible?

What I feel when I read the agile manifesto is that this was written by a group of very talented and independent-minded software engineers reacting to the bureaucracy of large organisations. One way to read the manifesto is as a cry for liberation from bureaucracy: “Please, no more of these stupid processes over-emphasising paperwork and constant negociation on an old plan that nobody believes in anymore! Can you just trust talented individuals to deliver regularly and collaborate effectively to deal with change?”. This is why I believe agile has been so popular in the last 2 decades: everyone who has been faced with the absurdity of bureaucracy has wanted to scream something similar. The agile manifesto did it for all of us!

And this is where I see the common root of lean and agile: they are both reactions to “The Big Company Disease”, the name Toyota gives to the forces of bureaucracy creeping into every large organisation. Agile is the reaction of talented independent-minded people in the software industry against that disease. Lean is the strategy and framework designed by Toyota against that same disease.

So what would the agile manifesto look like if it wanted it to be visibly compatible with lean? It would probably include these four core values:

Respect for People

The first agile value is “individuals and interactions instead of (stupid) processes and tools”. I would replace it with the first foundation of the TPS house: Respect for people. Respect for people is about making sure that processes and tools are designed to help the people do a good job and learn. This includes 5S, problem-solving and TPM.

Lean brings a lot of processes and tools. One cannot imagine scaling at the size of a Toyota or an Amazon without them. But lean agrees with agile that they need to be at the service of the people and their teams, not done for the sake of management and bureaucracy.

Built-in Quality and Just in Time

The second agile value is “Working software over comprehensive documentation”. I would replace it with the two pillars of the TPS house: “Built-in Quality and Just in Time”.

Built-in quality is about making sure that everything in the organisation is done to support the best quality and that includes designing the flow to provide regular inspection and trigger the “andon”, the red light that tells the team to stop as soon as a defect is detected to react to it on the spot. Jidoka in lean also includes separation of man and machine and pokayoke.

Lean expects the teams to document their best practices, for better knowledge sharing within the team and for newcomers, which is key to maintaining the highest quality when you scale. But this documentation is designed by the team for the team and updated whenever the analysis of a new defect produces a new learning.

Just in Time is about making sure there is a very regular pull to strain the system to make defects emerge earlier. Just in Time includes takt time, kanban and smed. “Working software” which in Scrum is about delivering working increments at the end of every sprint is exactly that: an artificial constraint to detect issues earlier and learn faster.

Value for Customers

The third agile value is “Customer collaboration over contract negotiation”. I would replace it with the roof of the TPS house: “Value for customers”. Value for customers is there to remind everyone that the goal of the company is to create value for customers. Creating value for customers requires understanding very deeply what value means to them, which requires indeed trust and collaboration. But in lean it is very clear that the goal at the end of the day is to meet the customer’s expectations with higher quality, shorter lead times, reduced costs, better safety and less impact on the environment. Yes this requires trust and deep understanding rather than contract negotiation, in line with the agile value. But it is a much more demanding north star than “customer collaboration”, high standards necessary when you want to scale fast and successfully.

Continuous Improvement

The fourth agile value is “responding to change over following an (outdated) plan”. I would replace it with the second foundation of the TPS house: Continuous improvement. Continuous improvement is about making sure that everyone in the organisation is engaged in small experiments to improve the work and the system. This includes Heijunka, standardized work and Kaizen.

Lean does not reject plans, on the contrary. Being scientific about work requires one to have thought about the theory and expressed clear hypotheses before doing the experiment. But lean, like agile, embraces change. Lean is all about doing a lot of small improvements at every level of the organisation to continuously improve and update the plan with the new learnings. Lean is, like agile, against a grand plan imposed by the top, oblivious to changes and ignorant of the reality of daily work. It promotes instead continuous improvement as a way to plan for change.

This “lean manifesto” is for me an illustration that lean and agile are compatible. But it also shows that lean includes so much more. The best implementations of agile I have seen or heard of are small teams of talented and dedicated people working on an exciting project. On the other hand, the best implementations of lean we know of are Toyota, Pixar, Amazon… some of the fastest growing and largest organisations in the world.

If you adopted agile because you wanted to fight the “Big Company Disease” and you are wondering how to scale that fight… I believe you can save a lot of time by learning from those who succeeded with lean.

Here is my way to make the agile manifesto more lean and therefore scale-compatible.

Lean Manifesto

We are uncovering better ways of running businesses by doing it and helping others do it.

Through this work we have come to value:

VALUE FOR CUSTOMERS (over Customer collaboration over contract negotiation)

RESPECT FOR PEOPLE (over Individuals and interactions over processes and tools)

BUILT-IN QUALITY AND JUST IN TIME (over Working software over comprehensive documentation)

CONTINUOUS IMPROVEMENT (over Responding to change over following a plan)

That is, while there is value in the items on the right, we value the items on the left more.