Before The First Scrum: The Scrum Master

The role of the Scrum Master is arguably the most important role on the Scrum Team. The 2011 Scrum Guide by Ken Schwaber and Jeff Sutherland define the role of Scrum Master as:

"The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practises, and rules. The Scrum Master is a servant-leader for the Scrum Team."

If a Scrum Team is having problems following Scrum practises and rules or is being interrupted and distracted, it's the Scrum Master we hold accountable to correct this. It is imperative that the right person is selected, appointed, or steps into the role of Scrum Master.

Selecting The Scrum Master

The Scrum Master must understand Scrum. This doesn't necessarily mean that the person has committed to memory the Scrum Guide or completed a Certified Scrum Master course but should have an understanding of Scrum that goes beyond these two artifacts. The prospective Scrum Master should have an ingrained knowledge and comprehension of the Agile Manifesto and the twelve principles behind it. The prospective Scrum Master should be committed to following the 5 principal Scrum activities, Sprint Planning, Daily Scrum, Sprint, Sprint Review, and Sprint Retrospective, and the rules of Scrum as outlined in the Scrum Guide.

The Scrum Master is usually selected from within the existing software organization. This may be project managers, team leads, senior software engineers, senior testers, etc. I've listed what seems to be the more experienced personnel of a software organization but I really don't think that a lot of software experience is essential for a Scrum Master. You won't find any technical requirements in the Scrum Guide for the Scrum Master role. In fact, a lot of technical experience could work to the detriment of a Scrum Master. For example, a strong technically minded project manager or team lead is usually an asset in a waterfall, command and control environment but in Scrum, a strong, technically minded Scrum Master may start 'telling' the Development Team how to do their work. The Development Team is meant to be self-organizing and Scrum assumes the people doing the work know best how to do it. From the Scrum Guide: "No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality".

Where I worked, the first Scrum Master came about when the person was asked by management to research the various Agile methodologies but focusing on Scrum, and provide a recommendation on how to best adopt Agile. This exercise really served two purposes: 1) Figure out which Agile methodology best suited the company's current situation (Scrum hands down) and 2) Give the potential Scrum Master a means to obtain a broad understanding of Agile and build a solid knowledge base of the recommended methodology.

Whoever the company or software development organization chooses to be Scrum Master, this person should have the following qualities:

• Be an early adopter,
• Understand, embrace, and be fluent in the Agile Manifesto,
• Be fully conversant in Scrum,
• Be well read on adopting Agile and Scrum,
• Have the stamina and patience to teach Scrum to the organization, and
• Have enormous enthusiasm for all things Scrum.

Be an early adopter: For most organizations, adopting Scrum is or will be a big change from a waterfall methodology. The Scrum Master must believe that Scrum is a better approach to software development. The Scrum Master can help convince the Development Team and software organization that Scrum is a better than waterfall if and only if, the Scrum Master believes this to be true to the core. Suppose a retrospective is skipped because the Development Team couldn't see the value in it two weeks after the last retrospective. If the Scrum Master allows this, the Scrum Master is not convinced a retrospective is needed after every sprint.

Understand, embrace, and be fluent in the Agile Manifesto: This document is the heart of Agile. Customer collaboration, high visibility of work, frequent deliveries, openness and honesty, continuous improvement, face-to-face communications, working software: they're all part of the Agile Manifesto as they are to Scrum.

Be fully conversant in Scrum: The Scrum Master will need to understand the Scrum Guide and it implications. Following the Scrum framework right from the start is essential; anything less will weaken the value of Scrum and can eventually lead back to waterfall. At first, the Scrum Team will probably resist the change to Scrum and will be reluctant to self-organize. What I found was developers new to Scrum are able to go through the mechanics of Scrum but with little appreciation of the benefits of Scrum. A Scrum Master must be able to identify and correct any variances from Scrum immediately.

Be well read on adopting Agile and Scrum: When a Scrum Team first forms, there will be some resistance to change but the Scrum Master can help ease people through it by citing examples of how other organizations got through the various issues the team will face. If the Scrum Master can address the issue and provide possible solutions immediately, the Scrum Team will gain confidence in Scrum and the Scrum Master. Almost any issue a team will face has probably been seen by someone else and they have somewhere documented it on the web. The Scrum Development Group on Yahoo (http://tech.groups.yahoo.com/group/scrumdevelopment/) is an excellent source of information but there are many blogs and other web sources that can be mined for solutions. Or, if you like, you can email me with your issue which I promise to answer quickly. Some areas that will probably cause confusion are:

• User Stories-How to write them and how to estimate them.
• Story Points-How to do relative estimations.
• Acceptance Testing-How to write acceptance criteria and who runs these tests.
• Continuous Integration-How to deliver new/modified capabilities every day.
• Daily Builds-Automating a daily build with automated system, acceptance, integration, and unit testing.
• Daily Scrum- Getting the most out of the meeting in < 15 minutes.
• Technical Debt-How to deal with partially completed stories and bugs.
• Self-Organization-What this means and how to achieve it.
• Development Team Structure-How to deal with former hierarchy and titles in Scrum.

There are many other issues that will pop up but the ones above I've seen in every team new to Scrum.

Have the stamina and patience to teach Scrum to the organization: I think this is the most demanding aspect of the Scrum Master's job.  I was lucky in that my boss was a superb listener and I was able to talk to him and come to better understand some of the issues I was confronted with.

Usually when I had problems with an individual or worst, the whole Development Team, it was paramount to separate the emotion from the logic and facts. I tended to speak a bit slower with carefully chosen words and appeal to the logic of the situation. I once spent over an hour with 2 people trying to explain that failing to meet a commitment (sprint goal) is not the end of the world. The team was unable to complete one of the user stories in the sprint and felt they had failed. My argument was that the complexity of some user stories is not entirely known at the start of the sprint and that the team's velocity, the average amount of work the team can expect to achieve during a sprint, is really a guide of the amount of work the team might achieve. If the team doesn't feel they can meet the goal of the sprint then the goal should be re-negotiated. In this case, the team was unable to see that they weren't going to meet the sprint goal-a common practice of developers I've seen over the years. Like the people on the Titanic, they believed that rescue was only moments away even while the ship was so obviously sinking. Why developers sometimes feel they'll be fired; not yelled at, not take a pay cut, but fired for making an inaccurate estimate is beyond me. In almost 30 years I've never seen the slightest disciplinary action against an individual for making an estimate that proved in fact to be wrong. In any case, after spending over an hour talking about vagaries of software estimates and about using the retrospective to figure out why the team over committed, I went home thinking that I failed to reach these people. You can imagine my surprise and strong emotional response when early the next morning I found an email where one person got it and realized that with Scrum, they can only do what they can do and that over commitment, especially in the early sprints, is something nobody is too upset over and that during their retrospective, the team needs to understand why it over committed  and make the appropriate modifications.

Have enormous enthusiasm for all things Scrum: If you need to pretend to be enthusiastic about Scrum then being a Scrum Master is not for you. I really loved being a Scrum Master. I was genuinely moved when the light turned on for team members as they comprehended the various facets of Scrum. My philosophy was that you initially do Scrum by the book (i.e. Scrum Guide). If something isn't working after you've given a fair chance then solicit from the Scrum Team on what should change. However, after two years doing Scrum, nothing about Scrum changed. Of course there were changes on how user stories were written, how to do acceptance testing, and other technical components but nothing about Scrum actually changed. The Development Team may take a while to make the transition between waterfall and Scrum but the Scrum Master knows Scrum is better and will be constantly pointing out to the team why Scrum is better.

Tweet