How to stop failing at DevOps

Source:-techbeacon.com

Although more than 60% of organizations have adopted DevOps at some level, according to Forrester, many continue to struggle with it. One reason: DevOps isn’t a hard-coded set of practices or principles, and this often leads to confusion and uncertainty, from the IT trenches all the way up to the C-suite.

This confusion is exacerbated by deep-rooted, conventional attitudes that are at cross-purposes with the lean/Six Sigma methodologies that formed the inspiration for DevOps. Just like the manufacturing firms that were trying to become lean a half a century ago, many existing software organizations don’t have the innate flexibility to reset their attitudes.

With this inflexibility comes a devotion to waste, although all players vehemently deny it. Waste in one form or another can be a serious impediment to virtually every linear, process-centered effort. I have seen it degrade DevOps workflows, and even derail entire projects.

Business leaders at these firms look at young, nimble companies that have built lean principles into their entire operating approach and culture, including software development. And they ask themselves, “Why can’t we get there?” The answer is simple: Those firms aren’t dragging around years of dead weight in the form of outdated attitudes and bloated processes.

But when leadership makes a meaningful commitment to eliminate wasteful, self-defeating activities; alerts its personnel that the effort is a business imperative; and empowers its most innovative thinkers to work on the problem, extraordinary results can follow.

Here are some scenarios that can help you identify these issues within your own organization—and how to move in the right direction.

[ Get up to speed on quality-driven development with TechBeacon’s new guide. Plus: Download the World Quality Report 2019-20 for lessons from leading organizations. ]

Are you blaming the right problem?
One impediment to DevOps success in many firms is the myopia that accompanies misplaced blame. Because many business leaders don’t accept that traditional, wasteful behaviors are at the core of their problems, they assume that failure is rooted in lack of technology or capacity. They think their teams can “tool their way” to a better outcome.

Here’s what happens next:

The CIO or CEO reads about nimble firms that are “getting DevOps right,” and sees they are using a stable of tools to automate their processes and enable continuous delivery.

Meetings take place with development and operations managers to determine which tools will be the most useful.

The development manager wants to order a handful of proven-process acceleration tools and implement them right away.

The operations manager worries that the tools will negatively affect compliance and security and requests time to evaluate them fully.

Six months later, nothing has changed.

If by some stroke of luck the development team gets approval to acquire the tools, at some point the operations manager still gets involved. He or she delays their adoption and integration into the development workflow out of fear that something will “break” or that governance will suffer.

The outcome is the same: Six months later, nothing has changed.

In either scenario, management fails to recognize that while using DevOps tools is a hallmark of efficient delivery pipelines, it doesn’t guarantee their success. Do teams need tools to expedite and optimize delivery? Certainly.

But tools only work if corporate mindsets, organizational structures, cultures, and internal processes—especially regarding governance—are just as lean and nimble. When those who are impeding the effort are not ready to accept responsibility, nothing happens.

Do internal attitudes conflict with your efforts?
Achieving the goals mentioned above can make a lot of people very uncomfortable—including people in the organization who act as conformity “enforcers,” like the operations manager in the scenario above. People in this role are traditionally charged with governance.

Understandably, these people feel that any change should be approached very cautiously. But caution is the enemy of lean, and it fosters one of the seven recognized areas of waste: over-processing.

At their cores, agile and DevOps are both expressions of lean principles, which are centered on ensuring that work moves quickly and smoothly through processes. Any barriers to that goal must be identified and re-engineered, or eliminated, to streamline the flow. (You can achieve this through value stream mapping.)

Yet the enforcer mentioned above has been given marching orders that are in direct conflict with the goals of efficient, expedited delivery. Until management addresses this issue, nothing will change.

So what should you do? Some organizations bring in outside experts to re-engineer processes and impose a new order on teams, but this can be problematic. If an existing team member has the expertise to lead the initiative, having this person take the lead can lessen internal resistance to the effort.

Either way, someone with leadership skills and a fanatical devotion to achieving a lean stance must sit at the helm of the effort.

[ Learn how to apply DevOps principles to succeed with your SAP modernization in TechBeacon’s new guide. Plus: Get the SAP HANA migration white paper. ]

Are bad habits increasing the challenge?
An equally significant hurdle to replacing waste with lean motion is the inertia that comes with habit. Here’s an example.

A traditional fabricator wants a custom maintenance management system (MMS) for spare parts and materials. The company brings in outside specialists to examine and map the firm’s processes, confirm its inventory, and set up the system.

The specialists conduct their investigation and work with the internal DevOps team to set up an MMS, import the inventory list, and assign SKUs to each item. They develop workflows to track the ordering, approval, requisitioning, procurement, and other processes.

The new system debuts, and the specialists explain to company personnel that, moving forward, everyone will request parts and materials using this system, and that all approvals will be handled through the system as well. Everyone nods their heads in agreement as the specialists wave goodbye.

At this point, the DevOps team takes over maintenance and updating of the system. Within one week, personnel have discovered they can print out the requests they log into the MMS, so they start walking them over to a supervisor for a manual signature rather than take a chance with the new system.

Staffers turn the signed requests into the DevOps team, expecting them to get the orders into the system. Frustrated, but not wanting to derail the fledgling effort, the team members comply.

Three months later, everyone has adopted this workaround, and the DevOps team spends its days in data entry rather than developing, testing, and deploying system code improvements. Shop floor workers are still getting their parts as quickly as before, but the entire IT process improvement effort has stalled.

This is just one example that plays out every day in firms around the globe, and neither agile nor DevOps by themselves will fix it.

Interrupt the cycle
You can’t just code these problems away; they’re hard-wired into many organizations through decades of familiarity and tradition. Enforcers, who often play a necessary role in ensuring security and compliance, resist new processes or workflows even when they have been fully tested. Their training, performance metrics, and bonus incentives are all targeted to reduce risk in ways that stifle change.

I have worked with many firms where the teams were able to deliver working code for an update every two weeks, but so many rounds of testing and evaluation ensued that multiple updates got bundled into one, resulting in a big, traditional release every six months.

To achieve the goals of DevOps and agile, you can’t let this situation continue.

Here’s the solution
Here are some ways your firm can start moving in the right direction.

Engage in value stream mapping (VSM) to identify where your value lies and prioritize what you need to accomplish. VSM is a flowchart-based mechanism to illustrate, analyze, and improve the steps to deliver a product or service to customers. It is something you should absolutely be incorporating into your development effort. However, in this scenario, we’re not talking about VSM for code delivery. VSM can also help you identify and eliminate the waste in your internal processes and culture.

Accept that this effort is a marathon, not a sprint. Develop iterative goals that can be benchmarked for progress on a consistent, scheduled basis. This will begin shifting the mindset from “Let’s make it flawless” to “Let’s make it good enough and keep moving forward.”

Establish KPIs and other metrics for process improvement, just as you would (or should) for code releases, with benchmarks to confirm progress or to address backsliding.

Identify a true innovator within your organization and put that person in charge of the effort. While this might be a developer, it doesn’t need to be. The type of change I am describing doesn’t involve mad coding skills; it requires persistence and persuasion. (Hint: The person in charge should not be an enforcer.)

Reinvent your control framework. The traditional, audit-based controls that have typically accompanied software development don’t work with DevOps. Controls and testing are vital, but they must be integrated into the release cycles and move just as quickly. (This is where the concept of continuous delivery morphs into “continuous everything,” but that’s a discussion for a different day.)

Bring enforcers into the conversation. Their buy-in is vital, so they must be reassured that the firm is still committed to risk management, and that it can coexist with innovation. Their concerns are also valid, so they should have the opportunity to present them in a meaningful way. Once the framework is in place and the enforcers start to become comfortable with results, their apprehension will lessen.

Once you begin seeing improvement, you can start evaluating and implementing process acceleration, automation, and integration tools to help you build, test, and deploy your applications more efficiently. While you are adopting these new capabilities, keep the ops manager apprised of the effort. Fear of irrelevance is as great as fear of the unknown.

Go forth and conquer DevOps like a startup.

Keep at it
This list can sound daunting, but don’t lose your courage. It’s a series of recommendations, not a sequence of steps. Change is most easily consumed one bite at a time.

No matter what pace you take, resist the urge to skip over poorly constructed processes, gaps, and weaknesses, thinking you will get back to them later. Chances are good that you never will. The inertia inherent in “that’s just how we do it” is too strong.

Stay focused, establish incremental goals, and celebrate your wins, no matter how small. Before long, you’ll be realizing long-term benefits—and greater customer value.