You’ll face numerous challenges when you manage by Release. I have learned over time that if you “get it right” with three key design areas, the rest will fall into place and reduce risk. In fact, instead of calling them challenges, let’s call them success factors.

First success factor: Clearly define an acceptable “business as usual” or BAU change, compared to a “Release change”. Defining those two categories is crucial.

If you leave gray areas, users will push requested changes (“we need a new line in the user form ASAP!”) into the BAU list for quick action. The BAU list will quickly bloat while the Release list shrinks and you’ll find you’ve undermined your own Release strategy.

For a discussion of similar multi-lane challenges, see our eBook Build Your Own ‘Super Highway’ to Manage Continuous Delivery of SAP Changes. One point it makes is that, without effective controls on multi-lane strategies, the emergency lane chokes up because everyone’s changes seem urgent to them. A method to decide and a way to enforce the decision are crucial.

Second success factor: Get the process right. A solid process with formalized steps to plan, schedule, control and approve Releases ensures they will be in tune with business requirements. Enforcing the process prevents changes being inserted or taken out of a Release after its deadline. Maybe you organize Releases around an application, or a date, or some other criterion. To accelerate delivery, use your process to limit the number of components, so your testing doesn’t have to go so broad and deep. Your changes will move into Production faster.

Third and final success factor: Manage your parallel changes closely. That relates to both change definition and process. Simultaneous changes within BAU and the Release can result in overwriting BAU change when the Release moves into Production. Such errors can be very difficult to track down and can reflect badly on the quality of the Release or even the strategy itself. Good process control and enforcement can prevent such problems.

Once you set up and debug decision criteria, establish process enforcement, and control parallel changes, you’ll face many other decisions – but you’ll have a solid basis for them. For example, should you deploy an N+1 development landscape? You can settle these sorts of issues by answering key questions such as:

  • How many changes will each Release contain (size of Release)?
  • What types of change will be included per Release (impact of Release)?
  • How often Releases are to be applied to Production (Release frequency)?
  • How much and what types of change will make up the steady volume of BAU change?

This chart may help you decide on delivery methods.

Considerations DEV – QAS – PRD (N) DV1 – QA1 (N+1)
Size of Releases Low – Medium Medium – High
Impact of Releases Low – Medium Medium – High
Frequency of Releases Quarterly – Bi Annual Fortnightly – Quarterly
Steady state BAU volume Low – Medium Medium – High

As one example, if you put small-to-medium changes into your BAU stream and save the quarterly Release for major enhancements, you might forego N+1 development processes and manage Releases through your standard process instead. Which approach works best for you is your decision. Just make sure the three “must get right” success factors will support your decision.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply