“O SM morreu? Que parada é essa, véi?”, perguntaria um amigo desenvolvedor.
Bom, parece que morreu, sim. Essa é a conclusão que eu chego a partir das conversas no cafezinho, com meus colegas de trabalho. Um gerente me disse: “Tem SM que só faz ritos. Isso qualquer um pode fazer”.
Um PO disse outro dia em uma reunião: “Eu vejo o SM e o DevOps fazendo praticamente o mesmo papel…”. Outro gerente falou: “O SM não blinda o time”.
E ainda existem outros que acham que o título “Scrum Master” não é aplicável, porque “ninguém é mestre de ninguém”, e esse título reduz a atuação do agente de mudanças (o tal Scrum Master) apenas ao Scrum.
Minha conclusão: se está é a opinião geral, então sim, o SM morreu. Mas espere um instante…
Precisamos lembrar que o Scrum é um framework, e não uma metodologia. E sendo um framework, ele precisa ser “turbinado” com aplicação de técnicas e ferramentas coerentes para atingir um objetivo estabelecido. Então, essa história de limitação pelo nome Scrum é relativa, concordam?
E o título de “Master”, como é que fica?
O Scrum Master não é o chefe da equipe, até porque os valores Scrum desestimulam uma estrutura hierarquizada. De fato, preconiza que as equipes devem ser auto-organizadas. Ou seja, o framework Scrum parece bastante recomendado para flat organizations como nós.
Além disso, não é de hoje que o Scrum Master é vendido e apresentado como um líder servidor. Neste caso, suas principais atribuições seriam:
- Defender os valores ágeis;
- Ajudar o time a “performar” em alto nível;
- Ser o protetor do time;
- Atuar para remover impedimentos para o time e/ou processos;
- Atuar como facilitador durante as reuniões;
- Atuar como catalizador entre o time e o PO;
- Certificar-se de que o time não está sobrecarregado;
- Estabelecer canais de comunicação entre time, PO e stakeholders;
- Cooperar para atingir os objetivos estabelecidos.
A partir das expectativas depositadas na atuação do SM, percebe-se que tal papel permeia três importantes dimensões quando falamos de desenvolvimento de produtos digitais: pessoas, processos e tecnologia.
Portanto, o SM não pode se limitar aos processos, tem que estar atento aos fatores endógenos e exógenos que podem impactar o produto que está sendo construído, e desta forma, tendo o conhecimento das competências e skills de cada membro do time, o SM pode propor um processo coerente e aplicável.
Porém, se 80% dos problemas ocorrem no âmbito das relações humanas – como me disse um Head –, o SM também precisa atuar. Talvez seja necessário a aplicação de técnicas e dinâmicas para mediar ou mitigar tais conflitos.
E também não se pode esquecer que a tecnologia deve ser usada para viabilizar/ potencializar os skills das pessoas, na busca pelos objetivos definidos (nunca se deve aplicar a tecnologia pela tecnologia).
Deveria um papel relevante como esse ser reduzido ou extinto? Parece-me que cabe a nós, SMs, uma reflexão: temos consciência das expectativas que são depositadas sobre nossa atuação? Temos feito pleno uso dos feedbacks produzidos por todos à nossa volta? O resultado de nosso trabalho tem agregado real valor ao produto?
Pensando bem, o SM não morreu.
Mas uma coisa é certa: ninguém é dono da verdade, e esta é situacional e transitória. Se eu esqueci alguma coisa, ou você tem algum contraponto, por favor escreva aí embaixo. O que vale é contribuir para a reflexão.
Até a próxima!
***
Artigo publicado originalmente em: http://www.concretesolutions.com.br/2017/02/15/o-scrum-master-morreu/