Implementing a process for smaller releases

[Kip]

Hi

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?

[UKVIKING]

Kip

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

[Diarmid]

Kip,

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