Nas últimas semanas, falei aqui sobre o Scrum. Primeiramente, destaquei as atitudes necessárias para se preparar para usar uma metodologia ágil. Depois, falei sobre as cerimônias, ou seja, as reuniões e práticas sugeridas pelo Scrum. E hoje, eu quero falar de gente, de pessoas. Assim, fechamos um conjunto importante: atitudes, processos e pessoas.
Por que 7 pessoas?
Quero começar falando do número de pessoas. Quem me conhece, sabe pelo meu apreço pelo número 7. Deixando a mística de lado, este quantitativo me parece racionalmente adequado. Há quem conheça, no entanto, esta métrica por regra dos 7, que diz que nenhum líder pode ter mais que 7 subordinados na equipe. Se você não gosta de números, então adote a regra do Jeff Bezos, que diz que duas pizzas devem ser suficientes para alimentar toda a sua equipe.
Time scrum
Mas, afinal, quem são estas possíveis sete pessoas que podem compor o seu time? Tem dois papeis que merecem destaque, que são o scrum master e o product owner. Os demais fazem parte da execução, compõem o time de desenvolvimento, também conhecido como time scrum. Cada um destes jogadores, além do scrum master e do product owner, vão, por conseguinte, ter habilidades específicas. Se estamos falando de produção de software, um trabalha com banco de dados, um faz programação web, outro cuida da interface do usuário e assim por diante. Perceba que o justo número sete é interessante por conta da multifuncionalidade do time.
Scrum master
Bem, vamos falar do scrum master, o técnico, uma espécie de coordenador, supervisor, um cara que tem que estar muito próximo da equipe. No futebol, costuma-se dizer que tem que saber falar a língua do boleiro. No vôlei, entretanto, talvez poderia ser comparado ao técnico ou líbero do time, um capitão. O grande mérito do scrum master é que ele conhece a rede formal e informal da empresa. Sabe aquele cara que a gente recorre quando precisa de um empurrãozinho pra alguma coisa acontecer? Só cuidado pra não ficar acionando o scrum master por qualquer motivo.
Product owner
Já o product owner, também chamado de PO, tem um papel diferente. Ele é o dono do produto. Este cara tem uma visão muito clara do problema, da dor que o time está atacando. Afinal, não faz sentido propor uma solução se não tivermos o problema bem claro. Lembra do backlog que eu falei na semana passada? Aquela lista de prioridades que você organiza e elege as atividades a serem cumpridas em cada semana, em cada sprint? Quem gerencia o backlog é o product owner. É ele, portanto, quem tem a percepção do que gera mais valor para o cliente em cada momento do projeto.
Pessoas e cerimônias
Em relação as cerimônias, alguns cuidados pra tomar. A reunião diária, a daily meeting é uma reunião de jogadores, do time scrum. O scrum master pode até participar, mas o product owner, salvo exceção, não precisa. A revisão do sprint, aquela que acontece no final da semana e cujo objetivo é avaliar o avanço do produto tem portas abertas para todos, inclusive pessoas de fora, tal como patrocinadores e gestores, haja vista que a ideia é de validação. Ah, e por fim, cuidado pra não usar a reunião de revisão para apresentar o avanço da semana para o product owner. Isso deve acontecer ao longo da semana e não só no fim dela.
Muito bem, em resumo, encerramos uma sequência de 3 semanas falando sobre o scrum, a metodologia ágil mais popular para gestão de projetos. Sou muito fã desta abordagem que envolve atitudes, processos e pessoas. Se você quer melhorar a produtividade do seu time ou da sua empresa, recomendo fortemente que você valorize o Scrum.