How to be a good Scrum Master?
Whether you have been practicing Scrum for some time now or are still a beginner, it is very important for every Scrum Master to question frequently, how much do I actually understand about the role and how confident am I in owning the responsibilities.
In this article, I will not talk about what is written in the Scrum Guide. I will focus mostly on what is not written in it and left for us to realize, explore and learn.
I’ve witnessed Scrum Teams who are ignorant of the details. In one case the Sprint Retrospective was held before the Sprint Review. In another case, the Daily Scrum took way longer than its 15-minute timebox.
However, in the real world, every minor issue later becomes a norm. This in turn leads the team to believe what is being practiced is in the right direction, eventually becoming very reluctant to change.
I would like to illustrate with my real-life experiences (when I was a developer) which changed my perspective about Agile Methodologies, Scrum Framework and the transformation that a Scrum Master role can bring to the team / organization.
Note: We did not have a dedicated Scrum Master and we implemented a custom version of Scrum. (Taking only a few Scrum events and also having the events on demand)
1. Skipping Daily Scrum thinking they are not beneficial.
Daily Scrum is the key inspect and adapt meeting, here the Developers (earlier referred to as the Development Team) collaborate, inspect the progress towards the Sprint Goal, identify any impediments.
Not having them every day can have serious impacts as below:
Everyone met their goal individually but the increment failed.
It is very common that everyone understands their individual goals but fails to see a bigger picture.
It happened once that we were building a complicated module, the initial design was drafted and everyone agreed and the implementation began.
However, the team members later did some modification in their modules assuming it will fit into existing design and at the point of integrating, it just did not work.
Impact: We had to spend few days discussing within the team on how to proceed, did a post-analysis of the situation making the necessary design changes, it was kind of a Task Force mode where everyone had an eye on delivery, we had to stretch to ensure that we complete everything on time.
Only if we had daily scrum, it would have brought the entire team together every day, providing an opportunity to discuss together the changes, discover better ways of implementing, and finally saving the time and effort of the entire team.
If we had the Daily Scrum, we would know the changes daily, adaptations could have been done early and every day team’s confidence on how the progress towards Sprint Goal could be measured.
Finally saving us a lot of time and also boosting our confidence in achieving Sprint Goal.
2. Not having the Retrospective Meeting
We were having our own version of doing the Sprint Retrospective meeting.
Back then every individual used to keep a track of the impediments he / she used to encounter, identify the person who can help resolve the impediment and follow up on them.
Outcomes :
a. Few impediments were short-lived and were solved immediately — Eg: Delay in software or hardware procurement.
b. Few impediments required to reach different levels of people, getting approvals from different levels and individuals had to spend a lot of time and eventually gets solved. Eg: Working on innovation topics
c. Due to other important priorities, the person leaves the impediment as it is. The impediment later hitting us hard later and the team rather than owning every impediment feels individuals responsible for the respective impediment.
Impact :
1. No one in the team has a clear picture of the number of open impediments.
2. Everyone lacked a vision of the impact of the impediments blocking the opportunity to come together as a team and discuss the approach, priority, and what is beneficial for the team.
3. Less owning culture and It is no one’s responsibility: Other than few proactive members, most of the team members were of the opinion, it is individuals responsible for identifying and following up on the impediment and failed to understand it is the teamwork.
4. It is left to the team when to come together, spend time in identifying the current impediments, any process improvements we need which rarely happened.
In all the above situations :
1. The team was not having a dedicated Scrum Master to guide and coach them in implementing Scrum. We derived our own version of Scrum.
2. The team was of the opinion, meetings are a waste of time and the time spent on development or testing activities are the only productive time.
3. Finally, when we were asked about implementing Scrum, we were of the opinion that we miserable failed trying to partially implement Scrum and implementing it completely would even worsen the situation. (Reason was we only saw a lot of Scrum Events and for us adding a bunch of meetings was losing productivity. However, not understanding its benefits)
Later, when the organization moved towards complete Agile transformation, when we got a dedicated Scrum Master, it changed everything.
We understood the importance of the role, the Scrum framework and its actual benefits.
I personally got the motivation to be a Scrum Master and help teams get the same benefit. This was a change in mindset and what we thought about Scrum and being Agile.
Characteristics that have personally helped me become a better Scrum Master :
- Lead by Example.
Living what we preach is the key. Eg: You can’t attend meetings late and expect everyone to join 5 minutes early.
Present yourself well, show how to be disciplined, how to follow the process and you shall see the difference. - Return on Investment
Only when you invest your time in your role, in your team, in individual team members, you will better connect and understand the needs and the problems of the team. Establish a channel of trust and eventually try gaining the confidence of the team.
This way people will be more open to seek help or suggestion and better connect. - Innovation vs sticking to the Scrum Guide
Implementing Scrum as mentioned in the Scrum Guide isn’t enough.
Eg: The Scrum Master should ensure Sprint Retrospective meetings are positive and productive. However, practically it's not as simple as saying it.
The Scrum Master should understand the team and bring in innovative ways of making the meeting interactive, interesting. Say Fun Retrospective !!! - Communication
I sometimes find it difficult to share my opinion in the right way. When any deviation is identified, which can become a potential threat, the Scrum Master should not hesitate to correct the team. The team will be willing to adapt if they see the benefits of the proposal.
Emotional intelligence is another key factor that the Scrum Master should practice which will help in this aspect.
Eg: I was facing it hard to keep the meetings within the timebox and allowed discussion in the same window
Only advantage :
No additional meeting required as most of the teammates are available.
Disadvantages :
1. People are not well prepared for the discussion as this is unplanned.
2. Few people had to drop off as they had other meetings or commitments
3. People had to go through recording and had no opportunity to ask the right questions or add any valuable points which could have been very important information.
However, when I spoke about this in Community of Practice, consulted other Scrum Masters in workshops, I got great advice.
1. Keep the agenda of the meeting very clear so that the team knows what to bring in and what not to.
2. Re-emphasis the importance of everyone’s time in the meeting and help the team self-manage to identify the required discussions, book the meetings in advance.
Apply: I adapted these learnings and ensured to specify the agenda in every meeting invite rather than assuming.
I boldly interrupted when I saw someone is trying to bring in a different topic and helped the team arrange a new meeting specific to the topic. Even though finding a timeslot and blocking everyone’s calendar was challenging at times, the entire team understood the benefit of the approach and has been since supporting me.
Learning: We can only make the best out of a meeting, when people are prepared before they arrive, attendees know the agenda of the meeting and have the time to spend un-interrupted. - Constant Feedback
There are often hidden impediments that required continuous attending like driving a car on an unknown hill. It is very important for a Scrum Master to identify them by paying close attention or the damage cannot be undone.
In a less mature team, individuals will hesitate to open up in the Scrum Events and would require an anonymous or one-on-one platform to bring it to the Scrum Master's notice. Thus, I recommend that Scrum Masters can initially try alternate techniques and get a better understand individual’s perspectives.
(Few techniques I used: freesuggestionbox.com, Mentimeter survey, quarterly 03s)
However, eventually the goal should be to lead by example and help the teams be braver to express their opinions and not promote alternate techniques.
Scrum Master should coach the team in making them understand the developer’s responsibilities, to be self-managed and address any internal conflicts as a team. - Continuous Learning :
To bring in more value and better practices, continuous learning is very essential and I recommend :
a. Working with other Scrum Masters
b. Participate in Community of Practice.
c. Participate in training associated with Scrum, Agile and project management.
d. Reading books that provide practical insights (One of my favorite: No Hard Feelings by Liz Fosslien and Mollie West Duffy) - Being Valued :
Even if you have a complete understanding of Scrum and Agile practices, if you cannot remove the team’s impediments, if you cannot inspire, if you cannot serve the Scrum Team, then its highly unlikely that the team will respect you or your certifications.
Identify the opportunities to improvise, provide constant feedback and follow up on your team’s happiness index to keep them productive, engaged and happy.
This helps the team realize the benefit of having a Scrum Master.
Conclusion :
To be a good Scrum Master, it takes a lot of effort and dedication. To connect with the team and solve the Developer’s issues, we need to expand our horizon and try to understand all the associated aspects (people, domain, technical).
Eg: A developer being a Scrum Master may understand the technical challenges better, a Quality Analyst as a Scrum Master will better know the quality-related aspects, and so on.
However, a Scrum Master can only be successful in his/her role, when they are satisfied with what they are doing and when the team and the organization recognizes them and values having them.
EndNote
This is my first post and with my little knowledge that I have collected through my journey, I have put forward a few aspects which I have learned and benefited from.
I hope the above information helps all the readers. However, there is a lot more to learn, a lot more to improve. Thus, I request everyone to please provide your comments and valuable feedback so that I can continue writing similar content.
Keep learning, keep exploring, keep sharing and Never give up !!!
