DEVOPSdigest

It has been argued that Dev and Ops teams should work more closely together for some time. For many, the benefits of a closer relationship are clear, and the debate has moved on from "if" to "how," but for lots of companies there are several types of walls to tear down.

The first is the organizational one: some large companies still have a clear distinction in their IT set up; "build the product" (Dev) and "maintain the product" (Ops). But the downsides of this divide are vast. Each department houses specific mindset, responsibilities and performance goals: Developers will be focused on creating new functionality and Operations on maintaining stability.

In some cases there is also a physical separation: Development and Operations teams are located at different floors, different buildings, or even with different companies, thanks to outsourcing. And this separation can result in a "them and us" attitude where ideas aren't shared well enough and collaboration is (albeit subconsciously) discouraged.

How to Collaborate

For most organizations, it's clear that these barriers need to be broken down — and many aspire to create DevOps teams where the two functions work seamlessly together. But it's when we come to the "how" to break down these barriers that debate ensues. For us, a fundamental shift in priorities is needed. Yesterday's model — where one team focuses on delivering software and one team focuses on overall app health in production — is fundamentally wrong and doesn't work in today's world of agility and digitalization. When thinking about fostering collaboration between Dev and Ops, savvy firms must instead think about one team, with shared objectives and shared tools.

But more than this, the focus must shift away from the intricacies of how a team works to rest firmly on delivering against customer expectations. The focus should be on providing useful, delightful and flawless customer experiences — helping enterprises to grow market share, and build and sustain a happy, loyal customer base. And that means organizations needs to design teams around that objective — allowing them to take ownership and designing the right tech stack to deliver and proactively monitor that outcome.

Ensuring Team Independency

The very first "Agile Value" is "Individuals and interactions over processes and tools". So, for us, one of the key elements in driving agility and collaboration in development teams is the notion of team independency. Reduce the team dependencies and they will produce more, and faster.

One implication of this, though, is that teams need to own more of the process themselves. With speed and collaboration must come independence and empowerment.

The status quo for most organizations is not agile-friendly: "production monitoring" (generating awareness of the application health in the production phase) is a task owned typically by a central operations team. The team is usually not enabled on the specific app, and certainly not on new features coming in the next build. They are usually using a separate tool for "Application Performance Management"

This impacts on the ability to work quickly. In real terms — if there is an incident in production (responsiveness degradation or even outage), that the operations teams can't resolve themselves, they typically call on the development team.

Using a separate tool and process, the developer then needs to familiarize him or herself with how that tool is setup. This means that the time to understand the root cause for the incident and the time to resolve it is naturally impacted. All of this while the brands' "front door" is closed due to an outage, impacting customers, the brand and the business.

So, we know that collaboration is critical and a customer-first(link is external) strategy must be prioritized in order to succeed.

For us, this goes one stage further, as both DevOps and non-IT roles see the need for better integrated toolsets that provide various teams with a composite view of how their systems are performing. But we also recognize that affecting this change isn't always easy or straightforward. And that a starting point is having these conversations, where we come together to discuss our experiences and issues, and work together to solve issues — collaboratively(link is external).