베인은 홈페이지 기능 및 성능 개선을 위해 쿠키를 사용합니다. 이와 관련된 더 많은 정보는 개인정보 메뉴에서 확인하실 수 있습니다. 이 웹사이트를 계속 사용하시면 쿠키 사용에 동의하신 것으로 간주됩니다. 

Brief

How to Plan and Budget for Agile at Scale
한눈에 보기
  • The adoption of Agile management is now widespread, with companies in every industry increasing their number of Agile teams. Many of those teams, however, will not produce their expected return on investment.
  • Maximizing their value is critical, and requires a planning and budgeting approach specifically designed to support a large number of Agile teams.
  • By following a handful of best practices, companies can earn better financial returns, improve frontline satisfaction and free executives to focus on strategic activities.

Consider this scenario: A large company is in the midst of an Agile transformation. Its managers have been using Agile principles for several years, and there are now dozens of Agile teams working on a wide variety of initiatives—everything from broad efforts, such as streamlining the supply chain, to more discrete jobs, such as updating a mobile app. Teams are more productive now, and members seem to enjoy the new way of working. Still, one issue nags at executives: Originally, the company expected that Agile would deliver major improvements in business value—something on the order of 50% to 100% or more—but that payoff has not come through.

Sound familiar? Today, many executives are puzzled by just such shortfalls and looking to maximize the financial returns generated by their Agile teams.

Though there are a specific set of best practices that support Agile teams, many companies have yet to embrace them. These practices include talent management tailored to Agile at scale, suitable leadership mindset and behavior, and a flexible IT architecture. Together, they help Agile teams operate at their full potential and deliver the returns that should accompany a successful Agile transition.

One key area is planning and budgeting, specifically adopting a model that effectively allocates and tracks funds enabling Agile efforts. For many companies, a new approach is required (see Figure 1).

Figure 1

Planning and budgeting should be frequent and flexible, but they rarely are

Planning and budgeting should be flexible, autonomous and accountable

The primary goal of any planning and budgeting model is to allocate an organization’s limited resources to the work that will generate the highest returns. When funding a large number of Agile teams, the model must be flexible enough to respond quickly to changes, ensure that the company’s highest priorities continually are addressed, and incorporate input from a variety of constituents, including senior executives, middle managers and frontline employees. And it needs to do all of this while enabling most teams to be persistent, for reasons we will explain later.

Such models emulate the systems pioneered by both digital natives and Agile leaders among well-established organizations, and represent a departure from traditional planning and budgeting. Traditionally, senior leaders tightly control the purse strings, requiring a rigorous business case, multiple stages of approval, and a strict linkage between the allocated budget and a highly specific output before they will fund a project. That may still be appropriate for certain parts of the business, but it has an adverse effect on Agile teams and the returns they can generate.

Innovation is the purpose of Agile, and successful innovation generally comes only after significant changes to the original concept. For an organization to allocate its resources to the innovations promising the highest returns, it must provide Agile teams with the stability and the financial and strategic independence to pivot quickly to new and better ideas. When it is determined that a different Agile team’s mission is more valuable, leaders must also be able to divert funds to that group. In this way, the planning and budgeting process supports flexibility both within and across the Agile teams.

Leading organizations follow three planning and budgeting practices that, when used to fund a large number of Agile teams, increase returns and improve overall results.

  • Fund (mostly) products, not projects. Rather than predominantly funding discrete features or output, persistent Agile teams focus on specific, long-lived products. Measures of success are clear and objective, and product managers decide what to build and how to solve the highest-priority problems.
  • Take a venture capitalist approach to allocation. Instead of a single, cumbersome annual funding allocation, work from less-detailed business cases and reallocate funds more frequently. Investments start small. Additional resources go to ventures that perform well. Less fruitful efforts stop.
  • Close the funding feedback loops. Real data on investment performance helps leaders know how current work is proceeding and make educated decisions about future funding allocations. Leading practitioners determine which business metrics they care about most, then link these metrics to individual Agile team goals, and, in time, report both the value generated and the cost incurred by each team.

Fund products instead of projects

It is common to assign Agile teams to traditional projects—for example, making changes to the company’s website. Each project gets a certain level of funding, with the expectation that the teams will deliver a specific set of changes by a fixed point in time—generally the end of the fiscal year or quarter. Teams scramble to deliver a good enough version by the deadline so that they can check the box on each item in their scope of work, but the result often is not as high quality as it could be and turns out to be less valuable than anticipated. This could be because the original ideas were not responding to customer needs or because market requirements changed in the months (in some cases, years) since the project began. Whatever the cause, the teams end up frustrated, as do the executives who funded the projects. When the next budget cycle comes around, many of the teams will be broken up and reconfigured to align with new projects, often unrelated to what they worked on last year. Social bonds formed over time are lost, and productivity and team morale both tend to dive as team members adjust to their new assignments and unfamiliar environments.

That is how things often work today, but contrast that approach with a model that aligns Agile teams not with rotating projects but instead with persistent products. The product is typically a customer experience, business capability or technology platform owned by one or multiple Agile teams. Rather than a project with a fixed start and end date charged with adding a specific set of features to the website, as in the prior example, a product-focused approach to that same work might assign persistent Agile teams that own and improve their different parts of the website. Each team (or group of teams) might own a different aspect of the customer journey. For example, some teams might focus on making it easier for customers to find the products they want, while others concern themselves with the checkout experience, and a third group oversees returns and exchanges.

This kind of product-centric approach organizes and funds the work differently. Funding and incentives for product teams align with a set of specific business outcomes, such as decreasing the time it takes customers to check out on the website. The product managers and their teams autonomously define what they should work on and then execute their plan. Because products, unlike projects, exist indefinitely, teams can be stable for years; this consistency dramatically improves productivity and employee morale. Funds are not tied to a specific set of project specifications. Rather, teams have a backlog of work that constantly evolves to focus on the highest-priority initiatives based on business results and market demands so that product managers reallocate funds to the most valuable items in the backlog as necessary. This funding model is a good match for Agile, which breaks up large initiatives into small, manageable modules. Managers can reward teams that deliver good results with higher compensation or larger funding allocations. Ultimately, business outcomes improve.

Companies across a variety of industries now organize their Agile teams using products rather than projects. In health insurance, providing exceptional customer experiences is so important that one health plan has assigned evergreen Agile teams to address critical aspects of its customer journey, such as finding a doctor. To ensure a seamless experience across channels (such as the website, mobile app and call centers), multiple Agile teams work together under the unified vision of a single product manager who determines priorities and how much funding each team should receive. As the insurer’s architecture continues to improve, single teams will be able to own an experience across channels. In financial services, USAA takes a similar approach, using products that align with member needs, such as changing an address or making a deposit. Retailer Walmart also focuses on products, attaching Agile teams to business capabilities, such as human resources and digital marketing.

Moving to a product model (rather than projects) requires investment and organizational change. Companies will likely need to hire or train qualified product managers. They may also need to align their IT systems to the products to avoid multiple software-focused Agile teams working on the same code at the same time, which would increase the likelihood of errors.

Organizing and funding the majority of Agile teams around products positions them to deliver dramatically better results, but not every Agile team should focus on products. A project focus is appropriate when requirements are fixed or the need for innovation is episodic.

Allocate like venture capitalists

Most executives dread the annual funding process, which often starts nine or more months ahead of the fiscal year. It involves countless meetings spent trying to decide how much money to allocate to something that their customers won’t even see for 18 months and requires making major decisions based on little more than assumptions. Confidence in the expected return on investment (ROI) is typically quite low.

This approach is OK for “keep the lights on” activities and other work that delivers highly predictable outcomes. Higher-risk and higher-return Agile innovation work is best supported by a model similar to that used by venture capitalists.

This starts with a lightweight initial allocation process that requires less executive time and that does not waste organizational talent and energy on business cases that are overly detailed and falsely precise. Many funding distributions are small by design in order to maintain flexibility. Larger distributions come later, based on demonstrated results. Check-ins occur throughout the year and can trigger additional fund releases or shift funds from one product to a better-performing investment that has passed certain tests (see Figure 2).

Figure 2

A flexible annual allocation process will include midyear reallocation decisions

One of the greatest benefits of this model is that instead of waiting until next year’s funding cycle, it gives organizations the flexibility immediately to pull the plug on bad ideas so that they can execute on the good ideas generated midyear. This can usually be accomplished while keeping the Agile teams focused on their product. On the occasions when resources must move from one product to another, managers should keep team members together whenever possible to maintain the benefits of team persistency.

For companies accustomed to traditional planning and budgeting, this approach requires a change in both the mechanics of funding and executive mindset. Tests designed to accelerate learning, avoid major failures and support ROI in the longer term need support. Leaders must support work that will not always immediately demonstrate positive ROI and relinquish some decision making to product managers, giving them the autonomy to prioritize their backlog and make funding decisions up to a certain dollar amount. This can be an uncomfortable change for executives, but most quickly realize that enabling those who best understand the work to make quicker decisions will deliver business value. This also frees the executives themselves to focus on more strategic activities.

Google successfully employs aspects of a venture capitalist approach to funding. In addition to making quarterly allocations to the initiatives making the best progress on their annual goals, leaders set aside pools of funds for good ideas that bubble up between quarterly budget meetings. Valuable initiatives do not have to wait, which is an explicit acknowledgment that individual contributors from the Agile teams will generate some of the best ideas.

Close funding feedback loops

Taking a venture capitalist approach and holding product managers accountable for the business value they deliver is not possible without a well-structured “closed” feedback loop. Closed feedback loops start with fund allocation, then measure how investments perform and finally enable decision makers to take action based on demonstrated results (see Figure 3).

Figure 3

A closed feedback loop is critical to Agile planning and budgeting

When companies do not have all three elements in place, their feedback loops are “open,” with minimal or no performance information going to the decision makers for budgeting. Open feedback loops typically provide leaders with status reports that are difficult to tie to real business value or the originally promised ROI. Without better insight into which funding allocations succeeded and which failed, executives’ ability to avoid bad investments and pick future winners cannot meaningfully improve.

In contrast, a closed feedback loop measures real business results. Closing a funding model’s feedback loops requires some effort, but it is conceptually straightforward.

  • First, senior leaders select a handful of the most important business metrics that Agile teams should try to improve—for example, mobile app revenue.
  • Second, product managers and their Agile teams identify metrics the team can affect that will benefit the most important goals. For example, increasing the number of categories of goods that the average shopper purchases from a retailer’s app will increase total mobile app revenue (see Figure 4).
  • Third, management creates processes (automated when possible) that track improvement in those metrics and shares the results with business, IT and finance department leaders who then decide how to allocate funds to the Agile teams.
Figure 4

How Agile team metrics can support a series of business goals

To help its Agile teams close their feedback loops, the health plan created a team of experts dedicated to helping product managers identify which metrics to focus on, ensuring that their backlog includes items that will demonstrably improve those metrics and then validating the actual business results achieved. For example, the “find a doctor” Agile team mentioned above knows that increasing the clicks on certain search results on the mobile app helps lower total medical cost, which is an important metric for the entire enterprise.

With a clear understanding of how an investment has performed on key metrics, business leaders can more accurately determine which groups merit increased funding and which should have their funding reduced or withdrawn. They can divert resources toward specific business outcomes or reward teams for a job especially well done. Over time, as more data becomes available and improves in quality, they can further improve their chances of identifying winning ideas.

Looking forward

Every company wants their Agile teams to generate the highest possible returns. Very few actually employ a planning and budgeting model that enables them to do so. While companies cannot implement a new planning and budgeting model overnight, they can make improvements that demonstrate tangible value relatively quickly. Companies can roll out a new planning and budgeting model in less than a year provided executives have thought through the drawbacks of their current approach and determined which aspects of this critical process to improve before their next funding distribution.

Darren Johnson is a principal with Bain & Company, and he is based in the firm’s Washington, DC, office. Steve Berez is a Bain partner and a founding member of Bain’s Enterprise Technology and Agile Innovation practices; he is based in the firm’s Boston office. Fabian Delava leads Bain’s Agile Innovation practice for Europe, the Middle East and Africa, and he is based in the firm’s Brussels office.

태그

베인에 궁금하신 점이 있으신가요?

베인은 글로벌 리더들이 중요한 이슈를 해결하고 기회를 놓치지 않도록 지원합니다. 고객사와 협력하여 지속되는 변화와 성과를 창출합니다.