3 Erros de Scrum Masters e como corrigi-los

Ser Scrum Master pode ser uma tarefa bem desafiadora.

Se você dá conselhos e orientações demais ao time, logo ele se acostuma a esperar que o Scrum Master dite tudo. Mas se você oferece pouca orientação, o time se desenvolve mais devagar do que poderia. Se você resolve alguns problemas para o time, logo vão esperar que você resolva todos os problemas. Por outro lado, se você não resolve os problemas do time, em algum momento os membros param até de contar ao Scrum Master sobre seus impedimentos e dificuldades.

Scrum Masters caminham numa linha tênue e é fácil cometer erros. Neste artigo, vamos descrever três erros que Scrum Masters frequentemente cometem e, para cada um deles, apresentar uma breve sugestão de solução.

1) Deixar trabalhos transbordarem para o próximo Sprint

O primeiro erro é, na minha opinião, um dos piores hábitos que uma equipe pode desenvolver: deixar trabalho transbordar de um Sprint para o próximo.

Isso acontece quando uma equipe não conclui todos os Product Backlog Items planejados para um Sprint e simplesmente leva esse trabalho para o próximo Sprint.

Não me entenda mal: de vez em quando vai acontecer de uma equipe não conseguir terminar tudo. Na verdade, é até um bom sinal quando isso acontece às vezes. Significa que a equipe está se desafiando com um plano ambicioso e não está planejando trabalho de menos para um Sprint por medo de não conseguir entregar tudo.

No entanto, um Scrum Master também não deve tratar como algo trivial quando uma equipe não termina o trabalho planejado, senão os Sprints se tornam limites artificiais e sem significado. As equipes devem sentir uma leve pressão quando o final do Sprint se aproxima. Uma equipe deveria pensar: "Puxa, o Sprint termina amanhã. Preciso realmente manter o foco hoje e terminar."

Se o transbordamento de trabalho para o próximo Sprint é um problema na sua equipe, existem algumas coisas que você pode fazer:

Primeiro, você precisa eliminar esse mau hábito. Encoraje os membros da equipe a planejar o próximo Sprint de forma que definitivamente consigam completar todo o trabalho. Isso significa que devem ir com calma e planejar o próximo Sprint com um pouco mais de cautela. Se tudo correr bem, mais trabalho pode ser adicionado ao Sprint.

Além disso, você pode tentar fazer com que a equipe sinta um pouquinho de culpa quando nem tudo é concluído. Não se trata de fazer alguém se sentir realmente mal. Os membros da equipe devem sentir apenas aquela culpazinha que estou sentindo agora. Estou tentando parar de beber tantos refrigerantes. Já estou fazendo progresso e não tomo um há uma semana. Mas hoje, enquanto escrevia este artigo, me deu vontade. Então me permiti um refrigerante. Não me sinto mal por isso, mas definitivamente não quero tomar outro amanhã, para não voltar aos velhos hábitos.

2) Realização dos Daily Scrums

Um segundo erro que frequentemente observo em Scrum Masters é que eles assumem a condução do Daily Scrum. Claro que o Scrum Master deve participar dos Daily Scrums e também dar seu próprio update. No entanto, o Scrum Master não precisa liderar a reunião, pedindo constantemente aos membros da equipe que participem, etc.

O Scrum Master deve explicar as regras e o propósito do Daily Scrum e liderar as primeiras duas ou três reuniões, incentivando as pessoas a participarem. Depois disso, porém, deve deixar a equipe conduzir os Daily Scrums por conta própria.

As atividades de um Daily Scrum não são particularmente difíceis. Não é necessário um "policial" para regular tudo, pois se o Scrum Master liderasse a reunião dessa forma, a discussão ficaria muito direcionada ao Scrum Master.

Com uma nova equipe, gosto de começar definitivamente moderando as primeiras reuniões eu mesmo. Depois, em algum momento, digo apenas "Ok pessoal, é hora de começar" e talvez ainda pergunte quem quer iniciar. Mas logo paro com isso também.

Após algumas reuniões, começo a olhar obviamente para o meu relógio quando é hora de começar a reunião. Se necessário, limpo a garganta alto o suficiente para que todos entendam o que está acontecendo. E então fico simplesmente parado em silêncio até que alguém diga: "Ah, acho que devemos começar." Após alguns dias olhando para o relógio e limpando a garganta, vou um passo além e apenas olho para o relógio quando é hora de começar. E novamente, após alguns dias, paro até com isso. Simplesmente fico parado esperando que a reunião comece.

Claro que não fico em silêncio durante toda a reunião. Eventualmente preciso orientar alguém a entrar em mais detalhes, ou interrompo alguém educadamente e sugiro que talvez seja melhor tratar dos detalhes após o Daily Scrum.

Imagine simplesmente que eu (ou outra pessoa desconhecida) estivesse presente no seu Daily. Nesse caso, não deveria ser possível descobrir apenas observando quem é o Scrum Master da equipe. Certamente acontecerá de vez em quando que o Scrum Master diga algo que apenas um Scrum Master diria. Isso, no entanto, não deveria acontecer constantemente.

3) Deixar a equipe caminhar para um burnout

Não sou um grande fã da maioria dos termos do Scrum, mas o termo Sprint é particularmente problemático. Quando eu faço um sprint na corrida, fico cansado rapidamente e preciso fazer pausas constantemente. Essa é uma metáfora bem ruim para uma equipe.

Um Sprint termina e o próximo começa. As equipes não deveriam começar o próximo Sprint enquanto ainda estão se recuperando do último. Em vez disso, as equipes deveriam trabalhar em um ritmo sustentável, que ficou conhecido como Sustainable Pace através de Kent Beck.

O terceiro erro que vejo frequentemente é que os Scrum Masters costumam permitir que suas equipes ultrapassem esse ritmo sustentável e caminhem em direção ao burnout. Um bom Scrum Master deveria prestar atenção e proteger a equipe de um possível burnout.

Muitas equipes são otimistas e esse otimismo se reflete na quantidade de trabalho que assumem para um Sprint. Os Scrum Masters deveriam ficar atentos e aconselhar cautela às equipes quando, durante o Sprint Planning, elas correm o risco de assumir mais compromissos do que conseguiram entregar em Sprints anteriores. Por quê? Porque a equipe, mesmo que consiga terminar todo o trabalho no Sprint, corre o risco de começar o próximo Sprint exausta e com otimismo excessivo em relação à quantidade de trabalho. Em algum momento, a equipe não conseguirá mais manter um ritmo sustentável e vai "queimar". Uma boa forma de proteger a equipe dessa situação é criar espaços onde eles possam decidir por conta própria no que querem trabalhar.

6 x 2 + 1

Para isso, gosto de usar um método que chamo de "6 x 2 + 1". Isso se refere a seis Sprints de duas semanas mais um Sprint de uma semana no final. Os membros da equipe podem então escolher por conta própria no que querem trabalhar nesse último Sprint. Algumas pessoas usam esse tempo para desenvolvimento pessoal (ler um livro, treinamento em vídeo, etc.). Outras usam o tempo para refatorar código feio que o Product Owner não priorizou. Outros membros da equipe talvez tentem um experimento que, na opinião deles, poderia levar a uma nova funcionalidade incrível. Tudo isso a equipe pode decidir sozinha.

Introduzir um ciclo assim pode trazer ainda mais vantagens. O Product Owner, por exemplo, também tem uma semana inteira sem ser "interrompido" pela equipe. E muitas vezes esse é o melhor argumento de venda para conseguir o apoio do Product Owner.

Esse ciclo também pode ser vantajoso para toda a organização quando é preciso assumir compromissos como "Precisamos entregar essa funcionalidade em 3 meses!" A 13ª semana dos Sprints 6 x 2 + 1 também pode ser usada para um Sprint normal se a equipe estiver atrasada em relação a um prazo. Se a equipe conseguir cumprir o prazo depois, ainda é possível dar a eles um Sprint de uma semana para uso livre.

Aprenda mais sobre esses pontos em nossos treinamentos de Scrum Master e fique preparado para esse papel ágil em três dias, aprendendo a assumir responsabilidade como Servant Leader.