As a project manager, the process of releasing software can be fraught with anxiety and dread. I can think about numerous times in my career where, in the shadow of an approaching release deadline, the thought of having to ship our application was akin to contemplating an imminent visit to the dentist. In fact, even the mechanism for getting our ‘awesome new features’ into the hands of our users felt like pulling teeth.
The temptation is to release as infrequently as possible, just as the temptation is to visit the dentist as rarely as you can get away with it. You know you ought to go more regularly but you fear it’s going to be really painful. You may even have a haunting memory of a previous visit that ended up with your pearly whites on the receiving end of the dental drill. Personally, my teeth ache just thinking about it.
Instead of visiting the dentist regularly, maybe at six monthly intervals, you might find yourself making excuses and putting it off. As a result, you never get around to that check-up and only drag yourself into the dental surgery two years later, when you’ve got a cavity the size of the Grand Canyon. I know I’ve done this, fully aware of the risk that it might happen and have subsequently chastised myself when it does. Ironically, the resultant marathon stint in the dentist’s chair contributes to the haunting memories that compelled me to avoid check-ups in the first place.
In the software development world, leaving an extended period between releases of your software is just as risky an approach as forgoing regular dental check-ups. The bigger the gap between deployments, the larger the amount of work – code changes, database schema modifications, configuration alterations – that have not been validated by your customers. The greater the functionality and code delta between deployments, the more likely the new release has broken something serious, unleashing a horde of pointy-fanged bugs that are going to eat your time and leave your plan for the next development iteration in tatters.
Instead of worrying about the huge list of changes you’ve built up between releases, you can feel better by simply assuming that you got your decisions right. You can assume that you made a good call regarding which new features to add, how to design the user interface so it is ‘easy to use’ and whether the user is going to like it more when it’s drawn in mauve. However, you can only prove you got that stuff right by giving it to your users. The bigger the gap between releases, the more development effort you are gambling has gone ‘right’. When the release is finally out, your users are going to tell you if you got it right through sales figures, raised bugs, direct feedback and even social media. So, if you got that decision on drawing it in mauve wrong, that’s when the pain really starts.
Back in the dentist’s chair, the longer the gap between check-ups, the more food you’ve eaten between visits and the more unchecked bacteria builds up on your teeth. You’re assuming that you are brushing your teeth right and that your reticence to floss has not impacted too much on your dental hygiene. However, if you got that wrong, that’s when things get painful.
Leading Agile Teams 
Leave a Reply