This chapter introduces us to the last part of the book, as well as to the third pillar of the DevOps 360° operating model: rollout, accelerate, and scale. The chapter will start with an outline of the enterprise portfolio planning and adoption value proposition, which is indeed rich and multidimensional. We will continue by highlighting the importance of balancing your enterprise portfolio planning and adoption between what we will call tactical and organic approaches. Afterward, we will deep-dive into the tactical approach, and we will discuss its value proposition and its four main aspects. Starting by outlining the predominant tactical strategic domains for incumbents, we will complement those domains with important considerations. We will enrich these considerations with a list of differentiations you can use to ensure that the tactical adoption candidates cover your wide organizational DevOps context. Concluding the tactical adoption, we will provide an all-hands-on-deck example.
In the second part of the chapter, we will focus on the practicalities of the enterprise portfolio planning and adoption, starting by outlining the core elements of the proposed mechanism, which we will also visualize. Emphasis will be put on distinguishing between the DevOps 360° enablement and adoption objectives and key results (OKRs) via two examples. We will continue by providing considerations derived from real lessons learned by adopting such mechanisms at scale. The chapter will close by introducing the DevOps minimum viable adoption concept, outlining its decisive importance and linkage to the DevOps equilibrium principles.
In this chapter, we’re going to cover the following main topics:
So far in this book, we have repeatedly mentioned that the DevOps 360° evolution needs to be performed at relevance in a multi-speed context. In this chapter, we will enrich this principle by adding an element of DevOps collective intentionality. We will include this element through the phrase of enterprise alignment and consensus, which we first introduced in Chapter 6, DevOps Software Development Life Cycle 360° Evolution and Engineering. By alignment, we mean the creation of the enterprise mechanism of planning the adoption, while by consensus, we mean certain agreements that need to be made and support the planning and adoption mechanism. Our evolution’s guiding principle will consequently be reshaped to:
A DevOps 360° evolution at relevance in a multi-speed context, characterized by enterprise alignment and consensus.
I think our guiding principle looks more complete now, and you should not expect further changes to it till the end of the book.
Small parenthesis
I also like the term synchronization when referring to the enterprise level, but it is not a very realistic concept. With variations in your DevOps maturity, models, business context, technological capabilities, and speed, it is likely that you will never achieve synchronization on an enterprise level, although it will be possible to extend an ecosystem, value stream, or tribe level through the adoption of fundamental capabilities, as we will see later in the chapter.
At this point, you might wonder, “Haven’t we been evolving DevOps in alignment already?” We have the vision and design authorities with representatives across the organization holding the DevOps enterprise OKRs, the DevOps CoE planning engagements across the organization, and the Agile DevOps teams and utility area representatives defining the DevOps SDLC and journeys. We evolve DevOps in alignment already, but with two caveats. So far in the book, we have engaged with only a subset of the organization’s broader DevOps 360° stakeholders. We have also mainly focused on the why and what of the evolution, but not the how, when, and whom. As in, we have defined enterprise DevOps OKRs and created governance bodies and workstreams in designing the approaches toward fulfilling those OKRs through the establishment of respective initiatives. But now is the time to define how to materialize the enterprise OKRs and initiatives, by when (in terms of timelines) and by who (in terms of responsibility), all while ensuring we are not just engaging with a sample of the organization, but reaching every corner of it. We are aligning everyone toward, on the one hand, the future desired DevOps state and, on the other hand, how and by when to reach it.
Tip – spend some time refreshing your memory
At this point, I propose you go back to Chapters 2 and 3. In Chapter 2, The DevOps Multi-Speed Context, Vision, Objectives, and Change Nature please refresh your memory on the strategic objectives and enterprise DevOps OKRs. In Chapter 3, The DevOps 360° Operating Model Pillars and Governance Model please revise the workstreams that we have created, the scope of which is to define initiatives on materializing the enterprise DevOps OKRs.
As with any element of the DevOps 360° operating model, the value proposition of the enterprise planning and adoption is multidimensional and concerned with the following objectives:
Jean-Jacques Rousseau and the “DevOps society”
Jean-Jacques Rousseau was a Swiss political philosopher who lived during the 18th century and significantly influenced the development of the Enlightenment across Europe. One of his main beliefs about modern society and humanity was that once humans give up their innate independence and become part of society, they become corrupted. In our enterprise DevOps society, the effect in most cases is the opposite, in my opinion. Getting your teams together during planning and adopting results in them being less corrupted during the DevOps evolution. This is because they need to act collectively, while also being measured collectively, which means, for instance, that they will more easily give up on their shadow IT solutions and collaborate on providing regulatory evidence, while working more closely overall, under DevOps solidarity, by feeling part of something bigger. This is not, of course, always the case (just to make sure I am not perceived as being naïve).
Before moving into the mechanism and practicalities of enterprise planning and adoption, I would like to go back again to the concept of speed. (I am sorry, and I cannot help it, speeds are everywhere.) Two terms and corresponding approaches that I repeatedly use in my career, while balancing them effectively, are the tactical planning and adoption approach and the organic planning and adoption approach. The following are the definitions in our DevOps evolution context:
To avoid confusion
Limited external support for organic growth does not mean you are left alone in your DevOps destiny. The necessary means must be enabled to support the organic adoption, but that will primarily be in the form of artifacts, solution recipes, frameworks, patterns, and methodologies, and not hands-on support. The big difference from an organizational focus perspective is that tactical involvement is characterized by We are dedicated to your cause and will provide hands-on support, while organic is Please find the solution in the GitHub repos of the CI/CD platform team and use the service desk if you have questions.
The tactical and organic approach distinction automatically creates two major DevOps speeds in your organization, which is natural and sensible. The tactical approach areas that have the full focus of the DevOps stakeholders and the necessary capital secured will inevitably start earlier with the DevOps evolution, and move faster through it.
But what is the value of investing extra effort and early focus on tactical adoption?
As we mentioned in the previous chapter in the DevOps speed formula, technology is a key element of speed. Hence, it is not only business applications that must belong to the tactical approach, but also core DevOps platforms that enable capabilities that are fundamental to the DevOps evolution and belong to the DevOps 360° technological ecosystem.
Did you know?
Across the enterprise DevOps evolutions I have been part of in my career, the organic adoption officially started 6 to 12 months after the tactical adoption.
Having read this book so far, I believe you can guess what the determinants of choosing tactical adoption candidates are. It’s about speed (criticality and impact) obviously, expressed using the formula we presented in the previous chapter, but also business context, time to market, reliability, compliance, and technology. But this time, the thinking is more strategic and goes beyond isolated business applications and platforms. Scale, not only speed, is important when choosing tactical adoption candidates. The main strategic domains that combine scale and speed in tactical adoption are the following, complemented by real industry examples. Note that the last entry in the following table adds a rather rare but important domain, which is one of absolute critical necessity.
Strategic domain |
Examples |
High-speed business domains and applications |
Mobile and online banking, core banking, trading, asset management, and payments |
End-to-end business-critical value streams and flows (either within or across business domains) |
Trading life cycle, open banking ecosystem, know your customer, and customer account life cycle |
Regulatory compliance ecosystems |
FRTB, MiFID, Basel, PSD 2, group risk, capital and liquidity reporting warehouses, and monthly and year-end reporting |
Strategic technological capabilities |
Standard CI/CD, public cloud platforms, developer self-service portals, and big data engineering platforms |
“Burning platforms” |
Areas that have severe reliability issues and/or accumulation of unfulfilled regulatory demand |
Table 10.1 – Strategic domains and examples of primary candidates for tactical adoption
Typically, you will find the tactical adoption portfolio to be balanced across the preceding strategic domains. And if you look closely at certain cases, you will also identify applications and platforms that are not necessarily fulfilling the criteria of the top speeds of the criticality portfolio. There are two main reasons for that. Firstly, in certain contexts, it is challenging to slice a business-critical flow or value stream with precision. Therefore, and inevitably, applications will belong to that flow or value stream that are not required to move at top speed. Secondly, there are troublemaker business applications and platforms that create direct reliability issues for the tactical adoption candidates. You take those in the scope with the ambition to fix them through the tactical adoption’s means and capital (another secret of the industry revealed).
Some important considerations when choosing the tactical adoption candidates are listed as follows:
Differentiator |
Degree edge 1 |
Degree edge 2 |
DevOps WoW principles |
Rotational |
Fixed |
Availability |
99.9% |
95% |
Time to market |
On demand |
Weekly |
Release size |
Incremental |
Bulk |
Platform |
Cloud native |
Mainframe |
Hosted |
Public cloud |
On-premises |
People skills |
Cross-functional advanced |
Skills gaps |
Client facing |
No |
Yes |
Regulatory impact |
High |
Low |
Future life cycle |
To continuously evolve |
To incrementally advance |
Service nature |
Shared service |
Business area dedicated |
Programming language |
Java |
HPS |
Vendor dependent |
No |
Yes |
CI/CD onboarded |
Yes |
No |
Passed PRR |
No |
Yes |
Architecture |
Distributed |
Monolithic |
Data transmission |
Real time |
Batch |
Compliance gaps |
Several |
Limited |
PII data |
Yes |
No |
Market and advantage |
Regional and new |
Global and existing |
In production |
No |
Yes |
Table 10.2 – Tactical adoption portfolio differentiation parameters
Of course, you should not use all the differentiators of the preceding table to identify candidates but to define a subset that you consider relevant to your context and ambitions. As you can see, the last differentiator is underlined, and this is intentional in order to highlight emphasis. It is an absolute must to include business applications and platforms that are already in production, as well as those that are not yet. Or, even better, business applications and platforms that you have just started designing without having written a single line of code. There are significant differences between the two categories, and you want to take full advantage of that. Starting from a blank page with zero technical debt and legacy is the best way to unleash DevOps innovation and create game-changing patterns, especially in the domains of greenfield and composable banking. We will discuss “early versus late” further in Chapter 13, Site Reliability Engineering in the FSI when we discuss SRE.
I like the phrase all hands on deck a lot, and I find it very relevant to DevOps tactical adoption. In our tactical adoption context, all hands on deck refers to dedicated determination across several DevOps ecosystem stakeholders to the success of the tactical adoption areas. Remember, two of the main motives behind the tactical adoptions are as follows:
Let’s focus on the second point. The tactical adoption areas can be the first ones to adopt a multi-cloud strategy, the first ones to adopt GitOps flows through the standard CI/CD pipelines, or even the first ones to adopt the advanced compliance as code DevOps controls. To do so, they will need dedicated support from various DevOps stakeholder teams, but also a demand/supply and feedback loops mechanism. Do you remember the guilds and communities for practice we mentioned in Chapter 5, Business Enterprise Agility and DevOps Ways of Working Reconciliation? Something similar to that can be enabled within the tactical portfolio and its external support areas. On the other hand, tactical adoption is a golden opportunity for several DevOps ecosystem stakeholders to have a playground and pilot the parts of the DevOps 360° operating model that they are responsible for, while getting valuable insights into the organization’s context, demands, and needs. The overall setup creates the operational environment and means for advanced DevOps collaboration opportunities, as well as promoting people mobility. As we have also seen in the DevOps CoE engagements, ideally, the external utility support areas move either temporarily or virtually in the agile DevOps teams that are part of the tactical adoption and become an integral part of them over the course of the evolution. That will enable them to better serve organic adoption in the long run, having built strong know-how, success stories, and contextual awareness.
Figure 10.1 – The tactical adoption all-hands-on-deck ecosystem
The preceding diagram provides a visual overview of the tactical adoption ecosystem, which consists of three main actors in our example:
At this point, we will close the tactical adoption section with the belief that you have got some valuable insights and ideas. The coming section will focus on the enterprise portfolio planning and adoption mechanism, touching also on the organic side of the evolution.
Different organizations, depending on their size of operations, organizational operating model, structure, and enterprise business agility model, follow different enterprise portfolio planning and adoption mechanisms. You will find cases where there are annual and quarterly enterprise-wide business reviews across a whole organization, and you will also find monthly priority planning dedicated to each business line or value stream, or even monthly or quarterly program increments for organizations that have adopted Scaled Agility Framework (SAFe). Irrespective of your enterprise planning and adoption mechanism, you will have to fit the DevOps 360° evolution into it. You’ll also need to agree on how you will balance your tactical and organic adoptions. Naturally, you must not create a dedicated mechanism only for the DevOps evolution, as you do much more than just DevOps in your organization.
Some common patterns are applied to enterprise planning and adoption that I have observed being repeated in my career across various contexts. Of course, different organizations follow different practices, but we also need to remember that imitation, as we discussed in Chapter 2, The DevOps Multi-Speed Context, Vision, Objectives, and Change Nature among incumbent banks is also a dominant industry practice. Let us have a close look at some pragmatic mechanisms, which we will summarize through a holistic visualization at the end of the section.
These objectives typically have a 3- to 5-year scope and are revised annually. As we also discussed in Chapter 2, The DevOps Multi-Speed Context, Vision, Objectives, and Change Nature the strategic objectives are initially shaped as corporate themes, which are then translated into technological themes. A transparency and reconciliation mechanism between the two is established and the progress is tracked on a quarterly basis.
These are defined by the DevOps 360° vision authority and are linked to the strategic objectives. Typically, they have a 3-year scope and are quarterly reviewed in terms of relevance to the DevOps evolution and benefit realization.
There is a workstream defined for every enterprise DevOps OKR on shaping and designing the initiatives that need to run in order to materialize it. The collection of the initiatives’ outcomes across workstreams will eventually be the final DevOps 360° operating model. The workstreams are virtual constructions that should not last for more than 3 to 6 months. Once the initiatives are defined, they are institutionalized and become business as usual, represented in the enablement and adoption teams’ specific OKRs, with the workstreams being dissolved.
Once the initiatives are defined, there are two paths to institutionalization and materialization: organizational enablement and the agile DevOps team’s adoption, in the form of epics and user stories.
Organizational enablement refers to activities that need to be conducted to enable the respective DevOps 360° operating model capabilities at the enterprise level, such as the following:
As you can see, these are simple capabilities that you need to enable on an enterprise level.
Organizational adoption refers to the activities that need to be performed at the agile DevOps team level when adopting the enabled organizational capabilities and the new DevOps 360° operating model. For example, and using the examples from organizational enablement, the agile DevOps teams in the payments value stream should do the following:
Both organizational enablement and adoption are expressed in the form of DevOps team-specific evolution OKRs (over the course of 3 months to 3 years), which are further expressed in the form of overarching epics and user stories. The accumulation of those epics and their respective estimates is the data that shows how long it will take for the evolution to be adopted. Also, it will reveal what is possible and what is not possible in terms of your organization’s capacity, conditions, and circumstances. Let’s look at a couple of examples to explain how we get from a bank-wide strategic objective to an agile DevOps team-specific DevOps OKR expressed in epics and user stories. In the following two examples, we will see some representative examples of how an online banking agile DevOps team could potentially break down the enterprise DevOps OKRs of compliance and operational efficiency into team-specific DevOps OKRs of DevOps controls and adoption of the fixed roles DevOps WoW organizing principles model.
Here’s the compliance adoption breakdown example:
Figure 10.2 – Adoption breakdown for the example of compliance
Figure 10.3 – Adoption breakdown for the example of DevOps models
As you would expect, situations, circumstances, conditions, speeds, and relevance will make different agile DevOps teams translate the enterprise OKRs differently. How can they nevertheless potentially be aligned toward common objectives? We will see in the last section of this chapter.
The following diagram illustrates an overview of the enterprise portfolio planning mechanism:
Figure 10.4 – Enterprise portfolio planning mechanism overview
The enterprise portfolio planning and adoption mechanism might sound straightforward, but it is quite the opposite when applied in reality, especially in cases where organizations are not used to planning and executing collectively. The following are my recommendations of considerations and decisions that you need to make in order to smoothen the process.
An anti-pattern that I have seen repeated is making the mechanism applicable only to the business lines and respective agile DevOps teams while excluding utility and technological functions. It is a must that you involve the broader DevOps 360° stakeholders’ ecosystems, or at least the ones who own parts of the DevOps 360 operating model.
Most probably, you are coming from a mixed context on making estimates. Some parts of your organization are used to estimate based on points in the user story, some estimate on days, some are based on weekly Scrum team capacity, and others do not estimate at all. Agreeing on a new way of providing estimates is vital in order to be able to get harmonized input when certain initiatives are planned to be enabled and adopted across your portfolio. Also, agree on who is responsible for providing estimates as part of the planning process. Please do not make the teams that are responsible for the initiatives enablement also responsible for providing adoption estimates on behalf of the agile DevOps teams. They do not know the context and state-of-the-art of each agile DevOps team out there. The responsibility should be ideally placed with the product owner (PO) of each agile DevOps team. In some cases, it is not even the PO as some things are of a purely technical nature. Though holding the PO responsible is what I advise you to do.
I need to tell you this story. Once upon a time, we were participating in a program increment session, and our engineers provided rough estimates on several platform modernization tasks. Some of the POs thought the estimates were too much. One said, “What do you mean 2 weeks, do you think it takes 2 weeks to do this at Revolut?” The engineer replied, “I have never worked for Revolut to be able to know how long things take there. But I can guess that Revolut can move faster than us.” Be realistic about what you are asking people to deliver and by when and also leave the estimates for the subject matter experts.
Typically, planning has two levels. The first level is what you wish to achieve as an enterprise from a corporate strategy perspective. The second level is what each business line wants to achieve internally. Different business lines have different market competitive advantages, client portfolios, countries of operations, and regulatory requirements and contribute differently to the revenue of the enterprise. The same logic applies to the DevOps technological ecosystem. Naturally, the teams that are part of enabling the DevOps journeys, experience, and productivity will also need to synchronize within their own ecosystem. Allowing for a minimum of two levels of planning while ensuring limited deviations will prove vital.
Let me explain this one using the dominant example in DevOps adoptions: the adoption of CI/CD pipelines. Do you remember that we come from a context of various CI/CD pipelines across agile DevOps teams, with only a subset of them using the standard offering? Considering this CI/CD pipeline contextual element example, two questions arise that you need to answer:
You will get those questions, plus similar ones, several times, so be prepared to answer with honesty, logic, rationality, and clarity.
Each initiative needs to have a value proposition and a scope of work: the DevOps SDLC to implement the SDLC capabilities, the DevOps controls to implement the regulatory compliance controls, and so on. You need to provide a scope and expected outcome to the agile DevOps teams, but do not tell them exactly what to do. Provide the solution recipes, frameworks, and patterns where applicable, but allow them to take it from there. You do not know their context and the current state of the DevOps art in detail, plus you need to give to them the best level of autonomy and allow creativity and innovation. Just tell them what they need to achieve and when, and let them work on it. In cases where the scope of an initiative is not clear yet, which means that it is not possible for the teams to create specific DevOps OKRs, allow them either to descope that initiative until clarity is created or to use their intuition, expertise, and experience and act based on the value proposition.
A common anti-pattern I have seen is setting priority zero for certain initiatives, primarily the initiatives concerned with regulatory compliance. Priority zero indicates that something needs to happen before everything else and de jure (“by law” in Latin). Avoid that practice as you do not have insight into the situation, condition, and circumstances of each agile DevOps team. You might ask them to prioritize DevOps controls while their production environment is on fire. Naturally, they will focus on reliability matters in the next sprint. Or you might ask them to focus on DevOps controls when they need to focus on GDPR as they will get a fine if they do not close the respective gaps soon.
Agile DevOps teams, as well as the DevOps evolution items, will have to work on delivering new features, hygiene tasks, compliance tasks, and so on. Therefore, their backlogs will have to cater to more than the DevOps evolution. How they balance their backlog should be up to their respective POs. Avoid prescribing that the priorities of each sprint should, for instance, be split like the following:
Allow the teams to self-organize to the best level of allowance by just informing them what they need to achieve, as we will outline in the following section.
The behind-the-scenes DevOps wonder
Once upon a time in one of the banks I used to work for, our business counterparts were amazed at how we could balance innovation with reliability and compliance, while the POs were primarily prioritizing innovation in terms of new features. That was because we were playing the priorities and estimates smartly, delivering new features while advancing our DevOps capabilities. We were also quite focused on reliability and compliance with the DoD of epics and user stories.
Not all your teams by default will follow the same DevOps evolution journey and reach the same adoption level at the same time. They have different starting points, capabilities, ambitions, contexts, and the like. Nonetheless, you need to somehow get them to align on certain DevOps evolution commonalities, defining the key evolution milestones that they all need to meet. To define and group those commonalities, I like to use the term DevOps minimum viable adoption. With this term, in this book we define the common DevOps adoption milestones that all the teams need to reach, no matter their situation, context, conditions, circumstances, or starting point. The concept is twofold and links very well to the production readiness review (PRR) framework that we discussed in the previous chapter. In my relatively extensive experience with DevOps adoption across the financial services industry, DevOps minimum viable adoption is the most pragmatic and sustainable mechanism that you can follow as part of your organic DevOps adoption. Here are some practicalities around it.
This is a pragmatic way to make clear to all the teams what is expected from them in terms of the following three DevOps equilibrium parameters, complemented by associated KPIs. What is expected is not only to be expressed qualitatively and quantitatively per parameter, but it also needs to be made clear that the three must be balanced. What is the value if your time to market is close to the speed of light, but if your production environment is crumbling and you have 10 open audit remarks? Setting targets and balance as in the following example is solid and pragmatic:
If you remember, these are attributes in the portfolio registry mechanism that we discussed in the previous chapter. The portfolio registration process also sets the parameters targets’ clarity. Having set the parameters, then it is up to the respective teams to judge which DevOps evolution direction they need to take in order to fulfill them and prioritize their DevOps adoption accordingly.
To refresh your memory, DevOps controls are risk management, compliance, and speed. They are almost identical to the equilibrium parameters, and that is intentional. The logic is that you become compliant while getting faster and more reliable. What I propose you do, which is the practice I also follow, is to define a set of controls that are applicable to any speed/criticality and technology and architectural classification and make them mandatory across your portfolio. They need to be prioritized by your teams from the start in order to first meet the three equilibrium parameters, and afterward, build on top of them and plan their evolution from there. As long as your teams have met the DevOps controls foundation you set and are also meeting the three equilibrium parameters, you can consider them as done from an evolution perspective. What other DevOps advancements they do is not related to enterprise planning and adoption and so is not your business anymore. That is, of course, unless production data on the equilibrium parameters gives you different indications. Some teams might even decide to exceed their targets. If they have the capacity, capability, and PO support, let them do it. Having said that, you need, as mentioned earlier in the chapter, to make some brave decisions, especially in the domain of standardization and simplification. As in, are your teams done if they fulfill the equilibrium parameters while using none of the standard offerings and having only partially adopted the DevOps SDLC? You decide.
The DevOps minimum viable adoption concept should be defined and launched as a formal framework, and its ownership ideally should be placed with the DevOps CoE (or with whoever owns the DevOps 360° operating model). The DevOps minimum viable adoption framework should also have a direct and transparent link with the PRR framework. The PRR is decisive and will eventually be the only source of truth on how your teams evolve with the DevOps adoption. A satisfactory PRR will also, to a large extent, indicate a satisfactory DevOps evolution state and progress. The following is a representation for your inspiration:
Figure 10.5 – Minimum viable adoption framework representation
As you can see, the capabilities under the minimum viable adoption line are quite fundamental to DevOps. But when we cross the red line and move toward context-specific advancements, the capabilities become more sophisticated.
How to prioritize the minimum viable adoption capabilities is up to each agile DevOps team, on both the business applications and platforms portfolio, and depends on conditions such as the following:
The element of DevOps minimum viable adoption is fundamental to your evolution but not as straightforward as it looks at first sight. There is further depth to it that can complicate the DevOps evolution for the agile DevOps teams. There’s more on this in the next chapter.
What about the part of the tactical adoption areas?
I almost forgot about them. The DevOps minimum viable adoption is not really applicable to them. They push the DevOps innovation boundaries because on the one hand, they are your flagships, and on the other hand, you use them to pilot new concepts. Therefore, they need to be constantly advancing and be at the DevOps evolution and innovation edge.
In this chapter, we focused on the enterprise portfolio planning and adoption mechanism of the DevOps 360° evolution. Initially, we explained its vital value proposition for the evolution, and afterward, we argued why your adoption should be divided between a tactical and an organic approach. On the tactical side, we discussed its arguments, highlighting its strategic importance in the organic evolution. Moving on, we looked into the main strategic domains that organizations focus on when appointing candidates for the tactical adoption, the parameters of differentiation between the tactical and organic adoption candidates, and what the concept of all hands on deck implies for the tactical adoption. Afterward, we moved on to presenting a practical approach for the enterprise portfolio planning and adoption mechanism, focusing on the organizational enablement and adoption of the DevOps OKRs. We also provided two examples to explain the connection between strategic objectives and team OKRs. Continuing, we outlined some important points to consider when designing and executing the mechanism derived from various examples from the industry. Closing the chapter, we focused on the important concept of DevOps minimum viable adoption. We explained its DevOps controls origin, relation to the PRR framework, applicability, and importance for the DevOps 360° evolution and complemented it with an example.
In the next chapter, we will focus on the mechanism of benefit measurement and realization. We will look into the approaches of validating whether your evolution’s business case materializes or not.