Browse by year:
The Devops Culture Change Goes Way Beyond It
Ramki Ramamurthy
VP, Application Services-Dell
Thursday, October 13, 2016
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.

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.

In addition, 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.
Share on LinkedIn