O framework scrum possui apenas três papéis. São eles:
* Product Owner (PO),
* Scrum Master (SM) e
* Time (Equipe de Desenvolvimento)
Resumindo as responsabilidades de cada um desses papíes temos:
* O Product Owner é responsável pela macrogerência do produto – ou seja, ele se preocupa com o status do projeto, com "O que fazer".
* O Time é responsável pela microgerência do produto – ou seja, se preocupa com o status das tarefas, em "Como fazer".
* O Scrum Master é responsável pela gerência do processo – ou seja, se preocupa com o dia-a-dia de trabalho dentro de uma visão ágil.
Como cada papel tem suas responsabilidades específicas, é altamente recomendado que não haja acúmulo de papéis pelos membors da Equipe Scrum. No entanto, a realidade em muitos projetos não permite essa divisão clara de papéis e o acúmulo acaba acontecendo. Então é comum vermos Equipes Scrum, onde:
1. O Scrum Master é também um membro do Time.
2. O Product Owner também colabora no desenvolvimento da sprint, no papel de membro do Time
3. O Product Owner também desempenha o papel de Scrum Master
Nesse contexto, onde o recomendável é que não haja acúmulo de papéis, o que mais me perguntam nos treinamentos e consultorias que tenho feito é: Por que não acumular papéis? Quais os problemas implícitos no acúmulo de papéis?
Vou enumerar aqui alguns pontos onde o "perigo se esconde" e que é preciso especial atenção e cuidado para não prejudicarmos a agilidade no projeto e principalmente, para não culparmos ao final a metodologia como sendo o vilão do história.
Analisemos o primeiro caso de acúmulo de papéis:
O Scrum Master é também um membro do Time.
1. Entregas tendem a ficar comprometidas
A medida que o Scrum Master é requisitado para remover impedimentos, ele deixa de dar horas para apoiar o desenvolvimento. Se os demais não se esquematizarem para cobrir as ausências do SM a entrega ficará comprometida.
2. Alta variância na velocidade da equipe
Com as entregas comprometidas a cada sprint, variam-se os pontos entregues e com isso varia-se também a velocidade da equipe, já que a mesma é calculada pela média dos pontos entregues nas sprints anteriores.
A cadência sustentável que se busca na agilidade fica comprometida. Os planejamentos começam a falhar também. As entregas ficam comprometidas.
3. Estimativas podem conter "gordura"
Como o Time (de desenvolvimento) sabe que o Scrum Master terá impedimentos ao longo da sprint para resolver, mas não sabe prever quais e o quanto de tempo isso irá tomar, o Time pode acabar estimando as histórias para cima, incluindo uma "gordurinha" para evitar a "decepção" da não entrega do combinado ao final da sprint ou para resolver o problema da alta varância da velocidade, já que a causa principal não pode ser resolvida (Scrum Master também no papel de Time).
4. Conflito de interesse
O Scrum Master pode se eximir de desenvolver tarefas que ele não queira/goste de desenvolver com a prerrogativa de que no momento ele está cuidando do processo. Para a história não ficar em aberto outros membros do Time terão que pegá-las para finalizar a história antes de seguir para uma nova.
Essa situação, por vezes, causa descontentamento no Time e não necessariamente será bem trabalhada na retrospectiva, já que o Scrum Master pode insitir na desculpa de que no momento do ocorrido ele estava cuidando do processo, que isso faz parte desse acúmulo de papéis e que o Time terá que conviver com isso : (
5. Histórias "meio prontas"
O Scrum Master na ação de resolver um impedimento pode acabar deixando uma tarefa em andamento por mais tempo do que o conveniente, pois isso pode acabar por prejudicar a finalização da história a qual a tarefa pertence.
Se for uma história que está sendo implementada já no fim da sprint e os demais do Time estiverem alocados na finalização de outras histórias, corre-se o risco de terminar a história com essa história "meio pronta". Para isso é muito importante a equipe diariamente fazer uma boa reunião diária, sempre ciente desse acúmulo de papel por um dos membros do Time para elaborar bem a tática a seguir para atacar as histórias.
6. O processo pode perder a agilidade
Com o Scrum Master envolvido em desenvolver ele perde o olhar (foco) para o processo e pontos chave de melhoria que ele perceberia estando de fora do Time ele não mais consegue perceber, por fazer parte do mesmo.
7. Dificuldades em "chavear o chapéu" na Retrospectiva
Sendo Scrum Master como ele poderá conduzir uma retrospectiva e também atuar como time (levando os problemas e souções).
É importante a figura do Scrum Master nessa reunião guiando a equipe na busca da agilidade, porém sem se deixar envolver nas discussões e etc. A pessoa estando no chapéu de Scrum Master estará preocupada em fazer a reunião acontecer da melhor forma e certamente para isso ocorrer ela não poderá chavear para o chapéu de membro do Time. O ideal nesse caso é chamar uma pessoa com capacidade para conduzir retrospectivas, porém pode ser que a mesma não esteja a par do que ocorre no dia-a-dia de trabalho do Time e nem do status atual que o Time se encontra no uso do Scrum e de onde se pretende chegar.
Enfim… Esses são alguns pontos que levantei aqui para que a Equipe Scrum (PO, SM e Time) esteja atenta ao acumular papéis no projeto, especificamente Scrum Master e membro do Time.
Se você participa de uma equipe com essa configuração que tal deixar aqui seu relato de dificuldades e soluções implantadas para compartilhar com demais amigos que estejam na mesma situação?
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.