Implementing a process for smaller releases

Discuss and debate ITIL Change Management issues
Post Reply
User avatar
Posts: 8
Joined: Thu Apr 23, 2009 8:00 pm

Mon Oct 11, 2010 4:41 am


Im currently working as a release manager for a National company currently enjoying a huge rate of expansion. As a result, our customers are requesting smaller, more frequent deliveries of functionality as we move towards an agile approach.

Currently, all releases, no matter what the content, go throuhg the full process, and are subject to the same amount of testing etc.

What we need to do is identify a suitable scope for these smaller releases and what constitutes one...

Has anybody here implemneted similar, and if so, what criteria did you use to define a release that may be suitable for a "condensed" release process?

User avatar
ITIL Expert
ITIL Expert
Posts: 3639
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Mon Oct 11, 2010 5:41 am


No no no no no and thousands times no

The same release process should be used for all releases whether big or small

All releases should be developed, tested and then deployed to the production environment

Also, just because a release is small does not mean the impact is small
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
User avatar
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Mon Oct 11, 2010 6:18 am


I'm inclined to agree with John that the release process should not be compromised.

Where gains can be made, I believe, is in mapping the impact scope of these small releases and confining testing to this scope. This is not as simple as it sounds, because it is normally very hard to ring-fence impact. But if you do a thorough mapping you may have a clearer measure of risk. If you identify, and agree, an acceptable level of business risk, you can simplify testing to this level.

But is that not what "agile" is all about anyway - a better integration of testing into development?
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
User avatar
Posts: 9
Joined: Wed May 21, 2014 8:00 pm

Fri May 23, 2014 3:00 am

This makes sense and this is how the strategies should be made,Scrum methods are accepted all over and people like discussing them i mean the way they can take all to another level for that Agile has its own level.
Post Reply