notes from Lean Software Development, An Agile Toolkit, by Mary and Tom Poppendieck, intro + ch3 at pearsoncmg.com
(emphasis mine)

…. 2. Amplify learning. Development is an exercise in discovery, while production is an exercise in reducing variation, and for this reason, a lean approach to development results in practices that are quite different than lean production practices.

see also Lean: Development is not Manufacturing.

…. 3. Decide as late as possible. Development practices that provide for late decision making are effective in domains that involve uncertainty, because they provide an options-based approach. In the face of uncertainty, most economic markets develop options to provide a way for investors to avoid locking in decisions until the future is closer and easier to predict. Delaying decisions is valuable because better decisions can be made when they are based on fact, not speculation. In an evolving market, keeping design options open is more valuable than committing early. A key strategy for delaying commitments when developing a complex system is to build a capacity for change into the system.

…. Decide as late as possible. Development practices that provide for late decision making are effective in domains that involve uncertainty, because they provide an options-based approach. In the face of uncertainty, most economic markets develop options to provide a way for investors to avoid locking in decisions until the future is closer and easier to predict. Delaying decisions is valuable because better decisions can be made when they are based on fact, not speculation. In an evolving market, keeping design options open is more valuable than committing early. A key strategy for delaying commitments when developing a complex system is to build a capacity for change into the system.

…. Not all change is equal. There are a few basic architectural decisions that you need to get right at the beginning of development, because they fix the constraints of the system for its life. Examples of these may be choice of language, architectural layering decisions, or the choice to interact with an existing database also used by other applications. These kinds of decisions might have the 100:1 cost escalation ratio. Because these decisions are so crucial, you should focus on minimizing the number of these high-stakes constraints. You also want to take a breadth-first approach to these high-stakes decisions.

The bulk of the change in a system does not have to have a high-cost escalation factor; it is the sequential approach that causes the cost of most changes to escalate exponentially as you move through development. Sequential development emphasizes getting all the decisions made as early as possible, so the cost of all changes is the same—very high. Concurrent design defers decisions as late as possible. This has four effects:

• Reduces the number of high-stake constraints.
• Gives a breadth-first approach to high-stakes decisions, making it more likely that they will be made correctly.
• Defers the bulk of the decisions, significantly reducing the need for change.
• Dramatically decreases the cost escalation factor for most changes

…. Lean software development delays freezing all design decisions as long as possible, because it is easier to change a decision that hasn’t been made. Lean software development emphasizes developing a robust, change-tolerant design, one that accepts the inevitability of change and structures the system so that it can be readily adapted to the most likely kinds of changes.

…. Agile software development processes can be thought of as creating options that allow decisions to be delayed until the customer needs are more clearly understood and evolving technologies have had time to mature. This is not to say that agile approaches are unplanned. Plans help clarify confusing situations, allow consideration of tradeoffs, and establish patterns that allow rapid action. So, plans tend to enhance the flexibility to respond to change. However, a plan should not prespecify detailed actions based on speculation. Agile software development follows speculation with experiments and learning to reduce uncertainty and adapt the plan to reality.

Conventional wisdom in software development tends to generate detailed decisions early in the process—like freezing the customer requirements and specifying the technical framework. In this approach, what is taken for planning is usually a process of predicting the future and making early decisions based on those predictions without any data or validation. Plans and predictions are not bad, but making irrevocable decisions based on speculation is to be avoided.

…. Options thinking is an important tool in software development as long as it is accompanied by recognition that options are not free and it takes expertise to know which options to keep open. Options do not guarantee success; they set the stage for success if the uncertain future moves in a favorable direction. Options allow factbased decisions based on learning rather than speculation.

Tool 8: the last responsible moment

…. Procrastinating is not the same as making decisions at the last responsible moment; in fact, delaying decisions is hard work. Here are some tactics for making decisions at the last responsible moment:

• Share partially complete design information.  The notion that a design must be complete before it is released is the biggest enemy of concurrent development. Requiring complete information before releasing a design increases the length of the feedback loop in the design process and causes irreversible decisions to be made far sooner than necessary. Good design is a discovery process, done through short, repeated exploratory cycles.
• Organize for direct, worker-to-worker collaboration. Early release of incomplete information means that the design will be refined as development proceeds. This requires that people who understand the details of what the system must do to provide value must communicate directly with people who understand the details of how the code works.
• Develop a sense of how to absorb changes. … experts know how to delay commitments and how to conceal their errors for as long as possible. Experts repair their errors before they cause problems. Amateurs try to get everything right the first time and so overload their problem-solving capacity that they end up committing early to wrong decisions.
• Develop a sense of what is critically important in the domain. Forgetting some critical feature of the system until too late is the fear that drives sequential development. If security, or response time, or failsafe operation are critically important in the domain, these issues need to be considered from the start; if they are ignored until too late, it will indeed be costly. However, the assumption that sequential development is the best way to discover these critical features is flawed. In practice, early commitments are more likely to overlook such critical elements than late commitments, because early commitments rapidly narrow the field of view.
• Develop a sense of when decisions must be made. ….
• Develop a quick response capability.  ….  If you can change your software quickly, you can wait to make a change until customers know what they want.

….

We offer seven simple rules, or principles, for software development along with the tools to help you translate the principles to agile practices that are appropriate for your particular environment:

1. Eliminate waste: Spend time only on what adds real customer value.
2. Amplify learning: When you have tough problems, increase feedback.
3. Decide as late as possible: Keep your options open as long as practical, but no longer.
4. Deliver as fast as possible: Deliver value to customers as soon as they ask for it.
5. Empower the team: Let the people who add value use their full potential.
6. Build integrity in: Don’t try to tack on integrity after the fact—build it in.
7. See the whole: Beware of the temptation to optimize parts at the expense of the whole.