My first big responsibility at my current job was to package a release and deploy it to the customer. Back in those days (2007), that involved creating a set of installers (server, desktop and tablet client – Windows XP tablet), burning them to a CD then driving to the client site on the day all the mobile workers returned to base for their monthly meeting, and installing into all the machines.
I remember my dad telling me how he taught others. Let them sit at the machine. Let them take notes. And be patient.
There weren’t many notes to work from at the time, and I wanted to be confident I could do it myself next time, so I wrote the steps down as a series of checklists, one for QA and build, one for media prep and one each for installing onto each target device.
And I noticed something. As soon as it was written down, I started to see where things were duplicated or could be automated. Within a couple of releases, I’d got the checklist down from 5 sides of A4 to 2. I probably could have done more, but 1 sheet felt right, and that project was coming to a close.
I thought every project had a way to visualise their release process, it sounded obvious. It wasn’t always the case, as I discovered when I started working on legacy projects with ad-hoc procedures and distributed troubleshooting guides, a SQL script here, a helpdesk ticket there, or an appendix in the technical architecture. It seemed crazy to me. You’re dealing with a legacy system, with a complex deployment process, or build process, scattered throughout various machines, and various people’s heads. It’s error prone and you want to improve it.
The first step to improvement is understanding, and the first step to understanding is to visualise it. If you don’t know what you’re doing, make it visible.