Home > Gemba Coach> Is agile project management simply lean thinking applied to software development?

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

10/8/2018
Permalink   |   4 Comments   |   Post a Comment   |  
  |   RSS

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.

 

4 Comments | Post a Comment
Carl Watt October 10, 2018

A fascinating article, forced me to think, thanks so much for sharing your wisdom with all of us!    To me there is no real difference between Lean and Agile, especially Agile Kanban.  Vive la France!

 

  To me the main problem for agile is that every time a consultant writes a book on Agile, that becomes a separate named religion leading to the early errors of lean - focusing on copying  what is done, not why it is done.

Nigel Thurlow October 15, 2018

I have huge respect for Michael and he writes some wise words here.  I have being writing on this more and more recently.

Lean and Agile are hugely complimentary, and one was, and remains, highly influenced by the other.  The creators of Scrum and eXtreme Programming all cite Toyota and many ‘lean’ practices are included in their own approaches and teaching.  The Agile Manifesto was created by the exponents of those approaches.

Agility is NOT Scrum as many seem to think, and although this article does not delve into that I am calling it our here anyway. 

Agility is about a business or organization being able to respond to change rapidly whatever that means to them.  It does not necessarily mean doing sprints in 1-4 week iterations.  If you are making house bricks you probably do not need to ship iterations of bricks weekly.  They're not going to change that rapidly.

Agility could be how do we ship a new car model every 12 months.  How do we ship a new phone every 6 months.  This is business agility.

Lean is about flow.  Getting the value to the customer as quickly as possible, with high quality and low cost.  Agility is about responding quickly to the changing needs and demands of the customer or market.

Scrum adds something that IS MISSING in lean, and that’s the customer feedback loop.  To be able to respond to your customers more effectively you need to be listening to them and adapting your products rapidly to achieve business agility.  The feedback loop will again be determined by your products and customers.  Ask yourself how often do you invite real customers to inspect your products while you are designing and building them, and how quickly can you change the design and build based on their feedback?  That's agility.

Computer software needs to change rapidly, but a tea kettle less so.  For an automotive company being able to update the features of a car more often than every new model is a reality, so no matter how lean we are and how high quality we are, if we are not responding to customer demand rapidly enough we are NOT agile.  Lean and Agile are subtly different things, but I would posit we need both in this 4th industrial revolution.

Nigel Thurlow - Chief of Agile Toyota Connected 

Thierry October 17, 2018

Michel says: "Agile Software développement accept only single loop and Lean is a double loop learning process."
 
For me single loop in agile software développement is a part of agile activity. But this  concern essentially " scope variability".
New imputs from business may change the scope of what is produced by the team. This is about backlog features prioritization and trade off between team and Product owners about what is going to be produced.
But other changes, as how the team builded the product, could be  double loop and  not just realtime adaptation.
An answer for  software engeneering  about  the "lean standardization way" is  "automatisation". From my point of vue, building, integrating, testing, deploying, all this activities are double loop learning path with an active capitalisation throught automatization. All this activities create artefacs that you could consider as standards builded and maintened by the team and a way to make better  products faster.
Do you aggree?

Ken Eakin November 26, 2018

Great article.

Seems to me that Agile, or an agile approach, is more pertinent to developing new products and services, where the outcomes are largely unknown (we've never built this before...) and customer desires are likely to change rapidly.

Lean is more pertinent to ongoing operations, where we repeat processes that have a fairly clear target outcome.  In such a context, we can improve, document and learn what works and what doesn't work.  And then improve it again on the next round. 

While there are some repeatable elements to Agile-style project work, there are fewer of them.  The trick is to apply Lean thinking for the repeatable stuff that can be standardized and Agile thinking on the more non-repeatable ("improvisational") stuff that cannot be standardized. (I believe some work cannot and should not be standardized).

Other Michael Ballé Related Content

Gold Mine Master Class

Books

Articles

Webinars