How Can Checklists for Software Development Make a Difference?
Our goal at Ascendle is to get a product in the hands of users as quickly as possible because real-world feedback is what matters. I’m sure that’s your goal, too! The purpose of an innovative software development team is to deliver business value each and every sprint. At Ascendle we document all of our Scrum processes to make sure we are continuously improving on producing shippable increments every two weeks. Having this documentation not only helps one team execute at a high level, but all of our teams benefit from the continuous shared process improvement. And of all forms of documentation, one of the most useful are supporting checklists for software development.
The word ‘supporting’ is important here. It is our expectation that a team member is already familiar with the ins and outs of a given process, and that the checklist is being used as a helpful reminder, so they don’t miss a step or overlook a less-likely scenario they’re not used to spending time on. Our checklists are not meant to be stand-alone process documents.
Two Types of Checklists for Software Development
For the teams I’ve worked with there are two main categories that most checklists fall into:
1. A Summary of a Repeating Process
If you’ve ever been on a Scrum team you know there are repeating ceremonies. You also know when those ceremonies are managed well, and when they flounder. We have all had daily standups that far surpass the 15-minute timebox we set for ourselves, or the sprint review that broke our adopted standards. Scrum ceremonies are a great place to start with checklists. You may be following someone else’s documentation for running a Scrum ceremony. That’s just fine! Develop your own checklist for software development by summarizing the key parts of a ceremony into 5-10 steps. You don’t need to get into the nitty-gritty with your checklist. Keep it high level and focused on what works for your team.
For example:
Daily Standup Checklist for Software Development
- Prior to standup remind team to update their sub-tasks.
- Have each team member report on what they worked on since the last standup, what they plan to work on before the next standup, and any impediments they have.
- Do not let anyone pontificate! Move any discussions to the parking lot.
- Make sure all sub-tasks are updated on the board.
- Impediments? Gather information to address the impediment once Standup ends.
- Review the burndown chart with the team.
- Dismiss team members not needed for parking lot discussion.
2. A List of Requirements the Team Wants to Track
When you’re in the throes of delivering on a sprint, it can be difficult to keep all the deployment, security, testing and development standards in mind. You may find it helpful to use a checklist for a specific activity, like preparing the application for production release. In this scenario we tend to use a requirements checklist to inform the sub-tasks we create in Jira. Each of the following checklist items would be added as a separate sub-task in a user story on our sprint board.
Pre-release checklists for software development may include:
- Release branch created
- Deploy release branch to staging
- Penetration testing in staging complete
- Smoke testing in staging complete
- Load testing in staging complete
Other examples of requirement checklists we use:
- Sprint Management Checklist – this is used by the ScrumMaster to help remind them of what to be on the lookout for during a sprint.
- Definition of Done – also used by the ScrumMaster, this is referenced during sprint planning to make sure all user stories include sub-tasks that will ensure a user story is “done done.” This will often include things such as peer code review, unit test coverage percentage met, product owner signoff in Develop branch, etc.
- Definition of Ready – again, this is used by the ScrumMaster to clarify what conditions need to be met for a story to enter the sprint. Possible items to include are: all dependencies have been resolved, all test user credentials are approved, testing environments are up and running, etc.
Objections to Checklists
A common objection I hear when I talk about using checklists for software development is, “that’s just more bureaucracy and process.” A good checklist is one that supports or enhances the process that you are already doing, to make it easier, to provide insight to the entire team, or to help save you time. It shouldn’t be thought of as adding process, but as a tool to uphold the process. Let’s take a moment to appreciate that software development is really hard – there is a lot to think about, all the time. Think of a checklist as a mental reminder. We can all use reminders here and there!
“Checklists turn out…to be among the basic tools of the quality and productivity revolution in aviation, engineering, construction – in virtually every field combining high risk and complexity. Checklists seem lowly and simplistic, but they help fill in for the gaps in our brains and between our brains.” The Checklist Manifesto by Atul Gawande, renowned Brigham and Women’s Hospital surgeon and author.
Why Checklists Don’t Work
Checklists often don’t work. Why? The most common reason is that the checklists are not followed.
In 2014 an article was published in the New England Journal of Medicine that assessed the adoption and outcomes of surgical safety checklists in Ontario. They concluded that the checklists did not tangibly result in fewer deaths or surgical complications. The reasons behind the disappointing results pointed to a lack of formalized and standardized training, leading to improper use of the checklists. Checklists don’t have a chance at being useful if no one is using them.
The most effective way of ensuring effective use of checklists is to have the team members be the ones to create them. If the use of checklists is mandated by management and the team members are given little context for the value they provide, with no opportunity to provide input, checklists will gather dust. When I am coaching teams, I never require teams to use a checklist, but I encourage them to consider what checklists make sense for their team and the nuances of their project. After a team creates their relevant checklists, the next step is to have the discipline to use them. Effective use of the checklists should come from team members holding each other accountable – again, not from management.
Our founder and CEO is a pilot. The preflight checklist he uses is a crucial step to remembering to check all of the things that make the plane safe to fly, and decide if it’s safe to fly given weather and other situational conditions. He has prepped his plane for take-off hundreds of times, yet he always uses the checklist – as does every pilot who flies the plane you are on!
No one will die if a checklist isn’t followed in Scrum, but it’s the same principle. It’s a tool that helps reduce error and ensure consistent, repeatable process.
Our Recommendation for Creating Checklists for Software Development
Checklists for software development often come out of an idea to improve the team’s process in order to provide greater business value to our client. Often these ideas are raised in retrospective. At the end of retrospective the ScrumMaster could ask the team, “Would it help to create a checklist for any of the things we’ve talked about today?” If the answer is “no”, don’t force it! Ask again next time. I also encourage ScrumMasters and product owners to hold Communities of Practice meetings so that successes in one team can be share with another, in the spirit of continuous improvement. This is a good time to ask if any of your teams use checklists. If they do, ask if they’d be willing to share them with you.
Remember, a checklist should be created by the team who is going to use it. The use of a specific checklist should never be mandated by management, as the team will lack engagement and involvement. Checklists should never override communication and teamwork. At the end of the day, the decision to use or not use the checklists should remain in the hands of the team and not be a requirement across teams.
BONUS: Listen to the ScrumMaster Toolbox Podcast to hear Diana explain how she uses checklists in Scrum!
