Agilidade na prática: evite tantas reuniões
Continuando a série de problemas práticos encontrados na maneira de pensar quando adotamos metodologias ágeis, um comentário sempre feito no curso é a situação que afeta muito a produtividade de Product Owners e Scrum Masters (ou líderes/papéis similares em qualquer metodologia): a falta de produtividade dos dois devido a quantidade de projetos que lidam.
Para praticantes de Scrum, por exemplo, 13% do tempo de um PO e SM é consumido em reuniões por cada projeto que ele participa.
Isso não é nada frente ao tempo investido por dois desenvolvedores em pair programming (80~100%). Mas o objetivo do desenvolvedor é alcançado durante esse período de comunicação. Para um PO, SM ou líder, é durante esses 13% que colherá informações para trabalhar em cima no resto do tempo.
A consequência é grave: PO e/ou SM e/ou líderes distantes, impedimentos que duram meses, falta de tempo para novas idéias etc.
Para deixar claro, vamos aos prejuízos alarmantes:
Se você, como SM, líder ou PO, toca cinco projetos simultâneamente, você tem 2 horas e 45 minutos para se dedicar a cada um desses produtos por semana. Nesse tempo terá que ter idéias novas, resolver problemas, responder emails, fazer reuniões fora do ciclo tradicional. É tempo suficiente?
A conclusão é que é impossível se dedicar com alta qualidade tocando 5 projetos simultaneamente. 4 projetos? Você agora tem 4 horas e 45 minutos por semana para pensar sobre seu produto, ter novas idéias, conversar com seus clientes, ler seus emails, fazer reuniões fora do ciclo etc.
3 projetos? Nesse caso você tem 8 horas, um dia por semana para pensar sobre seu produto ou resolver os problemas de sua equipe.
Está é uma medida simples que mostra quanto tempo estamos investindo em reuniões e faltando POs e SMs e quanto tempo está sendo gasto pensando em seu projeto e resolvendo os problemas de verdade. Para fins de completude - e possível conversa dentro de sua empresa para evitar cair nessa situação - o gráfico a seguir ilustra o número de horas livres por projeto por por semana em função do número de projetos:
Utilizei a regra de que, se sua iteração é mais longa ou mais curta que 3 semanas, utiliza-se um número de horas proporcionais ao seguinte: 15 minutos de daily meeting, 3 horas de review, 3 horas de planning e 2 horas de retrospectiva. Utilizando regras não proporcionais o cenário fica bem pior.
Para ter um ótimo desempenho, aceite o segundo, evite o terceiro e diga não ao quarto projeto.