Chapter 2. Demonstrate Value Iteratively

Benefits	Early risk reduction. Higher predictability throughout the project. Trust among stakeholders.
Patterns	Enable feedback by delivering incremental user value in each iteration. Adapt your plans using an iterative process. Embrace and manage change. Attack major technical, business, and programmatic risks early.
Anti-Patterns	Plan the whole lifecycle in detail, track variances against plan (can actually contribute to project failure). Assess status in the first two thirds of the project by relying on reviews of specifications and intermediate work products, rather than assessing status of test results and demonstrations of working software.

The principle of demonstrating value iteratively explains why software development greatly benefits from being iterative.^[1] An iterative process makes it possible to accommodate change easily, to obtain feedback and factor it into the project, to reduce risk early, and to adjust the process dynamically.

^[1] Material appearing in the introductions of Chapters 27 adapted from Kroll 2005. Used with permission.

Several imperatives underlie this principle. The first is that we must demonstrate incremental value to enable early and continuous feedback. We achieve this goal by dividing our project into a set of iterations. In each iteration we perform some requirements, design, implementation, and testing of our application, thus producing a deliverable that is one step closer to the final solution. This process allows us to demonstrate the application to end users and other stakeholders, or have them use the application directly, enabling them to provide early feedback on how we are doing. Are we moving in the right direction? Are stakeholders satisfied with what we have done to date? Do we need to change the features implemented so far? And finally, what additional features need to be implemented to add business value? If we can answer these questions satisfactorily, we are more likely to build trust among stakeholders that the system we are developing will address their needs. We are also less likely to overengineer our approach or to add capabilities that are not useful to the end user.^[2]

^[2] According to the Standish Group's Chaos Report (2003), 45 percent of features implemented on the average project are never used.

The second imperative is to leverage demonstrations and feedback to adapt our plans. Rather than relying on assessing specifications, such as requirements specifications, design models, or plans, we need instead to assess how well the code developed thus far actually works. We must therefore use test results and demonstrations of working code to stakeholders to determine how well we are doing. Following this procedure provides a good understanding of where we are, how fast the team is progressing, and whether we need to make course corrections to complete the project successfully. We can then use this information to update the overall plan for the project and develop detailed plans for just the next iteration, rather than for the entire project.

The third underlying imperative is to embrace and manage change. Today's applications are too complex for the requirements, design, implementation, and testing to align perfectly the first time through. Instead, the most effective application development methods embrace the inevitability of change. Through early and continuous feedback, we learn how to improve the application, and the iterative approach provides us with the opportunity to implement those changes incrementally. By having the processes and tools in place, we can effectively manage all this change without confining desired creativity.

The fourth imperative underlying this principle is the need to drive out key risks early in the lifecycle, as illustrated in the diagram in Figure 2.1. We must address the major technical, business, and programmatic risks as early as possible, rather than postponing risk resolution toward the end of the project. This stage is accomplished by continuously assessing what risks we are facing and addressing the top remaining risks in the next iteration. In successful projects, key business risks are mitigated in early iterations by involving stakeholders to ensure buy-in to a vision and high-level requirements, and key technical risks are mitigated through design, implementation, and testing of key aspects of the architecture. It is also important to retain information required to force decisions about what major reusable assets or commercial-off-the-shelf (COTS) software to use.

Figure 2.1. Risk Reduction Profiles for Waterfall and Iterative Developments.

A major goal with iterative development is to reduce risk early on by analyzing, prioritizing, and attacking top risks in each iteration.

(Adapted from Royce 1998.)

The anti-pattern to following this principle would be to plan the whole lifecycle in detail up front and then track variances against plan. Another anti-pattern would be to assess status in the first two thirds of the project by primarily relying on reviews of specifications, rather than assessing status of test results and demonstrations of working software.

This chapter will walk you through a number of best practices that will assist you in demonstrating value iteratively.

• Practice 1: Manage Risk explains how to identify and prioritize key risks. These risks are used to determine the focus of the next iteration.

• Practice 2: Execute Your Project in Iterations describes how to plan iterative development and how to divide your project into a series of iterations in which early iterations address high risks.

• Practice 3: Embrace and Manage Change suggests what changes to encourage and discourage at each stage of a project, as well as techniques to maximize change freedom.

• Practice 4: Measure Progress Objectively discusses how to leverage the right measures to avoid getting a false perception of status.