Section 5.3. Picking Which Smell to Work On

5.3. Picking Which Smell to Work On

Every change you make to your process has some risk. Making multiple changes at the same time multiplies that risk. In addition, if you work on more than one issue at a time, it will be difficult to isolate their various impacts and be sure that each was an improvement. Therefore, it's important that you pick one smell to work on at a time.

Given the opportunity, all of the stakeholders will detect smells, each of which is a potential improvement to the process. However, their perspectives on what is important will differ, and in fact their goals may be in conflict. The challenge is to pick the one smell whose resolution will have the maximum impact on your process and your ability to meet your goals and make that change. In order to do that, we need a process to weigh the alternatives and pick the one that will maximize the impact. For each change, we need to specify these items:

• Description of problem A short statement of the issue

• Process innovation The specific change being proposed

• Costs to implement Including training, equipment, time, etc.

• Expected benefit The effect this change will have on our metrics

• Risks Things that could prevent the change from achieving its expected benefits

• Time frame Any restrictions on the timing of the implementation of this process innovation, such as scheduling of training or purchasing of equipment

If there are multiple ways to address an issue, we need to complete this analysis for each possible process innovation.

The requirement to put a numeric value on the expected benefits can seem overly demanding, but the thought process necessary to develop that value helps us weigh the alternatives. We need to quantify the effect the change will have on throughput or efficiency. That essentially means that it must improve the rate at which we deliver functionality or eliminate waste within the process.

For example, if the smell was "Engineers were spending time waiting for the automated tests to run," and the process innovation proposed was "to upgrade the server on which the tests run," then the amount of time the engineers spend waiting now is an estimate^[3] of the expected benefit.

^[3] This estimate doesn't account for the impact of the interruption but is good enough to support the choices being made.

However, sometimes the impact of the change is less obvious. Consider another example where estimates for the effort required by stories are very inaccurate. One possible process innovation proposal would be to use a particular estimation technique to improve the accuracy of the estimates. In this case, the impact on throughput and efficiency is less direct; the time that we spend replanning or performing other adjustments when we realize the estimates are incorrect is the waste that we reduce.

This last example underscores the need for this analysis. Although the issue raised is the inaccuracy of our estimates, we have realized that the waste in the process is the replanning caused by the bad estimates. As is often the case, there are multiple ways to address this problem. An alternative to changing the estimation process would be to focus on the replanning process to see if changing it can make it more efficient or eliminate it.

An open and frank discussion by all of the people involved is the best way to find all of the viable alternatives and quantify their impacts. The easiest way to do this is to gather everyone (developers, customer, product owner, project manager, and anyone else with a vested interest)^[4] in a room and use index cards. This meeting is known as a Refactoring Planning Meeting. During the meeting, anybody can propose a change by recording the issue description and the proposed process innovation on an index card. After a discussion of the situation under consideration, the group agrees on the expected benefit and risks and records them on the card. This discussion resolves any misunderstandings and ensures that everyone understands both the issue and the proposed process innovation. If an issue can be addressed by multiple process innovations, each proposed process innovation gets separate analysis and its own index card. As the discussions continue, index cards can be removed if the group finds a process innovation they prefer or decides that the issue is not really an issue at all (usually this means that you have found a new underlying cause, so you replace the current card with another).

^[4] As with all meetings, too many people can be unproductive. Sometimes it is useful to regulate who can participate in the discussion if too many people attend. See the "Chickens and Pigs" philosophy in the Daily Scrum/Daily Standup Meeting refactoring.

As this process continues, you may find that there are things that need to be researched before you can pursue an issue. For example, if you are considering upgrading the test server, you may need someone to weigh alternative servers by specifying their costs and expected improvements in the run-time of tests. Where that research is deemed valuable (i.e., the group thinks the issue is important enough to pursue), the appropriate part of the organization should be responsible for doing the research. To plan for that activity, make it a task for the next iteration and, if that task is assigned to engineering, reserve that part of the team's velocity when selecting the functionality for that iteration.

After the cards are developed, they can be prioritized. Priority is affected by the expected benefits and risks, in addition to other factors. In particular, the time frame for the change may cause a high-priority change to be deferred. For most of the cards, strict ordering is not necessary. Partitioning the cards into high, medium, and low priority and ordering only the high-priority items is sufficient. The goal is to come to consensus about which process innovation will be implemented.