Done is Fun
Done; but only “close enough.” — sounds familiar? Insights, tools, techniques, and an AI-generated surprise await you in this week’s edition. Get your quality and predictability on point.
Agile Matinée is a fortnightly dispatch curated by Panaxeo, one Agile topic at a time. We bribe five Agile enthusiasts with croissants and expect them to collect interesting and read-worthy content in return. Here’s one centered around creating a great (Definition of) Done.
tl;dr: Unless done is really Done, you’re not doing Scrum!
A good ‘Done’ unlocks consistent quality, sustainability, and frictionless, timely feedback from stakeholders and users. The Definition of Done is a powerful tool to gain a 360 perspective on what quality means for everyone involved. Plus, it’s a way to control that creeping tech debt.
So, why do so many teams struggle with getting their DoDs right, and what are the remedies? Let’s go.
1. Stronger Together - Use DoD to improve Quality & Workflow in Tandem
This blog explains the link between DoD and quality, inspires you with a logical structure for your DoDs, surprises you with an opportunity to improve your DoD and workflows in parallel, and caps it off with a tricky story about Jim from compliance who tried to ruin a Scrum Team’s flow (with a happy ending). Learn something new and be Definitely Done.
2. Is this a game for you? — DoD Kards
While “Cards against Bad Quality” would have been a better name, DoD Kards remain a creative facilitation tool for a team-wide DoD discussion. Print ‘em out and go do something great for your product’s health.
3. Excel(lent) - DoD Template for Remote Teams
You want to facilitate a DoD discussion and capture the outcomes, but DoD Kards don’t cut it because Cindy is connecting from a cruise ship via Zoom. Luckily, Ignazio Paz – a skilled Agile MooC teacher – leaked one of his DoD templates out to the wild. Take it, customize it, hold a vote, save it, send it to your stakeholders, and finally, follow Ignazio on LinkedIn.
4. Broke! - 4 Scrum Anti-Patterns that Cause Technical Debt
Poor, absent, or outright ignored DoDs is a faucet that leaks technical debt until you’re knee-deep and weeping in desperation. Maarten describes 4 common causes for a flourishing tech debt in his blog, along with a more nuanced explanation of how to approach DoDs in multi-team environments. Oh, and a word or two about why Hardening Sprints suck.
5. OmG — DoR vs. DoD vs. AC
This might be a 101, but we hear some folks get confused by the difference between Acceptance Criteria, Definition of Done, and Definition of Ready. Clarity is only two links and 10 minutes away, so no more excuses! ;)
6. Ey, Ay! — We Asked ChatGPT Why Teams Struggle with their DoDs.
And it’s pretty good, actually. Albeit, quite long, you may want to pace yourself.
1. Ambiguity: Avoid using vague or unclear language. Make sure each criterion is specific and easy to understand, so the team knows exactly what is expected. 2. Overloading the DoD: Don't include too many criteria, as this can overwhelm the team and make it difficult to achieve a state of "done." Focus on the most important aspects that ensure a high-quality product increment. 3. Ignoring team input: The Definition of Done should be a collaborative effort involving the entire Scrum team. Avoid imposing a top-down approach, and ensure that all team members have the opportunity to contribute to the DoD's creation. 4. Neglecting stakeholder expectations: Be sure to consider the needs and expectations of all relevant stakeholders, including customers, product owners, and other business units, when defining the DoD. 5. Overlooking continuous improvement: The DoD should be a living document, subject to regular review and adjustment as your team and project evolve. Avoid treating it as a static, unchangeable set of rules. 6. Confusing the DoD with acceptance criteria: While both are important, the DoD represents the general criteria for determining when work is complete, while acceptance criteria are specific to individual user stories. Avoid mixing these two concepts. 7. Forgetting to align with organizational standards: Your DoD should be in line with your organization's quality, regulatory, and other relevant standards. Avoid creating a DoD that does not adhere to these guidelines, as this can lead to inconsistencies and compliance issues. 8. Inconsistency across teams: If you have multiple Scrum teams, try to maintain a consistent DoD across all of them. This will help streamline cross-team collaboration and ensure a uniform approach to product quality. 9. Focusing solely on functionality: While functional requirements are important, do not forget about non-functional aspects such as performance, security, usability, and maintainability. Including these aspects in your DoD will help ensure a well-rounded, high-quality product. 10. Not adapting to the project's context: Different projects may have unique requirements and constraints that should be reflected in the DoD. Avoid using a one-size-fits-all approach and customize the DoD for each specific project, while still maintaining consistency across teams. 11. Lack of clear ownership: Assigning clear ownership for validating the DoD criteria helps prevent confusion and miscommunication. Avoid situations where team members are unsure of who is responsible for verifying that the DoD has been met. 12. Overemphasis on documentation: While documentation is essential, avoid making the DoD overly focused on documentation at the expense of actual product quality. The primary goal of the DoD should be to ensure a high-quality product increment, not just thorough documentation. 13. Insufficient communication: Make sure the DoD is effectively communicated to all team members, as well as relevant stakeholders. Avoid assuming that everyone is on the same page without explicitly discussing and clarifying the DoD. 14. Not considering technical debt: Addressing technical debt should be part of the DoD to maintain the long-term health of your product. Avoid ignoring technical debt, as this can lead to increased maintenance costs and decreased product quality over time. 15. Skipping the validation process: After defining the DoD, it's crucial to ensure that it's being followed and validated throughout the development process. Avoid treating the DoD as a mere checklist without actively using it to guide and evaluate the work.That’s it; we’re off.
Hope you’ve basked enough in this Agile well of inspiration. Now go about your day and put this stuff into practice! Oh, and unless you want to miss our next digest, follow us on LinkedIn or share this post with your friends and frenemies!
Hasta la Agilista, baby!