Definitions of Done should be a co-star — not a supporting actor

Something I realised recently (which I knew in theory but ignored in practice) is that reminding teams that they are the ones responsible for quality (through incrementally developing their Definition of Done) is crucial.

Entropy is inevitable. Technical debt will accumulate as time goes along. At some point, technical debt becomes so much that teams will want to add “technical stories” to sprints. People start arguing that senior engineers should have equal footing with Product Owners about what goes into the backlog. “We have so much technical debt — we need to treat it just like any other story and prioritise it into sprints!” the team would murmur. Before this post, I would almost always agree with the team.

We know that the Product Owner is responsible for optimising value (building the right thing) and the Development Team is responsible for quality (building the thing right). In ideal Scrum-land, the Product Owner puts the right things to build on the product backlog, and the Development Team specifies how to build the things right through a solid Definition of Done.

But I’ve rarely seen a Definition of Done that’s alive and kicking (usually it ends up in a dark and dusty corner of the team wiki). On the other hand, every single team I’ve worked in had a monstrosity of a product backlog. So why is it that backlogs commands centre stage while Definitions of Done slip into obsolescence? Perhaps it’s the topic of another blog post, but my half-baked hypothesis is that the DoD’s limited surface area for contact (compared to the product backlog) combines with some cognitive bias to render it less significant (compared to the product backlog).

If your team’s DoD takes a backseat, all this “undone” work piles up and becomes technical debt. It becomes so bad at a point that the team typically wants to pay some of this technical debt off as part of “building the right thing” instead of “building the thing right”. At this point, it becomes a power game between Product Owners and the team. Product Owners are accused of not knowing what they’re doing, and all the technical debt makes implementing simple, valuable features so difficult that Product Owners lose all trust in the team. Vicious cycle.

My intuition is that this pattern can be mitigated if teams are reminded that they are responsible for (and mandated to ensure) the quality of the product. An incrementally developed Definitions of Done should be as important, visible and high-touch as the product backlog.

Hypothesis -- the Flair is not the ultimate beginner's espresso machine.

The Flair is not the ultimate beginner’s espresso machine.


I’m definitely not saying that it’s not an accessible espresso machine for beginner’s, because that it is: both because of its price point (relatively lower than other espresso machines) and its unintimidating user interface (no scary boilers or digital displays — just a big lever, some coffee and a cup).

I would go as far as to say that it’s the ultimate master’s espresso machine.

This is why:

  • It gives you (almost) full-control: you can make every single espresso recipe in any of John’s “four mother” recipe quadrants. I say almost. Something like the Decent espresso machine offers controls over brew temperature in a way the Flair would never be able to.
  • Paired with something like Naked Portafilter’s Smart Espresso Profiler for pressure and an Acacia scale for flow rate, you can measure everything you measure on something like a Decent espresso machine. Here’s a screenshot from https://www.naked-portafilter.com/smart-espresso-profiler/:


The Flair gives you incredible control. So much that, if you don’t really know what you’re doing, you might not know what to do with all this control (if you’re even aware of it in the first place). Even if you don’t know what you’re doing, the Flair might still give you amazing espresso (I know it does for me).