Como o Scrum Team inspeciona sua forma de trabalho, aumenta a qualidade e a eficácia, melhora pessoas e interações, adapta processos, ferramentas e a Definition of Done e transforma reflexão em melhoria contínua.
Tempo estimado de leitura: 25 minutos
Por João Ricardo Dutra••Artigo completo
Objetivo do capítulo
Ao final deste capítulo, você deverá compreender o propósito da , o que o inspeciona, como a qualidade e a eficácia podem ser aprimoradas, como a pode evoluir, como melhorias significativas são selecionadas e implementadas e por que a se concentra no produto, enquanto a se concentra na maneira como o trabalha.
Introdução: um time que nunca se inspeciona acaba repetindo os próprios problemas
O não pressupõe que um time se torne eficaz uma vez e permaneça eficaz para sempre. Ele cria um momento recorrente em que o inspeciona a si próprio e melhora deliberadamente a forma como trabalha.
Um produto pode melhorar após enquanto o sistema que cria esse produto, silenciosamente, piora. acumulam etapas manuais frágeis. Reuniões se multiplicam. A aumenta. As conversas com o se tornam apressadas. Os testes são empurrados para mais tarde. Um único especialista se transforma em gargalo. Os integrantes do time deixam de questionar premissas frágeis. A acontecendo, mas o custo de cada mudança futura aumenta.
A existe para evitar essa deterioração gradual e para criar algo mais ambicioso: . O Scrum Guide atual define seu propósito como planejar maneiras de aumentar a qualidade e a eficácia. O inspeciona como ocorreu a última no que diz respeito a indivíduos, interações, processos, ferramentas e à . O time identifica premissas que contribuíram para problemas, investiga suas origens, discute o que funcionou bem e o que não funcionou e escolhe as mudanças mais úteis para melhorar sua eficácia.
Essa ideia tem raízes profundas no pensamento . Um dos doze princípios por trás do afirma que os times devem refletir regularmente sobre como se tornar mais eficazes e, então, ajustar e aperfeiçoar seu comportamento. O transforma esse princípio em um evento formal e recorrente ao final de cada .
A , portanto, não é uma sessão de reclamações, um exercício de moral do time nem um ritual de post-its. Seu propósito é a adaptação. A reflexão só importa porque pode melhorar a próxima forma de trabalhar. Um time que identifica o mesmo problema em todas as Sprints, mas nunca altera o sistema, está realizando análise sem promover melhoria.
O evento também precisa ser distinguido da . Ambos inspecionam e adaptam, mas inspecionam coisas diferentes. A inspeciona principalmente o resultado do produto, o ambiente do produto, o progresso em direção ao e o que deve acontecer em seguida. A inspeciona principalmente o sistema de trabalho do : pessoas, interações, processos, ferramentas, práticas de qualidade, premissas e a .
Para candidatos à , essa distinção é fundamental. Questões do exame frequentemente misturam os eventos: stakeholders avaliando o desempenho do time em uma Retrospective, o discutindo mudanças de mercado em vez de suas práticas de trabalho, ou melhorias de processo sendo adiadas porque "não são trabalho de produto". Um modelo mental sólido evita esses erros: a Review pergunta como o produto e o ambiente devem alterar futuras decisões de produto; a Retrospective pergunta como o deve mudar a si próprio para se tornar mais eficaz.
O propósito oficial: aumentar a qualidade e a eficácia
O propósito da é planejar maneiras de aumentar a qualidade e a eficácia. Essas duas palavras definem um escopo amplo para o evento.
Qualidade inclui a qualidade do , as práticas que a protegem e os padrões representados pela . Se defeitos escapam repetidamente, os testes acontecem tarde demais, o feedback de segurança chega com atraso ou a integração é difícil, esses problemas pertencem à Retrospective porque afetam a capacidade do de criar um utilizável e de alta qualidade.
Eficácia é mais ampla do que produtividade. Um time pode estar ocupado e ainda assim ser ineficaz. Pode concluir muitas tarefas sem atingir Goals, gastar grande quantidade de tempo coordenando dependências ou criar funcionalidades que exigem muito retrabalho. A eficácia pergunta se a forma de trabalhar do o ajuda a gerar resultados valiosos com qualidade, aprendizado, foco e sustentabilidade adequados.
O propósito não é simplesmente tornar o time "mais rápido". Às vezes, a eficácia aumenta ao reduzir o trabalho em andamento, fortalecer padrões de qualidade, envolver stakeholders mais cedo, melhorar o refinamento do , aprender uma habilidade ausente, automatizar uma etapa repetitiva ou tornar conversas difíceis mais diretas.
Como o é empírico, a eficácia não pode ser melhorada apenas por teoria. A Retrospective inspeciona a mais recente como evidência. O time estuda o que realmente aconteceu e usa essa experiência para decidir o que mudar a seguir.
Âncora para a
A planeja maneiras de aumentar a qualidade e a eficácia. Ela não é, primordialmente, uma reunião de status, uma reunião de moral do time ou uma demonstração do produto.
O que o inspeciona
O Scrum Guide apresenta cinco áreas amplas de inspeção: indivíduos, interações, processos, ferramentas e a . Os elementos exatos variam conforme o domínio, o que mantém o evento flexível sem perder seu propósito.
Área de inspeção
Exemplos do que pode ser examinado
Indivíduos
Habilidades, carga de trabalho, aprendizado, foco, clareza, comportamento profissional, senso de responsabilidade, confiança e capacidade de contribuir.
Interações
Colaboração, comunicação, conflitos, feedback, handoffs, contato com stakeholders, interação entre e e tomada de decisão do time.
Processos
Como o trabalho flui, planejamento, refinamento, testes, fluxo de release, práticas de revisão, tratamento de incidentes, dependências e políticas internas.
Ferramentas
Automação, sistemas de build, ferramentas de colaboração, ambientes de teste, observabilidade, dashboards, ferramentas de desenvolvimento e outros facilitadores ou restrições.
Se o limite de qualidade atual é suficiente, claro, alcançável e ainda sustenta transparência e qualidade do produto.
Essas categorias não devem se transformar em um checklist obrigatório. Uma pode exigir uma discussão profunda sobre um ambiente de testes instável. Outra pode revelar problemas de comunicação entre e . Outra pode mostrar que a já não protege adequadamente a qualidade operacional. O inspeciona aquilo que mais importa para sua eficácia no momento.
O Guide também orienta o time a identificar as premissas que o levaram a caminhos inadequados e a explorar suas origens. Isso é mais sofisticado do que perguntar apenas o que deu errado. Um evento pode ter falhado porque o time pressupôs que uma dependência estaria disponível, que um estava suficientemente compreendido ou que um único especialista conseguiria apoiar diversos itens críticos. Encontrar a premissa ajuda a evitar a repetição do problema.
Pessoas: melhorar o sistema sem transformar o evento em busca por culpados
As pessoas fazem parte do sistema e, portanto, são objetos legítimos de inspeção, mas a Retrospective não deve se tornar um tribunal de desempenho. O objetivo é aumentar a eficácia do , não identificar alguém a quem atribuir culpa.
O time pode discutir desequilíbrio de carga de trabalho, habilidades ausentes, atrasos recorrentes, evasão de trabalhos difíceis, colaboração fraca ou problemas de comunicação. A abertura profissional exige que comportamentos reais sejam abordados. O respeito exige que isso seja feito sem reduzir um problema complexo de sistema a um ataque pessoal.
Por exemplo, se um Developer se torna repetidamente um gargalo, a explicação imediata pode ser que ele "trabalha devagar demais". Uma inspeção mais profunda pode revelar que ele é a única pessoa autorizada a realizar deploy em produção ou a única que compreende uma integração crítica. O sistema criou concentração de conhecimento e autoridade.
A Retrospective é um espaço para perguntar o que tornaria o time mais resiliente: pairing, mentoria, ampliação de acessos, treinamento, automação, acordos de trabalho mais claros ou um modelo diferente de colaboração.
Algumas questões podem, de fato, envolver desempenho ou comportamento individual e exigir gestão organizacional além do . A Retrospective não substitui a gestão apropriada, processos de recursos humanos ou a responsabilização ética. Ela apenas não deve ser utilizada de forma inadequada como uma reunião disciplinar pública.
Interações: onde a eficácia do time frequentemente prospera ou fracassa
O trabalho complexo de produto depende de interação porque nenhuma pessoa possui todo o conhecimento necessário. A qualidade dessas interações influencia fortemente a qualidade do produto.
O pode inspecionar se os colaboram ou apenas dividem tarefas. O fornece contexto suficiente? Divergências técnicas são exploradas de maneira construtiva? As pessoas levantam riscos cedo? O promove ou se torna o centro de coordenação? Os stakeholders estão acessíveis?
As interações também tornam visíveis os . Openness aparece quando problemas podem ser discutidos antes de se tornarem crises. Respect aparece quando a discordância não se torna pessoal. Courage aparece quando alguém questiona uma premissa frágil. Focus aparece quando as conversas retornam aos objetivos compartilhados. Commitment aparece quando os integrantes ajudam o sistema como um todo a ter sucesso, em vez de proteger apenas suas atribuições individuais.
O trabalho remoto e híbrido pode criar questões adicionais de interação. As ferramentas assíncronas estão apoiando a colaboração ou substituindo conversas importantes? Diferenças de fuso horário estão criando filas ocultas? Algumas vozes estão sistematicamente ausentes das decisões?
Uma Retrospective deve produzir experimentos que melhorem a interação, e não aspirações vagas como "comunicar melhor". Uma melhoria concreta pode ser trabalhar em pairing em itens de alto risco, envolver o mais cedo no refinamento, criar um caminho de escalonamento para dúvidas urgentes de stakeholders ou alterar a forma como discussões de arquitetura são facilitadas.
Processos: inspecione como o trabalho realmente flui
Processos são as formas recorrentes pelas quais o trabalho flui pelo e pelo sistema ao seu redor. Muitos impedimentos graves se escondem nos processos porque, depois de se repetirem por tempo suficiente, passam a parecer normais.
O pode inspecionar como items são refinados, como a qualidade é incorporada, como dependências são tratadas, como incidentes interrompem o trabalho da , como código ou outros tipos de trabalho são revisados, como ambientes são provisionados ou como releases são realizadas.
A Retrospective deve se concentrar no fluxo real, e não em diagramas oficiais de processo. Uma política pode dizer que a revisão de segurança leva um dia, enquanto o time sabe que as solicitações permanecem seis dias em uma fila. O exige que o sistema real seja inspecionado.
A melhoria de processo frequentemente significa reduzir espera, handoffs, retrabalho ou trabalho em andamento desnecessário. Também pode significar acrescentar disciplina: refinamento mais robusto, testes antecipados, reconhecimento mais claro da incerteza ou uma melhor.
O deve ter cautela ao acrescentar processo toda vez que algo dá errado. Um novo checklist, aprovação, reunião ou template pode resolver uma falha e, ao mesmo tempo, aumentar permanentemente o overhead. O time deve perguntar se o mecanismo proposto elimina uma causa raiz ou apenas cria mais uma camada de controle.
Ferramentas: a tecnologia pode ampliar ou restringir a capacidade do time
Ferramentas são incluídas explicitamente na inspeção da Retrospective porque moldam a forma como o trabalho é realizado. Um pipeline de build lento, um ambiente de testes pouco confiável, uma plataforma de observabilidade deficiente, uma ferramenta de colaboração inadequada ou um processo manual de deploy podem reduzir a eficácia todos os dias.
Às vezes, os times normalizam a causada pelas ferramentas porque ela não faz parte de uma funcionalidade visível ao cliente. A Retrospective torna esse custo visível. Dez minutos perdidos em cada build, multiplicados por um time e por várias Sprints, podem representar enorme perda de capacidade de produto.
A melhoria de ferramentas ainda deve ser orientada a valor. Trocar uma ferramenta apenas porque uma nova opção está em evidência não é automaticamente uma melhoria. O time deve identificar uma restrição real e formular uma hipótese de melhoria.
A automação é especialmente poderosa quando altera a economia da qualidade. Testes automatizados, security scanning, criação de ambientes, deploy e observabilidade podem encurtar loops de feedback e tornar uma mais forte alcançável em todas as Sprints.
A ferramenta relevante também pode não ser técnica: um quadro de colaboração, registro de decisões, visualização de fluxo de trabalho, sistema de feedback de clientes ou repositório de conhecimento. O não define ferramentas obrigatórias; a eficácia determina o que importa.
A : um compromisso de qualidade que merece ser inspecionado
A é o commitment do e uma descrição formal do estado de qualidade necessário para que um trabalho faça parte do . A Retrospective a inclui explicitamente entre os elementos que o inspeciona.
Uma pode ficar desatualizada. Um produto pode adquirir novos requisitos de segurança. O risco operacional pode aumentar. A acessibilidade pode se tornar importante. O time pode automatizar um trabalho que anteriormente precisava ficar de fora do padrão. Um defeito recorrente pode revelar a ausência de um critério de qualidade.
O pode, portanto, considerar a melhoria da quando apropriado, desde que isso não entre em conflito com padrões organizacionais ou do produto. Se existirem padrões organizacionais, eles constituem um mínimo. Se vários Teams trabalham em um mesmo produto, todos devem cumprir a mesma .
Fortalecer a pode, inicialmente, reduzir a quantidade de escopo concluída em uma , porque mais trabalho é necessário para atingir Done. Isso não significa que a eficácia diminuiu. O estado do produto se torna mais transparente, trabalho oculto é reduzido e o risco futuro de qualidade pode diminuir.
Uma Retrospective também pode revelar que a é excessivamente complicada ou pouco clara. Melhorar não significa sempre acrescentar critérios; pode significar esclarecer, automatizar ou redesenhar a maneira como os critérios são atendidos, preservando o nível de qualidade exigido.
Melhoria da qualidade
A Retrospective pode levar a uma mais forte ou mais eficaz. Ela nunca deve ser usada para reduzir a qualidade apenas para fazer com que mais trabalho pareça concluído.
Da observação à causa raiz: explore premissas, não apenas sintomas
Uma Retrospective fraca coleta sintomas: "Os testes atrasaram". "Tivemos reuniões demais". "O time de API nos bloqueou". Uma Retrospective forte pergunta por que o sistema produziu esses sintomas.
Suponha que os testes tenham atrasado. Por quê? Talvez os dados de teste não estivessem disponíveis. Por que não estavam disponíveis? Um ambiente compartilhado era preparado manualmente. Por que a preparação era manual? Os controles de acesso nunca foram automatizados. Agora, a oportunidade de melhoria é diferente de simplesmente pedir que os testadores comecem mais cedo.
O raciocínio de causa raiz não deve se transformar em uma busca interminável por uma única causa perfeita. Sistemas complexos frequentemente apresentam várias causas que interagem entre si. O objetivo é encontrar uma mudança que seja ao mesmo tempo significativa e viável de testar.
A ênfase do Guide em premissas é útil aqui. Times agem constantemente com base em premissas: uma dependência estará pronta, um stakeholder compreende um requisito, uma estimativa reflete a complexidade, uma ferramenta é confiável ou um processo protege a qualidade. Uma Retrospective pode revelar quais premissas falharam e como produzir evidências mais cedo na próxima vez.
Isso transforma o trabalho retrospectivo de simples narrativa em aprendizado. O time não apenas se lembra da ; ele melhora seu modelo de como o próprio sistema se comporta.
Identifique as melhorias mais úteis - não a lista mais longa
O identifica as mudanças mais úteis para melhorar sua eficácia. Essa formulação desencoraja um anti-pattern comum: gerar vinte ideias de melhoria e não implementar nenhuma.
A exige foco. Um time deve selecionar um pequeno número de mudanças com impacto esperado significativo. A mudança deve ser clara o suficiente para que o time consiga observar se ela ajudou.
Uma melhoria pode ser comportamental, técnica, procedimental, organizacional ou relacionada à qualidade. Exemplos incluem reduzir o , criar testes automatizados de contrato, fazer pairing em uma habilidade crítica, envolver stakeholders mais cedo, alterar práticas de refinamento, fortalecer a ou escalar uma dependência sistêmica.
As melhorias de maior impacto devem ser tratadas assim que possível. Elas podem até ser adicionadas ao da próxima . A palavra podem é importante: o Scrum Guide 2020 não exige que toda melhoria se torne um item do . Os times podem utilizar o mecanismo que tornar a melhoria real e transparente.
Esse foi um dos pontos simplificados em 2020. Versões anteriores do Scrum Guide eram mais prescritivas quanto à seleção de uma melhoria de processo de alta prioridade para a seguinte. O Guide atual oferece mais flexibilidade ao , preservando a expectativa de adaptação rápida.
Resultado da Retrospective
Uma Retrospective útil termina com um pequeno conjunto de mudanças significativas que o pretende colocar em prática - e não apenas com uma coleção de observações.
: a melhoria precisa sobreviver à reunião
A falha mais comum das Retrospectives não é uma facilitação ruim. É a incapacidade de implementar aquilo que o time aprendeu.
Times podem criar excelentes quadros, votar nos problemas mais importantes e sair da reunião motivados. Uma semana depois, o trabalho cotidiano consome toda a atenção e a melhoria desaparece. Na Retrospective seguinte, o mesmo problema é identificado novamente.
Um profissional trata a melhoria como parte da eficácia do produto, e não como trabalho opcional a ser feito somente quando sobra capacidade. Se uma mudança é importante o bastante para melhorar qualidade, confiabilidade, fluxo ou colaboração, ela merece atenção real.
O time deve tornar a melhoria observável. Quem precisa colaborar? O que mudará? Quando começará? Que evidência indicará se a mudança ajudou? Um experimento pode ser pequeno: durante uma , limitar PBIs ativos, fazer pairing em um gargalo, alterar a cadência de refinamento ou automatizar uma verificação de qualidade.
Na Retrospective seguinte, o time pode inspecionar a própria melhoria. Funcionou? Criou algum efeito colateral inesperado? Deve se tornar prática padrão, ser alterada ou abandonada? A também é empírica.
A responsabilidade pertence ao inteiro
A é um evento do - , e . Melhorar a eficácia não é uma responsabilidade delegada ao .
O serve ao ajudando-o a melhorar suas práticas dentro do e pode facilitar a Retrospective. Entretanto, um time que espera que o identifique todas as melhorias ainda não assumiu plenamente a responsabilidade por sua própria eficácia.
O faz parte do sistema de trabalho. Clareza do , acesso a stakeholders, direção do , disponibilidade para dúvidas e colaboração com podem afetar a eficácia. Portanto, o deve participar como integrante do , e não como um cliente externo avaliando o time.
contribuem com conhecimento sobre práticas técnicas, fluxo de trabalho, qualidade, colaboração e desafios de criação do . Eles devem ter autoridade e responsabilidade para melhorar essas práticas.
Uma Retrospective madura cria accountability coletiva: "O que vamos mudar?" em vez de "Quem a gestão deve consertar?". Algumas melhorias exigem ajuda organizacional, mas o continua responsável por tornar a necessidade transparente e buscar a adaptação.
vs. : produto vs. forma de trabalho
Dimensão
- Produto
- Forma de trabalho
Principal alvo de inspeção
Resultado do produto, , progresso em direção ao e ambiente.
Como o trabalhou durante a .
Principal alvo de adaptação
Futuras decisões de produto e .
Qualidade, eficácia, interações, processos, ferramentas e formas de trabalho.
Principais participantes externos
Stakeholders-chave colaboram ativamente.
O é o grupo central de participantes.
Pergunta central
Dado o resultado do produto e o ambiente, o que devemos fazer a seguir?
Dada a forma como trabalhamos, como podemos nos tornar mais eficazes?
Torna o transparente; a Review não é um gate de aceitação.
É explicitamente inspecionada e pode ser adaptada quando apropriado.
Posição na
Penúltimo evento.
Conclui a .
máximo para de um mês
4 horas.
3 horas.
Falha típica
Transforma-se em uma demonstração ou reunião de aprovação.
Transforma-se em sessão de reclamações ou ritual sem ação.
Memorize a distinção
-> inspeciona e adapta o produto. -> inspeciona e adapta a forma de trabalho do .
e posição na
A conclui a . Ela ocorre depois da e antes de a próxima começar com .
O evento possui máximo de três horas para uma de um mês. Para Sprints mais curtas, geralmente é mais curto. Três horas é um máximo, e não uma duração obrigatória.
Sua posição no final da é intencional. O acabou de inspecionar o produto com stakeholders na e agora volta o olhar para dentro, inspecionando seu próprio sistema de trabalho enquanto a experiência ainda está recente.
Uma nova começa imediatamente após a conclusão da atual. Portanto, as decisões de melhoria podem influenciar a seguinte imediatamente, sem aguardar uma revisão trimestral de processos.
A Retrospective oferece uma oportunidade formal de melhoria, mas a melhoria não se restringe a ela. Os times podem alterar uma prática ineficaz assim que descobrem uma abordagem melhor, desde que as e as restrições relevantes continuem sendo respeitadas.
Segurança psicológica, abertura e discordância produtiva
O Scrum Guide não prescreve uma técnica específica de segurança psicológica, mas Retrospectives úteis exigem abertura suficiente para que os problemas relevantes se tornem transparentes.
Se os integrantes do time temem punição por revelar erros, a Retrospective inspecionará uma versão higienizada da realidade. As pessoas discutirão assuntos seguros, enquanto as causas dos problemas reais permanecerão ocultas.
Os fornecem suporte comportamental. Respect torna possível separar pessoas de problemas. Courage sustenta a exposição de questões difíceis. Openness sustenta a transparência. Commitment sustenta a execução das melhorias. Focus evita que o time tente consertar tudo ao mesmo tempo.
Segurança não deve ser confundida com evitar discordâncias. Retrospectives eficazes podem conter conversas desafiadoras. Um Developer pode questionar a disponibilidade do . O pode questionar excesso de trabalho técnico em andamento. O pode questionar a dependência excessiva de facilitação. O padrão é uma discussão respeitosa, baseada em evidências e orientada à eficácia.
A facilitação pode ajudar a equilibrar as vozes. Brainstorming silencioso, affinity mapping, dot voting, timelines, perguntas estruturadas ou outras técnicas podem ser úteis. O não exige nenhum desses formatos; o método deve servir à transparência e à adaptação significativa.
Exemplo prático - Retrospective de um de confiabilidade de APIs
Imagine um responsável por uma plataforma de APIs de alto volume. O era melhorar a resiliência da autenticação durante picos de tráfego. Na , o time e os stakeholders inspecionaram um Done e evidências de produção. O produto melhorou, mas uma parte do rollout atrasou e vários trabalharam até tarde perto do fim da .
A se concentrou no produto: a latência melhorou, as taxas de erro mudaram, stakeholders forneceram feedback e o foi reordenado. Agora começa a , e o foco muda completamente.
O examina como a ocorreu. percebem que o ambiente de teste de carga ficou indisponível por dois dias. O observa que uma dependência de alto risco não havia sido discutida cedo o suficiente. O percebe que três especialistas trabalharam de forma independente até perto do fim da , criando pressão de integração.
Em vez de culpar o especialista de infraestrutura, o time explora as premissas. Eles presumiram que o ambiente de testes compartilhado estaria disponível sob demanda. Presumiram que a integração poderia esperar até os últimos dias. Presumiram que o especialista em segurança poderia apoiar dois itens paralelos sem se tornar um gargalo.
O time inspeciona seus . O ambiente é provisionado manualmente por outro departamento. Os testes de integração começam tarde demais. A validação de segurança depende de um único detentor de conhecimento. A atual exige validação de desempenho e segurança, mas o time ainda não construiu um fluxo de trabalho que torne esses critérios fáceis de atender continuamente.
Diversas melhorias são propostas. Uma é solicitar um ambiente de testes permanente. Outra é criar infrastructure as code para ambientes temporários de teste de desempenho. Outra é colocar dois em pairing com o especialista em segurança. Outra é iniciar os testes de integração desde os primeiros dias da .
Em vez de aceitar as quatro propostas, o seleciona as mudanças de maior impacto que consegue influenciar imediatamente: automatizar a criação do ambiente de teste de desempenho e fazer pairing no fluxo de validação de segurança. O trabalho de automação do ambiente é tornado visível no seguinte porque apoia diretamente a melhoria do time.
O time também inspeciona a . Os critérios continuam adequados; o problema não é que o padrão esteja alto demais, mas que o processo para atendê-lo seja manual demais. O time se recusa a enfraquecer a e, em vez disso, melhora sua capacidade de cumpri-la.
Na Retrospective seguinte, o time inspecionará se a automação do ambiente reduziu a espera e se o pairing reduziu o gargalo de segurança. A própria melhoria se torna um experimento empírico.
Esse exemplo mostra claramente a diferença entre Review e Retrospective. A Review perguntou se o resultado do produto de API criou valor e qual trabalho de produto deveria acontecer em seguida. A Retrospective perguntou por que o time vivenciou atraso e estresse e como seu sistema de trabalho deveria mudar.
Anti-patterns comuns de Retrospective
Anti-pattern
Por que enfraquece a Retrospective
Sessão de reclamações
Problemas são discutidos emocionalmente, mas nenhuma adaptação significativa é selecionada.
A mesma ação em toda
O time identifica repetidamente o mesmo problema, mas nunca implementa a melhoria.
"Hora da terapia" do
O evento depende inteiramente de um facilitador e não tem ownership do .
Retrospective de culpabilização
O time procura um indivíduo culpado em vez de melhorar o sistema.
Somente tópicos de processo
Qualidade, ferramentas, interações, pessoas e são ignoradas.
Sem
O é tratado como alguém de fora, embora faça parte do .
Avaliação de desempenho por stakeholders
Stakeholders externos usam o evento para avaliar indivíduos, reduzindo a abertura.
Melhorias demais
O time cria uma longa lista de ações que não pode implementar de forma realista.
Sem acompanhamento
As ações não se tornam visíveis e desaparecem quando a próxima fica movimentada.
Redução automática da
O time reduz a qualidade para facilitar a entrega, em vez de melhorar sua capacidade.
Formato ritualizado
A mesma técnica é repetida mecanicamente, mesmo quando deixa de gerar insight.
Somente aspectos negativos
Práticas bem-sucedidas e pontos fortes são ignorados, e o time perde aquilo que deveria preservar ou ampliar.
Armadilhas comuns da sobre
Armadilha
Interpretação correta segundo o
A se concentra no do produto.
Falso. A se concentra no resultado do produto; a Retrospective se concentra na qualidade e na eficácia do sistema de trabalho do .
Somente participam.
Falso. A é do :, e .
Stakeholders são participantes obrigatórios.
Falso. O é o grupo de participantes definido para o evento.
O é responsável por encontrar todas as melhorias.
Falso. O inspeciona e adapta coletivamente sua eficácia.
O deve facilitar toda Retrospective.
Falso. A facilitação pode variar; o é dono do propósito do evento.
Toda melhoria deve ser adicionada ao seguinte.
Falso. As melhorias de maior impacto são tratadas assim que possível e podem ser adicionadas ao .
A não pode ser discutida em uma Retrospective.
Falso. Ela é explicitamente um dos elementos inspecionados pelo .
A sempre pode ser enfraquecida se estiver reduzindo a velocidade da entrega.
Falso. Padrões de qualidade e requisitos organizacionais/do produto continuam devendo ser respeitados.
O evento serve principalmente para discutir o que foi bem e o que foi mal.
Incompleto. Seu propósito é planejar maneiras de aumentar qualidade e eficácia e identificar mudanças úteis.
Melhorias da Retrospective só podem ser implementadas na seguinte.
Falso. Melhorias podem ser tratadas assim que possível.
Uma de um mês exige uma Retrospective de três horas.
Falso. Três horas é o máximo; o evento pode terminar antes.
A ocorre depois da .
Falso. Ela conclui a .
Um framework de raciocínio para questões da sobre Retrospective
Propósito: a resposta planeja maneiras de aumentar a qualidade e a eficácia?
Alvo de inspeção: ela inspeciona indivíduos, interações, processos, ferramentas, premissas e a ?
Participantes: ela preserva a responsabilidade com o inteiro?
Melhoria: a resposta identifica mudanças úteis e trata rapidamente as melhorias de maior impacto?
: ela permite inspeção e fortalecimento/adaptação apropriados sem violar padrões?
Distinção da Review: a inspeção do resultado do produto permanece na e a inspeção das práticas de trabalho permanece na Retrospective?
: o está viabilizando a melhoria em vez de possuir todas as ações?
: o aprendizado se transforma em experimento ou mudança concreta em vez de permanecer apenas como discussão?
: o evento está dentro do máximo de três horas para uma de um mês?
Posição: a Retrospective conclui a antes de a seguinte começar?
Heurística rápida para o exame
Problema de produto e o que construir em seguida -> . Problema de time/processo/qualidade e como trabalhar melhor -> .
Conclusão: faz parte do sistema de produto, não é trabalho extra
A existe porque o próprio é um sistema complexo que precisa aprender. O sucesso do produto depende não apenas do que o time decide construir, mas também de quão eficazmente as pessoas colaboram, de quão rápido o feedback circula, de como a qualidade é protegida, de como as ferramentas apoiam o trabalho e de como o time adapta suas práticas.
Seu propósito formal é planejar maneiras de aumentar a qualidade e a eficácia. Para isso, o inspeciona indivíduos, interações, processos, ferramentas, premissas e a . Ele examina o que funcionou, o que gerou problemas, como esses problemas foram ou não resolvidos e quais mudanças têm maior probabilidade de melhorar o desempenho futuro.
A Retrospective pertence ao inteiro. não terceirizam a melhoria ao . O não é um cliente externo. O pode ensinar, fazer coaching e facilitar, mas o ownership coletivo é essencial.
Melhoria significativa exige foco. Um time não precisa de uma longa lista de itens de ação; precisa de algumas mudanças importantes o bastante para serem implementadas e transparentes o bastante para serem inspecionadas depois. As melhorias de maior impacto devem ser tratadas assim que possível e podem ser incluídas no seguinte.
A dá ao evento uma conexão direta com a qualidade do produto. Se o time descobre que os padrões de qualidade são insuficientes ou difíceis de cumprir porque seu sistema é frágil, a Retrospective oferece uma oportunidade formal para melhorar esse sistema. A resposta não é, automaticamente, reduzir o nível de qualidade.
A distinção em relação à continua sendo o modelo mental mais simples: a inspeciona o produto e o ambiente do produto; a inspeciona a forma de trabalho do . Uma adapta a direção do produto. A outra adapta o sistema que cria o produto.
Na minha visão, as Retrospectives revelam se uma organização realmente acredita em . É fácil inspecionar clientes e mercados. É mais difícil inspecionar a nós mesmos, admitir que um processo criado por nós é ineficaz e mudar nosso próprio comportamento. O transforma esse aprendizado desconfortável em uma responsabilidade recorrente. Times que levam isso a sério não se tornam apenas mais rápidos; tornam-se mais capazes de se adaptar, manter a qualidade e criar valor ao longo do tempo.
Principais conclusões
O propósito da é planejar maneiras de aumentar a qualidade e a eficácia.
O inspeciona indivíduos, interações, processos, ferramentas e a .
O time também identifica premissas que o levaram a caminhos inadequados e explora suas origens.
O discute o que funcionou bem, quais problemas encontrou e como esses problemas foram ou não resolvidos.
As mudanças mais úteis são identificadas para melhorar a eficácia.
As melhorias de maior impacto são tratadas assim que possível.
Melhorias podem ser adicionadas ao da próxima , mas o não exige que toda melhoria seja tratada dessa maneira.
A pertence ao inteiro.
O participa como integrante do ; o evento não é somente para .
O apoia a melhoria, mas não é dono de todas as ações de melhoria.
A é explicitamente inspecionada e pode evoluir quando apropriado.
A se concentra no produto; a se concentra na forma de trabalho do .
A conclui a .
Ela possui máximo de três horas para uma de um mês; Sprints mais curtas geralmente têm Retrospectives mais curtas.
