The best laid plans of DevOps adopters often go awry. Here's how you can fix things.

John Edwards, Technology Journalist & Author

June 14, 2018

5 Min Read
Image: Pixabay

DevOps encompasses a set of practices that automate and streamline processes between software development and IT teams, enabling organizations to build, test, and release software faster and more reliably.

That's the goal, anyway. But what happens when a DevOps initiative doesn't meet an organization's anticipated goals or, worse yet, actually begins exerting a negative impact on software development?

That's when it's time to go back to the virtual drawing board and steer the initiative back onto its planned course. "Easy to spot warning signs include the team being constantly stressed about deployments, bugs only appearing in production, the team being scared to change code because of how critical it is, and finger pointing when collaboration breaks down," said Brian White, senior solutions architect at software development tools supplier Small Footprint.

"If you start to notice that your system, processes or workflow on technical teams seems to be increasing, this is an early warning sign that your DevOps initiatives are failing," added Collin Meadows, vice president of engineering and technology at security services provider Terbium Labs. "If engineers are having more trouble deploying code, making updates, spinning up servers or any other engineering task due to your DevOps practices, then it is time to revisit what those practices were put in place for and how to change them to make things less complex."

Brian_White_Small_Footprint.jpg


Here are five basic ways to put a failing DevOps initiative back on course:

Step 1. Get to the heart of the problem

Most failing DevOps initiatives have one or more deeply rooted problems, typically related to a particular technology or skill. Time should be set aside to evaluate what's not working and how things can be fixed. Also make sure that everyone shares the same vision, goals, and ideals. "Find people that can work alongside the team helping and at the same time training the team to be self-sufficient," White advised.

Team members may also feel overwhelmed by the project's size and scope. "It’s important for IT leaders not to approach application development as monolithic projects. Rather they should be broken down into smaller microservices that can be maintained by a single DevOps team," observed Jasper van der Hoek, enterprise architect at application tools developer Mendix.

JaspervanderHoek_mendix.jpg

Step 2. Resolve internal dissention

Some DevOps initiatives fail simply because organizations are unable to get everyone on board. "People hate change, whether it’s due to fear, uncertainly, doubt, inherency or accretion," noted Robert Reeves, co-founder and CTO of software development tools provider Datical. Too often, departments and staff flee from change or have it forced upon them. "That's inherently bad, forcing (DevOps proponents) into reacting to, instead of being the harbingers of change," he added.

Van der Hoek recommended calming fears by focusing on culture and ideology. "Work closely with the team to enable them in all their initiatives," he urged. "This will allow them to own the processes and products that they work on, making them more willing to focus on both the development and operations side of the process."

Davy_Hua_shiftleft.jpg

Step 3.Check the metrics

Track and plot every part of the initiative that's capable of producing a metric. "This will allow you to see which part of the DevOps effort is deviating; then take extra precautions to help nudge it back on track," explained Davy Hua, head of DevOps security software developer ShiftLeft. Throwing more resources into the initiative without having reliable objectives and key results (OKRs) to track, and a clear understanding of what exactly it is failing, is a mistake, he added.

Rashad_Neloms.jpg

Step 4. Restate the initiative

Clearly restate the "why" of the initiative. "Everyone needs to have a clear line of sight to "why” (DevOps) will make the company better and how," observed Rashad Neloms, vice president of technology and strategy for DevOps consultant Forty8Fifty Labs. "Get people to invest back into that first, then they can begin to see how to contribute to the success and point out where to gain more traction both process- and business-wise."

Ed_Price_devbridge.jpg

 Step 5. Assert leadership

"When DevOps initiatives fail to live up to expectations, it's typically because business and technology leadership doesn’t have the trust in their teams to deliver quality software and allow automation to do its job," noted Ed Price, director of compliance at mission-critical software developer Devbridge Group.

Antony_Edwards_eggplant.jpg

"You need a leader who is able to work with people and cross-functionally," added Antony Edwards, CTO of digital automation intelligence software and service provider Eggplant. It's also important for the leader to clearly define DevOps objectives. "If there is no clear, agreed goal, then you’ll never get people to agree what (to) do."

Leadership is necessary across the project, not just at its top. "There should be champions in each team that will push the effort along some of the most difficult and painful transformational periods," ShiftLeft's Hua explained.

 For more on DevOps, check out these recent articles:

Why DevOps Is Your Key to Becoming a Digital Entity

Rethink Change Management for Agile Initiatives

Data, DevOps, and the Rest of the Business

DevOps at Scale: Best Practices in Use Today

 

About the Author(s)

John Edwards

Technology Journalist & Author

John Edwards is a veteran business technology journalist. His work has appeared in The New York Times, The Washington Post, and numerous business and technology publications, including Computerworld, CFO Magazine, IBM Data Management Magazine, RFID Journal, and Electronic Design. He has also written columns for The Economist's Business Intelligence Unit and PricewaterhouseCoopers' Communications Direct. John has authored several books on business technology topics. His work began appearing online as early as 1983. Throughout the 1980s and 90s, he wrote daily news and feature articles for both the CompuServe and Prodigy online services. His "Behind the Screens" commentaries made him the world's first known professional blogger.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights