Skip to end of metadata
Go to start of metadata

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.

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 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 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.

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

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.

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Sep 21, 2009

    In this case: What is frequent, this might vary from 50 times a day to production to once a year for tax income system (the latter I would say is not frequent any more).

    The deployment cost might be prohibitive. For example involves hardware changes, manual labor, significant effort, costly regulatory testing, costly recustomization or reintegration + associated testing, downtime, training for support or users, other disruption of business, any of these in significant (for the customer) amounts).The same might apply for creator organisation + additionally is the cost of delivery significant compared to other competing uses of delivery teams. Can the new system support the old use cases and databases all the time (tax and healthcare systems). Is the additional maintenance cost acceptable (many potential releases out in the customers).

    If the benefit of incremental release is bigger than the cost of deployment then sometimes doable.

    "- is the organisation interested in agile" -> should be: does the organisation need frequent releases for business purposes

  2. Sep 21, 2009

    Yes, there are many factors that can inhibit an organizations ability to release often. Most of these can be mitigated to some extent. I also contend that many projects arrive at an unnecessarily long release cycle without realizing the magnitude of the risk they are taking.

    1. Sep 21, 2009

      Yes, there are many factors that can inhibit an organizations ability to release often

      This is IMHO the most prohibiting thought which block the "release often" strategy. It is very easy to come up with problems, and before you have solved problem number one, new problems arises. The right mindset should be that there are NO real factors which inhibits release often other then psychology and lack of knowledge...

  3. Oct 14, 2009

    Pretty much agree that most teams benefit from releasing often. Even if you cannot release externally you should release internally to get the feedback. There is a cost of migration (data, configurations etc) in addition for each of the releases.

    It might be useful to try to look at mitigations for some of these things... But perhaps it is not in scope of this book. All of these come from my observations what stakeholders have said prevent frequent releases. Some of these are only relevant for large projects. Pollyanna Pixton has a nice categorisation of project types in her new book "Stand back and deliver" that may help here...

    I like the concept of MRP and that can be often very tiny, little piece of the stuff, for example every week, timothy fitz has this up to 50 times a day... The bigger your release is and the longer it takes the bigger are your chances of failure due to providing irrelevant functionality as you have been out of touch with reality...