In 2018, Scrum.org and McKinsey started collaborating around a shared purpose: to help companies innovate how their organizations, teams, and individuals work.
In this article, the latest in a series of research and insight papers, we examine the differences between doing work and creating value in an agile context. The findings here are based on interviews with agile practitioners across the Scrum.org community.
How valuable is the work you do? The productivity gains realized from moving to agile have felt great for teams, but are they seeing better customer outcomes and organizational performance from the adoption of agile?
Agile and scrum have never been more widely adopted1 and these methods are delivering results across many performance measures. For example, in our McKinsey Global Survey of 2,190 participants, highly successful agile transformations were shown to result in a 30 percent increase in customer satisfaction and operational decision making, while the speed of decision making increased by five- to tenfold.
Agile approaches ensure continuous improvement and make clear for the team the tasks to be completed clear through a daily and weekly cadence. They also allow for opportunities to reflect and improve on how the work gets done. But here’s the rub: teams that adopt agile often do so with an industrial mindset, focused not on value but on work. When done right, agile can unlock the power of bottom-up intelligence, innovation, and highly motivated teams that own not only the work but, more important, the outcome that work creates.
Often in agile teams, there is attention on completing work to the detriment of a focus on creating value. There are several symptoms of this overemphasis on work at the expense of value. First, sprint or product backlogs include tasks, and status is measured through task completion. Second, efficiency is seen as more important than outcomes with a focus on velocity—which results in the primary aim of sprint planning to fill team capacity for the two-week period. Third, customers are not connected to teams—most team members don’t talk to customers, and customers are rarely present at sprint reviews. Fourth, outcomes are not measured, so there is no clear, measurable definition of success beyond the velocity of the work completed. Producing things faster is the aim, rather than aiming for defined outcomes.
We take the idea of value as being commercial market value (see, for example, “The Liberators” and its piece on value2). There are other kinds of value, however (for example, efficiency, customer, future). For market value, a product’s success is measured by the number of potential users and customers who are aware of it. Invariably, product development involves efforts to increase this awareness, to move into new markets, or to distinguish from competing products. This work creates market value. Given the potential impact on organizational performance for those able to implement successful agile transformations, organizations should be highly motivated to move beyond a focus on work to a focus on value (see sidebar, “What is value versus work?”).
Organizations are waking up to value focus
Organizations are increasingly adopting objectives and key results (OKR) as part of their agile transformations, thereby ensuring that success is well defined (the O in OKRs), understood by the whole team, and measurable. This is emerging as one key component to get teams to focus on value.
Further, there continues to be growing interest in lean user experience and design thinking. Combining these approaches with agile helps to ensure a focus on the end user. A number of recent academic articles explore this topic. Our review of recent academic literature suggests that more than 90 percent of organizations are practicing agile.
An adoption of agile practices should, according to a recent McKinsey survey, correspond to a 30 percent increase in customer satisfaction.3 But we aren’t seeing more than 90 percent of companies getting those returns. Our fundamental view is that many organizations using agile are ultimately doing so to deliver work and not value.
The 2020 update of the Scrum guide4 also made value more explicit. With a focus on value, the guide now includes a new commitment to the product backlog that provides a description of the product goal. The aim was to move away from the idea that the product backlog is an ordered backlog of work where product backlog items are tasks that the team diligently works through. Teams are now more clearly invited to write each backlog item so that it describes a defined product goal. This makes it easier for teams to be self-managing and innovative. More important, it also brings greater focus and clarity to the outcomes and value that teams are creating.
With this reemphasis on value, there are four key missed opportunities that companies can take to shift their focus from productivity to value.
1. Management treats agile teams like cogs in a machine without empowering them to focus on value
The opportunity
There is a systemic leadership gap in defining business problems, setting a vision, and positioning a mission in the context of value. For some managers, agile represents an opportunity to return to a time-and-motion approach to work. But this builds on the knowledge of 19th-century mechanical engineer Frederick Taylor: managers are willing to let agile teams decide how they work but not willing to let go of control to enable teams to optimize the value of what they work on and when.
“Customer value is business value, but many teams focus on output, shipping something, getting a new feature out. They do not engage with the customer enough. They do not experiment with the customer and deliver real learning about what the customer values or not.” —Jeff Gothelf, author, Lean UX: Designing Great Products with Agile Teams
In our global survey of 93 agile practitioners, 48 percent of respondents agree that in their organization, their team’s purpose is handed down to them; they have no say in it. And 44 percent of respondents disagree that team members are empowered to challenge organizational goals. In addition, in the crucial area of budgeting, 65 percent of respondents disagree that their organizations’ budgeting processes are transparent and that a typical team understands how the budgeting process might affect them.
“While I am a coach, and I admire good coaches, agile coaches often frustrate me. They’re often uncomfortable with value metrics and focus on team harmony and culture while underemphasizing business impact. Culture, harmony, and safety are all important, but delivering value is existential. Unless teams deliver measurable business outcomes, harmony is irrelevant and safety is an illusion for the teams and everyone in the business.” —Evan Campbell, chief transformation architect, Gtmhub
The solution
This is about giving teams greater agency and empowering them to make their own decisions. There are three steps:
- Make the organizations’ strategic plans transparent to scrum teams so they can better understand the purpose behind their efforts and how their work fits in.
- Empower product owners to make budgetary decisions.
- Empower developers to make design, architecture, and delivery decisions.
The impact
A large consumer-packaged-goods organization needed to deliver a next-generation product to market in an aggressive time frame. Senior leadership tried the “Tayloristic” model of dividing this large body of work into smaller teams, each of which didn’t see the entire picture and were not empowered to make decisions without running it by a central steering committee (composed primarily of senior leaders).
After a few months, management realized the product launch was going nowhere. So they pushed all decision making (including financial, architecture, and delivery) to their agile teams, providing a clear vision of the customer outcomes they expected to change. They also provided guardrails, such as releasing a product to a customer every few weeks and getting their feedback. Additionally, management encouraged the teams to challenge the status quo and aggressively solved for organizational inefficiencies that this way of working made transparent. The result was one of their best products. It was released in record time by five teams of excited, motivated people who felt they had made a difference.
2. Work is prioritized by the size of the task and team capacity; the team itself is not focused on or measuring value metrics
The opportunity
Teams are not focused enough on creating value, as they don’t have a sufficient understanding of the metrics that define success. It is often easier to “fill the hopper” and have the team start working on tasks that take them to capacity than to reflect on what creates value.
In our global survey, 46 percent of respondents agree or strongly agree that during sprint planning, their teams ensure that everyone is fully utilized, with only 25 percent disagreeing. Moreover, teams habitually define success or feel accountable in terms of activity and delivery as opposed to—or in preference to—outcomes and value. There is insufficient time spent on defining goals for the team, who the end customer is, and what purpose the work of the team is serving.
“Many of the executives I talk to focus on team efficiency and ask me to put in metrics that highlight waste and when people are not utilized to 100 percent. The reality is that by focusing on everyone being busy, they remove the opportunity for working together to deliver great customer outcomes. And when the team realizes that at a review, it is often too late.” —Daniel Vacanti, cofounder, ProKanban.org
The solution
This is about defining success not in terms of activity but in terms of value. Get your teams to think more about value. There are three key elements:
- The product owner should work with management to define success clearly, including measurable metrics with targets that correspond to what customers value.
- Spend time and effort to create a baseline of these metric. This won’t be easy but is the only way to understand whether the team is having the desired impact on outcomes versus outputs.
- Celebrate impact on those metrics as a success instead of only completion of a to-do item that kept everyone busy—100 percent utilization is not a good sign.
The impact
A European telecommunications company had a prepaid-mobile team that was focused on creating new and elaborate offers for their current and future clients, yet they never actually checked to see whether the customers were happy. They quickly realized they were losing customers (the number of active prepaid mobile cards was dropping) and furthermore, they learned they had the lowest customer satisfaction score in the market.
Every two-week sprint, they sought to improve at least one thing that was adversely affecting their internal and external customers; they started measuring what really mattered (in this case, the number of active cards and their relative value) and they looked into internal customer satisfaction scores of call-center employees, as well as the number of calls about their product. All these changes helped them go from position four to position one in their customer satisfaction score, and they realized that their clients wanted one simple offer, not many different ones.
3. Agile coaching is biased toward enabling scrum done right at the expense of value delivered well
The opportunity
While agile coaching is essential for the establishment and smooth running of agile practices according to agile principles, it can focus too much on getting the process right to the detriment of the focus on value. Similarly, scrum masters tend to focus on velocity and speed of decision making to the detriment of making value-based decisions.
In our survey, 54 percent of respondents say their typical scrum master or agile coach spends significant time helping teams do agile “the right way” as opposed to engaging teams in ways that enable them to build “the right thing.” An example of this thinking is a blame game; we often hear, “My team delivered everything they could, but the product can’t be released to production, because the design team, the data team, the testing team, the other development team, the legal team, and the controlling team didn’t do their part. But my team is perfect.”
“Agile coaches frustrate me. They do not dig metrics and rather focus on the team harmony. Team harmony is important but in the context of delivering value. They need to work with the business to drive harmony while delivering real outcomes.” —Evan Campbell, Gtmhub
The solution
This is about scrum masters and agile coaches recognizing and using the already strong correlation between organizational alignment, team empowerment, and the team’s understanding of value that we found in our survey.
There are two key components:
- More than 70 percent of our survey respondents agree that agile coaching helps them gain value from transparency, inspection, and adaptation (empirical process control).
- While agile coaching should help the team understand value directly (for example, by having them focus on the success metrics described above), it can also help to pay attention to broader organizational alignment and transparency that then lead to value.
- Our survey also shows the link between agile coaching and alignment and empowerment of the organization. These, in turn, demonstrate that they are correlated with an understanding of value, implying that agile coaching that targets organizational alignment may positively “move the needle” on value.
The impact
A Japanese pharmaceutical company saw the effects of this firsthand when its agile coaches and scrum masters focused an inordinate amount of time trying to get scrum right. They mistakenly assumed that some common practices in the industry, such as applying user stories and story points, were required scrum practices. However, when they spent time removing these complementary practices—along with several layers of people who acted as proxies between users and engineers—the notion of value became more transparent to their engineers.
Scrum masters and agile coaches started changing their viewpoint, collaborating more with their teams to establish basic customer personas and impact maps for the primary users and customers of their product. They worked through the network of proxies in the organization to bring their teams closer to the customers they defined. This resulted in a profoundly different level of drive from their teams.
The teams, which could get firsthand information about how their users and customers were affected, could autonomously and effectively determine why, what, and how to work every sprint. Removing the network of proxies resulted in better team empowerment, and making customer impact transparent resulted in better alignment with organizational goals. Overall, this resulted in effective value being delivered every sprint.
4. The whole team isn’t engaging with customers enough
The opportunity
Often, the agile team—and, more important, the product owner—are isolated and prevented (by structure, process, or culture) from actually interacting with customers. They become—and feel—like a cog in a machine, unable to engage with the outside world. The product owner turns out to be a poor (but necessary) proxy for interacting frequently with customers. Equally, team colleagues might not want to initiate and maintain relationships with customers, because it is stressful and requires them to leave their work bubble.
This can become culturally embedded within an organization. Many businesses think that they know best and don’t want to engage with customers, preferring to broadcast rather than to listen: “We just need to tell them what’s right.” This might be true, but continued dialogue can help to smooth the transition of the product and also create advocates to whom other customers can relate.
“I hear from my team that they do not need to talk to customers. That they know best. But from my experience, they need to ask better questions. There is always something to learn when you get a customer in the room, and you are listening to them rather than telling them.” —A senior IT leader at a financial-services company
It’s common in many organizations to assume that a product owner is the only one who is supposed to talk to customers; they represent the voice of the customer. Unfortunately, this assumption is another common misunderstanding of both product owner and scrum team accountabilities. The primary accountability of a product owner is to bring transparency to the notion of value and to the bets made in pursuit of that value, through a product backlog and a product goal.
More broadly, a lack of customer interaction means the team is blind to understanding how to create value for the customer; there is often a culture of giving stakeholders a perfect solution and then refining or polishing it further. This approach reduces the opportunities to course correct based on early customer feedback.
The solution
This is about listening widely, deeply, and carefully to customers and finding the right formal way to do this. There are two key stages:
- Mandate that each sprint review has a customer representative. If the team can’t get access to someone to represent the customer, then question the value this work provides and how you can better serve the customer. What review meetings would they attend?
- Ask the team to engage with customers during the sprint—ask them questions! Access to customers and other stakeholders is not owned by managers. Everyone in an agile team should be able to have time with customers or people who represent them.
The impact
A large technology company was moving to a new customer relationship management (CRM) system. It was well known that salespeople used the current system only just before quarterly business reviews and that the real customer data was held by each salesperson. This was diminishing the team’s ability to treat customers well. The company was large, complex, and had many different needs placed on this customer data.
The traditional approach was to embark on a massive requirements exercise, to talk to every stakeholder, and to build a huge and complex CRM system. Instead, they decided to engage a small representative group of salespeople up front, focusing on their needs to get the data in. They also introduced an incremental approach to delivery, giving these salespeople access and seeing if it worked for them. Slowly, they built the CRM system, engaging more salespeople and making them feel that they owned the CRM system.
