“We don’t release software. It escapes!”—Carl, my former boss and a VP of Development
My former boss, Carl, once tried enticing me to join his management team by emphasizing how badly the company could use my process discipline skills—it worked. I felt bad for them, and I was intrigued by the challenge. But, I learned at least as much as they did during my tenure there.
Over the course of my career, I have seen many instances of people failing at release management. In this article, I highlight eight statements that I have heard over the years from people in our line of work. Even though these people abide by these statements, they would never dare to repeat them out loud. I hope you will find inspiration not to follow these sayings!
Alan S. Koch— I have added my editorial comments to each.
1. Don’t Think about Release until It Is Time
“Product requirements are what we need to get the project started. We need to understand what to build and what to test for, so we spend a bunch of time up front figuring these things out and writing them down. That prepares us for the project. Right?”
In Carl's shop, this thought process resulted in a commercially-sold product that was impossible for customers to install. For every new customer, a developer had to carry a tape to their site and do the install for them.
The Business Analysis Body of Knowledge (BABOK) guide focuses on the requirements process, while highlighting a type of often-overlooked requirement. Implementation requirements refer to the requirements, not for what the system will do and be after release, but for what is needed in order to do the release and deployment.
“But, why should we worry about these things before release? We’ll be able to figure it all out when the time comes.”
ASK—We wish! But too often, the reality is unhappy surprises due to a lack of preparation for release—preparation that begins with implementation requirements.
2. Use Build Management as Punishment
There is a famous story about a Microsoft development team in which the job of doing the daily build was used as punishment for the programmer who broke the prior day’s build. Although this story may be apocryphal, it is not far off from how many companies do builds.
Carl's shop didn't use the build as punishment. Their thought process went more like this: “Nobody likes doing the build, so we must be fair and spread the pain out to everyone. We all know what we are doing, so this policy shouldn’t cause problems!”
ASK— Many shops seem to be trying to avoid consistency in the build process by rotating this essential duty among the staff. The builds that were used in each QA cycle and the one that was finally released may differ in “interesting” ways.
3. Quick! Be in a Hurry!
Speaking of QA cycles…
“Who has time to fully test the product? First, the testers want way too much of the development schedule for testing. Then, they complain when delivery of the product to test is delayed but the release date remains unchanged. The reality is that time is a luxury that we can rarely afford. We must hit our dates, or else.”
ASK— This is precisely what Carl had in mind when he said their software escaped —too much hurry and too little validation. In spite of their best intentions, teams often find themselves slapping the product together, doing a quick checkout, and then watching helplessly as it rampages into production like a proverbial bull in a China shop. A little more time to tame the bull would be a well-placed investment.
4. Don’t Waste Time on Release Planning
“What’s to plan, anyway? When the predetermined date arrives, you declare the product to be done and you release it.
“Planning for release is a big headache. It requires that we step outside of our project cave and talk to a whole lot of people. First, there is operations, who have a million questions and concerns, followed by complaints and constraints. Then, there are the support folks and the help desk who want documentation, tutorials, hand holding, and general baby-sitting. And, of course, the end-users are the real nightmare. There is never a good time to do a release. They want it yesterday—but never tomorrow.
“Planning and gaining consensus