What is lean release management?
“Lean release management” is an oxymoron. It refers to a set of activities that either should not be performed when managing work in a lean way, or are part of other processes. In a lean context, release management as an independent process should not exist.1
I would be begging the question were I to stop the discussion here. So, I will continue by discussing three topics:
- Deployment management as a process distinct from release management
- The types of waste in “traditional” release management
- Where the truly lean activities of those traditionally attributed to release management might be performed, assuming an organization had no release management discipline, as such
I will conclude with a discussion of the product owner’s responsibilities for releases.
Release management vs. deployment management
The idea that release management and deployment management are separate has already been broached many times. It suffices to recall the reasons for keeping them separate (especially in a lean context) and the reasons why anyone ever mixed them up.
When software (or any other type of release unit) is developed in-house for internal use, the development, release and deployment of a given product version is traditionally treated as phases within a single project. I understand the word “project” to refer to a temporary organization created to deliver a fixed set of deliverables. Since such organizations have a long history of very poor performance, especially in IT, elaborate control processes and superstructures have been devised in an attempt to limit the damage they cause.
But, the process by which a system is designed, built and tested is not the same thing as a project. The distinction is not pedantic. It is perfectly feasible, indeed desirable, to create new service system components and component versions without a project organization. Which leads us to a second, increasingly common use of the term “project”. Often, a project is simply a logical container used to circumscribe the scope of work. In this use, the term implies nothing about the organization performing the work, nor does it imply any particular processes or control methods.
Thus, people often confuse a project plan or a project control methodology with one or more processes. As a result, when people think of releasing and deploying as two sides of the same coin, they are merely reflecting the habits of many years of “project” work, rather than any necessary reality. They feel that releasing and deploying belong together because they are typically contiguous parts of one and the same project plan.
The distinction between the two becomes much clearer in the case of a design and development company creating, often on speculation, a product version for use by third parties. The deployment of that product version is performed under the responsibility of an entirely separate organization, using quite different control criteria and with no necessary linkage in time. Company A releases version 1.1.4 of a product. Company X deploys it the same day; company Y waits several weeks before deploying it; and company Z decides not to deploy it at all, preferring to stay with its current version 1.1.3 of the product. In theory, company A could release a version of its product that no one deploys.
In certain organizations, especially for their web applications, application functions or code is deployed before it is released. Functions have configuration switches that enable or disable them. Thus, these functions can be enabled or disabled, either selectively for individual sessions, generally or in any other manner. The decision to release functionality becomes very flexible and it is very easy to roll back from that decision. This method is called by some “dark releasing”.
For these reasons, I prefer to treat release management separately from deployment management. Lean deployment management most certainly can and does exist. It is not an oxymoron. It can consist of a value stream of value-adding activities. But that activity is outside the scope of the following remarks. Suffice it to say that many organizations have jobs or roles entitled “release manager” where the essence of their work is in performing deployments, not in managing releases. So, in what follows, deployment is out of scope.
In “traditional” release management, what are the forms of waste that should be eliminated and what are the release-related activities that should be performed in the context of a discipline other than release management?
“Ensuring”-type activities in release management
Many of the activities attributed to release management, especially in the ITIL® framework, are described as “ensuring” that some task is performed or some outcome is achieved.2 Rather than analyze in painstaking detail all such activities, I will describe in general terms why these activities should not be performed when using a lean management approach. They are a form of waste.
In a lean approach, all activities should be value-adding from the perspective of the recipient of the output of the activity (i.e., the customer of the activity). Thus, any activity that only serves to ensure that someone else correctly performs a task should not be performed when using a lean approach. A lean approach will not perpetuate bad practices by integrating “ensuring” activities into processes or by hiring managers to “ensure” the correctness of work. Instead, it insists on analyzing the causes of those wasteful practices and improving them.
In the following table, I list those “ensure” activities, together with remarks on who should execute and improve the underlying activities in a lean context.
| Activity | Possible lean execution |
| Ensure release package integrity | Whatever does this mean as an activity? Mounting a guard around the release components? Checking them periodically to ensure that they haven’t been changed unduly? Whatever it might mean, diligence is de rigueur in the handling of the release package and its components, no matter who might perform that work. If system components have owners, then their owners should ensure their integrity. |
| Ensure that release packages are stored in a DML3 | Ideally, to be done by the creator of the release package, or perhaps done in a largely automated way. In a somewhat less lean context, that creator might hand off the package to the owner of the DML, who then physically stores it. |
| Ensure that release packages are recorded in the CMS | My critique of this activity is exactly parallel to the discussion of storage in a DML. |
| Ensure that organizational and stakeholder change is managed | Stakeholders, together with the impact of changes that a release should have, are identified very earlier in the process of deciding what should be changed. But it might be possible that certain changes in a release are identified and realized without any reference to or input from the stakeholders to be impacted. In both cases, the product owner is responsible for communicating to the product’s stakeholders what the changes are, why they will be introduced and what benefits they might bring.4 |
| Ensure knowledge transfer | Knowledge transfer requires a transferer and a transferee, that is, a person having the knowledge to be transferred and a person to whom it needs be transferred for subsequent use. Neither of those two roles are release management roles. As a footnote, one must ask whether there is even a role for a knowledge “manager” in a lean context? |
Other putative activities of release management
I continue with the same exercise regarding the other activities that have been attributed to release management
| Activity | Possible lean execution |
| Deciding that a given product version is deployable | This is the responsibility of the owner of the product. In a largely manual design value stream, that owner may require exit criteria for the version’s developers and entry criteria for the testers or deployers. In a highly automated approach, the decision criteria may be implemented in the software controlling the development cycle. But to the extent that a go/no-go decision is required, this belongs to the product owner. A service owner is a type of product owner (see below). Thus, unlike the recommendation of ITIL®, I view the service owner as responsible for the decision and not merely a stakeholder in the decision. |
| Plan | Planning of a release may appear to be needed if it is assumed, as per certain frameworks, that release management is a set of activities so disparate that they need tying together. However, I am arguing here that all these putative release activities are, in reality, either not needed at all or are part of other disciplines. The need for planning qua “release planning” thus disappears. If some planning is still needed, that planning is handled by the respective design, develop and test activities. |
| Create release packages | Creating a release package is understood in ITIL as the decision regarding which release units comprise the package, how they depend on each other and what compromises might be necessary in finalizing the components of a given release. In a waterfall approach to product management, such decisions are made by a product architect early in the design phase and are approved by the product owner. In a discipline such as scrum, the contents of the release package might be planned, but the reality is determined pragmatically, based on what can be achieved during sprints and whether the results are viable. In waterfall approaches, the product manager may be called upon to validate changes to release scope following project execution failure or the identification of defects during testing. |
| Test release packages | This activity belongs to the testing discipline. |
| Record and manage deviations, risks and issues related to the new or changed service and take necessary corrective action | This is precisely the responsibility of the product or service owner (see below). If the components or services being changed by the release have an owner, then that owner should perform these tasks. |
| Build and test release | Testing is split among the various stakeholders in the release, be they the owners, developers, users, operators or supporters. Assigning an additional testing responsibility to release management is redundant and an egregious form of waste. Building a release is a highly technical task that can only be performed by technical specialists. Whether it refers, as in the old sense, to compiling and linking source code, or in the more modern sense of creating installation packages, developers or packagers handle these tasks as part of the development cycle. The ultimate responsibility for deciding what to build is with the product owner. |
| Review and close | To the extent that any activities require post mortems, identifying lessons learned and future improvements, these should be performed by each team participating in the release design, creation, testing and deployment. Closing, to the extent that this is a real activity, would be done by the product owner. |
The product owner and releases
I have referred several times to the role of the product owner and its responsibilities for releasing. If I portray the release manager as a redundant role in a lean context, it is largely because I would give the planning, coordinating and decision-making responsibilities to the product owner. For those raised on ITSM “best practice” frameworks, a few additional word about product ownership are apposite.
The notion of “products” in ITSM has led to considerable confusion. The role of the product manager made a brief appearance in ITIL 3 Service Strategy: “[Business Relationship Managers] work closely with Product Managers who take responsibility for developing and managing services across the lifecycle” (§4.1.3, p. 67 – my emphasis). Product managers disappeared, for reasons that remain unstated, from the 2011 version of Service Strategy. I have chosen to speak of product owners, which would be identical to the product manager role as defined in ITIL 3, so as to align this analysis with lean approaches to service management, product development and the software life cycle. A service is merely a product offered by a service provider. In this sense, services are like the tangible, physical goods that are also offered up as products. It is in this sense that I referred above to the service owner as being a type of product owner.
What does it mean for a product owner (that is, a service owner) to take responsibility for developing and managing a service when it comes to releasing? It means that the product owner:
- determines the strategy for developing the product
- decides what should be in a release, in line with that strategy
- accepts what will be in a release
- reserves the right to approve a release candidate for deployment
- reserves the right to cancel a release
Some ITSM diehards might proclaim that such a product owner plays the role of the release manager (at least for certain activities). I won’t try to convince such people otherwise. But for those interested in simplification, in paring down work to the essential, which is what the lean approach is trying to achieve, the release manager and release management as an independent process is a redundancy, a form of waste to be eliminated.
What about organizations where the product owner role does not exist? Such organizations, lacking a responsibility for defining and evolving the long-term strategies of its offerings and guiding those offerings to reflect those strategies, will have issues far more severe than the management of releases. They should first ensure that the product portfolio is understood and under control.
The article Lean Release Management by Robert S. Falkowitz, including all its contents, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
1Disclaimer: By making such a categorical statement, I do not want to give the impression that I am defining a normative statement of what lean release management must be. To paraphrase Shigeo Shingo, lean is a state of mind rather than a checklist. When I use the word “should” in this article, I am expressing an opinion justified by experience. That does not mean that my opinion is the only “right” way to manage releases in a lean way.
2I am not picking on ITIL. CobiT is in similar. Interestingly, the objective of release management according to ISO 20000—”To deliver, distribute and track one or more changes in a release into the live environment”—is essentially concerned with deployment management, albeit Part 2 adds complementary information that aligns the standard with ITIL. Thus, the two parts are not entirely coherent. On the other hand, IT4IT puts release and deployment activities within the Request to Fulfill value stream. That being said, it still recognizes “release manager” as a distinct role.
3For those not familiar with the term, a DML is a “definitive media library”. This is a mechanism intended to provide a highly controlled environment, under the responsibility of a configuration manager, wherein copies of all authorized software components and related items are held.
4I would say that this activity is a responsibility of change management, but change control is just as problematic as release management in a lean context.
Hi Robert,
Thanks, very interesting article about lean release management !
What I do not see yet is the way the product owners interact when we speak of multiple releases that have integration aspects that need to be taken care of, for example we develop changes in more than one application that have integrated processes or data elements where we need to make sure the integration is considered and verified during development and testing,… is this implicitly taken care of in the develop and test stage of the Product owner(s) or is this managed in a different way ?
Thanks !
Marijn
That’s a very good issue that you raise, Marijn. I have two thoughts about it. First, these sorts of dependencies are not always necessary. For precisely the issue you are raising, the architects/designers of the systems should probably think about mitigating such dependencies using APIs or master data management techniques, etc. But that still leaves the cases where such dependencies are either unavoidable or simply exist and have to be handled. In the latter case, I would agree with your suggestion that this issue be handled at the design stage. One product owner says, “I want to make this change to my product.” Some form of configuration management tool needs to be consulted to see what dependencies exist. Then, the relevant product owners need to agree on the change to be made. If you leave such issues to the last minute, where it would be a release manager’s responsibility to detect and handle such dependencies, I think you will inevitably have delays, unexpected results, perhaps incidents and so forth.
This is quite an informative article on Lean Release Management. This will be very useful for many people in the ITSM and ITIL field. Thank you for explaining this step by step and also comparing it to other management methods.