Driving Business Agility Without Large-Scale Transformation Programs

September 21, 2021 Venkatesh Arunachalam

The agile transformation services market will grow at a compounded rate of 19.5 percent annually by 2026, according to Allied Market Research. The overall digital transformation services market, meanwhile, is estimated by Forbes to be worth trillions of dollars. 

Indeed, if we scroll through the annual reports of Fortune 500 companies over the last decade, many of them will detail going through some version of a digital transformation. While such transformation efforts have come to be expected by shareholders, most organizations either haven’t completed them or have failed to achieve their desired outcomes. So, why do organizations still persist with this treacherous multi-year, multimillion-dollar journey? Also, what are their alternatives? 

To drive the agility of their business, organizations need to take a systematic approach.

A systematic approach

The digital economy has enabled small businesses, which are nimble by nature, to disrupt the market, and that has in turn forced large organizations to rethink how they operate in order to stay not just profitable, but relevant. Undertaking a large-scale digital or agile transformation program has become the de facto solution to this problem. Some common examples include technology transformation (e.g., cloud transformation), process implementation (e.g., models such as SAFe, Spotify, and Scrum), and commercial off-the-shelf technology (COTS) product implementation (e.g., Salesforce or Adobe Experience Manager). The common thread in all these approaches is that they are typically looked at as “silver-bullet” solutions designed to address an organization’s people, process, or technology problems. But that is not what they are designed to do.

A typical agile transformation approach starts with a decision about a methodology, followed by the formation of a team of process experts. The process experts like scrum masters focus more on adherence to the methodology over outcome delivered from the product. They measure the success of the initiative based on the number of teams they have formed. For example, having 10 scrum teams or Kanban teams doesn’t translate into 10 successful products or better software. They have to still build the right products, which is never a part of these transformation initiatives. This is akin to taking a waterfall approach to organizational transformation. But transformation in a learning- and product-centric organization cannot happen by taking a waterfall approach to transformation.

At VMware Tanzu Labs, we take a systematic and product-centric approach to organizations’ transformation goals, one that focuses on delivering return on investment (ROI) quickly. Any investment that doesn’t generate a return is not a worthy investment. Our three-stage approach helps customers realize ROI faster than any traditional large-scale transformation because we focus on delivering value and driving the business forward rather than simply processing change.

Before we break down those three stages, we need to understand the organization’s needs in detail, especially their landscape, what’s driving their need for transformation, their mindset leading up to it, and the outcomes they are expecting against what they observe.

Understanding the context

In order to help an organization achieve the agility they need, we first need to understand the business drivers that led them to take the digital/agile transformation route in the first place. Large organizations have an irresistible temptation to make sweeping changes at scale. Given their size, that means massive changes to people, processes, and technologies. Even at a very small scale, a change to these three areas will result in friction. If an organization attempts to make such changes at a large scale too quickly, the friction will bring the entire initiative to a grinding halt. That’s why executives seek to find a silver-bullet solution or a magic potion that will address their scaling issues.

The below table captures the scaling challenges across people, processes, and technology along with the silver-bullet option. The success of the transformation is often measured by output (e.g., number of scrum teams, number of apps on AWS) over outcomes (e.g., change to business metrics).

A typical agile transformation

After spending a few years and millions of dollars, most organizations are left with a value stream that looks very similar to the one pictured below. The transformed value stream is a concatenation of waterfall planning, iterative development, and a long release process. Commonly described as Water-Scrum-Fall, it is the most common result of most transformation programs and is the state of many of the organizations that come to us for help. 


Some would argue that the scrum team is more efficient than the waterfall team that it replaces. However, making such a replacement doesn’t address the core business problem of how to take change to the market. The efficiency that gets introduced into the development process does not increase the effectiveness of the overall process.

This example makes clear the goals of most organizations’ large-scale transformation programs, namely to

  • Adapt quickly to the changing market and/or identify new revenue opportunities

  • Identify and mitigate business risks faster than the market

  • Generate ROI continuously

The challenges of scale have created a mindset whereby most organizations adopt one of the silver-bullet solutions to achieve their goals. 

The VMware Tanzu Labs approach

At Tanzu Labs, we help our customers reach their goals by adopting the same principles and practices that enable us to build successful products:

  • Start small and focus on the most important problem incrementally

  • Prioritize effectiveness over efficiency

  • Gain alignment and create a shared understanding

Start small and focus on the most important problem incrementally

Whether an organization is building products or transforming itself into a successful agile organization, the key is always to start small. The build-measure-learn cycle of product development should be embedded into the culture of the organization, not just be limited to building products.

Prioritize effectiveness over efficiency

A product is successful only once it is in the hands of users, generating real value. That is why before building any feature, we should ask, “Will the customers pay for this?” Customers won’t pay for a product just because the team that built it used scrum or deployed it to the cloud. So organizations need to put in place an end-to-end process that will shorten the time it takes to realize ROI. Addressing just one step in the process will not achieve the same benefit. It is analogous to driving a high-speed sports car through narrow streets with a low speed limit. Instead, organizations should focus on improving the end-to-end value stream. 

Gain alignment and shared understanding

Organizations should build a team of T-shapers who will bring perspective across disciplines. A value stream that involves blind handovers is not going to generate the desired quality outcome. Each member of the team has a role to play, so they need to know not just what they are doing and why they are doing it, but how it fits into the bigger picture. 

Traits of an “agile” organization

A product that stops evolving gets decommissioned very quickly. The same applies to an organization; it needs to continuously evolve and learn over time. There are three traits we see in organizations that have become agile by continuously adapting and improving their business. They are:

  1. Independent product teams with end-to-end responsibilities

  2. Products that get decomposed to ensure teams don’t get bigger

  3. A culture of experimentation, continuous learning, and improvement

Organizations that have such traits will not only be able to evolve, but will be able to do so incrementally. 

The 3 stages of our approach

At Tanzu Labs, we take a systematic approach to addressing the challenges typically faced by organizations looking to make large-scale transformations. The key barrier is the mindset of searching for a silver-bullet solution that will address all issues. Our staged approach takes organizations through a journey that will address their drivers one by one. 

The three stages of this approach are: 

Stage 1: Discover — Identify the early adopter, a function that differentiates the business.

Stage 2: Deliver — Create an atomic unit that models the future organization at a product level.

Stage 3: Expand — Decompose the product to avoid scaling and continuously seed teams to grow.

Stage 1: Discover

Every organization has functions that serve as differentiators between their competitors and themselves. A learning organization identifies new differentiators and ensures they are continuously relevant in the market. At Tanzu Labs, we recommend our customers build products that act as differentiators to the business. 

There are three key reasons why an organization should custom-build products that differentiate them and not use a COTS solution: 

  1. Custom software can go through the build-measure-learn cycle easier than any COTS solution. Its adaptability and the ability to rapidly iterate when using it also translates into a faster ROI. 

  2. One of the key aspects of time to market is the degree of automation across the value stream, especially the testing. A custom software product can be automated easily, reducing overhead and time wasted across the stages. 

  3. Forming a team that can hold end-to-end responsibility is easy with custom-built software. If an organization is using a COTS solution, then they are dependent on the provider to build the capabilities they need. 

A product that differentiates the organization from its competitors serves as a vehicle for the transformation.

Stage 2: Deliver

Once a business function is identified, the next stage is to build a product that will demonstrate return on investment to the organization. This stage is crucial as it will set the model for the third and final stage. The traits of a successful organization should be brought into the atomic unit, which is the seed product team. Many organizations also call their project teams product teams, which creates an illusion that doesn’t translate into the same benefits. 

At Tanzu Labs, we work with organizations to create the atomic unit that addresses the goals they’ve identified. This unit is a combination of product, process, and culture. 

This atomic unit needs to

  • Build the right product by validating which customer problem, once solved, will generate the maximum ROI

  • Build the product correctly by using the processes that will improve end-to-end effectiveness

  • Build the appropriate culture by forming a lean team and providing them the space to experiment and learn in a safe environment

VMware Tanzu Labs is a thought leader when it comes to forming these teams. We help organizations build lean, cross-functional teams that bring together the practices of lean product management, user-centered design, and extreme programming. 

A key component of our approach is the use of T-shaped roles. To that end, the Labs Product team has only three roles: 

  1. Product manager – Responsible for making sound business decisions and providing direction to the team

  2. Product engineer – Responsible for solving the problem in the right way

  3. Product designer – Responsible for addressing customer needs

Narrowing the team down to these three roles eliminates unnecessary handoffs, wait times, and overhead. 

The next aspect of our approach is implementing a culture of experimentation and de-risking. The team uses a data-driven approach to identify the business value of a product and validates it with that product’s customers. During the discovery process, the entire team builds empathy for the user/problem and creates a shared understanding among themselves. The product is then developed through a dual track of delivery and continuous research. Our engineering practices help reduce risk and eliminate waste. They include test-driven development; continuous integration and automated fitness testing; and frequent, small releases to production. 

A Labs designer and Labs engineer pairing (left), and research being done by one of our product managers with an engineer taking notes.

Stage 3: Expand

The next stage is to ensure we can expand the approach across the organization. The key challenge at this stage is to ensure that the expansion doesn’t result in the erosion of the principles and practices that were successfully formed in the second stage. There are two main reasons behind expanding this approach:

  1. A product grows big with more and more features

  2. The additional teams that are formed need to adopt the same ways of working

Once a product is successful, there will always be a need to add more features, expand to new markets, or increase the customer base in the existing market. As the product expands, the team is forced to expand with it. This will naturally result in a breakdown of communication within the team, issues with coordination across teams, the accumulation of technical debt, etc. At Tanzu Labs, we don’t scale products; we instead decompose the products as the problem space grows. This ensures that the products can always be managed by a small team. 

The Tanzu Labs approach is to continuously decompose the products as the problem space they address gets bigger

The engineers support this activity by breaking down the application from a monolith to microservices. It is critical that the technology goes hand in hand with the product evolution.

The other aspect of expansion is to spread the ways of working across multiple teams. At Tanzu Labs, we use the concept of “seed and rotate.” A Labs team works with the customer to help them pick up the necessary skills. Once we enable one team, we move to another team. In the process, we also create multiple teams that can seed other teams. This approach will soon propel an avalanche of product teams, each of which works independently but toward a common organizational goal. For example, one of our customers created 42 product teams in 24 months. For the first three months, the customer had one product team. Within six months they had five teams. By the end of the first year, they had 12 teams. 

    Tanzu Labs’ approach to seeding a product team and rotating its members after a few months

Organizations taking this approach will have a product generating revenue and a team that can continuously drive improvements in a matter of weeks. The approach is then expanded across the organization without any erosion to the principles we used to help them get to this place. A successful effort will ensure all teams in the organization are lean, agile, and customer-focused. 

The SAFe implementation roadmap, by comparison, has 11 steps, the first six of which have nothing to do with the products that will drive revenue. They are merely focused on training, creating gatekeepers for a process, and executing that process.

Organizations want to drive agility in their business in order to stay competitive and relevant in the market. However, they fail because their approach to transformation is time-consuming, expensive, and doesn’t address the underlying issues. At VMware Tanzu Labs, we help our customers become more agile by assisting them with the formation of teams that deliver successful products. With more than 30 years of experience building digital products, we have synthesized our learnings into a systematic approach that helps organizations overcome their challenges and build successful products that drive business agility.

Securing Modern Applications and APIs: Why and How?
Securing Modern Applications and APIs: Why and How?

Announcing VMware Tanzu Service Mesh Enterprise, a new offering to keep modern applications secure and comp...

Why Competing in E-Commerce Means Customizing Your Software
Why Competing in E-Commerce Means Customizing Your Software

How retailers are modernizing applications—and their businesses—with help from the Swift methodology and VM...