DevOps: It's an Ongoing Culture, Not a Project

More on DevOps
Live at Interop ITX

DevOps is a topic that everybody likes to talk about, and many are trying to do something about it. But it's a difficult conversion to make for IT shops steeped in the traditional methods of waterfall software development. Even those who have embraced DevOps principles may still find it difficult to get the results desired.

DevOps is more than a software methodology, an approach to a shared tool chain or finally putting somebody from operations on the development team. Rather, it's a big change in company culture, one that requires people to act as if they don't know there was once a boundary that set off the operations team from the development team or a database silo that was cordoned off from the storage silo and the security silo.

Andi Mann, Splunk

"If DevOps is about anything, it's about communications and sharing, collaboration and accountability to yourself and your team." said Andi Mann, chief technology advocate for the operational intelligence company Splunk. It's also about teams being accountable to each other and to the managers and executives of projects. Many companies are engaged in implementing DevOps and understand the basic concepts. But Mann said in an interview: "I don't see too many organizations being successful at a higher level" of coordinating and orchestrating DevOps teams as part of an overall company culture.

Mann will lead a session, Effective Leadership for DevOps Teams and Programs, at Interop ITX in Las Vegas May 17 from 3:20-4:20 p.m.  He won't be talking about agile programming or continuous integration so much as the change in attitude and culture required by DevOps and how executives and project managers need to provide leadership on the required changes.

Mann has been CTA at Splunk since August 2015. He was formerly a vice president in the office of the CTO at CA Technologies for five years, and a former analyst with Enterprise Management Associates, also for five years.

Want to learn more about the adoption of DevOps in the enterprise? Read DevOps Comes of Age.

Despite real advances in development and operations cooperation, DevOps can still fall short as managers try to identify bottlenecks, keep projects on track and on budget, coordinate one set of features with a set being developed by a different team, and correctly assigning limiting resources.

Both developers and project managers can conclude they're succeeding at DevOps without other stakeholders in the business either understanding how or agreeing with the conclusion. "At some point, you've got to be able to talk about the value of the project having an impact on the value of the business," Mann said.

But the chief culprit in preventing DevOps from living up to its potential is the way it up-ends the traditional way of determining software project value – say, number of lines of code produced, number of errors in those lines, whether the application materialized on schedule – without giving executives a firm view of what the new methods are achieving.

"From the management point of view, DevOps gets scary because you start to lose your accustomed measures of how the project is going," he said. If a big development team has been broken down into many small ones, with new members from operations and business stakeholders participating, what is a measure of success? What if a member of the security team is holding up a feature set because of concerns over how security has been addressed? Is that a plus or a minus? If security used to be addressed at the end of the project, some managers might come up with the wrong answer.

Mann plans to emphasize at his May 17 session that managers and executives have to collect data on the overall process and "turn DevOps into a data-driven environment. Team members explore and collaborate on the data instead of having an opinion-lead project," he said.

That is more easily said than done. With different specialties now pulled together on the same team, team members may not be using the same tools or looking at the same data. What's important is to collect the data that captures what work is being accomplished and examine everything that's known about it. Out of the collaborative effort, metrics will emerge that let each team member evaluate the project based on his own point of view.

"Everyone needs to know their role in an end-to-end process" that puts software into production use. "Everyone needs to be able to use the data to see what's going on in the system," he said.

That might be more likely to be achieved if developers who have previously sat as a separate organization are mixed in with stakeholders, operations staff, architects and security specialists working on the same part of a new application sitting in close proximity to each other. "Re-teaming is a really key aspect of DevOps," Mann noted.

"You might put the collaboration spaces in the most attractive places. What used to serve as an executive's corner-windows office should become a shared space, with the executive office moved into the center of the building," Mann suggested.

Such moves communicate a powerful message about what DevOps changes are trying to accomplish and how staff sitting in silo spaces must come out from behind the walls and collaborate.

A data driven environment spurs not just visibility and metrics but accountability by individual teams members, accountability of the different specialties represented in the team and in the end, accountability between teams and the executives trying to coordinate a project. But getting there can take a lot of scrum meetings and face and face discussions.

The ultimate measure of how well IT is implementing DevOps is not how quickly code goes into production or how easily its updated but how quickly a new business idea finds its support in business software and begins to impact the prospects of the company.

To get the answer to that, the DevOps-oriented IT staff has to not only have visibility into the progress of a project from many points of view but also good procedures for identifying something that's gone wrong and knowing what to do with the information. "When something goes wrong, how quickly can you fix an issue?" Mann asked.

While many DevOps sessions are focused on enlisting developer and operations staff enthusiasm with a bottoms up approach, Mann admits his is more of a top-down session on how to make coordinators of projects and executives better able to implement a wide ranging DevOps project. If the culture changes, if everyone agrees rapid software production and continuous integration are worthy goals, someone still has to take responsibility for see the parts fit together, stakeholders input their review, deployment is executed properly and security standards are maintained.

"You need to be able to get the data to be able to make the right decisions and be accountable to yourself, to your peers and to your executives," he said.