Eu estou no mesmo squad da empresa que eu trabalho, Gupy, por mais de um ano e meio. Uma das coisas que meu time sofria bastante era a eficiência das nossas plannings.
Era mais que comum que nossa planning passasse de 3 horas. A gente passava muito tempo mudando de contexto entre valor de negócio, detalhes de implementação e estimativa de complexidade. Assim como "code smells", a gente podia perceber que existia algo que não cheirava bem: era comum que a gente divergisse bastante nas estimativas, e quando a pessoa falava o racional por trás do voto era sempre *"Porque eu não sei muito de back ou front end" *****ou "Não conheço muito essa parte do código, mas ela parece ser uma bagunça".
Esse cheiro ruim se justificava com as nossas métricas. Nós não tinhamos um lead time estável entre sprints, e mesmo que tivéssemos melhorado nosso caminho para produção, as vezes a gente tinha tarefas anômalas que ficavam para sempre na fase de em desenvolvimento. Além disso, nossa previsibilidade de entrega da sprint era muito baixa. Tudo isso junto com o que a gente chama de queda da Felicidade da Pessoa Desenvolvedora, já que com alguma frequência a gente se encontrava com uma história muito mais complexa e difícil do que o estimado, e a ansiedade instaurava.
Então, depois de algumas retrospectivas com a mesma dor e os mesmos cartões de para melhorar, a gente decidiu experimentar uma cerimônia nova para melhorar a comunicação entre pessoas desenvolvedoras.
Alguns cards que surgiram de retrospectivas
Depois de mapear alguns problemas que a gente queria melhorar, como plannings longas demais, falta de contexto, e histórias mal estimadas, nós começamos a criar uma cerimônia chamada Dev Huddle.
De acordo com a Wikipedia:
"No esporte, um huddle é quando uma equipe se reúne junto, geralmente em um círculo apertado, para formular estratégias, motivar ou comemorar".
A ideia da huddle é que as pessoas desenvolvedoras do time vão olhar para as tarefas que devem entrar na próxima sprint e discutir uma por uma para criar uma estratégia: tentar prever problemas, falar sobre detalhes de implementação, compartilhar conhecimento daquele contexto e se comprometer com a regra do escoteiro.
Assim como uma retrospectiva, a Huddle tem diretivas: Nós não assumimos nada e Todos devem estar confortáveis com a decisão tomada. Esse acordo é importante para garantir que a estratégia seja baseada em evidências e que todas estão colaborando com uma missão.
