Getting things done differs per person.
For some, it is about the minimal effort for minimal results; for others, it is about hard-work and high achievements.
It is already challenging to align people on concrete deliverables like when building a house or cooking a meal.
It is even more complex for software.
Different perceptions lead to all sorts of waste building software: overwork, waiting-time, defects, rework.
Teams able to systematically consider software changes as completed with minimal effort can deliver continuous software increments.
This article covers the need and guidelines to start building such Quality Engineering capability for Quality at Speed software.
Follow the QE Unit for more Quality Engineering from the community.
What is the Definition of Done (DoD)
Agile methodologies define the Definition of Done as a formal description enabling to consider software changes meeting the quality requirements for a product.
The key aspect of DoD is to be:
- Aligned on company values
- Adapted to specific tasks
- Shared with the team
- Systematically performed
- Clear and concise requirements.
Concretely, an organization putting customer privacy as a key differentiator of their value proposition would add this requirement in their DoD.
The Definition of Done therefore contains a core checklist of quality attributes then adapted in different task templates.
It is equally important to differentiate what DoD are not:
- The scope of work
- The acceptance criteria
- The delivery of increments.
Implementation details are checked against DoD, while verifying the prerequisites for starting to work on software is a similar yet different concept, the Definition of Ready (DoR).
Now, what to do with DoD in Quality Engineering?
Why using DoD in Quality Engineering
Quality Engineering is the paradigm constraining the entire lifecycle to Quality at Speed software, continuously delivering valuable software.
Its implementation relies on the 5 domains of the Quality Engineering Framework, MAMOS: Methods, Architecture, Management & culture, Organization, Skills.
The Definition of Done is part of the Methods domain contributing both to Quality and Speed.
How DoD contributes to Quality
It feels good to work with peers aligned on the quality to deliver—a frictionless experience is generated enabling to focus on what matters.
Meeting the high-standard of Quality delivery built upon shared expectations reinforced by continuous feedback loops brought by DoD.
DoD contributes to Quality being:
- Result-oriented by explicitly define the state of quality requirements to meet
- Systematic with a checklist-approach applicable to different tasks
- Scale allowing to start small, then add requirements and expand them.
How DoD contributes to Speed
Economies of speed are equally—if not more—necessary to survive the digital transformation where fast actors quickly disrupt markets.
The actors able to meet their Quality requirements have the challenge of Speed, requiring streamlining the lifecycle to minimal viable iterations.
DoD contributes to Speed with:
- Focus in meeting the essential quality requirements
- Rhythm training faster iterations thanks for repeatability
- Asynchronous being a checklist easily shared and updated
- Visibility consulting the status of the implementation tasks, anytime.
How to start with DoD in Quality Engineering
Implementing the Definition of Done requires a collaborative exercise aligned with the company goals and values to maximize its value.
The DoD implementation process consists of:
- Gather the organization goals and values
- Identify the transversal software stakeholders
- Organize workshops to draft a Definition of Done
- Test it with minimal checklist in a few teams
- Continuously measure, adapt and share to improve
Mature teams end up with a core Definition of Done that is then tailored to different templates of tasks, maximizing their Quality at Speed capability.
One important point of DoD is to be incremental: you can start with minimal quality requirements, and add more through experimentation.
These quality attributes are minimal in Quality Engineering:
- Design
- Coding
- Test
- Code review
- Build
- Functional test passed
- Product owner accepted the story.
You can then add valuable practices along the way such as:
- Requirements review
- Architecture review
- Documentation update
- Non-functional test passed
- Unit test with build-time under x minutes
- Minimal automated test working
- Alerting & value rules defined
- Backlog of bugs cleaned.
It is recommended to use a common tool for task management to ease the collaboration, alignment, and scalability of DoDs.
Different type of tasks require adapting the DoD to what matters in context. This is where the alignment with the actors and organizational values helps focusing on the essential ones.
You can leverage standard solutions such as Basecamp, Atlassian JIRA, among others.
Below is one example of an incremental approach to DoD:
DoD within MAMOS, the Quality Engineering framework
Definition of Done is an essential practice to start with the Quality Engineering framework to progress towards Quality at Speed.
The DoD methodology is a powerful practice that can be maximized cascading from OKRs, combined in Kanban, and complemented with DoR.
But Quality at Speed software requires more than methods—it is about the alignment of 5 domains of MAMOS.
Implementing DoD with a complex architecture leading to delays and defects to perform simple changes will be of limited outcomes.
Building a Quality Engineering ecosystem is the responsibility of leaders, combining the most valuable practices and continuously linking outputs to the outcomes.
So, when would you consider your job done?
References
Definition of Done, Agile Alliance.
Derek Huether (2017), Definition of Done, Leading Agile.
What is the Definition of Done (DoD) in software development? Future Processing.
The Definition of Done: What Product Managers Need to Know, Product Plan.