notes from implementing lean sw dev, from concept to cash (amazon.co.uk) , by Poppendieck, ch 2 on infoq
(my emphasis)

Principles are underlying truths that don’t change over time or space, while practices are the application of principles to a particular situation. Practices can and should differ as you move from one environment to the next, and they also change as a situation evolves.
….

Principle 1: Eliminate Waste

….
A big form of waste in software development is “churn.” … we’ve often encountered “requirements churn” in the 30 percent to 50 percent range, and we’ve seen many test-and-fix cycles that take twice as long as the initial development time. We’ve found that software development churn is always associated with large inventories of partially done work. When requirements are specified long before coding, of course they change. When testing occurs long after coding, test-and-fix churn is inevitable. Unfortunately, these types of churn are often just a precursor to the ever larger churn created by delayed (aka big-bang) integration.
But far and away the biggest source of waste in software development is extra features.
….

Myth: Early Specification Reduces Waste ….

Principle 2: Build Quality In ….

Myth: The Job of Testing Is to Find Defects ….

Principle 3: Create Knowledge ….

MacCormack has identified four practices that lead to successful software development:
1. Early release of a minimum feature set to customers for evaluation and feedback
2. Daily builds and rapid feedback from integration tests
3. A team and/or leader with the experience and instincts to make good decisions
4. A modular architecture that supports the ability to easily add new features
….

Myth: Predictions Create Predictability

Predictable outcomes are one of the key expectations that the marketplace imposes on companies and their senior management, and these expectations eventually flow down to software development. Unfortunately, software development has a notorious reputation for being unpredictable, so there is a great deal of pressure to make it more predictable. The paradox is that in our zeal to improve the predictability of software development, we have institutionalized practices that have had the opposite effect. We create a plan, and then we act on that plan as if it embodies an accurate prediction of the future. Because we assume that our predictions are fact, we tend to make early decisions that lock us into a course of action that is difficult to change. Thus, we lose our capability to respond to change when our predictions turn out to be inaccurate. The solution to this problem, it would seem, is to make more accurate predictions.

We forget that the predictions of the future are always going to be inaccurate if they are 1) complex, 2) detailed, 3) about the distant future, or 4) about an uncertain environment. No amount of trying to make these kinds of predictions more accurate is going to do much good. There are, however, well-proven ways to create reliable outcomes even if we cannot start with accurate predictions. The idea is to stop acting as if our predictions of the future are fact rather than forecast. Instead, we need to reduce our response time so we can respond correctly to events as they unfold. In order to increase the predictability of outcomes, we need to decrease the amount of speculation that goes into making decisions. Decisions that are based on facts, rather than forecasts, produce the most predictable results.

Principle 4: Defer Commitment ….

Myth: Planning Is Commitment

…. But in the commercial world, wise businesses (such as Toyota) realize that sticking to a detailed plan is not healthy, and measuring process capability against ones ability to do so is measuring the wrong thing. Let’s not succumb to the myth that planning is the same thing as making a commitment. We should plan thoughtfully and commit sparingly.

Principle 5: Deliver Fast

Myth: Haste Makes Waste

…. Caution: Don’t equate high speed with hacking. They are worlds apart. A fast-moving development team must have excellent reflexes and a disciplined, stop-the-line culture. The reason for this is clear: You can’t sustain high speed unless you build quality in.

…. There are two ways to achieve high quality. You can slow down and be careful, or you can develop people who continually improve their processes, build quality into their product, and develop the capability to repeatedly and reliably respond to their customers many times faster than their competitors.

Principle 6: Respect People ….

Myth: There Is One Best Way ….

Principle 7: Optimize the Whole

…. Vicious Circle No. 1 (of course, this would never happen at your company):

• A customer wants some new features, “yesterday.”
• Developers hear: Get it done fast, at all costs!
• Result: Sloppy changes are made to the code base.
• Result: Complexity of the code base increases.
• Result: Number of defects in the code base increases.
• Result: There is an exponential increase in time to add features.

….  outsourced call centers working under the traditional revenue model have no incentive to find and resolve the causes of customer problems.
Crossing organizational boundaries is expensive.  ….

Myth: Optimize By Decomposition

…. People have a tendency to decompose complex situations into small pieces, probably a legacy from the efficiency experts who divided jobs into miniscule tasks. After decomposition, each piece is measured and each measurement is optimized. You would expect that when all of the individual measurements are optimized, then the overall system would be optimized too. But you would be wrong. If you break a value stream into silos and optimize them separately, experience has shown that the overall system will almost certainly be suboptimized.
We can’t measure everything ….