The Google Chrome team has released a blog post and a presentation that describes how their process can deliver a new version of Chrome to you every six weeks.  Maybe that is why, when I look at my logs, Chrome use has been climbing so quickly - up to 30% and gaining 2% per month. Their development process is very, very close to the "release early and often" process that I have been recommending, with at least one improvement.

The Chrome team can deliver a quality product with rapid evolution, while avoiding the stress that comes from arguing about scope ... and whether a feature needs to be in the release, and how they will stretch to squeeze it in, or change everybody's schedule .... They just release every six weeks, and people (read meddling managers) have confidence that if a feature doesn't make the release, there will be a new release soon.

Here is the basic structure:

The release goes out on time.  If a feature isn't ready, it just gets moved to the next release.

Features that are not ready can be disabled (hidden).  They have a flag for that.  After you start stabilizing a release, the only major thing that you can do is disable a feature, and you can do that by patching one little configuration.

They don't do development on "long running branches" and then do a big merge.  Everyone works most of the time on one trunk branch.

They have a long "feature freeze" period for testing, translation, and stabilization.  They make a release branch every six weeks and feature freeze it, and then the development team just keeps going. The release team spends the next six weeks stabilizing and building the production release. So, at any time, there is one development version, and one version in stabilization.

Andy's Notes

I usually ask for a feature show/hide flag if I think a feature is going to pose a problem.  I now realize that I should ask for this on everything.  That's the improvement.

Before we get to the end of a release cycle (milestone), we create a new release milestone and start moving tickets.  This allows us to focus on the stuff that will be completed with quality.

Agile planning tools try to trick you into believing that you need to finish a complete feature inside one release.  This defeats the whole idea of incremental development and causes the sort of stress that makes releases difficult.  We designed the Assembla agile planner so that you can schedule the tasks for one feature into more than one milestone, encouraging a calmer incremental approach.

I also believe that developers should work together on basically the same code, with one branch, and that maintaining and merging feature branches is often not worth the effort.  Assembla will be introducing new workflows for git that make it easier to push, test, and review code in a shared repository.

The reality of continuous development processes is that you do need freeze time to stabilize a production quality release.  This overlapping approach, where you cut a stabilization branch, is the realistic approach to delivering quality releases.

In this process there are three live versions of the software at any given time - the production release, the release that is in stabilization, and the development version.  That's easy to manage for something self-contained like a browser that just requires some local disk space.  If you build Web server software, it's not so easy to have three completely separate environments with databases etc. ( development, stabilization, and production).  It's easier on the infrastructure side to have just one dev/stabilization environment, and switch your team from development mode to stabilization mode on that environment. However, this is the age of cloud computing and on-demand infrastructure.  An investment in infrastructure to build that third environment will allow your dev team to keep going.