Is agile project management simply lean thinking applied to software development?

Dear Gemba Coach,

You seem to distinguish between agile and lean, but to my understanding, agile is simply lean thinking applied to software development. Am I missing something?

Okaaayy … let me see if I can wade into that mess. The first difficulty to address is that there is “agile,” as most organizations practice it, and “real agile,” as its founders envisaged it. Then there is “lean” as most companies practice it and “real lean,” as Toyota-inspired leanheads practice it. For argument’s sake, let me call the mainstream version of agile and lean “lesser agile” and “lesser lean” versus “higher agile” and “higher lean.”

Lesser agile is about producing software through the fast delivery of small iterations, with frequent customer validations, and structured autonomous teams. The core idea is that instead of defining the entire specifications upfront and then moving through requirements, design, code and test, system testing and user acceptance and rework, and delivery in massive batches, one can take feature by feature and write user stories which are coded in short sprints, with customer approval at each step. The key tools of lesser agile are:

• User stories,
• A “two pizzas” autonomous team (how many people you can feed with two pizzas),
• Sprints,
• Automated testing,
• Team boards with the agile version of “Kanban” (nothing to do with real kanban),
• Burndown charts.

Lesser lean is about introducing operational excellence to improve processes because there are no bad people only bad processes, and any process can be fixed through greater standardization. Lesser lean is about making teams more autonomous to create better flow through improvement projects, reducing batches where possible and studying every operation to standardize how it’s done and react more quickly to variances through daily rituals. Classic tools of lesser lean are:

• Value-stream mapping to map the process,
• Stable teams and daily briefs,
• Kanban,
• Stop at defect and escalation of problems,
• Standardization,
• Visual boards for performance management.

Evils of Two Lessers

On the face of it, no big difference. First, organizations feel they have transformed when they move from traditional operations to lean in production and agile in software development. Secondly, they do see initial results – though often not enough to offset the out-of-pocket cost of the “transformation.” Thirdly, these results tend to evaporate in the second or third years as these changes don’t often stick and organizational pressures revert to the mean.

Unfortunately, too often, what remains on the gemba is the vocabulary as day-to-day behavior reverts to the usual planning by bosses, setting targets, monitoring progress, and reward the guys with results, punish those without. I visited a factory this summer with “kanban” cards which were nothing else than production instructions: the kanban didn’t originate from the downstream process, but were generated by central planning and placed on boards in each team – and, what is more, in batches. Check out this funny picture of a heijunka box used to produce in batches:

I’m told the same happens with agile teams where the “agile” vocabulary and look and feel often hides traditional waterfall planning and experts organizing the work of teams.

Lesser agile and lean are essentially about fixing the process and pushing it onto people to make them more performant. The founders of agile themselves insist that most of what people call agile these days is not what they have in mind. “Higher agile,” had three core intents:

• Truly autonomous teams that constantly change their own work processes in order to adapt to changing environments. It’s what it says in the manifesto: individuals and interactions over processes and tools. Change is at the heart of the agile project, and teams should be really independent, without anything imposed on them to let them find truly innovative ways to respond.
• Technical excellence is key to producing good software – not just team feel-good motivation. Particularly in a world where the tools themselves evolve so fast, technical skills are half the battle and addressed in agile with “refactoring” – the improvement of one’s own code – that so few teams do or allocate time for.
• Product focus is the first thing that disappears with developing user stories piecemeal because a sum of features doesn’t make a product. The higher agile point here would be to abandon projects altogether (yikes – how will the director report progress?) and organize teams around full products with the aim of finding the sweet spots for the customer that truly make a difference.

Similarly, Toyota-minded students of lean would not recognize anything “lean” in the lesser lean approaches. As Tracey and Ernie Richardson have coined it, “lean is a system for the continuous development of people.” Indeed the one slogan we find in every Toyota factory I’ve seen is “good thinking, good products.” The key intentions of lean are:

• Produce a flow of products at a regular rhythm that each completely satisfies customers by blending robustness from accumulated learning and innovation to stay in the spirit of the times. This is achieved by a system of “chief engineers” who design the product in full and work with the functional silos to bring the product through design, process design, production and supply chain all the way to customers.
• Create the conditions to continuously create value, as opposed to simply produce value. Producing value means making more of the same consistently. Creating value means finding new ideas to make it safer, better, faster, cheaper. The Toyota Production System is not a system to manage performance, but a system to reveal problems as opportunities for improvement. As muda is made visible by the various TPS techniques, so people can take responsibility to tackle it, think harder, and come up with a better way of working.
• Creating value starts with revealing waste (unnecessary activities needed to deliver the completed work) and solving problems in order to eliminate this waste. This involves developing a culture of problem solvers who both, better understand the standard, repeatable parts of their jobs and also seek insights and take initiative to change things in order to find a better way. The assumption is that people understand better what they do on specific problems, they understand better their jobs in general, and make better judgment calls day to day.

Profound Differences

Higher agile and lean are essentially about better leveraging individual skills, talents, responsibility and initiatives to create better products, deliver them more reliably through better processes and, as a result, become more performant – even un volatile, uncertain, complex and ambiguous conditions.

“Higher agile” and “higher lean” have both in common a focus on products and developing people skills, and they have a common starting point: releasing several times a day, good products forced you to think differently about how you work. But they go about it in very different ways.

The agile approach is to give more independence to teams. The basic assumption is that by reacting and changing, people learn. This is what is called technically single-loop learning:

The lean approach expects a much more standardized approach to repeatable work, identifying problems with it, thinking deeply about the problems with the response and trying something new – mostly to better understand the problem first and then fix it so it stays fixed. This is called double-loop learning.

I realize this might sound abstruse – you’re probably thinking, Yeah, well, I’ll get to that once I’ve done the basic stuff. But the difference is immense. In agile thinking we consider things happen only once, and by having smart people adapt continuously, they’ll gain experience and find effective ways to get them done. All evidence from the study of human learning shows this only leads to developing habits and heuristics – some clever, some not so much, but all of them hinderances to deep learning.

Lean thinking, on the other hand, tries to separate the repeatable aspect of the job from the improvisation and study both differently: first, make the impro repeatable and look for the waste in it – and eliminate it. The underlying learning theory is that 1/ we need to master what is known knowledge – known standards – in order not to reinvent the wheel every day and then 2/ we need to query gaps and what doesn’t work as expected because some of these standards are wrong and need changing.

The agile approach is: listen to everything that is going on and change accordingly to adapt.

The lean approach is: know what you know, focus on one challenge where clearly things don’t work out as you’d expect, and change one thing after the other to discover which knowledge is still valid and which needs to be changed.

The key point is that these learning methods lead to very qualitatively different types of solution. Agile thinking leads to Tesla, lean thinking to Toyota. Both disruptive innovators, but in very, very different ways.

Now, this is my very personal point of view on a difficult issue where everyone has a different understanding of what is what, and I’d love to hear your own opinion and comments. But for what it’s worth, yes, I do believe agile and lean differences are profound enough to merit distinguishing between the two, and indeed, experimenting more with “higher lean” in software development as well.