A common objection to Agile Development is that customers don’t want frequent releases. To me, this is one of the stranger objections. It is true that very few customers want frequent releases. Nothing says that a particular customer has to take every release that you produce. In fact, they probably don’t do that no matter how frequently or infrequently you produce new releases. At AccuRev, we’ve had customers that stayed back on 2 year old and even 3 year old releases, despite the fact that bugs they had reported had been fixed and features they had asked for had been added.
Basically, the frequency of releases has nothing to do with the frequency of customer uptake of releases. The exception is when the customer has an urgent need. In that case, you had better be able to attend to that need quickly. Since that is the case anyway, again there is no connection between the frequency of regular releases and customer uptake of releases.
Customers take new releases when there is a good reason to do so. Usually, that is when the delta between where they are and the current release is big enough to warrant the disruption and they have a place in their schedule to put it. As the provider, this window is pretty much unpredictable for you. When that time comes, the customer will take your most recent release or perhaps the one before that under the assumption that more is known about the state of the older release. If you have more than one customer, the chances that your entire customer base is ready to take a release when you release it is pretty low.
One of the advantages of frequent releases is that there is a high likelihood that one of your customers will move to it fairly soon after the release, thus giving you an opportunity to gather feedback right away.
If you are just not ready to release frequently, that’s ok. Instead, use short iterations and just go on to the next iteration instead of releasing it. You can still get most of the feedback related benefits of Agile Development by having folks take a look at a demo of the new iteration and avoid the risk of disrupting your customer base.
1 comment:
I'd take that a little further and say that although you cannot predict when a customer will hit the threshold where they will take the next release, by moving to a more iterative development cycle you will push them to that threshold faster.
For example: Let's say you release once a year and average 4 new features plus bug fixes (averages out to 1 new feature per quarter). If you switch to quarterly with 1 feature per quarter at the end of the year you've spent an additional 3 quarters hardening up that first feature, 2 for the Q2 feature...
You are accelerating the delta between the releases on an annual basis.
Post a Comment