Overcoming Common Obstacles in a DevOps Transformation: Lessons from VMware Mobile Products

Briefly understand the obstacles encountered at the start of a DevOps transformation and how we solved them.

Today most companies are undertaking DevOps transformations to achieve faster releases, better quality, increased team agility, and quicker feedback. VMware’s mobile products are no exception. Two years ago we began our own journey, and this article lists the obstacles we faced and the solutions that moved us forward.

Starting two years ago with DevOps goals, we already had some initial elements: agile processes, an operations team, automation tools, and available technology, but none of these formed a cohesive engine, so we began making changes.

Resistance to Change

Uncertainty, fear, and doubt are human nature, creating an environment of resistance. Convincing the team to adopt new changes and drive cultural shift was one of the hardest tasks.

We addressed this by providing continuous training and gradually asking the team to adopt the changes, helping them understand the value of DevOps adoption. Management support was also crucial; without it, the transformation would have been impossible.

Feature Delivery

Another challenge was the pressure on teams to deliver new features quickly, focusing on delivering working code without taking responsibility for quality. Quality was left to a separate Quality Engineering (QE) team, while developers worked overtime, producing code beyond the team’s capacity, leading to many defects.

While adjusting team processes to adopt changes, we did not want major disruptions that would break the delivery of value to customers.

Our solution was two‑fold: first, we reduced the team’s velocity to 50 % of its normal capacity to allow time for higher‑quality work; second, we gave the team time to redefine the “Definition of Done,” focus on root‑cause analysis, and increase automation to prevent similar issues and reduce future problems.

Technical Debt

Technical debt is an inherent part of software development, especially for teams with legacy code, and our mobile products were no different.

By lowering the delivery speed to 50 % of previous capacity, we created breathing room to address smaller technical debt as part of the planned work. Deciding to halve the speed was difficult, but we worked closely with product management to prioritize debt, engineering improvements, and new features to ensure long‑term product success.

Team Structure

When we began the DevOps journey, the QE team operated independently from developers, with quality engineers testing the product—a setup that does not fit well in a DevOps model.

Management recognized the issue and restructured the teams, merging quality and development. Everyone now shares responsibility for high‑quality products. QE engineers pair with developers, report to the same manager, and engage in quality from design through development, creating a full‑stack DevOps team capable of building, testing, and managing infrastructure and services.

Skills and Knowledge

Changing the team structure made everyone accountable for product quality, but skill and product‑knowledge gaps emerged—for example, developers did not know how to write test cases, and QE engineers lacked insight into product code.

We addressed this by up‑skilling the team and fostering cross‑skill development. QE received training on development aspects, while developers learned testing strategies and quality‑first thinking. The goal was not to turn QE into developers or vice‑versa, but to equip everyone with enough knowledge to collaborate effectively, share programming expertise, and build the tools and systems they need.

Automation

Automation is critical for early and consistent feedback throughout the SDLC. Although we had automation in place, it was under‑utilized due to lack of trust in scripts and minimal test script writing by developers.

We revisited our automation testing strategy, choosing tools and technologies familiar to developers so they could write tests in their preferred languages, IDEs, and tools. This increased developer participation in writing test scripts, allowed QE engineers to fix defects faster, and improved the stability and design of our test framework, enabling every team member to contribute to quality goals.

Environment

One bottleneck for automation was the availability of on‑demand test environments, especially for Workspace ONE, a complex product with many inter‑dependencies.

The infrastructure team stepped in and built a self‑service portal backed by REST APIs, making it easy for all teams to provision test environments on demand and integrate them with automation.

Cross‑Team Collaboration

Workspace ONE consists of hundreds of inter‑dependent modules, leading teams to work in silos without sharing best practices or reusable code.

We formed a small coordination team to align release cycles, promote code reuse, and improve documentation. One example was recreating a micro‑service‑based test framework that allowed teams to share scripts and avoid duplication, and establishing a cross‑platform team to develop reusable code for the product line.

Conclusion

By applying the above solutions, we achieved many positive changes. Last year, after reviewing the mobile SDK results, iOS release speed increased by 50 % and Android by 25 %. Unplanned patches and minor releases dropped by 58 % on iOS and 29 % on Android. We reduced incident reports, boosted productivity, increased collaboration and quality, and gained many intangible benefits.

Do not fear change. As Martin Fowler said, “If you’re afraid to change something, it’s probably badly designed.”

If you’re afraid to change something, it’s obviously badly designed.

Start your DevOps transformation with proper planning, ensure management support, and let all stakeholders know it’s a journey, not a destination. Keep learning and continue improving.

About the author: Ze Yang, DevOps practitioner focusing on enterprise‑level DevOps operations and development technology sharing, offering practical Linux and DevOps courses based on real‑world experience.