Introduction to Lean Software Development

Editor’s note: This is a guest post on Lean Software Development by Corey Ladas. If you don’t know Corey, he’s a product development methodologist. He brings more to the table than most on engineering process because of his background working on integrated mechanical / electrical / software products.  What I like about Corey is his ability to take start of the art and bridge the gap with state of the practice. He has an uncanny ability to boil complex things down into their essence. without further ado, here’s Corey with an introduction to Lean Software Development …

The application of Lean principles to software development process requires interpretation, and there is more than one school of thought about the best interpretation of Lean Software Development.  Some focus on Lean principles applied to common development practices, some focus on workflow management, others focus on complementary product development processes used by Toyota and other Lean producers.
Five Principles of Lean Thinking
The principles of Lean Thinking are necessarily abstract compared to the detailed methods used by Toyota for making cars, but this generalization allows of to think of a great variety of business applications.  The authors of Lean Thinking, Jim Womack and Daniel Jones, define the five core principles as:

• Specify value from the standpoint of the end customer by product family.
• Identify all the steps in the value stream for each product family, eliminating every step and every action and every practice that does not create value.
• Make the remaining value-creating steps occur in a tight and integrated sequence so the product will flow smoothly toward the customer.
• As flow is introduced, let customers pull value from the next upstream activity.
• As these steps lead to greater transparency, enabling managers and teams to eliminate further waste, pursue perfection through continuous improvement.

Why Lean – The origin of Lean Thinking in the Toyota Production System
The history of business over the last two centuries is largely the history of industrial mass production.  Methods of accounting, project management, organizational design, and many other institutions of business culture developed in service of the needs of mass production.  The success of mass production has been so profound and so enduring that its practices have become synonymous with the practice of business in general, even when those practices are inappropriate for the specific problem at hand.  Mass production became traditional, traditional practice is taught in business school, and when all you have is a hammer, everything looks like a nail.
Unfortunately, there are a wide and increasing number of business problems for which mass production thinking is poorly suited.  Software development would be a major category.  There has been an ongoing mismatch between traditional business practices and the needs of software development throughout the entire history of software development — a fact which has been greatly lamented over the years, often under the label of “The Software Crisis.”

Sometimes it takes an historical event to disrupt an historical process.  In the case of mass production, it was the recovery of post-World War 2 Japan, and the emergence of the Toyota Motor Company as a global producer.  Mass production assumes a) capital is scarce and must be optimized, and b) the market wants large quantities of a limited variety of goods.  Toyota found itself in a situation where a) labor is scarce and must be optimized, and b) the market wants limited quantities of a wide variety of goods.  Japanese consumers expected comparable value and quality from Japanese producers as they did from American producers, but Toyota could not support the economics of mass production in the marketplace of postwar Japan.  Faced with such circumstances, Toyota’s only options were to exit the business or get very creative about how to make automobiles.  They got creative, and today they are the largest and most successful auto manufacturer in the world.

The problems that Toyota faced foreshadowed the problems that an increasing number of businesses would face in the late 20th century:  customers want more variety and better quality, and they want it now.  Traditional business practices are often poorly suited to deal with these expectations, and management theorists became increasingly restless in their pursuit of new understanding.  Much as the industrial practice of yesteryear evolved into more general business practice, the principles of the Toyota Production System were abstracted into the general business philosophy we now call Lean.

The Metaphor School of Lean Software Development
Since software development is really nothing like assembling an automobile, it will require some interpretation in order to make sense of Lean principles. The first school of thought in Lean Software Development is the interpretation of Lean principles in terms of native software development methodology.  If we can identify existing methods that are analogous to concepts in Lean, then this will help us deliver the value that Lean promises or help us align software development teams with a surrounding Lean business.

The founders and chief proponents of this school of thought are Mary and Tom Poppendieck, publishers of the popular Lean Software Development series of books.  The Poppendiecks interpret the general Lean principles into something more intelligible for software development:

• Eliminate Waste
• Create Knowledge
• Build Quality In
• Defer Commitment
• Deliver Fast
• Respect People
• Improve the System

This approach to Lean software development has been attractive to some who believe that software is fundamentally a craftwork discipline.  The individual craft mode of production is inconsistent with a strict interpretation of Lean, so craftwork proponents that are sympathetic to Lean tend to favor a more abstract interpretation.

The Agile software movement have been the most visible proponents of the craftwork philosophy in recent years.  The part of the Agile community that has adopted Lean thinking typically calls their flavor Lean/Agile development.  Lean/Agile proponents typically describe practices of methods like Scrum or Extreme Programming in terms of Lean principles, and sometimes modify or elaborate on those practices accordingly.  Craig Larman and Bas Vodde are notable proponents of this view, as expressed in their recent book Scaling Lean & Agile Development.  Alan Shalloway and Curt Hibbs are also well-known advocates of this approach.

The Workflow School of Lean Software Development
Another major school of Lean thinking in software development is more focused on management and is more comfortable with words like “software engineering.”  This “workflow school” believes that the majority of software development processes can be described in terms of…workflow, and that any workflow process is directly subject to the five principles of Lean Thinking, without need to abstract away the details.  There have been a few false starts since the 1980’s, but the modern founder of this approach is generally considered to be Donald Reinertsen.

Peter Middleton and James Sutton are advocates of a Lean approach to software engineering, including the application of systems engineering methods like Quality Function Deployment and software engineering methods like formal specification.  Enthusiasts of Tom Gilb’s evolutionary delivery approach to software engineering have been reinterpreting and updating some of Gilb’s methods in terms of Lean ideas.

The workflow school has experienced substantial growth over the last two years, with the adoption of the kanban style of workflow management popularized by David Anderson.  My book, Scrumban, is the first book to describe the kanban approach in detail, but there are a growing number of sources online.

Describing Lean software development in terms of “schools” might paint a more adversarial picture than is actually the case.  Most teams using kanban systems today would consider themselves to be Agile teams, but perhaps an emerging second generation of Agile that embraces Lean more openly.

Additional Resources

• Corey’s Blog – http://www.LeanSoftwareEngineering.com/
• Lean Thinking, James Womack and Daniel Jones
• Lean Software Development, Mary and Tom Poppendieck
• Scrumban: Essays on Kanban Systems for Lean Software Development, Corey Ladas

Photo by One man’s perspective.