Melhoria Contínua: a dor de hoje é o êxito de amanhã

Compartilhe:

“A dor de hoje é o êxito de amanhã”. Essa frase parece até algum ensinamento de autoajuda, mas ela está ligada a um valor essencial nos métodos ágeisa melhoria contínua!

Para explorar esse assunto, resolvi então trazer outras frases de efeito:

“Métodos ágeis não resolvem problemas, mas os expõem!”

A exposição dos problemas é o que estamos buscando quando aplicamos os métodos ágeis. Métodos não resolvem problemas, são as pessoas que resolvem os problemas. Ao dar visibilidade, as pessoas podem: se engajar na discussão, debater causa raiz, propor experimentações para solucionar o problema, metrificar etc. Valorizamos a gestão visual, por isso é tão comum postits na parede.

Para melhoria contínua, “O problema tem que doer!”

Muitas vezes vemos as empresas instaurando práticas para absorver problemas ao invés de eliminar a causa raiz. Seguem alguns exemplos:

Exemplo 1: “Estamos com problema de qualidade, então vamos montar um time de qualidade.”
Isso não resolve a causa raiz. Inclusive, por estar maquiando o verdadeiro problema, acaba por fazer com que a situação permaneça de vez. Quando há um time de qualidade, os demais times podem “relaxar” e talvez a qualidade reduza ainda mais. É um exemplo clássico de ciclo negativo, decorrente da maquiagem do problema.

Exemplo 2: Um outro exemplo ligado à qualidade que tipicamente acontece em TI: lista de bugs. A lista de bug é uma maneira de absorver o problema sem causar a dor que seria interromper o que estamos fazendo e corrigir imediatamente. Num curto prazo parece razoável, mas como não dói, acaba sendo muito cômodo simplesmente colocar bugs na lista e “um dia a gente resolve”. Mais uma vez, um ciclo negativo pode surgir pelo acúmulo de bugs. O acúmulo pode acontecer porque criamos mais bugs do que consertamos, ou não fazemos discussão de causa raiz, ou bugs que surgem em consequência de bugs anteriores, ou uma combinação desses fatores.

Exemplo 3Release train. Há uma parte da comunidade ágil que defende a existência de um ciclo longo para a liberação sincronizada de uma nova versão (release). Ora, buscamos ciclos cada vez mais curtos em métodos ágeis para termos resultados ponta a ponta, agregando valor e coletando feedback real. É claro que em grandes organizações, as dependências entre times é um grande dificultador, por isso devemos enfrentar esse problema. Porém, os “release trains” de 3 meses, como alguns defendem, justamente ocultam esses problemas de dependências. Ao invés de encarar e resolver o problema, mais uma vez estamos criando mecanismos para conviver com ele.

YouTube video

“Fail fast, learn faster”

O objetivo não é acertar de primeira, mas fazer com que na próxima iteração seja ainda melhor. Ter o entendimento que cada sprint é um experimento e que queremos validar o avanço a cada iteração. Saber melhorar é mais importante que acertar de primeira (assim como na matemática, a derivada é mais importante que o valor da função). Ou seja, acreditamos muito mais na capacidade de reação que na tentativa de perfeição.

“A dor de uma sprint pode ser o êxito da próxima!”

No Scrum, existem duas reuniões muito importantes no final de cada sprint, objetivando a melhoria contínua: review e retrospectiva.

A review é o momento para receber feedback do que foi feito na sprint. É o ápice no ciclo do Scrum, pois é o momento mais prazeroso, quando estamos ansiosos para ver a reação das pessoas ao nosso avanço. Nem sempre o feedback é positivo. Ex: “está faltando tal coisa” ou “sem aquilo não podemos lançar”. Nesse caso, devemos usar isso como alavanca para o sucesso da próxima sprint! Vamos fazer então ‘tal coisa’ ou ‘aquilo’. Aí sim teremos êxito.

Na retrospectiva, a reunião mais importante do Scrum, é quando discutimos as melhorias de tudo além do produto: pessoas, processos, colaboração etc. Se há uma frustração acontecendo com o time, com uma boa facilitação, a frustração ficará clara na retrô. Temos que usar isso como mola propulsora na busca dessa melhoria.

Portanto, vale reforçar a frase inicial, que serve para a vida:
A dor de hoje é o êxito de amanhã!

YouTube video

Sobre o autor(a)

Consultor, Trainer e Cofundador da K21

Rodrigo de Toledo é co-fundador da K21, Certified Scrum Trainer (CST) pela Scrum Alliance, Kanban Coaching Professional (KCP) e Accredited Kanban Trainer (AKT) pela Kanban University, além de Licensed Management 3.0 Facilitator. Com Ph.D na França, possui diversos artigos internacionais e lecionou por doze anos na PUC-Rio e na UFRJ, duas das principais universidades da América do Sul.

Artigos relacionados

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

É uma pergunta comum em diversos times ágeis: Temos capacidade para atender a demanda? A resposta é não. Como diz Rodrigo de Toledo: “No trabalho do conhecimento, a demanda sempre irá superar a nossa capacidade de atendê-la.”. O desafio é…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Data storytelling. Se você acompanha o nosso blog, já deve ter percebido que eu gosto muito de trabalhar com métricas, dados e gráficos. É interessante, mas esses artefatos, apesar de serem interessantes, sozinhos eles não vão dizer muitas coisas. Você…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

A criação de personas é um dos passos mais importantes no desenvolvimento de produtos, mas pode ser um desafio quando se trata de reunir dados e representá-los de forma precisa. Neste artigo, vou mostrar como usamos a inteligência artificial para…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Políticas explícitas são o alicerce invisível que mantém times ágeis funcionando com eficiência e harmonia. No contexto do Kanban, elas são mais do que simples regras: são acordos claros que orientam decisões, promovem transparência e evitam confusões. Apesar disso, muitas…