10

Tactical and Organic Enterprise Portfolio Planning and Adoption

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:

• The value proposition of the enterprise portfolio planning and adoption mechanism
• The difference between a tactical and organic DevOps evolution
• The main elements of the tactical DevOps evolution
• Practicalities and important considerations of the enterprise portfolio planning mechanism
• The DevOps minimum viable adoption concept and framework

What is the value proposition of enterprise portfolio planning and adoption in the DevOps 360° evolution?

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:

• Align on an enterprise level on the governance mechanism of planning and adopting the DevOps 360° operating model by providing clarity on the parts of the DevOps 360° operating model that are to be enabled and adopted, as well as agreeing on the governing process and practicalities.
• Align on the when, as in, when the standard CI/CD pipeline should be ready and when the agile DevOps teams need to/can get onboarded.
• Align on the who, as in, who owns the initiative of enabling the standard CI/CD pipeline and who is adopting it, as well as who can support both the enablement and onboarding (see the DevOps CoE section in Chapter 4, Enterprise Architecture and the DevOps Center of Excellence).
• Build awareness and acceptance of the vital milestones of the DevOps evolution. For instance, create a consensus that by the end of 2023, your organization should have approval from your main regulator on the DevOps controls adoption.
• Understand how long it will take for the various teams to reach the evolution’s milestones through their estimates on adopting the DevOps initiatives’ outcomes.
• Plan the funding mechanism for enablement and adoption.
• Enable a common benefit realization process, anchored to the periodical planning and adoption revisions.
• Create transparency on the DevOps work of your various teams and enable a sense of collectivism and alignment across backlogs. Putting it in a romantic way, we do this together, working on helping each other to advance.

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).

Why you should balance a tactical and an organic approach

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:

• Tactical approach: Going by the Oxford dictionary, the term tactical indicates “carefully and methodologically executed actions with the ambition to gain a specific advantage.” In our context, suppose that the vision for the mobile banking application is to transform it toward the greenfield banking state-of-the-art to allow it to move at its own rapid speed. This is in order to gain advantages internally by eliminating dependencies, but also externally, by beating the competition. To achieve that, a careful, methodological, and tactical transition plan is required. The transition needs to be planned and executed carefully across DevOps aspects, involving several stakeholders who will have to dedicate time to the cause within strict timelines. You will probably conduct an architectural and technological transformation of the mobile banking application to eliminate data and infrastructure dependencies, as well as ensuring it can run in multiple public cloud providers. Your EA function and core infrastructure teams will be involved, providing reference architectures and autonomy over the enterprise public cloud landing zone. Perhaps you will also get the DevOps CoE engaged in speeding up the cloud-native path SDLC adoption and improving the release velocity, while you might also engage a dedicated SRE team to focus on reliability engineering. In addition, I assume you will focus heavily on zero-trust security, engaging your cyber security teams. Compliance as code will also have a strong focus and will possibly require the involvement of your IT risk management framework function. Coordinating and funding the targeted actions of all these stakeholders toward the mobile banking application requires a tactical approach. You cannot just rely on people finding the time and resources to get it done. Mobile banking is one of the several business applications or platforms that are candidates for tactical adoption. I like to call them DevOps portfolio flagships.
• Organic approach: My definition for this is derived from the Greek word οργανικός, which in English translates to organic. When it is translated, though, it loses much of its original meaning. The original Greek definition of οργανικός is the totality of elements a living organism consists of, which grow at their own pace over time toward collectively supporting the living organism’s operations. The Greek interpretation also indicates growing from within, without external intervention. In our DevOps context, the living organism is the organization’s teams, which grow their DevOps capabilities at their own pace, eventually contributing to the realization of the DevOps 360° operating model. That growth for the majority of teams also happens with restricted external support, due to either insufficient monetary, technological, and people capital, or dedication of that capital to other causes (see the tactical approach). Let’s suppose that the mobile banking application, along with five other business applications, due to certain characteristics, will follow a tactical approach to the DevOps evolution, with full focus across stakeholders and specific deadlines. None of the other business applications and platforms in the organization (except those six) will have that dedicated focus and support, they might lack capital investment, and they will have more relaxed milestones to meet. They will also predominantly have to rely on their own competencies during the evolution without expecting significant external support. Those “rest of the organization, but not the tactical” areas are to consequently grow organically in their DevOps journey.

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 adoption value proposition

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?

• You need flagship applications and platforms to work toward the evolution’s outcome first, on the one hand because their situation and circumstances require them to do so (for instance, market competitive advantage and reputation), and on the other hand because you need big success stories in the early phases of your evolution, or because you have allocated budget dedicated to those flagships in the evolution’s business case, which you have reserved in your balance sheet and need to spend within certain timeframes.
• You do not have unlimited people and budget. This requires you to invest your monetary and people capital tactically. You cannot have the DevOps CoE focusing on SDLC engineering for 100 applications in parallel when your EA function cannot support the same 100 applications on defining business-critical flows. At the same time, I doubt you can go out there and hire hundreds of new people. (I already told you that most organizations are under cost pressure, and in Chapter 12, People Hiring, Incubation, and Mobility I will also discuss how they struggle with talent attraction as well.)
• Your regulators will primarily focus on certain flagship applications and platforms. Keep them busy with those while giving the organic ones the time to prepare to board the evolution train.
• You want to pilot your advanced DevOps concepts in applications and platforms where there is a certain long-term existence and a significant business and technological innovation space.
• Most probably, the tactical adoption areas are already ahead of the DevOps curve compared to the rest of your organization, which means that the ground is more prepared to receive the DevOps evolution seed. This will also help you to prove the new DevOps operating model and create solution recipes, frameworks, and patterns for the rest of the organization to adopt more quickly and with a forward-looking outlook.
• You need to make sure you get the flagships done as quickly as you can because unforeseen situations might jeopardize your efforts. Potential circumstances, such as changing market and economic conditions, a potential regulatory fine, stricter regulatory requirements, potential legal entity restructuring, a significant M&A activity, or severe and horizontal cost-cutting, have a high probability of either slowing down your evolution or even causing its absolute termination.
• Those areas consist of strategic technological utilities that the rest of the organization will need to use to adopt the evolution’s outcome. For instance, the standard CI/CD pipeline, the public cloud capabilities, and data engineering and analytics should be considered part of your evolution’s flagships.

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.

What are the predominant tactical strategic domains?

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:

• Go for magnitude. The larger the ecosystem, value stream, or critical business flow, the more positive noise it will make in terms of benefits and evolution dynamics.
• Take advantage as much as you can of the regulatory compliance work to ensure full focus through prioritization, people allocation, elimination of budget constraints, and positive regulatory pressure.
• Ensure that not all the tactical candidates are the best in the DevOps class. Their further advancements will create a large gap in DevOps maturity between them and the rest of the organization, risking making the DevOps operating model too advanced for others to adopt.
• Cover a broad range of parameters and characteristics in the tactical adoption portfolio. If you only focus, for instance, on mission-critical cloud-native applications, you will struggle to create solution recipes and patterns for highly available decoupled legacy applications, and most probably you will forget about the mainframes. In other words, you need a balanced portfolio in your tactical adoption, which can be representative of most of the contexts across your organization. The following differentiation parameters can help you to make your tactical adoption portfolio versatile:

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.

All hands on deck

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:

• Get certain parts of the portfolio to move faster: top speed.
• Define, design, prove, conceptualize, and scale the DevOps 360° operating model and in particular its DevOps 360° SDLC capability engineering and evolution part.

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:

• The tactical adoption candidates that lead the evolution and move at their own fast speed, having communities of practice on creating tactical adoption synergies
• The DevOps 360° operating model capabilities owners, who support the enablement and adoption of the model, receive feedback from the adoption and create solution recipes, frameworks, and patterns that can support the organic adoption
• The DevOps design and advocacy authority, which provides expertise through leadership and aligns the tactical adoption teams with the overall vision of the evolution

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.

The enterprise portfolio planning mechanism

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.

What a pragmatic mechanism can look like

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.

The bank’s strategic objectives

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.

The DevOps enterprise evolution 360° OKRs

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.

The DevOps enterprise 360° evolution workstreams

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.

The DevOps 360° enablement and adoption teams’ specific OKRs

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:

• DevOps SDLC and controls definition and built-in implementation on the DevOps technological ecosystem
• New dynamic and rotational identity and access management system to cater to the rotational model DevOps Ways of Working (WoW) organizing principles model
• A formal portfolio modernization mechanism
• Public cloud capabilities through the establishment of a new team

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:

• Implement the new DevOps SDLC cloud-native path and corresponding controls.
• Onboard their applications running based on the rotational model to the new identity and access management system.
• Conduct their forward-looking platform modernization plan.
• Give up their current shadow IT public cloud implementation and utilize the cloud services of the new public cloud platform team.

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

Here’s the DevOps models WoW:

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

What are the very important considerations when designing and enabling the mechanism?

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.

Define who is part of the mechanism

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.

Agree on the estimate’s measurement

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.

The Revolut example

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.

Find the right balance between enterprise and business-line-specific planning

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.

Define the DevOps initiative’s acceptable definition of done (DoD)

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:

• Is it sufficient to implement the new DevOps SDLC’s capabilities and controls in our own CI/CD pipelines?
• Do we need to shift to the standard common CI/CD pipeline?

You will get those questions, plus similar ones, several times, so be prepared to answer with honesty, logic, rationality, and clarity.

Do not tell people exactly how to implement their team-specific DevOps OKRs

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.

Do not set priority zero initiatives

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.

Do not become prescriptive on the backlog allocation per agile DevOps team

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:

• Innovation: New features and improvements 60% of the time
• Reliability: Non-functional requirements 20% of the time
• Compliance: 20% of the time

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.

The tactic of DevOps minimum viable adoption

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.

Go by the DevOps equilibrium parameters and set objectives

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:

• Time to market: On demand, with 15 minutes release velocity
• Reliability: 99% availability, while ensuring low latency
• Compliance: Adherence to the DevOps controls based on portfolio classification

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.

DevOps controls as the foundation of the evolution

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.

Shape it as a formal framework

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.

Where to start on the DevOps minimum viable adoption

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:

• Burning priorities and return on investment: Is it reliability or time to market that we need to focus on in our circumstances, and will it give us the best value?
• Priority agreements with the regulator: Is production hygiene or quality assurance the top priority?
• Available capacity: After the prioritization of new functionality, what is the bandwidth left per sprint?
• Available means: We do not have cloud engineers at the moment and need to hire in order to focus on the cloud-native journey.
• Capability readiness: We don’t have our own security information and event management (SIEM) solution, and it is not worth building one as the central common platform offering will be ready in 3 months. Let’s stick with automated security logging then.

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.

Summary

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.