This is the third in a series of posts walking through my approach to the performance review process for Scrum Masters.

 7. Determine the meaning of “meets expectations” for the Scrum Master role.

8. Cross-reference the Scrum Master expectation headings with company performance categories. 

9. Determine ratings based on your definition of “exceeds expectations” and your cross-reference exercise.

This is the second in a series of posts walking through my approach to the performance review process for Scrum Masters.

4. Observe, Observe, Observe

•  Be present. In my role as a Methodology Leader, I am able to bounce between many of the Scrum sessions for different teams throughout the day. I set the expectations with the teams early on that I am there as an observer only so they have become comfortable with me hanging around. It’s a fascinating experience watching as each team establishes their own rhythm, environment, and social norms. Be careful not to look at the deviations of approach between teams and treat them as a negative. Embrace and appreciate the diversity each team represents.
• Watch. The primary thing I look for is body language, movement, and position. Are team members physically engaged during planning sessions? Are they huddled around story cards with multiple hands moving things around? You will often see some team members start slowing pushing their chairs away from the table if they are feeling uncomfortable. View the daily stand-up meetings from afar. Are they standing? Are there sub-groups having their own dialog?  Much can be learned by just watching.
• Listen. What language does the team use in planning sessions and retrospectives? Is it uplifting or degrading? Is it focused on blame vs. a “live together, die alone” attitude? Is everything alway perfect? Is everything always failing? Does it foster self-healing and progress? Is the daily stand-up focused on the typical 3 questions or sporadic and prone to lengthy discussion? Along with the “watch” bullet point, there are plenty more questions that can be asked here.
• Identify those who would be able to provide the best feedback. Look for the quiet ones. In one-on-one meetings they consistently provide the best feedback and are an amazing source of what is really happening on the team. If you have remote employees, find a few to chat with about their level of inclusion with the team. And the people who were pushing away from the table…definitely on the list of people to talk to for feedback on team dynamics and inclusion.

5. Meet with the Product Owner for specific feedback on their happiness with the progress of their product vision and team performance.

• Periodically check in with the Product Owner. At least twice a year seems appropriate but stress to the product owner that you have an open door for any feedback or concerns that need quick attention.
• Use your noble cause and expectation diagram as the center of discussion. By pulling in your noble cause and expectations diagram, this conversation becomes crisp and focused. The Scrum Master is a unique role and your product owners may be more familiar with what a typical project manager would do. Your expectations diagram should help alleviate any confusion and guide your conversation appropriately.
• Ask specific and probing questions. I have created a list of starter questions around each expectation. Typically, the questions sound like, “Does your team have a sense of self-healing and is resolving internal team issues themselves?” for the Foster Team Health expectation or “Does your team need to consistently perform “heroic” efforts to live into sprint commitments?” for the Maintain Flow expectation. Having these questions keeps the conversation on track to ensure you get feedback that is focused on the expectations and is fair and unbiased for each Scrum Master.

6. Get specific feedback from team members.

• Build a set of team member questions. For team members, I would use similar questions to the ones used with the product owner with just some slight deviations. Something like, “Does your Scrum Master relentlessly remove team impediments in a timely manner?” for the Remove Impediments expectation or “Are your team retrospectives highlighting meaningful things for the team to work on?” for the Change Your Community expectation.
• Request feedback from the team members identified during the observation period. A couple of weeks before a review, pull out the list of people you have identified to receive feedback from and setup 1/2 hour sessions with them. An hour is too long and having your questions ready should make this move along.
• Build triads. Based on the Tribal Leadership principle of building triads, I try to end each session by asking them to share some of their feedback with their Scrum Master personally. Most people don’t like sharing anything negative about their peers so this gentle nudging goes a long way in building trust and community.

This is the first in a series of posts walking through my approach to the performance review process for Scrum Masters.

PREPARATION

1. Set clear and visual expectations for the Scrum Master role.

• Determine a “noble cause” for your Scrum Masters. Our noble cause is “Amazing Workplace + Happy Product Owners.” As we emerge from our Agile transformation, we have tried to build a strong culture based on trust, inclusion, and collaboration while delivering frequent value to our customers. This noble cause seemed to fit nicely – very simple and has a nice ring to it.
• Clearly set the expectations for the Scrum Master to live into the noble cause.I will be drilling into each of these in future posts
  

  A high level view of the role of the Scrum Master.

  but on a high level we need our Scrum Masters focused primarily on team health, maintaining flow, removing impediments, shaping the team experience, radiating information, and being change agents for the organization.

• Create a format that works for you to communicate the expectations to your team and others. I chose to create a sketch but whatever approach you choose, there should be no questions or ambiguity. Preferably, this is not a bulleted list in a presentation – take the time to make this memorable and motivating. Personally, I would rather draw this out with stick figures and arrows than to have someone read through another 50-word, 20-pt font slide.

2. Meet with the Product Owners to explain what they should expect from their Scrum Master.

• Share the noble cause. If the team is meeting their sprint commitments and seems to be getting along while doing it, chances are good that the product owner is a happy camper. The Scrum Master is responsible for putting the team in a position to make that happen by living into expectations for their role. Stress the balance between a happy owner and an amazing workplace. For example, if the team starts to get fried-out, there may be times when the planning velocity should be reduced and less work is completed in order to protect the health of the team. The Scrum Master should have a strong feel for the pulse of their team and be driving this discussion with the product owner.
• Get into some of the details. Provide an overview of the details behind each expectation. Explain that retrospectives should provide powerful information for the team to use to self-heal, explain how impediments should be removed in a timely and relentless manner, etc. You will need this information later…

3. Schedule regular sessions with your Scrum Masters individually to deliver ongoing feedback, praise, and encouragement.

• Put reoccurring sessions on the calendars of your Scrum Masters. I let each individual determine how frequently but it is always at least once a month. For some, they prefer once a week while others go bi-weekly or monthly. For those who may be struggling with living into the noble cause and expectations, I will require meeting once a week to provide real-time mentoring until they are back on their feet.
• Be the Chief Encouragement Officer. Generally, this should be a very positive experience for the Scrum Master by focusing on what is working well and the awesome things that are happening within their team and the organization. Do not put them in a position to dread this meeting. If you have feedback for them, share it by providing the necessary context with a touch of coaching. Don’t lecture, let them figure it out.

As the end of the year approaches, you may be facing the task of preparing for and/or receiving an annual performance review. Like many others (such as Esther Derby), I feel that we need to start thinking differently about this tradition. The reasons are many and Esther does a fine job of describing the reasons the current process is flawed and is probably more of a disservice to our people so I won’t get into specifics. Needless to say but there is just something about the typical performance review that does not feel natural in a truly Agile organization.

So, if you are in an organization moving to a whole-system Agile methodology, you may be in the same dilemma – how do you provide performance reviews when the people who report to you are in self-governing and self-accountable teams? How do you get insight into how well people are performing without being a member of one of those teams? How do we create, as the book “Get Rid of the Performance Review” states, a dynamic setting where employees joyfully live up to their potential?

With seven Scrum Masters now reporting to me organizationally, I needed to come up with this dynamic setting that fit into the current system of performance management, yet still make this a meaningful experience for my team. Scrum Masters are also a bit tricky as they typically don’t have quantitative metrics associated to the role, such as developers or testers may have. Until a broader performance review system is in place, I have experimented with a few things and while many of this could be found in leadership books everywhere, here are the steps I used this year. I will be drilling into the details of each of these over the next couple of weeks.

NOTE: Before going through this, the going in assumption is that you are NOT dealing with someone with substantial performance or HR issues and this person has the desire to be an exceptional Scrum Master within your organization. If you are dealing with someone who shouldn’t be or doesn’t want to be a Scrum Master then take the necessary steps to move this person into a better role as soon as possible.

PREPARATION (details)

1. Set clear and visual expectations for the Scrum Master role. There is just something about seeing a picture…

2. Meet with the Product Owners to explain what they should expect from their Scrum Master.

3. Schedule regular sessions with individual Scrum Masters to deliver ongoing feedback, praise, and encouragement.

DATA GATHERING (details)

4. Observe, Observe, Observe. (throughout the year) I’ll be discussing what to look for in a detailed post.

5. Meet with the Product Owner for specific feedback on their happiness with the progress of their product vision and team performance. (Ongoing but not overly frequent and formally a couple weeks before the review)

6. Get specific feedback from the team members identified in #4. (a couple weeks before the review)

TRANSLATION (details)

7. Define the meaning of “exceeds expectations” for the Scrum Master role.

8. Cross-reference the Scrum Master expectation headings with company performance categories.

9. Determine ratings based on your definition of “exceeds expectations” and your cross-reference exercise.

DELIVERING THE RESULTS (details)

10. Visually and specifically show the results based on the Scrum Master expectations.

11. Focus on the positive and personal strengths (75%) and show the specifics for any areas of development (25%).

12. Reveal and discuss the ratings from #9 and how they were translated from the expectations.