Three Recommendations to Drive Successful DevOps

Lingaro Strategic Advisor Andy Walter recently wrote a very informative article on driving digital transformations. We thought it was great for two reasons:

First, it gives a high-level perspective as to how Agile / DevOps – one of the core service offerings we bring to the table for enterprise clients – fits into an overall execution framework for a large organization undergoing a digital transformation.

Second, it was interesting to see how universal the principles Andy highlights are, even at the nuts-and-bolts level of our own DevOps methodology.

In this article, we're going to give a few recommendations as to how to incorporate three of these principles – strong leadership, combined technology and business expertise, and culture – into DevOps, based on our own experience serving Fortune Global 500 companies.

But first, some quick background on why DevOps can be so challenging in the first place:

DevOps is often fragmented by technical specialities.

In DevOps, as the term suggests, development and operations are supposed to be joined. Many DevOps organizational structures, however, are divided by technology competencies.

Depending on the technical expertise required for a given solution, specialists from various technology silos are supposed to come together to develop it. And then a different collection of technical specialists are supposed to support it.

With this approach, communication between all the various “factions” becomes a challenge and execution speed suffers. For starters, it is not always so obvious which technical expertise is required by a business user making an operations support request.

Ultimately, developers aim to ship projects with little regard for how they will be supported long-term, and support teams lack the in-depth knowledge of a solution that comes from building it.

At Lingaro we are taking a different approach.

Lingaro DevOps team members are allied around each solution.

Instead of organizing around technical specialities, at Lingaro we organize around the solution itself. In the early stages of the engagement, we put technically experienced team members (the "seniors") on the project with backup from newer staff in the process of skilling up (the "juniors").

They are segregated by level of expertise but not by individual technologies or the functions of development or operations.

You can think of the solution-based setup as a single structure -- a pyramid let's say -- with the team supporting two sides: development and operations.

This image represents a so-called "vertical start," where our technical experts are doing most of the development work, which accounts for most of the overall work involved at this point.

As the engagement progresses, the structure of the DevOps team evolves thanks to the following three processes:

1) A few seniors -- typically with the most relevant skill sets as discovered during the heavy development phase -- emerge as solution experts. Other seniors cycle out to other projects.

2) Juniors gain further experience and take on wider responsibilities as "mids." Newer juniors cycle in as necessary.

3) The entire team continuously simplifies the solution and adds to knowledge frameworks, documentation of best practices, and automation wherever possible.

At the mature stage of the project, the DevOps pyramid therefore looks as follows:

Here,

- new team members have a shorter learning curve thanks to frameworks and detailed documentation,

- seniors can devote themselves efficiently to the most complex tasks, and

- automation and ever greater solution simplicity drives down task completion times with less manual intervention required.

For businesses, the key benefits at this stage are:

1) Higher-quality changes and significantly decreased time to market. The model supports a streamlined software development cycle with frequent, small changes that often automated and pre-tested and always easy to control. A development cycle based on delivering larger changes is far riskier, as a failed change could lead to a serious business interruption.

2) Faster incident resolution. Each solution has a dedicated, highly engaged DevOps team -- which includes original developers -- supporting it through its entire lifecycle.

And that’s a short introduction to the theory behind our DevOps.

But how can you bring something like that together in practice?To ensure that all the processes run smoothly between a vertical start and maturity? How do we execute on our end so that our clients can execute on theirs?

Here are some DevOps recommendations that tie in nicely with the principles that Andy highlighted:

Leadership – Empower DevOps leaders to make talent judgment calls.

Based on our experience, good DevOps has two main ingredients: good people – who know a lot about everything to do with a particular solution, as opposed to one particular technical aspect of a solution – and shared incentives. And it takes good leadership to bring the two together.

As described above, our DevOps teams are always evolving. Initially in terms of the team composition itself and then in terms of the frameworks they use and the automation they incorporate. To guide that evolution, leaders need room to operate. They need to be able to identify individual strengths and delegate roles to make the team, as a whole, stronger.

Technology and business expertise – Incorporate business know-how into your DevOps processes. (Even if you’re a tech company.)

There’s an old saying that when you have a hammer, every problem looks like a nail.

And as a technology solutions partner, we know how tempting it is to view DevOps as an entirely technical exercise.

The problem with that approach is that DevOps is not about technology for our clients. It is about business. Users may or may not be familiar with the technology that powers the tools they use in their day-to-day jobs. But they can always articulate exactly their business needs and describe how the tool helps meet them. And to get the job done right, DevOps teams need to speak this language.

Accordingly, the DevOps documentation our teams develop for each supported solution include detailed descriptions not just of the technology involved but also the business functions it provides.

Culture – Build a DevOps culture of long-term ownership.

Constantly shifting priorities are a problem for even the most talented DevOps team members. With no culture of long-term ownership, they will find a clever way to put out a fire today, but they’ll be putting out a different one tomorrow, and another the day after. It’s only a question of time before today’s fire pops up again.

Therefore, don’t cause their priorities to shift! Have them build an application with the knowledge that they will have to support it after launch. And have them support the application with the knowledge they gained during its development. This way, fires get put out – and they stay out.

At Lingaro, one of our key DevOps goals is never to see the same issue twice. We try to find the underlying cause for any support ticket and fix it for good, ideally with an automated solution.

And there you have a few DevOps-specific recommendations based on the broader digital transformation principles from Andy Walter’s article. Be sure to check it out if you haven’t already, and get in touch with Andy or myself you have any questions about Lingaro DevOps.