7 tell-tale signs of fake DevOps

There’s no doubt that DevOps has helped many IT organizations achieve their goal of delivering applications and services faster and better than traditional software development processes. Unfortunately, while some IT leaders do a fine job of trumpeting DevOps’ benefits, their teams are headed in the wrong direction, embracing half-baked or completely wrong tools and practices.

It’s the CIOs responsibility to ensure that development teams aren’t intentionally or unintentionally straying off the DevOps path. Here are the seven warning signs that will alert you to the possible presence of fake DevOps in your organization.

1. Placing DevOps in a silo

The first sign of a fake DevOps implementation can be easily detected simply by viewing an organization chart. “If you find DevOps in its own silo, separate from engineering and operations, that’s an initial sign that your DevOps accountability isn’t there,” says Fernando Cuadra, a principal consultant with technology research and advisory firm ISG. “By creating a separate DevOps team, the CIO has essentially added another layer of complexity, another silo, and another hand-off to manage.”

The organization chart should reflect a design that allows teams to solve problems holistically across all relevant areas. “Opt for building cross-functional teams end-to-end from design to operations,” Cuadra advises. “DevOps is not about pipelines and CI/CD; it’s about owning your value delivery with minimal friction across the enterprise.”

DevOps is only a tool in what should be a much larger conversation around the human side of technology, Cuadra observes. “It requires a deep understanding of the core building blocks of high-performing teams, and how CIOs can refresh their perception of what highly functioning teams look like.”

2. Focusing on tools over people

An organization that hyper-focuses on a tool- and technology-centric DevOps culture, rather than on people and processes, is 180 degrees out of sync. “It’s crucial to assess current business practices and needs,” says Mohan Kumar, senior architect at TEKsystems, an IT service management firm.

Kumar recommends prioritizing teams. “Instill DevOps culture into communication, collaboration, feedback collection, and analysis,” he suggests. “An experiment-friendly environment that allows developers to fail fast, recover fast, and learn faster builds a blame-free culture within the organization.” Kumar also suggests nurturing a stream of creative ideas by tapping into teams’ collective intelligence.

DevOps adoption is an iterative process, so the CIO should begin by evaluating the development team’s current state and then gradually building a strategy of continuous improvement involving people, processes, and tools that can evolve along with future needs and developments. “Ultimately, creativity is a muscle that must be exercised continuously to grow,” Kumar observes.

3. Too little automation

Fake DevOps can occur when team leaders lack an automation mindset, particularly the ability to invest the time and resources necessary to build a strong architecture with automated code delivery.

Before moving forward with an automation initiative, carefully consider development needs, existing contracts, and current project teams. “See if the organization’s skills are at the level where you can automate infrastructure,” says Ian Fogarty, managing director of technology and operations at consulting firm Accenture Federal Services.

Automation can be a double-edged sword, however. Kumar observes that it’s all too easy to unintentionally switch from flawed manual processes to flawed automated processes. He advises resisting the urge to automate as much as possible. Instead, automate as much as is reasonable. The ultimate goal, Kumar notes, should be to turn software releases into a repeatable and reliable automated deployment process.

4. Haphazard automation

Although automation is highly beneficial, many organizations jump into DevOps automation without sufficient analysis and planning. “We have seen organizations that prioritize automation without considering other aspects, including governance, people, process, and technology,” says Aaron Oh, managing director of DevSecOps at Deloitte Risk & Financial Advisory. Such organizations typically end up wasting significant amounts of time revisiting and fixing automation work.

Before running directly into automation, Oh suggests establishing strong governance and standardizing requirements and processes. “Collaboration between the business units is an essential part of DevOps,” he notes. Address any organizational barriers that may exist. “The leadership’s guidance is going to be important to set the tone,” Oh says. “In addition, leverage intelligent orchestration tools to help further remove silos and enable efficient communications.”

5. Harboring unrealistic expectations

Senior technology leaders should focus on a commitment that extends beyond simply introducing new technology tools and practices. “They need to prioritize a shifting culture and employee mindset,” says Tim Potter, a principal with Deloitte Consulting. “They also need to set realistic timelines for the transformation to take root in the organization.”

An organization that simply deploys more automated tooling and renames existing application teams “DevOps teams,” committed to owning production issues from end-to-end, will likely be disappointed with the results, Potter explains.

Technology leaders should also be willing to accept the fact that after committing to DevOps, output may initially decrease before improving. “They need to be prepared to provide ‘air cover’ for their application teams, enabling them to test-and-learn and get comfortable operating in a new model,” Potter advises. “Setting inappropriate expectations and not providing sufficient time for transformation can lead to organizations that adopt DevOps in name only.”

6. Teams that are stuck in the past

Old habits die hard. For decades, software development followed traditional waterfall methodology, a process that demanded gathering requirements ahead of time, building features, and finally throwing the results over the fence to QA and other teams for release, says Ashish Kakran, principal with IT venture capital firm Thomvest Ventures. “It used to take months before customers would see any new features,” he notes.

When development teams fail to completely pull themselves out of the waterfall, they end up with weird combinations of processes that can be describe as “agilefall,” Kakran says. “It indicates that a complete move hasn’t happened to take advantage of latest advances in software development.”

Kakran suggests that a fast and easy way to spot a struggling team is by examining their DevOps “Epics” and “Stories.”

“The full context of an ongoing project is often captured in these tasks,” he explains. “If you sense a month’s long project is already broken down into tasks with little or no continuous customer feedback, it’s a sign that the team is setting itself up for failure, whether that’s missing project deadlines or not shipping useful user experiences.”

7. Inflexibility

DevOps isn’t a one-size-fits-all methodology. For maximum effectiveness, DevOps flows and tooling should be tuned to the organization’s specific needs, which can vary widely depending on its size, application types, and development expertise.

DevOps should never be static. Processes and tools must adapt as the organization grows and follows its quest for continuous improvement. These goals require flexible tools as well as an ability to analyze KPIs to reveal improvement opportunities, says Wing To, vice president of engineering at Digitial.ai, which markets an AI-powered DevOps platform. IT leaders should also be mindful of the cultural shift needed to bring development and operations teams together. Rather than building a separate DevOps department, which only creates more silos and process bottlenecks, the methodology should be integrated into each business area.

DevOps is basically about people and processes. IT leaders should understand that these resources have to be context specific. “The optimal way to use tools and processes changes over time, is dynamic, not static, and the tools and processes need careful coaching to be used properly,” To notes.

Reaching a balance

There’s a push and pull balance that must be achieved when launching a successful DevOps transformation. “If you’re fortunate, eager teams will step up and volunteer to be among the first to adopt,” Potter says. “It’s important to support these teams — reward them for their courage and celebrate their success, while maintaining focus on the broader organization transformation roadmap.”

Remember, however, that benefits will be limited and delayed if the entire organization fails to accept the transformation. “Inevitably, there will be interdependencies that will throttle down an application team if the broader organization has not made the shift,” Potter says.