My learnings as a part-time scrum master

I experienced the pretty fast growth of a company I worked for, in which scrum is used as the development process. When companies grow, teams get bigger or new teams form.

In my particular case the company used to have one scrum master - let's call him Jim - that dealt with all the engineering teams. This worked fine up to the point where new teams were founded with newly hired engineers. One scrum master could not handle the amount of teams anymore. However, hiring new scrum masters took time and as an interim solution one engineer of each team took over the scrum master duties for his or her team.

I was one of them. Already before I read discussions about how much time it takes a scrum master to organize meetings and doing other stuff that scrum master usually do and if it is justifiable to have a full-time scrum master for a team. Having gone through this time of being a part-time scrum master myself I can now say that, yes, it is justifiable. I would like to use this article to explain why.

Being overwhelmed

While working in my new role as a scrum master my colleagues and I got help and regular, short retrospectives with Jim. This was really helpful in the beginning where a lot of questions popped up. The opinion of an experienced scrum master was often times a relieve.

Nevertheless, I felt overwhelmed. Starting is always the hardest part, sure. The first change I felt was that I had to split my time. Officially, we got roughly 30 percent of our time as engineers for our scrum master duty.

Splitting yourself up

The problem I see with this approach is that it is harder to focus on one role. In my opinion it is easier to concentrate on your main role. Most of the time I started thinking about my scrum master tasks when they popped up, for example during stand ups.

However, a major task of a scrum master is to observe the happenings from the outside. Recognizing problems that are not immediately visible to the team members, as they are too absorbed with their technical issues, is an integral part of the scrum master role. This was very difficult for me as on the one hand I was part of the engineers thinking very hard about my technical issues and on the other hand had to take a step back, trying to be objective.

It took me some time to get into a rhythm of preparing, organizing and following up on team meetings. Those things got easier the more I dealt with them as the work was not scattered over the week. What kept being hard were the things that the scrum master has to do continuously like observing, coaching, handling impediments, etc.

The support of your team

If you do not have your full attention devoted to your scrum master role a very helpful fact is the support of your team. I was fortunate to be in a rather small team with people that had prior experiences doing scrum and also the motivation to work this way.

I saw colleagues struggling with their bigger teams. A bigger team naturally comes with more opinions, discussions and compromises. All of which have to be dealt with by the scrum master. I also saw colleagues struggle with their teams of less experienced members. This also puts a higher load on the scrum master as she is supposed to explain and coach those team members.

All of this is not easy. It is, however, even harder if you only have limited time to deal with those tasks. And it certainly restricts what you are able to achieve as the scrum master.

Learning from others

What helped me a lot were the regular meetings with all the other part-time scrum masters. We used those meetings to learn from our experiences, to support each other and to come up with solutions. It was like a retrospective just for us scrum masters.

Additionally, we used this time to see how the others worked in practice. For example, once we walked around the office and took a look at the other teams' boards. Everybody got time to explain the board setup, the others asked questions and compared it to their board.

Sum it up

I think that the experience of being a part-time scrum master was very valuable for me. Certainly, it made my work as an engineer more complex. But I am also grateful that I was able to invest some time in improving the teams collaboration and to understand team dynamics. It was a different kind of problem solving that I was used to until then.

Certainly harder was to think about alternatives of how I do things. The restricted time that I could invest in my scrum master role made it difficult for me to think about alternatives for, e.g., making retrospectives more interesting or introducing tools that could help the team.

Post image taken by me published under CC BY-SA 4.0.