Entanglement

(note: this is a continuation of a story that starts here)

The Danger of Simplistic Models

It's all too common for people to prefer a simpler-seeming model to one that actually works. Another way to put this is that people will typically choose a model with one less variable over one that predicts outcomes more accurately.

Every so often, there's another popular book or article on how people think. They usually try to build a blanket model that explains all people's minds as though each is cast from a single, shared mold.

These kinds of simplistic models are seductive because they feel good. They are easy to understand and easy to rationalize when some of the data don't fit.

That good feeling comes with a heavy price-tag, though.

For the same reasons they are so attractive, simplistic models run the risk of being canonized as right (about which I have previously written). As a result, people will fight to hold a broken model in place when it should be replaced and, ironically, discard a partially-broken model entirely rather than just amending it.

This means we waste a lot of time dropping bad ideas, only to find out they were good again later, then dropping the bad ideas that supplanted them, only to find out they were good, too.

We need a better way of managing this stuff.

Acceptance Criteria: Entire Scope

One way to help you and your team write better acceptance criteria is to make them the sole authority on the scope of any new work. If there's no acceptance criterion for something, it isn't required. If it isn't required, it shouldn't be done.

For this to work, all ancillary documentation must carry exactly zero weight. The title of a story can't be "a little" meaningful. The description can't enforceable under "special circumstances". They are comments. They mean nothing.

Putting this rule in place has some side benefits I'll delve into later. Right now, I'd like to focus on the fact that this provides an incentive to figure out how to write good acceptance criteria.

If you can only specify a requirement with an acceptance criterion, you'll have to figure out how to make sure each one actually specifies a requirement.

How to Get Better Acceptance Criteria

It's easy to say "rely more heavily on acceptance criteria" but, without some guidelines, the acceptance criteria written end up not being very helpful; they tend to have little to do with acceptance and do a poor job as criteria.

Instituting a few simple rules can boost the effectiveness of shifting toward acceptance criteria as the main vehicle of communication between groups.

1. Acceptance criteria are the sole authority on the scope of a block of work.
2. Acceptance criteria cannot be modified while a block of work is in-flight.
3. An acceptance criterion is met if any of its valid interpretations are met.

I'll drill into each of these pieces of advice separately.

Acceptance Criteria as Vehicles for Specification and Delegation

One way to improve the happiness of both Product and Engineering groups is to change the way they communicate to be more validation-centric. Abandon the question "What do we do, now?" in favor of "How will we know when we've done the next thing?"

Anyone paying attention knows that this is a well-traveled topic, so much so that the question "How will we know when we're done?" is basically a cliché in the software industry. Nevertheless. It's my turn to say it.

Get rid of detailed instructions, descriptions, and design documents. Replace them all with acceptance criteria.

After all, what else matters? How useful is a design document that you can't use to tell whether or not you're done? If you have an instrument that tells you that, what's the value in the other documents?

If you can get good acceptance criteria - really, truly, good ones - you can drive noise out of the communication lines between Product and Engineering. It goes further than that, but fixing the (usually) broken handoff between those two organizations yields enough value on its own to justify the change.

Agreeing with this post is the easy part. Making the change is the hard part. There's a social aspect to it and a skills aspect to it.

In the latter category is a hard question:

How do we get really good acceptance criteria?

More on that to come.

Specification and Delegation

In any handoff of work, there are two ways for decisions to be transmitted: specification and delegation.

When specifying, the party requesting the work makes a decision and communicates that decision. When delegating, the requesting party conveys intent and authorizes the work-provider to make the necessary decisions on their behalf.

If you aren't getting the results you want out of communicating requests for work - whether it's enablers coming from architects or requirements coming from Product - you have two ways to make it better.

One option is to improve how you delegate. Make an attempt to better-convey intent, give a broad charter to realize that intent, and educate the people doing the work on how to evaluate whether or not they are moving closer to or further from the goal.

Another option is to improve how you specify. Make an attempt to eliminate the potential for misunderstandings in lines of communication, channels that cause information to change hands many times. Install feedback loops to ensure that specifications are met.

While you don't have to choose between getting good at one and getting good at another, do you have to choose one and only one path for any given decision at any given point of time.

That is, you can hand off the specification of a decision you've made or you can delegate a decision to someone else but you cannot delegate a decision to be made exactly as you would have made it.

Modus Priori