Agility is catching fire, and there is growing recognition of its transformational benefits. But moving to an agile operating model is tough, especially for established companies. There are several paths to agility and many different starting points, yet successful agile transformations all share the common elements described in this paper.
Agile organizations are different. Traditional organizations are built around a static, siloed, structural hierarchy, whereas agile organizations are characterized as a network of teams operating in rapid learning and decision-making cycles. Traditional organizations place their governance bodies at their apex, and decision rights flow down the hierarchy; conversely, agile organizations instill a common purpose and use new data to give decision rights to the teams closest to the information. An agile organization can ideally combine velocity and adaptability with stability and efficiency.
Transforming to an agile operating model
Any enterprise-wide agile transformation needs to be both comprehensive and iterative. That is, it should be comprehensive in that it touches strategy, structure, people, process, and technology, and iterative in that not everything can be planned up front (Exhibit 1).
There are many different paths to enterprise agility. Some organizations are born agile—they use an agile operating model from the start. As for others, broadly put, we see three types of journeys to agile: All-in, which entails an organization-wide commitment to go agile and a series of waves of agile transformation; Step-wise, which involves a systematic and more discreet approach; and Emergent, which represents essentially a bottom-up approach.
Born-agile organizations are relatively common in the technology sector (for instance, Spotify or Riot Games1 ), with rare examples in other industries (Hilcorp, a North American oil and gas company, is a case in point). Most organizations must undergo a transformation to embrace enterprise agility. Such transformations vary in pace, scope, and approach, but all contain a set of common elements across two broad stages (Exhibit 2).
First, successful transformations start with an effort to aspire, design, and pilot the new agile operating model. These elements can occur in any order and often happen in parallel. Second, the impetus to scale and improve involves increasing the number of agile cells. However, this involves much more than simply rolling out more pilots. Organizations may iterate among these stages as they roll out agility across more and more of their component parts.
Aspire, design, and pilot
Most transformations start with building the top team’s understanding and aspirations, creating a blueprint to identify how agility will add value, and learning through agile pilots. These three elements inform one another and often overlap.
Successful agile transformations need strong and aligned leadership from the top. A compelling, commonly understood and jointly owned aspiration is critical for success.
The blueprint should, at first, be a minimum viable product developed in a fast-paced, iterative manner that gives enough direction for the organization to start testing the design.
Adopting an agile operating model can alleviate challenges in the current organization (such as unclear accountabilities, problematic interfaces, or slow decision making). Yet a desire to address pain points is not enough; there is a bigger prize. As one CEO observed, “I’d never have launched this agile transformation if I only wanted to remove pain points; we’re doing this because we need to fundamentally transform the company to compete in the future.” This aligns with McKinsey research showing that transformations emphasising both strengths and challenges are three times more likely to succeed.
To build the top team’s understanding and aspiration, nothing beats site visits to companies that have undergone an agile transformation. For example, the entire leadership team at a global telecommunications company contemplating an agile transformation invested a week to visit ING (a Dutch bank), TDC (a Danish telecommunications company), Spotify, Entel (a Chilean communications company), and others prior to launching an agile transformation.2
The blueprint for an agile operating model is much more than an organization chart and must provide a clear vision and design of how a new operating model might work (Exhibit 3). An agile transformation fundamentally changes the way work is done and, therefore, blueprinting also needs to identify changes to the people, processes, and technology elements of the operating model. The blueprint should, at first, be a minimum viable product developed in a fast-paced, iterative manner that gives enough direction for the organization to start testing the design.
The first step in blueprinting is to get clear on where the value lies. All operating-model design must be grounded in an understanding of how value is created in the industry and how the individual organization creates value. This fundamentally links to strategy.
Next comes structure. An agile organization doesn’t deliver work according to a classic organization chart; rather, it can be thought of as a series of cells (or “teams,” “squads,” or “pools”) grouped around common missions, often called “tribes.” The blueprinting element should produce a “tribe map” to illustrate how individuals that are grouped get work done, as well as a more recognizable organization chart to show the capability axis along which common skill sets are owned and managed (Exhibit 4).
Individual agile cells are defined by outcomes or missions rather than by input actions or capabilities. Teams performing different types of missions will likely use different agile models. However, three types of agile cells are most common. First, cross-functional teams deliver products, projects, or activities. These have the knowledge and skills within the team and should have a mission representing end-to-end delivery of the associated value stream. The “squads and tribes” model developed by Spotify and used by ING, among others, is one example. Second, self-managing teams deliver baseload activity and are relatively stable over time. These teams define the best way to set goals, prioritize activities, and focus effort. Lean-manufacturing teams or maintenance crews could be examples of this agile approach. Indeed, more broadly, lean-management tools and practices are highly complementary with enterprise agility. Third, flow-to-work pools of individuals are staffed full time to different tasks based on the priority of the need. Functional teams like HR or scarce resources like enterprise architects are often seen as “flow” resources.
One telecommunications company identified five major activities across their business and selected an agile approach for each: channel and delivery units (for example, stores) were organized as self-managing teams to increase local flexibility with joint accountability; segment ownership, product development, and enabling teams were organized in cross-functional squads and tribes; and centers of excellence for all other activities (including subject-matter experts and corporate support activities) combined flow-to-work and temporary cross-functional teams for specific tasks.Would you like to learn more about our Organization Practice?Visit our Enterprise Agility page
Working in teams may sound familiar, but at scale this requires change across the whole operating model to provide appropriate governance and coordination. The organizational backbone comprises the stable components of an agile operating model that are essential to enable agile teams. Typically, these backbone elements include core processes (for example, talent management, budgeting, planning, performance management, and risk), people elements (including a North Star,3 core values, and expected leadership behaviors), and technology components. In trying to scale up, many agile transformations fail by simply launching more agile teams without addressing these backbone elements.
The final step of blueprinting is to outline the implementation road map. This road map should contain, at minimum, a view on the overall scope and pace of the transformation, and the list (or “backlog”) of tasks.
The five steps of the blueprint form a coherent approach. A commercial insurer in North America used an agile blueprint to accelerate innovation of digital and business processes. It defined a chapter-based organization structure and created a new organization of product managers (who played product-owner roles in agile teams) to guide teams toward business outcomes. They defined a team structure mostly aligned to customer and internal user journeys, with dedicated teams to grow selected businesses. They created a stable planning and performance-management backbone, as well as a culture of risk taking, and they used an 18-month road map to create all the new positions, train personnel in the new roles, and implement the change in full.
Nothing convinces skeptical executives like teams of their own employees having verifiable impact through agile working. For example, one oil and gas company launched a series of agile pilots through which cross-functional teams managed to design wells in 50 to 75 percent less time than the historical average.
The purpose of a pilot is to demonstrate the value of agile ways of working through tangible business outcomes. Early experiments may be limited to individual teams, but most pilots involve multiple teams to test the broader elements of enterprise agility. Nothing convinces skeptical executives like teams of their own employees having verifiable impact through agile working. For example, one oil and gas company launched a series of agile pilots through which cross-functional teams managed to design wells in 50 to 75 percent less time than the historical average.
Initially, the scope of the agile pilot must be defined and the team set up with a practical end in view; this might include deciding on team staffing, structure, workspace, facilities, and resources. Next, the way the agile pilot will run must be outlined with respect to structure, process, and people; this is typically collated in a playbook that forms the basis for communications with those in the pilot.
Scale and improve
Agile transformations acknowledge that not everything can be known and planned for, and that the best way to implement is to adjust as you go.
Scaling beyond a few pilots is no small feat; this is where most agile transformations fail. It requires recognition from leadership that scale-up will require an iterative mind-set: learning is rapidly incorporated in the scale-up plan. In this, enough time is required—a significant portion of key leaders’ time—as well as willingness to role model new mind-sets and behaviors. Agile transformations acknowledge that not everything can be known and planned for, and that the best way to implement is to adjust as you go. For example, a leading European bank first deployed four “frontrunner” tribes to test the blueprint in action and adapted important elements of the blueprint across the delivery enterprise. Such an iterative rollout approach enables continuous refinement based on constant feedback and capability building for key roles across the organization, including agile coaches, product owners, scrum masters, and leadership.
Agile cell deployment and support
Agile scale-up first and foremost requires standing up more agile cells. However, an organization can’t pilot its way to enterprise agility. The transformation should match the organizational cadence, context, and aspiration. But at some point, it is necessary to leap toward the new agile operating model, ways of working, and culture. For large organizations, this need not be a day one for the entirety but will likely progress through a series of waves.
Many chose to start by transforming their headquarters and product-development organizations before touching frontline, customer-facing units (call centers, stores, or manufacturing facilities). It is possible to transform one factory or one end-to-end customer journey at a time, but highly interconnected functions in the headquarters may need an All-in transition approach.
The size and scope of waves depend on the context and aspiration. For example, a large Eastern European bank designed waves of nine months, where the diagnostic, design, and selection for 10 tribes, 150 squads, and 1,500 roles were performed in the first three months and then deployed over a six-month period, launching a new tribe every two weeks. Furthermore, the scale-up effort was a top priority for C-suite executives, which dedicated more than 10 percent of their time to the transformation.
Resources to support new agile cells—for example, availability of agile coaches or appropriate workspace—can often limit the speed of scale-up. Failure to address the support of new agile cells can cause friction and delay in the transformation.
Reflecting on its agile experience before scaling up, one executive observed: “Most of our agile pilots are working despite, rather than supported by, our broader organizational ‘wiring’ [processes, systems, and even beliefs and values] that forms what we call the backbone of an organization.” The backbone governs how decisions get made; how people, budgets, and capital get deployed; and how risk gets managed. Taking an organization to an agile operating model requires that this backbone be transformed (Exhibit 5).
Successfully scaling an agile operating model requires new skills, behaviors, and mind-sets across the organization. This is vitally important and constitutes an intensive phase of an agile transformation. Most organizations require existing staff to take on these new roles or responsibilities, and as such, need a way to build new skills and capabilities. Specifically, any successful agile transformation will invariably create a capability accelerator to retrain and reorganize staff, make the agile idea common to all, and develop the right skills across the organization.
A typical capability journey may well have distinct phases. First, organizations need to identify the number of trainers (agile coaches) required, and then hire and develop them; a failure to do so can cause delay and blockage when the agile transformation extends across the whole organization. Second, as part of building capabilities, the organization must define the new agile roles (agile coaches, product owners, tribe leads, chapter leads, and product owners, for example), along with a clear idea of what success looks like in each role. Third, learning and career paths should be set for all staff, making clear the opportunities that the agile transformation opens up. Fourth, the organization needs to enable continuous learning and improvement across the organization (this will entail a large-scale digital and communications program). Finally, it’s necessary to design and run a whole-organization effort to raise agile skills (often by means of intensive boot camps) and ensure that new staff are onboarded appropriately. Larger organizations often set up an academy to consolidate and formalize these functions.
The importance of investing in culture and change on the journey to agility cannot be overstated. Agile is, above all, a mind-set. Without the right mind-set, all other parts of the agile operating system can be in place, and yet companies will see few benefits.
Focusing on culture and the change team
A culture and change team is an essential coordinating element of an agile transformation. But it is not a traditional project-management office; rather, the emphasis should be on enabling the other transformation elements, helping to remove impediments and catalyzing culture change.
As an example, Roche, a global healthcare company, launched a global leadership initiative as a central component of its transformation to become a more agile enterprise. It designed a four-day program with a combined focus on personal and organizational transformation. More than 4,000 leaders have now been touched by the effort, helping to shift the collective consciousness and capabilities for leaders to deliver the change.
The importance of investing in culture and change on the journey to agility cannot be overstated. Agile is, above all, a mind-set. Without the right mind-set, all other parts of the agile operating system can be in place, and yet companies will see few benefits. In contrast, when leaders and teams have a strong agile mind-set, then a clear aspiration alone is often enough for a successful agile operating model to emerge.
Understanding transformation archetypes
All successful enterprise-wide agile transformations include the elements described above, but there are several different ways in which the elements can be combined and sequenced. As introduced earlier, there are three major transformation archetypes:
- Step-wise. Transforming to an agile organization often feels like a step into the dark for senior leaders. Perhaps understandably, then, the most common transformation archetype shows a clear distinction between the aspire, design, and pilot phase and the scale and improve phase. Many companies will run multiple rounds of pilots and iterate their blueprint several times before fully committing to scaling up across a large part of the organization. It is not uncommon for this process to take one to two years, as leaders and the organization build familiarity with agility and prove to themselves that agile ways of working can bring value in their organization. Organizations may well go through several subsequent rounds of aspire, design, and pilot before scaling up elsewhere.
- All-in. Although less common, an increasing number of organizations gain strong conviction early on and fully commit up front to move the whole organization to an agile model. Leaders from these organizations define a plan to execute all steps of the transformation approach as quickly as possible. Even in these types of transformation it is rare for the whole organization to transform to an agile model in a single “big bang”; rather, it is more common for the transformation to proceed through a number of planned waves.
- Emergent. It is impossible—and not very agile—to plan out an agile transformation in detail from the start. Instead, most agile transformations have emergent elements. Some organizations have chosen to progress their entire agile transformation through an emergent, bottom-up approach. In this archetype, an aspiration from top leaders sets a clear direction, and significant effort is spent building agile mind-sets and capabilities among leaders.
“It’s like this,” one CEO explained. “We are 3,000 people on a giant cruise ship. But what we need to be is 3,000 people in a few hundred yachts. So, how do I get my people safely into those smaller boats?” As is increasingly common, the discussion had moved from if an agile operating model was applicable to how leaders could help their organization transform. Navigating an organization to an agile operating model is not easy. The elements of an agile transformation described in this article provide a guide.
About the author(s)
Daniel Brosseau is a partner in McKinsey’s Montreal office, Sherina Ebrahim is a senior partner in the New Jersey office, and Christopher Handscomb is a partner in the London office, where Shail Thaker is a senior partner.