SDLC types and release management

Release Management can work with any type of SDLC as long as different software development methodologies and project management methodologies stay within the boundaries of a certain project and let release management bundle the different projects into a release. Yes, different ways of delivering different projects can live together in a release as long as the rules of a release dominate and overwrite conflicting management parts.

Here are some principles:

In details:

1. Size does matter (in case of release management)

Size does matter when considering release management in the light of development lifecycles. The bigger the organisation the more dominance release management has over individual project management methodologies. For instance: at a big corporation with quarterly IT releases it is normal to have some agile projects and waterfall project together with certain kanban items in the same release with obeying the simple waterfall principles of a release by exiting design-stage more or less at the same time, extiting development-stage at the same time and starting SIT-stage (System Integration Testing) precisely at the same time.

2. The individual release is always a waterfall process

There is this new tendency to look at release management and release cycles in particular as an iterative agile-like phenomenon. And in a way release management deals with backlog items and limits the amount of projects that can be scoped into a single release. So release management in a business-year perspective resembles and agile approach. But any specific release is as waterfall as it can be from its start to its finish. And the less waterfall a release is treated the less effective it becomes. Please have a look at a release cycle with its stages and consider that the main reason of a release based delivery is the cost savings of ordering, testing and deploying different type of projects at the same time.

3. Agile supports effective Release Management

Not talking about the flexibility of a project scope in agile but talking about the flexibility of agile SDLC reacting to release management principles. We know that if we have a scrum team that delivers projects/product versions then by principle they can dance around the scope of the project but they normally never change their delivery dates. Set delivery dates are great for release management but it sometimes happens that during testing integration with other components of other projects or infrastructure/environment issues/defects can occur and agile teams can have scalability issues with bugfixing (debugging) due to their tight iteration agenda. So it could easily happen that project delivered by an agile team cannot pass testing by its release due date and needs to be descoped from the release. In such cases agile projects are the less problematic to be scoped into the next release with all the necessary re-design due to code-base changes of the Production environment or other variables. So in general waterfall projects are great in a release as long as they are OK, but agile projects are much more flexible in case of rescoping a release.

4. Any or all SDLC types can be used in projects of a release

Lets see the usual suspects of SDLC with my personal comments based on experience:

...back to knowledge base main page