Six tips for devops success from DevOps Enterprise Summit 2016

‘Devops’ has just about evolved away from buzzword territory and is now a strategy most businesses should be thinking about to improve their testing and delivery times in production. Here are some tips from businesses that have seen positive results.


A loose definition of ‘devops’ – short for development and operations – is a cultural shift that brings together previously siloed teams under one umbrella, collaborating with a mutual goal in mind, and aided by technology such as automation.

The consumerisation of IT means both consumers and businesses expect software products as soon as possible – red tape-laden testing phases that take weeks or months to deliver are out of the question.

Image: Flickr Creative Commons/Ben Simo
Image: Flickr Creative Commons/Ben Simo

See also: Devops explained: why culture is key to devops success

How can businesses use devops to speed up their deployment and testing? According to major players in finance, on the high street, and in software, there are plenty of things your organisation can do to help. Read on for some of them.

Seek forgiveness

According to Mark Howell, digital devops lead at Lloyds Banking Group, sometimes it’s just easier to seek forgiveness once you’ve begun the project and started to see results. “I can draw the pipeline of what devops is, before devops arrives,” he said, speaking at the sponsor track. “Breaking it into chunks and small pieces that I can influence, and then build up the picture. In our large organisation we’ve got hundreds of developers and we don’t transform them overnight – so pick the small bits of what would be the old, manual pipeline and start transforming pieces and bringing them together gradually.”

“We sought forgiveness over the sort of things we were doing – we’re a large corporate, we have very strict rules about the types of kit we can use, the types of software we can use,” Howell said. “Sometimes you need to bend the rules a little to show people what good looks like. And that’s when you build momentum: I have support from our senior leaders within the bank and they’re good technologists as well, so they’re great people to go and show – and say, this is what good could really look like.”

Change your name

Director of systems strategy at Disney Jason Cox found that when his department changed their official titles, they started to notice a difference in how other teams approached them.

Suddenly the other teams didn’t view them just as operators, but as fellow engineers.

“The profound impact was how we viewed ourselves,” he said. “As systems engineers, we were no longer those who were operating the train, we were builders: building the track, the bridges, the locomotive, becoming part of the factory itself, along with the development teams.”

Prepare for organisational change

Ticketmaster’s Justin Dean, SVP of platform and technical operations, noted that there will be “substantial organisational change” for any business that’s taking devops seriously. “We got serious enough to make pretty substantial org changes – it’s going to be a sensitive topic, but in my opinion, if you’re going to do this for real, there’s going to be organisational changes coming,” he said.

The ticketing business moved primary on-sale support directly into the product teams – getting the latter well connected into how the business is running and performing, as well as making sure they’ve got everything in their roadmap to make those processes better.

“We moved our application support teams out of tech-ops into the product teams they support directly,” Dean said. “The team that operates our core ticketing system used to be in ops, and you had that huge wall. So we moved that team directly into the product team and instantly devops’d it – I use that jokingly, but it did remove 90 percent of the friction immediately.”

“You had this wall – all of that is just gone. And now they have a shared vision of what is going to work, not ops protecting them from themselves.”

The company also changed expectations around systems engineering, and what that means – from the team that others asked for things, into being embedded directly into product teams.

“They are the people that help product teams with scalability, reliability, deployability, repeatability – they are an advisor sitting in the passenger seat, not the driver’s seat. It is a huge fundamental shift.”

Buoys not boundaries

“We didn’t think we should prescribe a particular pipeline,” said Rafael Garcia, director of R&D IT at HPE. “But we understand that also means you can’t leave it to chaos. So we came up with this concept of buoys, not boundaries – we established a series of vetted pipelines that are very well tested and very easy to consume. If the team doesn’t know what they want to do in order to create a pipeline, they can leverage this very easily from a central service.”

“If they do want to explore, though, they’re buoys, not solid boundaries – you can go explore,” Garcia explained. “That’s critical in the devops world, because the world is changing constantly. If you’re worried about some kind of central team doing some kind of assessment that takes nine months, by the time they’re done assessing, the new tool is already out. You need to give your team the ability to explore.”

Configure the tools to work for the product

According to Unilever’s VP for information and analytics Kjersten Moody, organisations should take the time to properly consider and configure the tools they’re using, rather than just bringing in the technology as a kind of panacea.

“It’s not just bringing in the tools – it’s configuring the tools to work for the product,” Moody said. “You can bring in a tool, but if you don’t have the right template, and you haven’t thought about the workflow of how code and people need to interact with the system, you’re not really doing it, I would argue.”

Disasters are opportunities

Lee Sexton, who is the head of devops at high-street travel agents Thomas Cook, said during a Q&A that a positive way to get the journey started is when a business is dealing with a “real bad p1 instance” – in other words, a major incident in the running of an organisation that’s the top priority to fix, ASAP.

“It sounds really wrong, but the way to get the journey started is when they’ve got a real bad p1 instance –they’re normally running around panicking, they don’t know how to get the right monitoring out on it,” Sexton said. “That’s a great place to go: I’ve got an idea. And they’ll go: ‘Wow, you did that in five minutes’. Yes.”

“It is true that with most companies they’re not willing to make a change until they’ve got a problem,” he explained. “You just need to make sure you’re in the right place at the right time for that problem.”

"Recommended For You"

Devops explained: Why culture is key to devops success How Capital One went from one agile team to enterprise-wide devops