DevOps.com

  • Latest
    • Articles
    • Features
    • Most Read
    • News
    • News Releases
  • Topics
    • AI
    • Continuous Delivery
    • Continuous Testing
    • Cloud
    • Culture
    • DevSecOps
    • Enterprise DevOps
    • Leadership Suite
    • DevOps Practice
    • ROELBOB
    • DevOps Toolbox
    • IT as Code
  • Videos/Podcasts
    • DevOps Chats
    • DevOps Unbound
  • Webinars
    • Upcoming
    • On-Demand Webinars
  • Library
  • Events
    • Upcoming Events
    • On-Demand Events
  • Sponsored Communities
    • AWS Community Hub
    • CloudBees
    • IT as Code
    • Rocket on DevOps.com
    • Traceable on DevOps.com
    • Quali on DevOps.com
  • Related Sites
    • Techstrong Group
    • Container Journal
    • Security Boulevard
    • Techstrong Research
    • DevOps Chat
    • DevOps Dozen
    • DevOps TV
    • Digital Anarchist
  • Media Kit
  • About
  • AI
  • Cloud
  • Continuous Delivery
  • Continuous Testing
  • DevSecOps
  • Leadership Suite
  • Practices
  • ROELBOB
  • Low-Code/No-Code
  • IT as Code
  • More Topics
    • Application Performance Management/Monitoring
    • Culture
    • Enterprise DevOps

Home » Features » DevOps Abandonment: Reasons Not to Give Up

DevOps Abandonment

DevOps Abandonment: Reasons Not to Give Up

By: Don Macvittie on August 15, 2018 1 Comment

The Never-Ending Story

Recent Posts By Don Macvittie
  • Is Your Future in SaaS? Yes, Except …
  • Update Those Ops Tools, Too
  • Why We Still Need Specialists
More from Don Macvittie
Related Posts
  • DevOps Abandonment: Reasons Not to Give Up
  • What Donuts Teach Us About DevOps and Delivery Risk
  • SRE Vs. DevOps: The Wrong Question?
    Related Categories
  • Blogs
  • Features
  • Leadership Suite
    Related Topics
  • DevOps failures
  • pilot
  • pitfalls
Show more
Show less

When a new process or methodology comes along—particularly when one gets a lot of attention like DevOps has—there always will be failures. I’m not talking about those always-present group of people who say they’ve seen this cycle before and, thus, it is just a fad; I’m talking about actual implementers who, in the end, come up empty-handed.

DevOps is no exception. In fact, because it radically changes much about IT, it probably has a higher rate of this problem than most new methodologies.

DevOps/Cloud-Native Live! Boston

The end result is easy enough to identify: Either an organization abandons DevOps altogether or shunts it off into that area where other processes and technologies have been implemented by only one team and eventually die.

Problem Children

In almost every case of DevOps failure, people are the problem. That is not to say people purposely undermine the system, but IT is built, managed and run by people. And the breadth of people in an organization has immense influence on the success or failure of DevOps (or any other IT initiative).

With that said, let’s look at some problems that contribute to DevOps abandonment organizations should avoid in their attempts to evaluate/implement DevOps.

Team Isolation

It is a standard enterprise reaction to split off a team to look at a new technology/process and isolate them from the rest of IT. I was the first hire in a “New IT” at an organization—it was weird to have rooms of cubicles filled with people I was not allowed to talk to. One of several keys to success in DevOps is communication, and no application or application portfolio works in a vacuum. The need to discuss server space, security, routing and a host of other topics with core IT means isolation will not work. It is one thing to clear the pilot team’s workload to allow them to focus on assessing DevOps for the organization, but it is quite another to isolate them (functionally, geographically, whatever). If they find some quick-hit streamlining opportunities in standard operations, don’t you want those shared with the wider IT department?

Getting the Tools Side Right, but Missing the Culture Side

I make no secret about the fact that I’m a bigger fan of the automation side of DevOps than the culture side. But sooner or later, all the whiz-bang tools are deployed, and culture becomes the main focus. That includes not only communications between different parts of the DevOps team, but also the “can jump in and do” mentality that is more prevalent in DevOps than in a more divided IT environment. Getting the culture and communications down early is important for success. And success is important for wider gains in IT’s ability to meet the demands of the business.

Adding to the Workload of Overloaded Team Members

This is perhaps the most common pitfall that causes organizations to leave DevOps or minimize their exposure to DevOps practices. DevOps holds the promise of increased productivity and decreased backlog. But it is a promise. Implementing tools and forging new relationships and new paths of communication … these things take time. And that time is added to existing workloads, unless steps are taken to lighten existing workloads.

The team working 10 to 12 hours a day just keeping the lights on will not side-track into anything that requires a definite investment of more man-hours unless it is mandated to them by the business. Asking them to start working on it is a recipe for failure; the best you can hope for is some automation that makes their life easier in some other way.

Not Managing/Meeting the Expectations of Various Leaders

What line of business (LoB) leaders and the CIO expect out of DevOps are different things. While vaguely similar—increased responsiveness to business needs is normally 100 percent shared—the details show different concerns.

It is up to the CIO to manage what those under him in IT expect/demand from DevOps, and what those peers in the line of business expect from it. There is no reduction in commitment from LoB teams—indeed, one could argue there is an increase, as IT is no longer the bottleneck. And, perhaps most importantly for some organizations, DevOps doesn’t make IT mind readers any more than previous new methodologies did. The LoB still must define what is needed and get requirements into IT.

Trying or Retrying DevOps? A Few Tips

Pilot

Run a pilot project. Lighten the load of the project team so members can focus on DevOps and bring its value into the team. Do not isolate them in any way. Including other teams by asking for help/ideas should be encouraged. In fact, if the pilot team is motivated and enjoying the pilot, this type of interaction can help smooth the way for extension of DevOps to the wider organization.

Use Existing Resources/Management

Don’t bring in specialists to do DevOps. DevOps can be learned, and there are a ton of resources available, so use people who know your environment and can apply standardized tools and practices to it. That includes management. The last thing an organization should have in a pilot is a manager that knows DevOps but not the relationships within and special quirks of your organization—both technical and social.

Pick Your Pilot Carefully

Pilot a project that is relatively small but is visible to the organization. Actively manage expectations, and see where DevOps takes you.

Rethink Everything

Empower the team to look critically at every single process/workflow and see where the most gain can be had. DevOps is not a switch; prioritizing high-value/important items for change in this iteration and lower-value items for future iterations is part of the process. But if you don’t look at everything, you can’t guarantee you’re getting the most bang for your buck on this—or any—iteration.

Clearly Communicate Goals/Changes

Make sure everyone in IT and out understands what the pilot is testing. Is it increased time to market? Is it ability to apply tools and processes to intractable sub-projects? Is it a test of the benefits touted by talking heads? Communicate what you are measuring and how you’re measuring it. If possible, share a dashboard showing those measurements with everyone who cares to follow along.

This Time is Different

DevOps is different from any other new methodology that has gained traction for the operations side. Ever. I’d say it was different than any other new methodology at all, but Agile is the precursor to DevOps on the Dev side, and they share a lot. It challenges decades-old thoughts on the best way to do things. It will fail sometimes, for a variety of reasons. Give it the best chance for success that you can, don’t tie the pilot team’s hands and use it where it succeeds, even if it doesn’t include every project in the portfolio.

In the end, if it really does help the business succeed, then—like it or not—it is the right tool for the job.

— Don Macvittie

Filed Under: Blogs, Features, Leadership Suite Tagged With: DevOps failures, pilot, pitfalls

Sponsored Content
Featured eBook
The 101 of Continuous Software Delivery

The 101 of Continuous Software Delivery

Now, more than ever, companies who rapidly react to changing market conditions and customer behavior will have a competitive edge.  Innovation-driven response is successful not only when a company has new ideas, but also when the software needed to implement them is delivered quickly. Companies who have weathered recent events ... Read More
« The Magic Quadrants
When AI Met DevOps: Machine Teaching »

TechStrong TV – Live

Click full-screen to enable volume control
Watch latest episodes and shows

Upcoming Webinars

Get Infrastructure Transparency and Improve Your Developers’ Experience in the Process
Thursday, May 19, 2022 - 3:00 pm EDT
Accelerating Continuous Security With Value Stream Management
Monday, May 23, 2022 - 11:00 am EDT
The Complete Guide to Open Source Licenses 2022
Monday, May 23, 2022 - 3:00 pm EDT

Latest from DevOps.com

DevOps Institute Releases Upskilling IT 2022 Report 
May 18, 2022 | Natan Solomon
Creating Automated GitHub Bots in Go
May 18, 2022 | Sebastian Spaink
Is Your Future in SaaS? Yes, Except …
May 18, 2022 | Don Macvittie
Apple Allows 50% Fee Rise | @ElonMusk Fans: 70% Fake | Microsoft Salaries up by 100%?
May 17, 2022 | Richi Jennings
Making DevOps Smoother
May 17, 2022 | Gaurav Belani

Get The Top Stories of the Week

  • View DevOps.com Privacy Policy
  • This field is for validation purposes and should be left unchanged.

Download Free eBook

Hybrid Cloud Security 101
New call-to-action

Most Read on DevOps.com

How Waterfall Methodologies Stifle Enterprise Agility
May 12, 2022 | Jordy Dekker
Top 3 Requirements for Next-Gen ML Tools
May 13, 2022 | Jervis Hui
Progress Expands Scope of Compliance-as-Code Capabilities
May 12, 2022 | Mike Vizard
15 Ways Software Becomes a Cyberthreat
May 13, 2022 | Anas Baig
Why Over-Permissive CI/CD Pipelines are an Unnecessary Evil
May 16, 2022 | Vladi Sandler

On-Demand Webinars

DevOps.com Webinar ReplaysDevOps.com Webinar Replays
  • Home
  • About DevOps.com
  • Meet our Authors
  • Write for DevOps.com
  • Media Kit
  • Sponsor Info
  • Copyright
  • TOS
  • Privacy Policy

Powered by Techstrong Group, Inc.

© 2022 ·Techstrong Group, Inc.All rights reserved.