“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 ágeis: a 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 3: Release 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.
“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ã!
