No myth about agile is more rampant or ruinous than the claim that agile companies don’t have to plan. We meet too many executives who fear adopting agile because of this delusion. We also meet too many agile beginners who try to disguise their failings in planning by arguing that they shouldn’t have to plan.
We understand the source of confusion. The agile manifesto states that agile practitioners have come to value “responding to change over following a plan.”1 But that doesn’t mean no planning. It means developing adaptive plans. Conventional bureaucratic organizations create detailed plans—wasting time and resources in pursuit of precision—and assume that executives will implement them to the letter. Agile practitioners view plans more as testable hypotheses, to be adapted over time. Adaptive planners estimate potential benefits and costs so that people can decide on priorities and budgets. Those are the hypotheses. They also lay out the questions that will determine whether the hypotheses are valid or not. Then they use frequent reviews and empirical data to determine whether to change the plans or change the activities designed to achieve the plan’s objectives. Planning, budgeting, and reviewing work together in iterative feedback loops to create an agile plan-do-study-adjust system, just as any individual agile team would.
Improving the agility of planning, budgeting, and reviewing processes is an essential element of creating an agile enterprise. It may improve enterprise agility far more than changing organizational structures or even increasing the number of agile teams. In this chapter we’ll look at how companies achieve that objective.
In 2014, Dell Inc., as the computer company was then known, was in the midst of a multiyear transformation. The previous December, CEO Michael Dell and an investment firm called Silver Lake Partners had taken the company private. Without the pressure of public earnings releases, Dell could lengthen its innovation horizons. It could accept greater variability in short-term profits in return for greater long-term benefits. But the new strategy would require substantial changes in Dell’s then-quite-conventional annual planning cycles.
So Michael Dell decided to implement a new model for strategic planning, budgeting, and reviewing. The firm—known since 2016 as Dell Technologies—now calls it the Dell Management Model. If you were to boil the model down to its essence, it would look something like this: Michael Dell first develops a clear ambition for the company’s future value. Company leaders compare this target to a projection of its value on its current trajectory, and they identify the high-level actions required to close the gap between the two. This process produces a multiyear outlook of revenue and profit and a backlog of initiatives. The leaders then develop a detailed one-year operating plan. While this process happens annually, the team challenges the prioritization and resourcing of initiatives periodically during the year, ensuring that Dell can react quickly to changing customer needs, competitor moves, and information about the results of past actions.
Initiatives in this model move through a life cycle. Each begins as an issue or opportunity to be addressed that would help close the gap between the ambition and the status quo projection. Issues and opportunities with the greatest potential impact and organizational breadth are addressed by the company leaders. These initiatives form a backlog called the Dell Agenda. Issues with narrower scope and lesser impact are addressed by the appropriate business unit or function. After each initiative is identified and categorized in one of these groups, it is assigned an owner, provided initial resources for a team, and sequenced in the backlog. Each initiative team then works through a series of steps: gathering facts, developing alternatives, choosing among alternatives, committing to outcomes, gaining approval to execute the initiative, moving forward with the execution, periodically reporting on results, and ultimately being retired as an initiative by being incorporated into Dell’s regular operations. Company leaders engage with initiative teams to provide guidance or approvals at various points in this life cycle, typically addressing two or three initiatives from the Dell Agenda each month. The model allows for a great deal of flexibility. Whenever a new issue or opportunity is identified at any time during the year, leaders estimate the rough value at stake. If it’s important enough, the opportunity will be added to the Dell Agenda, with an initiative owner assigned, resources allocated, and a place in the sequence established.
An important benefit of the model is focus. The company’s leadership team regularly revisits the Dell Agenda and revises it to ensure that it always includes the highest priority issues and opportunities. Because of this review, the agenda typically has fewer than a dozen active initiatives at any given time. By avoiding the inefficiencies of organizational multitasking, Dell accomplishes much more each year than would be possible with a less focused approach. Dennis Hoffman, Dell’s senior vice president for corporate strategy, told us, “The Dell Management Model [DMM] ensures Dell always focuses its resources on the initiatives that will make the biggest difference to enable our strategic and financial ambitions. Before we started using DMM, we were not always aligned as an executive leadership team on what the most important issues were, and it was harder to make progress on issues that cut across organizational boundaries. Establishing the Dell Agenda has helped us focus as a leadership team on what matters most, while remaining flexible to adjust as new issues arise. Then we can work together to achieve our ambition.”
Dell uses agile approaches in other ways as well. The company has focused on improving customer service and cost effectiveness for many years. For example, leaders in the supply-chain function wanted to improve their ability to plan demand and supply. In September 2018, Kevin Brown, Dell’s chief supply-chain officer, launched two agile teams staffed with dedicated people from several functions. One team was charged with developing and installing a collaborative planning process with the company’s largest customers to foster an active dialogue around upcoming orders and better ensure on-time delivery. The team developed process changes, created new tools, and deployed advanced analytical models. But rather than roll out the new procedures all at once, team members launched a series of small changes in two-week sprints. Then they gathered feedback from customers and internal stakeholders and fine-tuned their solutions. By June 2019 these teams had delivered multiple solutions that were popular with customers and well received by the internal sales organization. “Since we started using agile teams about a year ago,” said Brown, “we have found the agile approach to be a differentiated way to drive fast, high-value change across our operations. The solutions we are developing using agile methodologies are more innovative, more robust, and more accepted by our internal and external customers. We’re now applying agile values to how we run many of our transformation efforts.” At this writing, Dell has scaled up the supply-chain effort to nine teams, expanding the use of agile to continue to improve cost and operational outcomes.
Dell’s agile approach to planning has underpinned an ambitious agenda. Since putting the DMM in place five years ago, the company has integrated the largest-ever merger in the technology industry, exited some businesses to transform its portfolio, gained or strengthened leadership positions in several other businesses, improved customer advocacy, reemerged as a public company, and doubled its enterprise value.
As Dell illustrates, agile enterprises tend to do four things differently from conventional companies:
Budgeting in an agile enterprise serves two main purposes. It provides the controls necessary for the company’s operations. It also directs funds to the areas of highest priority for agile innovation. Bureaucratic budgeters typically devote enormous effort to producing precise numbers. Their budgets last for a year or more, meaning that some unproductive projects continue on until their budgets run out. Meanwhile, critical innovation efforts wait in line for the next budget cycle to compete for funding.
Agile budgeters operate with a different mindset and different procedures, particularly where funding innovation is concerned. They recognize that for two-thirds of successful innovations, the original concept will change significantly during the development process. They know that teams will drop some features and launch others without waiting for the next annual cycle. As a result, agile funding procedures often evolve to resemble those of a venture capitalist: the procedures provide opportunities to purchase options for further discovery. Their objective is not to instantly create a large-scale business but, rather, to develop a critical component of the ultimate solution. This leads to a lot of apparent failures but—critically—it accelerates and reduces the cost of learning. Funding decisions look similar in an agile enterprise, greatly improving the speed and efficiency of innovation. Target Corp., for instance, organized its technology to align with its business capabilities and customer experiences. Its more than 250 product managers are like entrepreneurs charged with achieving measurable business results. Those who deliver stronger returns are rewarded with more resources and responsibility.
While most agile enterprises still have an annual budgeting cycle, it is far less onerous than conventional budgeting, and executives update their budgets periodically during the year to reflect both changing conditions and updated information about innovation activities. This flexibility can provide significant benefits. A leading US financial services firm, for instance, offers automobile insurance to its customers. A while ago, it funded several agile teams to develop the elements of a new capability: enabling customers to find cars to buy on its website and mobile app. The company’s original idea was to include recommendations about what to buy in addition to the search capability. But when the teams tested the idea, they found that customers valued only the search function, not the recommendations. That changed the group’s priorities and allowed one of the teams to be redeployed to other work. In a traditional budgeting environment, the entire project scope would typically have been delivered and the effort to develop the recommendation capability largely wasted.
Agile enterprises typically follow three other practices related to budgeting for innovation:
The planning process should clarify strategy and identify the actions required to achieve a company’s ambitions. Funding the activities most vital to achieving the strategy should be the highest priority. In some cases those activities may require nearly all the available funding; in others, they may leave substantial room for unpredictable initiatives. So every enterprise needs a prioritized, sequenced backlog of investment opportunities. Backlog items come from a wide variety of sources: the planning process, interesting ideas from ongoing agile teams, new customer research, competitive analysis, suggestions from front-line employees, unexpected acquisition opportunities, and so on. Unplanned initiatives may warrant greater funding than ideas that were once priorities in the planning process but now seem to be flailing or losing relevance.
Amazon Prime and Amazon Web Services, for example, were both ideas generated from the bottom up outside the normal planning cycle. Neither looked like strategic priorities at the time, but they quickly rose in importance as their successful growth required increased funding. Failures at Amazon open up other opportunities. When the Fire Phone fizzled, the company had no shortage of innovative opportunities on its backlog to fund with far better returns. (We’ll have more to say about Amazon in chapter 8.)
Agile teams come in two types. Project teams address issues or opportunities that can be solved reasonably quickly, typically in weeks or months. Persistent teams (often called product teams) tackle significant customer opportunities that may take years to address properly. As Jeff Bezos likes to say, “Customers are always beautifully, wonderfully dissatisfied, even when they report being happy and business is great. Even when they don’t yet know it, customers want something better, and your desire to delight customers will drive you to invent on their behalf.”2 As customer needs change and customer solutions evolve, persistent teams will typically pivot dozens of times in a period of years. No one wants teams to come back for approval every time they need to change direction; if they find a better way to offer a customer solution, they should pursue it. (Conversely, if they do not find a good way or the problem is no longer important, the team should move to a different problem or disband.) The longevity and empowerment of persistent agile teams makes them more effective and efficient innovators as they become ever more familiar with one another, with their customers, and with the processes and systems that serve those customers. You can find a deeper treatment of planning, budgeting, and reviewing for persistent teams at the website bain.com/doing-agile-right.
Agile enterprises respect results more than seniority. The pet projects of senior leaders are as transparent as any other agile initiative. The opinions of executives are subject to the same scrutiny as those of software engineers: How could we test that?
With funding comes accountability. Every funded agile activity, whether it be a persistent team, a project, a strategic imperative, or an unplanned opportunity, is responsible for delivering the customer outcome that originally justified the investment. This sounds obvious, but it’s surprising how many traditional budgeting systems spend months or years deciding whether to invest in a project, then never spend a day determining how the investment actually panned out. Agile budgeting is different. Agile constantly questions whether incremental investments are justified. Agile rewards efficiency in experimentation. Practitioners grow skilled in identifying the most critical questions and devising ingenious ways of formulating prototypes to answer those questions. Agile teams fully expect to find ways to either achieve those outcomes or to pass their budgets on to other agile teams that can create greater value for the money.
Of course, different companies face different challenges. So each develops budgeting procedures that fits its own needs. One example is Royal Bank of Scotland (RBS), a company that you’ll read more about in chapter 7. A few years ago, as a core part of an effort to make the bank more customer-focused, leaders in the personal banking division began to create persistent agile teams mapped to specific customer experiences. Unfortunately, RBS’s budgeting, funding, and governance model stood in the way. For one thing, the model was designed to fund only traditional projects. It required tremendous detail on features, costs, and outcomes—detail that took a lot of time to prepare and that left teams unable to adapt as they learned more about customer behavior. Because teams were disbanded at the end of each project and reformulated for each new one, teams rarely got the benefits of members working together for a long time. Finally, the approval process for rolling out changes was onerous, which delayed results and made testing and learning from small changes impractical.
So RBS’s leaders began reshaping their budgeting and funding model. Step one was to create customer business areas (CBAs) focused on a specific set of experiences, such as home buying and ownership. Step two was to establish persistent journey teams within the CBAs, each one focused on one customer experience, such as disputing a credit card charge. Each CBA has a performance agreement consisting of outcomes such as revenue growth, cost reduction, or Net Promoter Score increase, to which the CBA owner commits in return for the requested resources. Each journey owner is given resources for commitments that support their CBA’s performance agreement. This system empowers team members to manage their own backlogs in pursuit of their teams’ objectives. Since it was deployed throughout the RBS personal bank, it has reduced the number of business cases developed in a year from eighty to six, which has freed up substantial time and energy. RBS plans to evolve the model further so that funding for CBAs and journey teams is continuously in place and adjusted gradually as customer priorities and business opportunities change.
RBS also uses a technique it calls scenario-based funding to help ensure that it supports the most promising opportunities. It asks business unit heads to provide a base case request for innovation and investment funding and the associated business value that they can deliver. It also asks them to project the incremental value they could deliver with 20 percent more funding and the value that would be lost with 20 percent less. This process allows RBS leaders to consider how shifts in funding among business units could optimize enterprise business value. Business unit leaders develop their estimates and make budget allocation decisions using the same approach with the product leads who report to them.
Reviewing is an essential part of the plan-do-study-adjust cycle. Quarterly, monthly, or even weekly reviews provide frequent opportunities to compare actual versus expected performance, and to determine whether to change plans and budgets or the activities designed to achieve them. But here, too, agile enterprises go about it differently. Participants share information in a transparent and informal way, avoiding the time and effort wasted in preparing slick presentations. They are far more likely to use reviews to update plans and budgets. Their chief goal is to boost rather than hinder the empowerment of agile teams. Reviewers want to give teams the information they need to manage a full range of business considerations, so teams can do their own reviews of topics that, in a bureaucratic organization, would be reviewed by control functions or other managers. This helps avoid excessive top-down direction.
Finance departments, for example, will always manage budgets. But financial managers don’t need to keep questioning the decisions of the owners of agile initiatives. “Our CFO constantly shifts accountability to empowered agile teams,” says Ahmed Sidky, the head of development management at the videogame company Riot Games. “He’ll say, ‘I am not here to run the finances of the company. You are, as team leaders. I’m here in an advisory capacity.’ In the day-to-day organization, finance partners [are assigned to groups of agile teams]. They don’t control what the teams do or don’t do. They are more like finance coaches who ask hard questions and provide deep expertise. But ultimately it’s the team leader who makes decisions, according to what is best for Riot players.”3
Riot Games, of course, is a digital-native company with a lot of agile experience. But RBS’s personal bank is pursuing a similar goal, adapting its quarterly budget review process to better empower its agile teams. Instead of reviewing project spending and degree of completion versus budget, the quarterly reviews now involve a much more valuable set of discussions revolving around customer business area and journey team performance agreements, including a set of agreed measurable outcomes. Owners report on outcomes achieved and on any that were missed, discussing the reasons and seeking input for improvement. This shift in reviewing focus has contributed to much greater engagement and satisfaction of the owners and their teams. At this writing, the performance agreements of change-the-business innovation teams are separate from those of run-the-business operations teams. But the bank was planning to create a unified set of goals and commitments for both kinds of teams assigned to each customer journey. It was also developing governance changes that should further increase the agility of journey teams. These changes include reducing and accelerating the steps required to approve changes that affect customers and streamlining the reporting of how funds are being used.
Dell—no surprise here—also uses reviews to update plans frequently. Each month, the executive leadership team meeting reviews the results-to-date of some ongoing strategic agenda initiatives. This creates accountability for the initiative owner to deliver promised outcomes. The process avoids the common problem in traditional bureaucracies of projects continuing over many years with little to show for it.
Dell’s agile reviewing process also provides information needed for finance’s management of the company’s annual plan and budget. Finance teams and business-unit leaders develop the annual plan and budget in the fourth quarter of each year, and then they update it twice during the year. The plan and budget include revenue and cost targets by business area, and they reflect the expected impacts of all active initiatives. The process harmonizes innovation and operations teams by having each work toward a shared set of goals. Dell’s reviews thus avoid another common problem with traditional bureaucracies: their difficulty in adjusting annual budgets to reflect the impact of changing conditions.
The right cadence for the planning, budgeting, and reviewing cycle depends on the organization, and particularly on where the balance lies between stability and innovation. Too slow a cycle can lead to stagnation or misdirected resources. Too fast a cycle can create unnecessary work and confusion in operations. Most agile enterprises find that the right balance is to update corporate and business unit plans and budgets at least every few months and at most every month.
The transition from conventional planning, budgeting, and reviewing to agile will initially feel risky to control-oriented executives. It goes to the heart of a company’s financial control, which is a fundamental responsibility of the chief executive, the CFO, and the board. It raises questions about the traditional mechanisms for planning work and allocating resources. It also involves power shifts at every level of management as agile teams take on more responsibility and decision-making authority. Making these changes throughout a large corporation all at once can indeed be risky. But the use of agile principles reduces the risk significantly. Companies that succeed at such a transition make a point of laying out the failings of existing processes and showing how the new model can overcome them. They connect the CFO and other senior leaders to other firms that have successfully made the transition. They pilot the new plan-budget-review model to prove its benefits and then roll it out incrementally, perhaps by business unit or geography.
However they may make the journey to agile planning, budgeting, and reviewing, it is an essential one for any company aspiring to be an agile enterprise.
FIVE KEY TAKEAWAYS