What’s In a Name? Does DevOps Mean Just Dev and Ops?

----
What's In a Name? Does DevOps Mean Just Dev and Ops?
// Chef Blog

One of the challenges in implementing DevOps practices and processes is spreading collaboration beyond developers and operations engineers.

At InformationWeek's Interop ITX conference last month, Nathen Harvey, our VP of Community Development, pointed to one reason many organizations struggle. It's right there in the name.

I hate the word DevOps.

If you want a high velocity organization you can't just focus on two departments. It involves everyone.

Nathen Harvey at Interop ITX

Jennifer Davis, senior software engineer at Chef and co-author of Effective DevOps, agrees that the name for DevOps can be misleading.

"Understanding the context of other departments within our organizations helps to repair wasted time and effort spent on unnecessary work and helps to minimize unplanned work…Security, marketing, legal, and sales can all be part of a successful DevOps transformation."

Jennifer Davis, in Implementing DevOps: 5 Obstacles to Overcome, ZDNet

Maybe we need to expand the word (and definition) to include more of the business. We already have DevSecOps. Why not DevMarkOps, DevSalesOps, or DevOps, Esq. ?

No matter what we call it, there will sometimes be challenges in getting buy-in on new practices from the business side of an organization.

"We are technologists. We are leaders in our organizations. We need to speak the language of business [and] the language of business is about moving faster."

Nathen Harvey at Interop ITX

The best way to encourage DevOps within your company is to focus on the value increased velocity — or the time from idea to when software is shipped to users — will bring to the business.

Aligning DevOps measurement with critical business outcomes allows everyone to see the value or work yet to be done in order to see improvements with the process. These outcomes are:

• Speed: The rate of software change, measured by deployment frequency and time from commit to deploy.
• Efficiency: Effectiveness of software change, measured by change failure rate and mean time to recovery.
• Risk: Quality of software change, measured by compliance audit frequency and time to deploy remediation.

Nathen explained these three metrics in an article for IBM's developerWorks blog.

These metrics are one cohesive set. Companies cannot pick and choose a la carte, otherwise they will not be laddering up to the larger outcome of building a high-velocity organization. Outperformance is correlated only with organizations that achieve all of these metrics. The outcomes of effectively implementing DevOps mean increased speed, efficiency and decreased risk. Measuring DevOps performance allows teams to analyze where they are succeeding and where improvements need to be made so companies can continue to drive innovative solutions to exceed customer needs and ship better software experiences faster and more reliably.

Measuring your success with DevOps also ensures you're incorporating everyone into the practice, not just developers and operations teams.
In the end, it's important to remember what Nell Shamrell-Harrington explained in the 'History of DevOps':

Ops and Dev actually have the same job, and that is to enable the business to function. And the truth about business is that all businesses require change.

In that context, it's everybody's job to make the business better at delivering change faster, more efficiently while improving risk management. Of course, we'd love to help you with that.

The post What's In a Name? Does DevOps Mean Just Dev and Ops? appeared first on Chef Blog.

----

Read in my feedly

Sent from my iPhone