Interesting article at:
"Lean Programming" article: www.poppendieck.com 
"Lean Programming" "W. Edwards Deming's Total Quality Management still rings true for software" --> www.ddj.com and www.ddj.com
[The following is Broken Link as of 2007-01-02. Use the link above.] -- www.sdmagazine.com
The article compares Lightweight Methodologies to Lean Production, the production method that helped Toyota become a global company. (William Edwards Deming and Total Quality Management are involved, too.)
There are ten basic practices of Lean Production:
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:
Lean Software Development, 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: xp123.com
Read Lean Software Development, 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 You Arent Gonna Need It, and/or Once And Only Once. -- Mike Smith
Definitely Minimize Inventory is about Simplicity and You Arent Gonna Need It. After all, minimizing inventory is not having to maintain what is not absolutely required for the next delivery. -- Jason Yip
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 Widget Xs on hand (usually about a week's worth). This is comparable to Big Design Up Front. 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 Widget Xes 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 (Yesterdays Weather, 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, Test First Design, and You Arent Gonna Need It promote, you end up paying only for the architecture you use, and have less work involved in changing your mind. -- Robert Watkins.
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 Frequent Releases. 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 Software In Process.
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. -- Pete Bevin
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.
See original on c2.com