The death march towards the release date has begun. The email just went out to ask for “volunteers” to put in a few extra hours this weekend to complete a couple rounds of testing before sending it over the wall for user testing. The project manager is trying to herd cats to get a complete status before the leadership team goes on “holiday”. The developers are questioning why leadership isn’t going to be in on the weekend and what does volunteer mean anyways. It will be frowned upon if they don’t show up.

Unfortunately, this story is one that I have seen replayed constantly. Only the names of the people involved change. Reason is thrown out the window for most projects when there is a fixed release date. Pizza sales and coffee intake increase. Dissatisfaction rises within the team leaving many scarred for a long time. When the software ships, it is at a significantly poorer quality.

For most projects it doesn’t have to be this way.

How to avoid the death march of software

• Ship “dark” features. One of the popular ways to ship software that needs to be released on a certain date is to configure them to go live and deploy days ahead of time. Use a configuration approach to allow for real time testing.
• Invest In a continuous deployment model for software. This takes up front planning to get it right and some core investments in infrastructure services. The payoff is consistent, repeatable, and reliable software deployments. I often say that the “easy” button should be how deployments are done for every environment. By taking care of this process up front, you will save countless hours to be recouped for software development.
• Eliminate the release date. Where possible, a release date should be whenever the feature is finished. This may seem counterintuitive to most, but the advantage is to reshape what a release truly is. Many times, there are fictional reasons around why software has to be released on a certain date. I have found over the years that most are associated to review dates or time off for particular people.
• Cut scope. Sometimes it just can’t be fit into a release. This could be due to over aggressive estimates or unknown external pressure where priority has changed and other scope has been added. Many of my colleagues are beginning to champion the “no estimates” mantra. This is because most estimates are just that, a guess. I am not sure of the validity of saying we should have no estimates, but rather get more clarity of work.

The effects of the death march on a team

The side effects of pushing hard to meet the deadline on a team has some pretty negative results. These are:

• Poor quality - Rushing to get something out the door, is not the same as building something with quality when it is ready
• Low team morale - This is common especially when the whole team or organization doesn’t feel the pain and it is unfairly distributed to the few.
• Processes become broken - Shortcuts are taken, steps missed, and checkpoints are often overlooked.
• Team members shut down - There is nothing worse than telling a team member who is an expert that even though he/she says the work will take longer, decisions are made to say get it done anyways. Not being heard will cause even the best of the team to quit.

Fortunately for the software industry, the death march mentality is starting to diminish. Software is now being “released” upon check-in and value added to customers daily. Now is the time to invest heavily to deliver quickly and continuously.