DevOps Culture Clash: Think Process - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
IoT
IT Leadership // IT Strategy
Commentary
10/14/2014
10:26 AM
Lori MacVittie
Lori MacVittie
Commentary
100%
0%

DevOps Culture Clash: Think Process

Even the most charismatic leader can't just tell people to change from a silo-based culture to DevOps. You have to gradually introduce new goals, one pilot project at a time.

I'm a fan of the "CAMS" approach to defining DevOps, which brings together the concepts of culture, automation, measurement, and sharing as a way to understand what DevOps is all about. What I'm not a fan of? Focusing on culture over all else.  

If DevOps is a cultural shift, something must initiate that shift, and that something must be powerful enough to change the practices, values, and goals of operations (across all of IT, but that's a topic for another day). Unfortunately, even the most charismatic team of consultants can't just walk into an organization, point out why its current silo-laden culture is broken, and tell people to change.

Well, they could, but it wouldn't do any good.

Changing a culture is a process that requires leaders to introduce new goals and incentivize practices that gradually shift values and attitudes toward the desired outcome. If you want to engender a culture of collaboration across longstanding IT silos, you can't just send a memo. Leaders must support initiatives that challenge the status quo.

[Here are 10 things we wish Apple would make happen in its next operating system: Mac OS X Yosemite: What's Missing?]

Leaders must also realize that change doesn't happen lock, stock, and barrel over a few weeks. That's akin to rip and replace, and it's never been a successful IT strategy. Ever. An IT leader does not set his people and organization up for failure by introducing unattainable goals. Saying all of IT will meet ambitious objectives for MTTR, error rates, and frequency of deployments by the end of the quarter is unreasonable.

Instead, focus on a single project. That's not only reasonable but is typically how any new technology or methodology is brought in to the enterprise -- through an initial "pilot" project. Select a venture that will benefit from automation and ops' collaboration with development teams to improve the overall deployment process and ensure it meets the desired measurements.

Assuming success, the pilot gets "rolled out" to other efforts, and so on, until the entire IT organization has embraced the changes, accepted the measurements, and the culture it embodies is established as the new normal.

A few more concepts: You can't change culture overnight, and when a bunch of engineers are involved, you also can't do it by appealing to "soft" outcomes. In a "society" like IT where culture may be defined as "the set of shared attitudes, values, goals, and practices that characterizes an institution or organization," change happens when you prove results.

Ultimately, the folks who have to meet goals are interested primarily in, well, meeting goals. That means showing what actions they need to take, and how to make results happen. They will necessarily focus on automation and programmability because those are the tools that will enable them to succeed -- and keep their jobs.

Culture is a byproduct of results.

Extending a DevOps approach to operations isn't going to happen overnight any more than agile was adopted overnight by development teams. Heck, agile adoption -- another cultural change -- is still not pervasive. Though most organizations have "gone agile," they have done so only for a portion of their projects.

DevOps is likewise going to "go DevOps" (yes, I said it, and I'll probably say it again in the future) for only a portion of projects initially. With hundreds (and often thousands) of applications needing deployment, an organization simply can't flick a switch and become DevOps. It takes time, and practitioners in the trenches need concrete direction to enable that cultural change.  

Is DevOps about culture? Yes. But it isn't about forcing a culture on an organization by implementing strict measurements and requiring absolute adherence to meeting them on Day 1. Cultural shifts take time, and they spread from person to person, group to group, project by project. As successes mount, more and more groups and projects will want "in" on the secret because they, too, are struggling under an increasing load of apps and services that the business needs now and consumers need fast. They want to become more efficient, better able to scale out to meet demand. DevOps makes that not only possible but probable.

Don't try to push a cultural change from the top down. Focus on empowering operations across all of IT to achieve goals, and your people will embrace sharing and collaboration and personify the cultural shift we all agree has to occur.

InformationWeek's new Must Reads is a compendium of our best recent coverage of project management. Learn why enterprises must adapt to the Agile approach, how to handle project members who aren't performing up to expectations, whether project management offices are worthwhile, and more. Get the new Project Management Must Reads issue today. (Free registration required.)

Lori MacVittie is the principal technical evangelist for cloud computing, cloud and application security, and application delivery and is responsible for education and evangelism across F5's entire product suite. MacVittie has extensive development and technical architecture ... View Full Bio
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Lorna Garey
100%
0%
Lorna Garey,
User Rank: Author
10/14/2014 | 4:25:15 PM
Lead, Don't Push
Success breeds success -- if a pilot works out well and one unit cuts time to deploy in half, with fewer errors, everyone is going to want in. It does seem, however, that the ops teams may need more of a nudge, especially if they're wary of having to learn to code. 
ChrisMurphy
100%
0%
ChrisMurphy,
User Rank: Author
10/14/2014 | 12:42:59 PM
Tools
At Interop New York earlier this month, I talked with a vendor executive who attended a few DevOps Days events, where he got pushback anytime he'd talk about tools. People wanted to stress it's all about culture, culture, culture. Certainly you need to get the culture right, but you also need this kind of practical, tactical view thta Lori brings.     
InformationWeek Is Getting an Upgrade!

Find out more about our plans to improve the look, functionality, and performance of the InformationWeek site in the coming months.

News
Remote Work Tops SF, NYC for Most High-Paying Job Openings
Jessica Davis, Senior Editor, Enterprise Apps,  7/20/2021
Slideshows
Blockchain Gets Real Across Industries
Lisa Morgan, Freelance Writer,  7/22/2021
Commentary
Seeking a Competitive Edge vs. Chasing Savings in the Cloud
Joao-Pierre S. Ruth, Senior Writer,  7/19/2021
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
Monitoring Critical Cloud Workloads Report
In this report, our experts will discuss how to advance your ability to monitor critical workloads as they move about the various cloud platforms in your company.
Slideshows
Flash Poll