Breaking Release Cycles

There exist today endless software methodologies, each of which, allow for differing policies on producing releases. Some methodologies allow for variable length between releases while some dictate a strict cycle length. The methodologies that follow a strict release time-line are most likely using an agile approach to software development. When using this approach, the release dates for the software are one of the, if not the most, important rules to stick to.

When using an agile approach to software development, there should be a fixed amount of time between releases. This may at first seem counter intuitive. How can a development methodology be agile if the time-line is of fixed length? Agile should support change and that is indeed one of the key benefits to using an agile approach. However, not everything can change. There has to be at least some formal rules that allow for some sort of organization. If there is nothing strict in place, the practice is flawed because nothing would ever get released. And it is the continuous releasing of software that provides the invaluable feedback that plays a huge role in the agile methodology. Take a look at some open source projects that have a six month release cycle. Sure, there is feedback from the user community, but they don't see how their feedback is reflected, which, in turn, generates more feedback and so on.

With a shorter release cycle, this feedback is reflected sooner. But what about when the agile approach is used for developing a solution for a paying customer. Does their request for some change or some feature mean that the release cycle length should be changed? In almost every case, I would say no it doesn't. They are paying you to develop software because you know how to do it and constantly pushing back release dates does not help anyone. The only exception to this rule is when it is a deal breaker. If holding up the release will prevent the loss of money, you simply do not have a choice. Otherwise, there is always a good reason one can give for not including a requested feature. This is especially easy to explain to customers when you always ship predictably and on time.