"Definition of Done (DoD)" is probably the most important aspect of Scrum. We can follow all the practices, guidelines, values, and ceremonies that Scrum suggests but still fail to deliver increments useful to the customers at the end of sprints if the Definition of Done is either not transparent or well defined or teams do not adhere to it.
When we ask a developer if it is done, the question remains ambiguous in the absence of a clear DoD. Without the DoD, it could mean, "Are you done with development" or "Are you done with development & testing" etc.
Also, responses like "almost done,” "it works on my machine,” "only integration pending,” "only security testing pending,” and "only performance improvement pending" defy the entire purpose of being Agile. The Scrum guide clearly defines when, how, and by whom the Definition of Done is defined and continuously refined.
But, what about the DoD in Scaled Agile Framework? When is the DoD defined in SAFe, and by whom? Who owns the DoD in SAFe? The term "Definition of Done does find its place in SAFe but is probably overshadowed by one of the 4 SAFe Core values; "Built-in Quality.”
SAFe describes how Built-in Quality organizes quality thinking around five explicit aspects—Flow, Architecture and Design Quality, Code Quality, System Quality, and Release Quality. Built-in quality is also a core principle of the Lean-Agile Mindset, helping to avoid the cost of delays (CoDs) associated with recalls, rework, and fixing defects.
Definition of Done for SAFe
The article "Built-in Quality" in SAFe has a section on the Scalable Definition of Done. It says, "The continuous development of incremental system functionality requires a scaled definition of done to ensure the right work is done at the right time, some early and some only for release.
Each team, train, and enterprise should build their definition. While these may be different for each ART or team, they usually share a core set of items". Here is the Example SAFe scalable Definition of Done from the SAFe website.
The teams could use the below events within the SAFe framework to continuously improve the DoD.
Iteration Retrospective
The Iteration Retrospective is a regular event where Agile Team members discuss the Iteration results, review their practices, and identify ways to improve. The qualitative part of the iteration retrospective is an opportunity for the Agile Teams to discuss the current process, focusing on finding one or two things they can do better in the next iteration. Agile Teams could continuously work on improving the DoD in this event.
Inspect and Adapt the workshop
Inspect and Adapt is a significant event held every PI. It is a regular time to reflect, collect data, and solve problems. All Teams and Stakeholders meet to inspect and adapt, which is timeboxed for 3 to 4 hours per PI. This could be another opportunity for all the Agile Teams in the ART to share & discuss their own DoDs and see how they could collectively improve the DoD for the entire ART. The RTE and System Architect could collaborate to act as the guardian of the DoD for ART. Again, SAFe doesn't explicitly recommend it, but this could be an option to manage the DoD for an ART.
Scrum of Scrum
Though this meeting is for different purposes, teams could also take this opportunity to discuss how to improve or refine the DoD. It is nowhere prescribed within the SAFe framework on how and when to work on the DoD, but SAFe doesn't prohibit discussing DoD in the above-mentioned events. So, it is up to the teams to decide which way works better for them.
Find Our Upcoming Training
