ISerialized .Net, C#, Scrum and agile software development

Checklists in software development

I guess a big percent of the developers reading my blog have stopped reading already, another big percentage probably still reads, but for the sole purpose to find out what's wrong with this stupid f*** who mentions the words checklists and software development in the same sentence! http://utihagen.com/?p=116

For those how have already stopped reading, there is not much I can do, other than feel sorry for their employers who hire people who wont keep an open mind and try new techniques to make us even better developers!

In most of my professional career I have worked as a consultant, with a constant focus on hours spent vs. value added to my customers. As a rookie you are normally afraid you don't have enough work to fill the day, being a senior or an architect is the opposite, I have too many obligations, too many projects to monitor, too many customers and too little time. And how do we solve this?

I see too many who end up just being the firefighter: always short of time, always on the project where hell has broken loose, always stressed and always cranky! I got tired of being a fire fighter, got tired of being cranky when I came home to my children, got tired of saving the day!

How did I solve my problems? I started using checklists!

The checklist theory

Too many developers have been forced to use a set of checklists that never worked, and therefore hate the word an all it stands for! But I guess the biggest problem was that they were incorrect all from the beginning. Designing a good checklist is hard, and we need to keep a couple of things in mind:

• What is the single(!) purpose of the checklist?
• What kind of checklist is it, is it a READ-DO checklist, or a DO-CONFIRM checklist?

If you have not decided whether your checklist is a READ-DO or a DO-CONFIRM checklist, or you try to  add too much into your checklist, you end up with a failure. Everybody else will hate your checklist, and you will probably hate it yourselves or at least not use it! Its hard to use, only parts of it is relevant in certain situations, and it takes too much time to use! It steals time, it doesn't save you time!

Read-Do or Do-Confirm

When we talk about checklists, we basically divide between to types (More details can be found in the book "The checklist manifesto" by Atul Gawande).

• Read-Do.  With a Read-Do checklist, people carry out the tasks as they check them off. More like a recipe.
• Do-Confirm. With a Do-Confirm checklist, team members perform their jobs from memory and experience, often separately: But then they stop. They pause to run the checklist and confirm that everything that was supposed to be done was done.

When we design a new check list we need to keep this decision in mind, when will our checklist be used and what makes most sense for the situation?

My experiences with Read-Do and Do-Confirm

The concepts of Read-Do and Do-Confirm comes from aviation where the need of checklists are crucial due to both complexity and the fact that you are airborne and have only a certain  time to figure out what's wrong before its too late!

In our business this is seldom the case, but we still have the need to keep the distinction in place! My experiences are that I use Read-Do checklists on:

1. Tasks involving rookie developers
2. Getting a developers started on an existing project (rookie or senior)
3. Tasks I seldom do where I tend to forget what was involved

Do-Confirm checklists on the other hand is my preferred choice on:

1. Everyday business where I still need a checklist to remember each step
2. Fallback checklists for support when we are stuck and need to confirm that we have tried all common solutions/trials.
3. Tasks involving senior developers
4. My weekly tasks (Normally remember to do code review on project A, remember to check reported issues each week on project B ect.)

But do we need checklists?

It's important to note that a check-list will never be able to replace competency and experience, but that's not their purpose either!

If the checklist doesn't work, change it. If it still doesn't work, it probably means you don't need a checklist in that specific situation. If the checklist work on the other hand, grasp it!

But why are we so hostile? Is it beyond our dignity? Do you think you are to smart to need a checklist? We all need checklists!  We can all make it through the day without checklists, but we end up less productive and with greater overhead, as we easily end up being re-active instead of pro-active! Once again, it costs our customers a lot of money!

Where do I use checklists

To optimize my daily work, keep track of my projects and beeing as effective as possible, I have developed a set of quick and efficient checklists. To sum up the most common situations where I tend to create check lists:

• Bug tracking. Who has never spent hours or days searching for a  bug, and in the end found that the error was a trivial thing you could have solved in 5 minutes if you just started in the correct end! A checklist will never be able to solve all these, but keeping a short checklist for these situations might solve 1 of 10 of these issues, saving us hours and days each year! I will rather do development than bug tracking! This is a perfect Do-Confirm when you feel stuck, and are about to deep dive into the code-base to look for a solution!
• Configuring a projects development environment. How many hours do a developer use, setting up development environment when he starts on your project? Configuration and setup of a dev env is a perfect read-do checklist!
• Customer support. Here I use both Do-Confirm and Read-Do checklists as most issues are easily solved without checklists.
• Release procedures. In all my project I have an strict rule, that all steps should be automated through scripts (if possible). The rest is handled with a single read-do checklist. At this stage and this close to a production environment, the steps are too critical to be handled through a Do-Confirm, as a missed step can be crucial!
• Work-week tasks. I keep a simple work-week Do-Confirm checklist to remember the minimum effort I must put in each of my projects each week. Normally I use it to remember to take a look at production logs, do code-review, remember to go through all follow-ups in Outlook, remember to take a quick look at next weeks calendar to see if there are something I need to prepare. It takes me a minimum of time to go through this list, but it keeps me clear of allot of panic attacks and ulcers!
• Smoke testing. I keep a very short smoke-testing checklist of what we always have to test before a release, even though we only change small fractions of our code-base. Check the normal pitfalls, check that most screens can be opened without exceptions, that the installer is able to start etc. Very small, just to avoid the most embarrassing errors. It doesn't replace real testing, but it is short enough (5 min) to run through it after those dangerous microscopic last minute changes right before a release!

The future

When a product is complex, when a developer fails or screws things up, when we introduce the same error again three months after we fixed it, we can either say that we will try harder next time, or that the developer is incompetent, or we could look for permanent improvements to make sure we do a better job in the future!

We see the pattern and we see the cost. We can be naive and think that we will suddenly improve and that the world will become less complex, or we could try something new! Try checklists!

Related Posts

Cynefin Framework in the context of agile vs.

Playing Last.FM radio on Squeezebox outside UK, US

Timeboxing in Scrum

Troubleshooting Squeezebox network connections

Scrum is like a game of Backgammon

Five key principles to mitigate risk

Features/Epics vs. user stories in Scrum

Log4Net for noobs

Getting started with Flattr

Code segments and syntax highlighting in Confluence

prev next

Related Posts Slider