Understanding DevOps opponents on stakeholder level beyond typical examples

Question

What are typical stakeholders and their reasons not to support/enable DevOps principles?*

Background: in small to medium organizations, certain level of DevOps is not a very big problem due to thinner silos and faster communications paths.

But how do you do DevOps at large organizational scales and which groups of stakeholders do you deal with?

I can think of these typical examples:

• Developers, either junior or more experienced who would like to "just do their job they are paid for - establishing software solutions and coding them"

• Management/Deciders concentrating on the service aspect in terms of man-months, where you find out a thing like a toolchain is non-existent to them: they recognize people doing their work on computers, not more.

Others?

• (And how can DevOps be a benefit to them? - as a side thought to be separate question, "how can DevOps be a benefit to stakeholder group X?")

Answer 1

People resist change, particularly when it's perceived to be outside of their control. Organizations that have been around a while naturally devolve into silos, and organizational structures often reflect that (e.g., database administration teams often manage all of the databases for the org, even though they are often distanced from the business purpose of those databases). DevOps has the potential to disrupt silos, and may cause realignment of org structures. For example, you could have product teams composed of developers and operations people (like DBA's) that focus solely on a single product.

For some mid-level managers, that could threaten their sense of job security. The benefit of a DevOps mindset is that it encourages everyone to understand the value stream to the customer, and the relationship of all the roles in delivering that value. IT could mean that the manager of DBA's suddenly has to understand development processes because they're now managing a product team.

Answer 2

DevOps fundamentally is an arbitrage play: it exploits the idea that if the things you are developing and operating are known to be stateless and immutable and ephemeral you can move very quickly, because there are a bunch of things you just don't need to do. And this is true, you can, and you don't.

But "traditional" IT is all about managing statefulness and controlling the transitions between states (or "mutation" if you prefer). A database server, a file server. A database server for example: once you have made changes to a schema and data has gone in, you can no longer "roll back" because you probably have nowhere you can put that data that satisfies the constraints of all the stakeholders. If the database server goes down you can't just spin up a new one, it has to be exactly the same to the greatest extent possible, and you need to have a plan for resolving the deltas. DevOps doesn't really address this and even worse, the typical DevOps pitch includes some jabs at "traditional" IT for being slow and obsolete, without any acknowledgement that maybe there were reasons for things to be done the "old fashioned" way other than the practitioners being dinosaurs.

What that sounds like to a stakeholder is that DevOps people are willing to take risks with the company's most precious assets - customer records, accounts, inventory control, all the other things that typically reside in the stateful parts of the technology infrastructure. Therefore to work with and bring on board skeptics the very first thing you must do is convince them that you have mitigated all the risks of operating the stateful parts of the infrastructure in a DevOps fashion.

I will wager that some variation on this theme is the root cause of TSB's woes at the time of writing. They failed to exercise sufficient care with the stateful parts of their system.

Answer 3

At one point a higher level tools manager, asked to review/vote on a proposal for using a CI tool which would allow gradual elimination of long-lived branches and migration towards true CI methodology (i.e. Trunk-Based Development - TBD) for a large scale product line, opposed it. The stated reason was belief that it wouldn't scale to the very large team (1000+ developers) working on the product.

I may be wrong, but I got the feeling another reason behind the vote was fear of having his ranks (which included an army of sync-masters for driving the many, quite difficult branch merges) shrink - in TBD there wouldn't be any such branch merges for them to work on.

Answer 4

The biggest challenge I've encountered with people resisting the change is the reason of not seeing the value of it, or build automation in general. His idea was, we were our getting product(s) out the door, and on time. So why do we need to "create work" for ourselves, and take a developer off of working on a product. After 4 years since then I've finally got the owners on board with CI by capturing metrics on how much time is wasted copying files manually from bin folders to SVN for qa to copy from SVN to environments. This along with the overhead of managing what build is in what environment and other pitfalls of you are testing the wrong build etc. He has finally came around, but I think he feels that the time could be put to other tasks.