Parece que foi ontem o meu primeiro Sprint Review na empresa em que havia sido contratado como treinador ágil. O Scrum estava sendo exercitado há anos e parecia que a empresa era composta de agilistas maduros e bem disciplinados. Quando foram agendadas as cerimônias de review de sprint das várias equipes para que pudessem demonstrar os resultados do último ciclo de sprints, fiquei muito entusiasmado. Cheguei cedo à sala para conseguir um bom lugar, cheio das melhores expectativas.
Aos poucos, as pessoas foram chegando e a sala foi se enchendo e ficando bastante agitada, o que inclusive aumentou minhas expectativas. Então, a primeira equipe começou a apresentar seu review. Exibiram alguns slides de PowerPoint e só...
A equipe possuía uma lista de trabalhos feitos, algumas imagens e piadas, as quais foram usadas em momentos adequados para animar o ambiente. Mostraram o trabalho feito, um slide por vez e em alguns momentos as pessoas aplaudiam educadamente em aprovação.
Mas ocorreu-me em algum ponto durante o primeiro review que alguma coisa muito importante estava faltando: não havia software em funcionamento. O propósito de um review é mostrar código funcionando para revisão e feedback. Imaginei que este caso fosse uma exceção, que apenas esta equipe não apresentasse o software em funcionamento e que certamente a próxima o faria.
Mas, uma-a-uma, cada equipe seguiu o mesmo padrão, mostrando slides engraçados e representações textuais do esforço, sem nenhum código em funcionamento para ser visto. Meu entusiasmo foi desaparecendo rapidamente ao mesmo tempo em que fui me frustrando.
A frustração não foi tanta com as equipes, mas com quem quer que seja que tinha explicado a razão da cerimônia de review para todos. Claramente ninguém tinha entendido, nem mesmo os stakeholders, que riam das piadas e aplaudiam os esforços das equipes. Parecia mais que esta reunião acontecia apenas por constar na lista de práticas do Scrum.
Nunca mais!
Esta foi a última vez em que os reviews foram feitos desta forma, pois apesar de acreditar na noção de equipes autodirigidas, imediatamente passei alguns direcionamentos e objetivos para reviews futuros.
Algumas das orientações estavam naturalmente alinhadas com o manifesto ágil, como por exemplo a ideia de mostrar código funcionando ao final de cada iteração ou sprint, mas outras eram adaptadas para nossa dinâmica e cultura organizacional.
O foco deste artigo é compartilhar algumas orientações, estratégias e formas de pensar que promovemos para mudar nossos reviews de sprint. Com o passar do tempo, saímos daquela situação para a seguinte:
- De aplausos educados ..para.. aplausos entusiasmados
- De aplausos educados ..para.. recebimento de feedback coerente e construtivo
- Da venda e marketing dos nossos resultados ..para.. torná-los transparentes e honestos
- De pequenas aglomerações ..para.. uma sala tranquila para se reunir e assistir os vídeos
- De apresentações em PowerPoint ..para.. software em funcionamento sempre que possível
- De mero entretenimento ..para.. demonstração de valor de negócio e exposição do esforço da equipe
- De fingimento ..para.. feedback intencional e coerente
- Da venda e marketing dos nossos resultados ..para.. a equipe falando em nome próprio.
Certamente as recomendações não levaram imediatamente aos resultados e continuamos fazendo ajustes para ter reviews cada vez melhores. Contudo, conseguimos tornar nossos reviews em um pilar para a adoção do ágil pela organização.
Abaixo estão alguns objetivos nos quais focamos...
Reviews orientados à excelência
Os reviews de sprint são de grande importância. Uma equipe ágil trabalhou nas histórias mais importantes para a organização durante um período de tempo e está pronta para entregar software em funcionamento. Trata-se de algo novo e as pessoas deveriam estar interessadas e entusiasmadas para ver os resultados.
É da equipe a responsabilidade de revelar efetivamente seus esforços. Não se trata simplesmente de exibir software em funcionamento, trata-se de contar e mostrar toda a história relacionada ao trabalho feito. Esta história deveria possuir contexto e narrativa, assim como uma conexão com o último sprint e uma visão para os próximos.
Há alguns pontos de atenção comentados logo abaixo, bem como exemplos de pauta para um review de sprint. Espero que as ideias possam ajudar com seus próprios reviews, especialmente em como conseguir o engajamento real dos stakeholders e em como criar um momento mais cheio de energia na apresentação de suas equipes.
Sete pontos de atenção para seus reviews de sprint
1. Propriedade
Estabelecemos que o Product Owner (PO) dá o tom geral do review de sprint. Apesar de ser algo da "equipe inteira", no final, a comunicação externa, a demonstração do valor planejado e a entrega e recebimento de feedback, assim como os ajustes correspondentes, são características básicas do papel do PO. Este papel também é responsável por levar as pessoas ao review - se a frequência for irregular, deve-se tentar descobrir o motivo e agir para conseguir que as pessoas desejadas estejam no review.
Muitas vezes penso no papel do product owner como o de anfitrião do evento - no qual conduzem todos os aspectos do review. Certamente não fazem tudo sozinhos, mas guiam a qualidade, foco e resultados gerais da cerimônia.
2. Formato
Vale pensar bastante na coordenação do review (ou reviews no caso de uma iniciativa multiequipes), pois é importante estabelecer uma cadência, de forma que estes aconteçam periodicamente e sempre nos mesmos horários. Outro ponto importante nos reviews é conseguir que as equipes sigam um fluxo consistente, como veremos mais a frente na proposta de pauta para reviews.
Nossa experiência de coordenação era a de ter várias equipes apresentando seus reviews no mesmo dia, pois os sprints eram sincronizados. Nosso formato dividia um tempo aproximado de três horas para que cada equipe pudesse apresentar o seu review. Não só planejava-se cada review, como havia a condução do fluxo das cerimônias entre as equipes pelo PO Geral (Chief Product Owner).
3. Metas de Sprint
O review está ligado à meta do sprint ao qual a equipe havia se comprometido. Assim, uma boa dica ao se tentar criar uma meta de sprint é a de se pensar no texto que será enviado aos stakeholders convidando-os para o review. A história do sprint então estará ligada à meta e também sobre como a equipe se comportou para atingí-la.
Deve haver honestidade no review sobre a entrega da equipe em relação aos compromissos assumidos, no intuito de declarar o sprint como um sucesso ou um fracasso. Mas não deixe que a sua equipe se sinta abatida com o termo "fracasso", pois faz parte do aprendizado fracassar; é saudável que a organização adote uma atitude de tolerância a falhas.
4. Visão de equipe coesa
Vejo o Product Owner como o condutor do review, o Scrum Master como o facilitador (se necessário) e a equipe toda pode exibir seus resultados. Esta abordagem de equipe coesa serve para dar transparência a sua equipe e a a chance de fazê-la brilhar, então rotacione as pessoas de forma que todos, independente de papel, tenham a chance de mostrar o seu trabalho e resultados.
E não force as pessoas introvertidas a falar em um fórum muito grande, apenas as encoraje, mas sempre deixando a tarefa como algo opcional. É comum para os introvertidos ajudarem bastante no review, apenas não como apresentadores. No final, o importante é conseguir o engajamento da equipe inteira.
5. Preparação
Se há uma base sólida para um bom review, esta deve ser a sua preparação - dose bem para não pecar pelo excesso ou pela falta. Deve-se eleger qual trabalho é relevante para o review, em que fluxo deveria ser demonstrado e como ele se conecta com os trabalhos anteriores e os dos próximos sprints.
Muitas vezes, alguém com conhecimento em Quality Assurance (QA) desenvolve um 'script' para ajudar a equipe a demonstrar seus esforços de forma coerente. Por fim, o Product Owner deve ter a última palavra sobre o que deve ser exibido e por qual razão, preparando o cenário da demonstração para os demais stakeholders.
Esteja preparado para a apresentação do review. Se necessário, já na cerimônia de planejamento reserve algum tempo do sprint para ser gasto na preparação do review.
6. Execução e Demonstração
O review deve ser suave, bem pensado e preparado, mas no final o que é necessário mesmo é que o software funcione sem problemas. Faça testes do tipo dry run sobre a demonstração e não se esqueça de fazer uma configuração prévia. Lembre-se de cronometrar seus tempos para que sua demonstração não extrapole o tempo esperado e reserve também um intervalo para as perguntas e respostas.
No review, deve-se contar uma história que mostre o fluxo de trabalho utilizado para a entrega de funcionalidades. Já vi algumas equipes que no primeiro review mostravam um diagrama arquitetural do que pretendiam fazer nos próximos seis sprints. A cada review, marcavam no diagrama as partes que haviam ficado prontas. Isto ajudava os ouvintes a entender a evolução do trabalho.
Todo o trabalho que a equipe realizou em um sprint é um bom candidato a ser demonstrado, incluindo funcionalidades, melhorias, correções de defeitos, refatorações, documentação, infraestrutura de testes, praticamente qualquer coisa. Naturalmente há coisas difíceis de se demonstrar ou ilustrar, mas se a equipe empenhou trabalho em algo, este deve ser candidato a ser demonstrado no review.
Por fim, esteja pronto para explicar as coisas suficientemente bem para que os ouvintes possam entender o que acabou de ser demonstrado, além do significado e do nível de esforço utilizado para realizar o trabalho.
7. Fechamento
Sempre finalizamos nossos reviews com um pedido por feedback - tanto do software quanto da própria dinâmica da cerimônia. Perguntas como, por exemplo, "explicamos bem o que fizemos?", "Está claro como nos encaminhar os feedbacks?" ou ainda "como podemos tornar o nosso review ainda melhor?". Utiliza-se apenas alguns minutos com isso, mas é um tempo muito bem gasto. Utilizamos uma técnica conhecida em inglês como Fist-of-Five (punho-de-cinco - técnica na qual as pessoas levantam as mãos mostrando de um a cinco dedos) para obter o feedback final de como foi o review.
Exemplo de pauta
Temos a seguir um exemplo de modelo de pauta para o review de sprint:
1. Introdução
2. Apresentação da equipe
-
quem é quem: nomes, papéis e localização dos integrantes da equipe
-
pessoas de fora da equipe que ajudaram no sprint
3. Agradecimentos
-
valorização dos integrantes da equipe
-
reconhecimento das pessoas de fora da equipe que tiveram atuação importante no sprint
4. Meta do sprint
-
relembrar a meta do sprint e de qualquer ajuste feito durante o sprint
-
declarar se o sprint foi bem sucedido, por exemplo, se a equipe conseguiu atingir a meta com a qual se comprometeu
5. Estratégias? Sucesso? Esforços? Descobertas? Resultados?
-
compartilhar qualquer estratégia relevante utilizada para entregar os resultados
-
explorar os esforços feitos durante o sprint
-
contar sobre alguma descoberta de algo inesperado; sobre algum resultado crítico
-
todas estas recomendações servem para dar à audiência uma visão do que aconteceu por trás dos bastidores do sprint
6. Demonstração e sessão de perguntas e respostas
-
demonstrar o conjunto de histórias de usuário e funcionalidades - deixando espaço para sessão de perguntas e respostas
7. Próximas atrações
-
falar sobre o progresso em direção ao(s) objetivo(s) da release e do trabalho por vir nos próximos sprints
8. Fist-of-Five voltado a melhoria
-
levar a audiência no review a dar feedback
9. Fechamento
Conclusões
Um review de alto impacto provoca uma sensação muito positiva de bem estar. Apesar da pressão por resultados para o review ser maior sobre o Product Owner e a equipe, um gerente de projetos ágeis também tem papel fundamental.
As equipes costumam ficar presas na pressão do dia-a-dia e acabam deixando de lado a preparação do review, o que representa um antipadrão. Uma sugestão para evitar que isto aconteça é reservar tempo suficiente para a preparação do review no planejamento do sprint, ao mesmo tempo em que, conforme se chega ao fim do sprint, é útil lembrar a equipe de que é chegado o momento de consolidar seus trabalhos.
Lembre-se que o review também representa um ponto de checagem de qualidade pela equipe. Não há nada como demonstrar o trabalho realizado para trazer uma boa dose de realidade para os esforços da equipe. Isto traz à tona problemas como ambientes que não funcionam, integrações que não foram feitas e interações esquecidas.
Espero que este artigo tenha inspirado os gerentes de projetos ágeis a tomar para si a responsabilidade sobre os reviews e fazer deles o evento mais poderoso para equipes ágeis. Apesar de ser certamente responsabilidade da equipe preparar e realizar o review, pode-se influenciar suas atitudes e abordagens. Pode-se também ampliar o feedback positivo à medida em que se melhora.
Para mais informações, o material desta apresentação (em inglês) foi disponibilizado no evento 2012 Atlanta Scrum Gathering.