One of extreme programming’s practices is “daily deployment”. That name sounds imposing, but don’t ask your team to start deploying daily on Monday. We’re not in it to deploy for its own sake. Like everything else in XP, deploy intentionally. There are a number of reasons to deploy your product more frequently:
Practise deployment so that it is effortless when you would normally deploy. I find teams underestimate the value of practising in general, let alone practising deployment. Still, if your deployment mechanism is complex enough that a specialist or team of specialists needs to perform it, then you have room for improvement. Anything you can do to move in the direction of one-button deployment would be good.
Deploying more frequently means paying greater attention to “done”. Many of the teams I work with suffer the same problem: they underestimate what it means to be “done”, so they find a lot of unplanned work piles up at the end of an iteration, and because iterations are shorter than they used to be, they experience the pain of delivery more often than they used to. Unfortunately, since they often don’t really deliver to a paying customer, these iterations become little more than more frequent, but arbitrary deadlines, and we all hate arbitrary deadlines. It’s important to make iterations mean something by truly delivering to a real customer.
Let your users steer your feature set. The most obvious reason to deploy frequently is to let your users give you feedback on what to build, what not to build, and how well you’ve built what you’ve built. When your users are involved in choosing features, they are more likely to be happy with the results, as you tend to build what they plan to use.
With all this, though, there is another important reason to deploy frequently: give your users a chance to say, “Wow!”
A few days ago, I logged in to Google Documents. The night before they must have deployed a new version of the service, because I found a new, nicer user interface. I actually said “Wow!” aloud when I saw it, not because it’s so great, but because I didn’t expect to see it. It was a pleasant surprise, and whenever you can pleasantly surprise your customers, that’s certainly to your advantage.
If you’re able to deploy daily, then you’re able to release your product at any time, especially early. Releasing early helps set up the opportunity for your users to say “Wow!” If Google Documents hadn’t run with the less attractive interface, then I wouldn’t have been as impressed by the nicer-looking one. To be frank, the nicer-looking interface is nothing special: it looks a lot like Outlook or any other e-mail client I’ve ever used. Still, it’s nicer than what was there before, and it’s that contrast that made the difference for me. Am I advocating releasing crap so that when you release not-crap your users will be impressed? Not at all. I am, however, advocating releasing as soon as you have an adequate product, in part so that you know which bells and whistles are worth building. If, in the process, you impress your users, then so much the better.
Now early on I wrote that switching from, say, yearly deployment to daily deployment overnight is a mistake. I’ve made it before. It frustrates the team no end to try to do something its infrastructure is simply not set up to do, so I have changed my approach here. However frequently you deploy your product now, try doubling the frequency. If you released twice last year, release four times this year. If you were releasing every month, then try every two weeks. This way you can build up the infrastructure gradually, rather than having to stop the line and face a host of difficult, frustrating problems at once. There’s no reason why we have to kill ourselves to move in the direction of deploying daily, so let’s not do that. Pick one aspect of your deployment mechanism, automate it (or make the current automation easier to use), then try deploying twice as frequently as you currently do. When that becomes more comfortable, double the frequency again. Before you know it, you’ll be able to deploy every day and your users will say “Wow!” even when you release something you feel isn’t all that impressive.
How can you lose?