Why Are We Creating Scrum Masters From Developers
It is not about the person it is about the team.
Spoilers; this post will not be about the Scrum Master's responsibilities or the definition of Scrum Master.
I will share my experiences as a Scrum Master and Developer for a scrum team. Also, I will share how we are doing this at Insider with lots of different teams.
At Insider we are choosing Scrum Master from one of our team members and there is constant circulation. Generally, the Scrum Master changes after some time to a new person. We believe that if the team is autonomous enough everyone can be a Scrum Master.
We are not giving someone the role of Scrum Master for just improving the team, we are doing it to improve the person who was selected as a Scrum Master. The reason is that the person should evolve to be a better Scrum Master for the team and herself or himself. So becoming a Scrum Master is not a reward or does not show that you are the best for the team. It is an opportunity to improve.
We don’t want Scrum Masters to act like heroes or shepherds. We are aiming to make every team member self-sufficient for her/his work. So, if a person can resolve a problem without supervising or can find the right person for the problem, this means for the next step this person can make the same things for the other teammates.
Also, I want to take look at that from a different standpoint, from a development standpoint. Let’s think of a team that has a great Scrum Master? who can remove all obstacles and fix all problems at ease. And other team members are used to working with this person and are dependent on their Scrum Master. What will happen if this Scrum Master wants to retire or decide to work somewhere else or is hit by a bus? Will this team’s deliveries get affected by this situation? Probably yes. I think nobody wants this to happen. It is similar to a single point of failure. To create reliable systems or teams we should try to avoid these situations.
So we are trying to avoid this by creating diverse teams with any person of the team who can take the responsibility of the Scrum Master.
But it is not always an easy task. As I said at the beginning? the main requirement is creating autonomous teams. To achieve this? we are trying to compose teams with different characteristics and we are trying to distribute responsibilities inside the team. For example, we are not giving the Scrum Master role to the most experienced person in the team or we are not putting the most technically capable people in one super team.
My journey has similarities with the general Scrum Master lifecycle at Insider. I am working with my current team for more than a year and I was the Scrum Master of my team for 10 months. I am saying ‘was’ because my watch as a Scrum Master has ended for now.
When I just joined the team, I was so dependent on the other team members and I didn’t know the dynamics of the team. But over the time I got used to the team. First? I started to resolve my impediments on my own and after that, I start to contribute to my team better.
After I became self-sufficient enough, I realized that I am also helping the team in moving obstacles and deliver more reliably. After a couple of months, a suggestion came from the previous Scrum Master to make me the Scrum Master of the team. The goal was to distribute responsibilities more evenly and make team members grow, as I mentioned above. I happily accepted this and saw this is a chance which leads me to know how successfully a team works.
At first, I was a little bit anxious about extra responsibilities and I was thinking there might extra load for me. Since I was still making development, I thought it may interrupt me. But after a couple of weeks, I noticed that if the team goes well, I would not need to do anything except some small extra responsibilities. When everybody makes their parts there was no need for me.
The real struggle starts when somebody or something fails. But even at that time, there were no unresolvable problems. The key was well-distributed team structure and responsibilities. The main thing for those times for me was only a follow up or to direct people to the right person. If there are no destructive people in your team or organization, these two things will always solve problems or improve processes.
If somebody does fail on a technical matter, I was noticing by following up and if the person doesn’t know whom to ask or holding himself/herself back from asking, I was just pushing to start communication with the correct person. If there is a dependency/problems with outer things or other teams, my job was finding a key person.
Through time, I notice that 99% of the problems occurred were about the lack of communication. So I was just pushing people to remove their impediments instead of doing it by myself, because, sometimes, 5 minutes of conversation can resolve more things than a whole night of self-working.
For example, there is a waiting dependency from another team and one of the team members has a thing to develop about this dependency. Let’s imagine your team member complains about this dependency and asks you to talk with them about this.The first option is to talk with the Scrum Master of that team to ask about that dependency, get the answer to talk back to your teammate. If there are still unresolved things, do the same things again. I am never okay with this solution, because there is no need to add an extra people layer to the communication. Also, this solution will create a Scrum Master dependent team members. At first, this may look better because the team member’s problem was solved by his/her Scrum Master directly. But in the long run, I see no benefit from this approach.
The second option is to ask that team member to create a group chat with the dependency owner, the Scrum Master of the team and with me, ask in publicly from there. This may seem favorable to the teammate, but when a similar problem appears again, she/he will not need another person to solve the problem. This may create more self-sufficient teammates and future Scrum Masters for the team.
Also, there is one extra perk to be a Scrum Master as a developer. If somebody faces some challenge, he/she talks with the Scrum Master who works side-by-side and faces similar problems. It is always helpful because when somebody faces a problem, I can quickly relate that problem and this is very helpful for understanding and solving.
At last, we decided to change the Scrum Master again because I was developing my responsibilities as a developer as well. So we think that we can give Scrum Master responsibilities to a newer person. We re-distributed the responsibilities within the team, which s also good for another person in terms of trying to fit into the Scrum Master role by gaining extra responsibilities.
In conclusion, at Insider we are trying to create different and new Scrum Masters around the teams. When a Scrum Master hands over his responsibilities to another person, the team gains a fully self-sufficient member and a Scrum Master who can grow to be a better contributor. With this circulation, we are trying to create more autonomous teams, more self-sufficient people who can take Scrum Master responsibilities easily.
Want to be a part of dream team? Check out our career page!
