The Usefulness Test

Maximizing the amount of work not done was quite elusive to me until I started to think about it more as a test of only doing things that are useful. I think what the Agile Manifesto founders had in mind with this principle is to exclude non-value added work from the process. To me this seems quite obvious, but for people who have been trained to accept things as they are it is not always so obvious what is useful and what is not.

Weinberg describes in his book on Secrets of Consulting that a cucumber gets more pickled than brine gets cucumbered. The analogy is that people tend to be changed by their environment more than they change the environment itself. Even skilled agile practitioners can start to accept the status quo.

Each change a person makes to their environment has a cost and a benefit and thus a return on investment (ROI = benefit ÷ cost ). If a person is always trying to improve their environment they will be more effective if they make changes for things that deliver the most ROI. If a person is only making the changes that have a high ROI they are necessarily not making changes that have a low ROI. However, changes with a low ROI can have a low ROI not only because the value is low but also because the cost of making the change is enormous. Non-value added activities can thus persist if the cost to remove those non-value added activities is very high. So non-value added activities can become part of daily routine because they are “not worth the effort to change” aka “not useful, but too costly to stop doing.” Over time people, even agile practitioners, forget that things don’t have a value because they have been doing them for so long.

I would say the only way to escape this trap is to establish a habit of continuously re-evaluating usefulness. We should ask ourselves and each other “How useful is this?” Regardless of the effort required to change something, we should challenge things that are not useful so that we can maximize the amount of work not done.