View Source

You are probably thinking that your problem is uniquely difficult to release incrementally. Most people think their project is unique in this way. But the fact is that coming up with reasons why releasing often is hard is very easy. Fortunately, the factors that make releasing often difficult can be alleviated.

h2.The organization does not want more frequent releases

It is not uncommon for organizations to oppose getting more frequent releases than they currently have. The only way to influence this attitude is to look at the underlying causes of this opposition. In most cases it should be possible to address the underlying problems and find a way for the organization to realize more frequent releases. Here are some common causes of organizational resistance to more frequent releases:

* *Bad experiences*
Users are often wary of releases because they are used to getting poor quality in almost every major release. The solution is use modern software development techniques to ensure that releases are of high quality. Once the project has [built trust|build trust] by demonstrating that releases have a reasonable level of quality it will be much easier to gain acceptance for more frequent releases.

* *Customer in waterfall mode*
Interest in agile practices is much more widespread amongst software developers than in customer organizations. Many agile projects have to cope with a situation where the customer is still thinking in terms of a waterfall process. The customer delivers a specification at the beginning of the project and is not interested in allocating resources to it or [accepting costs|Accept transition costs] for any [MRP] strategy. At the end of the project the customer plans for a single "big bang" release. As long as the customer side of a project does not understand the value of an agile approach it will be difficult to gain acceptance for frequent releases. Use of the [Build trust] principle can help here.

* *Regulatory impediments*
In many areas there are regulatory hurdles that add to the costs of every release. These impediments can not be ignored but it is often possible to mitigate their effects to a large degree.

* *Technical impediments*
Many projects argue that in their particular environment the complexities of getting a release deployed preclude having frequent releases. Experience from projects that have aggressively worked on [Reducing release costs] is that many of these costs can be eliminated or dramatically reduced. "If something is hard, do it often" An example of this is Flickr. They have implemented support for feature switches. A new feature can be deployed without being activated. That way they can first incrementally deploy the feature to all the servers and then activate the feature once it is completely deployed. This is essential since some features would break if only some of the servers had been upgraded before the feature was activated. Read more about this on their [blog|].

* *Reluctance to invest in a dying system*
Many projects are intended to replace an existing system. When you release often that means that the new system and the old system will have to coexist. To support this coexistence, the old system will often need to be adjusted. This appears to extend the lifespan and investment in the old, dying system. At some point in time, even the most optimistic projects will realize that the new and the old have to coexist for some time. The sooner your project realizes this, the sooner you can overcome this hurdle.

h2._Lazy developers_ that are _"too agile to architect"_
It is quite common to meet agile development teams that argue against putting enough effort into the architecture in the early stages to support release often strategies. Their arguments are usually based upon lack of skills/knowledge but take the form of calling the up-front work unnecessary waste. A common architectural guideline for agile teams is to ensure that the architectural effort is net-positive within 3 sprints and make sure that it is measured.

h2.The team delivers too poor quality
If the development team does not have experience with a core technology and the learning curve is long (think Cobol programmers learning to develop web applications) it will be hard to get releases of sufficient quality. One strategy that can be used is the [Learning curve] technique. Instead of trying to solve the most complex issues in the new system first the team works on easier tasks.