Learning to be a ScrumMaster
BLOG

Learning to be a ScrumMaster

author By admin Feb 7, 2015
learning-be-scrummaster
Submit guest post

Though I had a fair knowledge of Scrum, I never had an opportunity to practice it before and never felt the heat of being a Scrum team member. But recently, I got a chance to work as a Scrum Master for a team in Srijan’s Goa office.

When I joined the Goa office, Avienaash (our Agile coach) gave me three books on Scrum to read in my spare time. I read the one that looked the thinnest and started practicing it. Srijan already has mature Scrum and Agile practices, all thanks to Avienaash. Hence, it was easy for me to get started.

I had two challenges in front of me, even before I took the role of ScrumMaster (SM). One of not having practised Scrum before, and another that I did not have a technical background. As I come from an entrepreneurial background, I did have the advantage of understanding the market and product easily. Getting into the shoes of the customer has always been very easy for me, but as a Scrum Master my role demanded me to do more.

According to Mike Cohn: 

“Many who are new to the Scrum Master role struggle with the apparent contradiction of the Scrum Master as both a servant-leader to the team and also someone with no authority. The seeming contradiction disappears when we realize that although the Scrum Master has no authority over Scrum team members, the Scrum Master does have authority over the process.”

Different people can have different sets of challenges as per their ability and mindset. I came across the following challenges:

  • Fear of not knowing something, which could be obvious to the team- The only way to deal with this situation is to read as much as you can. As an SM, I should have complete knowledge of Scrum, so I started with reading a book written by Mike Cohn called Succeeding with Agile, and it gave me enormous confidence. Trust me, when you practice along with reading, it becomes easier to connect the dots and the learning curve becomes shorter. Technical jargon are still a problem for me, but I do try to go back and read about that.

  • Understanding Impediments - This has been a problem for me especially in the case of technical bottlenecks, because I don’t have a tech background. As an SM, I should know the impediments, but it is even more important to understand how to find the right solution. There may be a chance that team members have not given enough thought to other consequences. So, asking questions is an important aspect of being an SM to help the team understand the real problem.

  • When to seek help outside - The ‘never give up’ attitude of team is good, but it can be a hindrance when strict timelines of the project is also a factor of success. At some point of time, external help becomes unavoidable, but to take that call is not easy. External help can dismantle the team morale because when team solves a problem by themselves, they get a sense of achievement. A good team tends to get closer to each other at the time of crises. So trusting your team’s ability is important here, and let the team decide when they need help.
  • Having an effective daily standup - Daily Scrum meetings at start of the day is important as they bring discipline into the team and sets the tone for the day. Some usual problems are:

    • Coming late
    • Connecting with distributed team members

    • Low energy levels
    • Not attentively listening to others updates
    • Team tends to face the SM while giving the update instead of the team

The essence of a daily standup is not just to give an update to the SM, but to sync up with each other on how we are doing as a team. As a Scrum Master I play the role of a moderator in this daily standup meeting. Most of the above mentioned problems got resolved by consistently bringing them up in our retrospection meeting.

  • Sharing my update in a daily standup meeting in the format of “What I did yesterday” & “What will I do today” - I work on multiple things throughout the day. But to filter out what is relevant and valuable in the daily stand up is tricky. Committing a task for the day in the daily standup has not been as easy for me as compared to my fellow team members. They can see the sprint backlog to choose a task, but for me as a SM, I have to go with the flow, as per situation demands.

In Scrum, everyday unfolds something new, hence identifying tasks and prioritising them is quite challenging. I am not convinced that a SM should give the updates in the same format as the team does, since SM has a completely different role. However, a SM must give the update on the impediments identified on the previous day, change requests, budget, new developments, product backlog, status of sprint planning, UAT, etc.

  • Writing user stories on behalf of PO, who is far away - Acting as proxy PO is not easy, because the team expects SM to have 100 percent clarity on user stories. It requires intensive thinking to ask all the probable questions to a PO before the implementation starts. I could manage this problem by setting up the team’s expectations in beginning of the sprint by telling that 20 percent ambiguity in stories are recommended to make them negotiable at the time of implementation.

You can also gain clarity by discussing with the team while writing stories and involving the QA in writing acceptance criteria. Doing the story estimation exercise with the team also helps, and the team gets an idea of the backlog in advance. The point that needs to be understood by the team is that discussion is valued over the excessive documentation (detailed story) in Scrum.

  • Engaging the designer - Designers always work one sprint ahead of the team, hence it is important to plan the dependencies early. Sometime you don’t realise which user story will trigger a change in the UX, so it is important to evaluate every task from a designer’s perspective. Cohesion between development team and designer is also very important.
  • Focussing on my work and keeping an eye on how we are doing as a team - This becomes even more difficult when team members are not co-located and working across different time zones. To deal with this, I created a checklist for myself. This helped me to keep an eye on every aspect. Later, I found Scrum Master’s checklist which is very useful to evaluate myself on how I am doing as a SM.
  • Estimation vs committing - Whenever we could not finish all the committed stories in a particular sprint, we would blame estimation. However, it was not always the reason because estimation and commitment of stories in a sprint are different things. So, while committing to stories, the following things are important to be considered:
  • Actual productivity fluctuates due to external factors, hence 70 percent is the maximum output we should expect, not 100 percent
  • A good mix of tasks between developers and QA, which depends upon the ratio of developers and QA in a team
  • Considering offs and holidays, because sometimes we tend to forget this while planning for sprint
  • Nature of Stories/Task and dependencies
  • Frequency of Deployment/Release/UAT

  • Better Sprint Planning - It becomes cumbersome when you try to do it at the last moment. So, planning two sprints in advance is important because it takes some time to get clarity on the stories. For example, some user stories require POC to be performed even before estimation, hence it is required to pick that POC at least one sprint before. Understanding such dependencies is key for a smooth implementation. It is important to involve the team to do the backlog estimation from time to time. I kept 10 percent of my team’s time in each sprint to plan for the next sprint. This helped the team to deal with last minute surprises. Consistent grooming of product backlog is key for better sprint planning.

  • Effective Retrospection - To do an effective retrospection, it is important to understand what we want to achieve as a team, and what needs to be done to achieve that. For example ask yourself, "How are we doing on XP practices?" "How can the team be more productive?" etc. My contribution in the retrospection meeting got drastically improved when I learned how an ideal agile team should be working.

My constant endeavour of finding the root cause of every problem has helped me to come out of most of the problems. I would retrospect my performance almost every day. It kept me on my toes to improve. I think when you know the exact problem statement then solution comes easily. Avie has played a great role by providing constant feedback to me on where I lag. I am still learning and trying to improve myself.

Discussion

Write to us

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms Of Service apply. By submitting this form, you agree to our Privacy Policy.

See how our uniquely collaborative work style, can help you redesign your business.

Contact us