Lean Programming

Interesting article at:

"Lean Programming" article: http://www.poppendieck.com/lean.htm
"Lean Programming" "W. Edwards Deming's Total Quality Management still rings true for software" --> http://www.ddj.com/architect/184414734 and http://www.ddj.com/architect/184414744
[The following is BrokenLink as of 2007-01-02. Use the link above.] -- http://www.sdmagazine.com/articles/2001/0105/0105e/0105e.htm?topic=ppm

The article compares LightweightMethodologies to LeanProduction?, the production method that helped Toyota become a global company. (WilliamEdwardsDeming and TotalQualityManagement are involved, too.)

There are ten basic practices of LeanProduction?:

Eliminate waste.
Minimize inventory.
Maximize flow.
Pull from demand.
Meet customer requirements.
Do it right the first time.
Empower workers.
Ban local optimization.
Partner with suppliers.
Create a culture of continuous improvement.

References:

http://www.poppendieck.com/lean.htm
LeanSoftwareDevelopment, An Agile Toolkit by Mary Poppendieck and Tom Poppendieck. ISBN 0-321-15078-3 .
Lean Thinking Books - a number of short book reviews of lean design books: http://xp123.com/books/lean/index.htm

Read LeanSoftwareDevelopment, An Agile Toolkit by Mary Poppendieck and Tom Poppendieck. ISBN 0-321-15078-3 . Highly recommended to anyone interested in this topic. The primary topics of the book are:

Eliminate waste.
Amplify learning.
Decide as late as possible.
Deliver as fast as possible.
Empower the team.
Build integrity in.
See the whole.

Inventory, in software development, per the Poppendiecks, is partially done work. Partially done work is an investment that has not yet yielded a return. And not even been deployed to where it could yield a return. Therefor minimize inventory by frequently delivering small complete units of working functionality to the customer.

-- Mark Delaney

I find the comparisons very interesting, but I'm skeptical on (at least) one point: The one about minimizing inventory. Specifically, I don't think software is the kind of business that has inventory, since its product is primarily intellectual, not physical. (Ad agencies and recording studios don't have inventories either.) The mapping of that rule is a little clumsy, and perhaps should've been avoided. That's a minor nitpick, though.

It sounds to me as though it could map to YouArentGonnaNeedIt, and/or OnceAndOnlyOnce. -- MikeSmith

Definitely MinimizeInventory? is about Simplicity and YouArentGonnaNeedIt. After all, minimizing inventory is not having to maintain what is not absolutely required for the next delivery. -- JasonYip

It's an analogy, with a bit of stretch, but it does make sense. Consider: a manufacturing plant buys stocks of inventory so that it can keep the line running and not have to stop production just because they ran out of WidgetX. This is good and necessary, sort of like design in software development. Traditional manufacturers would buy a lot of inventory, and buy some more before when the amount dropped below a certain level. This meant that they never ran out of WidgetX, but they had to keep a few thousand WidgetXs? on hand (usually about a week's worth). This is comparable to BigDesignUpFront. The investment in inventory meant: cash was spent before the WidgetX was used; they had to pay for warehouse space; if they decided to use WidgetY instead, they had several thousand WidgetXes? to use or dispose of first. With lean-inventory practices, they would buy in small quantities, typically just enough to avoid running out. The judgement of experienced workers was used on how much was enough, but ultimately they would usually buy what they had used the day before (YesterdaysWeather, anyone?). Here, the manufacturing company gets to spend the cash as late as possible, they don't have the inventory overhead, and they can change their mind easily.

Compare this to a system architecture. If you design lots of architecture at a time, you're investing time (and money) before you need to, you have the extra hassles of dealing with design elements that aren't required yet, and you have a lot of work wasted if you change your mind about something. By contrast, with the "just-enough" architecture that Simplicity, TestFirstDesign, and YouArentGonnaNeedIt promote, you end up paying only for the architecture you use, and have less work involved in changing your mind. -- RobertWatkins.

Yes, but, consider that in a manufacturing process inventory is relatively low-risk. You know what it does, how well it works, and how much it costs. The only risk involved is sheer quantity. In programming, system architecture, etc., creating the excess stuff is higher risk, with a (theoretically) higher potential return.

Well, I admitted the analogy is a stretch; no analogy is a perfect fit. There are other risks, though. For example, with low inventory, you are very vulnerable to shake-ups in your supply-chain. You can't afford just one supplier, you have to have a backup. Going to a just-in-time inventory model is usually seen as a very high-risk activity, with high payoffs. Now, compare it to the typical view of software architecture. The conventional view is that big design up front is a risk-mitigating technique, not a risk-producing one. You spend all that time doing analysis, design, and framework construction to lower the risk that the application you are building is going to break. Of course, we enlightened ones know this to be a false economy, but bear in mind that the people we're trying to convince don't know this. By comparing the reduction in design to the reduction in inventory, a reasonably accurate picture of what is occurring is constructed. New risk is accepted [actually, it's traded off against the risk of making the wrong decision and bearing the consequences] for the associated gains in flexibility and productivity.

Inventory is waste according to the definition of waste: waste is anything that does not provide immediate value to the customer. Inventory in software is the software that is not providing immediate value to the customer. Therefore, minimize inventory maps to FrequentReleases. Software is not inventory only when the customer starts to realize value. So all the code you write up until the software starts generating value for the customer is inventory. Which is waste. So release early and release often and keep your inventory low. Kent calls this SoftwareInProcess.

-- CurtisCooley

Chapter 1 of the book has a table of manufacturing ideas vs software ideas, and "inventory" is listed against "partially done work" - i.e., software that has been written but is not currently integrated or deployed and is therefore not adding value. -- PeteBevin

Although the article referenced above is mostly about lean production, it does contain a reference that also differentiates between process and rule-sets:

Simple Rules In a January 2001 Harvard Business Review article titled "Strategy as Simple Rules", Kathleen Eisenhardt describes how smart companies thrive in a complex business environment: by establishing a set of rules that define - not confine - direction. She suggests that instead of complex processes, simple communication strategies can best enable people to seize fleeting opportunities in rapidly changing markets.

Software development and manufacturing are different. And software development is different from project to project. That is why Mary and Tom emphasize, repeatedly, that you can not transfer the practices and benefit, but you can transfer the principles. Focus on the principles, listed above, and you can bring the concepts of Lean Manufacturing to your software project.

-- CurtisCooley