Until recently, I was under the impression that my obsessive use of checklists was just a way for me to ensure nothing slipped through the cracks. Then something entirely changed my outlook on checklists. In mid April, Jack Dorsey tweeted he was giving out copies of The Checklist Manifesto to Twitter employees. Being both a Jack Dorsey and checklist fan, I impulsively bought the book on Amazon. If you read the book, you'll notice that Dr. Atul Gawande, the author, wastes little time getting to the thesis - checklists are extremely powerful when used correctly.
Throughout the book, the author takes you on a journey through all the different applications of checklists. He has fascinating stories that illustrate how and why checklists are used in different professions. Through all the tips and pitfalls, the biggest takeaway was the following:
[Checklists] improve outcomes with no increase in skill.
In essence, checklists are a simple form of life hacking. A checklist can save you from forgetting a simple, yet crucial step or task, which can lead to more work. The more unnecessary work you can cut out, the more efficient you are. I typically look at life hacking as simple tools that allow you to exert less effort to achieve equal or better results. Checklists definitely fall into this category in my opinion.
There is a caveat with checklists. They don't make you more intelligent, they simply allow you to work more intelligently. The difference is subtle, but important. If you have ever heard of Test Driven Development (TDD), then the easiest metaphor would be saying checklists are essentially adding test coverage to the management of a project. Sometimes it's monotonous and overkill, but it's all worth it when you catch that small oversight that can be critical to your project's success. Plus, if you're anything like me, checklists (and proper TDD for that matter) allow you sleep with a clear mind at night.
One of my favorite quotes from the book is '[checklists] are quick and simple tools aimed to buttress the skills of expert professionals'. A common misconception is that checklists aren't functional in complex lines of work. The author proves the contrary with countless examples ranging from specialized surgery, building skyscrapers, flying a Boeing 747, and even venture capitalist investments. To demonstrate the practicality, Dr. Gawande created a checklist for the World Health Organization (WHO) to help combat common mistakes that can occur in an operating room during surgery. He goes into great detail about how he researched, created, and implemented the checklist; the outcome of said checklist was the rate of complications for surgical patients falling by 36% and deaths by 47%. It's hard to argue with those results.
So how can checklists be applied to development?
I've always found that the most important and often hardest parts of a project are the first 10% and the last 10%. Figuring out where to start and determining the first steps can be a tedious and overwhelming process. In my experience, if you build a checklist of all the deliverables that must be completed and then elaborate on each deliverable point-by-point, the momentum will begin to build and anxiety will recede.
As for the last 10%, it's typically just a matter of covering all your bases and polishing. If you discipline yourself to write down every loose end you come across as the project matures, then it's just a matter of crossing off those items 1 by 1 and giving them the attention to detail they deserve.
So taking that into consideration and incorporating the lessons learned from reading The Checklist Manifesto, my personal use of developing daily with checklists has evolved into what is described below.
Daily Checklist
In the past, I more or less broke down every project into a series of checklists and then slotted them into my calendar at the beginning of every sprint (thredUP's dev team is agile). It was essentially a checklist version of a burn down chart.
I found my system faulty for two reasons. First, it assumes the priorities remain static over the course of all your projects, which they rarely do. Second, it leads to developing with blinders on as after the initial super checklist is built, then all I did was crank out the remaining items. This is why I now create a brand new checklist every morning.
The daily checklist contains a bulleted list of everything I plan to accomplish that day. I often group the items by project and clearly define what items, if finished, would constitute a productive day. Anything that isn't completed will be recompiled and re-prioritized the next day. This is the key to the daily checklist - build it from scratch every morning so you can re-weigh the priority of each task in the context of how each project is progressing. The daily checklist keeps you on track throughout the day, ensures nothing obvious is passed over, and it helps give you some momentum as you progress through the list.
Project Checklist
For every project, assuming you know how to do it, determine the critical path and identify every step along the way. Those steps become the project checklist. Granularity on those steps should be a balance between diving in far enough to uncover any logic gaps on your implementation strategy while staying away from getting too into the weeds that you lose perspective. Once you know how you're going to do every one of your projects to a certain extent, you won't be stressed.
By not becoming too granular, you don't trap yourself into one way to approach the problem. I found that when I broke down all my projects in advance to very specific tasks, I was more resilient to change. If you balance it just right, you'll be able to talk intelligently on how the project will be done without becoming married to the specifics. I haven't mastered that last part yet, but I do try to keep it in mind.
I was going to talk about my secret weapon - my email inbox - but I'll save that for a different post. As for how I actually create these checklists, I do it the old fashioned way - pen and paper.
For the project checklists I'll often start on a whiteboard and transfer it to Basecamp so I can circulate my strategy to the project stakeholders.
In conclusion, I do not propose that this post will apply to all developers or even a large subset. Also, this definitely isn't applicable to all work environments so think about this in the context of your unique situation. This was not written in stone and I'm always looking for ways to improve it or have some of my assumptions proven wrong. If you have thoughts, ideas or criticism (whether it's constructive or not), I'd love to hear about it in the comments below.
