Not Being Curious about Management’s Needs

We’ve all been there: You’re working with a manager who is against adopting Scrum. They put up roadblocks and try to maintain control and oversight over areas that Scrum teams should handle for themselves, such as architecture, design, and testing. They’ll often mandate technical solutions to the Scrum team, regardless of whether the team members agree that it’s the right approach.

It may seem like the manager is trying to make your life as a Scrum master more difficult. They aren’t.

Unfortunately, Ryan and Todd have both heard countless stories from Scrum masters about impossible-to-please managers who “just don’t get it.” And we admit that we’ve voiced these complaints ourselves. Eventually, we decided to take responsibility for such situations, and you can too.

If a manager is putting up roadblocks and resisting change, stay curious. Consider what would have to be true for someone to display the “difficult behavior” you’re seeing from this person. If you’ve followed our advice from the previous section and have fostered a relationship with this manager, ask them what they are trying to achieve.

When the person gives you an answer, truly listen to what they have to say, and then pause before responding. There have been many times in our careers where we wish we had taken a moment before responding. If the manager says something about Scrum or the way a team works that goes a little outside the tenets of Scrum, pause—instead of trying to immediately rebut what they just said. Think of a question you could ask to get to the core of what they’re trying to achieve. The question could be as simple as, “That sounds interesting; what does your idea make possible?”

Staying curious (by asking questions instead of passing judgment) is how you fulfill your role as a servant leader. In situations like this one, you’re providing coaching to those involved in the Scrum adoption—specifically, a manager. Asking questions helps you get insights from the manager about what they really need.

Here’s an example of how this technique once worked for Ryan: He was working with a manager who insisted that every Scrum team in the organization set up their team boards the exact same way. It would have been easy to instantly reject this demand, and argue with the manager about how this policy wasn’t in-line with Scrum. But instead, Ryan paused and asked, “What does a consistent team board format give you?” The manager explained that it helped him understand how the projects were going—which is a totally reasonable thing for a manager to want.

This exchange led Ryan to invite the manager to the next sprint review to hear from the Scrum team and stakeholders about the project’s progress. The manager attended the meeting and, afterward, decided that he’d rather get updates directly from the Scrum team during sprint reviews, as that gave him all the information he needed. And he agreed to let Scrum teams arrange their team boards however they liked.

Staying curious and focusing on the needs of others can take some practice. Take some time to develop questions you can use when you need to pause and remain curious. Here are a few more to get you started:

• Which decisions would you change based on that information?
• What kind of new decisions can we make based on this change?
• What does success look like for this change?

Even when you have a mental stash of such questions, staying curious isn’t always easy. During their careers, Todd and Ryan have encountered many scenarios where maintaining curiosity was particularly challenging. Let’s explore a few of the most common of these scenarios and discuss ways to navigate them.

Focusing on Resource Utilization

Remember our discussion of Taylorism in Chapter 2, ​Why Scrum Goes Bad​? If managers in your organization frequently ask about resource utilization, that’s a clear sign that they’re still influenced by Taylorism. The concept behind 100% resource utilization is a throwback to the belief that, in order to maximize efficiency, an employee’s workday must be completely filled with tasks they need to complete.

We’ll suggest some ways to work with management on their “getting the most out of people” concern in a moment. But first, let’s tackle a secondary myth that arises when management has resource utilization on the brain.

Many managers think that a good way to keep workers busy (a.k.a. 100% utilized) is to spread the workers’ time across many projects. This strategy has what some managers consider an added benefit: It means that managers don’t have to make ordering decisions about their project portfolios. They can simply start every project they have slated in the annual budget at the same time ,and spread workers out across the projects.

We’ve spoken quite a bit about you being curious, but it’s equally important to raise the curiosity of others. Transparency goes a long way toward dispelling this 100% utilization myth, and so does making managers curious about other ways of thinking. If you believe that management is avoiding making ordering decisions about their project portfolio, try showing them connections between corporate goals and the various projects that are in flight. Here are some steps to get you started:

1. Invite managers and internal stakeholders into a conference room to discuss goals and projects. If gathering them all at once isn’t possible, seek them out one by one to get the data you need for this exercise. In the event you can’t wrangle everybody, be sure to share the results of this exercise with all of management.

2. Create a list of the corporate goals that that your organization is currently investing in.

3. Summarize these goals on large sticky notes on a wall.

4. Next, create a list of every project and initiative currently in-flight in your organization, and write each one on a large sticky note.

5. Place each project/initiative sticky note next to the corporate goal that it supports. If it supports more than one goal, place it under the one that it’s intended to impact most.

6. If any project/initiative doesn’t directly map to a corporate goal, place its sticky note on a different wall than the one with the project-goal pairs. These projects/initiatives are likely ones that were created just to keep workers busy, not to further a corporate goal.

7. Ask the participants to reflect on how the projects that don’t support the corporate goals could delay the delivery of more valuable projects. This can help managers see how trying to keep people 100% utilized can actually prevent corporate goals from being realized, and make them more interested in creating policies that focus teams around corporate goals.

Ryan used this exercise at a company in the Midwest to help stop work on over 100 in-progress projects that were created just to keep people busy. Not surprisingly, with more people available and both management and the people doing the work having a clearer focus, the higher-priority projects began to finish sooner than expect.

When management believes that people should be 100% busy at all times, we Scrum masters have a chance to pique managers’ curiosity so they can find new ways of managing work. On an assembly line (the kind of work Taylorism was designed to optimize), it makes sense to limit downtime and to optimize how much work people can achieve. But professions such as software development require knowledge workers, not factory workers. In order to successfully perform knowledge work, people need time to think and space to focus.

As we’ve mentioned, 100% resource utilization often means assigning people to multiple projects. For example, someone might be told to spend 25% of their time on project A, 25% on project B, 25% on project C, and 25% on project D—as if people can split their brains into quarters. Being 100% busy removes the ability for teammates to work together. Alas, this practice is still common today. Fortunately, some transparency can help managers see that spreading workers over many projects actually takes a toll on productivity.

Ask the members of your Scrum team to track how often they task-switch, and then share the results during the next sprint review (you invited management to the event, right?). Managers are often unaware of how much time is lost as people try to multitask. Presenting this info can help encourage management to rethink their 100% utilization policies. Real data often piques curiosity.

Better, Faster, Cheaper—Who Cares?

Boss:

Look, you can sell me on the Scrum theory all you want, but if Scrum isn’t better, faster, and cheaper than what we’re currently doing, we won’t invest in it.

When Ryan heard this comment, he got defensive. He channeled his frustration into creating a presentation called “The Business of Scrum: Better, Faster, Cheaper,” which he then delivered at many conferences over the course of the following year. The goal of his talk was to prove his boss wrong. Ryan was resisting applying common business goals to Scrum. What he should have done instead was actually listen to his boss and consider why his boss thought about Scrum in those terms. In other words, Ryan should have stayed curious. Doing so would have saved him a lot of time and travel expense!

Ryan’s boss was simply using a different lens to explore the benefits of Scrum. Truth be told, after a year of giving his conference talk, Ryan was forced to agree. A moment of self-reflection led Ryan to think about why Scrum actually is better, faster, and cheaper than traditional ways of working. Here are a few reasons that he came up with:

• Scrum creates opportunities to make new decisions based on frequent feedback. That’s better than past practices that valued completing a set of requirements instead of collaborating with customers.

• Scrum is faster than other methods or frameworks. It’s faster at delivering value to customers because the frequent feedback helps you know when problems occur, which lets stakeholders get a return on their investment faster. And learning where challenges and risks lie as the product is built is faster for the Scrum team, too.

• Scrum is cheaper. Scrum done well prevents you from delivering things that customers don’t want and won’t pay for—in other words, waste.

In all honesty, if Ryan had framed Scrum in the above terms, his boss would probably have become an ally instead of an unimpressed skeptic.

Consider the conversations you’ve had lately with leaders and managers in your organization. Were the discussions centered exclusively on the Scrum team’s needs, or have you acknowledged management’s needs, too? Put yourself in management’s shoes and think about what they consider important (such as “better, faster, cheaper” in Ryan’s scenario). How can Scrum create success for them and fulfill their needs? Stay curious and don’t make assumptions.

Loving the Details of Delivery

By design, Scrum empowers Scrum team members to make decisions about their work. The product owner is fully empowered to make strategic and tactical decisions about the product. The Scrum master is responsible for upholding the Scrum framework; serving the development team, product owner, and organization; and removing any impediments that block the Scrum team. The development team decides how to best do their work and builds high-quality increments of potentially shippable product.

The problem is that this decentralized style of decision making can be difficult for managers to adjust to. Many managers enjoy making decisions about products and how work is done. Managers are often reluctant to lose this decision-making power, and they may feel nervous because the manager’s role in Scrum is unclear. In fact, The Scrum Guide doesn’t even mention managers.

So what does a manager do for a Scrum team? A lot, actually. Managers:

• Set high-level, organizational goals for the Scrum team. These goals clarify the purpose of the team’s work. Having a clear sense of purpose motivates teams, which leads to high performance.

• Help ensure that everyone in the organization is working toward a common goal. An organization won’t get the full benefits of Scrum if various groups aren’t all aligned toward common goals and outcomes.

• Define the boundaries that Scrum teams work within. Management sets organizational standards, conventions, and polices that can help people focus and clearly understand how they should perform their work.

• Preserve self-organization. A manager should defend a team’s ability to self-organize and decide how best to do their work. For example, a director in an organization where Todd was consulting tried to mandate that every development team create estimates the same way. A development manager fought for each development team’s right to estimate the way they considered best. The manager eventually prevailed, preserving the development teams’ ability to make decisions that enabled self-organization.

• Remove organizational impediments. In collaboration with the Scrum master, a manager should work to get organizational impediments removed as quickly as possible. For instance, what if your team only had one license for a tool that was critical for them to properly test an application? You could reach out to your manager for help expediting the procurement process for additional licenses.

• Handle HR responsibilities. These include policy compliance, benefits, career growth, training, and everything else related to serving the needs of their team members.

Managers are still very much needed in Scrum. Helping them understand how they can contribute to your Scrum team is an essential first step to getting them comfortable with adopting Scrum. Even after an organization has been using Scrum for a while, the Scrum master’s work with management doesn’t stop. You need to continually foster open lines of communication with management.

Pop the Scrum bubble that you work within. Step up and coach the outside organization on Scrum. Many of the managers you coach will have limiting beliefs that hold them back, such as “this is the way we’ve always done things.” Such thinking can be so deeply ingrained that they may need your help to see that these beliefs are stopping them from moving away from Taylorism and into the digital age.

Powerful questions can help foster productive discussions with managers who aren’t real keen on Scrum. Such questions bring clarity to difficult situations while also energizing people to take action. Typically, a powerful question is open-ended (meaning it can’t be answered with a simple yes or no), direct, and focused. Most importantly, powerful questions are rooted in honest curiosity. Here are some examples of powerful questions that you can try when talking to managers who are skeptical of Scrum:

• How can we turn your concerns into an experiment?
• What do we risk by trying some experiments?
• What has worked in the past that we can build on?

Removing the limiting beliefs of managers (and others) and energizing them to action can help make your organization more supportive of Scrum.

Difficult situations involving management come up frequently. The techniques and practices that your Scrum team is applying—especially the transparency, inspection, and adaptation—can feel threatening to people who aren’t used to working in a way that’s open and transparent. But by staying curious and finding out what your managers need to feel more comfortable with Scrum, you can help them become more accepting of this exciting new way of working.