Motley says: "Lean is for meat, not software"



Motley: I like my steak lean. Software? Not so much.


Maven: Lean goes hand-in-hand with agile, and focuses on eliminating waste, learning, building in quality, deferring commitment, delivering fast, respecting people, and optimizing the whole.



[Context:  Maven has been doing some reading in his spare time and wants to share some ideas with Motley]


Maven: Hey Mot, I've been doing some reading on Toyota and their product development and manufacturing techniques. It's pretty cool stuff.


Motley: So what does car manufacturing have to do with me? I am a software developer. You pretend to be a software developer. Nothing to do with cars.


Maven: Au contraire mon ami. If your French sucks, you probably didn't get that. Anyway, Toyota invented something called "Lean Development" that has all sorts of applicability to software. In fact, agile development - of which test-driven development is an agile practice - has many principles in common with lean development.


Motley: I like my steak lean. Software? Not so much.


Maven: Ah, but wait. Hear me out. Lean Development embodies certain guiding ideas and insights (i.e. principles) about engineering and manufacturing that lead to extreme efficiencies in the development of a product - regardless if the product is a car or software.


Motley: Jeez, more principles. Don't we have enough principles to live by with agile development? Why more?


Maven: Well, in fact, the principles from lean and the principles from agile play well with one another. Lean is all about developing products quickly and efficiently while creating as much value for the customer as possible. You let quality drive your speed by building in quality up front and with increased speed and quality comes lower cost and easier maintenance of the product moving forward. Care to hear the core principles of lean development?


Motley: I have come to know that if I say "no" we both know that you never accept "no".


Maven: I love your enthusiasm. There are 7 key principles. The first one is eliminate waste.


Motley: Yeah, I do that every morning before my shower.


Maven: You're pretty funny. But seriously, much of what we do generates waste. Examples of waste are extra features that we build that never or rarely get used, documentation that we generate for no useful purpose other than our process requires it, and any barriers in communication imposed by our environment. The second principle is focus on learning.


Motley: I learn a lot by watching "Are You Smarter Than a 5th Grader?" every night. Great show.


Maven: Let's go deeper. We always want to learn throughout a development cycle and apply that feedback to improve our processes. One of the agile principles is continuous improvement, so this fits right in. A scientist would never do a huge amount of analysis and risk everything on one guess at a theory. Instead, they form a hypothesis, conduct many quick experiments, learn from the results, and iterate until they find the best alternative. Same for software - short quick iterations that we can learn from. Yet another principle from agile. The third principle is build quality in.


Motley: Quality from the start is definitely something to take from agile development. I am a big believer.


Maven: You bet. We want to focus on avoiding finding defects in our quality assurance process. We've been talking a lot about quality-driven practices like Test-Driven Development and test automation, so no real need to go into more detail here. You are the example everyone now looks up to! The fourth principle is defer commitment.


Motley: Thanks for the kind words! Hmmmm…. "defer commitment." Sounds like something I do on a regular basis with my girlfriend. I definitely respect her viewpoint there, but deferral is definitely the way to go for me.


Maven:  Although not necessarily the best advice for dealing with your girlfriend, it is great advice for software. Dependencies, for example, can get us in all kinds of trouble if they don't deliver. It's a big risk. We want to avoid taking them on as long as possible and have a contingency plan if things fail. We also want to embrace change - another agile principle - and that means we cannot rely on customer requirements being right early on. We don't want to solidify customer requests until we're just about ready to ship the functionality. Change is good from our perspective, and big up front requirements analysis phases lead to waste and expensive change later. Another principle is deliver fast.


Motley: Pregnant mothers want doctors to live by that rule.


Maven: Exactly! Software too. Delay is an evil waste in lean development. Delay leads to developers not being efficient. We want to minimize delay and deliver software in small chunks as quickly as possible. Speed baby! Minimize the overhead in the form of queues between organizations and disciplines. Test should not be standing around idle waiting for the code from the developers. We also want to focus not on doing many projects in parallel, which leads to context switching and thrashing, but instead do one at a time to a clear meaning of "done." The next principle is respect people.


Motley: Sing it Aretha!


Maven: You stated earlier that even though you defer commitment you respect your girlfriend. You're right on it! The idea is to empower people to make the right decision and have leaders in place that are willing to do that. Trust is a big factor here. We'll talk more about empowering the team later on when we talk about Scrum. The last principle is optimize the whole.


Motley: What do you mean by "the whole"? If we optimize the development team, for example, we'll make the rest of the organization more efficient. After all, I am a machine! Hehehe.


Maven: To fully minimize cycle time, you need to address the system as a whole. You find the constraints in the system, elevate them, and address them. If optimizing one small piece of the system leads to delays elsewhere, you really haven't fixed anything.


Motley: Well, there are some interesting concepts in there, and I see how the ideas can help development, but where does the rubber meet the road?


Maven: We've already been putting some practices in place that exercise lean principles without even thinking about being lean. That's the cool part. Let's save the discussion of lean practices (vs. lean principles) for another time. Some of your practices, like TDD, already build on these principles.


Motley: So to summarize, the lean principles you mentioned are:

  • Eliminate waste

  • Focus on learning

  • Build quality in

  • Deliver fast

  • Respect people

  • Optimize the whole


Motley: In the meantime, I feel like a steak. Care to join me? No? Bummer.




Motley's Pointer: Another key idea in Toyota's Product Development System is set-based design. If a new brake system is needed for a car, for example, three teams may design solutions to the same problem. Each team learns about the problem space and designs a potential solution. As a solution is deemed unreasonable, it is cut. At the end of a period, the surviving designs are compared and one is chosen, perhaps with some modifications based on learning from the others - a great example of deferring commitment until the last possible moment. Software decisions could also benefit from this practice to minimize the risk brought on by big up-front design.


Motley's Resources:  Lean Software Development: An Agile Toolkit, by Mary and Tom Poppendieck, Addison-Wesley, ISBN:0321150783, 2003,

Comments (3)

  1. Dave says:

    Well done.  Lean is still kind of under the radar in software development circles, but I think it’s becoming more relevant, especially as Agile is seeing more adoption in the enterprise.

    Besides, who doesn’t want to eliminate waste 😉

  2. If you want to tune your software engineering, take a look at Lean . Lean is a great discipline with

  3. Corey says:

    Michael Kennedy’s <a href="">Product Development for the Lean Enterprise</a> is a terrific resource for set-based development, and <a href="">Lean Thinking</a> is still the classic reference for lean thinking in general.

Skip to main content