Arguments against releasing often

The organization does not want frequent releases

• Bad experiences
  Users are often wary of frequent releases because they are used to getting poor quality in the first release. The solution is use modern software development techniques to ensure that releases are of high quality.

• 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 waterfall terms. 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.

• 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 some degree.

Frequent releases cost

• Technical impediments

• much higher cost in not doing it "if something is hard, do it often"

• identify cost sources and eliminate

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.

The team delivers too poor quality

• frequent releases expose quality problems