For an Agile Transformation, Choose the Right People

Authors: Rob Cross, Heidi K. Gardner, and Alia Crocker

CREATED BY A GROUP OF software developers in 2001, the agile methodology, which helps project teams achieve objectives quickly in rapidly changing or unpredictable environments, is now being used broadly throughout organizations. But wanting to be agile and being it are two different things. Our research, which looked at the agile initiatives of scores of companies over several years, reveals that many large-scale ones not only fail to meet their goals but also cause disruption within an organization. A poorly managed initiative can miss critical deadlines, slow product development, and lead to staff burnout, the loss of key talent, and infighting among teams. In one survey of 112 companies that we conducted, nearly 90% reported that they had struggled with rolling out organization-wide agile transformations, even after succeeding with initial small-scale projects.

Why are these efforts going so off track? To identify where unforeseen barriers undermined otherwise well-designed agile initiatives, we employed organizational network analysis—a methodology for mapping informal and formal relationships in order to understand and improve how people collaborate. In total, we studied more than 140 companies, surveyed some 30,000 employees, and interviewed more than 100 leaders. The main problem we uncovered: Traditional practices for framing, staffing, and executing agile projects are ineffective in company-wide initiatives.

Idea in Brief

• The Problem

Agile methodology has been widely adopted in recent years, but large-scale initiatives often disrupt organizations and fail to meet their goals.

• The Typical Causes

Companies often staff an agile team only with stars, overloading them; isolate the team from the main business to protect it, inadvertently impeding its access to crucial capabilities; and dedicate all members 100% to the team, which is unrealistic and unnecessary.

• The Solution

Staff the team with “hidden stars”—people who have lower profiles and are less likely to be maxed out. Identify people who can help the team pull in or provide expertise as needed. Organizational network analysis, a methodology for mapping informal and formal relationships, can help with these tasks.

Where Agile Efforts Go Wrong

In high-profile strategic initiatives, three typical mistakes undermine agile teams almost right from the start.

1. The company staffs teams only with star performers

This approach can undermine other important efforts in the company when it’s taken with agile projects. The problem is that stars are deeply embedded in networks of relationships essential to getting existing work done and can’t disconnect from their prior roles. Even when they’re assigned exclusively to an agile project, star performers are constantly sought out by colleagues, often informally. “Susan, we’re hitting roadblocks with your old account,” a coworker might say. “Given that you know them so well, could you answer a couple of questions about how to position our solution?” The request for help then moves from late-night emails to a few phone calls, and before you know it, Susan has to prepare for and participate in a key client call. The number and range of demands placed on star performers outside the agile project are seldom recognized. Our research across companies has found that overloaded employees are sometimes working on 10 or more projects at once—even if that work doesn’t show up in formal timekeeping databases. (See “The Overcommitted Organization,” HBR, September–October 2017.) The risks of their burning out or failing because they’re stretched too thin are very high.

2. Agile teams are kept apart from the main business to protect them from being contaminated by status quo thinking or killed off

This approach has been popularized by Clayton Christensen’s playbook for disruptive innovation. But isolation can create shortcomings for projects. Yes, it’s true that an agile team needs some autonomy to spare it excessive scrutiny and interference, but complete isolation doesn’t work. Agile teams seldom have all the capabilities needed to develop and execute a new initiative. A team typically has to pull in expertise from other parts of the company to get a big-picture view of problems, understand nuances in different geographies or clients, and anticipate rapidly shifting competitive landscapes. It’s also critical for the team to engage with organizational stakeholders to get timely buy-in for resource requests and implementation plans.

3. All members of an agile team are dedicated 100% to it

The rationale is that total commitment is necessary for team members to cope with the demanding schedule of daily huddles and short sprints while maintaining a laserlike focus on key goals. But it’s unrealistic to expect this from all members. Some initiatives would benefit from the involvement of experts who are so valuable that they don’t need to—or can’t—be pulled off their day jobs. Think of the specialists whose early opinions might shape a project: the regulatory lawyer who spots a less-risky product positioning and the cyber expert who alerts the team to data-privacy threats. Their input is extraordinarily important, but they don’t have to be assigned full-time to an agile team.

Getting Agile Projects Right

In our research we’ve uncovered two core principles that are crucial to assigning the right people to an agile project—and determining what roles they should play.

Staff teams with “hidden stars”

Resist the temptation to assign recognized star employees to key roles. Instead tap hidden stars, who possess the talent and contacts needed to develop and roll out an initiative but have much lower profiles in the organization and therefore are far less likely to be overloaded. An added benefit is that these people often are less steeped in a company’s “This is how we do things here” mindset, so they can bring fresh perspective to a project that’s looking to redefine processes and priorities. Choosing these less-obvious individuals for high-visibility agile teams also allows companies to build a deeper bench of talent.

You can use organizational network analysis (ONA) to identify your hidden stars. ONA analyzes data from internal surveys and electronic communications, like email and instant messaging, and other metrics—for instance, the number of times someone is sought out by colleagues, mentioned, or assigned to collaborative projects—to surface people and patterns that are typically overlooked by both leaders and workforce planning systems. In fact, when we looked at the 3% to 5% of employees who accounted for the most value-added collaborations (usually 20% to 35% of them) in organizations in our research, we found that at least half of those people hadn’t been identified as high potentials in talent management systems. And when we’ve asked the leaders charged with assembling agile teams to list their company’s most in-demand employees, their knowledge has always been shallow: They can accurately name only three or four. When we use ONA, however, we typically get a much more comprehensive list.

Once the leading candidates for the agile team have been identified, firms should do a final cross-check to make sure those individuals won’t have so many formal and informal obligations outside the project that they could derail its progress. ONA surveys can unearth the information you need to do this by asking two questions: (1) Which capabilities do you most need to seek out from others in order to do your work? and (2) To whom do you turn to get those capabilities?

If an otherwise suitable candidate has too many obligations that can’t be off-loaded, you might consider designating her as a “go to” outside expert who can be tapped on an intermittent, informal basis. In fact, that practice proved so effective for one project at a technology company we studied that the firm’s leaders started applying it elsewhere, giving individuals whom teams wanted to tap some additional resources and monitoring how their time was allocated so that they didn’t get bogged down with lower-value work.

Identify highly connected potential resources.

Most agile projects require occasional input from contacts outside the core team who have complementary expertise. But knowing the right people to consult—and when—can be challenging. In our work with high-tech, software, life sciences, and manufacturing companies, we’ve seen that ONA can help companies find three kinds of critical contacts.

Brokers sit at the juncture between silos in a company—such as business units, functions, and offices—and dramatically influence the diffusion of ideas and uptake of plans. They don’t necessarily hold formal cross-silo positions but can help the agile team acquire ideas, expertise, equipment, or funding that its members don’t have direct or easy access to. Because they “speak the language” of disparate groups, brokers instinctively look for ways to connect ideas across the company.

A good example is Jordan, the deputy director of a pharmaceutical company’s R&D labs (featured in the section “Who Makes the Best Team Member?”). Jordan has successfully led many product-development efforts because he has strong ties in both sales and manufacturing and is able to seed his ideas with—and bring ideas back to his unit from—those groups. So even though his heavy demands make him a poor candidate for the full-time leader or even a member of the team, he could be useful to it as a broker. The team could bring him in occasionally to help brainstorm how to frame early-stage problems, discuss specific issues that arise during solution development, help obtain necessary resources, and suggest how to position the team’s output to maximize its acceptance across the organization. Jordan would naturally share those discussions with people in multiple parts of the company, obtaining their input.

Central connectors are deeply embedded in their area of the organization—whether it’s a function, a business unit, or even a floor of a building. Although they may be only individual contributors (such as R&D specialists, data analysts, and supply chain experts) and not in senior leadership positions, they have extensive working relationships with peers, subordinates, and managers throughout their part of the company. They are, in practice, central to their networks. They’re important because they have deep local knowledge of what will work in different geographical or product markets and are influential within their groups. If an agile project team can win the support of a central connector, it can be reasonably sure that his or her entire network will follow suit. Conversely, a skeptical central connector can torpedo a project. So connectors can invisibly affect the speed and ultimate success of innovation projects. This means you should ask for their input both early in a project (to benefit from their experience and understanding of the context the agile solution will be used in) and late (to get their buy-in, which will then spread to others).

Domain experts have subject-matter knowledge that an agile team needs temporarily to tackle challenges. Their expertise may be scientific, technical, related to human factors or the design-thinking process, and so on. The agile team should seek out these highest-profile experts only for must-have input.

Here again, ONA can help. With its insights, a company can avoid putting an already-stretched domain expert on yet another project—or worse, potentially jeopardizing all the projects that person is working on. Unfortunately, we saw exactly that happen in one company. A scientist whose domain expertise was essential to the company’s strategy of developing medical diagnostics and treatments was pulled into a new agile team that was trying to design a therapeutic for certain brain tumors. But because her knowledge was so valuable and rare, she was the go-to person for a range of research projects, and numerous other teams continued to call on her either formally or informally. Soon after she joined the team, she became stretched too thin, and the sponsors of various projects began to fight over her time. The problem reached the board when the company’s highest-priority drug-development project nearly missed a major filing deadline because the scientist had become a bottleneck.

One software company we studied created an “expert library” for a major off-site that several innovation teams attended (an approach that companies could apply more broadly). The experts were brought to the meeting but stayed in a separate room until they were “checked out” by individual teams that needed them. The teams then “returned” the experts so that they wouldn’t dominate the discussion outside the issues they were consulted on and so that other teams could use them. It was a highly effective way for the teams to get insight at critical junctures without making the experts full team members.

Agile methods can accelerate product development and process improvements. They can also help engage an organization’s most valuable employees, deepening their connections and experiences in ways that pay off for the company in the long run. But agile teams are not stand-alone entities; they’re embedded in broader collaborative networks. By taking that reality into account, leaders can design them so that they make the most of talent inside and outside teams, avoid overload and burnout, avert potential disruptions, and achieve their objectives better and faster.