Over the last several blog posts, we’ve learned to shape the path by tweaking the environment and building habits. In the embedded video, we will use a technology that combines the two: the humble checklist.
Checklists On Software Teams
How might a software development team use checklists? Let’s examine four cases:
- Code review
- Retrospectives
- Run lists
- Continuous Delivery
Code Review
In code review, you can have a checklist to confirm that you have addressed the following list of concerns (not meant to be exhaustive) before code is committed:
- formatting
- architecture
- best practices
- security
- performance
- testability
- monitoring and alerting
- usability
Retrospectives
Also, retrospectives can use a form of checklist in the five steps to a retrospective (from the book Agile Retrospectives):
- set the stage
- gather data
- generate insights
- decide what to do
- close the retrospective
Run lists
Furthermore, in operations, run lists and standard operating procedures provide a form of checklist. They reduce the chance of human error in processes that are difficult to automate or have not yet been automated.
Continuous Delivery
Finally, continuous integration and continuous delivery systems provide checklists too, but we have automated them. What other checklists can you think of?
Coming Up Next
Now we’ve seen how to shape the path by tweaking the environment, building supportive habits, preloading decisions with action triggers, and using checklists. In the next few blog posts, we will examine the final piece of the puzzle: the influence of other people. We’re going to learn how to rally the herd.
I would love to hear what you thought of the video, so feel free to comment below, on The K Guy Twitter, or on The K Guy Facebook fan page.