Em março, a diretoria de operações de uma seguradora decidiu que as seis equipes do backoffice de sinistros passariam a trabalhar com metodologia ágil. Veio uma consultoria, cada equipe ganhou um quadro, sprints de duas semanas, reunião diária de 15 minutos, revisão e retrospectiva. Em julho, o painel mostrava o que a diretoria queria ver: a quantidade de tarefas concluídas por sprint tinha subido 40%.
O cliente não percebeu nada. O tempo entre a abertura do sinistro e o pagamento, que era de 19 dias em média, estava em 18. A diretoria concluiu que as equipes ainda não tinham internalizado a cultura ágil e contratou mais um ciclo de capacitação. A decisão parecia lógica e estava apoiada no indicador errado.
O que é metodologia ágil
Metodologia ágil é um conjunto de práticas para entregar trabalho em ciclos curtos, com o cliente avaliando cada entrega e a equipe ajustando o plano a partir do que aprendeu. O termo vem do Manifesto para Desenvolvimento Ágil de Software, assinado em 2001 por 17 desenvolvedores, que propõe quatro valores e doze princípios. Scrum e Kanban são as formas mais usadas de colocar isso em prática.
A definição fica mais clara pelo que a metodologia ágil não é. Não é um pacote de reuniões: daily, sprint e retrospectiva são a forma, e uma equipe pode cumpri-las todas sem entregar nada mais rápido ao cliente. Não é velocidade de equipe: tarefas concluídas por sprint medem quanto a equipe produz, não quanto o cliente espera. E não é método de melhoria de processo: ela organiza o trabalho dentro da equipe, mas não diz como descobrir por que o processo como um todo é lento. Os valores do Manifesto Ágil estão explicados em detalhe na página própria.
Onde a seguradora errou
A pergunta que ninguém fez em março foi: onde o sinistro passa os 19 dias? Quando a equipe de qualidade finalmente mediu, em agosto, o resultado mudou a conversa. Cada sinistro foi acompanhado da abertura ao pagamento, com hora de entrada e saída em cada etapa.
Dos 19 dias, as equipes ágeis tocavam o sinistro por cerca de 2,5 dias somados. O resto era espera: 11 dias aguardando laudo da perícia externa, 3 dias parado entre a análise e a aprovação da alçada, e o restante em filas de documentação pendente do segurado. As sprints aceleraram exatamente a parte que já era pequena. Ninguém estava fazendo nada errado dentro da equipe; o tempo estava fora dela.
| Pergunta | O que a metodologia ágil mede | O que o cliente sente |
|---|---|---|
| Indicador principal | Tarefas concluídas por sprint (velocidade) | Dias entre pedir e receber (lead time) |
| Onde olha | Dentro da equipe | Do início ao fim do processo, entre equipes |
| No caso da seguradora | +40% de tarefas por sprint | 19 → 18 dias |
| O que esconde | Filas e esperas fora do quadro | Nada: o cliente sente as esperas |
Esse descompasso é o mais comum quando a ordem de ser ágil desce da diretoria: a mudança acontece, o indicador de esforço melhora e o resultado não se mexe. Mudança não é melhoria. Uma mudança só vira melhoria quando o indicador que importa para o cliente melhora, de forma relevante e sustentada, e isso precisa ser verificado — não presumido. O tema está desenvolvido em como saber se uma mudança é uma melhoria.
Scrum, Kanban e as outras formas de ser ágil
A escolha entre as práticas ágeis depende do tipo de trabalho, e confundir as duas principais é fonte frequente de frustração. O Scrum organiza o trabalho em sprints de duração fixa, com papéis definidos — product owner, scrum master e time — e funciona bem quando há um produto a construir em incrementos. O Kanban não tem ciclos fixos: limita o trabalho em andamento e faz o fluxo aparecer no quadro, o que combina melhor com demandas contínuas, como sinistros, chamados e pedidos.
No backoffice da seguradora, sprints de duas semanas para um fluxo contínuo de sinistros criaram um efeito colateral: casos que chegavam no meio da sprint esperavam a próxima para entrar no planejamento. Parte do ganho de velocidade era isso — a equipe escolhia o que cabia na sprint, e o restante esperava. A aproximação entre os princípios do Lean e as práticas ágeis está tratada em Lean Agile.
Como fazer a metodologia ágil melhorar o resultado
A virada no caso da seguradora não foi abandonar o ágil. Foi trocar a pergunta. Em vez de “como fazemos mais tarefas por sprint”, a equipe passou a perguntar “o que estamos tentando realizar, como saberemos se uma mudança é uma melhoria e que mudanças podemos testar” — as três questões do Modelo de Melhoria.
O objetivo virou reduzir o tempo da abertura ao pagamento de 19 para 12 dias até dezembro. O indicador de resultado passou a ser o lead time de cada sinistro, acompanhado semana a semana num gráfico de controle, e não a média do mês contra a do mês anterior. O indicador de processo foi a proporção de sinistros que chegavam à análise já com a documentação completa. O de equilíbrio, a proporção de pagamentos revistos depois por erro.
As mudanças foram testadas em ciclos PDSA, uma de cada vez e em pequena escala. A primeira: agendar a perícia no mesmo dia da abertura, em vez de esperar a triagem — testada com uma equipe e um tipo de sinistro por duas semanas. A segunda: lista de documentos enviada ao segurado na abertura. A terceira: aprovação de alçada em dois horários fixos por dia. Em novembro, o lead time médio estava em 11 dias e se manteve nesse patamar por três meses, com a proporção de pagamentos revistos estável. As sprints continuaram; passaram a servir ao fluxo, e não o contrário.
Essa sequência — objetivo, indicador no tempo, mudança testada em pequena escala — é o núcleo do método científico aplicado à gestão, ensinado na formação Green Belt como o caminho para separar o que mudou do que melhorou.
Quando a metodologia ágil não resolve
A metodologia ágil não resolve problema cuja causa está fora da equipe que a adota: esperas entre áreas, fornecedores, alçadas de aprovação, sistemas que não conversam. Também não resolve problema de variação — prazos que oscilam muito de um caso para o outro —, porque a sprint organiza o trabalho, mas não investiga por que ele varia. E não substitui um objetivo de resultado: equipe ágil sem indicador do cliente tende a otimizar a própria velocidade.
Ela funciona bem quando o trabalho é construir algo cujo formato final não se conhece de início, quando o cliente pode avaliar entregas parciais e quando a maior parte do tempo do processo está, de fato, dentro da equipe.
Até onde o ágil leva — e quem assume depois
A metodologia ágil leva uma equipe até o ponto de trabalhar em ciclos curtos, com prioridades visíveis e aprendizado a cada entrega. Daí em diante, quando a pergunta passa a ser por que o cliente continua esperando, por que o prazo varia tanto ou se a mudança de março melhorou alguma coisa, o problema é de outro instrumento: medir o processo de ponta a ponta, entender a variação e testar mudanças com predição registrada. Gestores que recebem a ordem de ser ágeis ganham muito quando chegam a esse segundo ponto antes de contratar o próximo ciclo de capacitação.
Conteúdo revisado pelo Master Black Belt Marcelo Petenate, estatístico, formado pela Unicamp, mestre pela USP e especialista em Lean Six Sigma e melhoria contínua.
Nesta revisão, o foco foi a diferença entre adotar práticas ágeis e melhorar o resultado que o cliente sente.
Quem precisa transformar a ordem de ser ágil em resultado medido encontra o método — objetivo, indicador no tempo e mudança testada — na formação Green Belt da EDTI.
Perguntas frequentes
Qual a diferença entre metodologia ágil e Scrum?
Metodologia ágil é o conjunto de valores e práticas que nasceu do Manifesto Ágil de 2001. Scrum é uma das formas de aplicá-la, com sprints de duração fixa, papéis definidos e eventos próprios. Toda equipe que usa Scrum é ágil na forma, mas nem toda equipe ágil usa Scrum.
Metodologia ágil serve fora da área de tecnologia?
Serve, com adaptação. Em áreas de fluxo contínuo — atendimento, backoffice, compras —, práticas como o Kanban costumam encaixar melhor que sprints fixas. O cuidado é medir o tempo que o cliente espera, e não apenas a produção da equipe.
Quais são os quatro valores do Manifesto Ágil?
Indivíduos e interações mais que processos e ferramentas; software em funcionamento mais que documentação abrangente; colaboração com o cliente mais que negociação de contratos; responder a mudanças mais que seguir um plano. O manifesto ressalva que os itens da direita também têm valor.
Como medir se a metodologia ágil está funcionando?
Pelo indicador que o cliente sente, como o lead time do pedido à entrega, acompanhado no tempo em gráfico de controle. Velocidade de equipe é indicador de esforço. Se ela sobe e o lead time não cai, a mudança aconteceu, mas a melhoria não.
Ágil e Lean Six Sigma competem entre si?
Não. O ágil organiza o trabalho da equipe em ciclos curtos; o Lean Six Sigma mede o processo de ponta a ponta, reduz esperas e variação e verifica se a mudança melhorou o resultado. Muitas empresas usam os dois: o segundo diz onde o primeiro deve atuar.
Metodologia ágil é suficiente sozinha?
Para organizar o trabalho de uma equipe, muitas vezes é. Para melhorar um resultado que depende de várias áreas, raramente: falta medir o processo inteiro e testar mudanças com predição. É esse complemento que a formação Green Belt da EDTI ensina.