July 3, 2017
Complex and highly flexible processes dominate the software development industry.
No two projects are the same, and agreement on exactly how to tackle even the simplest tasks can differ widely from one team to another.
When we apply the measure of successful delivery, however, the noise begins to settle a bit. Historically, it is possible to look at many different software projects, examine how they were done, and make reasonably objective judgement on their success or failure.
As you might expect, some things work most of the time, some things don't.
Automated testing, for instance, is fairly widely accepted as a technique that has merit. How deeply it is applied, and whether the tests are written before or after the corresponding code can (and will!) be debated, but the existence of tests can be concluded to be a factor in the success of timely and cost-effective delivery of working software.
As we extract these accepted practices, then, we can form some reminders, some lists of things that can and should generally contribute to a successful outcome.
The details can vary, but general shapes tend to emerge, and from these lists we can create checklists.
Just like an pilot operating a sophisticated jetliner, a software practitioner can benefit from a set of simple list-form reminders. Not every one will be applicable in every situation, so we'll probably want to form separate lists for different situations.
Just like a pilot has a checklist for pre-takeoff, we might have a checklist for the time before a project gets underway, to ensure we have everything we generally need for a successful "launch" of a project.
Just like pilots have checklists for emergencies, we might have a list for common issues that arise: What are things to remember to do when project scope alters substantially mid "flight"? What should we do when our team loses a member unexpectedly?
We can, of course, "wing it" (pun intended, if abysmal), but that assumes two things: It assumes we've been in that particular situation ourselves before (e.g. we can't rely on the collective wisdom of a lot of different people), and it assumes we remember what we did (assuming what we did worked!).
That's why I like to create my own checklists from the distilled experiences of many different people, from many different perspectives, filtering down to things that worked - actions that didn't result in a successful delivery can be struck from the list.
These checklists don't diminish the need for great skill on the part of the practitioner: Just like piloting a jetliner can't be done by an amateur no matter how many lists he or she has, there is still a huge reliance on the practitioner knowing which list to use, and from that list, which items to emphasize, which items to skip, and when to go "off script".
Shorter, simpler projects might only need an abbreviated version of our checklist, whereas long and complex projects get the full treatment.
Still, the presence of the list ensures that, no matter how many times we've done it before, we don't forget items we've found to be important, things that we know will be valuable,