Why Demo Meetings Require Insanity

You can’t be “Done” and also demoing for feedback.

If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

(Side note - if the DoD changes does every story ever completed return to the backlog?)

In an agile environment “Done” requires several iterations; continually applying a checklist to something that has not been approved by a review is not going to make it more done. It’s just going to gold plate something unlikely to meet expectations and make everyone less inclined to improve it.

Even in a not agile environment quality is an investment - not the result of a “Definition of Done”.

You can invest in the level of automated testing necessary to guarantee quality, but you might instead decide to invest in moving to a new architecture or a new testing infrastructure.

Every developer knows this. For any piece of code I write the testing strategy can vary. Sometimes unit testing works and sometimes only integration or UI automation testing makes sense. Maybe TDD is appropriate and maybe not. DoD imagines there is one standard that can be applied for all projects and stories undertaken by an organization and this finishing work should be done before review.

Similarly, you can’t be agile and also have “acceptance criteria”. If we know exactly what we are building than why are we having a demo meeting?

So demo meetings require insanity on multiple fronts.

We have to believe in an edict like “all code must be unit tested” when we know full well there are all kinds of testing strategies and levels of testing.

We have to wait for a demo meeting when what we really need is immediate feedback - not in a week or two.

Finally, we have to apply that not agile DoD and acceptance criteria to work that will likely change dramatically in the next iteration.

How to Stop the Insanity

Best practices are important, but they can only take you so far. An ever-growing number of developer tools and services have stepped up to help handle the complexity of software development - IDEs, CI/CD, open source, source control, AWS, etc.

We have tools for code reviews, and we need to approach higher level feedback the same way - with tools that handle the complexity of gathering opinions without waiting to demo.