Definitions of Done should be a co-star — not a supporting actor17 May 2018
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.