Falaremos sobre o Scrum Master com perfil técnico, levantando a discussão de alguns pontos do que ele pode ou deve fazer ou não dentro da equipe Scrum.
O artigo do Mike Cohn demonstra seis características do Scrum Master que ele considera que sejam as principais. E uma delas é:
“Knowledgeable The best ScrumMasters have the technical, market, or specific knowledge to help the team in pursuit of its goal. LaFasto and Larson have studied successful teams and their leaders and have concluded that ‘an intimate and detailed knowledge of how something works increases the chance of the leader helping the team surface the more subtle technical issues that must be addressed.'”
Ou seja, esse conhecimento técnico e do negócio proporcionam ao Scrum Master entender melhor os problemas do projeto e ajudar melhor a Equipe Scrum. Mas deve-se ter cuidado quanto a isso!
Uma das premissas do Scrum quanto ao papel do Scrum Master afirma que ele não deve estar comprometido com tarefas dentro do projeto e deve evitar se intrometer tecnicamente. Por dois motivos:
- isso pode impedir que se concentre em resolver os impedimentos e problemas que estão no caminho do time (que no início da adoção são muitos graves),
- além de pode acabar tirando o compromisso do time.
Então, no início da adoção é recomendável que o Scrum Master siga as recomendações e as práticas à risca, concentrando-se em cuidar só disso.
Por outro lado, à medida que o Scrum vai se tornando “sangue e carne” da organização, o Scrum Master vai sendo cada vez menos exigido ao passo que o time entra em um alto ritmo de produtividade sofrendo menos interferências. Isso permitiria que o Scrum Master fique um bom período sentado a espera de um novo impedimento.
Diante desse contexto, e desde que o Scrum Master concentre-se primeiramente em exercer bem o seu papel de Scrum Master, e que não atrapalhe o time nem o projeto, é totalmente aceitável que ele colabore com a equipe. Como é argumentado nos posts de Phillip Calçado e Guilherme Chapiewski, resume-se que, já que o manifesto ágil coloca as pessoas acima do processo, não se pode permitir que o processo coloque-se acima das pessoas, gerando um desenvolvedor (que pode estar dentro de um Scrum Master) completamente desestimulado e frustrado na equipe.
Então, você, Scrum Master com um perfil técnico nato, não se deixe frustrar pelo processo, só não atrapalhe a equipe e garanta o processo Scrum.