Não são poucas as empresas e times de desenvolvimento que vem questionando o papel do ScrumMaster. Precisamos realmente de um ScrumMaster? O que faz um ScrumMaster se o time já sabe auto-organizar? E se não há impedimentos, o que ele deve fazer? E se não uso mais Scrum, o que farei com o ScrumMaster? Neste post pretendo discutir esses e outros pontos para tentar desmistificar o trabalho do ScrumMaster.
Por que preciso de um ScrumMaster?
Se você revisitar o paper que “oficialmente” deu origem ao Scrum (Scrum Development Process, Ken Schwaber, 1995) e procurar por alguma referência ao papel de ScrumMaster não encontrará absolutamente nada! Isso porque quando da “criação” do Scrum este papel simplesmente não existia. Mas então por que ele foi criado? Essencialmente, porque Scrum é difícil de ser colocado em prática, a resisência é muito grande, e foi percebido que se não houvesse alguém realmente comprometido e dedicado a fazer isso acontencer, a mudança não aconteceria.
Quais as principais dificuldades para colocar Scrum na prática?
Segundo a edição mais recente da pesquisa “State of Agile Survey”, organizada pela Version One, 58% das empresas que disseram usar Agile mencionaram Scrum como o método que utiliza, e mais 17% citaram que usam Scrum e Extreme Programming (XP). Nesta mesma pesquisa, quando perguntados sobre as principais barreiras para fazer Agile funcionar, responderam:
- [ 51% ] Habilidade para mudar a cultura organizacional
- [ 40% ] Resistência geral a mudança
- [ 40% ] Disponibilidades das pessoas com as habilidades necessárias
- [ 34% ] Suporte da Gestão
- [ 31% ] Complexidade ou tamanho do projeto
- [ 29% ] Colaboração do Cliente
- [ 21% ] Confiança na habilidade para escalar Agile
- [ 19% ] Tempo percebido para transição
- [ 13% ] Restrições de orçamento
- [ 12% ] Nenhum
- [ 06% ] Outros
Bom, se sua empresa está decidida a aplicar Scrum a ponto de ter alguém com um papel chamado “ScrumMaster”, os impedimentos acima são os principais a serem combatidos por este profissional. Mas aí eu pergunto: quantos ScrumMasters você conhece que estão se envolvendo nos impedimentos organizacionais? quantos estão influenciando a Gestão para conseguir mais apoio? Quantos estão trabalhando com as pessoas para reduzir a resistência a mudanças, trazendo o cliente para dentro do projeto, ajudando áreas resistentes a entender e se aproximar de Agile…quantos?
Infelizmente eu tenho visto pouquíssimos, o que portanto me faz acreditar que grande parte dos questionamentos em volta deste papel seja pelo fato de poucos ScrumMasters estarem conseguindo fazer bem o seu trabalho. Portanto, a culpa é do ScrumMaster, certo? Não necessariamente. Grande parte do problema tem sido o fato das empresas não empoderarem este papel de forma adequada. Não estão dando a ele a autonomia necessária para se envolver em questões organizacionais que estão impactando aquele projeto.
O que tem faltado aos ScrumMasters?
Segundo Thiago Santos, que atua em papel equivalente ao de ScrumMaster na R7.com, “Faltam mais habilidades humanas, relacionadas a técnicas de facilitação, coaching e motivação de pessoas.”. Além disso, pelos pontos citados no “State of Agile” podemos perceber claramente que falta aos ScrumMasters investir no estudo de gestão e liderança, e ainda no conhecimento organizacional. Se grande parte dos reais impedimentos estão fora do ambiente de projeto e muitas vezes até fora de TI, um ScrumMaster que não conseguir influenciar outras áreas da organização se tornará fraco.
Mas se a empresa (ou departamento/área) não deu o nível de empoderação necessária ao ScrumMaster, é dever dele influenciá-la para conseguir isto. “Os primeiros meses foram terríveis, para praticamente todos os impedimentos que apareciam eu tinha que dar a resposta ‘Não tenho como resolver, vou ter que escalar.’. Passei então a investigar porque era tão difícil para a Gestão me dar autonomia, e comecei a ver que não era chatisse ou necessidade de mostrar poder. Trabalhei então nos pontos que descobri tentando mostrar ao PMO como poderiam ter a mesma ‘segurança’ ao me dar um certo nível de autonomia em alguns pontos.”. diz Charles Bennini, brasileiro que trabalha como ScrumMaster no Coutts Bank em Londres.
ScrumMasters precisam ainda entender que em sistemas complexos a gestão é diferente do que estamos acostumados a ler nas cartilhas de “boa gestão”. Em sistemas complexos o conceito de auto-organização é natural, e portanto a gestão tem que ser focada no sistema e não no trabalho que as pessoas fazem ou deixam de fazer. Recentemente fiz o seguinte comentário no blog da Lambda3 em uma discussão relacionada à figura do gerente:
Basicamente minha mensagem é: novos gerentes devem esquecer a idéia de gerenciar pessoas…e devem aprender a gerenciar sistemas, “apenas” isso. Uma mudança difícil, mas com impactos radicais. Restrições são necessárias em sistemas complexos – se não estes se tornam caóticos – e é aí onde entra a figura dos “novos” gerentes.
[…]
No meu ponto, o gerente A gerencia X que é o sistema onde B, C, D, E trabalham o sistema onde as pessoas trabalham, e não o trabalho das pessoas. Mas para garantir que este sistema não caia na falácia da linearidade…e nem no caos; ele precisa trabalhar com as restrições do ambiente, e para isso precisa trabalhar – dentre outras coisas – com os fatores humanos (ufa…rs).
É um trabalho full-time?
É comum os livros de Scrum afirmarem que um ScrumMaster deve ser um trabalho em tempo integral. Mas isso, na minha opinião, só faz sentido se ele possuir (ou estiver em busca de) empoderação suficiente para atuar em problemas que envolvam a estrutura da empresa, ou seja, quando ele realmente assumir a figura de um agente de mudança, que na verdade é o que esperamos dele. Mas caso isso não aconteça acho difícil conseguir uma justificativa para mantê-lo em tempo integral, aí o natural vai ser atribuir a ele novas responsabilidades e, comumente, dar a ele um outro título. “Apesar de ser um trabalho em tempo integral, como o título ScrumMaster não representava bem o papel, este passou a ser chamado de ‘Consultor de Projetos’.” diz Thiago Santos da R7.com.
Além disso há ainda a situação de empresas (ou times) pequenas, que possuem uma natural auto-organização e pouca interrupção da cultura organizacional. É bastante comum nestes casos haver o compartilhamento do papel de ScrumMaster com outras funções ou papéis.
O que um ScrumMaster deve estudar
É quase um consenso que o que mais tem faltado aos ScrumMasters tem sido habilidades de gestão e liderança, “ScrumMasters precisam de habilidades menos técnicas e mais interpessoais” afirma Milene Fiorio, Especialista em Agile na Petrobras, que cita que na sua área ScrumMasters são responsáveis por auxiliar os desenvolvedores e resolver os impedimentos, e comumente fazem parte do próprio time de desenvolvimento.
“Logo após servir e dar coaching aos times [de desenvolvimento], os [Certified] ScrumMasters devem considerar servir e dar coaching aos gerentes e líderes da organização” escreveu Jurgen Appelo, autor do livro Management 3.0, no post “What Comes After Certified Scrum Master?”.
Para finalizar, minha recomendação de estudo para ScrumMasters está concetrada em 03 pontos:
- Complexidade Organizacional: Teoria da Complexidade, CAS – Complex Adaptive Systems, System Thinking, o impacto da complexidade nas organizações, organizational design, …
- Gestão e liderança em Sistemas Complexos: Management 3.0 (Leia Você sabe o que é Gestão 3.0?), Beyond Budgeting, Radical Leadership, …
- Relacionamento de Agile com: Governança de TI, Operações, Área de Negócios, e outras áreas e processos da organização.
Excelente Texto Magno. Como você, também vejo pouquissimos ScrumMasters envolvidos em questões organizacionais. Meu diagnóstico é que empresas olham o Scrum como um método de desenvolvimento de software que “roda lá na TI”. Eu vejo como um problema de transparência e não de empowerment do SM. Lembro de uma frase de um CIO pra mim: “Se eu soubesse que o Agile iria me dar (mostrar na verdade) tantos problemas eu não iria sequer começar a transição”.
Particularmente, tenho adotado uma tática de inicialmente não ter ScrumMasters nas equipes antes de entender a natureza dos impedimentos e dos gargalos. Isso me parece ser mais “puxado”. Logo em seguida torno esses impedimentos e gargalos públicos, demonstrando como eles afetam o fluxo (as vezes até mostrando o custo deles através de Cost of Delay).
O Agile em geral sofre de ser nascido de um manifesto de programadores, virou um assunto de TI. Essas resistências e o resultado do Agile Survey não me surpreendem. No fim, se vai ter SM, se vai ser Scrum, se vai ser Agile é uma decisão econômica. É a empresa que tem que funcionar, não o processo.
Rodrigo, legal que gostou do texto!
Entendo que a origem do problema de empowerment pode ser a falta de transparência, você está certo. No caso do CIO que você cita, a mensagem desde o início deveria ter sido clara: Scrum é assim, se você não está disposto a conhecer seus problemas e trabalhar neles, é melhor nem começar.
No entanto, vejo em algumas empresas os ScrumMasters sendo vitais para o avanço de Agile/Scrum/etc., então por isso continuo insistindo em tê-los desde o início, mas batalho para que haja abertura para tentar envovê-los na estrutura da organização, e não apenas na do time.
Concordo que Agile sofre por ter nascido por programadores, mas acho que isso já está sendo notado (e trabalhado) mundo afora. É melhor uma melhoria local que funcione e permita dar o próximo passo, do que uma melhoria global que falhe. E sim, a empresa é que tem que funcionar (fim), e não o processo (possível meio).
Abs.