More on Scrum roles Source: Mike Cohn - Succeeding with Agile Software Development Using Scrum (Addison Wesley, 2010) 4
Scrum Master Responsible Humble Collaborative Committed Influential Knowledgeable
Responsible A good Scrum Master is able and willing to assume responsibility that special type of responsibility that comes without power. That is not to say that Scrum Masters are responsible for the success of the project; that is shared by the team as a whole. However, the Scrum Master is responsible for maximizing the throughput of the team and for assisting team members in adopting and using Scrum. Think of the Scrum Master 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. Humble A good Scrum Master 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.
Collaborative A good Scrum Master works to ensure a collaborative culture exists within the team. The Scrum Master 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 Scrum Masters encourage teams to think in terms of solutions that benefit all involved rather than in terms of winners and losers. Committed The Scrum Master must feel the same high level of commitment to the project and the goals of the current iteration as the team members do. As part of that commitment, a good Scrum Master 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. One way a Scrum Master can demonstrate commitment is by remaining in that role for the full duration of the project. It is disruptive for a team to change Scrum Masters mid-project.
Influential A successful Scrum Master 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 Scrum Master may need to convince a team to try a new technical practice, such as test-driven development or pair programming. A Scrum Master 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. Knowledgeable Beyond having a solid understanding of and experience with Scrum, the best Scrum Masters also have the technical, market, or other specialized knowledge to help the team pursue its goal. Although Scrum Masters do not necessarily need to be marketing gurus or programming experts, they should know enough about both to be effective in leading the team.
Technical Leads as Scrum Masters?
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 Scrum Masters. One of the risks in using a former tech lead as the Scrum Master 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 Scrum Masters is that they often do not have the requisite people skills. Although technical leads must have some interpersonal skills, Scrum Masters must be facilitators who can guide and lead selforganizing teams over which they have no authority.
Internal or External Scrum Masters?
A common question is whether teams should use Scrum Masters from within the company or whether outside experts should be brought in. The long-term answer is easy: Having skilled Scrum Masters is a critical requirement and as such they should reside within the organization. You should not use contract Scrum Masters 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 Scrum Master initially. This outsider may act as the Scrum Master to the team, but he should also serve as a mentor to prospective Scrum Masters within the team so that the organization can develop its own cadre of Scrum Masters.
Rotating the Scrum Master?
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 Scrum Master. Problems with it, including the following: Someone who has rotated into the role usually has other, non- ScrumMaster tasks to perform, 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. However, there are some occasions when you may want to rotate. The most common is when you want to create learning opportunities. If team members are struggling to understand the duties of the Scrum Master, 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 Scrum Master 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 Scrum Master.
Someone inappropriate takes the role
The Scrum Master is also a programmer / tester / other on the team
The Scrum Master is making decisions for the team
Product Owner Available Business-savvy Communicative Decisive Empowered
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. Decisive 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. Empowered A good product owner must be someone empowered with the authority to make decisions and one who is held accountable for those decisions.
Product Owner Responsibilities: Providing vision Providing 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. 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.
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.
Each team needs exactly one Product Owner
Each team needs exactly one Product Owner
Each team needs exactly one Product Owner
The Scrum Master as Product Owner
One common consideration is whether the Scrum Master 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 Scrum Master/ product owner hybrid. A certain amount of tension should exist between these roles. Product owners continually want more, more, more features. Scrum Masters 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.
The Product Owner delegates decision making but then overrules the decision maker
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. 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 iteration to iteration. 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 Scrum Masters should first push back and then work with the product owners to set longerterm 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
The Product Owner is in a different city than the development team
Changed Roles
Changed Roles (Business) Analyst
Changed Roles Project Manager
Changed Roles Architect
Changed Roles Functional Manager
Changed Roles Programmer Tester UX designer DB Admin They do anything necessary to help the team complete the work committed to for an iteration
Common Themes Work incrementally Work iteratively Work beyond your specialty
Sample of an Emergent Practice An Agile way to estimate a project in 3 steps Story brainstorming Affinity estimation Velocity prediction
Story brainstorming As a <role>, I want <goal/desire> so that <benefit>
Story brainstorming I S T Independent Scalable (small sized) Testable
Story brainstorming Step 1 Focus on quantity 10 minutes Step 2 Focus on quality 15 minutes
An Agile way to estimate a project in 3 steps Story brainstorming Affinity estimation Velocity prediction
Affinity estimation
Affinity estimation
Affinity estimation 1 3 4 8 12.
An Agile way to estimate a project in 3 steps Story brainstorming Affinity estimation Velocity prediction
Velocity prediction
Velocity prediction
Velocity prediction
Velocity prediction
Velocity prediction 1 3 4 8 12
Velocity prediction 18