Frequent Releases
This topic has created more controversy than I anticipated, which is great because it also means I’ve gotten lots of great feedback on it. Most of the feedback has pointed out holes in my earlier posts, so I've tried to make this post as comprehensive as possible without writing a whole book! There's not much discussion on the benefits of releasing frequently, that has been adequately covered in earlier posts (or at least there wasn't much pushback on it!)
Size of Customer Base
An important consideration when considering frequent releases is how many customers you have. If you have a single customer, for instance an in-house customer, the application of the practice of frequent releases is a bit different. I’ll assume that you have multiple customers for the moment and then come back and address the case of a single customer near the end.
Overhead Associated with Producing and Consuming a Release
Another factor to consider with frequent releases is the overhead associated with producing a release, and what is the overhead associated with consuming (upgrading to) a release. The release overhead will influence how frequently you can produce releases and the upgrade overhead will influence how frequently any given customer can upgrade to a particular release. To get the most out of frequent releases, you must work hard to reduce the overhead in both cases.
Supported Versions
When you are releasing infrequently, the number of releases that you have to support in the field is probably pretty low: one or two major releases plus the patch train for each of those major releases. For the sake of argument, let’s say it is two releases in a one year cycle. Supporting two releases seems pretty straightforward and the overhead associated with that is entirely manageable.
If you increase your frequency to once per month, doesn’t that mean you’ve moved from two releases to twelve releases? Supporting twelve releases compared to two does seem pretty unrealistic! But let’s take a closer look at this situation. The patch release is unlikely to be a single release. It is more likely that there is a patch release every 1-2 months at the very least. And what is the policy on that patch train? If you have a problem with a previous patch, upgrade to the latest patch. The majority of the companies that I’ve talked to (which is in the hundreds, across a wide variety of industries) are already doing frequent releases, it is just on the patch side rather than on the major release side.
So the question is, how does breaking up the release of the major release into multiple releases fit into this equation? There are at least four ways of doing this as described below. The method you use depends on your exact circumstances. As a provider, you should carefully consider the needs of your customer and give the customer as much control over the decision of upgrading as possible.
Release Option 1: Forced Upgrades
This option is primarily a Software as a Service (SaaS) release method, for instance Gmail, Mapquest, Salesforce.com, and RallyDev . In this case the application is hosted by the provider and when they upgrade the application, all users are affected. To use this option your software must be incredibly easy to use and you must be able to find and fix problems almost instantaneously.
Release Option 2: Automatic Updates
Automatic updates are more of a “push” than a “pull.” The customer didn’t ask for the next release, it was either done automatically or offered as a choice. Usually this is configurable, or there is a prompt until you eventually give in and install the update. In some cases, such as virus definitions, it makes sense to take the automatic updates. In other cases, taking an update is disruptive and the customer would prefer to wait until they really need to do it.
Release Option 3: Always Upgrade to the Latest Release
In this option, there is only one release train. If you have a problem with the release you are on, the only way to get it addressed is to upgrade to the latest release. To use this option, you’ve really got to have your act together: upgrading has to be painless and re-training either non-existent or minimal. It is also good if there are very few problems and customers rarely need to upgrade to address problems.
Release Option 4: Dual Release Trains
The first three options are very similar, most of their differences are logistical. The Dual Release Train option is closer to a traditional model, but still allows for frequent releases. In this model you have the “conservative” train and the “frequent release” train. Each train has a separate policy. The policy of the conservative train is that releases come out infrequently and do get patches when needed. The policy of the frequent release train is the same as option 3 above: always upgrade to the latest release. There is one significant difference with this option as compared with the traditional release pattern. All releases except the patches come from the same source: the frequent release train. Thus, the size of all releases are small. For example, instead of having release A in a six month period, you have A, B, C, D, E, and F. The frequent release train consists of all six releases. The conservative train consists of A with a patch or two and then moves to F. Customers can opt to jump from train to train, realizing that they have different policies.
This option is not the same as the stable/unstable model where the unstable "early release" is not yet fully tested. All of the releases are stable. The frequent releases are not like traditional patches, they are like traditional major releases, except their contents is smaller. They are all well tested, stable, and of high quality. If an organization can't do this, then it should not change its frequency of releases until it can. Agile is not an excuse for poor quality, it is a way to produce significantly higher quality.
Customer Burnout From High Frequency of Releases
Unless you force your customers to upgrade, which I don’t recommend, then customers will take your releases according to their own schedule, no matter how frequently you release. So, there’s no more chance of burnout if you release frequently than if you don’t. When you have multiple customers, there is a good likelihood that at least one of them will upgrade to your latest release, so you will get feedback on those releases, it may just be different sets of customers each time.
Frequent Releases for a Single Customer
When you have a single customer, getting uptake of your frequent releases is much harder since there is only one customer to take those releases. However, there is still opportunity here because even with a single customer there is more opportunity for them to take your release when you are releasing more frequently. Consider an example. Your customer has 3 windows during the year during which they can do an upgrade. You produce a major release on the average of every 6 months. That means that while they could have taken 3 releases from you, you can only take advantage of two upgrade windows. Worse, if you miss a window, then they may not take that release in the next window because now the next release has something they really want and they would prefer to wait for that release. So, you may end up only being able to take advantage of a single release window that year. But if you had monthly releases, then it is much more likely that you will be able to take advantage of your customer’s upgrade windows.
Moving to Frequent Releases Takes Time
I’m not advocating releasing frequently no matter what, I’m advocating releasing as frequently as you can with no drop in quality. For some that might mean once every two years, and for others it might mean once per week. The frequency depends on your exact circumstances. The important point is: if you could release more frequently, but you don’t, ask yourself why not. Releasing frequently is a goal, and on the way to that goal you’ll find impediments which must be dealt with in order to reach that goal. Simply moving to frequent releases before you are ready is a recipe for disaster. A good first step might be simply changing the release cycle from a year to nine months.
Next: Preparing for the Transition to Agile
No comments:
Post a Comment