What is the Definition of Done (DOD) in SAFe (Scaled Agile Framework)?

"Definition of Done (DoD)" is probably the most important aspect when it comes to producing a piece of working software at the end of the iteration. We can follow all the practices, guidelines, values, and events 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 the 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 3 dimensions of the “team  &Technical Agility” competency; "Built-in Quality.”

SAFe® organizes built-in quality practices into five domains to account for these major differences in context:

Five domains of Built-in Quality

• 1Business functions – HR, marketing, finance, sales, and other disciplines that do not engineer technology-enabled solutions as a primary function are governed by quality standards that are unique to their fields. Examples could include accounting standards, marketing style guides, and employment laws.
• 2Software applications – Developing software-based solutions with built-in quality involves careful attention to functional, non-functional, and compliance requirements.
• 3IT systems – The infrastructure upon which software-based solutions operate must be designed with the scalability, reliability, and security needed to provide sustained business value.
• 4Hardware – Unlike purely digital products, hardware-based solutions have physical features that must conform to specific weight, tension, heat, thrust, electrical, or other engineering specifications.
• 5Cyber-physical systems – Systems comprising a multitude of hardware components controlled by complex software routines—such as automobiles and aircraft—involve a complex array of quality standards that large teams of teams must address.

Definition of Done for SAFe®

SAFe® has a clearly defined  Definition of Done at different levels. Each team, train, and enterprise should build their definition. While these may differ 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.

So, who owns these DoDs at different levels? These could be owned by Agile Teams, System Architects, and Solution Architects. SAFe® doesn't prescribe these ownerships, but we could follow this, so there is no ambiguity in a clear set of DoDs. The DoD is not static, and we continuously work on it to include more stringent criteria and different aspects. The teams could use the below events within the SAFe® framework to improve the DoD continuously.

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.

Coach Sync

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 events mentioned above. So, it is up to the teams to decide which way works better for them.