Making better use of your DevOps rock stars

DevOps teams need to share the secrets of their successes before the methodology is rolled out, says Rob Vanstone of XebiaLabs

The introduction of DevOps in an organisation tends to follow a pattern similar to the familiar Gartner hype cycle. Early promise give rise to inflated expectations which inevitably lead to a fractious descent into the trough of disillusionment before, hopefully, lessons are learned and acted upon to bring real productivity.

In DevOps terms, the first step is often a sudden local increase in productivity in part of the technology department brought about by the introduction of CI/CD, followed by the automation of low hanging fruit and a doubling or tripling of the frequency of releases.

Suddenly you have a team of rock stars on your hands with egos to match. They are going to transform this dinosaur business into a sleek, modern, flexible and agile entity fit for the 21^st century.

Then, as the methodology is scaled up, the problems start. Some teams are resistant to having their operations disrupted, legacy applications prove hard to change, methodologies turnout to be less transferable than had been thought, automation actually results in more work, people leave, the compliance and security people start pushing back, and now you're back where you started, or worse.

Avoiding this scenario, or at least smoothing the curve to avoid hitting the ‘scalability wall', was the subject of a talk by Rob Vanstone, technical director UK at DevOps intelligence and automation vendor XebiaLabs, during Computing's DevOps Live event in Manchester on Tuesday.

There are four common factors that adversely affect DevOps and Agile transformations, Vanstone said: a ‘Waterfall' mindset across the business which is out of step with Agile; a tendency in management to prefer incremental change over transformation; a false sense of security among the rock stars; and low priority being given to QA and testing.

These issues are frequently only faced once the trough of disillusionment has been plumbed, but is there a shortcut to this organisational learning? Could, perhaps, the initial stage of creating a specialist DevOps team to tackle quick wins and demonstrate the potential of DevOps and Agile be bypassed "in favour of involving all teams and doing it properly from the off?" asked a member of the audience.

This depends very much on the leadership, said Vanstone.

"Winning breeds winning so I completely understand the pattern of the rock star team, but sometimes that rock star team becomes the new unicorn within its own organisation," he said.

Instead of having the DevOps team focused solely on creating highly visible success stories, they should be encouraged to share their knowledge at an early stage, Vanstone said.

"Implementing the change in other areas is the key thing to do here. If you don't do that you end up with another silo, the DevOps silo, so there needs to be a visible way of getting that information out. So there's certainly a role for showing off these poster children, showing it's not just the realm of the Amazons and Etsys but you really need the structure and leadership to make it work."

Above all, an engineering, problem-solving mind set needs to be promoted across the organisation, Vanstone said.

"Build, measure, learn. That's the mantra that works everywhere."