Sempre houve uma retrospectiva no final do ano na tv e eu quando criança achava aquilo o máximo, aí veio a agilidade e transformou a inspeção, transparência e adaptação em uma cerimônia que eu adoro!
Ao seguir práticas ágeis, alguns membros da equipe podem achar alguns processos redundantes – possivelmente porque eles não entendem sua importância. Um desses eventos é a retrospectiva, que é conduzida após cada revisão / demonstração do Sprint.
Uma vez que a equipe scrum comece a progredir no caminho da maturidade ágil, certas atividades são realizadas como uma formalidade para transmitir a adesão à mecânica ágil. Pode haver um equívoco aqui, já que a adesão a uma prática ou processo não é para um público maior, mas para o aprimoramento da equipe.
Normalmente, quando uma retrospectiva é conduzida, a equipe se concentra em três pontos principais:
1. O que foi bem?
2. O que não correu bem?
3. Existem melhorias ou melhores práticas que podem ser implementadas (ou o que a equipe pode fazer de diferente)?
Quando uma retrospectiva é conduzida, o scrum master precisa definir o palco adequadamente para que toda a equipe esteja envolvida. Eles devem colaborar para melhorar o desempenho, discutir como percebem as metas do Sprint e determinar se alcançaram o que se comprometeram.
Não se trata apenas de desempenho, mas de como a coordenação e a colaboração entre vários stakeholders tornaram o Sprint um sucesso ou um fracasso. As retrospectivas normalmente não são uma reunião post-mortem, em que a análise da causa raiz se destina a identificar gargalos e pontos de falha.
Em vez disso, são reuniões colaborativas voltadas para o futuro para refinar as ações a fim de se alinhar aos objetivos.
O papel do scrum master em alinhar a equipe com os eventos scrum é de suma importância para que a equipe não participe dos eventos por uma questão de adesão ao processo, mas sim como um meio de colaborar, melhorar, alcançar e comemorar.
Frequentemente, uma equipe age com pressa ao passar de uma demonstração / revisão de sprint para outra iniciação de sprint.
Mas retrospectiva é tarefa indireta!??
Uma retrospectiva costuma ser vista como uma tarefa indireta, em que a equipe entra com a intenção de terminá-la rapidamente para que possa se concentrar nas metas e resultados finais do próximo sprint.
Normalmente, os sprints são contínuos por natureza (a menos que ocorram em um fim de semana ou feriado). Idealmente, as retrospectivas são conduzidas no mesmo dia em que a revisão do sprint é concluída.
Às vezes, se as histórias confirmadas não são marcadas como “concluídas” (de acordo com a definição de “pronto”) devido a funcionalidade incompleta ou bugs imprevistos, elas são transportadas para o próximo sprint (a menos que o proprietário do produto troque a priorização delas em vez de novas histórias a serem desenvolvidas).
Uma reunião de planejamento para um próximo sprint seguido por uma retrospectiva pode prejudicar a reunião de retrospectiva do sprint anterior porque a equipe, o product owner e o scrum master estão com pressa para completar suas histórias inacabadas.
Aqui, o scrum master atua como uma ponte entre a equipe e o product owner para facilitar e guiá-los na condução da retrospectiva (especialmente quando as histórias estavam inacabadas no sprint que acabou de ser concluído).
O antipadrão das retrospectivas
Um antipadrão comum seguido pelos proprietários do produto é continuar o sprint mesmo depois de sua duração definida devido a histórias incompletas e a meta não ser totalmente cumprida. Uma sprint deve terminar após revisão ou expiração de sua duração.
Este é o aspecto mais importante em termos do primeiro pilar do scrum: transparência. Quando a meta da sprint não é alcançada por qualquer motivo, a equipe, o product owner e o scrum master têm que ser transparentes e declarar que foi uma sprint com falha – sem aumentar sua duração ou acarretar os bugs.
O aspecto mais importante de uma meta de sprint é permitir que a equipe e o product owner saibam que o plano de liberação pode precisar de ajustes se um impacto for considerado. Um ponto crucial a lembrar aqui é que a linha do tempo da sprint foi definida tendo em mente a complexidade e o esforço envolvidos para completar as histórias comprometidas em uma sprint com base na capacidade disponível (que normalmente é fixada entre as sprints).
Quando houver histórias inacabadas em sprints consecutivas se torna uma tendência, pode ser revisitado na reunião de retrospectiva – que pode revelar causas potenciais de falha de sprint e histórias inacabadas.
Essas causas incluem:
- Falta de compreensão da história;
- Teste impróprio ou bugs imprevistos que resultaram de mudanças sugeridas durante a execução da sprint;
- Critérios impróprios de sucesso / aceitação para as histórias em questão.
Lembre-se de que uma reunião retrospectiva é para melhorar, aprender, resolver problemas e celebrar as conquistas da equipe durante a execução e revisão da sprint; eles devem ter uma abordagem motivadora.
Mas quando é visto como apenas mais uma parte da mecânica ágil, pode deixar rachaduras dentro da equipe (e entre a equipe e o scrum master e o product owner; e entre o scrum master e o product owner). Não existe uma solução única para todos, mas as retrospectivas devem ser mais participativas – e direcionadas com uma mentalidade focada no crescimento e na inovação.
A retrospectiva: uma prática essencial para equipes ágeis
Conheci muitas equipes que não realizam retrospectivas – a parte inspecionar e adaptar – da abordagem ágil. Às vezes, as pessoas acham que o retrô vai demorar muito ou que não vão aprender rápido o suficiente.
O problema é que as equipes fazem a mesma coisa continuamente. Nada muda.
Costumo recomendar a abordagem de cinco etapas nas Agile Retrospectives: Making Good Teams Great de Derby e Larson, para qualquer equipe, ágil ou não.
- Prepare o cenário
- Colete dados
- Gere percepções
- Decida o que fazer
- Conclua a retrospectiva
Ou você também pode saber sobre as quatro perguntas mais tradicionais:
- O fizemos que foi bom?
- Onde falhamos?
- O que aprendemos?
- O que ainda nos intriga?
Como suspeito que você conheça essas abordagens de retrospectivas, usarei uma estrutura diferente aqui para mostrar como refletir rapidamente logo após realizar algum tipo de atividade.
Essa abordagem de reflexão é extraída do livro The Art of Focused Conversation: 100 Ways to Access Group Wisdom in the Workplace, de Brian Stanfield. Costumo usar essa estrutura quando faço um balanço das experiências dos alunos (por exemplo, em uma aula de treinamento ou quando facilito a retrospectiva provisória de uma equipe).
A estrutura é chamada de ORID, como em:
- O bter os dados
- R efletir sobre os dados
- I nterpretar os dados e fazer o que significa que a partir dos dados
- D ecidir o que fazer
Você pode usar uma estrutura ORID após o planejamento do backlog ou após as histórias de workshopping. Aplique-o a um período de tempo em que a equipe gastou mais de 20 minutos, mas menos de uma ou duas semanas de trabalho.
Obtenha os dados para definir o contexto
Cada pessoa experimenta os projetos de maneira diferente. Precisamos primeiro concordar com o contexto. Os dados nos ajudam a definir o contexto.
- Quais são os fatos?
- O que eu vi e ouvi?
- O que eu percebi?
- Existe história ou outros fatos?
- Existem palavras ou dados que se destacam?
Refletir sobre os dados
Quando refletimos sobre os dados, traçamos conexões entre dados díspares. Usamos nossas emoções para fazer essas conexões. Eu faço perguntas como estas para dados reflexivos:
- O que me surpreendeu?
- O que isso me lembra?
- Achei algo refrescante?
- O que me desafiou ou frustrou?
Interpretar o significado
Gosto de pensar que esta pergunta é o “E daí?” pergunta – o que os dados significam para mim? Que ações posso realizar ou que experimentos posso realizar com base nos dados? Aqui estão algumas perguntas interpretativas que uso:
- O que eu aprendi?
- O que mais eu quero explorar?
- Eu faria algo diferente?
- Que insights eu ganhei?
- Existem questões subjacentes que desejo abordar?
Decida o que fazer
Agora que aprendemos, é hora de decidir o que fazer a seguir. Quando eu facilitar a retrospectiva de uma equipe, muitas vezes eu peça às equipes para considerar o que uma coisa que eles vão colocar em prática. Aqui estão algumas perguntas de decisão que uso:
- Temos frutas ao alcance que seriam fáceis de considerar?
- O que usaremos como base para um experimento?
- Qual é o nosso próximo passo?
- O que vamos parar de fazer?
Não podemos fazer tudo – não ao mesmo tempo. Podemos escolher o que fazer e quando. Posso servir a alguns de vocês escrevendo sobre essas questões. Explorar essas questões pode expandir todo o nosso aprendizado e nossas práticas.
Então, ao aplicar o ORID, espero esclarecer algumas das preocupações que muitos de vocês têm sobre a abordagem ágil para o portfólio de projetos e roteiros de produtos.
Não negligencie as ações pós retrospectiva
Na busca pela melhoria contínua da equipe, identificar ações corretivas por meio de retrospectivas é apenas o primeiro passo. Essas ações precisam ser acordadas pela equipe, tornadas visíveis e rastreadas pelo Scrum Master, revisitadas na próxima retrospectiva e celebradas após a implementação bem-sucedida.
No entanto, aprendi por experiência própria que identificar ações corretivas em uma retrospectiva é apenas parte da batalha. Para garantir que a equipe obtenha todos os benefícios de suas ações propostas, elas devem ser gerenciadas de forma adequada.
Sem esse gerenciamento, ações corretivas valiosas podem se perder ou atrasar desnecessariamente e a equipe pode perder a fé no processo retrospectivo. O resultado final pode ser uma paralisação da melhoria contínua, o que é um desastre para uma equipe ágil.
Concordando com as ações
Inicialmente o ponto de partida para o gerenciamento de ações retrospectivas está na própria retrospectiva. Se a sessão foi bem-sucedida, no final haverá um conjunto de ações corretivas que foram identificadas por um ou mais membros da equipe.
Consequentemente o Scrum Master deve passar por cada ação por vez para confirmar que toda a equipe concorda que ela é válida.
Tendo em vista que uma ação válida é aquela que irá melhorar a produtividade da equipe sem incorrer em custos indevidos. A revisão das ações reforça sua importância e faz com que todos na equipe concordem que vale a pena implementá-las.
Além disso você pode descobrir que a equipe não consegue concordar sobre quais ações valem a pena serem realizadas. Se o debate chegar a um impasse, a votação por pontos pode ser usada para desfazer o impasse. A votação por pontos também pode ser útil se houver muitas ações corretivas para uma equipe realizar. A equipe pode usar a votação por pontos para priorizar as ações mais importantes para implementação de curto prazo.
Logo as ações de baixa prioridade para as quais a equipe não tem largura de banda podem ser descartadas por enquanto. Não se preocupe em perdê-los, pois, se tiverem valor, voltarão a surgir em retrospectivas futuras, quando puderem ser mais viáveis para implementação.
Quadro de ações pós retrospectivas
Nesse ponto, vi equipes criarem histórias para cada uma de suas ações que vão para o backlog do produto. Não faço isso porque as ações não são histórias. Em vez disso, são coisas que a equipe pode fazer para tornar o negócio de implementação de histórias mais rápido ou fácil. Eles podem representar documentação, mudanças no processo, ferramentas aprimoradas e assim por diante.
O que eles não são: funcionalidade para o usuário final. Eles não devem, portanto, ser priorizados com histórias.
Contudo, as ações corretivas precisam ir para algum lugar ou podem ser esquecidas e nunca implementadas. Como acredito que as ações das retrospectivas são tão importantes e sua implementação pode ser tão crucial para o sucesso de um projeto, eu as torno o mais visíveis possível usando um Quadro de Ações das Retrospectivas:
Analogamente um quadro de ações das retrospectivas é como um quadro de tarefas físicas, exceto que os cartões nele contêm as ações retrospectivas acordadas em vez de histórias. Uma vez que as ações que não foram implementadas residem na coluna To Do, aquelas em andamento estão na coluna In Progress e aquelas que a equipe executou estão na coluna Implemented.
Já que as ações não implementadas ficam bem na frente da equipe todos os dias, elas não podem ser esquecidas. Além disso, todos podem ver quais ações foram realizadas. Isso significa que a equipe pode ver um progresso real em direção à sua própria melhoria contínua.
Nesse sentido, a medida em que tornamos as ações visíveis, será que podemos garantir que elas realmente sejam percebidas? Cabe ao Scrum Master reforçar a mensagem de que qualquer membro da equipe pode escolher uma ação retrospectiva para implementação.
Afinal, a equipe concordou com as ações porque todos acreditavam que as ações tornariam o negócio de implementação de histórias mais rápido, fácil, simples, resultaria em menos bugs, etc. Não há nada de errado em um membro da equipe melhorar a capacidade da equipe de trabalho implementando ações enquanto, ao mesmo tempo, outros realizam esse trabalho implementando histórias.
Inicialmente, o Scrum Master pode ter que se envolver para garantir que o equilíbrio entre as ações e histórias permaneça ideal. Ter um limite de WIP na coluna Em andamento é uma maneira de fazer isso. No entanto, uma equipe auto organizada vai sempre encontrar um equilíbrio produtivo muito rapidamente e essa intervenção raramente será necessária.
Rastreamento eletrônico
Em outras palavras, o painel de ações retrospectivas é um poderoso radiador de informações para a melhoria contínua, mas não é tudo. Além do quadro físico, acho informativo manter um histórico eletrônico das ações com as quais a equipe concorda. Faço isso porque, com um fluxo constante de ações implementadas, a coluna Implementado no quadro se enche rapidamente e precisa ser limpa.
A história do que a equipe conquistou é então perdida. Além disso, o histórico pode registrar metadados sobre ações, como quando são identificadas e quando foram implementadas. Eu chamo isso de Rastreamento de Ações Retrospectivas e é representado por uma página no wiki da equipe, uma planilha no Gdrive etc..:
Em suma a página de rastreamento é um registro permanente de cada ação retrospectiva acordada e de seu estado atual. Você pode ainda adicionar um código de cores indica as ações que estão aguardando para serem implementadas (vermelho) ou foram implementadas (verde). Além de ter o registro de onde a ação foi implantada e em qual sprint e em qual sprint ela foi acordada.
Também é interessante registrar nos sprints quanto tempo a equipe leva para cumprir as ações (Sprint Lag). Se uma equipe de sucesso precisar de um lembrete da importância das retrospectivas e de seu progresso em direção ao aprimoramento, uma rápida revisão desta página irá tranquilizá-los.
Mas a página de rastreamento também é útil para identificar ações que não estão sendo realizadas. Se uma ação não for implementada por muitos sprints depois de ter sido acordada, vale a pena perguntar por quê. Pode ser que a ação esteja bloqueada. Uma ação bloqueada não é menos impedimento para o sucesso do projeto do que uma história bloqueada e pode exigir a intervenção do Scrum Master para facilitar sua remoção. Como alternativa, você pode descobrir que a ação está simplesmente obsoleta e que a equipe não acredita mais que sua implementação valha a pena. Nesse caso, e com a concordância da equipe, a ação pode ser retirada da página de rastreamento e do quadro de ações físicas.
Ação pós implementação
Finalmente, é importante fechar o círculo na próxima retrospectiva. O Scrum Master deve revisar a página Rastreamento de Ações Retrospectivas antes da retrospectiva para ver quais ações foram implementadas no último sprint. Eles devem usar essas informações na retrospectiva para comemorar o sucesso da melhoria contínua da equipe, ao mesmo tempo em que as histórias concluídas são comemoradas.
Uma vez que isso reforça para a equipe que eles estão cumprindo as ações acordadas antes de identificar outro conjunto. Isso ajuda a manter o fluxo de ações.
Conclusão
Concluindo, às vezes, ações retrospectivas podem ser negligenciadas. Eu mesmo fiz isso com uma crença anteriormente sustentada e incorreta de que as ações seriam simplesmente realizadas porque eram obviamente importantes.
No entanto, não é tão simples assim. As ações precisam ser totalmente acordadas, tornadas visíveis, sua conclusão ativamente encorajada e sua implementação bem-sucedida celebrada.
Somente com essas etapas em vigor uma equipe pode tirar o máximo proveito das grandes ideias que têm em retrospectivas.
