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.