The rift between Dev and Ops teams has long been one of the main obstacles for organizations managing their IT capabilities. Overcoming it can be crucial for a successful business. In fact, every company should be able to achieve harmony by improving process automation, implementing better procedures and refining workflow regulations. This is where DevOps culture steps in.
To be successful, your DevOps approach must include a detailed understanding of your culture and learned behaviors that will influence the changes you want to see in your organization.
According to recent Gartner research, DevOps will only work when both Dev and Ops are willing to collaborate. They need to embrace change at a behavioral level to initiate and achieve culture change. If not, there is a 90 percent likelihood that any DevOps initiative will fail.
In discussing the importance of communication in implementing DevOps know-how with Consultancy UK, Gartner’s research director Laurie Wurster explained: “With respect to culture, DevOps seeks to change the dynamics in which operations and development teams interact. Key to this change are the issues of trust, honesty and responsibility. In essence, the goal is to enable each organization to see the perspective of the other and to modify behavior accordingly, while motivating autonomy.”
Theory vs. Practice
In reality, the existing autonomy of the operations and development teams is one of the most common reasons for a possible failure of the DevOps approach. While the business culture of developers is founded on innovation and breaking the status quo, life in Operations can seem unthinkable without a procedure-based routine.
Going further, these two teams can be pushed apart by their own executives. After all, handing out separate tasks and objectives without actually putting the Dev and Ops teams in a room together (even when working on the same project!) has been a traditional approach that dates back decades.
Deadlines and Objectives
With Dev and Ops each being unaware of the business value of the other, the departments end up sharing only two business factors: deadlines and objectives. This often leads to a blame game—explaining a delay or a failure seems much easier when you have someone else to blame and a team with an unknown value is always an easy target.
Putting a stop to this poor practice by initiating cooperation and reminding both they are part of the same organization is the best way to improve efficiency and speed of innovation. IT managers must build bridges and encourage Dev and Ops to discover new ways to accomplish their shared objectives.
DevOps for an Agile Reboot
Modern business has realized that while Agile improves speed and service delivery, it may have skipped some very important aspects of culture change resulting in the birth of “fragile infrastructure.” The term is used to describe the damage that can be caused by Agile’s ‘shortcut policy,’ in which teams may compromise to meet their deadlines.
Many see DevOps as the savior that comes just in time to influence business on a cultural level and unite with Agile toward excellence.
One of DevOps’s flagmen, Mike Kavis, vice president and principal architect at Cloud Technology Partners and a Forbes contributor, points out that “the solution is for dev and ops to collaborate on the environment specs and together build the appropriate automation scripts that can provision environments with a single touch of a button without the need of additional configurations.”
When implementing the DevOps approach, developers can be the toughest audience. They may remember all the arguments and rifts with operations, potentially caused by tentative coding leading to functionality issues within the environment—a destabilization every Operations team fears and detests. So, one question remains: How can you build this collaboration?
Incentivize Accordingly
As stated by Forrester analyst Kurt Bittner, IT companies of today are helping the cultural rift between dev and ops by incentivizing the teams to do different things—developers are prompted to deliver quickly, while operators are targeted to keep the services up and running.
Encouraged to pull in opposite directions, it is only natural that the two business units end up facing a rift, making cooperation seem more illusion than reality.
Because most companies set their priorities based in part on its incentives policy, it is important that those priorities agree with the company goals. In short, once you “go DevOps,” make sure your incentives policy is encouraging rather than hindering collaboration.
Set Shared Goals
DevOps supporters see DevOps as a cultural movement and a philosophy, rather than a framework or simply an approach.
“DevOps is a mindset of moving away from fragile systems that take too long to deploy to reliable software that can be deployed quickly. DevOps requires great collaboration and teamwork, not just within IT, but also with management and product,” Kavis notes.
Identifying a goal that can bridge the gap and make teams work together is a great way to initiate a change in a positive direction. As Bittner explains, “Part of that means measuring devs on stability, and part of that means measuring ops on innovation. But the best thing is to reward everybody on improving the customer experience.”
A recent case study presented by Orbitz Worldwide’s senior software engineers Greg Burton and Ori Rawlings at the Velocity Conference neatly demonstrated how setting a common goal for Dev and Ops can bring actual results.
The goal itself was simple but ambitious: to double the hotel search capacity across the whole website. While achieving it by working closely with operatives, the development team managed to get a hold of many issues plaguing the system on day to day.
In fact, being a back-end developer himself, Burton defined the term “feature guilt”—the belief among developers that any time spent in aiding operations to resolve outstanding performance issues is lost and unproductive, so everything that does not involve new features must be completed quickly.
Like many other professionals, Burton also believes change should be realized as soon as possible throughout the organization to prevent substantial losses for everyone. Working on a shared goal, such as improving the customer experience, for example, can help influence developers to appreciate that maintaining a system is as important as developing new features.
Change the Culture of Fear
As Bittner notes, “If agile was the opening act, continuous delivery is the headliner.” Once the culture change is favorable and the company is running at full capacity thanks to the DevOps approach, favoring innovation and experiments within the organization becomes one of DevOps’s main advantages. Still, allowing it to work might prove unattainable to some companies. What lies beneath is the fear of failure that can paralyze every manager and employee.
Randy Bias, director of the CloudStack Foundation and vice president Technology at EMC, speaks of “a culture of fear” that exists within organizations, which is driven by an “endemic” fear of failure.
This is caused by the widely adopted practice of heavily penalizing every form of failure instead of focusing on how to minimize the potential losses and still allow experimentation for the sake of innovation.
The real question is, How can you make this possible when your business is at stake? The secret to success, according to many industry experts, is creating a structure based on separate components that can malfunction without leading the company to bankruptcy.
As hard as this may be for companies relying on monolithic applications, it is best to adopt microservice architecture that will permit managers to allow developers freedom, even if this means paying the cost for the potential mistakes.
According to Mike Kavis, vice president and principal architect at Cloud Technology Partners, and Etsy’s CEO Chad Dickerson, it is essential to allow people to make mistakes as freely as reason allows and turn postmortems into productive and proactive meetings, not a blame game.
One of the greatest success stories of today’s business practices, the e-commerce platform Etsy is a great example of the benefits of DevOps practices and blame-free meetings.
Senior vice president of Technical Operations John Allspaw, who is in charge of Etsy’s “blameless postmortems,” told Business Insider: “Less-skilled companies name, blame and shame. It’s not about avoiding accountability. In a blameless culture, it’s easier for people to take responsibility for their mistakes and learn from them. Developers already feel quite guilty when they break the site.”
Seeing is Believing
One-on-one meetings with management, prearranged brainstorming and specially made presentations are no longer enough to effectively influence culture change. Encouraging communication between teams with the right incentives is vital, but modern management needs to push even further.
The best way to make developers understand operations and vice versa is to get them together and even share job descriptions.
Companies like OnShape, for example, have taken a big step in reorganizing on-call duty by making developers and operations actually work together. According to Paul Beltrani, webops at MC10 Inc. and former techops at Onshape, this has been a win-win game, as the change has helped both teams.
Developers have gotten a grasp of the after-effect of a faulty code, while operations have gained a better understanding of how the code works. Furthermore, making dev and ops share a responsibility has also proven to be less stressful, as developers and operations were effectively cooperating by exchanging knowledge to handle the issues.
CenturyLink goes even further in this direction, by transforming its dev and ops teams into product teams able to support the entire service.
“It aims to be light on management and process, with each product team assigned each aspect of the product with a laser focus,” explains Jared Wray, CTO of CenturyLink Cloud and head of the development center. “There’s no throwing it over the fence, and there’s no distractions between the two organizations.”
Patience is a Virtue
If you’re willing to transform your organization according to DevOps, you should invest all of your patience and good will; be ready to listen and improve.
As every business is unique in its organizational structure and services, and is counting on many individuals, there is no strict route to follow when implementing DevOps. Of course, there is something all professionals agree on: “Most people think they’re going to snap their fingers and it’s going to happen overnight by doing a reorg. But it’s a full culture shift. It took us three years to make this model, and we’re still evolving it,” Wray says.
According to Chris Nowak, senior vice president and head of DevOps Services at Bank of America, it’s natural to face initial resistance when presenting teams with new requirements and processes and the best way to handle it is with care. Nowak recommends the human approach: finding and encouraging opinion leaders who can influence change and “eventually help other teams let go and embrace a new way.”
So, setting clear goals is the first step to becoming a DevOps success and rushing change has only ever resulted in a temporary workaround. DevOps is gaining more and more popularity, making it possible to gather opinions and learn from the forerunners.
Industry experts have come together to found the DevOps Institute and share a common language through the DevOps Foundation course, so maybe now more than ever is a good time for your business to “go DevOps” and see the value.
