1001010110101010
Thank you! Our team will contact you soon

6 Myths About DevOps Busted

October 15, 2020
Setting the Stage for DevOps

To create a successful DevOps culture, you need support and commitment from both IT and business executives, which can be a challenge to obtain. Many managers, technologists, and business leaders are still not sure what DevOps is, much less why they need it, and the abundance of materials from vendors trying to capitalize on DevOps’ status as something of a buzzword does not help the confusion. As such, education on the benefits of adoption of DevOps core values must be a high priority for anyone looking to lead a digital transformation at their company. Although you’ll be faced with many challenges in this process, the major ones you’re likely to encounter can be boiled down to two generic points: uncertainty about what DevOps is and uncertainty about how it will benefit the organization. In this post, we discuss these challenges, and I provide you with practical strategies for educating stakeholders on how DevOps can optimize business.

What is NOT DevOps?

Many companies and decision-makers don’t fully understand what DevOps brings to the organization, and because of that, they don’t understand where the changes need to be made to truly make a positive impact. They are looking for a silver-bullet solution or product that doesn’t exist.

When bringing the concept of DevOps to organizations where decision makers are not sure of what DevOps really is or the value it provides, I tend to start from the opposite end of the information spectrum and educate on what DevOps is not. This approach helps to clear up some of the reductive ideas that many people have about DevOps.

1. DevOps Is Not a Product (or Suite of Products)

We’re doing DevOps by using a configuration management tool.
DevOps is a philosophy. An approach. A method. It is not a product. You can’t “buy” DevOps (or its accessories) just to say that you have it. No matter how many companies are trying to sell you a “complete DevOps solution,” DevOps is an entire culture that must be adopted and embraced by the entire organization.

2. DevOps Is Not Interchangeable with Other Industry Buzzwords

By using Agile techniques for automation in the cloud, we’ve successfully achieved DevOps.
DevOps is not a synonym for other industry terms like “Agile,” “cloud,” or “automation.” Even though certain elements of these practices and tools do intersect, you cannot equate them to one another.

3. DevOps Is Not a Separate Team

We’ve created a new DevOps team to make communication between our Dev and Ops more effective.
One of the goals of DevOps culture is to help eliminate siloed structure, improve communication between development and operational groups, and cross-educate those groups make them more efficient and effective. Creating a new siloed group does not contribute to any of those goals.

4. DevOps Is Not a Staff Consolidation Technique

We’ve given our developers pagers and made them responsible for operations.
DevOps is not a method to reduce staff and stack cross-department responsibilities on remaining people. It logically expands the area of responsibility for each group and defines the processes for all technology groups to work efficiently together. As example, it extends developers’ responsibility for success of the application after deploying it to production, both reducing the load on operations team and providing a subject matter expertise in production troubleshooting.

5. DevOps Is Not New

The DevOps model is not mature yet. We’ll give it a few more years.
Both engineers and organizations have been applying DevOps principles for years prior to when the term was coined. Companies that understand the need of cross-department collaboration successfully streamlined execution and increased the success rates in time-to-market and quality of products. The toolset that is most commonly associated with DevOps-related concepts are (arguably improved upon) derivatives of what were used well more than a decade ago.

6. DevOps Is Not Just About Development and Operations

We finished our reorg; now, IT consists of DevOps, QA, Security, Database, and Networking groups.
DevOps is, in a certain sense, a misnomer. Initially intended as a method to improve efficiency between development and operations group, the concept has logically expanded to cover other technology units, as well. And with the end goal being optimization of service delivery for organizations, the more successful companies have begun to span principles beyond technology groups, including marketing, finance, HR, and other nontechnical business units. DevOps is about a culture; a set of processes and practices that optimize service delivery for organizations. The other often-discussed concepts, such as automation, tooling, and staff responsibility, should be tactical implementations for the overall digital transformation strategy.

So what is DevOps?

The term DevOps has many different perceived meanings, which often leads to misunderstanding about what it actually is. When the term was first introduced, it was intended to define a relationship between development and operations groups. Over time, the definition has been expanded; DevOps is not just about interdepartmental communication; rather, it’s about building the culture and providing value to an organization. DevOps represents an organizational culture aimed at delivering business value quickly.

Defining Your DevOps Goals

After you’ve established a baseline definition of DevOps for teams at your organization, you need to make sure that both technical and business units agree upon and understand the overall strategy and goals of a DevOps transformation and are comfortable with the changes required to put DevOps principles into practice. To accomplish this, you can use the CAMS principles as a blueprint to assess and outline areas of impact and potential improvement for your organization.
Remember that you are not picking tools or implementing an isolated processes. DevOps is about a culture shift, to promote collaboration and empathy both within and across diverse business units.
Focus on removing manual steps from your value chain (where appropriate). Keep an eye towards the end goal of improving the time from inception to delivery to customer.
Much like performance and security, threat measurement should not be merely a feature or an afterthought, but a core requirement for each component in your delivery model. Keep in mind that you can’t improve what you can’t measure.
Creating robust feedback loops is key to a successful continuous improvement model. And being transparent with information made available (success and failure alike) will contribute to culture of collaboration and empathy. After the key areas are outlined, it’s time to focus on the effects the changes would have for individual groups and people.

Understanding the Impact of Change

Change is crucial to long-term organizational success, yet it is often met with resistance by individuals. Despite being vital to success, change can easily be perceived as having negative connotations and consequences, such as increasing individuals’ workloads, creating potential failures, compromising product quality, and reducing the size of the staff. Overcoming resistance to change is especially difficult when working with organizations and individuals who don’t believe that they have an immediate, acute problem and those who perceive change as a threat to their current role. There are a number of common reasons for resistance to change that tend to fall into three main categories. You should address each of these reasons as part of a buy-in acquisition from all groups.

Complacency

Complacency is often a problem in organizations and individuals with a history of success without recent reliance on innovation—“If it ain’t broke, don’t fix it,” as the saying goes. As one of the more egregious examples, many traditional retail businesses either passed on or procrastinated on a strong push from many organizational leaders to shift the priorities to online venues. On an individual level, not keeping current with your industry can make your skills quickly outdated and, as a byproduct, have a negative impact on any solutions you propose based on then-current knowledge. Remember, continuity when you aren’t going anywhere is stagnation.

Personal Impact

Fear for job stability is perhaps the most common reason that contributes to resistance to change on an individual level. Some people are worried about stepping out of their comfort zone, either technically or socially, or hesitant to change their routines. Others feel that they won’t be able to make the transition very well, either because the change may force them out of the job if they don’t pick up new skills, or due to automating themselves out of a job—a frequent concern during a DevOps transformation. Lack of Trust Trust is a key factor in getting a cross-departmental buy-in for change. If management doesn’t believe IT can successfully manage change, they will be skeptical of any innovations that require their buy-in. Similarly, if organizations continuously reject grassroots innovation, it disincentivizes engineers from providing value through change. Not trusting that change will better your situation creates strong resistance.

Helping Teams to Embrace Change

The previous three categories, at their core, essentially boil down to an aversion to change due to risk and money factors. Though those concerns can be valid, they are often driven by a fear of the unknown, which is amplified by the lack of understanding of reasons for change. And a lack of understanding stems from a lack of clear communication. As such, when preparing a compelling case to get a buy-in, there are a number of strategies that you can use to communicate clearly and directly with your stakeholders across teams to help them embrace change. Let’s take a look at some of them.

Address Personal Concerns

Consider each audience. When you’re presenting to executives, you should focus on the impact of change to improve organizational goals, but when you’re trying to get a buy-in from the people in your group, you need to consider their individual concerns. When presented with a change to their routine, people’s first reaction is usually, “What does it mean for me?” Address that question first. • Discuss how individual job descriptions will change. • Outline a plan of action to train people if needed. • Talk through group structure changes. • Perhaps most important, address any potential personnel changes head on.

Be Transparent

Explicitly tell people what’s going on. Given incomplete information, people will speculate and make assumptions, forming a resistance to change before the change is even communicated or understood. Even if you don’t possess all the details, update the people involved and acknowledge that information will be made available as soon as it’s available.

Involve Affected Groups

Involve the people in conversations who will be affected by the proposed change about the purpose and effects of change, and involve them early and often. Get them excited about the change by focusing on how the changes will improve the business, which will benefit everyone at the organization. It’s less likely for individuals to oppose to change when they are part of the decision, let alone if they feel there is a personal connection or benefit associated with it. After you have secured buy-in for the overall strategy, you can begin focusing on defining individual implementation tactics with an eye out for the strategic outcomes. As part of this exercise, you should define goals and outcomes that would signal incremental success of changes in your group.

Protect yourself and others from the covid-19 pandemic. Learn more