O Scrum indica que uma retrospectiva deve ter 3 horas para uma sprint de um mês. Proporcionalmente menos em sprints menores. Uma sprint de uma semana deve ter, assim, 45 minutos.
Eu acho 45 minutos pouco para uma retrospectiva decente. É muito difícil para um time jovem, ainda aprendendo a se auto-organizar e a lidar com complexidade, se auto-analisar em apenas 45 minutos.
Porque estou dizendo isso? Porque se você fizer mais que 45 minutos você não está fazendo Scrum. É um Scrum-but. “Eu faço Scrum, mas minhas restrospectivas levam uma hora e meia em sprints de uma semana, porque o time não consegue destilar tudo o que vivem em menos tempo do que isso”.
No entanto, cenários de alta complexidade não possuem melhores práticas claras. Isso é resultado da imprevisibilidade resultante da interação das variáveis de um sistema complexo. E a prescrição de um tempo de reunião seria como uma boa prática. Ao que me parece, inadequada, neste cenário específico, à uma boa parte dos times.
Um time deveria ser capaz de se auto-organizar e escolher o timebox correto de uma reunião de retrospectiva. Um bom líder vai indicar que quanto menor a retrospectiva melhor, desde que bata a meta de buscar a melhoria do processo. No entanto, se se restringir a um tempo qualquer pode incorrer no erro de impedir auto-organização. E se não se restringir pode acabar tento uma retrospectiva grande demais, e ineficiente. Portanto, a definição do timebox fica completamente subjetiva.
Não poderia ser de outra forma. O líder deve se avaliar, sentir e responder, em vez de categorizar seguindo boas práticas.
Isso significa que você não deve fazer Scrum com sprints de uma semana? Não. Signfica que o desenvolvimento de software é mais complexo do que parece, que nem todas as recomendações de qualquer framework ou metodolodia (mesmo os tidos como melhores ou os mais famosos) estão sempre corretos, e que o objetivo é entregar software, e não entregar determinada prática, selo ou nome que está na moda no mercado.
Temos poucos Scrum Master ou líderes que de fato entendem isso.
Giovanni Bassi
Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.