Seven Things I Wish I'd Known When I Started out as a ScrumMaster

Typically, when an organization starts using Scrum, the person chosen to play the role of ScrumMaster comes from some sort of managerial background. The organization expects that the manager, the so-called "Master," will get the Scrum project delivered because she has managerial expertise — and will handle it along with two other projects she's managing at the same time.

That expectation itself is the first impediment to deal with. Otherwise it's almost certain that the organization won't get the benefits it should out of the Scrum project. Remember, there are no right ways to fulfill the wrong expectations.

I wish I'd known that fact when I first started playing the role of ScrumMaster several years ago. Following are seven more things I wish I'd known when I started out as a ScrumMaster:

1. Work on one (and only one) project.

"If you chase two rabbits, you will not catch either." — Russian proverb

Consider this: If you're 100 percent committed, when you choose to work on two projects, you imply that you're only 50% committed to each one. That's a disservice to the organization you serve and to the customers your organization serves, isn't it?

Michael James has contributed a fantastic resource on what makes a great ScrumMaster, and it highlights this point effectively. Here's my paraphrase: An adequate ScrumMaster may handle two or three teams at a time, but the most effective ScrumMaster chooses to handle one team at a time.

Many ScrumMasters know this, but they don't take a stand because it seems like a risky proposition. You're working on only one project, and if that fails, you will be a failure. But that's the whole point. That fear will bring out the best in you and inspire you to bring out the best in your Scrum team.

2. Focus on improving team effectiveness.

It's OK if team effectiveness comes at the cost of individual efficiency. Building great software is what matters, regardless of who does it.

In Scrum projects, a focus on individual efficiency is an impediment. Here's the chief reason: To achieve individual efficiency, team members are likely to shy away from practicing Scrum principles, such as transparency and collaboration. For example, if a team member is focusing on achieving individual efficiency, he may choose not to communicate some information that might be useful for the project so that he can use that information to prove that he's more efficient than other team members.

Reflect on the quote written by author Margaret Carty: "The nice thing about teamwork is that you always have others on your side." It resonates with one of the prime Agile principles: customer collaboration over contract negotiation. Inspire your team members to consider every other team member as the customer with whom you all have to collaborate and bring out the desired result.

3. Don't manage, facilitate.

This might be a difficult one for a manager, but it's important to understand that Scrum is based on the principle of self-organization that requires facilitation, not management. So any attempt to "manage" the team members is anti-Scrum.

Pete Deemer has written a must-read article on manager's role in Scrum. Below is my take on its basics.

What not to do:

·         Don't make decisions on behalf of other team members.

·         Don't assign the work to the team members.

·         Don't keep track of what the team members are doing.

·         Don't incorrectly "own" other team members' work.

·         Don't engage team members in status meetings.

What's OK to do:

·         Help remove impediments.

·         Organize one-on-one mentoring sessions for the team members.

·         Give input about how to make features better.

·         Collectively participate in hiring new team members.

·         Help plan team members' career development activities.

The manager's role is concerned with doing things right and complying with the standards, whereas the facilitator's role is about doing the right things and creating the product. These roles require different types of skills, so get convinced that facilitating is what you want to do — or explore non-Scrum work options.

4. Establish a "work-life balance" as early as possible.

Too many people, including Scrum team members, don't know how to live until they interact closely with death. They spend the best of their time chasing what I call fool's gold by neglecting their own health, their relationships, and other important pleasures of their lives.

The result? Burnout, unhappiness, half-hearted work, and, at best, mediocrity.

In order for each Scrum team member to perform at his best, it's important that the work the team members pick isn't too much for them, requiring them to spend long hours and weekends in the office at the cost of their health, relationships, or leisure activities.

The classic book The One Minute Manager, by Kenneth Blanchard and Spencer Johnson, puts it clearly: "People who produce good results feel good about themselves." By ensuring a work-life balance, you help people feel good about themselves.

Someone asked me the other day whether a 40-hour workweek contributes to a good work-life balance. There are no right answers to this question; much depends on the person and the situation. The point here is to figure out a win-win solution for the team and the organization, one that helps the team produce great results.

5. Ensure that each team member knows what "done" means.

The problem with the definition of "done" is that it's relative. For the person who carrying out the work, finishing her part of it means she's done. Producing software is a complex activity, however, and it's important that all team members understand exactly what "done" means for the given project.

When a team member says a particular feature is "done," how does he ensure that it's done per the expectation? Agile coach and Certified Scrum Trainer Dhaval Panchal has written avery good article to help teams figure out what "done" means. I'd summarize it this way: The definition of done is a nonstatic, auditable checklist that is influenced by reality. So, as a team, identify what the "potentially shippable state" is for a feature, a sprint, and a release at large. Then commit to accomplish each task per its definition of done.

6. If a team member is not thrilled by the project and committed to achieving its purpose, the ScrumMaster is not doing a good job.

Consider the example of an orchestra. All the musicians, along with their conductor, work in sync to achieve a common goal: to produce great music. If even one person is out of sync, the resulting music isn't good, much less great. Scrum teams are no different. All Scrum team members, along with their ScrumMaster, work in sync to achieve a common goal: to produce great software. If even one team member is out of sync, the produced software feature might be out of order. That's an impediment the ScrumMaster must remove.

7. The ScrumMaster is not the boss.

Anyone trying to be the boss of other team members is behaving in an anti-Scrum manner.

Unlike managers, the ScrumMaster is to be a "servant leader." The ScrumMaster is a coach for the team, not the boss. She facilitates the project work in a way that delivers according to the definition of "done."

Although they have some authority over the Scrum process, many new ScrumMasters struggle to play the servant-leader role, with no formal authority over the team members.

Think of the ScrumMaster's role as similar to that of a health coach, who helps you follow an overall health routine, including establishing good eating habits and exercising properly. A good health coach will inspire you to learn about the benefits of healthful activities, such as eating well, exploring yoga, getting other regular exercise, and so on. In fact, however, the health coach has no formal authority. He can't force you to follow a routine. Instead, he must connect you with the health commitments you've made to yourself.

The ScrumMaster too is expected to make a difference while not having any formal authority over team members. That requires a 360-degree change in the mind-set of some, and it can be difficult for newbie ScrumMasters. But it's said that opportunities come wearing the masks of difficulties. So make a correct choice, and give it your best and most thoughtful try.

In summary

If you're aware of these suggestions and you're still not able to practice them in your Scrum projects, there are some gaps in your understanding or execution. But remember, these gaps are nothing but opportunities for you to shine as a leader, beyond whatever title you hold in your organization. Go make that change happen.