July 28th, 2020 By The Guide

Is fear of change preventing your devops transformation from getting off the ground?

Having led and consulted on a number of enterprise DevOps transformation initiatives over the past two decades, there are four key behaviors to enable success (beyond looking at the software development lifecycle as an end-to-end value chain) that are commonly undervalued or overlooked when executing transformations. One pattern that is sure to be pathological to your transformation is failing to drive the necessary culture shift…

Transforming culture is said to be one of the most difficult aspects of DevOps transformation, as the fear of change will cause many individuals to defend the organization’s current culture. It’s imperative that executive sponsors engage throughout the journey to help manage the cultural shift, or you may end up feeling like you are losing control.

The following four aspects must be in order to successfully transform to a DevOps culture: communication, employee education, leadership and a standardized operating platform. Every developer needs to be aware of these components of success whether they’re currently going through a DevOps initiative or not. It takes a village to make this culture shift successful, and it starts with communication.

Open communication builds trust

The premise of DevOps is bringing departments closer to the end user, then quickly delivering continuous updates based on those user needs. This gives every employee, from developers to customer support, a better understanding of their role and the purpose of their work. As a whole, the business then aligns more accurately on goals and can move faster with more agility.

Why should CEOs and senior executives care about building trust in a DevOps transformation? Aren’t there already too many things to worry about nowadays such as sustaining profitability in a cutthroat, competitive environment? What about that stagnating share price or those restructuring projects that never seem to produce all the promised benefits?

“Leaders are people who are followed,” says Basheer Janjua, President of CTOForum “People won’t follow a leader they don’t trust. Trust makes it easier to get alignment.”

Trust is a powerful force that builds loyalty, increases credibility and supports effective communications. It gives you the benefit of the doubt in situations where you want to be heard, understood and believed.

As every CEO, employee and analyst knows, trust is severely tested in periods of high uncertainty and change. Despite best intentions, at these times it is often impossible to communicate as much information as everyone would like. Executive involvement to understand progress and identify challenges will help determine the right C-level communication to appropriate individuals involved in the project, maintaining trust and alignment.

A single leader championing the process

If an executive gives a product priority to a team, then the team loses focus on DevOps and can bring the transformation to a screeching halt. It takes time to learn a new process and proactively collaborate with others and left to their own devices, Dev and Ops organizations are too busy with the tasks at hand to collaborate and/or merge efforts. DevOps change calls for leadership guidance and intervention, and if there isn’t any the business likely won’t be able to transform.

This is why DevOps needs to be a priority for every member of leadership, and why there should be an executive sponsor consistently advocating for these changes. This sponsor should hold all team leads accountable to move to a DevOps model and provide support when organization resistance inevitably occurs.

Education on what’s happening and why

One of the major barriers to DevOps integration is employees’ resistance to change and this is often overcome through education. The most critical item for developers to understand is the tie between their role, and delivery and operations development. While it might not be in their job description, without the willingness to collaborate with and support other departments the entire DevOps implementation will fall apart.

Showing examples of change in action is an excellent strategy; some areas to consider include:

  • Benefits that DevOps provides vs. other styles

  • Clearly illuminating how existing roles will morph to deliver higher organizational value post-transformation

  • How the move from traditional software development to cloud-based service development is simplified

The right collaboration tools

Many tools used in DevOps fulfill specific technical functions, for example Ansible or Jenkins help facilitate CI/CD DevOps processes, but they alone won’t improve the implementation of DevOps across departments. In many enterprises, tool proliferation, local optimizations and unnecessary complexities or handoffs throughout the SDLC impede a successful DevOps transformation. Traditional communication tools like meetings, email and phone take too long in today’s work environment.

A complete set of tools are needed to ensure all team members are on the same page, no matter what phase of the SDLC they’re in.

  • Real-time telemetry and dashboards need to be available at all levels of the organization so that all teams can understand who is where in their SDLC

  • A common view across development, product, security, program, operations and executive staff in real-time is essential to success – uniting stakeholders and extending the lines of communication

  • Teams need to incorporate a tool like Slack or Zoom into their workflow to enable quick collaboration on issues, and to help keep company-wide product roadmaps aligned

What’s harder than climbing Everest? Adjusting business processes…

It takes communication, tools, education and leadership to properly integrate DevOps into an organization. While it’s daunting to be part of a business reworking its operations, there’s no reason the change won’t succeed – just keep an eye out for those four components to ensure your company is on the right track.

Learn More About Our Platform