Peripatetic thinking
Last week at the Agile Vancouver conference, my colleague Jeremy Goldstrom presented on the process that we use at our company to deploy new releases to production every week. Aside from being a good distillation of our team process, the session led to some interesting follow on discussion with others that were doing something similar.
Helping organizations compress their release cycles has been a passion of mine for a while and is something that I helped a number of teams achieve in my consulting work with ThoughtWorks. I had worked on trying to set up a service offering called Rapid Response devoted to helping enterprise clients build the capacity for monthly releases, but unfortunately it seemed to gain limited traction with the TW sales staff.
As a SaS company with a rapidly evolving product offering, my current company is an ideal place for applying these ideas. I’ve resolved to try and capture the learnings that I’ve gained through our weekly release process on this blog; if anything it will encourage me to blog a bit more frequently. So stay tuned.
80% technical, 20% social change. This blog is dedicated to finding ways to sustainably release software more frequently.
Anand Vishwanath
December 11th, 2008 at 4:18 am
IMHO what is a “frequent release” is subjective to the project itself. For example a green field project starting from scratch with 4 pairs of developers can do a release every month, but it might not be the same case with a huge legacy architecture system communicating with 15 third parties each being released by another vendor frequently. In the latter case, sometimes the cost of doing the release itself outweighs the cost of building business value.
But yes the idea should be to push for the release cycles to be as frequent as possible.
exortech
December 17th, 2008 at 8:13 am
Anand: thanks for your comment. While I agree that what constitutes a ‘frequent release’ varies from project to project, the majority of organizations in my experience have the potential to release software much more frequently than they realize they can. Often the business value of more frequent releases (greater customer responsiveness, continuous incremental improvements, lowered risk and improving the overall efficiency of the IT organization) is not recognized. I’ve found that for most enterprises, developing the capacity to release software on a monthly cycle is achievable and beneficial.
My current focus, however, is to see how far can we sustainably compress our release cycles. Rather than pushing enterprises to release once per month, I’m starting at the other end of the spectrum. For my company, at least, releasing once per week is a good challenge. But I’ve been reading about other startups that are releasing software several times per day. What processes and culture need to be in place to support this? That is something that I think is worth exploring.