Thursday, February 9, 2012

ScrumMaster Basics

I recently spoke with a group of ScrumMasters who were new to their teams, new to their organizations and new to Agile. Although this is far from ideal, it happens occasionally, particularly in organizations undergoing a period of dramatic growth or in those new to Scrum.

These ScrumMasters told me they were able to find a lot of good information online about Scrum, but most of it was either targeted at more experienced ScrumMasters or contained little practical detail for new ScrumMasters.

This article is the first in a series intended for beginning Agilists.

Becoming a ScrumMaster

Mike Cohn, of Mountain Goat Software and author of multiple Agile books, says, “In an ideal world a team would select its own ScrumMaster, but that it isn’t always practical.”

However you came to be a ScrumMaster, certain characteristics will increase your success in leading a Scrum team. Below is a compilation of those characteristics as identified by leading Agilists (see references below). Even if you don’t feel you have all these characteristics, being aware of them can help you start fostering the behavior and attitudes to develop them.

Qualities

  • Exercises initiative
  • Flexible & resilient
  • Optimistic
  • Detached
  • Shows discernment
  • Supportive
  • Responsible
  • Humble
  • Collaborative

Skills

  • Agile and technical coaching
  • Meeting facilitation
  • Deep understanding of Agile values, principles, methods, practices
  • Interpersonal skills
  • Team dynamics and system thinking

A ScrumMaster is NOT

  • Directive
  • Defensive
  • Judgmental
  • Easily frustrated

Now that you know the characteristics of a successful ScrumMaster, let’s talk about the role itself. What does a ScrumMaster actually do?

ScrumMaster Role

According to the 2011 Scrum Guide by Ken Schwaber and Jeff Sutherland, the ScrumMaster role encompasses the following:

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, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team.

The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

The Scrum Master serves the Product Owner in several ways, including:

    • Finding techniques for effective Product Backlog management;
    • Clearly communicating vision, goals, and Product Backlog items to the Development Team;
    • Teaching the Development Team to create clear and concise Product Backlog items;
    • Understanding long-term product planning in an empirical environment;
    • Understanding and practicing agility; and,
    • Facilitating Scrum events as requested or needed.

The Scrum Master serves the Development Team in several ways, including:

    • Coaching the Development Team in self-organization and cross-functionality;
    • Teaching and leading the Development Team to create high-value products;
    • Removing impediments to the Development Team’s progress;
    • Facilitating Scrum events as requested or needed; and,
    • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

The Scrum Master serves the organization in several ways, including:

    • Leading and coaching the organization in its Scrum adoption;
    • Planning Scrum implementations within the organization;
    • Helping employees and stakeholders understand and enact Scrum and empirical product development;
    • Causing change that increases the productivity of the Scrum Team; and,
    • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

At this point, it seems fairly clear that leading standups and talking about the team’s burndown is only the tip of the iceberg when discussing the ScrumMaster role and responsibilities. You also need to know a lot about Agile in general and the Scrum methodology specifically. Where can you acquire this knowledge?

Agile Manifesto

Start by reading the Agile Manifesto. The 4 tenets of the Agile Manifesto are listed below.

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

These tenets are supported by 12 principles.

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity – the art of maximizing the amount of work not done – is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Scrum Methodology

Next, read the Scrum Guide.

The Scrum Guide will offer you a high-level understanding of the Scrum methodology, but there is still a lot to learn. Understanding the value of ritual meetings and the various ways they can be approached is a great next step. Two of the most important ritual meetings are retrospectives and standups.

Retrospectives

A retrospective is one of the most powerful tools in Agile because self-reflection is how we improve. There are many approaches to facilitating a retrospective, all of which can be valid as long as you keep in mind that the purpose of a retrospective is to help the team answer 2 questions:

  1. What do we want to keep?
  2. What do we want to change?

Once you identify what you want to change, you (as a team) need to prioritize the changes, choose a reasonable number of changes to work on (typically 3-6), decide what experiment you will use to create the change, find an owner to drive the change, estimate a timeline, and follow up. Often, these changes can be identified in a Sprint Retrospective and then carried into Sprint Planning as an agenda item.

Sometimes, teams identify changes that cannot be accomplished within the team, but cross over to other groups. In those cases, the changes can be taken to the Sprint Review, where larger groups can be told about the issues.

For more details on retrospectives, read Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. This book is the gold standard among Agilists for conducting retrospectives.

Standups

Standups, also known as Daily Scrum meetings, are limited to 15 minutes and answer the following 3 questions:

  1. What did I do yesterday?
  2. What am I doing today?
  3. What are my impediments?

Standups are not status meetings. The Scrum Guide characterizes standups in this way:

Daily Scrums improve communications, eliminate other meetings, identify and remove impediments to development, highlight and promote quick decision-making, and improve the Development Team’s level of project knowledge. This is a key inspect and adapt meeting.

Metrics

Another key responsibility of ScrumMasters is to communicate the team’s progress to others within the organization. Meaningful metrics tell a story in two directions – internally to the team and externally to stakeholders outside the team.

The definition of meaningful is determined by the team and the organization. These metrics can be communicated through burndown charts, dashboards, etc., depending on the tools available to the ScrumMaster and the needs of various members of the organization.

Stakeholders

As a ScrumMaster, you will be responsible for facilitating meetings, including developing agendas and inviting attendees. In the past, you may have heard the fable of chickens and pigs as a metaphor for types of attendees. However, as of the July 2011 Scrum Guide, the concept of chickens and pigs in Scrum no longer exists.

Professional Scrum Trainer Steve Porter explains why in an article on the Scrum.org site.

The labels were being used to create barriers between the Scrum team and individuals in the organization who potentially could assist the team in meeting its goals.

As a consultant, I witness many key members of an organization pull themselves away from a Scrum team with comments such as, "I know I'm just a chicken, so I can't say anything.” In some cases these people were key project sponsors or critical system matter experts. These are individuals who, while possibly needing some education and guidance from a Scrum Master, can be critical to the success of a project. The better the level of engagement you get from all of your stakeholders, the better off your project will be. By calling someone a chicken, it doesn't exactly look like you're rolling out the red carpet.

Use judgment as you engage stakeholders in various conversations and be cautious when choosing to shut down input.

How We Do It Here

Every organization approaches Agile slightly differently, tailoring agendas, team members and timing to the needs of the teams and the demands of the product. This can be confusing for new ScrumMasters, but as long as the changes support the intent of Agile (as defined by the tenets and principles of the manifesto), you can feel confident in your approach.

Where Can I Get Additional Help?

  1. Internal Training. Request internal Agile training from your organization.
  2. Online Courses. Several organizations offer online courses, including Mountain Goat Software eLearning and courses from Rally.
  3. ScrumMaster Brown Bag. Invite fellow ScrumMasters to meet for regular brown-bag lunches to discuss topics of interest and get input on questions and challenges from other current and former ScrumMasters.
  4. Agile Coach. Seek 1:1 help from an experienced Agile practitioner within your organization.
  5. Agile Conferences. Many organizations understand the value of conferences and training. Conduct a web search or ask your Agile Coach for opportunities available to increase your skills as a ScrumMaster.
  6. Certification. Certification courses can offer intensive training. Two well-known options are CSM training from ScrumAlliance and Alistair Cockburn’s ICAgile.

References

  1. Beck, Kent et al. "Manifesto for Agile Software Development." Agile Manifesto. The Agile Alliance, 13Feb2001. Web. 17 Nov 2011.
  2. Cohn, Mike. "Leader of the Band: Six Attributes of the Good ScrumMaster." Mountain Goat Software. N.p., 01Feb2007. Web. 17 Nov. 2011.
  3. Derby, Esther. "ScrumMasters and Agile Coaches: More than a Title." Insights You Can Use. 15Nov2011. Web. 17 Nov 2011.
  4. Derby, Esther and Diana Larsen. Agile Retrospectives: Making Good Teams Great. 1. Pragmatic Bookshelf, 2006. PDF.
  5. Porter, Steve. "Chickens and Pigs." Scrum Guide Updates. Scrum.org, 01Aug2011. Web. 17 Nov. 2011.
  6. Schwaber, Ken and Jeff Sutherland. "The Definitive Guide to Scrum: The Rules of the Game." Scrum.org: Improving the Profession of Software Development. Scrum.org, 01Jul2011. Web. 17 Nov 2011.
  7. Szalvay, Laszlo. "Top 7 Responsibilities of a ScrumMaster." Top 7 Business. Christopher M. Knight, 20Apr2009. Web. 17 Nov. 2011. 
Jen Stone Browne
@jenstonebrowne