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

Photo by One man’s perspective.


  1. I think these principles are universal:
    * Eliminate Waste
    * Create Knowledge
    * Build Quality In
    * Defer Commitment
    * Deliver Fast
    * Respect People
    * Improve the System
    It resonates a lot with Kaizen practiced by Toyota.
    Love these principles, love Kaizen!

  2. Nice article, Cory! Great introduction to Lean/Agile in software development. I generally focus on the principles behind lean and agile, with their intersection creating my rules of software development. There are great ideas in both camps, and it makes total sense to combine those, IMHO. As long as I focus on the principles, I can leverage the practices that abide by those principles, or even invent my own and be successful.

    Thanks again!

  3. Thanks Corey (and JD) for bringing this piece together. Honestly, I was unaware of “Kaizen” till today. I have been doing all sorts of reading on Kaizen, Toyota’s model and others.
    I also read an article on how GM should have adopted Toyota’s philosophy, instead of their “command & control” approach. Apparently they have been having problems with their model since early 90s, and did little to change it. On the contrary, Wipro, an IT company based out of India, adopted the model and has seen success & growth (improvement to the tune of 43%).
    I’m quite sure Kaizen is not meant for a one man s/w team (my case), but I plan to learn & master it, and adopt it for life itself.

    Thank you.

  4. Six Sigma and continuous improvement are core Japanese business practices. Improving efficiency, creating value and reducing cost are its main points.

    Mass production (e.g., cars) was focused on value/quality/efficiency (Toyota) or decorative add ons (GM/Ford). GM/Ford built a few core car platforms and then added items only for looks (tailfins, pin stripes, etc.) instead of improving efficiency, adding real value and building in better quality. This is why Toyota does better than GM. Toyota/Honda limited their franchise numbers (number of dealerships) while GM/Ford sold too many franchises.

  5. I appreciate the comments. Interesting that they all focus on continuous improvement. That is a big part of what we’ve been after: creating conditions where improvement is understandable and possible in the real world, and not just an empty slogan. Focus on limiting work in process and delivering work in small batches all the way through deployment makes problems and opportunities to improve more obvious to everybody.

  6. Nice article! I’m completing my business/IT degree now after many years working in IT companies both large and small. I have now covered these Lean systems approaches from both operations management and software engineering perspectives.
    I think the core concept that can be applied to software engineering is that quality is determined by the customer, and if what we’re doing doesn’t benefit them, in a way thats visible and tangible to them, then we probably shouldn’t be doing it at all. This can as often be a matter of managing expectations as it of design or delivery.
    Most of us are in IT because we love learning the latest tools and playing with the new technology. But I’ve seen many projects go to hell in a handbasket when a clever engineer pushed for something the customer didn’t want or really need. In the end the customer ends up disappointed by either the quality, timing or cost of the project, and thats not good for us as developers or vendors.

  7. I am pursuing my Lean Six Sigma Black Belt and have many years in application development. How about taking this thinking one step further and apply Lean Six Sigma to applications development? Lean alone is not enough and adding Six Sigma is not enough. Lean Six Sigma takes the best of both to add more value combined than it would separately.

Comments are closed.