When Done Means Done - How to Create a Global Definition of Done
Since adopting Agile a few years back, we have been working very hard to get aligned with the practice, in particular Scrum. Weekly study groups sharpen our knowledge, and a number of team members have become certified Scrum Masters and Product Owners.
To fully embrace Scrum we needed to be more disciplined and implement more standardized processes. One of these was the “Definition of Done”.
What is a Definition of Done?
The Definition of Done (DoD) is a "shared understanding of expectations that software must live up to in order to be releasable into production", usually in the form of a checklist.
Importantly, a DoD is also specific to the environment and teams who are working with it, meaning what works for my team at Web Essentials may not work for yours. This blog post outlines what we learnt defining our own "Definition of Done" .
Why Create a Global Definition of Done?
In Scrum one of the characteristics of the development team is that they are self-organizing and have the power to decide on the best practices for their own team, such as how many times the code should be reviewed before being merged into the repository. So at first we gave each team the responsibility of creating their own DoD under the supervision of their certified Scrum Master. But these differing standards created a few issues:
- Inconsistency for clients - if a team switched halfway through a project, a change in definition could cause confusion for the client
Cross team complexity - cross functional team members such as PO, QA and support managers were juggling differing definitions depending which development team they were working with
On-boarding obstacles - instead of a universal training session on a global DoD, new staff would have a different understanding depending on which agile team they trained in first.
These inconsistencies soon made us realize we needed to centralize the rules to provide a common framework for all our agile teams to be guided by and ensure that certain steps could not be skipped. Creating an easily accessible and universally applicable DoD became part of the QA department goals for 2016.
How we did it
To create a DoD for the whole company, I brought on board a team of experts from all operation departments, including a QA Manager, IT Manager, Development Manager, Support Manager and the PO Team Lead.
As QA team lead with a good overview across all departments I proposed an initial list of quality requirements to include. This list was pretty long at around 20 in-depth points.
Rather than an overwhelming list of criteria, we wanted our final DoD to be a succinct checklist of the most important conditions; it should be easy for team members to remember and hung up next to their boards for fast reference during daily stand-ups.
Over a period of two months I got the DoD task force around a table every couple of weeks to refine the list and discuss the feedback from each of their teams.
Getting Down to Details
We agreed that the DoD only applies to tasks at the ticket level. Using the logic that all list items should be clear, tangible and easily verifiable, we reduced them down to the most important points i.e. the specific conditions that must be met to move a ticket on the Jira board from 'in testing' to 'done'. If a condition was not specific enough or could not be made any more specific we removed it from the DoD list.
As much of these quality criteria were too valuable to dismiss completely we decided to use them to create two accompanying sets of guidelines:
- Release Guidelines: conditions that must be met before the release of an increment to production
- Best Practice Guidelines: development best practices that all projects and development teams within the organization are expected to follow
We structured our final Definition of Done in two lists - an 11 point list for the initial developer, and a 10 point list for a QA peer reviewer.
Then came the time for presentation and roll-out to all departments. We presented our final product to the entire team, as it was important that everyone with a potential client facing role - including HR, Marketing and Sales - knew and started to understand what each point means.
But what about the autonomy of the self-organizing Agile teams?
Although we now had a global acceptance criteria across all projects, the development teams are still self-organizing and should have the power to decide their own best practices.
So we authorized them to add more definitions specifically for their own team. We also made it possible to override or change the global DoD for a specific project, subject to formal agreement from the QA team as resident quality authority. For consistency, these changes must be confirmed before the start of each sprint, not mid-sprint.
Here are a couple of exception examples from previous projects:
Each code change should be tested via continuous integration on our latest system and the client’s staging server before deployment to the live server
Reason for Exception
Client doesn’t have a staging environment on their hosting and requires an immediate deployment from our latest instance to live
Code must follow standard Web Essentials coding style
Reason for Exception
Client has their own coding guidelines. In this case, we follow the client coding style instead
If you need a disciplined development team who works to a consistently high quality standard: Talk to us today!