In this, the second of a series of blog posts from the Value Stream Management Consortium, our experts weigh in on, “Is THIS a value stream?” This time, we’re looking at Release Management.
Helen Beal, Chair of the Value Stream Management Consortium and Co-Author of the Value Stream Management Foundation Course & Certification:
No, it’s not. Release is a step, action or process in a value stream. But we care about it a LOT in value stream management for two main reasons:
- It can be a very complex process that introduces large amounts of both delay and risk. Often when I do value stream mapping (which is a high level view of how all the steps in the stream connect), I follow it with process mapping (drilling down a level) one or two of the most ‘chunky’ steps. And the release step is frequently one of these, with often over 100 steps of its own that can take weeks to complete.
- A lot of organizations have built significant controls around the process, which is what release management is, including individuals and teams who are accountable for making sure it works by managing release calendars, creating release checklists, assigning release weekends and nights. All of this happens because organizations and systems have dependencies, which brings us back around again to risk.
Value stream management’s core goal is to optimize flow from ideation to value realization. The release process itself is not value adding (no value is actually created here for the customer, it’s all about getting the value that’s been created to the customer) so our objective is to minimize this step as much as possible. The DevOps practices we use to achieve VSM’s goal here include:
- Breaking dependencies, not managing them. Or at least, managing them while we break them - which is something that VSMPs are very good at
- Killing the CAB (Change Approval/Advisory Board) and replacing it with peer-review in our multi-functional, autonomous value stream (product, service or platform) teams
- Automating checklists in the CICD pipeline and the build and deploy activities themselves
- Dark launch techniques like canary deployments, blue/green testing
- Ultimately, we decentralize the release management role which may be subsumed into the team or disappear entirely - at minimum it transforms from gatekeeper to coach
Patrice Corbard, Founder of SD ReFocus and Influencer Member of the Value Stream Management Consortium:
No, I think Release Management is a discipline that is integrated or supports the software delivery value streams.
The term "release" can be used in different ways, which can be confusing:
- A “release” as the software product or service delivered to users;
- A “release” as a step, process or activity in our SDLC (software delivery lifecycle);
- A “release” as a phase of the DevOps infinite loop aiming to prepare the software before its deployment in production;
- A “release” as the action of making the software available to users, after it has been technically deployed to production.
In this type of situation, it is important to start by sharing a common vocabulary and adopting naming conventions to facilitate our understanding.
First, my preference is to use the term "release" or "software release" to designate the product or service as defined by the ISO/IEC 20000 standard definition:
a release is: “A collection of one or more new or changed services or service components deployed into the live environment as a result of one or more changes.”
Then, when we visualise the existing or desired flow of work on a Value Stream Map, we represent the “release” as a product and use an “action verb-noun” format to clearly identify macro activities or processes like for instance “prepare the release”, “deploy the release”, or “open the release to end users” :
The software delivery value stream is supported by activities of the release management discipline, from release planning to delivery and user feedback loops. In other words, as Helen explained, the software delivery value stream includes activities or processes, roles, artefacts, automation, ... from this release management discipline.
In complex situations where there are many dependencies (although ideally we should strive to reduce or eliminate these dependencies), release management activities may be necessary to orchestrate the delivery of a release by integrating the components or products of several “stream-aligned teams” as defined in the book “Team Topologies”.
Steve Pereira, Board Advisor and Value Stream Lead at the Value Stream Management Consortium and Co-Author of the Value Stream Management Foundation Course & Certification:
My understanding of core and supporting streams informs me here as well. If product development and delivery is a core stream, I can see release management as a supporting stream if it is structured as a supporting stream.
If your organization is fairly large and complicated, you could have hundreds of teams working on tens of core streams. I would hope that these streams are releasing fairly often and there is some standard of quality and consistency across the organization.
Let’s look at what comprises a successful release. A release requires:
- Advance notice to dependent teams, partners, customers
- Marketing
- Internal communication
- Analyst briefings
- PR post
- Slack messages
- Documentation
- Changelog update
- Change documentation
- Release notes
- Screenshots
- Video
- Testimonials
- Release verification
- User acceptance testing
- Performance analytics
- Performance testing
- Smoke testing
- Go-or-no-go
- Release planning
- Feature flagging
- Dependency analysis
- Release calendar maintenance
All of these steps are only required if the work is going to be released (something like 20% of all features are cancelled prior to release).
Across an entire product portfolio and many, many teams, I can see the value in having a release platform that supports all of the activities above. The natural operating model for this platform team is a supporting value stream - with its own release process!
Comments 0