Chapter 7. New Roles

As we discussed in the previous chapter, teams and organizations resist Scrum for many different reasons. One likely source of opposition to adopting Scrum is confusion over the new roles that exist on a Scrum project. The roles of Scrum-Master and product owner are new ones without exact corollaries in the pretransition organization. It is common for an organization new to Scrum to struggle with filling these roles with appropriate individuals. Until people figure out what the new roles entail and which individuals have those skills, it is hard to put the right people in place.

In this chapter, I describe the new roles of ScrumMaster and product owner. For each role, we look at the responsibilities of the role, ideal attributes of candidates for the role, and how to overcome some common problems these roles present.

The Role of the ScrumMaster

Much has already been written about the job of the ScrumMaster in removing impediments to the team’s progress (Schwaber and Beedle 2001, Schwaber 2004). Most ScrumMasters quickly grasp that part of their job. Where many falter—especially during the critical first 6 to 12 months of using Scrum—is in their relationships to their teams, which is why we will focus on that topic here.

Many who are new to the ScrumMaster role struggle with the apparent contradiction of the ScrumMaster as both a servant-leader to the team and also someone with no authority. The seeming contradiction disappears when we realize that although the ScrumMaster has no authority over Scrum team members, the ScrumMaster does have authority over the process. Although a ScrumMaster may not be able to say, “You’re fired,” a ScrumMaster can say, “I’ve decided we’re going to try two-week sprints for the next month.”¹

1 Ideally, the ScrumMaster tries to get team members to decide this on their own. But, if they do not, the ScrumMaster’s authority over the process allows for this decision.

The ScrumMaster is there to help the team in its use of Scrum. Think of the help from a ScrumMaster as similar to a personal trainer who helps you stick with an exercise regimen and perform all exercises with the correct form. A good trainer will provide motivation while at the same time making sure you don’t cheat by skipping a hard exercise. The trainer’s authority, however, is limited. The trainer cannot make you do an exercise you don’t want to do. Instead, the trainer reminds you of your goals and how you’ve chosen to meet them. To the extent that the trainer does have authority, it has been granted by the client. Scrum-Masters are much the same: They have authority, but that authority is granted to them by the team.

A ScrumMaster can say to a team, “Look, we’re supposed to deliver potentially shippable software at the end of each sprint. We didn’t do that this time. What can we do to make sure we do better the next sprint?” This is the Scrum-Master exerting authority over the process; something has gone wrong with the process if the team has failed to deliver something potentially shippable. But because the ScrumMaster’s authority does not extend beyond the process, the same ScrumMaster should not say, “Because we failed to deliver something potentially shippable the last sprint, I want Tod to review all code before it gets checked in.” Having Tod review the code might be a good idea, but the decision is not the ScrumMaster’s to make. Doing so goes beyond authority over the process and enters into how the team works.

With authority limited to ensuring the team follows the process, the ScrumMaster’s role can be more difficult than that of a typical project manager. Project managers often have the fallback position of “do it because I say so.” The times when a ScrumMaster can say that are limited and restricted to ensuring that Scrum is being followed.

Attributes of a Good ScrumMaster

Today’s surgeons are highly trained and skilled individuals who have had years of formal education followed by extensive internships. This was not always the case. Pete Moore has written that “the first surgeons had little anatomical knowledge, but plied their trade because they had sharp instruments and strong arms. They often did surgery in their spare time while working as the local barber or blacksmith” (2005, 143).

Many organizations choose their first ScrumMasters in much the same way; but instead of seeking sharp instruments and strong arms, they look for management or leadership experience. As they become more experienced with Scrum, organizations eventually realize there are many more factors to consider in selecting ScrumMasters. To help save you from picking a ScrumMaster whose sole qualifications are strong arms and sharp instruments, I have listed the six attributes I have found to be common among the best ScrumMasters I’ve worked with.

Responsible

A good ScrumMaster is able and willing to assume responsibility. That is not to say that ScrumMasters are responsible for the success of the project; that is shared by the team as a whole. However, the ScrumMaster is responsible for maximizing the throughput of the team and for assisting team members in adopting and using Scrum. As noted earlier, the ScrumMaster takes on this responsibility without assuming any of the authority that might be useful in achieving it.

Think of the ScrumMaster as similar to an orchestra conductor. Both must provide real-time guidance and leadership to a talented collection of individuals who come together to create something that no one of them could create alone. Boston Pops conductor Keith Lockhart has said of his role, “People assume that when you become a conductor you’re into some sort of a Napoleonic thing—that you want to stand on that big box and wield your power. I’m not a power junkie, I’m a responsibility junkie” (Mangurian 2006, 30). In an identical manner, a good ScrumMaster thrives on responsibility—that special type of responsibility that comes without power.

Humble

A good ScrumMaster is not in it for her ego. She may take pride (often immense pride) in her achievements, but the feeling will be “look what I helped accomplish” rather than the more self-centered “look what I accomplished.” A humble ScrumMaster is one who realizes the job does not come with a company car or parking spot near the building entrance. Rather than putting her own needs first, a humble ScrumMaster is willing to do whatever is necessary to help the team achieve its goal. Humble ScrumMasters recognize the value in all team members and by example lead others to the same opinion.

Collaborative

A good ScrumMaster works to ensure a collaborative culture exists within the team. The ScrumMaster needs to make sure team members feel able to raise issues for open discussion and that they feel supported in doing so. The right ScrumMaster helps create a collaborative atmosphere for the team through words and actions. When disputes arise, collaborative ScrumMasters encourage teams to think in terms of solutions that benefit all involved rather than in terms of winners and losers. A good ScrumMaster models this type of behavior by working with other ScrumMasters in the organization. However, beyond modeling a collaborative attitude, a good ScrumMaster establishes collaboration as the team norm and will call out inappropriate behavior (if the other team members don’t do it themselves).

Committed

Although being a ScrumMaster is not always a full-time job, it does require someone who is fully committed to doing it. The ScrumMaster must feel the same high level of commitment to the project and the goals of the current sprint as the team members do. As part of that commitment, a good ScrumMaster does not end very many days with impediments left unaddressed. There will, of course, be times when this is inevitable, as not all impediments can be removed in a day. For example, convincing a manager to dedicate a full-time resource to the team may take a series of discussions over several days. On the whole, however, if a team finds that impediments are often not cleared quickly, team member should remind their Scrum-Master about the importance of being committed to the team.

One way a ScrumMaster can demonstrate commitment is by remaining in that role for the full duration of the project. It is disruptive for a team to change ScrumMasters mid-project.

Influential

A successful ScrumMaster influences others, both on the team and outside it. Initially, team members might need to be persuaded to give Scrum a fair trial or to behave more collaboratively; later, a ScrumMaster may need to convince a team to try a new technical practice, such as test-driven development or pair programming. A ScrumMaster should know how to exert influence without resorting to a dictatorial “because I say so” style.

Most ScrumMasters will also be called upon to influence those outside the team. For example, a ScrumMaster might need to convince a traditional team to provide a partial implementation to the Scrum team. Or, a ScrumMaster might need to prevail upon a QA director to dedicate full-time testers to the project.

Although all ScrumMasters should know how to use their personal influence, the ideal one will come with a degree of corporate political skill. The term “corporate politics” is often used pejoratively; however, a ScrumMaster who knows who makes decisions in the organization, how those decisions are made, which coalitions exist, and so on can be an asset to a team.

Knowledgeable

Beyond having a solid understanding of and experience with Scrum, the best ScrumMasters also have the technical, market, or other specialized knowledge to help the team pursue its goal. LaFasto and Larson have studied successful teams and their leaders and have concluded that “an intimate and detailed knowledge of how something works increases the chance of the leader helping the team surface the more subtle technical issues that must be addressed” (2001, 133). Although ScrumMasters do not necessarily need to be marketing gurus or programming experts, they should know enough about both to be effective in leading the team.

Tech Leads as ScrumMasters

That we’d like ScrumMasters to have solid technical knowledge does not mean, however, that we simply anoint each team’s tech lead as its ScrumMaster. In fact, because Scrum teams are self-organizing, there should not be a company-designated role such as “tech lead.” However, when adopting Scrum it can be very tempting to take the former tech leads and search for equivalent roles where they can exert similar influence on the team and the product. Often this leads to designating tech leads as ScrumMasters. Although some tech leads make great ScrumMasters, never select someone as a ScrumMaster solely because of this, or any other, past role.

A few years ago I provided some initial training to a company, with the goal of helping its leaders decide whether they would adopt Scrum. Two weeks later, one of them called me and said that my training had convinced them, and they were proceeding with Scrum. In fact, she and a few others were in a meeting that moment discussing who their initial ScrumMasters should be, and they wanted my advice. She then said, “We don’t have time for a lot of discussion on this. We have only one question: Can the tech lead on each team become the ScrumMaster for that team? Just give a yes or no answer.” I began to reply, “Yes, they can, but...” and was about to explain the risks of this when she thanked me for my answer and hung up.

When I visited this client two months later, I was confronted with, “Why did you say we should make our tech leads our ScrumMasters?” Uh, I hadn’t. Apparently they had encountered some of the problems I had tried to warn them about and had since found that having solid technical knowledge was only one of the desirable attributes of a ScrumMaster.

One of the risks in using a former tech lead as the ScrumMaster is that tech leads are used to providing direction to their teammates. And worse, team members are used to looking to their tech leads for decisions. Because a good Scrum-Master does not make decisions for the team, the former tech lead’s history as a decision maker can work against the transition.

A second risk of converting tech leads into ScrumMasters is that they often do not have the requisite people skills. Although technical leads must have some interpersonal skills, ScrumMasters must be facilitators who can guide and lead self-organizing teams over which they have no authority. Author of Collaboration Explained, Jean Tabaka, shares similar concerns.

I work primarily with Scrum teams, and those that struggle the most typically have a command-and-control project manager or a decision-oriented technical lead as ScrumMaster. Without a facilitative, servant-leader mode of team guidance, the agile adoption will be only a thin veneer over nonempowered, demoralized teams. (2007, 7)

All of this is not to say that tech leads should never be considered as possible ScrumMasters. Rather, the point is to be aware of these issues and not cavalierly decide that all tech leads in your organization will make great ScrumMasters. Perhaps the best way to assess a tech lead as a candidate for the ScrumMaster role is to look at how that person has used the leadership authority that came with the tech lead designation. Tech leads who took an “it’s-my-way-or-the-highway” approach in the past will not make good ScrumMasters. On the other hand, tech leads who could have dictated decisions but instead worked to rally supporters to their viewpoint will probably do well.

Internal or External ScrumMasters

A common question is whether teams should use ScrumMasters from within the company or whether outside experts should be brought in. The long-term answer is easy: Having skilled ScrumMasters is a critical requirement and as such they should reside within the organization. You should not use contract ScrumMasters over the long-term.

But it is hard to learn a new skill until you’ve seen someone else demonstrate it. Learning how to lead without authority, when and how to nudge a team toward adopting new engineering practices, when it’s OK to intervene, and so on can be difficult. Therefore, many organizations benefit from bringing in an outside consultant as a ScrumMaster initially. This outsider may act as the ScrumMaster to the team, but he should also serve as a mentor to prospective ScrumMasters within the team so that the organization can develop its own cadre of ScrumMasters.

Rotating the ScrumMaster

Some teams that struggle with choosing the best ScrumMaster decide that an appropriate strategy is to rotate the role among all team members. I don’t advocate this, as I don’t think it demonstrates an appropriate respect for the challenges and significance of the role. In my family, we rotate who cleans the table and loads the dishwasher. Any of us can do that job. We do not, however, rotate who cooks dinner. My wife is a far better cook than anyone else in the family. We want the cooking to be the best it can be, so we don’t rotate that job. If you want your Scrum team to be the best it can be, I do not recommend that you make a habit of rotating the job of ScrumMaster.

However, there are some occasions when you may want to rotate. The most common is when you want to create learning opportunities. For example, if team members are struggling to understand the duties of the ScrumMaster, they may want to consider rotating each team member through the role. This may allow each to develop an understanding of what it means to be a ScrumMaster. Similarly, if a team identifies four or five good ScrumMaster candidates among its ranks, it may want to rotate among them, giving each a chance to try the role. Then by considering the performance of each, the team will hopefully be able to choose the most appropriate ScrumMaster.

Bob Schatz and Ibrahim Abdelshafi of Primavera Systems point out another reason why rotating might be useful.

With time the team can begin to treat this position as their manager. And the person in that position typically detects and dutifully fills the apparent need. The result is a breakdown in the team’s self-management practice. By rotating the responsibility at the start of each sprint, it diffuses the role and makes it a shared team responsibility and establishes a balance of power. (2006, 145)

So, although it is possible to rotate the job of ScrumMaster, I recommend doing it only for specific reasons, such as those just given, and only temporarily. Rotating should not be a permanent practice. There are simply too many problems with it, including the following:

• Someone who has rotated into the role usually has other, non-ScrumMaster tasks to perform during the sprint, and these often take priority.

• It’s hard to train enough people to do the role well.

• Some people will use their time as ScrumMaster to try to push through changes to the process.

• Designating someone as ScrumMaster for a sprint or two does not automatically make someone value the job, which can lead to ScrumMasters who think Scrum is a mistake.

Overcoming Common Problems

Some of the common problems you may face in making sure that each team has the appropriate ScrumMaster and what you can do to address them include

Someone inappropriate takes the role

Sometimes the decision of who should be the ScrumMaster is made for you: someone just says, “I’ll do it,” and takes on the role. Often this is great—after all, good ScrumMasters are likely to be the ones who take on additional responsibility before being asked. But what if the person who volunteers is inappropriate for the role? Your response to this will depend on your role in the organization.

If you have some authority over the inappropriate ScrumMaster, the team, or the adoption of Scrum, meet with the volunteer and explain why you need someone different in the role. If appropriate, give the volunteer specific things you would like him to do to be considered as a ScrumMaster candidate later. And if the inappropriate person is already in the role of ScrumMaster? Even though it will be a bit more difficult, I still suggest removing the person from the role if you are convinced the person is truly inappropriate. In either case, act swiftly. An inappropriate ScrumMaster should be changed as soon as possible; I haven’t met a team yet who felt an inappropriate ScrumMaster was removed too soon.

If you do not have authority over the ScrumMaster, team, or process, I still suggest you pursue a conversation with the person who has inappropriately assumed the ScrumMaster role. Approach the discussion from the perspective of having the team’s best interests in mind. Try to accentuate the ScrumMaster’s strengths and suggest that he might be able to find a better way of applying them to the project if he steps out of the ScrumMaster role.

The ScrumMaster is also a programmer/tester/other on the team

When it is impractical to have a dedicated ScrumMaster for a team, a decision must be made between a ScrumMaster who splits time between two or more teams and a ScrumMaster who is both a ScrumMaster and a programmer, tester, or other on the same team. Although either of these approaches can work suitably well, I tend to prefer that when necessary a ScrumMaster’s time is split between two teams. Having a ScrumMaster who is also an individual contributor on the team carries many risks.

One risk is that the person may not have adequate time to devote to both roles. Another is that someone in a combined role will probably need to stay away from critical path activities because the person could be interrupted with ScrumMaster duties at any time. A more subtle risk is that other team members will not easily know whether they are talking to their ScrumMaster or to another individual contributor. Yet another risk is the ScrumMaster will have less credibility when protecting the team from outsiders. A dedicated ScrumMaster will have more credibility when saying, “We can’t help. The team is busy,” than will the ScrumMaster/individual contributor whose same message can be interpreted as “We can’t help. I’m busy.”

As risky as it can be for someone to be both ScrumMaster and a technical contributor on the project, it is a common situation. Awareness of these issues and a willingness to work through them as they arise is often the best solution.

The ScrumMaster is making decisions for the team

This problem can arise for two completely different reasons: it could be because the ScrumMaster misunderstands or is uncomfortable in the new role, or it could be because the team is used to someone else making decisions. In either case, the solution is the same. The ScrumMaster should be taken aside and reminded that being a ScrumMaster is about providing guidance, not answers.

As a new ScrumMaster, one of the first things I had to learn was how to count. When we’d be in a meeting, struggling with some vexing problem, the team would look to me to tell them the solution. Having previously been the team leader I was tempted to blurt out “the answer.” But I needed the team to learn how to find the right answers themselves, and so I sat there quietly counting to myself. 1, 2, 3.... I counted well into the hundreds on a few occasions, but this helped me learn to keep my mouth shut. And it helped the team learn not only how to make those decisions but also that I wouldn’t do it for them.

The Product Owner

I think of the ScrumMaster as the person who ensures that the team is working well together, that impediments to progress are quickly removed, and that the team is moving efficiently toward its goal. I think of the product owner as the person who makes sure the team is aimed at the right goal. A good team needs both roles to succeed. The product owner points the team at the right target; the ScrumMaster helps the team get to that target as efficiently as possible.

Roman Pichler, author of Agile Product Management with Scrum: Creating Products that Customers Love, stresses the importance of the product owner: “The product owner has the authority to set a goal and shape the vision. The product owner is not just a project manager who now also writes requirements and does a little bit of prioritization.” Thinking of the product owner as the provider of a team’s goal helps make certain aspects of the product owner’s job clear. For example, the product owner is clearly responsible for defining and prioritizing the product backlog that expresses the goal. Similarly, the product owner is responsible for making sure the project earns a good return on the investment made in it.

Responsibilities of the Product Owner

Compiling an exhaustive list of the responsibilities of the product owner would be difficult. Every application exists within its own context of company culture, individual and team competencies, competitive forces, and so on. This context strongly influences how the product owner role is performed in different companies. So instead of providing a checklist of product owner responsibilities (“must attend sprint planning meeting”), I find it more helpful to think in terms of two things that a product owner provides the team: a vision and boundaries.

Providing Vision

Many of the product owner’s responsibilities involve establishing and communicating the vision for the product. The best teams are those whose passion has been ignited by a compelling vision shared by the product owner. Who will we be selling to? What is unique about our product? What are our competitors doing? How will our product evolve over time? Of course, the questions are different for an application or service that is being delivered to a group of in-house users, but having a shared vision is important for motivating a team and creating a long-term connection between those developing the product and those using it.

Beyond having a clear vision in mind, the product owner must elucidate that vision for the team. The product owner does this through creating, maintaining, and prioritizing the product backlog. There is a lot of dissension among Scrum-Masters and teams as to whether the product owner is the one who actually writes the product backlog. I am firmly in the camp of I-don’t-care. It doesn’t matter to me who performs the physical act of writing the product backlog; what does matter is that the product owner is the one who makes sure it happens. If the product owner delegates this to a business analyst and the analyst gets sidetracked and fails to write the product backlog, it is still the product owner who is responsible.

Beyond ensuring that the product backlog exists, the product owner adds detail to the vision by answering questions team members will have: Do you want it to work this way? What did you mean when you said such-and-such? Although the product owner can delegate or distribute the responsibility for answering these questions, the product owner cannot delegate the responsibility that they indeed get answered. A product owner can say, “Talk to Nirav if you have questions about how the shopping cart and checkout features should work,” but if Nirav isn’t responsive or helpful, a good product owner will step in and answer questions personally, find out why Nirav is unable to do so, designate a different person, or find some other solution.

Providing Boundaries

Vision and boundaries can be thought of as competing aspects of the project. The vision shows what the product can become. The boundaries describe the realities within which the vision must be realized. Boundaries are provided by the product owner and often come in the form of constraints, such as

• I need it by June.

• We need to reduce the per-unit cost by half.

• It needs to run at twice the speed.

• It can use only half the memory of the current version.

Often when I tell groups that the product owner is allowed to dictate things such as this—especially the date—I am met with angry responses. “No,” they tell me, “estimates are up to the team. All the product owner does is prioritize the work.” Although those statements are true, the product owner is also responsible for defining the boundaries that will determine the success of the product.

Most experienced Scrum team members will readily agree that it is within the product owner’s purview to say, “We need to develop at least this much of the product backlog or the product won’t be worth shipping.” But many of these same experienced people resist when similar statements are made about deadlines. But, let’s see what Takeuchi and Nonaka had to say in their study of the six teams that formed the foundation of Scrum and that were the subject of the first paper on Scrum back in 1986.

Fuji-Xerox’s top management asked for a radically different copier and gave the FX-3500 project team two years to come up with a machine that could be produced at half the cost of its high-end line and still perform as well. (139)

Here, we clearly have a team that is given a challenging problem—match the performance of the company’s best current copiers but at half the cost—and a deadline for solving the problem. There is nothing wrong with this. Product owners go wrong when they overly constrain a problem or when they make a solution impossible. Had Fuji-Xerox’s management given that team the same problem but only one month to solve it, the team would have seen the futility in the situation and not even tried. The problem as presented to that team presumably left the team plenty of operating room in which to find a solution. A part of the product owner’s job that is more art than science is providing just enough of a boundary around the project so that the team is motivated to solve the difficult problem before them but not providing so many boundaries that solving the problem becomes impossible.

When brainstorming solutions to a challenging problem, common advice is to think “outside the box.” However, there is evidence that better solutions emerge more easily from thinking that is done “inside the box” as long as the box has been properly framed (Coyne, Clifford, and Dye 2007). When we’re told to think outside the box, they say, the total lack of constraints can be unsettling.

Imagine a random product you are trying to improve in a typical facilitated brainstorming session. Outside-the-box possibilities could include making the product bigger or smaller, lighter or heavier, prettier or more rugged (or changing its appearance in any of a hundred ways). Further ideas could involve making the product more expensive or less or maybe breaking it into parts or bundling it with other products. They could involve changing the product’s functionality, durability, ease of use, or the way it fits with other products. Or its availability, affordability, or repairability. How do you know which dimensions are fruitful to explore? Without some guidance, people cannot judge whether they should continue in the direction of their first notion or change course altogether. They cannot handle the uncertainty, and they shut down. (2007, 71)

The product owner’s job is to create the new box—the boundaries—in which the team will think. This new box prevents the team from getting lost in the infinitude of possible solutions and gives team members a basis for making and comparing choices. Boundaries for that new box are determined by the most important constraints for the business, which may involve things like minimum guaranteed functionality, dramatically faster performance, reduced resource consumption, and, yes, in some cases the date.

Each Team Needs Exactly One Product Owner

On a team that is new to Scrum, the ScrumMaster job can be very time consuming. The ScrumMaster will be busy training team members on Scrum itself, encouraging them to think in different ways about the problems they encounter, removing impediments to the team’s progress, and more. Early on, this might even be a full-time job, depending on the newness of the team and the types of impediments team members face. Over time, however, things improve. Eventually the ScrumMaster has removed many recurring impediments, and the team itself has begun to master Scrum and has embraced its self-organizing nature. As these changes occur, the team needs less and less of their ScrumMaster’s time. If we were to graph a team’s demands on its ScrumMaster’s time, it would look something like Figure 7.1.

Figure 7.1 A team’s time demands on their product owner and ScrumMaster move in different directions.

Contrast this with the team’s need for its product owner. When the team first adopts Scrum, it will not be very good at it. It will struggle with how much detail to put on the product backlog, how much work can be completed in a sprint, how to work well together within the sprint, and so on. Team members will be learning new practices and new ways of working together. The team will not be very fast—at least not compared to how fast it will be after it gets good at Scrum. As the team speeds up (through its own improvements and from the ScrumMaster gradually removing impediments), it will be completing more work each sprint. This means members will have more questions for their product owner. Therefore, as the team’s efficiency increases, so will its demands on the product owner’s time. This is likely the case even as team members learn the domain and take on more responsibility themselves.

This inverse relationship between a team’s demands on the product owner’s and the ScrumMaster’s time is shown in Figure 7.1. The lines in this figure show that although it may be acceptable to have an experienced ScrumMaster work with two or possibly even three teams (depending on how much help each team needs at the time), it is not advisable to share one product owner across more than two teams. Instead, each team should ideally have its own dedicated product owner. The product owner job is very challenging. Part of the job is outward-facing: talking to customers and following market trends. Another part of the job is inward-facing: working with the team to build the product. When a job involves both inward- and outward-facing duties, the outward, customer-facing duties always seem to win. Any developer who is responsible for both new development and customer support can confirm that customer-facing issues almost always win.

Just as a product owner should work only with one team, each team should work only with one product owner. I have seen occasions where having two product owners assigned to a team works, but this is usually a result of someone in the organization not wanting to make the hard call of saying, “Your product owner is so-and-so.” Find someone to make the hard call, designate one product owner for the team, and then encourage that person to solicit all sorts of helpful input and feedback from those who also could have been the product owner.

A team with two product owners will inevitably fall into the trap of “Mom said no; let’s go ask Dad.” Of course, only the most dysfunctional (or perhaps desperate) teams will get the “wrong” answer from one product owner and go ask the same question of the other. Even they know they will eventually be found out and will be called on their behavior. However, most teams with two product owners will go so far as to think about which product owner will give the most satisfying answer before they choose which one to ask.

A Product Owner Team

In some cases, the product owner role can be too much for one person. Researchers Angela Martin, Robert Biddle, and James Noble found that the product owner role is “consistently under more pressure than the developers and other participants in the project” (2004, 51). Ron Jeffries, one of the inventors of the Extreme Programming process and a Scrum trainer, agrees: “It was only after the first book or two on XP came out that we fully realized the load a single XP Customer/Scrum product owner is taking on. It’s clear that they’ll need to be a group.”

A common solution is the use of a product owner team. Splitting the duties of the product owner across a product owner team is fine as long as there remains one person on that team who can be singled out as the person with ultimate responsibility and authority, a “the-buck-stops-here” individual. Even with a product owner team, each development team needs to have one identifiable, consistent person it can go to for answers. As Ken Schwaber and Mike Beedle have written, “The product owner is one person, not a committee” (2001, 34). Make sure each team can identify one person people can go to for decisions. A good Scrum team moves far too quickly to wait for all questions to be answered by committee. A product owner will never be able to instantly answer all questions the team may have; occasionally telling the team, “I need to run this by my colleagues,” is fine. But, well-founded caution should not be replaced by de facto decision-by-committee.

Attributes of a Good Product Owner

As when describing what to look for in selecting or hiring a good ScrumMaster, I’ve culled the long list of desirable product owner traits down to five must-have attributes.

Available

By far the most frequent complaint I hear from teams about their product owners is that they are unavailable when needed. When a fast-moving team needs an answer to a question, waiting three days for an answer is completely disruptive to the rhythm it has established. By being available to the team, a product owner demonstrates commitment to the project. The best product owners demonstrate their commitment by doing whatever is necessary to build the best product possible. On some projects this includes doing things like assisting in test planning, performing manual tests, and being actively engaged with other team members.

Business-savvy

It is essential that the product owner understand the business. As the decision maker regarding what is in or out of the product, the product owner must have a deep understanding of the business, market conditions, customers, and users. Usually this type of understanding is built over years of working in the domain, perhaps as a past user of the type of product being developed. This is why many successful product owners come from product manager, marketing, or business analyst roles.

Communicative

Product owners must be good communicators and must be able to work well with a diverse set of stakeholders. Product owners routinely interact with users, customers, management within the organization, partners, and, naturally, others on the team. Skilled product owners will be able to deliver the same information to each of these different audiences while at the same time tailoring their message to best match the audience.

A good product owner must also listen to users, customers, and perhaps most important the team. Especially as team members learn more about the product and market (as they should over time, especially on a Scrum project), they will be able to offer valuable suggestions about the product. Additionally, all teams will have much to say to the product owner about the technical risks and challenges of the project. Although it is true that the product owner prioritizes all work for the team, the wise product owner will listen to her team when it recommends some adjustments in those priorities based on technical factors.

Decisive

Another common complaint teams make about their product owners is their lack of decisiveness. When team members go to the product owner with an issue, they want a resolution. Scrum puts a lot of pressure on teams to produce functionality as quickly as possible. Teams are frustrated when a product owner responds to a question with, “Let me call a meeting or convene a task force to work on that.” A good team will understand that this is sometimes necessary, but teams are very perceptive at knowing when a product owner is actually just trying to avoid making a hard decision. Just as bad as a product owner who won’t make a decision is the product owner who makes the same decision over and over but with different answers. A good product owner will not reverse prior decisions without a good reason.

Empowered

A good product owner must be someone empowered with the authority to make decisions and one who is held accountable for those decisions. The product owner must be sufficiently high up in the organization to be given this level of responsibility. If a product owner is consistently overruled by others in the organization, team members will learn to go to those others with their important questions.

The ScrumMaster as Product Owner

One common consideration is whether the ScrumMaster and product owner roles should be combined. No. In the vast majority of times I’ve seen this done, the results have been disappointing. Not only does combining these roles put a lot of power in one person’s hands, but it also creates confusion for both team members and the ScrumMaster/product owner hybrid. A certain amount of tension should exist between these roles. Product owners continually want more, more, more features. ScrumMasters protect their teams by pushing back against the product owner when they feel that pushing their teams harder would be detrimental. When the roles are combined, this tension is removed.

With an eye toward full disclosure, I feel compelled to add that two of the most successful Scrum projects I’ve participated in or witnessed had a combination ScrumMaster/product owner. There are tremendous advantages to having a single person who has a deep understanding of the market, has the technical and collaborative skills of a ScrumMaster, and can effectively balance them. Toyota essentially combines the ScrumMaster and product owner roles into its single chief engineer role. The Toyota chief engineer is someone who is most definitely an engineer and could likely engineer any part of a new vehicle but who also has a deep understanding of the market and likely purchasers of the vehicle being engineered.

So, the combined ScrumMaster/product owner model can be successful. However, I suspect that there are very few individuals who are good at both jobs and who are good at doing them both at the same time. Even if you suspect you are one of them or can identify these people within your organization at the start of the transition to Scrum, I still recommend using separate individuals in these roles, at least at the start.

Overcoming Common Problems

There are many potential pitfalls when selecting the initial product owner. Some of the most common early-stage problems and what you can do to address them include

The product owner delegates decision making but then overrules the decision maker

To fit the new duties of the product owner into their schedules, some product owners delegate decisions about specific parts of the product. Other product owners enlist a business analyst to be a “feature owner” over some part of the system. This can work well because the product owner has more time to dedicate to areas that are not as easy to delegate.

Problems arise when the product owner says that decision-making authority has been delegated but then continues to approve or sometimes reverses decisions. Before delegating, product owners should be sure they are really willing to delegate without later second-guessing. Because of the pressure of the short, timeboxed sprints, Scrum teams often move much more quickly than they did before transitioning. It is inevitable that some decisions that the product owner delegates will turn out to be wrong, and these should be revisited. What we want to avoid, however, are situations where the product owner says, “Get your answers from Dave; he owns this part of the system,” and then consistently overrules Dave’s answers.

My advice to a new and overloaded product owner is to free some time by delegating just beyond the point at which you’re comfortable. You may be pleasantly surprised and find no important decisions to reverse. But you’ll occasionally find some decisions you would have made differently. Often the best thing to do in this case is the same thing we’re all taught when learning to drive: If the car starts to slide, steer into the slide. Rather than pull against the decision (assuming it is not a horrendous one), allow that decision to persist through the end of the sprint; then decide if it should be changed. When the cost of reversing a decision is compared against all the other valuable work on the product backlog, you may find that the decision wasn’t so bad after all.

The product owner pushes the team too hard

Product owners are often under pressure to deliver financial results to the company; more features delivered sooner is one way for them to achieve it. As I’ve said, I have no objection to a product owner who announces at the start of a project, “We need to build a product that is smaller, better-performing, and cheaper than our competitor’s, and we need to do it in three months less than we spent on the last product.” As long as a challenging goal like that is accompanied by appropriate freedom in how the goal is achieved, the team will do its best. The problems arise when the team is kept under constant and changing pressure from sprint to sprint. One difficult goal of “do this amazing thing in 6 months” is in many ways less stressful for the team than 13 successive two-week sprints of “I need more, more, more!” If you have product owners who are pushing teams this way, the ScrumMasters should first push back and then work with the product owners to set longer-term goals for the teams while ensuring teams have commensurate degrees of freedom in how those goals are achieved.

The product owner wants to cut quality

Cutting quality is an oh-so-tempting decision when trying to deliver a challenging set of features by a difficult date. It can lead to the short-term appearance of having met the objectives established at the start of the project. Eventually, however, the cost of having cut quality becomes apparent as more post-release bugs than usual are reported, the team’s velocity decreases, and customers clamor for the product to behave as they thought it would.

Ken Schwaber has called quality a “corporate asset” (2006). As such, no one except the chief executive has the authority to sacrifice quality in exchange for achieving a short-term goal such as making a release date. A decision to cut quality may be the appropriate one; I can’t tell you otherwise without knowing the full context of a situation. But, that decision is one that needs to be made sufficiently high up in the organization and with such openness that no one is surprised by the negative impacts that will almost certainly follow.

Selecting product owners who understand this is sometimes challenging in organizations that are consistently focused on this quarter’s numbers. Pushing back against attempts to reduce quality is the job of the ScrumMaster. The ScrumMaster does not need to prevail in these early disagreements. The ScrumMaster does, however, have to succeed in making the decision visible.

Time is on the ScrumMaster’s side. If the ScrumMaster successfully raises the visibility of decisions to cut quality, he should eventually be able to win later arguments against reducing quality. “Remember on the Gouda project how I told you that cutting quality on version one would hurt us during version two?” the ScrumMaster can say. “Well, here are the graphs of velocity on the two projects. Note that version two had a lower velocity even though we added two experienced people. That was because we left bugs behind during version one (here’s a graph showing that) and because the team didn’t feel it had the time to do a good job of keeping its code clean. We even skipped the automated unit tests on a few modules. Here’s a comparison of the number of defects found during the six months following release, broken down by whether the module had automated unit tests. It’s up to you if we do this again on this project, but I think you know my opinion.”

Our product owner is in a different city than the development team

With more projects being developed by remote teams, this is an increasingly common situation. Both the team and product owner in this situation should assume some of the burden of overcommunicating with the other. I have worked with many remote product owners, and it can work very successfully as long as the product owner does the following:

• Remains engaged in the project

• Establishes a rapport with the team

• Performs all usual duties of the role

• Is available to the team for phone calls for at least some part of the day, even if it is after the usual workday for the product owner

• Responds by e-mail or phone when not available in person

New Roles, Old Responsibilities

The roles of product owner and ScrumMaster are critical for becoming a high-performing Scrum team. In this chapter we’ve looked at the responsibilities of the people in these jobs, attributes we’d like our product owners and ScrumMasters to possess, and how to overcome some common problems that occur when introducing these roles into an organization.

Although the roles of product owner and ScrumMaster are new, the responsibilities are not. High-performance teams have always known they needed to do the things described in this chapter. On a Scrum team, individuals are asked to look beyond their explicit roles to find ways to help the team accomplish its goals. In the next chapter, we look at what this new emphasis on teamwork and shared responsibility means for existing roles in the organization.

Additional Reading

Davies, Rachel, and Liz Sedley. 2009. Agile coaching. The Pragmatic Bookshelf.

This book is full of practical, immediately useful advice for any ScrumMaster. It covers everything from how to help the team improve to how to help yourself improve.

Fisher, Kimball. 1999. Leading self-directed work teams. McGraw-Hill.

The self-directed work teams of Fisher’s book are the self-organizing teams of an agile project. His book offers guidance appropriate to ScrumMasters.

James, Michael. 2007. A ScrumMaster’s checklist, August 13. Michael James’ blog on Danube’s website. http://danube.com/blog/michaeljames/a_scrummasters_checklist.

In making his argument that a great team needs a full-time ScrumMaster, rather than one who works with two or more teams, Michael James presents a rather exhaustive list of work to be performed by the ScrumMaster.

Kelly, James, and Scott Nadler. 2007. Leading from below. MIT Sloan Management Review, March 3. http://sloanreview.mit.edu/business-insight/articles/2007/1/4917/leading-from-below.

This article presents useful information for those not in authority positions who nonetheless realize they can still influence the direction of the organization.

Pichler, Roman. Forthcoming. Agile product management with Scrum: Creating products that customers love. Addison-Wesley Professional.

The most complete coverage available of the role of the product owner. Pichler clarifies the key differences between traditional and agile product management while providing useful tips to product owners.

Schwaber, Ken. 2004. Agile project management with Scrum. Microsoft Press.

Schwaber’s second book is full of anecdotes about teams using Scrum both successfully and unsuccessfully. In addition to chapters dedicated to the product owner and ScrumMaster roles, other valuable advice on performing those roles is spread throughout the book.

Spann, David. 2006. Agile manager behaviors: What to look for and develop. Cutter Consortium Executive Report, September.

In this extensive report, Cutter consultant David Spann addresses the question of what attributes to look for in what he calls an “agile manager,” but which corresponds closely to the ScrumMaster role of this chapter. He starts with a list of 22 candidate behaviors but reduces this to a list of 8 preferred behaviors to look for when hiring an agile manager.