prescriptive process

The Power of Checklists

The Power of ChecklistsSurgeons, astronauts, airline pilots and software professionals. What do all these people have in common? Well, for one, all of these professionals are very highly trained – in most cases in takes many years to reach a point where you can practice without supervision.

But even highly trained, experienced professionals can have a bad day, and make the occasional mistake. The problem is, if you’re an astronaut, airline pilot, or surgeon, and you make a mistake, lives can be lost. Software development, perhaps, is somewhat less life-critical, most of the time.

Simple checklists can help reduce human error dramatically. Some reports suggest that surgical checklists introduced by the World Health Organization have helped reduce mortality rates in major surgery by as much as 47%. Neil Armstrong had a checklist printed on the back of his glove (pictured), to ensure he remembered the important things as he made history as the first person to walk on the moon.

So if checklists can save lives, keep aircraft in the air, and help take people to the moon and back, why not utilize them to keep software projects on track, and help maximize the delivery of value, and minimize the risk of project failure?

Checklists help highly trained professionals focus on, and remember, the stuff that is important, and critical to the success of the endeavor they are working on. Unlike traditional process documentation, checklists are, by definition, lean, light and concise, so work well with agile development. The point is that they don’t burden a professional with lots of extra things to remember, or try to be prescriptive about how things are done – experienced professionals can generally be trusted to do the job properly, and make the right decisions when circumstances demand it – a checklist simply acts as an “aide-memoir” so nothing vital is forgotten.

So what does a software project checklist look like? Fortunately, some smart people have already done some work in this area, identifying a core set of checklists that can be applied to any software project, regardless of practices being applied, life-cycle being followed, or the technology or languages being used. They have been particularly effective when used in conjunction with agile approaches such as Scrum. These checklists are available in card form as Alpha State Cards, or as an iOS app.

You can learn more about the checklists by attending this free webinar.

Your feedback is welcomed!

The Kernel Journals 6: Where to (first/next)?

The Kernel Journals 6: Where to (first/next)?We all know that we want to “cut to the chase” as soon as we can and start incrementally developing the software product through which we deliver value back to the business. But we also know that there are certain essential pre-requisites to “sprinting”, such as some kind of vision of where we are supposed to be going and the right team and tools to get us there. If we start motoring before we are ready we may head off in the wrong direction or we may find that the wheels come off as we accelerate through the gears. Read More

The Kernel Journals 1: The Hegelian Dialectic of Software Engineering

The Kernel Journals 1: The Hegelian Dialectic of Software EngineeringWe in the software development industry face a seemingly intractable problem. We have learnt the lesson that prescriptive process is a bad thing. Process bureaucrats sitting in ivory method towers, telling highly-skilled professionals how to do their job and setting the process police on them if they don’t follow their instructions to the letter, can (unsurprisingly) be really quite damaging. It disempowers the development team  and engrains apathetic attitudes along the lines of “When we inevitably under-deliver, it will not be our fault, but the fault of these ludicrous process hoops that we are forced to jump through, instead of being able to focus on writing great software”.  The agile revolution was software engineering’s way of learning this lesson, and the agile manifesto pledge to value “people over process” and “software over documentation” has got to be right. But (… there was always a “but” coming …), we are already finding that the opposite extreme of little or no explicit process isn’t going to cut it either, because it leaves too many problems unsolved, such as: Read More