Skip to content
Tiatra, LLCTiatra, LLC
Tiatra, LLC
Information Technology Solutions for Washington, DC Government Agencies
  • Home
  • About Us
  • Services
    • IT Engineering and Support
    • Software Development
    • Information Assurance and Testing
    • Project and Program Management
  • Clients & Partners
  • Careers
  • News
  • Contact
 
  • Home
  • About Us
  • Services
    • IT Engineering and Support
    • Software Development
    • Information Assurance and Testing
    • Project and Program Management
  • Clients & Partners
  • Careers
  • News
  • Contact

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.

Devops, Software Development


Read More from This Article: 7 tell-tale signs of fake DevOps
Source: News

Category: NewsJanuary 16, 2023
Tags: art

Post navigation

PreviousPrevious post:4 moves CIOs should make to achieve a more efficient IT organizationNextNext post:Google Cloud for Retailers adds AI-based inventory, e-commerce tools

Related posts

휴먼컨설팅그룹, HR 솔루션 ‘휴넬’ 업그레이드 발표
May 9, 2025
Epicor expands AI offerings, launches new green initiative
May 9, 2025
MS도 합류··· 구글의 A2A 프로토콜, AI 에이전트 분야의 공용어 될까?
May 9, 2025
오픈AI, 아시아 4국에 데이터 레지던시 도입··· 한국 기업 데이터는 한국 서버에 저장
May 9, 2025
SAS supercharges Viya platform with AI agents, copilots, and synthetic data tools
May 8, 2025
IBM aims to set industry standard for enterprise AI with ITBench SaaS launch
May 8, 2025
Recent Posts
  • 휴먼컨설팅그룹, HR 솔루션 ‘휴넬’ 업그레이드 발표
  • Epicor expands AI offerings, launches new green initiative
  • MS도 합류··· 구글의 A2A 프로토콜, AI 에이전트 분야의 공용어 될까?
  • 오픈AI, 아시아 4국에 데이터 레지던시 도입··· 한국 기업 데이터는 한국 서버에 저장
  • SAS supercharges Viya platform with AI agents, copilots, and synthetic data tools
Recent Comments
    Archives
    • May 2025
    • April 2025
    • March 2025
    • February 2025
    • January 2025
    • December 2024
    • November 2024
    • October 2024
    • September 2024
    • August 2024
    • July 2024
    • June 2024
    • May 2024
    • April 2024
    • March 2024
    • February 2024
    • January 2024
    • December 2023
    • November 2023
    • October 2023
    • September 2023
    • August 2023
    • July 2023
    • June 2023
    • May 2023
    • April 2023
    • March 2023
    • February 2023
    • January 2023
    • December 2022
    • November 2022
    • October 2022
    • September 2022
    • August 2022
    • July 2022
    • June 2022
    • May 2022
    • April 2022
    • March 2022
    • February 2022
    • January 2022
    • December 2021
    • November 2021
    • October 2021
    • September 2021
    • August 2021
    • July 2021
    • June 2021
    • May 2021
    • April 2021
    • March 2021
    • February 2021
    • January 2021
    • December 2020
    • November 2020
    • October 2020
    • September 2020
    • August 2020
    • July 2020
    • June 2020
    • May 2020
    • April 2020
    • January 2020
    • December 2019
    • November 2019
    • October 2019
    • September 2019
    • August 2019
    • July 2019
    • June 2019
    • May 2019
    • April 2019
    • March 2019
    • February 2019
    • January 2019
    • December 2018
    • November 2018
    • October 2018
    • September 2018
    • August 2018
    • July 2018
    • June 2018
    • May 2018
    • April 2018
    • March 2018
    • February 2018
    • January 2018
    • December 2017
    • November 2017
    • October 2017
    • September 2017
    • August 2017
    • July 2017
    • June 2017
    • May 2017
    • April 2017
    • March 2017
    • February 2017
    • January 2017
    Categories
    • News
    Meta
    • Log in
    • Entries feed
    • Comments feed
    • WordPress.org
    Tiatra LLC.

    Tiatra, LLC, based in the Washington, DC metropolitan area, proudly serves federal government agencies, organizations that work with the government and other commercial businesses and organizations. Tiatra specializes in a broad range of information technology (IT) development and management services incorporating solid engineering, attention to client needs, and meeting or exceeding any security parameters required. Our small yet innovative company is structured with a full complement of the necessary technical experts, working with hands-on management, to provide a high level of service and competitive pricing for your systems and engineering requirements.

    Find us on:

    FacebookTwitterLinkedin

    Submitclear

    Tiatra, LLC
    Copyright 2016. All rights reserved.