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?