The promise

The promise or dreamland many CTOs have alluded to is leaning on the famous quote by Donovan Brown:

“The union of people, process and products to enable the continuous delivery of value to our end users”.

There is a lot to digest here.

As I interpret this, to me it tells me about a harmonious way of working, where everyone involved in delivering high quality software at speed, aligns themselves to best serve the need of the end user.

People over process and products!

DevOps, especially in Donovan’s definition, has always been about people. Process and products are of less importance and should serve the needs of the people doing the work.

Reality check

A lot of the core of this message has somehow gotten lost, especially in large organizations that we usually refer to as enterprises. That’s a shame since, when approached as a whole, can deliver powerful results. Unfortunately we see and read of many implementations failing. Let’s explore some of the symptoms that are expressed or visible and see if we can define a way forward.

Symptom 1: We want to be agile, therefore DevOps

Conflation of the concept of DevOps with Agile has been (imho) the single biggest mistake. This seems to be a knowledge gap that “we” as in, “the ones in the software industry who should know”, apparently are unable to express this in a clear and consistent manner to companies requesting guidance. With regards to evaluating this symptom for enterprises, we also need to look a bit deeper.

Not everything needs agility

The nature of an enterprise is that it is an evolved system. Over time it has accumulated all kinds of people, processes, business units and many, many tools. This by nature already exposes the misunderstanding that this vehicle can in it’s totality become agile. Of course that’s like believing an iceberg will fit in your fridge, but yet again here we are. As we know from Wardley mapping, not every type of engineering requires an agile approach. If the work is novel then agile is best fit. If the outcome needs to be built for scale, have robustness for example, a more LEAN approach is best suited and if you’re building products for life, you will need to consider using six-sigma or something similar to engineer the products.

Frameworks for scale

The past two decades we’ve seen the introduction of the likes of Scrum, Scrum @ Scale, LeSS, SAFe, etc. I don’t think any of the frameworks pushes the notion of becoming fully agile. From what I understand of the provided guidance is that they allow some form of coordinated engineering at scale in which priorities can change and fast feedback loops are sought. However, somehow the key message that gets conveyed from these is that “it will make your business agile!”.

Don’t blame the CTO

Of course any CTO that hears that message sees this a a blessing and will be eager to onboard these practices. Who doesn’t want “double the delivery in half the time”? Keeping an enterprise competitive is a hard task and should not be underestimated. Especially in an age where more and more of the services companies deliver are based on- or intertwined with software. The IT landscape of enterprises is often littered with ancient technology, relying on just a few people who know how to operate and run these systems. That results in a lot of sources of inertia, resisting change when asked. The key in implementing successful change in such an environment is managing this properly. We can start by creating and building a better common understanding of the landscape, climate and options whe have, hence make a Wardely map.

Symptom 2: We’re planning 12-18 Months for this

What I cannot get my head around is that at some level there is such a huge underestimation how much effort and time is required to change the way of working. Anyone in a leadership position should ask themselves “how long did it take you just to get comfortable working as a leader in your enterprise?”. The answer most likely is somewhere between six and twelve Months. This is just to find your footing, connect with the people, get acquainted on the surface with processes and tools.

It will probably take another couple of years before the organizations starts to feel like you’re in tune with it’s rhythm, like it fits you as your favorite jacket. The process you’ve gone through is adjusting to the unwritten ways of working of the organization and absorbing the relationships at play that are not on the org chart.

The learning curve

This learning curve on many levels is the same for engineers (either developers or system operators) when being thrown in to a “DevOps initiative”. Teams need to release their old habits and acquire new ones. Building trust in your peers, becoming comfortable with building and running your own system. Overcoming cultural differences, working and communication styles, defining your teams path by doing and improving. There’s a lot to take in and it’s no small feat for people having to go through that type of transformation. as they say “The struggle is real”.

Scaling change

It not just becomes problematic when leadership expects these teams to become productive in an instant. This is creating even more pressure and putting a huge strain on the individuals who are made responsible, but not given the necessary preparation, bonding and support structure to succeed.

When this pressure cooker adds a large concurrent transformation program to “transform” the way-of-working for many or all teams in a fixed time frame, bad things are bound to happen. What we know from achieving flow from Don Reinertsen and his lectures on “product development flow” is that batch size matters. So start small, create flow and learn from the challenges people have to overcome in this transformation.

Team Topologies

Have a read of the wonderful book “Team Topologies” by Matthew Skelton and Manuel Pais to learn about creating a fitting team setup and transforming the way of working at scale for your organization.

Symptom 3: Technology first

DevOps transformation doesn’t come from tools or toys you introduce. you can’t Jira you way into a DevOps way-of-working. So many companies unfortunately focus on the tools whereas these should be merely supporting teams in the way they need. I’m not sure what’s driving this but there seems to be a preference for buying things over having difficult conversations about change in the organization. Once a tool is on boarded it can “safely” be mandated and be the target of blame for everything that follows. Sad but true.

It is also true that technology and the improvements these bring, can help a team deliver more value. But all too often, tools are thrown at teams in the expectation that they will somehow know how to operate them and out of the gates create awesome outcomes. As you may have noticed, this is not catering to the needs. If you want a team to become more autonomous you may want to ask them what they or even tell them, “if you need anything, buy it”. But that final point is for many a pipe dream, a utopia that only exists on paper.

Symptom 4: One size fits all

In the previous symptom we’ve already touched on this, the notion that all teams having to go through this transformation. And even worse that all teams require the same treatment on that journey. We have to stop trying to define these “silver bullet solutions”.

PEOPLE FIRST

In the enterprise we have to revive the notion that transformations (albeit: digital, DevOps, Agile, Product centric, etc.) must be PEOPLE FIRST approaches. If the process or tools become more important than the people we’re setting ourselves up for failure. That doesn’t mean that process and tools play an unimportant role but they have their limits. Look at the needs of the people impacted by the change, evaluate the landscape and the climate in which you operate and bring sustainable change accordingly.

Have not just one plan, take small steps, run experiments, build on the feedback and continuously improve!

All is not lost

The good news is that by now, we (in the software industry) have learned a lot about the friction involved in transformations like these. There is an excellent book called: “Accelerate” by dr. Nicole Forsgren, Jez Humble and Gene Kim that is dedicated to uncovering the science behind DevOps. Next to that, there is a wonderful book by Mirco Hering called: “DevOps for the Modern Enterprise” that addresses many of the challenges in way more detail.

If you need help

If you want to learn more or dive into your own transformation journey challenges, feel free to reach out for a chat . Happy to help ;-)