Fall, Falls, and a Fall

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

Auto-Close to Force Better Communication

Recently, I proposed some rules to eliminate ambiguity from acceptance criteria. They centered around the idea of automatically choosing a particular kind of interpretation.

It seems like a powerful tool, replacing decisions with automatic rules. Of course, you don't want to do it all the time...but it seems like a really good way to drive decision-making away from where we don't want it to be, like interpreting acceptance tests.

Another place we don't want judgment calls to be made is at the end of a story/task/work-item. It should be apparent, at that time, whether or not a story is ready to be closed. If it's not, it's already too late.

What if story-closure was automatic?

Imagine a workflow with the following properties.

• Anyone can close a story when all its criteria are met.
• Nobody can close a story if any of its criteria are unmet.
• The strictest interpretation of any given criterion is always enforced by Product, no matter how hard Engineering worked.
• Engineering can reject a story based on insufficient/ambiguous acceptance criteria, no matter how high priority Product says it is.

How would that change the conversation about what to do next, for your team?

Local Excellence and Global Alignment

It's popular in our industry to say you prefer global alignment over local excellence.

Sometimes that's part of an argument against investing in the technical skills of individual developers. Instead of "wasting" energy on that, you should solve the "real" problem: getting everyone marching to the same drummer.

I don't question the truth of the assertion but I do wonder if it considers enough factors to apply to the real world. Here are some questions we can ask ourselves to make sure it is useful guidance and not just some unconsidered platitude...

• Is global alignment as easy to achieve as local excellence?
• Is global alignment as enduring as local excellence?
• Does global alignment have a "critical mass" problem? (e.g., can you have 1% global alignment?)
• What does it cost to maintain global alignment over time?
• Does global alignment carry any typically-unexamined risks?
• Should global alignment and local excellence even be in competition in the first place?
• Can global alignment really be achieved and sustained in a software organization without skilled individual developers?

I'm not sure either way.

I suspect strongly, however, that the answers to the last two questions are "No", and "No."

Downtime

I'll add my voice to this chorus: Take breaks.

Stopping to smell the roses is great. Maintaining your sanity is paramount.

Those aren't the reasons for this post. Taking breaks improves your productivity.

There are immediate effects. You can gain inspiration from time spent doing something other than your main task. Unbroken focus creates blind spots. For those and other reasons, you can be struggling with a problem before a context change that seems simple afterward.

There's also a long-term benefit: As a software developer, your mind is your tool and all tools dull with use. Taking breaks allows your mind to regain its sharpness. Problems that seem intractable when you are tired or burned-out can melt away once you are properly rested and recharged.

Relaxation and recreation may seem selfish, or even hedonistic to some, but they are actually productivity tools of the highest caliber.

Acceptance Criteria: Eliminate Ambiguity

One of the problems that people have when trying to build real, meaningful acceptance criteria for their work is that the criteria end up being ambiguous. There are several reasons why this might be and I won't get into them, in this post.

Any such force can be at least partially counteracted by introducing one of two simple rules.

1. Any way to interpret an AC as met means it is met.
2. Any way to interpret an AC as unmet, it is unmet.

You might think these rules are horribly unfair and one-sided. Yet, that's why they work so well. They eliminate the potential for ambiguity by automatically selecting the most relaxed or strictest version of any AC.

At the same time, they provide an incentive to drive ambiguity out of an acceptance criterion's wording. The easiest way to ensure nobody uses the "wrong" version of an acceptance criterion is to make sure there is only one interpretation.

Over time, the criteria will justify themselves and no incentive will be required to make them unambiguous, but something like this can help at first.

Acceptance Criteria: All or Nothing

Commitment works both ways. Teams that commit to delivering on little pieces of acceptable work based upon agreed-to acceptance criteria need to know that Product commits to accepting based upon those same requirements.

Once an acceptance criterion is "in-flight", it should not be adjusted without unanimous consent by all stakeholders who originally committed to the requirement, including developers. Any dissent leaves the old criterion in force.

This gives Product several options for changing their minds:

1. Cancel a criterion and halt all work in that direction.
2. Renegotiate a criterion with engineering.
3. Add new criteria after the current ones are implemented.

Limiting your options to renegotiate creates an incentive to limit the size of an increment of work.

No Time to Swim