No último sábado (1 de abril) tive o prazer de palestrar pela primeira vez no Devops Summit Brasil. Tivemos uma conversa bem animada sobre as 8 Competências do Scrum Master. Mas fiquei bastante surpreso com a quantidade de pessoas balançando a cabeça positivamente na primeira parte da talk:

8 disfunções do trabalho do Scrum Master

O trabalho de um Scrum Master geralmente é limitado por algumas disfunções que, pela recepção da audiência da palestra, ainda são muito comuns no mercado. Para mim, estas disfunções estão intimamente ligadas a alguns mal entendidos com a premissa de que a essência do Scrum Master está em amparar o time. Ou seja, um conceito equivocado de liderança servidora.

Vamos explorar um pouco alguns destes mal entendidos.

Escriba

Tem Scrum Master por aí que vai pra planning com um caderno ou com o notebook debaixo do braço. “se alguém tiver alguma dúvida, eu consigo resolver” é, em geral, a justificativa.

É muito valioso que o Scrum Master esteja alinhado e por dentro do que está acontecendo no projeto. Mas isso não significa que ele precisa tomar pra si o papel que é do Product Owner! Certa vez, escrevi que “uma user story é um convite para uma conversa” entre o time e o Product Owner. O Scrum Master não tem o direito de se tornar um intermediário nesta ou criar uma barreira para essa comunicação colaborativa.

Pessoalmente, tenho um problema quanto a pessoas fazendo anotações enquanto um tema está sendo discutido (sobretudo nas discussões de grooming e planning, onde a feature está amadurecendo): é fato que o cérebro humano não consegue dar exatamente a mesma atenção para duas coisas ao mesmo tempo! Ou você escreve, ou você ouve. Ou você ouve, ou perde alguma informação importante. Ou você presta atenção no desenrolar da conversa, ou pode ficar perdido quando a conversa tomar um rumo diferente.

Se você riu, possivelmente, já viveu a sensação de que perdeu alguma coisa enquanto sua atenção não era exclusiva da discussão! 🙂

Secretário

No meu primeiro projeto Scrum, o time quis me dar o papel de secretário. Atender telefones, arrumar agendas, marcar cerimônias e trazer o café.

Confortável, não?

O argumento aqui é bem simples: liderança servidora não tem nada a ver com servidão; entregar software de qualidade e funcional não tem nada a ver com escrever linhas de código loucamente, como se não houvesse amanhã.

O Scrum Master serve ao time no sentido de criar um ambiente de aprendizado e propício para que seja possível a tão sonhada auto organização. É desenvolver pessoas, ao invés de mimá-las ou ampará-las.

Patrulheiro do Scrum

O papel do Scrum Master não reside em garantir que aconteçam as cerimônias ou que exista uma definition of done colada na parede. O Scrum Master precisa, em primeiro lugar, ajudar o time a entender o que realmente faz sentido para o seu processo. Depois que este entendimento é formado, o Scrum Master pode ajudar o time a garantir que seus acordos estão sendo cumpridos.

Gosto de contar a história de dois times onde eu era o Scrum Master: um tinha uma reunião diária de 15 minutos; o outro, de pelo menos meia hora. Por que? Um deles mais sênior, preocupado com a entrega. O outro, formado por pessoas menos experientes, que usavam a reunião para trocar experiências de como resolveram seus problemas.

Várias pessoas me perguntavam por que eu não intervinha. Simples: por que era um momento valioso para o time! Com o tempo, o timebox foi diminuindo naturalmente, à medida que as pessoas evoluíam tecnicamente.

Um bom Scrum Master conhece as regras; um ótimo Scrum Master sabe quando pode quebrá-las.

Chefe do Time

Isso é muito comum em empresas mais tradicionais. As pessoas estão tão acostumadas a se reportar a alguém que, quando chegam num Time Scrum pela primeira vez, elas começam a se reportar ao Scrum Master.

É muito fácil identificar esta disfunção quando as pessoas começam a avisar para o Scrum Master que vão sair mais cedo, mais tarde ou emendar feriados. Ou quando as retrospectivas são prestações de contas para o Scrum Master.

Vai emendar o feriado? Pergunta pro time o que ele acha! Eles podem dizer, mais do que o Scrum Master, qual o impacto de uma ausência para uma entrega. Olha você aí, Scrum Master, ensinando o time a tomar decisões e fazer análise de riscos!

Administrador da Ferramenta

Algumas empresas transferem a administração da ferramenta – e, consequentemente, seu bom uso – para os Scrum Masters. E parece ser um grande alívio ter alguém dedicado para esta função!

Tal atitude cria aquelas famosas vagas que requerem profunda experiência na ferramenta XYZ, tirando o foco daquilo que realmente importa no Scrum: entregar software de valor e desenvolver o mindset ágil nas pessoas e na empresa.

Não tem problema nenhum em o Scrum Master administrar a ferramenta escolhida pela empresa. Mas a ferramenta não pode, de forma alguma, ser um fator limitante na seleção do profissional.

É como diz o Manifesto Ágil: indivíduos e interação entre eles, mais que processos e ferramentas!

Dono do Board

Eu acho esta disfunção muito divertida!

Certa vez, em uma empresa, fui procurado por uma pessoa de uma outra área, pra me dar um feedback: “cara, eu gosto muito do seu trabalho! você trouxe cor pra empresa, com esses papéis na parede!”

Logo eu, que sou daltônico?

Primeiramente, o board físico (apesar de eu, pessoalmente, gostar muito) não precisa existir só por que o Scrum Master quer! Como eu disse quando falamos sobre o Patrulheiro do Scrum, o board físico também precisa fazer sentido e ser útil para o time!

Outra coisa que eu não gosto é quando o Scrum Master organiza pessoalmente o board. O board é do time! Os cards são do time! A partir do momento que uma pessoa do time pegou aquele card, ela passa a ter uma ligação com ele. É muito mais legal quando as pessoas querem, elas mesmas, movimentarem os cards no board, pois estão contribuindo para alcançar os objetivos da iteração.

Presidente da Reunião Diária

Do mesmo jeito que as pessoas estão acostumadas a se reportar a alguém, elas estão acostumadas a se justificar para alguém. Todos os times em que fui Scrum Master, em algum momento, fizeram da reunião diária uma cerimônia de Status Report. Pra mim!

Reunião diária é uma ferramenta de planejamento do time, para o time! O Time Scrum precisa entender o quão próximos (ou não) estão de atingir os objetivos da iteração e traçar um plano para atingí-lo. Ou levantar riscos. Ou dizer que não vão conseguir.

Simples assim.

Duas técnicas bem simples cabem aqui: eu costumo evitar contato visual com o time, quando percebo que criou-se uma reunião de status. As pessoas precisam olhar pra alguém enquanto falam. E, se não for o Scrum Master, elas tendem a trocar informações de forma mais orgânica.

Outra coisa que funcionou pra mim foi pedir para o time focar mais no planejamento do que no que fez ou não. Visão de futuro, planejamento, goals.

Herói

No meu primeiro dia de trabalho em uma grande empresa, o Product Owner sentou do meu lado e disse “nossa! você vai salvar o meu dia! você vai me ajudar muito a resolver os meus impedimentos!”.

Bom, primeiro, tive que realinhar as expectativas: eu tinha mesmo que resolver impedimentos do PO (todos relacionados à falta de comunicação com o cliente)?

Depois, tive que alinhar as expectativas do Product Owner: o Scrum Master faz um curso de Scrum e não de bruxaria! Nós não recebemos poderes mágicos ou aprendemos dinâmicas milagrosas que resolvem todos os problemas. Nós aprendemos como organizar as coisas de modo que as pessoas queiram falar sobre o elefante no meio da sala!

Um traço bem comum do ser humano é a necessidade de um herói, que salve o seu dia, que entenda suas angústias e tire a sua agonia. Isso em todos os sentidos, alinhado à disfunção no conceito de líder servidor gera toda uma expectativa em torno desta pessoa Mestre em Scrum!

Mas, sim, existem muitos Mestres em Scrum que assumem suas identidades secretas e querem resolver todos os problemas do time, pelo time.

Eu não gosto deste tipo de abordagem! Eu acredito que uma das principais funções de um Scrum Master é desenvolver pessoas, além de times de alto desempenho. E como é que você vai desenvolver alguém se você sempre ampara o seu time?

Acredito muito mais em observar como o time se comporta e como estão tentando resolver seus problemas. A minha atuação fica mais voltada para a orientação do time e facilitação. Sim, eu gosto de colocar o time no fogo.

E gosto que as pessoas descubram que podem ser heróis delas mesmas. Quando eu, Scrum Master, consigo esta mudança é que eu me sinto, de verdade, Mestre em alguma coisa.

Faz sentido, Mestre?