Alan S. Koch:I have added my editorial comments to each.
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 also 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! Too often, though, the reality is unhappy surprises due to a lack of preparation for release (preparation that begins with implementation requirements). 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.
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. 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 is overrated. It is much easier to just release and watch everyone scramble (and it can be more fun, too).”
Ask:The truth is that the project is not done until the product has been deployed. That means our project plans must include a release plan in addition to a development plan (and other plans, too).
Equate “Release” with “Deployment”
Is there a difference between release and deploy? Not in many shops. “Remember? We didn’t waste time with release planning, so the difference between the two is not important!”
For some, that all-important release date is the date of the Big Push. “Look out! Ready or not, here it comes! You weren’t ready? Too bad!”
For others, release simply means that the new stuff is out there ready to be used, but will anyone actually ever install and use it? “That is not our concern—we are just the development team!”
“Of course, the main reason why we don’t distinguish between release and deployment is because we didn’t bother with release planning. All of that nasty discussion would lead us to some sort of messy phased roll out, or pull-push combo. Without a plan, we can avoid all of that hard work.”
Ask: Again, the project is not done until the product has been deployed. In many environments, deployment and release are different matters.
Nothing Can Go Wrong
“Look at the brain trust we have in our development shop, and look at the time and effort that went into developing and testing the product. With all of the work we have already put in, we don’t need to waste even more time developing back-out plans.”
“The mere presence of a back-out plan might make everyone complacent. They’ll think, ‘It’s no big deal if the release fails; we can just back it out.’”
Ask:Murphy’s Law (“anything that can go wrong, will go wrong”) applies equally to release and deployment as to development. We prepare to deal with problems in the software we write because we know defects will be there. The same should be true of our release and deployment processes. Of Course, Everyone Knows!
“Communication is overrated. That was one of the reasons why we avoided release planning, right?”
“We have poured our hearts into building this brilliant, intuitive product. If the users are too dumb to figure it out, they can always call the help desk. And if our own operations and support people can’t figure it out, then there is something wrong with them.”
“And, of course, if they didn’t know the release was coming, then they must not have been paying attention. We’ve been working on this project for months! It has been in every status report.”
Ask:While we have been consumed with the project, all of these other stakeholders have been consumed with their own jobs. There is plenty that we need to communicate to them and we need to do this well ahead of the release date.
Throw It Over the Wall
“We already tested the product! Well, a little. What is left to test?”
“The release procedure is a no-brainer. It is so simple that a monkey (or even a trained manager) could do it. There is no way it could fail, so we won’t bother testing it. And those funky deployment scripts will be fine. I tested them on my own PC.”
“There is conversion to be done? We’re up to that. Just shut down the old system and we’ll hack through that old data with a machete until it’s subdued. If it is a really complex conversion, we’ll whip up a program that will do it for us, and, of course, there is no need to test that, because it is not being delivered to the end-users.”
“And if we went the extra mile of preparing roll-back procedures, we definitely didn’t test them. First, we are unlikely to need them, and if we do need them, we can make them work. We are highly paid professionals!”
Ask:Refer back to Murphy’s Law (six, above). Everything we build needs to be tested, whether it will be delivered to the users or not. Deployment’s success depends on this.
Using the Failure Checklist
Do you carefully manage the release of your software, or do you identify more with Carl's plight (it escapes before it is ready)? I hope these items have provided some insight. If so, I would love to hear what you have done about them. Here’s to your project success: Ask!
