Retrospectiva: ganhando maturidade nesse evento de melhoria

Este post não tem tags.

Compartilhe:

Não importa o método adotado pela sua organização, a Retrospectiva faz parte da agilidade.

Algo que os Métodos Ágeis trouxeram foi a melhoria contínua sendo realizada em ciclos curtos.  É inclusive um dos princípios do Manifesto Ágil:

Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.
(Beedle et al., 2001)

Diversos métodos trouxeram pontos específicos onde este princípio pudesse ser instanciado e torna-se algo prático. Boa parte deles criou um evento de retrospectiva. No Scrum é a cerimônia de Retrospectiva da Sprint. No Kanban, começa com a Retrospectiva do Time, porém, se necessário podem ser realizadas retrospectivas com mais de um time como a Revisão do Fluxo ou a Revisão de Entrega de Serviço. Depende do nível de maturidade e necessidade da organização.

Algo que é sempre importante frisar é que esse evento de retrospectiva não deve ser o único ponto de melhoria. Caso o time perceba que algo pode ser melhorado entre uma retrospectiva e outra, tal melhoria deve ser realizada antes da próxima reunião. O evento é uma forma de “forçar” o time a sair da rotina diária e pensar em como pode melhorar a sua forma de trabalho.

A inspiração para este artigo veio após uma conversa no Rio Scrum Gathering 2023. Gostaria de lembrar o nome do meu interlocutor. Caso você esteja lendo este artigo entre em contato comigo (pistas: homem, branco, trabalha em uma companhia de seguros).

Como não fazer retrospectivas 

Antes de falar sobre como fazer retrospectivas, gostaria de colocar algumas formas que são comuns, porém ineficientes. A ideia não é uma crítica, mas prover alguns insumos que te ajudam a verificar se estamos diante de alguma disfunção.

Não fazendo

A primeira forma de como não fazer uma retrospectiva é… não fazendo. Times com altíssima maturidade podem incluir no fluxo deles a melhoria contínua e sendo assim, deixam de ter um evento específico. Entretanto, sejamos sinceros, poucos times conseguem tal feito. Na prática, é tão fácil ficarmos imersos no dia a dia de trabalho, tarefas, ligações, mensagens e e-mails, que nunca paramos para olhar como podemos melhorar nossas vidas.

Se um time não faz a pausa “forçada” para a melhoria, nada melhora. Muito pelo contrário, tudo tende a piorar. Como um buraco na rua. Se ninguém consertá-lo, ele se transformará em uma cratera.

Fazer por fazer

Diversos times seguem frameworks, métodos e processos sem compreender os porquês de cada coisa. Fazem de forma robótica, pois em algum lugar está escrito que deve ser feito. De X em X dias paramos um monte de gente. Eles se reúnem em uma sala e saem de lá sem nada resolvido. 

Veja que o final do princípio 12 do Manifesto Ágil é: “… e então refina e ajusta seu comportamento de acordo.” Se não há refinamento e ajustes, um happy hour seria mais relevante do que essa retrospectiva mecânica. 

Retrospectiva Zero Ação 

Dia 7 de janeiro fizemos uma retrospectiva e achamos que o pior problema é a falta de acesso à publicação de conteúdo. Dia 21 de janeiro fizemos uma retrospectiva e achamos que o pior problema é a falta de acesso à publicação de conteúdo. Já estamos no dia 29 de agosto, fizemos uma retrospectiva e continuamos achando que o pior problema é a falta de acesso à publicação de conteúdo.

Os meses se passaram e nada foi feito. A retrospectiva sem resultado é ineficaz. Mais cedo ou mais tarde alguém vai questionar o que estamos fazendo aqui se nada é feito em relação ao pior problema.

Vejamos o que o Guia do Scrum diz sobre isso:

O Scrum Team identifica as mudanças mais úteis para melhorar sua eficácia. As melhorias mais impactantes são endereçadas o mais rápido possível. Essas podem até ser adicionadas ao Sprint Backlog para a próxima Sprint. 
(Ken Schwaber e Jeff Sutherland, 2020, p.11)

Já o Kanban:

A iteração termina com a entrega do software funcional e uma reunião retrospectiva para discutir futuras melhorias e ajustes de processo.
(David J. Anderson, 2011, p. 138, tradução do autor)

Independente do que seu time utilize, sair de uma retrospectiva sem pelo menos uma ação de melhoria não é aceitável. A identificação do problema é parte da retrospectiva, mas não é uma saída dela.

Processo simples com entrada, processamento e saída. Na entrada temos métricas, fluxo de trabalho, bloqueios e problemas percebidos. O processamento é a retrospectiva que tem identificação de problemas e priorização de pontos de melhoria. A Saída tem as ações de melhorias com pessoas responsáveis indicadas em cada uma delas.
Entradas e saídas da retrospectiva

Muita animação, mas pouca solução

Ao longo do tempo, as pessoas ficaram criativas com relação às retrospectivas. Tem de tudo: dinâmicas, questionários, desenhos e até dramatizações. Eu gosto muito de reuniões dinâmicas, participativas e divertidas, mas só isso não resolve problemas. 

A retrospectiva tem que ser pragmática. Se ao final dela não soubermos quais os problemas e como resolvê-los, não passou de um momento de descontração. Estes são importantes, mas não podemos chamá-los de retrospectiva.

Retrospectiva Longa

Nada mais chato do que ficar horas e horas discutindo um monte de coisas. A retrospectiva não deve ser algo entediante. Se a sua cadência de retrospectiva for enorme, por exemplo, mensal, é provável que ela demore muito. Afinal, muitas coisas precisam ser tratadas. Quanto menor a cadência, mais curta será a reunião. Eu, Avelino, prefiro que não ultrapasse o limite de 2 horas. Em ciclos gigantes no máximo 4 horas e com muita habilidade do facilitador.

Retrospectiva com sala abarrotada

Times muito grandes requerem muito esforço de coordenação. É um problema matemático muito bem definido pela Lei de Brooks sobre nós de comunicação, logo não há uma solução de contorno verdadeira para o problema. 

Lei de Brooks sobre a quantidade de canais de comunicação possível em uma reunião com uma quantidade N de pessoas. Quanto mais pessoas, mais canais de comunicação. Exatamente igual a N x [(N-1)/2] conexões possíveis. Falamos mais sobre isso nesse artigo.
Lei de Brooks sobre a quantidade de canais de comunicação possível em uma reunião com uma quantidade N de pessoas. Quanto mais pessoas, mais canais de comunicação. Exatamente igual a N x [(N-1)/2] conexões possíveis. Falamos mais sobre isso nesse artigo.

Caso você esteja em times com muitos nós de comunicação, você terá que exercitar bastante seu poder de facilitação. Muito provavelmente com a divisão do timão (não estou falando do Corinthians 😃) em grupos menores para discussões e retornando apenas os resultados para o grande time.

Retrospectiva com pessoas externas

A retrospectiva é um momento de discussão de problemas. Alguns desses problemas são fraquezas internas e a maioria das pessoas não se sentem confortáveis em compartilhá-las com pessoas que desconhecem. Fazer retrospectiva acompanhado dos “ores” (diretores, gestores, auditores, coordenadores…) não ajudará muita coisa.

Retrospectiva sem as pessoas certas

O extremo oposto disso é fazer retrospectiva sem que as pessoas-chave para que a melhoria aconteça estejam lá. Saímos cheios de soluções idealizadas que, porém , nunca serão concretizadas, pois esquecemos de “combinar com os russos”.

Retrospectiva Arquivo X

“A verdade está lá fora” era o lema do seriado Arquivo X (The X-Files) produzido pela Fox entre 1993 e 2018. Em nossos times isso acontece quando todas as ações pensadas para resolver o problema dependem única e exclusivamente de pessoas externas, muitas das vezes, inacessíveis. Por exemplo: Para resolver o problema X, precisamos que a diretoria da organização com 10.000 funcionários mude a sua forma de atuar. Ou então, precisamos adquirir uma nova ferramenta de R$100.000, sendo que a alçada responsável por fazer tal solicitação está a três níveis acima do time.

Veja bem. Não estou dizendo que não seja necessário por vez ou outra ir “lá fora” para buscar uma solução. Tal desafio não é incomum. Entretanto um alerta é necessário, pois essa solução externa pode ser utilizada como bengala para não promovermos nenhuma ação de melhoria. As perguntas que o time poderia fazer são: Partindo do princípio que não podemos mudar a forma de trabalho dos diretores e diretoras, o que podemos fazer? Há ferramentas gratuitas? Há outras formas de resolver o problema sem termos que ir até o agente externo? Normalmente tais soluções internas acabam aparecendo e descobrimos que “A verdade está aqui dentro” também.

Como fazer a retrospectiva

Alguns elementos são importantes para uma retrospectiva. A ideia dessas próximas linhas não é criar um passo a passo, mas apenas elencar pontos de atenção para que o time tenha um momento produtivo.

Descobrindo o problema

Essa é a etapa mais importante da retrospectiva. Se não sabemos o que temos que resolver, corremos o risco de criarmos uma solução para um problema que não existe. Ou, como prefiro dizer, responder perguntas que não foram perguntadas.

A inteligência coletiva não é a melhor fonte de problemas

É comum que nesse momento os facilitadores façam um momento de levantamento de problemas utilizando a inteligência coletiva das pessoas presentes. Acho bacana, mas tem um grande problema nessa estratégia. Em seu livro Mentes Manipuladas, Brian B. Wachler comenta sobre diversos problemas de percepções que temos ao longo da vida. Não farei um resumo deles, mas colocarei alguns que acredito serem relevantes para a minha tese.

  1. foco no que causou maior espanto;
  2. foco nos acontecimentos mais recentes;
  3. concordamos com amigos para fazer parte da tribo;
  4. buscamos espaços seguros.

Por que é um problema confiarmos em nosso sentimento quando analisamos problemas: 1) O que causa mais espanto pode não ser o pior problema de todos, apenas aquele que mais nos chamou atenção. 2) Se estamos falando de longas cadências de retrospectivas, o que aconteceu há dois dias receberá muito mais atenção do que aquilo que aconteceu há duas semanas. 3) Nós somos seres sociais e queremos fazer parte da tribo, nosso time, logo existe um comportamento natural em nós em evitar conflitos e agir em conformidade com o grupo, mesmo que isso seja contrário àquilo que acreditamos. 4) Entre resolver um problema dificílimo, mas fundamental e resolver um fácil que nos dará um ganho marginal, tendemos a poupar esforço e ir para o mais fácil, mesmo que o ganho seja irrelevante. 

As melhores fontes de problema

Bom, então, de onde devem vir os insumos dos problemas que devem ser tratados na retrospectiva? métricas!

Nós da K21 sempre olhamos para a agilidade nesses 4 domínios. Neles temos também os 4 Domínios das Métricas. Você deveria olhar para as métricas, os fatos, antes de começar uma retrospectiva. Na verdade, o time inteiro deveria olhar para as métricas antes de começar uma retrospectiva. 

Os quatro domínios da agilidade com suas métricas. Negócio (Eficácia) com ROI, Faturamento, Cost of Delay, Fatia de Mercado, Retenção e Aquisição. Cultural (Ecossistema) com Turnover, Radar da Satisfação, Health and Check e eNPS. Organizacional (Eficiência) com as métricas de fluxo, Customer Lead Time, Taxa de Entrega, Bloqueio e Aging e, por fim, Técnica (Excelência) com Reclamações, Devoluções, Percentual de Automação e Quantidade de Treinamentos.
Exemplos de métricas nos 4 domínios da agilidade.

Qual é o problema: O produto não está vendendo? As pessoas estão cancelando o serviço? A Satisfação da Equipe está caindo? O nosso Customer Lead Time está aumentando? A taxa de entrega está caindo? Estamos tendo muitas reclamações? As métricas deveriam apresentar o problema e o “tamanho do buraco” em que vocês estão. Sem elas, tudo o que temos são feelings (sentimentos) e até onde eu sei, apenas Morris Albert ganhou dinheiro com feelings.

Entretanto, não desconsidere a inteligência das pessoas

Algumas informações não são “traduzidas” por métricas. Sempre haverá algum espaço para a subjetividade e a narrativa das pessoas. Por exemplo, problemas de comunicação. Dificilmente você estará contando quantas ligações não foram retornadas ou quantos e-mails não foram respondidos.

Priorizando o problema

É comum termos mais de um problema para tratar em uma retrospectiva. Reclamações do cliente e perda de eficiência, por exemplo. Tentar resolver tudo é muito difícil. Como diz o meu amigo Luiz (Lula) Rodrigues: “Tudo é muita coisa”. Até a próxima retrospectiva você terá que continuar construindo e evoluindo seu produto ou serviço, além de implementar as melhorias que discutirão nessas reuniões. Logo, precisamos priorizar. 

Aqui, mais uma vez, é comum o uso da inteligência coletiva. Ela não é de todo ruim, mas é mais importante vermos qual é o caminho traçado na estratégia da empresa. Utilizando o exemplo anterior, se ela tem algum KPI ou OKR estratégico que mede a satisfação do cliente e nenhum falando sobre a eficiência de entrega, é melhor priorizar o problema de reclamações do cliente. Não significa que não olharemos o problema de ineficiência, apenas que o olharemos quando a situação for mais apropriada. A estratégia da organização e das demais unidades na hierarquia da empresa devem ser um direcionador da priorização.

Plano de Ação

Toda reunião de retrospectiva deve terminar com pelo menos uma ação de melhoria. Eu não saberia precisar um número máximo, mas não devem ser muitas. Zero é uma reunião improdutiva e muitas é igualmente improdutiva, pois nenhuma será feita. Para manter o foco, tente aquela que o seu time prevê ganhar o maior resultado. Uma ação bem-feita é melhor que um plano elaborado não feito.

O prazo de execução dessas ações não deve ultrapassar a próxima retrospectiva. Caso contrário, elas tendem a não ser realizadas.

Responsabilidade

Toda ação tem um responsável. Antes que você pergunte, sim. Uma ação pode contar com a participação de diversas pessoas. Entretanto ela tem uma pessoa responsável e somente uma. Cuidado ao escolhê-la. Se o critério for: a pessoa menos ocupada do time. Podemos estar colocando na mão de uma pessoa que não tem a vontade ou o poder para realizar e/ou coordenar a ação. Deveria ser alguém engajado com o problema. Preferencialmente, que seja diretamente impactado por ele. 

Medindo se o problema foi resolvido

Lembre-se, estamos fazendo a melhoria contínua. Você não saberá se melhorou caso não meça o resultado de suas ações. Essa medição pode começar a ser feita assim que começarmos a ação ou até mesmo após a implementação dela. Os efeitos poderão ser imediatos (ações pontuais). Entretanto, ações estruturais que provocam mudanças sistêmicas tendem a ter seus efeitos percebidos no longo prazo. De fato, nestas últimas é possível que aconteça um período de queda. Antes da melhoria ser sentida.  

Nesse caso, entre a ação de melhoria e a validação de seu efeito, tivemos 4 semanas (entre 3 e 7).
Nesse caso, entre a ação de melhoria e a validação de seu efeito, tivemos 4 semanas (entre 3 e 7).

Espero ter ajudado a criar retrospectivas eficazes.

Para saber mais sobre retrospectivas e facilitação, continue acompanhando nosso blog.

Quer se tornar um Scrum Master? Inscreva-se nos nossos treinamentos de Certified Scrum Master!

Sobre o autor(a)

Trainer na K21

Avelino Ferreira é formado e mestre em Ciência da Computação. Teve uma longa trajetória na TI, começando como programador e chegando a gestor de diversos times de criação de produtos digitais. Conheceu e começou a adotar as melhores prática de de Métodos Ágeis em 2008. Desde então, se dedica a auxiliar outras empresas na construção da cultura ágil. Atualmente, é Consultor e Trainer na K21

Artigos relacionados

Após terminar de ler o livro Ruído de Daniel Kahneman, decidi reler alguns clássicos que não olhava há algum tempo. Dentre eles, Rápido e Devagar do mesmo autor e Pensando em Sistemas de Daniela Meadows. Não pude deixar de perceber…

O Guia do Scrum fala sobre o refinamento do Product Backlog: “O Product Backlog é refinado conforme necessário” (p. 9). Todavia ele não descreve exatamente o que é o refinamento. Uma reunião, uma atividade, um processo. Neste artigo vamos jogar…

Marcos Garrido, Sócio-fundador e Trainer na K21

Existem muitas formas de organizar as métricas de seu produto / empresa. Aqui neste blog já escrevemos sobre as Métricas do Pirata, Fit For Purpose (F4P) e Métricas nas Quatro Áreas de Domínio da Agilidade. Todavia, agora, queremos falar sobre…

Após alguns anos desenvolvendo produtos e ajudando outras empresas a fazer tal, gostaria de listar com vocês alguns erros comuns que percebi ao longo dessa jornada. Olhando para as 4 Áreas de Domínio da Agilidade (Negócio, Cultural, Organizacional e Técnica)…