DevOps Summit: The importance of culture to implementing DevOps - from the board to the IT team
'It's not in the interests of outsourcing companies to have teams talking to each other and working efficiently'
DevOps is being driven by IT departments' needs to churn out applications and updates faster than ever - and the best way to introduce DevOps to any organisation is to get people in who have done it before, if you can find them.
That was the message from the final panel discussion at Computing's DevOps Summit 2015. "If you ask the business, it's about getting changes into production fast... They don't care how you get there, it's the end result that counts," said Jonathan Fletcher, technology and platform lead at insurance company Hiscox.
Fletcher was responding to questions about developing a DevOps culture within IT teams, and selling the business case for DevOps to sceptical corporate boards.
For Jonny Wooldridge, chief technology officer at The Cambridge Satchel Company, selling the business case to the board was easier than persuading ordinary staff of the need for change.
"I'm quite lucky to have quite an enlightened CEO and CIO, who are ambitious and open to suggestions... It wasn't a difficult sell in terms of the higher IT leaders. The difficulties were on the ground floor, with people who have been building stuff a certain way for 30 years, asking: 'Why are you telling me now how to do my job?'" said Wooldridge.
But introducing DevOps doesn't just require the board to be convinced but, often, IT staff too, who will invariably have changes in working practices thrust upon them.
Start small
Fletcher suggested starting small, demonstrating success - with the appropriate metrics to back it up - and then instead of having to pull the organisation along, people will want to be part of it.
"Demonstrate success: start with something small that you can influence. Get that, make it better, capture the before and after metrics, and then sell it... we were lucky that we could do it on the biggest change programme we've ever done. We got some amazing benefits and that changed everything in IT," said Fletcher. Instead of resisting change, people welcome it and wanted to be part of it, he added.
At retail giant Marks & Spencer, said Wooldridge, a team of some 50 engineers were recruited to develop apps using a DevOps methodology. "While I was at M&S we built a team of about 50 engineers," said Wooldridge. "Rather than train everyone up, we injected a few specialists who had already done it - a couple of those people in every team to get it working."
The success of one project helped it to gain momentum - with potential friction from, perhaps, one unexpected source. "All these outsourced companies, it wasn't in their best interests to actually be efficient and have the teams talking together. That's the worst possible thing that could happen to them," added Wooldridge.
As a result, he added: "I spent most of my time drinking coffee and talking to people."
DevOps in name only
However, warned Chris Dunne, senior technical manager at performance management monitoring company New Relic, many DevOps teams are DevOps in name only. "I go into lots of organisations that say 'we are the DevOps team', but actually they are the Ops team and just sit together with Dev in the same room," said Dunne.
For them to properly work together requires more than that: maximum automation of technical processes and insight supported by metrics about what is happening in the application, on the server its running on and on the network.
"If people don't know or can't see what's happening in their applications, it breeds a mutual resentment whereby Dev feels it's Ops' fault and Ops feels it's Dev's fault," said Dunne. "But when it's clear to see where the problem is - you can clearly see it's an infrastructure issue, for example, and they can pull together to fix it."