We can talk all day about the intent of our Scrum teams delivering product increments in small iterations, learning from real customer feedback and delivering real customer value along the way.
The software engineering practices need to live up to ensure we actually deliver that high quality, technically shippable product increment. Without being sure we really know what “done” means when we declare a user story complete, we can try to draw nice burn down charts showing our claimed progress. However, when the rubber hits the road, without having clearly defined a “Definition of Done” (DoD) that the entire Scrum team is committed to and that gets rigorously applied when checking whether user stories are really “done” — we tend to fall back into the trap of illusion of progress. Pretty much like many times in the old, plan-driven or “waterfall”-defined days.
Recently, I had the opportunity to work with a software engineering team that refused to define and commit to a Definition of Done (DoD) — even a basic, entry-level version of a DoD – before they delivered the first version of their platform product. I was promised that they would define their first version of a DoD after their first product version had shipped. I acknowledge that is better to work on a DoD rather late than never.
However, my key question remains:
How do you avoid giving the illusion of progress and be reasonably sure that your software is really done, i.e. potentially shippable and really useful for your customers when you tell your stakeholders your software is ready?
Right, you capture the key and basic criteria to ensure quality via the “Definition of Done” such as the code has been
- implemented,
- documented,
- reviewed,
- built and deployed,
- passing tests,
- etc.
Moreover, you also agree upon and consistently check the application of a Definition of Ready (DoR) for the completeness of user stories that your product owners deliver as responsible author. This DoR will include valid and meaningful acceptance criteria for the user story to cover any story specific quality expectation — that your product owner obviously checks before accepting any user story as “done” as well.
Now, this is all very basic stuff about the application of agile methods and specifically Scrum.
Why do you care? Well in the end its all about reducing risk and removing any potential cause for delay and disappointment.
As simple and as obvious as these things may seem to any experienced Scrum practitioner — whether developer, PO or Scrum Master — I was surprised to see people thinking they would be running agile or “in Scrum mode” — even though they didn’t see the need to start by defining what “done” really means for them. Needless to say, that it did show: the results demoed even during the first sprint review that I attended were very “diverse” to say the least. Some demos worked as I would have expected in any Scrum review. Some demos of user stories failed entirely or delivered unexpected results.
Bottom line:
One of the things that I took away from the Scrum Master course that Ken Schwaber taught and that I had the pleasure to attend a few years ago was this: When you not just establish or adapt a particular practice, but you willingly ignore or violate some core principle of agile, then you run the risk that “you are doing something, but you are not doing Scrum!” as Ken told us back then.
Trying to deliver a product without making the effort of defining and committing to a Definition of Ready and a Definition of Done — not even be it in a very rudimentary form — in my book clearly falls under that category.
May I offer an a bit uncommon analogy that drives home the point about the danger of creating the illusion of progress:
As one of the former executives of a major ISV once told me: If you happen to spend time in a really cold environment in winter, like in Greenland, it may at first seem like a good idea to pee in your pants in order to help you feel warm. However, this only works for about a couple of minutes until it feels really damn cold!
A strong DoR and DoD will force you and your teams to raise difficult questions early, find appropriate solutions and make commitments that you will be able to deliver against.
original post:
https://medium.com/@whilpert/the-definition-of-done-is-not-for-wimps-19d101b8a254