Product Oversee

Ser ágil é ser rápido?

Um dos conceitos mais mal entendidos da agilidade

Imagem de destaque de Ser ágil é ser rápido?

Oras, se você estiver se referindo ao significado do adjetivo ágil, contido no dicionário e que se refere a algo

“que se movimenta com excesso de facilidade; que se move de maneira rápida; veloz”

pode até ser que sim. Agora, se você estiver se referindo ao ágil dentro do contexto de software, então com certeza não!

Ainda lembro quando estava estagiando na SAP da Hungria, primeiro lugar em que realmente tive experiência com desenvolvimento de software (ainda software, não existia product management lá ainda em 2013), e, em minha entrevista, o gerente falou que eles eram ágeis.

Eu já havia feito um minicurso de Scrum em um evento da universidade e para mim até então, saber Scrum era ser ágil. Logo, sem hesitar, falei para eles que achava legal o fato de utilizarem a metodologia e estava me gabando por saber o que significava ágil (mal sabia eu, que se eles não utilizassem Scrum mesmo, talvez eu nem tivesse conseguido a vaga :D).

Outra coisa que eu havia colocado em minha cabeça é que ser ágil é realmente ser mais rápido. Pode até que isso realmente aconteça em algumas situações, mas essa não é a regra, de maneira alguma.

E você não precisa ler aqueles livros de páginas sobre as mais diferentes abordagens que dão para o ágil por aí. Basta ler o manifesto ágil. Sim, simples assim. Tem até o link aqui para ficar ainda mais fácil.

Agora, faça o seguinte: abra a busca de texto do seu navegador na página do manifesto e procure pelas palavras “rápido” e “veloz”. Achou? Pois é!

Para iniciar no ágil, essa é uma das coisas mais importantes para colocar em sua cabeça: gestão de produto ágil não necessariamente significa que o produto ficará pronto mais rápido. Não! Uma das melhores definições para o ágil que eu já vi é a seguinte:

“The point of Agile is reducing the cost of change and uncertainty.”.

Não é uma maravilha? Esse sim é o ponto do ágil: reduzir os custos das mudanças e incertezas. O que o seu cliente precisa hoje, amanhã pode não precisar mais e não é porque ele é indeciso (pode até ser, vai :D), mas porque o mercado muda e os comportamentos das pessoas também. E toda essa mudança e incerteza não são colocados na conta dos processos antigos que existiam e ainda existem por aí.

Mas então por que o ágil consegue responder às mudanças e outras filosofias não? Ué, por entregar o produto mais rápido! Êpaaaa! Como assim, Pablo? Você acabou de dizer que não tem nada a ver com rapidez! Então, são unidades do produto final que geram algum valor para que o cliente entenda se está tudo bem; se a ideia é essa mesmo, se é esse o valor que ele estava esperando. E isso sim é mais rápido.

O que eu estou querendo mostrar é que não adianta pensar que um produto que você demoraria um ano para entregar utilizando waterfall, agora você vai entregar com dois meses utilizando ágil. O que vai acontecer é que, mesmo que você demore o mesmo ano (o que provavelmente será menos), o valor que você vai gerar para o seu cliente será certeiro.

O produto entregue será o que ele realmente estava precisando, ao invés de chegar no final do ano de desenvolvimento com waterfall - e descobrir que seu cliente queria uma moto vermelha mas você acabou entregando um barco azul.

Tenha na cabeça que ágil não é algo milagroso. As incertezas sempre estarão lá e o seu cliente sempre vai mudar, isso é natural. O que o ágil faz é induzir que você responda às mudanças mais cedo e gastando menos. E como já dizia Benjamin Franklin “Tempo é dinheiro”!