At one point in his writeup, Chris notes that this was the “YEARS MOST IMPORTANT deliverable for many, many people”. This is a big neon warning sign. Part of the strategy of iterative delivery in Scrum is to avoid this situation. In a well-functioning scrum organization, releases are a non-event. In fact, Jeff Sutherland was recently telling Ken and I about his weekly releases at PatientKeeper, where there is little fanfare, just an automated deployment, and if the phone doesn’t ring from the customer, the release was a success.

There are plenty of reasons why iterative delivery might not have been viable in Chris’ particular situation, of course. Still, when a situation causes you to re-evaluate your approach to building software, it’s a good idea to look again at the decisions where you strayed from the ideal and ask yourself what you can do differently moving forward.

[My addition: One of the reason’s for “constant releasing” is because releasing is often hard. The only way (IMHO) to make hard things easy is to do them over and over and over again. You slowly (and iteratively) get better at them. In fact, it is a favorite technique of mine for places that can’t seem to grasp iterative development. Say something along the lines of “This is really hard and we’re not doing it well. We’re going to do it once a week (or whatever) until we have it down.” After that it’ll take care of itself… So while this may not have helped in this situation, which I know next to nothing about, stick in your pocket as a technique for when it can be applied. You’d be surprised how easy it is to get it workin’]
Source: Luke Melia