9

Agile Value

Chapter 9 begins our discussion of an important agile concept: value. Agile methods are all about delivering value. What exactly do we mean by value? As previously mentioned in Chapter 1, we are referring to business value, a concept that pertains to different variations of value that define the strength and health of a company for the long term. Business value encompasses several types (stakeholder value, increased profits). Projects are taken on to increase business value. This includes producing some type of benefit or improvements to existing services. A company must consider choices and make decisions that maximize business value and reduce risks. A risk does not add value and it must be managed. To summarize, a business must maximize value coming in and minimize value going out of the firm in order to remain profitable. For the purposes of our discussion and in contrast to traditional project management, we are referring to negative risks only.

CALCULATING VALUE

Readers should recall that we discussed what we mean by the word “value” in Chapter 1. A common way to calculate value without bias is to calculate a return on investment (ROI), internal rate of return (IRR), or the net present value (NPV). Each of these three formulas can be relatively easy to calculate with the help of Microsoft Excel. The meanings of these formulas are as follows:

• Net present value (NPV): When choosing between several projects to take on, the one with the highest NPV should be selected over the others.

• Return on investment (ROI): The project with the highest ROI should be selected.

• Internal rate of return (IRR): Select the project with the highest IRR.

Readers may be aware that value can be intangible, however, the author is referring to tangible value that is subjective and cannot easily be disputed.

PLAN VALUE

When planning an agile project, the focus should be on value. The work that needs to be done on the project should be prioritized based on its business value. This means that the user stories adding the most value should be added in early iterations rather than later. High-risk user stories should be addressed in the same way because risk can reduce value. We want to ensure that we maximize value by handling high-risk items early in the project to lessen the impact of those that are non-value-added. Readers must once again understand that the author is referring to negative risks in this instance.

ADAPTABILITY AND VALUE

The logic behind adaptability in the agile environment is that projects should be at all times open to accepting changes. In traditional project management, changes must go through a formal process in order to be evaluated and approved for incorporation into the project. This would not be the case for the agile project as change is expected and embraced. As mentioned in Chapter 1, the acceptance of change does not automatically imply that “anything goes” on the agile project. With regard to change and adaptability, the idea is to accept changes that increase the amount of value for the customer.

Adaptive Planning

According to the Declaration of Interdependence (DOI) from Chapter 2, “we increase return on investment by making continuous flow of value our focus.” The agile project must deliver a constant flow of value to the customer. Agile methods are all about delivering the maximum amount of value to the customer and minimizing non-value-added activities. Adaptive planning is an agile concept that suggests plans will more than likely change (and they always do) and it is wiser to plan on replanning and adapting as things change. Again, this is in contrast to the traditional project management approach where the development of plans is a required process.

Again, we refer back to the DOI from Chapter 2: “we expect uncertainty and manage for it through iterations, anticipation, and adaptation.” We are referring to changes on the agile project. There is a high level of change on the agile project and the expectation is that the plan will need to be adapted as we proceed. We have now come to a familiar concept that is shared with both traditional and agile projects. This term is progressive elaboration, which means to add more detail as it becomes available. This would mean that planning should consist of continually making updates throughout the project. In the agile environment, plans are updated throughout the iterations.

Agile versus Traditional Changes

As we have seen throughout this book thus far, agile and traditional project management practices are frequently dissimilar. The agile world focuses on experiments and demonstrations that reveal hidden project requirements. As new information is uncovered, replanning becomes necessary. Contrary to traditional project management and its extensive planning efforts, there is very little up-front planning on the agile project because planning is done throughout the project. Changes and adjustments are customary on the agile project, whereas the traditional project views changes as cumbersome and often unwelcome.

Minimally Marketable Features

In terms of a release, there are certain requirements that must be satisfied in order to provide value to the end user. Minimally marketable feature is a term that must apply to any release of the product for customer use. This means that a release of the product must contain the minimally marketable features possible and is not representative of the complete product.

Tailoring and Value

A DOI principle states that “we improve effectiveness and reliability through situational specific strategies, processes, and practices.” This brings us to the concept of tailoring. The author expects that many experienced project managers are quite familiar with this terminology. The iteration or project retrospectives provide the opportunity to reflect on what works, what does not work, what should be done differently, and what needs to be improved. When reflecting on areas that may need to be enhanced, it is these types of situations which result in tailoring, which is considered to be a form of adaptation.

DELIVER VALUE

Value is delivered when an agile project is executed. The team delivers through the process of maximizing value and minimizing non-value-added activities. Any type of wastefulness is considered to be in the category of non-value-adding activities. Following are examples of wasteful activities that should be considered when attempting to maximize value. These activities should be avoided as much as possible. The following list includes but is not limited to the following:

• Unfinished work: Started but not finished; this is considered to be wasteful.

• Unnecessary processes: Work that does not add value; irrelevant work does not add value.

• Bugs: Faulty software or artifacts; this is considered to be rework and it is considered to be wasteful.

• Noncollocated communication efforts: Remote teams; this would require a greater level of effort to communicate if the team is not colocated. There is some waste involved.

• Extra features: Not required or good to have features; wasting time doing unneeded work.

• Waiting around: Delays for approvals or signoffs; wasting time by waiting.

• Switching projects: Working on more than one project; multitasking on multiple projects. Agile team members should be focused on one project at a time if possible.

Iterative delivery is a good way to maximize value on the agile project. Increments of the product are demonstrated and delivered as working software. Recall that working software is the highest priority of agile methods. Value is delivered early which results in the obtainment of a fast return on investment.

Using Software or Task Boards to Deliver Value

On the agile project, a common tool that is used to display the project status is the task board. Traditional project management uses software such as MS Project to manage its scheduling requirements. Some believe that using scheduling software is not practical on the agile project and here’s why:

• Scheduling software shows layers of tasks that are often lengthy and interdependent.

• Scheduling software may be viewed as being too complex for agile projects.

• Scheduling software is sometimes viewed as primarily the project manager’s tool and not necessarily a team tool.

Task (or white) boards are the simple alternative to scheduling software on the agile project. From Chapter 7, we have discussed the three columns on the task board: (1) To Do, (2) In Progress, and (3) Done. This is a simple, yet visual scheduling way to show the work status of an iteration quickly. The benefits of task boards include:

• Agile projects have a preference for low technology, high visibility tools.

• Simplicity is always the best approach for the agile project. The task board is very simple in comparison with scheduling software.

• The accuracy of data on the task board is visible for the entire agile team and all stakeholders to see. It is perceived that data on the task board will be more accurate than data entered into a scheduling tool.

• With a scheduling tool, charts and graphs are not always accessible for all project team members. In contrast, the task board is visible to all at any time.

ANALYZING AND DETERMINING VALUE

In order to analyze and deliver the maximum value for the customer properly, we must reflect on the business value of our efforts and then take the appropriate action. We must focus on business value throughout the entire agile project and every work component, practice, procedure, or effort must add value. In addition, we must focus our efforts on delivering the highest value items before those with lower value. All costing factors (such as coding and distribution) associated with value must be included. This is referred to as comparing the benefits versus the costs to calculate the value. See Table 9.1 for an example of analyzing and determining value.

TABLE 9.1
Analyzing and Determining Value

Another factor that we need to consider when analyzing value is that we cannot always just focus only on high-value items. We need to consider that some intermediate-level items can add value faster than a high-value item, which will result in delivering high value quicker. In other cases, high-value features may need low-value items in order to function properly. This is a codependent situation that may need to be addressed after the analysis process has been undertaken. The bottom line is that the agile team must understand how to determine what is actually high value and what is not.

VALUE PRIORITIZATION

User stories (requirements) must be prioritized based on value as perceived by the customer. This in turn means that the customer must be a part of the discussions during the prioritization process. There are several techniques that are used to prioritize requirements from the customer’s perception and a discussion follows. These techniques are referred to as prioritization schemes:^*

1. Monopoly Money: This scheme is played somewhat like the Monopoly game in that the customer is asked to divide the money up among the product’s features. During this process, the high-priority items are discovered. The monopoly money should be limited to high-value product features to ensure effectiveness in the prioritization game.

2. 100-Point Model: This prioritization scheme is based upon use cases. Stakeholders are given 100 points to vote for the high-priority requirements. The higher the points for a feature are, the higher the priority level.

3. MoSCoW Prioritization Scheme: This prioritization scheme is based on the letters in the name of the scheme where: (Note that the letter O is not used.)

   • M stands for Must have

   – Priority 1—Very High

   • S stands for Should have

   – Priority 2—High

   • C stands for Could have

   – Priority 3—Moderate

   • W stands for Would like to have, but not now

   – Priority 4—Low

The meanings of these letters are pretty straightforward and represent the priority levels of the requirements. There are other prioritization schemes, however, we limit our discussion to the three mentioned above. The idea is to use a method that the customer is comfortable with when prioritizing the user stories based on value. Readers must understand that any prioritization scheme can be used; even one that is as simple as High, Medium or Low.

CONFIRM VALUE

Value is confirmed on the agile project by means of demonstrating the product increments to the customer and other stakeholders. These demonstrations take place as simulations or prototypes. Regardless of the methods, during these demonstrations, requirements are clarified and the customer is given the chance to accept or reject the software that has been presented. In certain instances, these demos result in the acknowledgment that additional requirements are needed or the existing requirements are enhanced (functionality added to an existing user story).

TRACK AND REPORT VALUE

The final value-related action is to track and report value. On the agile project, the idea is to make sure that the project stays on track and information gets communicated to the stakeholders. This information is covered in detail in Chapter 7 as “Agile Tracking and Reporting.”

CHAPTER SUMMARY

Delivering value to the business is a main feature of agile methods. Most decisions on the agile project are focused around the amount of value that the project can create. Value-driven delivery must be maximized for the customer at all times and any non-valued-added activities and events such as risks must be managed or eliminated. It is really that simple. The agile project should at all times add value.