Having a good understanding of a job’s definition is essential for good execution. This is especially true for the role of the scrum master in the scrum framework. The scrum master has a special role in the scrum team and thus it is a very interesting and challenging one. Although scrum defines the role of the scrum master, it still leaves many questions open about that mystery role.

1 Different Scrum Master Styles

Out of experience, and also from discussions that we had with other scrum team members, we found out that many teams understand the role of the scrum master in several different ways. Interestingly enough, some understandings are even in contradiction with each other, especially when it comes to the question about who is the leader of the team. There even might not be a leader of the team at all. In the following sections I will introduce three scrum master styles.

1.1 Facilitator

As a facilitator, the scrum master helps the team to make decisions and ensures team communication. The SM should be a mirror to the team. This means that the scrum master will point out problems, but not solve them. This is the task of the whole team. The scrum master neither makes decisions nor dominates team communication. However, the scrum master is allowed to step up, after the team asked them to take action.

The scrum master is not the leader of the team, hence in the same position like the other team members. The tasks of the scrum master include to remove any impediments from the team, making sure that the team can focus on development and on delivering the product. The scrum master should teach scrum to the scrum team, making sure all involved persons are understanding the rules.

1.2 Manager

In some teams the scrum master is also the manager of the team members. This can lead to several difficulties. The scrum master will probably dominate the team in both communication and making decisions. No matter whether being dominant on purpose or just by being the manager, it might cause the team members to feel less and less responsible for the whole project. The manager then would have command and control. However, this is in contradiction to the team-centric scrum philosophy.

1.3 Servant Leader

Instead of being a controlling person, the scrum master is a servant leader to the team. In this role, the SM leads the team, but in a different way than a manager. Servant leadership is about being patient, respectful and selfless towards team members. A servant leader would point out things that are not working, without taking responsibility away from the team. Furthermore, a servant leader stays in the background and supports team communication and team decisions.

As a team lead in this definition, the scrum master ensures proper programming standards and also helps the product owner to prioritize the backlog. Other than this, the scrum master should be a facilitator here as well, like described above.

2 Behaviour during Meetings

It is part of the scrum master’s role to schedule team meetings, as well as to open and to close them. Both team and scrum master can easily misunderstand this, because in typical cases the scheduler of the meeting is also the “owner” of the meeting. However, this is different for team meetings in scrum.

During team meetings, the team is the owner of the meeting. The team will discuss, make decisions and come to solutions. The scrum master just helps the team to schedule the meeting, make required preparations and so on. But that role should not be understood as the owner of the meeting.

Of course, the scrum master should participate in discussions during these meeting. That person belongs to the team as well, like all other team members. But the SM should make it clear that the role in the meeting is a team member, not a leader.

We encourage our scrum masters to stay vocally in the background to avoid dominating the meeting. The other team members should be encouraged to discuss and decide, and should also understand the idea of the scrum master being a facilitator, not as the one who decides on problems. In case several solutions exist for a certain problem, we encourage the team to vote for their favourite solution.

3 Conclusions

The opinions about what a scrum master should be and should not be are very different. The manager position and the facilitator position do not have anything in common, whereas the servant leader is a role in between.

Scrum is all about the team. The team makes decisions about solutions and is in charge for implementing them. This makes each team member aware of the product and responsible for the whole team’s delivery (and not only the part a team member was working on).

With too much domination, the scrum master can easily prevent the team from working as a team. A scrum master should keep in mind that the task is to help the team to implement the backlog, and not to dominate the team.

In scrum, the scrum master is an essential role. A scrum team that does not have a scrum master should better call itself a team working together on one project, rather than a scrum team. The role of the scrum master is clear, but how would you decide about who is going to be the scrum master in a team? What would be the best way according to scrum?

Recently in one of our teams we were looking for a new scrum master. There were basically two options.

Let the manager decide

When we started with scrum in our company more than two years ago, the team’s manager made the final decision about who is going to be the scrum master in the team. This is a clear decision, and the manager would have the possibility to install a scrum master whom he knows and whom he trusts.

No, let the team decide

But, wait, what does the scrum master have to do with the manager? The scrum master is a team member and is fully dedicated to the team, the scrum master serves the team.

That’s why we were thinking of letting the team members decide who will become the team’s new scrum master, rather than keeping them outside of the loop. This has several advantages:

• The team acts as a team
• Team members concentrate on team decisions
• Team members learn to self-manage themselves
• Team members understand that their voices are important

Since the team members are actively involved in the decision, it is more likely that they accept the result than if somebody from outside of the team appoints the scrum master.

Having a vote

After listening to the two different options, the team eventually decided to go with the second option. We scheduled a meeting for the election and we even prepared ballot papers with the names of the team members listed. Before the vote, we discussed again about the tasks and duties of “the perfect” scrum master and we also agreed that the new scrum master should prove themselves during a probation time of five sprints (almost four months in our case).

During the vote, each team member had one main vote and one second vote. The second vote would have helped us in case two or more team members received the same number of main votes. The election was held anonymously (which is very easy to achieve with a room big enough). We counted the votes for each team member and finally had a new scrum master for one of our teams.

Conclusion

I am satisfied with the process of our election and how the team discussed this matter. Luckily, the team was already very experienced and also had several good candidates for the new scrum master.

Concluding, I have to say that although it is not a big deal to have an election for the scrum master, I also did not find any sources that described this as a common practice. I was curious to try that out and fortunately the team was open for this opportunity and very curious, too.

For one of our web sites we programmed a server that provides us with information about the whole friendship network on this site: Who is friends with who, six degrees of separation information, etc. Back in 2007, we wrote that server in C and since we started using it, it was running with absolute reliability.

Suddenly it stopped working, without any prior warning. It did not crash, the process was still alive. It just did not response to any requests that we sent to it. All requests timed out. And even worse, there was no helpful log information that pointed us to any specific direction we could look for the error.

Check list

The good thing was, since we programmed the server, we already had several points to think about first. On top of a C programmer’s check list is the segmentation fault, that happens when trying to access a memory area that the process does not own. But we could almost exclude this point, since the server would have logged any segmentation fault it did. This point got crossed out.

This left a second point on our check list: Blocking. Our server creates worker threads that deal with each client’s requests. For responding to the requests, all threads are sharing the same information about the friendship network, or, in a mathematical term, the graph. Here we are using mutexes in order to keep the information consistent (by preventing to have more than one writing operation at a time or to have a read request while there was some data written).

Mutual exclusion? Dining philosophers? Race condition? Deadlock?

Continue reading →