More on Scrum rolestzutzu/Didactic/Agile/Course 04 - More... · Collaborative A good Scrum Master...

52
More on Scrum roles 4 Source: Mike Cohn - Succeeding with Agile Software Development Using Scrum (Addison Wesley, 2010)

Transcript of More on Scrum rolestzutzu/Didactic/Agile/Course 04 - More... · Collaborative A good Scrum Master...

More on Scrum roles

4Source: Mike Cohn - Succeeding with Agile Software Development Using Scrum (Addison Wesley, 2010)

Scrum Master

Responsible

Humble

Collaborative

Committed

Influential

Knowledgeable

Responsible A good Scrum Master is able and willing toassume responsibility — that special type of responsibility thatcomes without power. That is not to say that Scrum Mastersare responsible for the success of the project; that is sharedby the team as a whole. However, the Scrum Master isresponsible for maximizing the throughput of the team and forassisting team members in adopting and using Scrum.Think of the Scrum Master as similar to an orchestraconductor. Both must provide real-time guidance andleadership to a talented collection of individuals who cometogether to create something that no one of them could createalone.

Humble A good Scrum Master is not in it for her ego. Shemay take pride (often immense pride) in her achievements,but the feeling will be “look what I helped accomplish” ratherthan the more self-centered “look what I accomplished.”

Collaborative A good Scrum Master works to ensure acollaborative culture exists within the team. The Scrum Masterneeds to make sure team members feel able to raise issues foropen discussion and that they feel supported in doing so. Theright ScrumMaster helps create a collaborative atmosphere forthe team through words and actions. When disputes arise,collaborative Scrum Masters encourage teams to think in termsof solutions that benefit all involved rather than in terms ofwinners and losers.

Committed The Scrum Master must feel the same high level ofcommitment to the project and the goals of the current iterationas the team members do. As part of that commitment, a goodScrum Master does not end very many days with impedimentsleft unaddressed. There will, of course, be times when this isinevitable, as not all impediments can be removed in a day. Forexample, convincing a manager to dedicate a full-time resourceto the team may take a series of discussions over several days.One way a Scrum Master can demonstrate commitment is byremaining in that role for the full duration of the project. It isdisruptive for a team to change Scrum Masters mid-project.

Influential A successful Scrum Master influences others, both onthe team and outside it. Initially, team members might need to bepersuaded to give Scrum a fair trial or to behave morecollaboratively; later, a Scrum Master may need to convince a teamto try a new technical practice, such as test-driven development orpair programming. A Scrum Master should know how to exertinfluence without resorting to a dictatorial “because I say so” style.Most ScrumMasters will also be called upon to influence thoseoutside the team. For example, a ScrumMaster might need toconvince a traditional team to provide a partial implementation tothe Scrum team. Or, a ScrumMaster might need to prevail upon aQA director to dedicate full-time testers to the project. Although allScrumMasters should know how to use their personal influence, theideal one will come with a degree of corporate political skill.

Knowledgeable Beyond having a solid understanding of andexperience with Scrum, the best Scrum Masters also have thetechnical, market, or other specialized knowledge to help the teampursue its goal. Although Scrum Masters do not necessarily need tobe marketing gurus or programming experts, they should knowenough about both to be effective in leading the team.

Technical Leads as

Scrum Masters

?

Because Scrum teams are self-organizing, there should not bea company-designated role such as “tech lead.” However, whenadopting Scrum it can be very tempting to take the former techleads and search for equivalent roles where they can exertsimilar influence on the team and the product. Often this leadsto designating tech leads as Scrum Masters.

One of the risks in using a former tech lead as the ScrumMaster is that tech leads are used to providing direction to theirteammates. And worse, team members are used to looking totheir tech leads for decisions. Because a good Scrum-Masterdoes not make decisions for the team, the former tech lead’shistory as a decision maker can work against the transition.A second risk of converting tech leads into Scrum Masters isthat they often do not have the requisite people skills. Althoughtechnical leads must have some interpersonal skills, ScrumMasters must be facilitators who can guide and lead self-organizing teams over which they have no authority.

Internal or External Scrum Masters

?

A common question is whether teams should use ScrumMasters from within the company or whether outsideexperts should be brought in. The long-term answer iseasy: Having skilled Scrum Masters is a criticalrequirement and as such they should reside within theorganization. You should not use contract Scrum Mastersover the long-term.But it is hard to learn a new skill until you’ve seensomeone else demonstrate it. Learning how to leadwithout authority, when and how to nudge a team towardadopting new engineering practices, when it’s OK tointervene, and so on can be difficult. Therefore, manyorganizations benefit from bringing in an outsideconsultant as a Scrum Master initially. This outsider mayact as the Scrum Master to the team, but he should alsoserve as a mentor to prospective Scrum Masters withinthe team so that the organization can develop its owncadre of Scrum Masters.

?

Rotating the Scrum Master

If you want your Scrum team to be the best it can be, I do notrecommend that you make a habit of rotating the job of ScrumMaster.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 pushthrough changes to the process.

However, there are some occasions when you may want to rotate.The most common is when you want to create learningopportunities. If team members are struggling to understand theduties of the Scrum Master, they may want to consider rotatingeach team member through the role. This may allow each todevelop an understanding of what it means to be a ScrumMaster.Similarly, if a team identifies four or five good Scrum Mastercandidates among its ranks, it may want to rotate among them,giving each a chance to try the role. Then by considering theperformance of each, the team will hopefully be able to choose themost 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 fromteams about their product owners is that they are unavailablewhen needed. When a fast-moving team needs an answer to aquestion, waiting three days for an answer is completelydisruptive to the rhythm it has established. By being availableto the team, a product owner demonstrates commitment to theproject. The best product owners demonstrate theircommitment by doing whatever is necessary to build the bestproduct possible. On some projects this includes doing thingslike assisting in test planning, performing manual tests, andbeing actively engaged with other team members.Business-savvy It is essential that the product ownerunderstand the business. As the decision maker regarding whatis in or out of the product, the product owner must have a deepunderstanding of the business, market conditions, customers,and users. Usually this type of understanding is built over yearsof working in the domain, perhaps as a past user of the type ofproduct being developed. This is why many successful productowners come from product manager, marketing, or businessanalyst roles.

Communicative Product owners must be good communicatorsand must be able to work well with a diverse set ofstakeholders. Product owners routinely interact with users,customers, management within the organization, partners, and,naturally, others on the team. Skilled product owners will beable to deliver the same information to each of these differentaudiences while at the same time tailoring their message tobest match the audience. A good product owner must alsolisten to users, customers, and perhaps most important theteam.Decisive Scrum puts a lot of pressure on teams to producefunctionality as quickly as possible. Teams are frustrated whena product owner responds to a question with, “Let me call ameeting or convene a task force to work on that.” A good teamwill understand that this is sometimes necessary, but teams arevery perceptive at knowing when a product owner is actuallyjust trying to avoid making a hard decision.Empowered A good product owner must be someoneempowered with the authority to make decisions and one whois held accountable for those decisions.

Product Owner

Responsibilities:

Providing vision

Providing boundaries

Providing Vision Many of the product owner’s responsibilitiesinvolve establishing and communicating the vision for the product.The best teams are those whose passion has been ignited by acompelling vision shared by the product owner. Who will we beselling to? What is unique about our product? What are ourcompetitors doing? How will our product evolve over time? Ofcourse, the questions are different for an application or service thatis being delivered to a group of in-house users, but having ashared vision is important for motivating a team and creating along-term connection between those developing the product andthose using it. Beyond having a clear vision in mind, the productowner must elucidate that vision for the team. The product ownerdoes this through creating, maintaining, and prioritizing theproduct backlog. It doesn’t matter to me who performs thephysical act of writing the product backlog; what does matter isthat the product owner is the one who makes sure it happens. Ifthe product owner delegates this to a business analyst and theanalyst gets sidetracked and fails to write the product backlog, it isstill the product owner who is responsible.

Providing Boundaries Vision and boundaries can be thought ofas competing aspects of the project. The vision shows what theproduct can become. The boundaries describe the realities withinwhich the vision must be realized. Boundaries are provided by theproduct 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 todictate things such as this— especially the date— I am met withangry responses. “No,” they tell me, “estimates are up to theteam. All the product owner does is prioritize the work.” Althoughthose statements are true, the product owner is also responsiblefor defining the boundaries that will determine the success of theproduct.

Each team needs exactly one

Product Owner

Each team needs exactly one

Product Owner

Each team needs exactly one

Product Owner

The Scrum Masteras

Product Owner

One common consideration is whether the Scrum Master andProduct Owner roles should be combined. No. In the vast majorityof times I’ve seen this done, the results have been disappointing.Not only does combining these roles put a lot of power in oneperson’s hands, but it also creates confusion for both teammembers and the Scrum Master/ product owner hybrid. A certainamount of tension should exist between these roles. Productowners continually want more, more, more features. ScrumMasters protect their teams by pushing back against the productowner when they feel that pushing their teams harder would bedetrimental. When the roles are combined, this tension isremoved.

The Product Ownerdelegates decision making

but then overrules the decision maker

The Product Ownerpushes the team too hard

Product owners are often under pressure to deliver financial resultsto the company; more features delivered sooner is one way forthem to achieve it. I have no objection to a product owner whoannounces at the start of a project, “We need to build a productthat is smaller, better-performing, and cheaper than ourcompetitor’s, and we need to do it in three months less than wespent on the last product.” As long as a challenging goal like that isaccompanied by appropriate freedom in how the goal is achieved,the team will do its best. The problems arise when the team is keptunder constant and changing pressure from iteration to iteration.One difficult goal of “do this amazing thing in 6 months” is in manyways less stressful for the team than 13 successive two-weeksprints of “I need more, more, more!” If you have product ownerswho are pushing teams this way, the Scrum Masters should firstpush back and then work with the product owners to set longer-term goals for the teams while ensuring teams havecommensurate degrees of freedom in how those goals areachieved.

The Product Ownerwants to cut quality

The Product Owneris 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 AdminThey 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 projectin 3 steps ☺

Story brainstorming

Affinity estimation

Velocity prediction

Story brainstorming

As a <role>,

I want <goal/desire>

so that <benefit>

Story brainstorming

I Independent

S Scalable (small sized)

T Testable

Story brainstorming

• Step 1

– Focus on quantity

– 10 minutes

• Step 2

– Focus on quality

– 15 minutes

An Agile way to estimate a projectin 3 steps ☺

Story brainstorming

Affinity estimation

Velocity prediction

Affinity estimation

Affinity estimation

….

Affinity estimation1 3 4 8 12

An Agile way to estimate a projectin 3 steps ☺

Story brainstorming

Affinity estimation

Velocity prediction

Velocity prediction

Velocity prediction

Velocity prediction

Velocity prediction

Velocity prediction1 3 4 8 12

Velocity prediction

18