How to apply a DevOps culture beyond IT

How to apply a DevOps culture beyond IT

Upgrade your entire organization using DevOps principles with these three steps.

Green graph of measurements
Image by : 

Internet Archive Book Images. Modified by Opensource.com. CC BY-SA 4.0

x

Get the newsletter

Join the 85,000 open source advocates who receive our giveaway alerts and article roundups.

There's a new evolution of DevOps that's being applied beyond the traditional IT department. I refer to it as "DevOps 2.0," and I recommend that you stop what you're doing and upgrade!

As DevOps is increasingly adopted into large corporate and public institutions, a new perspective has formed on the core principles and practices that realize the benefits of speed, safety, and efficiency.

At the surface of DevOps 2.0 is a focus on greater business engagement. Change that's driven only by IT addresses the silos and inefficiencies within IT, but it fails to deal with the void between IT and the business.

From my perspective, DevOps 2.0 means applying DevOps principles across the entire organization (you might also think of this as "BizDevOps"). Applying DevOps beyond the IT department and breaking down organizational silos starts with the following three concepts:

1. Agree on what you need to deliver more business value

IT knows that investing in self-service environments and implementing continuous delivery and deployment will add value to the business. Most businesses don’t have a clue what that means unless you speak in a language of value:

  • As a delivery team, you want to be able to define, create, and deploy your own environments automatically so you don’t need to hand off the responsibility to another team and wait for weeks

  • As a business, you want to be able to release changes immediately so you can react to the competition and not lose customers

  • As a delivery team, you want to ensure that you release the same functionality you test and not impact your customers

Once the value is understood, empower the business to determine the order of delivery.

2. Define a set of principles that delivery is based upon

Rather than simply broadcasting the adoption of agile or environments on demand, define the principles that enable these outcomes. Provide teams with actionable instructions:

  • I want the business representatives and delivery teams to collaboratively take time to plan, size, and visualize work. I want you to show me when you have achieved this.

  • I want infrastructure as code. I want delivery teams to be able to code infrastructure and operations teams to govern and control it. I want safety and scale.

3. Form a consensus on where you are and what’s next

Visiting customers and observing your colleagues working hands-on provides real insight into the day-to-day challenges of improving delivery. I was recently an observer in an experiment to re-engage two parties, and it was great to gain an insight into the approach. Stepping through this:

  • Listen to others, and discuss openly and honestly what’s not working

  • Understand what is working. Even if ten things are failing, agree and focus on the one thing that’s going well

  • Agree on what should be done next to move forward

Don't just repair the business-IT bridge—join hands and walk across the river. Start small and gain trust.

Discussions and reflections on the challenges enterprises face in DevOps adoption are extremely helpful. There is no need for a reinstall or a migration to upgrade DevOps. Simply bring others from within the business in as engaged stakeholders, provide actions—not outcomes—and encourage open communication across the organization. You’ll get there.

Topics

About the author

Chris Wellington - Chris is the CEO of IntegrationQA, a team focused on improving software delivery and the return on business investment. He enjoys helping people improve what they do everyday at work or at play.