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:
The bigger the organisation the more dominance release management has over individual project management methodologies.
Release based delivery can be viewed and called CI/CD or DevOps (or anything else) but the individual release itself is always a waterfall process.
Agile supports the highest possible release frequency hence Agile SDLC helps the efficacy of release management.
All possible SDLC methods could deliver to a release though not with the same amount of effort.
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:
Lean - unfortunately it is hard to find well structured Lean IT projects
Agile - great match with release based delivery do to its flexibility in release scope management.
Waterfall - as long as waterfall projects are delivered in a disciplined manner these type of projects are the best for any release cycle.
DevOps - the more DevOps the easier to end PIP (Post Implementation Period) and transfer over the code to Operations
Spiral - no comment (so far)
Iterative - hard to keep GOLIVE dates with misunderstood Iterative SDLC (and it often happens)
V-shape - Great ease from test planning and test process point of view for release management.