CIOREVIEW >> DevOps >>

The DevOps Culture Change Goes Way Beyond IT

Raman Sapra, VP & Global Leader, Dell Digital Business Services
Raman Sapra, VP & Global Leader, Dell Digital Business Services

Raman Sapra, VP & Global Leader, Dell Digital Business Services

DevOps got its name from its inclusion of IT Operations participants on application development teams.

That’s unfortunate, because Dev + Ops is not only what’s least interesting about DevOps, it’s also its most transient characteristic: Companies like Pivotal, RedHat and Chef are providing so much automation for provisioning, integration, isolation, and deployment, that Operations’ role in DevOps is shrinking on a daily basis.

What the name does hint at is that at its core DevOps isn’t about processes, or techniques, or tools.

Talk to anyone who’s been through the DevOps transformation and you’ll hear the same thing: Before it’s anything else, DevOps is a change in culture.

For those who have been through it, this change in culture is often so permeating that articulating just what it means can be difficult.

Start with a definition. While anthropologists have several definitions of culture, and consultants use the term in several different ways, in the end culture means “how we do things around here.” It’s the shared set of hidden assumptions, unwritten rules, and attitude about things that gives the word “we” some bite.

  ​DevOps culture can’t succeed in traditional businesses 

For DevOps teams, how we do things around here means:

► Collaboration – This was the first DevOps breakthrough. App Dev and IT Operations usually exist in a state of uneasy truce, with App Dev trying to change the production environment by promoting new code to production, and IT Operations trying to keep the production environment stable and prevent frequent changes. DevOps turned this hostile relationship into collaboration, and is now the most prominent element of the DevOps culture.

► Automation – The usual approach to business decision-making when it comes to automation is to perform some form of return-on-investment analysis, which presupposes that cost minimization is the be all and end all of process optimization. The DevOps way is to automate everything that can be automated, not to only automate everything whose automation passes a financial ROI hurdle. Everything. That’s because speed rules.

► Speed rules – DevOps is all about speed in both of its meanings – reducing cycle time and increasing throughput. It’s about each requested change producing value faster than before, and increasing IT’s overall capacity to deliver changes. Among DevOps devotees, cost-cutting is nice, but any false economies that slow a project down are off the table.

► Quality is more than the absence of bugs – Standard practice in App Dev teams is that quality is defined as bug-free code, a bug being software that doesn’t do what it’s supposed to do. Among DevOps developers, poorly structured code that violates good programming practices is low-quality code, whether or not it runs and yields the right results.

► Recognizing the exalted state of “good enough” Quality is one thing. Needless insistence on “just one more test” is something else entirely – a pointless nod to the timid that violates the speed-rules rule.

This DevOps culture can’t succeed in traditional businesses. It can’t because businesses that have these characteristics won’t let IT develop the DevOps way – for the rest of the business, the DevOps culture just isn’t how we do things around here, the way we do things around here including an intense emphasis on cost-cutting, excessive risk aversion, and organizational siloes with high walls and wide moats – the polar opposite of collaboration.

Which means companies that want IT to successfully implement DevOps will find themselves adopting equivalent cultural traits, in particular: The habit of collaboration, and all the silo-busting it implies; the automation of anything that can be automated, not mere process enablement; and speed ruling the business too.

And an additional point: In DevOps businesses, the culture reorients from slow and steady to quick and agile. DevOps businesses recognize that failing fast and failing forward is a competitive advantage – they recognize their own “exalted state of good enough,” which is the point where testing an idea is superior to analyzing it.

Speed might, in fact, literally rule the business, if executive suite strategists make the OODA loop (for “observe, orient, decide, act”) the centerpiece of business strategy. Even if it falls short of that, businesses with a DevOps culture will, at a minimum, replace “Has this reached the point where we have no choice” with “Is there any reason we can’t proceed?” as the trigger for important decisions and actions.

Business managers that insist on yet one more analysis before acting will find that increasingly, their peers who have participated in DevOps projects will ask them a simple question: What if Amazon made decisions this way? Google? Facebook? Think they’d lead their industries if they did?

Beyond this, the DevOps culture of collaboration and inclusion reinforces a trend that’s been incubating for years and is finally coming into its own: a change in management culture that begins with the recognition that there is no such thing as an IT project – every project is about business change and improvement.

It extends to recognize that very few business changes can happen without changes to the supporting information technology.

Its logical end-point is that “Business/IT alignment” is no longer good enough. Business/IT alignment is a relic of a time when IT was supposed to be run like a business – a supplier of technology to its “internal customers.”

But if there’s no such thing as an IT project because all projects are about business change, then IT has to be a peer, a partner, and a collaborator in making those changes happen.

And in particular IT has to be a partner in creating value for the company’s real paying customers.

Business/IT alignment? Hardly. Business/IT integration is the wave of the future.

No, make that the wave of the present, where the highest level of effectiveness is a collaboration of business, development and operations, working in a “BusDevOps” partnership –one that moves beyond a “paint-by-numbers” approach to focus on creating a unique and superior customer experience with the marketplace.

DevOps is a handy way to make and deliver software, especially the software that delivers a brilliant customer experience across all of the channels customers use to communicate and do business.

But compared to the culture change DevOps can drive into the business, fast software delivery probably pales in importance.

Read Also

ITSM: The Digital Customer Experience

ITSM: The Digital Customer Experience

Christian Moore, SVP, IT Service Mgmt., Texas Capital Bank
Managing Knowledge and Managing Processes

Managing Knowledge and Managing Processes

Matthew Morgan, COO, Savills Inc. (North American business unit of Savills plc)
Can your Investment Manager be both fundamentally and artificially intelligent?

Can your Investment Manager be both fundamentally and artificially...

Patrick Dugnolle, U.S. Head of Multi-Asset and Quantitative Solutions, BNP Paribas Asset Management
The coming Enterprise 5G Boom three trends that will drive Enterprise Demand for 5G in 2020

The coming Enterprise 5G Boom three trends that will drive Enterprise...

Imran Akbar, VP & GM, Small Cells & Wireless Enterprise, Samsung Electronics America
Survival of the fittest in the age of Innovation

Survival of the fittest in the age of Innovation

Bob Karschnia, VP & GM of Wireless, Emerson Automation Solutions [NYSE: EMR]
The Era of Frictionless Mobility

The Era of Frictionless Mobility

Dr. Derek Peterson, Chief Technology Officer, Boingo Wireless [NASDAQ: WIFI]