The evolution of my tasks as a Scrum Master
What tasks to expect when you are a Scrum Master? What your first days and later your day-to-day work may look like? These are the questions I try to answer with this article. I hope my personal experience will be useful for early-career Scrum Masters.
I am happy to belong to that younger generation of female Scrum Masters, which is catching up, according to the recent report. Being a Scrum Master can be rewarding, but at the same, don’t forget that no two teams and products are the same and the behavior and tasks of a Scrum Master are very contextual. For me, becoming a Scrum Master has been one of the best career decisions.
Instead of copying the passages about the Scrum Master’s duties from the Scrum Guide (you might already know them), I will describe how my life as a Scrum Master has been so far. I will divide my Scrum Master’s work (which is a bit over six months) into three subsequent time periods, to better describe the evolution of my tasks:
· The first two weeks
· After the “first two weeks”
· After several Sprints
During the first two weeks…
I joined my team mid-flight, during their 8th sprint. I needed to gain their trust, which may not always be an easy job, especially within a team with established practices. Thanks to some research, I planned my “gaining their trust”.
Here is what my tactic looked like:
- The very first (few) weeks were about observing my team, while attending their Scrum events and joining the team for their lunches. I would go with the team for lunch, to get to know them outside the work environment.
- I tried to form a good relationship with the Product Owner by having several 1:1 conversations. For me, a good partnership and collaboration between a Scrum Master and a Product Owner is valuable for the Development Team.
- I learned about the engineering practices and tools used by my team, about their Definition of Done and what does it take to get to “Done” state.
- After nearly 2 weeks, many Scrum events and lunches with the team, I learned and understood where I as a Scrum Master could contribute and bring my expertise to the team. By this point, the team got to know me, and I was confident enough to recommend some changes in their Scrum processes.
Please, don’t just push your team with the passages from the Scrum Guide, telling them: “because the Scrum Guide says so, we must do like this and that”.
This might demotivate and negatively affect established positive atmosphere in team. Again, depending on the circumstances and timing, I offered changes in a gradual, gentle way and in various forms (posters on the walls in German, entries in our Scrum chat, handouts). Don’t forget to mention that colleagues just need to give a try to those new practices and also explain how these changes might be beneficial to them.
It is a good sign when the team becomes receptive to your ideas, as it might mean: “welcome to the team as a Scrum Master”. Someday, the relationship will become reciprocal: you introduce your ideas with caution and the team starts believing in your competencies.
After “the first two weeks” …
After my peaceful on-boarding and after the introduction of some changes to our Scrum practices, my day-to-day tasks became kind of the standard list of “To Dos” for each week. This phase was a bit more stabilized compared to the first phase, as the introduced ideas have been accepted and established and I, as a Scrum Master could enjoy the new “flow” in their collaboration. Though, the need for minor changes and adaptations comes after each iteration -this is what Scrum is about. So, my tasks in the second phase were the following:
1. Coaching _ I continued observing our everyday Scrum practices; when needed I did issue-specific research and provided additional coaching materials in various forms. To note, this activity is highly context dependent. Keep in mind, developers are too busy to read long texts. My tip is to keep your text short, but clear and when possible, add some visualization. In this case, some Scrum memes can be helpful, and funny. (P.S. fun factor and a sense of humor are important in a Scrum Master’s job).
(e.g. this meme can be used for a friendly reminder for the team about the three “holy” questions of the Daily Scrum, in case they only answer the “what I did since our last Daily Scrum” question).
2. Staying fit _ What I mean by staying fit as a Scrum Master? Sometimes I need new ideas and learn from the experiences of others to try things out and keep my team’s collaboration in the “flow”, so I took some time to learn from newsletters and blogs. Please embrace the fact that your training as a Scrum Master continues in your day-to-day work, as you may not know everything (and who does?).
3. Facilitating Scrum Events _ this is one of the main working areas for Scrum Masters and I did the following tasks:
a. Daily Scrum _ for Daily Scrum we used a white board. Before this event every morning, I updated the board, which means that if new sub tasks have been created in the online project management tool, I wrote the tickets on special magnet cards and placed them on the “to-do” column on our physical board. During the Daily Scrum, team could relocate the cards according to their current states.
Actually, no Scrum Guide states that Scrum Master must attend Daily Scrum, but I did regularly at the beginning — to get acquainted with team members, and I do so now. This is to enhance my understanding of the technical and non-technical context my team works in.
b. Sprint Planning _ before the Sprint Planning event, I prepared the capacity table, so that the team could fill in availability (number of days) for the upcoming Sprint. I also gathered information on what had been achieved during the previous three Sprints with similar capacities. These data are important for the team during the Sprint Planning to decide how much work they can take up in the coming Sprint.
c. Sprint Review _ for the Sprint Review, I made sure that the calendar appointments were sent, so that nobody missed the meeting. When necessary, I re-invited stakeholders for the appointment via the calendar feature.
d. Sprint Retrospective _ among the Scrum events, I spent most of the prep time on Sprint Retrospective. Usually, during the Retrospective, three main dimensions are analyzed: “what went well”, “what went wrong” and “actions for improvements”. I tried applying different Retrospective format to every meeting, e.g. with regard to team’s emotional health, I asked what made the team glad, sad and mad during the last Sprint. The site is one of the sources, where I get an inspiration from.
Depending on the Sprint goal and the mood in the team, a) I prepared the template with corresponding questions on the flip chart, b) made sure enough office supplies were provided and c) provided some munchies for cozy atmosphere. Like Daily Scrum, we conducted “analogous” Sprint Retrospective, where team members wrote their answers on the “Post Its” and placed them on the board.
During the Retrospective you as a Scrum Master may also conduct some small assessments, like the level of adoption of Scrum values in your team. (You may find one here). I also use Retrospective meeting to update status of the board of “possible improvements” which we gather in every Retrospective.
4. Observing _ I also spent some time observing people interactions (not only during our Scrum events) to “hear any unspoken words” or to recognize any conflict at an early stage. Keep in mind, especially early in your career, you as a Scrum Master might not bring a “box of tools” for every possible situation. But I think my personally tested approach may help you here. This approach has two components: the first one is knowing the power of “not talking, but listening” and the second one is remembering one system rule from the Zuzana’s presentation:
Besides, some conflicts are healthy, and those constructive disagreements may be used to find even better practices for your Scrum team.
5. Impediments _ I spent the least of my time on removing impediments, because the team is self-organized. If they cannot “remove the impediment” alone, they can refer to me, but this does not happen often.
6. Servant Leader _ I spent no time on report preparation or gathering metrics for the leadership. I do not do typical project manager’s chores; I am a Servant Leader and focus on the needs of the team; I facilitate their collaboration and as a coach, I ensure that the team supports the chosen Scrum framework and understands the value of every Scrum event.
After several sprints with team …
In this phase, the intensity of my duties has been reduced slightly, and I no longer need to work as a full-time Scrum Master. Actually, this is not a bad sign at all. Rather, this means that the team is self-organized, they take the ownership of their processes and the team functions well; now, they have space to grow. This does not mean though that I no longer fulfill the tasks I mentioned above, like coaching and facilitating. But it feels like less intense intervention is necessary. I may do less, but it does not mean that I do less, and I do not care. I carefully observe the team. I have the faith in their self-organization. I am still there, for the team, as a Servant Leader.
Conclusion
Remember there is no prescriptive template of a Scrum Master. The Scrum Master has different stances and you can apply them as your team(s) and projects evolve. And while trying to optimize the processes, don’t forget to have fun with your team.
Do you want to write for Serious Scrum or seriously discuss Scrum?
