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.
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:
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:
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:
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”.
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:
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!