Refatorando o planejamento da sprint - mais pomodoros, mais negócio

Todas as cerimônias do scrum são reuniões. Portanto, se você fizer reuniões melhores, fará projetos melhores.
Essa citação é do Luiz Carlos Parzianello, e veio em bom tempo, quando estava pensando na qualidade da reunião de planejamento de sprint da equipe na qual trabalho.  Estava preocupado com o tempo que ela estava levando, com o excesso de preciosismo técnico na sprint planning e com uma tendência a querer esmiuçar detalhes de implantação das histórias de usuário antes do tempo.  Como na semana passada voltei empolgadíssimo do Agile Brazil 2010, e a equipe entregou uma excelente sprint na iteração passada e portanto estavam confiantes para experimentar algo novo, resolvemos refatorar nossa reunião...<!--more-->A primeira atitude foi com relação ao tempo.  O pessoal concordou que a reunião estava longa demais, e que o rendimento na segunda etapa da reunião era sofrível.  Muita coisa decidida mais próximo do final da reunião era esquecido simplesmente porque ninguém estava prestando muita atenção a essa hora.  O benefício obtido por esse esforço todo era muito pequeno, segundo a lei de retornos decrescentes mencionada em outro post nesse blog. Já tinha lido o relato de um pessoal da Globo.com sobre o uso da Pomodoro Technique para rodar reuniões, e achei que seria interessante tentar.  Especificamente nesse dia ficou fácil convencer o pessoal a tentar, uma vez que tinha jogo do Brasil às 11h, então combinamos de fazer quatro pomodoros de reunião até o jogo, e mais quatro depois de voltarmos do almoço. O incrível é que funcionou bastante bem!  Ao voltarmos pra parte da tarde, a própria equipe optou por continuar usando a técnica, porque sentiu que a reunião ficava mais dinâmica com a introdução de pausas periódicas, fica todo mundo mais focado justamente porque nos forçamos a "desligar" por um tempinho.  Acabamos levando nove pomodoros para a reunião toda, um a mais do que o previsto, mas transformar uma reunião que durava oito horas para quatro horas e meia na primeira tentativa não é um resultado ruim...  A sensação no final do dia foi de que estávamos todos muito menos cansados e com um nível de concentração muito superior ao que tínhamos no final da reunião no formato anterior. Outro ponto que tivemos que tratar, até para que conseguíssemos reduzir o tempo da reunião sem perder conteúdo, foi a quebra das histórias em atividades. Até então as histórias eram discutidas em grande riqueza de detalhes - inclusive a solução técnica para cada situação específica - e as atividades eram criadas a partir da necessidade técnica dos desenvolvedores. Isso quer dizer que saíamos da sprint planning com tarefas como "HTML/CSS", "Model", "Controller".  Ocasionalmente apareciam atividades que, quando alguém fosse executar cinco dias depois do planejamento, ninguém mais lembrava o que era.  O reflexo disso era claro nas reuniões diárias, onde a conversa era sempre focada no "micro", no detalhe técnico, e não na funcionalidade de negócio na qual se estava trabalhando. Para reverter isso, optamos por dividir as tarefas em macro-funcionalidades de negócio, e passamos a estimar a duração das atividades em "blocos" de horas, e não mais horas individuais, detalhadas.  Isto é, uma atividade só pode ser estimada em meio dia, um dia, dois dias, três dias, etc., ao invés de usar qualquer quantidade de horas.  Os nomes das atividades passaram a ser "Criar papel administrador", "Float de pessoas funcionando", etc.  Quando cada história começar a ser executada, o pessoal envolvido sentará com o Product Owner para, aí sim, fazer a análise da solução técnica e quebrar as atividades em atividades técnicas.  A expectativa é que isso faça com que, nas reuniões diárias, o pessoal discuta mais a funcionalidade de negócio do que somente um pedaço muito pequeno de trabalho técnico que estiver executando.  Isso está alinhado com outra prática que adotamos a uns dois ou três sprints, o de não numerar mais as histórias no quadro do sprint, para que as pessoas sempre se refiram às histórias pelo seu nome e assim nunca esqueçam o que cada uma representa. Acredito que com essas alterações (pomodoros nas reuniões, atividades macro e baseadas em funcionalidades e análise da solução técnica postergada para o início de cada história), teremos um processo mais leve como um todo. A equipe terá mais tempo para análise de cada história, uma vez que fica muito claro que isso não precisa ser feito na sprint planning e que haverá oportunidade de discutir isso durante a sprint. Além disso, a divisão das atividades explicitando as funcionalidades de negócio faz com que os desenvolvedores mantenham o foco no benefício que estão entregando para o cliente, e não somente no código que estão produzindo. Essas sugestões foram aceitas e trouxeram bons resultados porque todas as decisões foram tomadas por toda a equipe, em um momento em que o pessoal estava confiante depois de uma boa sprint e portanto dispostos a experimentar algo novo. Falta ver como ficarão as discussões na reunião diária, mas acho que teremos mais foco em funcionalidade e uma equipe mais atenta ao benefício que estamos procurando entregar na sprint.