Release Policy: far from being a reality (Part 1)

By Laurent Duenas, March 15th 2013 

 

A concept difficult to apprehend

 

Introduction to Release Policy planning ?

Release policy is a set of rules defining the content of Release Units and the scheduling of all planning, build, and deployment (into the Live environment) operations. The content of Release Unit is based on the type and the size of the update. The frequency of the release update depends mainly on business expectations and on other constraints (as IT department organization, IT vendors’ roadmaps). It defines also naming convention, designs build and integration models, to manage releases in an industrialized way.

 

The Release Policy guarantees stability in order to limit any potential impact on the availability of Services for user and limits any unexpected workload variation for integration teams.

 

►  As the Release mode includes changes complying with a business-approved schedule, it does not risk to disrupt Service availability outside time slots

►  As they no longer work on a "on-the-fly" basis, integration teams do not depend any more on development hazards (which, by their nature, depend on business hazards), and thus, have a better control on their workload, their schedules and last but not least, their budgets

 

Illustration of a planning structured by a Release policy: Delays are managed with industrial methods and do not have impacts on the planning of the next releases, or the organization of teams:

Release policy is a deliverable which requires the mixing of several planning constraints.

The “end-to-end” vision of an IT Service implies mixing the evolution roadmaps of different components (application software, infrastructure software and sometimes equipment) on the same schedule.

In order to stay agile while preserving IT Service stability during Release (see following impacts), the reflection exercise about this unified schedule becomes very complex. Companies are actually left to themselves and field achievements are rare.


That is why many companies still prefer to enjoy comfort without any regulation or planning constraint rather than to indulge in a reflection considered as an uncertain undertaking.


A day-to-day operating mode limits IT Service availability to stabilize

In a day to day operating mode, the unavailability risk of an IT Service is strongly increased. Unavailability causes are proportional to the number of changes made (let's not forget that 80% of incidents result from changes).


The chart below lists all possible changes carried out in an uncoordinated way, i.e. outside any Release Unit or Release policy concept. It shows what could be the impacts on a vital IT Service, in a typical company, incurred by stakeholders as follows:

In general, organizations prefer to let technical stakeholders organize their own changes. Few constraints are imposed on them to have them regroup their operations following more transverse guidelines. Technical stakeholders too prefer to manage their changes separately, in order to identify more easily sources of possible incidents. Potentially every morning this operating mode opens the door to the risk of Service unavailability for the business.

 

Illustration of changes carried out on an “on the fly” basis (1 change = 1 release), without grouping them by release unit:

In short, change release planning must be considered from the stakeholder's point of view, to avoid jeopardizing their business activity (and not according to management complexity, which is only a technical point of view).

 

Changes on a day-to-day basis generate disruptions in integration teams" activity

In reality, notice periods are only a few days, at best 1 or 2 weeks. Which is already perceived as fairly binding by Design teams and as a significant control level by Release teams, but still insufficient to be optimal. Based on this period, (Release) integration teams can only act in a reactive mode:

 

►  Teams in charge of deployment must systematically get organized at the last moment, or shortly before the change cycle starts 

►  Their workload planning is systematically disrupted by other changes coming up every day from Design teams

►  Or human task forces are doubled to answer all requests through a dedicated project organization for each one of them. Costs are explicitly exponential.

 

Without any Release Policy, teams in charge of change integration into the live environment are only managed at the project’s pace. The number of hazards can be high: development delays, stakeholders’ validation delays, changes in specification requirements, etc. The integration team is directlyimpacted by delays, and as many times as it is solicited for new projects.

 

As a result, the initial planning of releases is constantly revised, affecting releases for other projects, impacting business (even external customers) for totally separate reasons.

 

The illustration below shows the disruptions caused by project postponements in integration teams:

The IT Department as a whole does not operate as an integrated organization sharing a common vision of the respective contributions of various entities to a common goal, sharing the same processes.

 

Example:

The IT department of an industrial company selling goods observed that its integration service (pre-release) was a bottleneck. Project (Design) teams frequently complained about the inability to release evolutions quickly. The department operated without any Release policy and carried out most releases “on the fly”. To solve this defect, the IT department decided to attach integration resources to Design teams, according to functional areas. So, their schedule was aligned on that of projects. Not only was the objective to bring more reactivity not reached, since the cause of disorganization was not dealt with at its source; but worse, the uniformity of releases was widely lost because of management by different project teams. Finally, the quality of the IT Service deployed deteriorated sharply and the organization centralized again around integration activities. At this stage, the root problem had remained unsolved.

 

In addition, most of the time, Design departments (or business IT directors according to organizations) are the only ones who commit themselves to providing changes (new IT Service or evolution of existing Service) to business. As a result, any constraints imposed by Release are seen as obstacles to agility. Release departments are singled out as being responsible for delays and are considered as the generators of “bureaucracy”. However, the real issue above all is the lack of coordination of all the group of stakeholders who contribute to the same result.

 

Remark:

In most IT organizations we met, only Design departments participate in project reviews for the design of new IT systems. As long as release topics are not raised, Release departments are rarely invited (except for infrastructure needs). As a consequence, Design teams alone commit themselves to deliver IT Service to Business Units. These commitments are based on a few approvals of technical architectures and on planned availabilities of integration teams. But this does not give evaluations depending on the release unit to deal with, as a release policy would.

 

3 times out of 4, when design time consumes the totality of the time devoted to projects, integration activities are seen as obstacles. The customer does not perceive the nature or the value of services added at this stage, although indispensable to the quality of the IT Service they will use in the future. This situation only generates misunderstanding and discontent.

 

 


Other articles

►  No link


External links

►  No link


Related products

►  Change & Release ...

Copyright © 2014 - PRACT Publishing