Confession of a Scrum Master

My Journey of Personal and Professional Growth

A Scrum Master's journey is about experiencing and learning from all the mistakes, and improvising at every stage of this journey.

Scrum is a simple framework, and simplicity brings complexity when we do not understand the why behind the way the framework is designed to work, and the same applies to the responsibilities of all the involved roles.

My Scrum Master journey started somewhere in early 2017. But the truth is, I started working as a dedicated Scrum Master in August 2021. I was a Product Lead and a Scrum Master, later, I became a Product Manager and a Scrum Master and finally, I became a Proxy Product Owner and a Scrum Master. I was never an exclusive Scrum Master; I was more of a sidekick Scrum Master. Which always blocked my mind from grasping its full potential.

I have always been in positions of control, which contradicts the role of a Scrum Master. Implementing stuff as a Scrum Master was easy, as the other half of my title did that for me. I took more decisions on behalf of the team. If this resonates with you, follow my journey of learning and unlearning to become a better Scrum Master.

I was always good at my management roles and was an amateur Scrum Master. I am more comfortable being responsible and making decisions. Leading the way, being a Scrum Master is about encouraging others to lead and making sure you create a support infrastructure for the team to succeed. Let me take the steps and create a supportive environment where they can actually experiment and grow.

The classic Scrum Master mistakes that I am guilty of:

Estimation vs. Commitment: Holding the team responsible for story points.

Misunderstanding estimation as a commitment made the team feel as if they had to jump through a ring of fire during estimations. The consequence of this was buffer time. Every Product Backlog Item had some buffer estimates added to it just to be sure the team was able to meet the commitment. The team suffered burnout when they faced challenges and were forced to do firefighting. This was also a classic enemy of maintaining a sustainable pace. The team was either far too relaxed due to the buffer time or the other extreme end was burnout. This was the general feedback that was gathered during Retrospectives from the team.

It is important that the team understands how estimation works and they gradually get better at it. I believe it is always good to go over the story points regularly to check if the team has a shared understanding. Does a story estimate means the same to every team member? If they are not aligned it is a good time to have a discussion and help the team ask the right question and clarify assumptions. We actually noted stories that we over estimated or underestimated. We discussed those stories and the reasoned the unrealistic estimations. This helped the team get better and shared understand about the sizing technique.

Balancing Roles: Avoiding Overstepping Boundaries of different roles

The other part of the title always did the trick. At times, my presence was more as Product Manager or Project Lead or Proxy Product Manager which resulted in changing the daily’s in stand up meetings. I did refrain from repeating this mistake, but on certain occasions, it just happened. I was not influencing my team by leading the way; rather, I was giving directions. Involving myself in all kinds of discussions that a Scrum Master should not get involved in Sometimes having strong technical knowledge can become dangerous. I was definitely adding value, but at times I was asking questions that might just result in distractions.

Being in a command and control position, which the hierarchy imposed, typically meant that I had the power to establish goals, allocate resources, assign tasks, and make final decisions. This was in conflict with the core nature of the Scrum Team.

The Daily Scrum are for the team to help understand how they are progressing towards the Sprint Goal. These are not technical discussion or refinements or even 1-to-1 reporting meetings with your manager. This is a team meeting and the team owns it. The Scrum Master, Product Owner or Manager should not highjack it. If they attend the daily they need to be passive participants.

The Pitfalls of Jumping to Conclusions

Jumping to conclusions and giving solutions right away based on my experience without letting the team explore what works best for them. The team did appreciate the help and made those decisions but didn’t own them, which ultimately led to failure. The ideas were great, but they weren’t the best fit for the team. The suggestions were based on my experience and not the team's.

To address the issue of jumping to conclusions and providing solutions based on my own experience, I need to create space for the team to explore and find their own solutions. While the team may appreciate my input, it’s important that they own the decisions they make and that these decisions are based on their own experiences and insights. By empowering the team to take ownership of their decisions and encouraging collaboration, we can find solutions that are not only great, but also the best fit for the team. This will require me to step back and allow the team to take the lead, while still providing guidance and support as needed. Ultimately, this approach will help build a stronger, more self-sufficient team that is better equipped to handle challenges in the future.

Scrum Manager — Micromanagement

Having a Project Manager mindset, I also prioritised Product Backlog Item with the Product Owner for the team. Trying to be a Scrum Manager rather than a Scrum Master. Continuously monitoring and micromanaging the team.

To address the issue of trying to be a Scrum Manager rather than a Scrum Master, I need to shift my mindset and focus on empowering the team to prioritise and deliver stories. This means trusting the team to take ownership of their work and prioritise their own tasks, rather than trying to micromanage their every move. As a Scrum Master, it’s my role to facilitate communication and collaboration between the team and the Product Owner, rather than taking control of the prioritisation process. By stepping back and allowing the team to take the lead, we can foster a more collaborative and self-organising environment that leads to better outcomes. This will require me to let go of some control and trust in the skills and abilities of the team, but the result will be a stronger and more cohesive team that is better equipped to deliver results.

The Ring Master: Rigid Adherence to Scrum Rules

I am also guilty of focusing on tools and following the rules rather than adapting the mindset. The best example was daily’s, without understanding the reason behind these boundaries (in this case, timebox), just making things mandatory. The approach taken was to strictly limit the team’s daily discussions to 15 minutes without delving into the underlying reasons for these extended conversations. To understand why the team felt the need to discuss topics during the daily instead of focusing on updating progress towards the shared Sprint Goal.

To overcome this issue, it’s important to focus on the Agile mindset and values, rather than just following the rules and using the tools. As a Scrum Master, it’s crucial to understand the reasoning behind the practices and ceremonies, and help the team understand their importance. Instead of imposing strict time limits on daily standups, it’s important to understand the root cause of extended discussions and work with the team to find a solution that works for them. This involves being open to feedback, facilitating discussions, and encouraging continuous improvement.

King of Scrum

Owning the Scrum events, not letting the team take ownership, and marking my territory. I sent all the meeting invites and facilitated the Retrospectives, and in my absence, the team postponed or even canceled the Retrospective. This was definitely not helping in building self-organising or self-managing teams. I was actually making the team depend on me for making these arrangements and facilitating them. Trying to help when it was not needed.

It’s good that I started recognising the negative impact of my behavior had on the team’s ability to become self-organised. It’s important for the Scrum Master to create an environment that encourages collaboration and team ownership. Here are some suggestions on how to shift the approach based on my experience: Encourage team participation: Instead of owning all the Scrum events, encourage the team to take ownership of the meetings. Start by delegating tasks and responsibilities to different team members, such as leading the Daily Scrum or facilitating the Sprint Review. This will not only help the team build ownership but also provide opportunities for skill development. Step back: During the meetings, try to take a step back and let the team lead. You can still offer guidance and support when needed, but let the team take the lead in problem-solving and decision-making. This will allow the team to build confidence in their abilities and work towards becoming self-organised. Empower the team: Encourage the team to take initiative and make decisions on their own. For example, if you cannot attend a Retrospective, allow the team to decide if they want to reschedule or proceed without you. This will help them develop problem-solving skills and feel more ownership over the process. Facilitate, don’t control: As the Scrum Master, your role is to facilitate the meetings, not control them. Allow the team to share their ideas and opinions freely without interrupting or dominating the conversation. Encourage open communication and collaboration among team members. By shifting your approach and empowering the team, you can help them become more self-organised and successful in their work.

As a Scrum Master, I have come to realise the importance of leading by example and constantly striving to improve myself as a leader. Through my role, I have been introduced to many interesting topics and tools that have helped me grow and develop.

To improve my facilitation skills, I have taken several steps, such as reading books, attending IMPROV workshops, participating in the Road to Mastery workshop, and blogging about my experiences. I have also actively engaged with the broader Scrum Master community, attending conferences and networking events and building a Scrum Master support group to share knowledge and ideas.

These efforts have not only helped me become a better Scrum Master but have also had a positive impact on my personal and professional life, enabling me to lead with greater confidence, empathy, and effectiveness.

This blog was originally published by me on Medium, in SeriousScrum Publication: https://medium.com/serious-scrum/confession-of-a-scrum-master-6bd4e82a923b