Recently, I was part of a retrospective with a team that is mature in terms of self-organization and collaboration. However, as I approached the topic of the Definition of Done, one of the participants slipped this sentence:
“If we follow our “Definition of Done” to the letter . . . we will triple our development time. I understand that it’s important, but we do not have that time available. “
The retrospective was coming to an end and I couldn’t delve into it at the time. However, it seems important to me to come back to this subject which is fundamental in Scrum.
Yes, indeed, I think that development time will be longer if the Definition of Done built by the team is applied conscientiously for each element of the Sprint Backlog and for the increment itself.
- Developing tests will always take longer than not developing them.
- Writing documentation will always take longer than not writing it.
- Systematically testing on all platforms will always take longer than testing only locally.
- , etc.
I understand that this is scary and perhaps discouraging to some, because we are dedicated to our work and we always want to be as efficient and quick as possible by delivering more value to our client.
The rhetorical question I ask myself is this one: is this really the best equation? Doesn’t short-term effectiveness cost more in the end? Is it rewarding to go back to a feature for weeks, even months, to fix bugs?
During this same retrospective and previous ones, we talked about certain recurring subjects. One of these topics was, “How do I facilitate the arrival of a new team member?” and in parallel, “How to work on the same product with several development teams in a consistent way?”
In response to these questions, an improvement in the documentation was designed. Improvement, because documentation had been started a few months ago but had not been updated . . . while the point “Write documentation” was in the team’s Definition of Done. So the team now had to go back to documenting, listing missing pages and writing them.
Another topic was: “Why was a stabilization sprint necessary before going into production?” The stabilization sprint consisted of fixing bugs, performing basic tests on the various platforms and also more extensive testing. However, in the Definition of Done, there were several points that spoke of tests (unit, functional and cross-platforms, in particular on mobile)
Another thing that should not be forgotten: a Definition of Done is worked on, it improves and completes itself as it goes.
With these few examples, I see multiple reasons to take the Definition of Done immediately into account during development and not afterwards by catching up with technical debt. The reasons that come to mind are:
- Technical quality
- Customer confidence
- Stakeholder confidence
- Transparency on the work delivered
- Delivering value rather than fixing bugs
- Less daunting work (more pleasant to do a few docs here and there than to make up for the missing documentation as a whole)
- Feeling of moving forward rather than backing up or rehashing
- Better visibility of the rest to be done
- Better calculation of velocity (with less technical debt and a real notion of done)
Let’s not forget that as Scrum teams, we deliver a done increment at the end of each sprint, potentially deliverable at all times. It is the application of the Definition of Done that allows us to guarantee this.
And you? What do you think? Do you see other reasons to apply the Definition of Done?
To go further
Some articles from the Agile KnowHow blog on technical debt, transparency and velocity: