A equipe não consegue entregar nada durante a sprint, mas finaliza tudo (quando consegue finalizar) no último minuto. Esse comportamento fica evidente quando vemos no gráfico o que chamei de burndown triângulo retângulo: a linha de progresso real se mantém reta e contínua até o último dia da sprint, quando, então, cai perpendicularmente ao eixo X para mostrar o avanço da equipe. Você já deve ter visto uma anomalia como esta, certo?

Principais causas

Algumas podem ser as causas desse comportamento triângulo-retangular das equipes, como:

• Histórias muito grandes. O que nos leva a perguntar novamente por quê haviam histórias tão grandes… e descobriremos que ou foram mal detalhadas ou mal estimadas ou negligenciou-se a potencial quebra em atividades menores;
• Histórias mal escritas, que geraram confusão na hora de desenvolver e que, por sua vez, tomaram mais tempo que o previsto. Some-se à isto o tempo em que o desenvolvedor passa tentando entender a história e a demora que leva para poder pedir ajuda e dar clareza para o trabalho;
• Muitas atividades em paralelo. Que é, geralmente, a principal causa: quando cada membro da equipe pega uma coisa diferente para fazer. Abrem várias frentes ao mesmo tempo e sobrecarregam as fases seguintes quando terminam todos próximos uns dos outros. Neste cenário, em que a fase de Qualidade é posterior ao desenvolvimento, será fácil ver um gargalo se formando em Testes e o acúmulo de itens “semi-prontos” com grandes riscos de serem recusados e nada atender ao done da equipe;
• Gargalos nas últimas fases, pois pode ser que uma destas fases esteja esperando alguém atuar que: ou não está sempre disponível; ou que esteja com baixa produtividade: seja por falta de gente ou competências.

Indicações

As ações para correção deste cenário no qual a equipe termina tudo na última hora e que tem grande potencial de dar tudo errado, são basicamente o contrário das causas: histórias menores e mais bem escritas e menos coisas em paralelo.

Mas seja como for, uma boa maneira de começar a endereçar a questão é limitar o trabalho em progresso de uma das fases. Este conceito do Kanban é essencial para uma melhor fluidez das informações; para evidenciar o gargalo e para incomodar a ponto de alguma coisa precisar ser feita.

• Ao limitar o trabalho em progresso de todo o fluxo, você verá melhor se:
• Ao melhorar a escrita das histórias, mais itens são entregues antes do final da sprint;
• Ao melhorar a quebra das histórias a vazão aumenta e o lead time diminui;
• Pode diminuir o número de desenvolvedores, pois não precisa de tanta velocidade nesta fase;
• Cria mecanismos de mutirão (swarm), em que funções diferentes se ajudam nos gargalos;
• Precisa aumentar a equipe de qualidade;
• Precisa melhorar os processos de qualidade;
• Precisa melhorar os processos de desenvolvimento, uma vez que pode estar deixando passar muitos bugs.

Enfim, você diagnosticará melhor suas causas-raiz de acordo com pequenos experimentos olhando para o fluxo e testando estas hipóteses levantadas acima. Mas limitar o trabalho em progresso, de alguma das fases, talvez seja o ponto inicial da sua jornada em evitar o triângulo retângulo no seu gráfico de burndown.