When scaling Agile, engaged self-aware leadership matters. A lot.

Generally speaking, what works for one team or group of teams within an organization may not work elsewhere because no two teams and no two organizations have identical cultures. As a case in point is the well-known Spotify approach to scaling Agile that emphasizes the role of culture and people.³

In its approach to Agile, Spotify relies on success factors through a cultural prism more than a technical prism—decentralized team-driven and bespoke decision-making, increased transparency, fostering a culture of experimentation, risk-taking, shorter feedback loops, and servant leadership. In this culture, rapid failure is seen as a necessary premise to better products, happier customers, and more engaged employees.

Many companies have tried to follow “the Spotify model.” Some succeeded, some failed, but most missed the point that it was never intended to be a model, per se.⁴  What works for Spotify may not work for other companies.

To further this idea, Professor Danielle Wood of MIT speaks to how any given organization may have a wide variability of cultures across teams and groups of teams simultaneously. Drawing in organizational theory, she calls them “ambidextrous” organizations. As Professor Wood states, “There is a concept called ‘ambidexterity’, [which] says some organizations can actually operate with the two extremes at the same time. They can be exploring and exploiting at the same time, and they can be both integrated and differentiated at the same time in different styles.”⁵ Her second key point is that the underlying characteristics of an organization may, themselves, vary over time. Put differently, an organization’s ambidexterity itself evolves.⁶

What the Spotify example and Professor Wood’s formulation, among others⁷, suggest, ultimately, is that leaders who want to scale Agile successfully need to understand the underlying—and ever-changing—cultures that exist within the organizations they lead and apply Agile accordingly.

To be sure, formal Agile enterprise frameworks are prevalent, but many organizations find that they can be too rigid and eventually outgrow them. While such frameworks are, perhaps, helpful to start along the scaling journey, they are not by any means the only tool in the tool-belt, and leaders driving toward innovation are always evolving their thinking and philosophy along with the needs of the market and their respective organizations. Indeed, for leaders anything less than such vigilant self-awareness runs the risk of applying Agile in ways that do not achieve optimal outcomes.

When leaders cling to orthodox leadership practices, Agile scaling might be constrained. The CEO of a British insurance company discovered first-hand just how traditional thinking inhibits Agile transformation: “The hardest thing so far has been putting Agile into an organization. I had a very ‘old school’ head office: product, marketing, pricing—those core central areas. They operate in a hierarchical, traditional format. We put in an enterprise-wide Agile model. We went from zero to five on a scale of five and low and behold, it didn’t work, only in patches.”⁸

The DNA of many organizations, even today, evolved from and is still defined by the practices of the first, second, and third industrial revolutions: Management values that tend to promote silos and isolation, reward meeting financial goals over value creation, rely obsessively on traditional cost-focused measures to gauge productivity, discourage ideation, and punish failure even if it serves a larger good. Values such as these are incompatible with Agility culture.

Successfully scaling Agile requires leaders to combat fear of lost power, uncertainty, and power vacuums that can erupt from new ways of thinking and doing. When a rigid, legacy-intensive organization decides to implement and scale Agile, it can result in friction and discomfort if leadership remains indifferent.

How leaders create an environment in which Agile can thrive at any scale

Successful Agile leaders understand that successful scaling of technical agility at the team level, if done correctly, could help engender a kind of “enterprise agility” that transforms the entire organization. Here’s how leaders can better support Agile teams:

Because many, if not most, organizations are more than one thing, leaders should view each team as unique and always evolving. Even though Agile started as a shared set of values, what it should advance is what makes every individual, team, and, ultimately, each organization, unique. Leadership should allow that uniqueness to emerge. Homogeneity is antithetical to an Agile culture because context dictates culture, and every team has its own context.

Leadership needs to be willing to find what works best for each team and group within the larger organization and apply Agile accordingly. In other words, leadership should exercise self-awareness.

Leaders succeed when serving as partners or “servant leaders” to Agile teams—and do not when teams serve them. As Ben McCormack, Technical Director, Office of the CTO, at Google Cloud said, “If I'm a software engineer or a product leader, my organizational position may not be that high, but ultimately I am where value is delivered to the organization. I think leadership and management should recognize that they’re not the people that deliver value. They are there to support that creation of value and delivery of value.”⁹

This means forming a closed-loop relationship with teams when caring for and feeding the Agile initiative (figure 1). This may also mean letting go of fiefdoms, image, long-term power structures, and self-importance—another exercise in self-awareness. Leaders should trust and promote a culture of learning and experimentation. Leaders and organizations should empower, trust, and listen to their teams and be willing to lean into uncertainty.

Manoj Raghunandan, Global President of Self-Care and Consumer Experience Organization, Johnson & Johnson Consumer Health summed it up by saying, “I think if you do a really good job putting forth your intent, and you live into the principle of empathetic leadership and truly listen to your people, I think you can get there, but you’ve got to meet people where they are.”¹⁰

Leaders should reimagine how they measure outcomes. Conventional organizational systems use measures such as units of work (productivity), number of product releases, cost reduction, and other process-based metrics aligned to predictable budgets. This is not consistent with an Agile approach, which focuses on outcome-based metrics, such as objectives and key results(OKRs), net promoter score, customer satisfaction score, team happiness, value delivery, etc.

Fundamentally, Agile is about creating small increments of value to benefit the product end user and experience. That may mean failures in a conventional sense or successes in ways that cannot easily be captured. For example, instead of measuring quantitative outcomes like time taken for product development, a company could measure qualitative outcomes like the team’s ability to communicate and solve problems. It could also mean a mindset shift that promotes learning from failures without judgment—even given negative outcomes.

Paddy Crooks, from Deloitte Australia, envisions a strong parallel between people who adopt OKR measures and companies that are Agile. “The reason for that is the OKR mindset is really around ‘What are you trying to achieve?’ It’s not prescriptive around how I expect you to achieve it. I as an executive would put my objectives forward to my team and my team nearly self-selects how they’re going to help me achieve those objectives, and that then becomes their OKRs, and so it helps generate an Agile sensibility.”¹¹

A successful move to Agile will shift the measurement story from cost to value and, ultimately, meaning. A strict “cost efficiency” story misses the opportunity to think about what is possible in serving customers and to innovate. Value-oriented measures, on the other hand, focus on ways technology imparts new benefits to the customer. And measures that speak to meaning capture how well the employee is connected to the work in better ways.

Today, most workers want to derive purpose and motivation from their jobs, and, when they achieve those things, they typically give more to their roles and teams. Meaning is what drives many of today’s workers to explore, experiment, connect, and innovate. Few traditional KPIs are geared to concepts like customer delight, new product launches, market penetration, or learning—the very kinds of measures that can drive Agile culture.

Figure 2 depicts one way that organizations might classify how to measure outcomes within an Agile context.

Any new approach to measuring outcomes, however, should be intentional, balanced against traditional measures, and guided by leadership.

Leaders need to know what objectives they’re trying to achieve from Agile scaling initiatives and choose metrics that align accordingly. For example, a big challenge for IT leaders today is retaining and energizing their workforce, especially given the Great Resignation.¹² Thus, OKRs related to team turnover and team happiness may be important measures of success. Our survey data suggests (figure 3) that when an IT workforce is considering the future of cloud, increased Agile maturity can improve workforce sentiment and perhaps retention. In fact, organizations that do Agile well seem to feel more triumphant, full of pride, confident, and have greater peace of mind about the future of cloud than those that don’t, as respondents’ feedback depicted in figure 3 suggests. Non-Agile organizations express greater uncertainty, stress, fear, and panic. Ultimately, leaders need to choose the measures and metrics that matter when scaling Agile and help create the atmosphere to achieve them.

A deeper look at figure 3 also shows that the most powerful emotion about the future of cloud for respondents is confidence. But it is interesting and perhaps significant that confidence is also the emotion where there is the largest absolute gap between Agile (strongly and moderate) and non-Agile organizations. This may point to a quick payoff for those who are only in the relatively early and mid-stream phases of their Agile scaling journeys.

We often hear about Agile being tied closely to product innovation objectives, and while Agile vs. non-Agile can advance many innovation objectives, it may help more against certain OKRs and value measures than others depending on the context. For example, figure 4 below shows that strongly and moderately Agile respondents report that they more successfully drive cloud innovation across an array of value outcomes verses non-Agile respondents. This is especially so in such areas as “developing new ideas, approaches or methodologies”; “mitigating business and regulatory risk”; and “expanding existing product/service revenue”. However, our interviews with SMSs also suggested that different modes of software development—cloud vs. noncloud, packaged vs. nonpackaged, etc.—should also be considered when determining if an Agile approach is most appropriate and most aligned to the value outcomes the organization is looking to achieve. In other words, in choosing OKRs, context is key.

What leaders should keep in mind as they scale Agile

Even when done successfully, scaling may introduce new challenges. Eventually, with each additional team, Agile at scale could introduce new interdependencies and complexities that mirror the structural challenges and characteristics of the organization itself. This is one of multiple challenges that organizations may face as Agile reaches critical scale.

Amazon is one of the pioneers in scaling Agile and was the creator of “2-pizza teams” for agility in software development—that is, teams limited in size to those that could be fed with two pizzas. As the number of two-pizza teams grow, however, companies can begin to experience the challenge of bureaucracy and rising overhead costs to manage them. Amazon discovered that two-pizza teams worked best primarily in areas like product development and established a unique balance between standards and autonomy: Each two-pizza team now has the freedom to develop products on their own that can interoperate with the core platform business.

In other words, as you scale, it may help to avoid too much governance and control and develop a common set of agreed-upon development standards to allow for baseline interoperability across scrum teams, if that makes sense for your organization. This way teams can operate independently to create new services since they’ll be compatible based on already agreed-upon standards. These “single-threaded leader teams” can help ensure that leaders have the “skills, authority, and experience,” according to Amazon, to manage teams focused on one job at a time (irrespective of team size).¹³

Another potential unintended scaling consequence is losing the bigger picture to the two-week sprint cycle. While organizations can benefit from continuous improvement, they should make sure they maintain the time and space to adequately evaluate much larger shifts in markets and customer needs. The Agile approach is to think in small, yet frequent increments of progress, which can limit bold, longer-term break-through innovations, obscure rising overhead, or cause teams to miss the mark as markets shift. Short-term thinking can muddy the big picture.

To overcome this challenge, Amazon introduced the “working backwards” approach where the team first drafts out a fully realized vision of a proposed product, gains buy-in from stakeholders, and then initiates code writing and product assembly.¹⁴

Across organizations more generally, as Agile scales successfully, increasing focus on core Agile teams may also engender a feeling of resentment among those in non-Agile roles who feel that Agile teams are part of a “favored class.” Organizations that mitigate the “haves vs. have nots” culture may, in fact, help inspire an Agile sensibility even among support functions that are not part of the core Agile initiative by engendering an overall enterprise-wide agility.¹⁵

Beyond these challenges, there are practical things that leadership can keep in mind as they figure out what works for them:

• Not every process or problem requires Agile. Don’t look at Agile as a panacea. Agile reveals problems; it doesn’t solve them. Assess if your organization (or any part thereof) really needs Agile or if it’s suffering from “shiny object syndrome.” If you can’t express the work in ways that measure outcomes in units of value, perhaps it is not a good candidate for Agile, much less Agile scaling.
  
• If you have never done Agile before, start small with passion. In other words, start slow to go faster, otherwise you’ll end up going slower. Before thinking big, consider a single “lighthouse” team that can incubate what works and doesn’t work. An Agile activation office can serve as a passive repository of learnings in the early phase of the scaling initiative, provided such a group would not interfere with the natural flourishing of the scaling process. Create a clear and consumable vision—a roadmap that is not just for the C-suite but for the entire organization. As Awais Farooq, SVP of Strategy and Transformation at Crawford & Company, said “It’s about accepting that we're not going to have this big-bang launch of a plan. It's going to be in small bites. It's going to be consumable. It's going to be an incremental focus on what we can deliver in a given period with measurable milestones.” 
• Define success metrics that capture the essence of your desired transformation and measure incremental business value. But remember that you live in the real world.  Standard KPIs and other metrics speak to a “Waterfall” sensibility and constrain Agile scaling. Transition from metrics that use terms like “cost” and “return” to terms that describe value outcomes and meaning. Such may require the organization to rearchitect work processes that align with the use of such value metrics. As Deloitte Australia’s Paddy Crooks puts it, “All the companies that I know that are Agile, live and breathe OKRs. It’s just like, don’t bring me a project unless it’s got an OKR-attached concept.”¹⁶

Even as you increasingly rely on metrics that reflect an Agile sensibility, you will likely need to find ways to translate such metrics into terms that an outside stakeholder can understand.  Such translation is not without risk. In so doing,  you may find yourself, perhaps unwittingly, making unwelcome tradeoffs between the good of the organization and the good of the product as some of the success that Agile metrics reveal may not necessarily be captured by way of traditional “bottom line” metrics.

Understand that Agile is a journey and not a destination

Successful Agile organizations are learning organizations that encourage fast failure and faster recovery. The organizations that are most likely to fail in achieving an Agile culture are the ones that are not giving permission for Agile teams to fail themselves. And for Agile, even when it appears to work, there is always room for improvement. It should never end. 

What Agile does, ideally, is allow organizations to better operate within a larger global business culture while inspiring Agile team members to do their best work within their individual microcultures. But Agile, at any scale, is only as effective as its leadership’s ability to let Agile be Agile, applied in ways that are tailored to the organizational and individual team DNA cultures at any given point in time. It’s often not an intuitive fit, but Agile’s rewards are numerous for the intrepid leaders who adapt to its needs rather than the other way around.