Recognize “Done” Traps

Teams might not realize they encounter “done” traps. Here are three I’ve seen too often in teams:

• The team has no “done” criteria.
• It “all” has to be done before any of it can be released.
• The team requires “hardening” iterations or effort.

I’ve seen teams where these “done” traps prevent the team from releasing anything. Consider enlisting your leadership and your allies to help the team see what “done” means and how to release intermittent value.

Trap: The Team Has No Criteria for “Done”

In my experience, teams want to deliver value. Also in my experience, teams need to know what “done” means at various levels: for the story, for the iteration if the team works in iterations, for releasing, and for the project. If the team does not have working agreements or criteria for what “done” means, it will done-done-done everyone to death. “Oh, you meant done-done?”

Help the team create working agreements for what “done” means. Let’s abolish this notion of done-done-done once and for all.

Trap: We Can’t Release Anything Until It’s “All” Done

I’ve seen product owners and teams create double-binds for themselves: they can’t get feedback until they release something. And they can’t release anything until it’s “all” done. Their agile project has very few deliverables. The deliverables they have are quite large.

And the larger the deliverable, the more likely the team is to make mistakes or not quite deliver what the product owner or customer wants. The team becomes frustrated because it worked for a long time on this product. The customer or product owner is frustrated because that person isn’t getting any value until too late. It’s a mess.

As a leader, you can help the product owner create small stories. See ​Write Small Stories​, for more details. Encourage the team to build a culture of experimentation so the team can try an MVE or an MVP to gain feedback as early as possible.

Trap: We Need to “Harden” the Product

Sometimes teams don’t realize that they have insufficient story-acceptance criteria. Or the team realizes at the end of an iteration or after some number of stories in flow that it didn’t really finish its work.

Teams that are new to agile approaches might not realize this not-doneness for a while. Some teams use the idea of a “hardening iteration” (this seems to occur more often in iterations than it does in flow) to finish the work they didn’t complete before.

Encourage the team to fix problems as soon as someone discovers them, especially if the work is not yet done. I don’t recommend a regular practice of hardening iterations.

If your team realizes it didn’t quite finish work it had previously marked as done, consider these options:

• Conduct a retrospective to understand what happened. Make sure not to blame anyone. Do unearth the data that led to people making what they thought was the best possible decision at the time.

• Watch any estimation efforts. Do people think they should forego or reduce testing to make a particular date or squeeze “more” into an iteration? This is another instance of “how much” thinking, which causes the team problems later. See if you can help everyone move to “how little” thinking instead.

• Revisit the idea of what “done” means for working agreements, for stories, for releases. Does the team need to refine any criteria to achieve technical excellence in its work?

If a team has trouble achieving its done criteria, reduce the work: the size of the stories and the work in progress. If the team encounters the need to “harden” its work infrequently, maybe you can ignore it. But I see teams that use hardening iterations or hardening activities every few weeks. That defeats the idea of finishing work so you never have to touch it again. Be wary of any “finish later” activities.