The Scrum framework has 3 roles:

   * Product Owner (PO),

   * Scrum Master (SM) e

   * Development Team

In a few words the responsabilities of each roles are:

   * The Product Owner is responsable for the macro menagement of the product – this means that he is worried , about the product status, "what shoud be done".

   * The Development Team is responsable for the micro management of the product – this means that they are worried with the status of the tasks to get the job done, "how to do it".

   * The Scrum Master is responsable for ensuring Scrum is understood and enacted.

As each role has specific responsibilities, it is highly recommended that there is no accumulation of roles by members in Scrum Team. However, the reality in many projects does not allow such a clear division of roles and accumulation ends up happening. So it's common to see Scrum teams, where:

1. The Scrum Master is also a member of the Development Team.

2. The Product Owner also collaborate in development in the role of the Development Team.

3. The Product Owner also is the Scrum Master or the other way around.

 

In this context, where it is recommended do not have accumulation of roles, the question that people much ask me in training and consulting I have done is: Why do not it´s recommended to accumulate roles? What are the problems implicit in the accumulation of roles?

I will list here some points where the "danger hides" and it´s important to take special attention and care not to injure agility.

Let us consider the first case of accumulation of roles:

 

The Scrum Master is also a Development Team Member.

 

1. Compromise Deliveries

Every time Scrum Master is requested to remove impediments he works less on the development of the product. Less hours of a team member on implementation of the sprint, maybe the delivery plann will be compromised.

 

2. High Variance in Team Velocity

 

With committed deliveries every sprint, the velocity of the team also varies, since it is calculated by the average of the story points given in the previous sprints.

The sustainable pace that is sought in agility is compromised. Schedules begin to fail too as deliveries are compromised.  

 

3. Estimates can be "fat"

As Development Team knows that the Scrum Master will have impediments along the sprint to solve, but do not know how to predict which and how much time it will take, maybe the Development Team ends up estimating the stories, including a "fat" to avoid "disappointment" of not delivering at the end of the sprint the commited.

 

4. Conflict of interesting  

The Scrum Master can hide to get work in some tasks that his not intresting in with the excuse that he is handling some imepediment. For history.

This situation can cause discontent in Team members and will not necessarily be well crafted in retrospect, as the Scrum Master can always excuse yourself that he was handling the case, that it´s part of the problem of accumulation roles and the Team will have to live with this.

 

5. Loose of agility

If the Scrum Master is so much involved in developing, he can care less for the process, and not coach the team in self-organizing.

 

6. Doubts in which role he will assume in retrospective´s meeting

A Scrum Master has to conduct a retrospective meeting in the role of a facilitator of this meeting. But if a Scrum Master is also a member of the Development Team, is he allowed to enumerate positive and negative points?

Maybe the retrospective meeting will not be so effective, as the Scrum Master will care less to act as a facilitator

 

These are some points to take care when accumulate roles in Scrum.