As metodologias ágeis são apaixonantes. O formato voltado para um design de pensamento direcionado à inovação traz sinergia entre equipes, sintonia dos times com suas lideranças, alegria dos clientes no tempo de entrega e satisfação geral. Hoje, as metodologias ágeis são populares, e estão muito além de suas raízes – o desenvolvimento e fabricação de produtos. Tem sido normal ouvir sobre a abordagem ágil de orçamento, gerenciamento de talentos e ver profissionais especialista nos métodos no LinkedIn.

O desenvolvimento ágil é um processo poderoso para o design de produtos e serviços, mas ultimamente as empresas parecem terem ido longe demais e esgarçado seus métodos para, na verdade, ganhar tempo, poupar planejamento e investimento.

Diante desta propensão das empresas, em artigo dedicado ao Harvard Business Review, os consultores Colin Bryar e Bill Carr, ambos conselheiros de Jeff Bezos por anos e escritores do livro “Trabalhando de trás para frente: Percepções, Histórias e Segredos da Amazon”, se propuseram a comentar algumas deficiências nas investidas de metodologias ágeis nos estágios iniciais cruciais.

Como as empresas ágeis tropeçam em si mesmas

As metodologias ágeis caem bem quando uma empresa está desenvolvendo um produto ou serviço que não existe e está procurando mudar rapidamente. Nesses casos, é complicado simplesmente entrevistar clientes ou observá-los em ação, pois eles não podem responder muito bem a um produto hipotético. A solução, então, é desenvolver um protótipo, ou produto mínimo viável.

Por meio de uma série de sprints, normalmente com duração de duas semanas, o time de produto monta algo que é bom o suficiente para mostrar ao cliente e obter sua reação. Se a ideia não for vem aceita, ela não necessariamente fracassou, pois pelo menos a equipe fez uma descoberta sem um grande investimento – além de aumentar as chances de desenvolver algo no processo. Se ganhar força, a equipe pode de fato criar um produto ainda melhor.

Pausa. Agora, pense em um processo retroativo.

Bryar e Carr sugerem atingir uma visão totalmente esclarecida sobre o produto proposto para então desenvolvê-lo. Isso inclui começar pelo release de imprensa do lançamento – o que na Amazon soava bem antinatural aos desenvolvedores e gerentes de produto, que já queriam sair programando, segundo os consultores. Os especialistas contam que as equipes chegavam a passar meses discutindo os comunicados de imprensa, enquanto a equipe de atendimento passava semanas explicando a outros departamentos, clientes e gerentes o quanto o produto era maravilhoso e acessível.

Pode parecer estapafúrdio, mas Bryar e Carr desenvolveram o “trabalho de trás para frente” em 2004, quando as estratégias de e-commerce da Amazon provaram ser bem-sucedidas e a empresa estava buscando agressivamente novas oportunidades com um grande mercado potencial. Em vez de começarem a desenvolver um produto plausível – que é exatamente o que uma mentalidade ágil encoraja -, eles preferiram ir devagar para então correrem. Os consultores contam que esta parcimônia tinha a ver com o próprio Bezos, que costumava se chamar de “chief slowdown officer” por se envolver nas equipes quando pensava que elas estavam muito aceleradas, sem pleno esclarecimento do problema do cliente, e com uma solução de produto demasiadamente elegante.

E a prática permanece até hoje. A Amazon trabalha de trás para frente, não se intimidando quando não tem os recursos para fabricar um produto. Os autores do livro contam que o Kindle, os serviços de computação em nuvem da AWS e o assistente de voz Alexa surgiram a partir dessa metodologia reversa em uma época em que a Amazon tinha pouca experiência em fazer dispositivos ou hospedar atividades de outras empresas em seus servidores.

Velocidade não é tudo

O grande problema das implementações das metodologias ágeis em boa parte das empresas é o ritmo implacável que pressiona os desenvolvedores. Há uma ideia de que eles lancem um produto minimamente viável em coisa de semanas, e assim se poupam em definir o que o produto deve realizar. Ou pior: eles fazem dois tipos de concessões, segundo os autores.

Primeiro, em vez de perderem tempo e quebrarem a cabeça com incertezas para desenvolver algo novo, eles seguem usam as habilidades que já possuem. Basicamente, aceitam suas restrições existentes – o que limita automaticamente o potencial para uma oferta de alto crescimento. Em segundo lugar, eles restringem suas ambições em relação ao produto. Em vez de almejarem um grande avanço, eles tendem apenas a fazer reparos e melhorias incrementais nas ofertas já existentes. Ou, se eles forem ousados, o produto minimamente viável não nem um pouco viável, e assim não conseguirão um feedback realista do cliente para fazer reparos e entregar algo que satisfaça ou impressione.

Pode ser que em casos como esse a equipe diga a si mesma que qualquer informação é válida para um futuro produto inovador. Mas Bryar e Carr dizem que esse futuro raramente chega. Muitas vezes, o processo de sprints de duas semanas se torna a missão em si, e a equipe nunca tem tempo e espaço para recuar e ficar obcecada sobre o que é necessário para realmente encantar os clientes. As equipes pensam em pedaços pequenos com base nos recursos que já possuem – não há tempo para o pensamento cuidadoso que as descobertas exigem.

Para Bryar e Carr, quem propõem esquemas ágeis muitas vezes teme que uma abordagem retroativa tire a autoridade e a urgência das equipes para lançar algo, obter o feedback e fazer os reparos. Mas velocidade não é tudo – especialmente quando se trata de produtos disruptivos. “Não confunda escrever códigos com progredir por si só. Ao trabalhar de trás para frente, você pode realmente colocar um produto de sucesso no mercado mais rapidamente”, ponderam os consultores.

Como fazer metodologias ágeis funcionarem melhor

Bryar e Carr não estão dizendo para abandonar as metodologias ágeis. Elas são provadamente eficazes para o desenvolvimento de produtos, principalmente se tratando de softwares. Eles lembram que muitos dos princípios e processos dessas metodologias foram usados ​​com sucesso pela Amazon e muitas outras grandes e pequenas empresas – uma vez que a maior parte do desenvolvimento de produtos envolve apenas mudanças incrementais.

“Você não precisa se preocupar muito com essas melhorias. Basta reunir duas alternativas básicas e experimentá-las no mundo real, para as quais você terá um feedback vital”, esclarecem os consultores.

Sprints mantêm você no caminho certo e garantem que você realmente coloque algo no mercado, lembram eles.

Assim, a melhor solução, segundo Bryar e Carr, é combinar agilidade com pitadas de trabalhos de trás para frente. A Amazon, por exemplo, aprendeu a usar o processo reverso para evoluir ideias, mas depois seguiu com processos ágeis para desenvolver produtos.

Se uma gigante ela pode mudar de rumo dessa forma, por que empresas menores não conseguiriam?

+ Notícias

Resultados conquistados pelas empresas com as metodologias ágeis

23 informações para empresas que querem ir além das metodologias ágeis

Metodologias Ágeis: Como unir esforços para garantir o sucesso da empresa