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.
Olá. Onde trabalho temos essa configuração de SM também ocupando o papel de desenvolvedor. Como a equipe é pequena, essa situação é inevitável.
Para tentarmos contornar esse inconveniente, atualmente temos utilizado de dois artifícios:
1. O SM é considerado no Sprint como “menos de um recurso”. Ou seja, ele é considerado, por exemplo, como 50%.
2. O SM não participa das atividades do Sprint. O seu tempo ocioso é aplicado a tarefas de fora do Sprint: correção de bugs, ações urgentes, desenvolvimento de tarefas já discutidas mas que não entraram para o Sprint, tarefas referentes a outros projetos, etc.
Assim, tendemos a minimizar os problemas citados no artigo.
Olá Bruno!
O objetivo desse post foi apenas apresentar os pontos que temos que nos cuidar quando tivermos acúmulo de papéis de Membro do Time sendo também Scrum Master, pois cada equipe dará sua solução em função do seu contexto. Sendo assim, foi muito legal a sua contribuição aqui no blog.
Essa é uma questão que sempre é abordada e que demanda muita discussão, e nada melhor que ouvir as soluções de cada equipe para formularmos a nossa. Mas para isso é sempre importante a contribuição de todos.
Parabéns pelo seu comentário, Gostei muito! Só devolvo para você uma pergunta (de curiosidade mesmo!):
O fato do Scrum Master (dentre várias responsabilidades extras que você citou) ficar responsável pela correção de bugs não cria um clima de menor responsabilidade na equipe de desenvolvimento quanto a quantidade de bugs que são deixados no produto entregue? Eles já sabem que é o Scrum Master que terá que resolvê-los! Como vocês lidam com isso?
Olá Ester e Bruno,
Muito bom o comentário de vocês!
Um comentário: na minha visão, a correção de bugs, tarefas de teste ou quaisquer outras tarefas relacionadas ao produto que o Time Scrum está executando, devem está listados no Backlog do Produto para também fazerem parte de uma Sprint. Assim o Time de Desenvolvimento tende a ficar mais comprometido com o produto que estão desenvolvendo, uma vez que a responsabilidade de fazer o produto (software codificado) fica apenas com eles.