Scrum Master Sync

How did it all start?

Once, while facilitating a retrospective, I realised it was a disaster on multiple levels (though I will not categorise it as a failure because it was a great learning opportunity for me). 

What is it that went wrong during the retrospective?

• Selecting an intense activity for a short time duration.
• No time management, prolonged discussions without timeboxing.
• Abruptly ending the discussion in the middle due to lack of time.
• After completing the next sprint, picking up the half-done communication, and continuing without briefing about the previous discussion. The team was in a different mindset and didn’t recollect most of the points that were mentioned in a few words on the stickies. The team felt lost, disconnected.
• Wasted two opportunities by continuing with the incomplete retrospective activity from the previous retrospective in the following one. 

This was like a retro nightmare – but also one of the most amazing learning opportunities for me as a Scrum Master. Rather than shying away from this setback, I started to collect feedback from my team members and discuss it with another fellow Scrum Master. The feedback helped me leverage my learning by shining a spotlight on my shortcomings. 

It was the first time that the awkward silence between the Scrum Master community broke and we expressed our feelings. We spoke about overwhelming situations, which made me feel lighter and more confident. This one-time incidence of sharing my failures, learning, and insecurities boosted my confidence, and the other Scrum Masters felt the same. So we came up with a weekly short Scrum Master Synch meeting famously known as SMS. 

The Scrum Master Sync meeting is a great initiative that has benefited a lot of us. It provides the Scrum Masters with the platform to express our feelings, share our observations, bring in different perspectives, question our assumptions and find answers together, agree and disagree, and talk about vulnerabilities. It’s an opportunity to discuss various topics and try to look at the same problem from a different perspective, challenge each other, and reason the actions we take. We support each other and are always glad to just say hi. It gives us a chance to improve in order to better support our teams.

Unknowingly, the “Disastrous Retrospective” became our first topic of discussion and the start of SMS.

Presenting SMS - A safe space for Scrum Masters to raise questions, share experience, bring in new perspectives, learn, and expand horizons.

When an organisation is on its way towards growth, things change rapidly, and making sure that the focus remains on the agile mindset is the responsibility of the entire organisation led by the Agile Coach or the Scrum Master community.

There are a lot of unknowns for the Scrum Master on this journey, and continuous experimenting and learning are required to fill in those gaps. The Scrum Master is a one-of-a-kind member on the team, having no one to observe and learn from, no one to give validation and receive feedback from. 

Development teams have peers and experienced fellow team members that help them grow in their roles. Code reviews and technical discussions are a way to improve and learn from each other, providing growth opportunities. A Product Owner or a Scrum Master, on the other hand, needs to explore and learn on their own. That is why building a support community can be very beneficial.

Asking practical questions, sharing experiences, observing other Scrum Masters facilitation skills, experimenting with the different communication styles, practising mock events or meetings – all of these help identify gaps in facilitation and boost confidence. 

SMS Case #1: Disastrous Retrospective

Case background

How can we gather feedback and learn from our mistakes?

Feedback is a very valuable tool if utilised correctly. Since this was the first unintentional SMS discussion, it wasn’t structured. I collected feedback from team members and discussed it within the Scrum Master community.

Discussion:

• Take your time choosing an activity and ensuring that the appropriate amount of time is reserved on the schedule for it.
• Timeboxing all parts of the retrospective process allows for more focused discussions. Setting screen timers is quite beneficial, as are reminders such as the "last two minutes remaining". For instance, team check-in takes 5 minutes. The team then had 15 minutes to add inputs to the retrospective board.
• Providing specific instructions and setting expectations. In a retro exercise, for example, the team is supposed to add sticky notes with information clarifying their point. The team can begin with section A, then go on to section B, and finally to section C.
• It's fine if the activity is half completed and the team was unable to discuss all aspects of it, as long as the team was satisfied with the conversation and was able to draw some valuable conclusions.
• Depending on how the team feels, you can either continue the half-done activity during the next retrospective or start again with a new one and leave the half-done one alone because you've already derived value from it. Ask the team to make the choice rather than the Scrum Master deciding it on their behalf.
• If the team decides to continue with the half-done activity, give a summary of what was discussed so that everyone is on the same page. Allow the team to reconsider all of the undiscussed points that were added to the board. Things may have changed during the sprint, so allow the team to reevaluate what was written and make any necessary changes. This helps the team's alignment.

Conclusion:

When the team was asked for feedback and suggestions for changes, they were enthusiastic. Showing your vulnerabilities makes you stronger and allows you to improvise. Sharing one's vulnerability inspires others to share their own fears and vulnerabilities. After hearing comments, I recognized that I had been overly harsh of the disastrous retro, but the team did not share my opinion. They did enjoy some parts of the discussion that helped them identify potential problems.

SMS case #2: Role of a Scrum Master

Case background

Is a Scrum Master merely a facilitator, or are they a team member who may point out problems? 

It is very crucial for a Scrum Master to understand when to participate and when to stand behind the line and let the team explore.

I have tried to experience and explore the responsibilities of a Scrum Master and I often get stuck at some practical stuff. I read about the 8 stances of Scrum Master-Servant Leader, Facilitator, Coach, Manager, Mentor, Teacher, Impediment Remover & Change agent. This supports the understanding of the Scrum Master’s role and responsibilities on a theoretical level. What intrigues me the most about the Scrum Master role is the practical side of it. We covered a practical subject during one of the SMS meetings, which was considered from multiple points of view.

Is a Scrum Master merely a facilitator, or are they a team member who may point out problems?

During retrospectives, I was always in a dilemma: should I just be a facilitator, or should I also participate as a team member and provide my inputs by pointing out problems that I have observed?

For example, as a Scrum Master, I’ve noticed that team members often provided no communication on the progress of their tasks if they missed daily’s or took leave(s).

There are two types of leaves: planned and unplanned. When you take an unanticipated leave and need to attend to something important, it is obvious that updating on task progress is not possible. This is particularly felt when team members take vacations or miss daily meetings, there is “No Communication” on how the task is progressing. The majority of teams skip the task without updating it, and no one else picks up the work, therefore “No Communication” is not an issue for the team. 

It is, in my opinion, difficult, since we want to form cross-functional teams and work on prioritised tasks. Due to a lack of communication, we are also unable to predict whether or not the team will be able to reach the sprint goal.

As a Scrum Master, I attempted to engage in the retrospective and bring up the issue of communication breakdown. Because the team had failed to see the issue, they refused to take responsibility for it. Rather, the team defended its position, and we squandered an opportunity to talk about something interesting that the team was prepared to own and modify.

Discussion:

During our SMS conversation, some of the other Scrum Masters brought up some intriguing issues:

• Did you have any evidence or examples of other team members being blocked because they were unaware of what needed to be done by someone else, owing to a lack of communication?
• Are there any other critical or painful concerns that cause the team to overlook this communication breakdown problem because it isn’t a roadblock?
• Is everyone in the team really on board with the definition of a cross-functional, self-organised team that works on prioritised tasks? Is it possible for team members to switch tasks?
• Transparency is harmed as a result of a lack of communication, and the team recognizes this as a problem. Is it vital for the team to be transparent at every stage of the process?
• They don’t want to find a solution if it isn’t a problem that’s getting in their way. Perhaps the team wasn’t ready to receive that message at the time.

Conclusion:

It depends on finding the right balance between – sharing observations on team behaviour and what the team thinks about it vs. trusting the team to raise things themselves.

Whether as a facilitator or as a participant, as Scrum Masters, we should share our observations with the teams without expecting them to take action.

The Scrum Guide does not handle the need of Scrum Masters to get feedback and improve themselves. It's like, who is the therapist of the therapist? :) 

In this article I tried to show a method we came up within our organisation and provide some examples, hoping it can help other Scrum Masters who feel like I do. 

Would love to hear your thoughts!