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 Enterprise DevOps blog series from Sacha and Nigel
Enterprise DevOps: I Wouldn't Start from Here: Understand Your DevOps Starting Point
Enterprise DevOps: The Peoples' Front of Judea, or Don't Sweat the Small Stuff (this post)
Enterprise DevOps: 13 Principles of Meaningful Metrics Measurement, Part 1
Enterprise DevOps: 4 Further Considerations for Metrics Measurement, Part 2
About the Authors
Sacha Labourey
Sacha is a native of Switzerland and graduated in 1999 from EPFL. While at EPFL, he started his first consulting business - Cogito Informatique. In 2001, he joined Marc Fleury’s JBoss project as a core contributor, and implemented JBoss’ original clustering features. Sacha went on to become GM for JBoss Europe. In this role, he led the strategy and helped to recruit the partners that fueled the company’s growth in that region. In 2005, he was appointed CTO, overseeing all of JBoss engineering.
In June 2006, JBoss was acquired by Red Hat (NYSE:RHT). As CTO, Sacha played a crucial role in integrating and productizing the JBoss software with Red Hat offerings. In 2007, Sacha became co-General Manager of Red Hat’s middleware division. He left Red Hat in 2009 and founded CloudBees in March 2010.
Nigel Willie
With over 20 years’ experience working in IT for one of the world’s largest financial institutions, Nigel has experience managing and delivering global transformation programs. Starting his career as a developer, Nigel’s most recent role was to deliver cross-platform DevOps automation capabilities to the enterprise.
From his experience, he understands many of the challenges and mistakes involved; indeed, he claims to have made most of the mistakes himself. Nigel has also had the good fortune to work with a lot of highly skilled individuals, both as colleagues and across the industry. He is attempting to share some of his personal observations and thoughts in the hope they will be of value to others. Nigel is a great believer that every initiative is individual and any observations he makes are intended as principles or guidelines, not rules.