November 30, 2019

Another Look at Ambiguity in Working Agreements

  —Maybe a little ambiguity goes a long way.

I’ve said a lot about working agreements (Working Agreements for Agile Teams (Part 6)). Good agreements are concise and easy to evaluate regarding whether they are being fulfilled or not and are unambiguous. Recently, I find myself reconsidering my position on ambiguity. Or at least a little ambiguity.

The team and I are facing challenges improving our test regime. One team member put forth the notion that it isn’t sufficient to test the product. We must use meaningful tests.

They defined meaningful tests using an example involving a histogram and bin counting. Their example went like this:

• we have a bin counting algorithm in our software.
• Bin counting describes a frequency distribution (like you’d see if you plotted a histogram of the counts).
• Any reasonable test must test the properties of a frequency distribution.

I’ll call this an argument for POLA. And think it reasonble.

The flaw in this argument is that it doesn’t describe a use case. For example, if I’m counting inventory and my bins are part numbers. It’s not clear this use case requires my bin counting algorithm to exhibit any property except retaining a count of parts for a given part number. A frequency distribution in this case might be useful but it might not be.

The difference is in how the information will be used–maybe I need to display a histogram, maybe I don’t.

In any event, the comment on developing meaningful tests piqued my interest. What is a meaningful test?

There isn’t one answer to this. I can argue that meaningful requires viewing bin counting through the lens of a frequency distribution. I can argue that it requires understanding the use case. I’m in the use case camp.

Since meaningful means different things to different people its use in the working agreement was ambigous. It’s ambiguous because I can easily check if you wrote a test. The meaningfulness of any test is debatable without a shared understanding of the requirement.

I’m confident the team will eventually come around to the realization that meaningful tests provide evidence the requirement is fulfilled. This will remove the ambiguity.

In the meantime, the use of meaningful in our working agreement is ambiguous because of different interpretations of what a meaningful test is. It’s power might also come from the realization that you can’t debate meaningful without a shared understanding of the outcome.

The power of ambiguity in a working agreement is exploration required to remove the ambiguity. A little ambiguity is, in effect, a powerful learning tool for an engaged team.