If Agile is going Lean, then get it right

on Apr 8, 10 • by Eric Hollebone • with 3 Comments

There has been a start to bring the concepts of  lean manufacturing  into agile development. Recently, Mike Cottmeyer in How to Build a Large Agile Organization proposes that Agile on its own is not enough for a large organization.  In his view, Agile falls short and needs to be supplemented by...

Home » Agile Development » If Agile is going Lean, then get it right

There has been a start to bring the concepts of  lean manufacturing  into agile development. Recently, Mike Cottmeyer in How to Build a Large Agile Organization proposes that Agile on its own is not enough for a large organization.  In his view, Agile falls short and needs to be supplemented by additional methodologies like Lean or Kanban when coordinating outside the development team.

If adoption of Agile is impeded by its very nature in large organizations and Kanban is the proposed answer, then the Agile solution is insufficient. Agile needs to expand its scope to be relevant and useful for non-developers as well as across development teams.

To understand how Lean applies to Agile development, I’m going to take a short detour though history.

Mapping manufacturing principles to software development is an interesting cross-pollination of ideas. Discrete manufacturing is quite different from application development, but that doesn’t mean the software industry can’t learn a thing or two from a different sector.

Lean was born out of a need to re-invent the manufacturing industry, which had not really evolved since the inventions of Henry Ford and the production line. From Ford’s time to the post second world war period, most manufacturing was very good at making enormous quantities of the same product, regardless of the demand. Ford’s famous quote about color clearly exemplified the thinking of the day: “Any customer can have a car painted any colour that he wants so long as it is black”. In other words, Ford’s production line was optimized for manufacturing, not profit, and turned out to be quite inflexible when market conditions changed.

In the 1950s, Sakichi Toyoda made a revolutionary leap forward with two principles:

  1. Pull vs. push – at any point in the production process, the trigger to start work on a production unit is governed by its upstream neighbor.  As an example, I do not start my work on a product unit until the guy following me says he will be able to receive it.
  2. Efficient manufacturing depends on the management of three key inefficiencies: overburden (muri), inconsistency (mura), and eliminating waste (muda).

Together, these elements formed the underlying principles that Sakichi spearheaded into what is now known as The Toyota Production System (TPS). The TPS has subsequently been used as the the basis for Western derivatives such as Just-In-Time, value-stream mapping, Six Sigma and Lean, to name a few.

So what does this have to do with Agile and large organizations?

There are well-documented cases where agile alone was not enough, and that’s where Lean/TPS can add value.  For the most part though, the application of Lean principles has been limited to just one part: Kanban.

The TPS Kanban methodology has two aspects. First,  a Kanban card is attached to every unit under production and carries contextual information (metadata) about the tasks that need to be performed on that unit  and second, task readiness and data are used to trigger an specific action (work).

Over the past decade, the Agile methodology has been used successfully within  development teams, usually sized between  8 and 15 people. Agile’s benefits and values for this type of environment have been well articulated by many others (including on this blog), but most Agile adopters may not have realized the close mapping to Lean/TPS.

  • Muri (overburden) – overproduction – in an Agile context, this is usually expressed as over-planning
  • Mura (inconsistency) – elimination of bugs at the earliest stages, resulting in more  stable and reliable iterations
  • Muda (waste) – close interaction with the customer to absorb change and prevent wasted iterations
  • Kaizen (continuous improvement) – refactoring, unit testing, system integration

Secondly and more importantly for large teams, the TPS/Lean idea of pull vs. push is key. But there are other aspects of Lean/TPS that would benefit software development, Kanban being an important one but not the only one.

In an Agile context, Kanban is usually expressed as a board or wall with movable index cards to visualize units of customer value and work flow. This is where I think the rails have come off Agile/Kanban compared to the original TPS philosophy.  Kanban is just one gear in the whole TPS methodology.  Its an integral part but no more important than the other parts.  To function optimally, the TPS/Lean requires all the piece to be implemented not just one.

The other aspects of TPS/Lean are:

  • Andon (signage, early warning)  – literally means paper lantern and is used to call attention to a problem in the process.  For Agile, it should be express as how do you measure your team’s progress and convey that information to the whole organization.
  • Jidoka (autonomation) – automation with human intelligence.  The efficient use of tools like static analysis and continuous build to aid in development.
  • Poka-yoke (fail-safing) – not just exception handling, but actual prevention of faults and counter-measure strategies to prevent the fault from reoccurring.

These other parts of the TPS were not born because people like more processes and rules; they came out of need, something the agile methodology has yet to realize it requires.

Related Posts

3 Responses to If Agile is going Lean, then get it right

  1. Hello Eric,
    I like the way that you have laid out the lean principles and practices, it makes them very easy to understand. I am honoured you used a picture of my Kanban board and would agree that Kanban is a part of lean and not the whole.

    Building a Kanban board seems to be a common first step for people to become leaner and I think this is a good starting place for most people as it helps visualise the concepts in lean and start to see the value of lean in their day to day activities.

    I started using a Kanban board as a way to understand what the lean principles meant to me and the people I worked with. With an eye on continual improvement (Kaizen), I continue to evolve the board and card design as well as incorporating other techniques such as pomodoro and parallel thinking to help the lean concepts permeate my work.

    Thank you.

  2. Great insight on incorporating lean with agile. MIKE2.0 is currently trying to work lean processes into our open source agile solution: http://mike2.openmethodology.org/wiki/Agile_Information_Development_Solution_Offering . Would love for you to offer some insight when you have some time.

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top