Section 5.2. What Is a Process Smell?


5.2. What Is a Process "Smell"?

In the context of this optimization strategy, a process "smell" is much like a code "smell" in refactoring code; it is something that you know is "wrong" in some way.[2] Just like in refactoring code, you can feel that something is wrong in the process, and it is in your best interest to repair the problem before it gets worse.

[2] The concept of "smell" comes from a parent's experience of knowing when something needs to be changed.

When we are writing code, particularly iteratively, we incur design debt every time we make a change without maintaining the overall quality of the design of the system. Design debt is just like financial debtit does not go away unless you pay it back, and it accrues interest if you leave it too long. The same thing happens with our development processes; we start with a process that we think will work, but then personnel, technologies, skills, customers, or other things change. As each change occurs, we accrue some process debt. The symptoms of process debt are process smells, and their odor increases with time. Therefore, just as we need to refactor our code, we also need to refactor our process.

In this text, process smells are defined by their symptomsthe negative effect that we feel. The root cause of these symptoms may be different in different organizations, so there will be a variety of process changes that may eliminate the problem. The challenge is to spend the time to find the root cause in your organization and select the most appropriate process innovation.

The issue here is acknowledging that the problem is in the processnot the people. For example, if your team is regularly unable to meet its commitments, the problem is not that the engineers are lazy or don't care. Most likely, the problem lies somewhere in the process you use to estimate and allocate tasks. I once attended a presentation about a PhD thesis that was based on the premise that organizations need a rigid process to force engineers to produce quality code. The speaker was assuming that engineers do not care about quality naturally. I have found that to be completely inaccurate. Most engineers care deeply about the quality of what they produce, but many feel unable to work at their highest level in the context of the demands from the process and management. As a result, many engineers get frustrated and burned out. If it appears that the team is not producing to a high standard, look for the part of the process that is hampering the engineers as opposed to looking for more process demands to inflict on them.



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.