Olhar sobre o problema
Um dia você acorda se sentindo indisposto e seu corpo parece estar quente. Ao utilizar o termômetro você constata que está com 39º C, ou seja, febre. Sem pensar duas vezes você toma algumas aspirinas, a temperatura baixa e já melhor vai para o trabalho. Ao chegar lá você já está com dor de cabeça e a temperatura parece que voltou a subir. Toma mais alguns remédios, permanece um tempinho bem, só que em breve todos os sintomas voltam a aparecer.
A metáfora da febre pode ser aplicada aos projetos que construímos ao longo da nossa vida profissional. Quando trabalhamos juntos por muito tempo com uma equipe ou quando estamos desenvolvendo projetos de longa duração, problemas certamente surgirão. Assim como nosso corpo emite sinais de que algo não está bem (tosse, coriza, dor de cabeça, etc.), nosso ambiente de trabalho também emite sinais de que algo não está bem (excesso de burocracia, falhas constantes de comunicação, brigas, saída de pessoas, etc.).
Em ambos os casos, percebemos apenas os efeitos causados pelo problema e tentamos tratá-los sem uma análise mais profunda sobre a causa do mesmo. Ao fazer isso, temos resultados irrelevantes e o problema retorna em breve.
Na história contada no início do texto, o ideal é que um médico seja consultado para diagnosticar e tratar a origem da enfermidade. Já no ambiente profissional, várias pessoas estão envolvidas no problema e não há necessariamente um especialista com A Resposta. Vamos utilizar então a inteligência coletiva. A dinâmica da Causa Raiz procura justamente encontrar, dar transparência e permitir o tratamento da fonte do problema.
Preparação
Reúna todas as pessoas envolvidas no problema. O ideal é que esse grupo não seja tão pequeno que não gere discussão e nem tão grande que torne as discussões intermináveis. Recomendo algo entre 5 até 7 pessoas.
Essa é uma dinâmica bastante introspectiva, logo será longa. Reserve pelo menos duas horas com o time. Providencie o material (quadro branco, post-it e canetas) e leve todos para um ambiente seguro (não custa lembrar, mas corredores e salas abertas não são seguros).
Levantando os problemas
Distribua post-its para todos e peça para escreverem em até 5 minutos todos os problemas que percebem. 1 problema por post-it. Não há limite máximo.
Na sequência, cole na parede ou num quadro branco todos os post-its, sempre agrupando os que forem similares. Leia os grupos e peça para as pessoas darem uma explicação sucinta caso haja dúvidas.
Em todas as vezes que rodei essa dinâmica, duas coisas costumam a acontecer. A primeira é que a percepção das pessoas é na superfície do problema e raramente na causa. A segunda é o sentimento de “O problema está lá fora”. Isso é, o time aponta o problema para agentes externos (departamentos, empresas, outros times, etc.). Isso não gera nenhum resultado, pois o grupo ficará imóvel esperando que os outros mudem. Esta dinâmica ajudará responder a seguinte pergunta: O que o nosso time deve mudar para causar um impacto significativo capaz de melhorar todo o sistema?
Escolha o pior
No final da primeira etapa teremos muitos problemas. Como diz Rodrigo de Toledo “uma lista com dois ou mais itens deve ser priorizada”. Pergunte para o time, dentre os problemas listados no quadro, qual o pior deles. Recomendo a técnica de Dot Voting para evitar discussões homéricas.
Na imagem abaixo, temos um exemplo de lista de problemas levantados já priorizados através do Dot Voting. O problema O cliente quer romper o contrato foi eleito o pior de todos pelo time.
Descobrindo os sintomas
A Árvore
Desenhe uma árvore com folhas e raiz no quadro e cole na copa da árvore (folhas) o pior problema.
Utilize a Técnica dos 5 Porquês de Taiichi Ohno [1]. Segundo o autor, se você perguntar o Por quê de um problema em até 5 vezes você chegará à causa raiz do mesmo.
Pergunte para o time: Por que vocês acham que o problema X existe? Cada resposta que eles derem será colada no tronco da árvore até que cheguemos a raiz do mesmo em até cinco passos. Apenas uma resposta será aceita para cada pergunta. O facilitador deverá levar o time ao consenso.
Exemplo:
Pior problema: O cliente ligou falando que vai romper o contrato.
Copa da árvore: Por que o cliente ligou falando que vai romper o contrato?
Resposta: Porque não entregamos o que ele pediu.
Tronco (próximo à copa): Por que não entregamos o que ele pediu?
Resposta: Porque ele não detalhou o que precisávamos saber.
Tronco: Por que ele não especificou o que precisávamos saber?
Resposta: Porque não paramos para conversar com ele.
Tronco: Por que não paramos para conversar com ele?
Resposta: Porque nossos Product Owners (responsáveis pelos requisitos do produto) não tiveram tempo para se reunir com o cliente.
Raiz: Por que os Product Owners não tiveram tempo?
Resposta: Porque a atenção deles está dividida em diversos produtos. Eles não podem se dedicar a um específico.
Chegando à causa raiz
Outro ponto interessante é que se voltarmos aos problemas levantados inicialmente, perceberemos que muitos têm uma única causa raiz. Coloque-os na copa da árvore.
Plano de ação
Expomos os problemas, achamos a causa raiz. O próximo passo é descobrir: Qual é o menor passo que eu posso dar (menor esforço) capaz de dar o maior resultado? Você poderá ter várias ações para remover a causa raiz. Porém caso sejam muitas, podemos levar as pessoas para o Paradoxo da Escolha [2] (Muitas Opções e nada é realmente feito). Crie uma ação, atribua a um responsável, aplique e avalie. “Responder a mudanças mais que seguir um plano”.
Ações para resolver a causa raiz do problema
Gostou deste artigo? Compartilhe conosco através dos comentários sua opinião sobre o assunto. Quer saber técnicas sobre como dar e receber feedback, inscreva-se nos nossos cursos de Agile Facilitator.
Referências
[1] – Ohno, Taiichi. Ask ‘why’ five times about every matter. Disponível em http://www.toyota-global.com/company/toyota_traditions/quality/mar_apr_2006.html. Acessado em setembro de 2017.
[2] – Schwartz, Barry. The Paradox of Choice: Why More Is Less. Harper Collins.
