“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/

Wilson Silva