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.

“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

Nas discussões e workshops sobre OKRs que fazemos nas empresas, um conceito sempre aparece: Estão faltando métricas de guard rail para equilibrar esses OKRs! As Métricas de saúde (ou Guard Rails) ajudam a liderança e as equipes a manterem um…

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

O que é gargalo Quando falamos sobre Kanban um dos nossos principais objetivos é identificar onde está o gargalo do nosso fluxo. O gargalo é a etapa em que os itens permanecem por mais tempo. É fundamental resolver os gargalos…

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

Seja em treinamentos, consultoria ou até mesmo com meus times de desenvolvimento. Uma coisa fácil de perceber é o desconforto causado quando comento sobre a necessidade de limitação de WIP. É algo que me causa estranheza. Por que as pessoas…

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

No artigo anterior, comentamos sobre o que era o Kanban, qual problema ele resolve e os princípios que norteiam esse método de gestão de trabalho. Este artigo é um complemento ao primeiro e nele quero tratar as práticas que o…