Enterprise DevOps: The People's Front of Judea, or Don't Sweat the Small Stuff

DZone 's Guide to

Enterprise DevOps: The People's Front of Judea, or Don't Sweat the Small Stuff

This enterprise DevOps article takes a look at the fundamental and tactical considerations for continuous software delivery.

· DevOps Zone ·
Free Resource

This is the eighth in a series of blogs about enterprise DevOps. The series is co-authored by Sacha Labourey, CEO, CloudBees, and Nigel Willie, DevOps practitioner.

Previously in this series, we have discussed some approaches to creating a foundation and setting up a service line. In this article, we shall focus on one of the key challenges that anybody delivering a program will have experienced.

In any major initiative, it is our experience that key stakeholders are aligned with the core aims of the program. There may be pockets of resistance, but in general, the consensus tends to support the objectives. That said, even within a broad consensus, it is common for low-level disagreements to derail material progress.

Monty Python illustrated this phenomenon in The Life of Brian where various groups, ostensibly with aligned interests, wanted to free themselves from Roman occupation. They end up falling out on how to achieve this, rather than working together. This concludes with the various groups fighting with each other, while a group of bemused Roman soldiers watch on. It's far funnier on screen than in writing!

It is critical that you always focus on the fundamental requirements, rather than digress too early into the potential solutions or diversions to the overarching strategy.

In our experience, it is common for individuals or groups to bring problems to the table. The skill in managing a large-scale DevOps adoption is to distinguish between those items which are fundamental and need to be resolved, and those items which are tactical problems for specific individuals.

Fundamental Issues

For example: To enable continuous delivery it is fundamental to clearly articulate approval points in the process that require validation and recording to provide an audit trail of due process. The number of points and stringency of the validation will depend to a large extent on the industry you operate in. Certainly, in some industries, the regulatory considerations will be far greater than in others, such as financial services. A requirement such as this would need to be driven centrally as a separate initiative. It is likely to involve core stakeholders from teams such as business risk, change management, quality, audit, process excellence and of course product teams. In all cases, as per our initial blog, we recommend you start by defining the current process. From our experience, an effective beginning point is to start by defining the requirements in the process, rather than the current solutions, then compare the requirements to the extant process. We shall cover this in more detail in a later post.

Tactical Issues

Now we consider the tactical problem: These are local issues raised by specific teams, often items which have been on their too-hard-to-resolve-pile for a period of time. There is a temptation for these to be raised as issues, or even blockers, at an early stage of the process. It is very easy for the early stages of a programme to become the repository of everybody's pain points. There is value in a central repository of issues; if nothing else, you are likely to surface common problems that were previously hidden. The risk is that rather than focus on fundamental challenges, you become distracted by chasing a multitude of lower-level issues which, while individually important, are not fundamental to your overall strategy. It is critical to use your experience to avoid spending excess time on "noise" to the detriment of overall success.

"Give a man a fish and you feed him for a day; teach him to fish and you feed him for a lifetime."

A key tenet of DevOps is the promotion of self-sufficiency and autonomy. This culture needs to become embedded within the organization and individuals should be empowered and encouraged to resolve issues. The role of any central team is to act as enablers to this and to assist in removing roadblocks. We recommend that this is borne in mind when local issues or roadblocks are brought to you. As noted above, you need to resolve those issues which are institutionally critical. However, you will add far more value if you assist others to help themselves to solve specific problems. It provides the dual benefit of enabling a focus on core problems to assist the full community while also building up skills and confidence in the wider community as they resolve their own issues.

Follow the series from Sacha and Nigel:

  1. Enterprise DevOps: An Introduction
  2. Enterprise DevOps: I Wouldn't Start from Here: Understand Your DevOps Starting Point
  3. Enterprise DevOps: Context is King
  4. Enterprise DevOps: Creating a Service Line
  5. Enterprise DevOps: On Governance
  6. Enterprise DevOps: The Spine is Critical
  7. Enterprise DevOps: Move to Self-Service
  8. Enterprise DevOps: The Peoples' Front of Judea, or Don't Sweat the Small Stuff (this post)

Published at DZone with permission of Sacha Labourey , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}