Tag Archives: project

Poppendieck: lean software development, an agile toolkit

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.


Poppendieck: implementing lean software development

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 ….


Your Agile Project Needs a Budget, Not an Estimate

from hbr.org/2014/12/your-agile-project-needs-a-budget-not-an-estimate

Nearly every software development project starts with one question: How much is this going to cost?

Maybe it’s been asked another way — How long will this take? How many stories can we get into this next sprint? How many people do we need to hire to get this done? How much money do I we need to raise?

These are all variations on the same question — how much effort is this going to cost in terms of time and/or money?

There are two common replies to this question: 

  1. We don’t know;
  2. Let us estimate and get back to you.

Stakeholders and decision-makers don’t like the first reply because they desperately need an answer to their question and they don’t have the knowledge to answer it themselves. Technical teams don’t like the second answer, because estimating takes a ton of time and it’s often abused

To minimize the risk of having your next technical project go awry, stop estimating and start budgeting.

For most strategic decisions, estimating is too precise.

tactical approach to budgeting. [update throughout the life of your project]

Step 1: Identify Decisions
Step 2: Match Precision to Decision
Step 3: Budget