O que é a Retrospectiva Espinha de Peixe (Ishikawa)?
A Retrospectiva Espinha de Peixe (Ishikawa) ajuda sua equipe a encontrar as causas raiz de um problema em vez de tratar só os sintomas. Ela se baseia no diagrama de causa e efeito que Kaoru Ishikawa popularizou na década de 1960, que organiza as possíveis causas em um formato parecido com o esqueleto de um peixe. Neste modelo, sua equipe passa por seis categorias de causas: Sistema, Processo, Formulários, Pessoas, Políticas e Local. Analisar uma categoria de cada vez faz as pessoas irem além da primeira explicação que vem à cabeça, e assim também aparecem causas que estão fora da área de atuação de cada um. Ela é mais útil para problemas com vários fatores envolvidos, quando uma solução óbvia já não funcionou. Organizar as causas em categorias mostra como elas se relacionam, e isso indica qual mudança vai fazer mais diferença. Um diagrama espinha de peixe (também chamado de diagrama de Ishikawa ou diagrama de causa e efeito; os três nomes se referem à mesma ferramenta) coloca o problema na "cabeça" do peixe e desenha as principais categorias de causas como espinhas que saem da coluna central. Na sua forma original, usada na indústria e na gestão da qualidade, essas categorias são os "6 Ms": Mão de obra (pessoas), Método (processo), Máquina (equipamentos), Material (insumos), Medição (dados e métricas) e Meio ambiente (o contexto ao redor). A equipe levanta possíveis causas em cada espinha e continua perguntando "por quê?" para seguir cada ramificação até a causa raiz. As categorias deste modelo adaptam os 6 Ms para equipes de software e de trabalho do conhecimento. A técnica é a mesma; só os nomes mudam para combinar com o trabalho que vocês fazem. Se o problema na cabeça do peixe for "as entregas sempre atrasam", uma causa em Pessoas pode ser "o principal revisor virou um gargalo", uma causa em Processo pode ser "não existe definição de pronto" e uma causa em Sistema pode ser "pipeline de CI instável". Mapear as causas dessa forma evita que a equipe corrija um sintoma e deixe passar o que realmente está por trás do problema.
Formato de retrospectiva Espinha de Peixe
Sistema
Quais tecnologias, softwares ou ferramentas podem estar afetando o desempenho ou os resultados da equipe?
Analisem a infraestrutura técnica, as ferramentas de software e os pontos onde os sistemas se conectam. Pergunte sobre falhas técnicas evidentes e também sobre as formas mais sutis como os sistemas interagem e atrasam o trabalho.
Processo
Quais fluxos ou sequências de atividades estão causando atrasos ou ineficiências no trabalho?
Procurem gargalos, etapas duplicadas e lacunas nos fluxos de trabalho. Perguntar sobre etapas específicas de como o trabalho é feito ajuda a equipe a separar problemas de processo de outras causas.
Formulários
Quais problemas nos modelos ou na documentação podem estar prejudicando a clareza ou a precisão?
Analisem os modelos e a documentação. As pessoas conseguem encontrar o que precisam, as informações estão completas e cumprem seu papel? Incluam documentos informais além dos formais.
Pessoas
Quais fatores ligados a habilidades, comunicação ou papéis estão afetando nosso sucesso?
Falem sobre habilidades, comunicação e papéis sem buscar culpados. Foquem nas condições em torno das pessoas, como papéis pouco claros ou silos de conhecimento, e não em criticar indivíduos.
Políticas
Quais diretrizes ou regras podem estar desalinhadas da prática ou criando dificuldades?
Analisem as regras escritas e não escritas que afetam o trabalho. Perguntem se cada política ainda apoia a forma como a equipe trabalha hoje ou se atrapalha.
Local
Quais aspectos do espaço de trabalho físico ou virtual podem estar afetando a colaboração ou a produtividade?
Considerem o espaço de trabalho físico e virtual, incluindo as ferramentas, o layout do escritório e o quanto a colaboração remota funciona bem.
Quando utilizar esta análise retrospectiva
- Quando um problema provavelmente tem mais de uma causa
- Depois de um problema sério que precisa de uma análise estruturada antes que alguém proponha uma solução
- Quando a equipe vive corrigindo sintomas e o problema sempre volta
- Em post-mortems de projetos ou revisões de incidentes, para evitar que a mesma falha se repita
Perguntas sugeridas para quebra-gelo
- Se a nossa equipe fosse uma máquina, qual peça mais precisaria de manutenção agora?
- Qual foi a solução mais surpreendente que você já encontrou para um problema recorrente?
Quer um exercício de aquecimento que sua equipe faça, e não apenas responda em voz alta? Veja quebra-gelos gratuitos →
Ideias e dicas para sua reunião de retrospectiva
- Escrevam uma descrição clara do problema na cabeça do peixe antes de qualquer pessoa adicionar uma causa
- Garantam que todos adicionem causas em todas as categorias, inclusive nas que estão fora da própria função
- Deixem as soluções para depois que as causas estiverem mapeadas
- Usem os Cinco Porquês dentro de cada categoria para ir além da primeira resposta
- Registrem todas as causas, mesmo as que parecem pequenas no início
- Reservem de 90 a 120 minutos para cobrir bem as seis categorias