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:
- 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.
- 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.