“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ã!
Perguntas frequentes
Qual é o papel dos métodos ágeis na resolução de problemas?
Os métodos ágeis não resolvem problemas por si sós, mas expõem os gargalos para que as próprias pessoas os resolvam. Ao dar visibilidade com a gestão visual, os times conseguem debater a causa raiz dos desafios, engajar a equipe em discussões e propor experimentações práticas para alcançar soluções definitivas.
Por que criar uma lista de bugs pode prejudicar a qualidade do produto?
A lista de bugs absorve os problemas em vez de eliminá-los, adiando a correção imediata por ser uma alternativa cômoda. Isso pode gerar um ciclo negativo de acúmulo de falhas, seja pelo surgimento de novos erros decorrentes de antigos ou pela ausência de discussões sobre a causa raiz.
O que significa o conceito de fail fast no desenvolvimento ágil?
O conceito de fail fast foca na rápida capacidade de reação e aprendizado contínuo, tratando cada sprint como um experimento. O objetivo principal não é acertar de primeira, mas evoluir a cada iteração, priorizando a capacidade de adaptar o trabalho e melhorar constantemente em vez de buscar a perfeição inicial.
Qual a diferença entre reunião de review e retrospectiva no Scrum?
A reunião de review foca na coleta de feedback sobre o produto entregue na sprint para direcionar os próximos passos. Já a retrospectiva avalia os processos, a colaboração e as pessoas. As frustrações identificadas na retrospectiva servem como base para promover melhorias internas e impulsionar o avanço do time.
Pronto pra dar o próximo passo?
Conheça os cursos da K21 e leve essas ideias pra prática com quem vive agilidade todo dia.
Ver cursos K21