You can benefit from continuous delivery even if you can't release frequently. Maybe your customers will only accept a release once per quarter, or once per year. You may have strict regulatory or security requirements for testing. Maybe Apple will only let you release an app once every two weeks.

Developers can still reduce stress and increase focus by running a continuous delivery process inside the programming team. They can run a continuous agile process with Kanban, continuous integration, and test layering, and anything else that makes them fast and agile. They just need to make sure that the build is stable and high quality when the release team needs it.

Periodically, the release team will grab a release candidate from the development mainline and run that release candidate through a test and release process. You can select the point where you drop versions from continuous delivery into a batch release process. You can think of this as moving a dial - the CD Dial.

My friends Steve Brodie and Rohit Jainendra made this picture of a CD Dial when they were at Serena. In the diagram below, the CD Dial is set to run continuous delivery through development, test and integration. At that point the Ops people grab a release candidate and run it through staging, user acceptance testing, and production release.

Source: Serena Software, Inc.

When you run continuous agile for the development team only, you still get benefits like:

• Less stress. You remove the stress that builds up before a release.
• A faster track for the most important fixes and enhancements
• A more scalable development team
• Lower meeting and management costs
• More time for developers and product owners to think

Measure results

If you do release software that only gets installed once per year, you probably find it frustrating that you only get feedback from users long after you work on something. Often, software companies don't even know what features get used. This puts you at a big disadvantage when trying to figure out how to improve the product. I STRONGLY encourage you to program your system to log feature usage, and optionally, send you the logs.

A walk on the wild side

Spinal Tap fans will be happy to know that there is an "11" on the CD Dial. You can release changes to production servers before you merge them to your mainline, and if they work, use the changes. This may involve inconveniences for your users, but it is an efficient test.