Most agile approaches recommend the use of explicit quality standards expressed as check-lists. Scrum has the Definition of Done to ensure the product is releasable, and Kanban teams use exit or entry criteria between stages to add rigor to the process.
For many years when teaching these concepts, we have compared this practice to the Surgical Safety Checklist advocated by the World Health Organisation. This was established as a sanity check to prevent silly mistakes:
- What is the site of the surgical procedure?
- Who is the anaesthetist?
- Do we have the same number of instruments at the end as we did at the start?
Going through a formal procedure reduces mistakes, or problems emerging half way through when it’s more difficult to resolve. The same idea is used in aviation in the form of pre-flight checks. We make the point that having a checklist doesn’t detract from the skills and expertise of the professionals – it just adds integrity to the process. Systematically, over 10,000 procedures, it will save a handful of unfortunate incidents. In software product delivery the outcomes are not always life and death, but there are still things that are reassuring to know:
- Is the support runbook still accurate?
- Are we sure the test environment isn’t connected to production?
- Do we have the same number of opening parentheses as closing parentheses?
It was interesting therefore to hear from the creator of the surgical safety checklist ten years after its creation. The use of quality standards through checklists seems to have the same benefits and the same problems, whether applied to surgery, flying a plane, or building software:
- When applied consistently, incident rates drop dramatically.
- In order to work, there must be commitment to the process.
- Highly skilled and educated individuals assume they know what’s best and ignore others.
- Resistance is likely – people don’t like “box-ticking exercises”.
- Resistance is even more likely if it is “handed down from management” or seen as irrelevant / out of date.
This is the intent of the surgical safety checklist, according to its creator:
The object of the checklist is not to eliminate thought but to stimulate it, by assisting professionals with the myriad routine tasks they must carry out, freeing them to do what they are trained to do.
For checklists to work, however, surgical units must make them their own, with local champions, regular feedback and sharing of experiences. They must be inclusive and simple to implement.
To achieve this for your team of technology professionals, try this:
- Have a conversation with the whole team about the purpose of the checklist, and the desired outcomes.
- Ensure that the checklist is created by the team themselves. Technology practice is so diverse that each team will need to create their own checklist from scratch.
- Keep the checklist alive: make it a formal part of daily activities such as marking work “done” and review it regularly during retrospectives.
- In an enterprise environment, put systems in place for teams to collaborate in the creation and maintenance of the checklist(s). Monthly or quarterly knowledge-sharing sessions work well.
- Teach teams to hold themselves to account. Mistakes are much less likely if the whole team is actively involved, rather than relying on one individual such as a scrum master.
- Put a date on the checklist when it was last reviewed and updated, so it’s easy to see if it has become a relic.
This article was first published at https://agility.im/insights/checklists-save-lives/