Afinal, a agilidade funciona mesmo em qualquer contexto?

São inegáveis os benefícios que as metodologias ágeis vêm proporcionando a alguns setores, como, por exemplo, as áreas de desenvolvimento de softwares e produtos digitais

Nos últimos anos, temos vivido um boom do mercado da agilidade. Ela virou a palavra do momento que soluciona todos os problemas de uma empresa. Basta você ativar o “raio squaditizador”, usar meia dúzia de palavras em inglês, colocar alguns post-its na parede, fazer reuniões em pé, e isso significará que a organização está vivendo a famosa “transformação ágil”.

Assim como aconteceu com a onda Coach alguns anos atrás, a agilidade corre o risco de entrar na superficialidade e ser vendida para qualquer contexto ou pessoa, com o objetivo de resolver qualquer problema. A análise que eu proponho antes de acreditarmos em poção mágica é: a agilidade serve mesmo para qualquer coisa?

São inegáveis os benefícios que as metodologias ágeis vêm proporcionando a alguns setores, como, por exemplo, as áreas de desenvolvimento de softwares e produtos digitais. Permeados por um ambiente de incerteza e necessidade de adaptação a mudanças frequentes, mercados como esses precisam de abordagens que permitam evoluções incrementais, ciclos curtos, feedbacks constantes, respostas rápidas e auto-organização.

Mas então, se isso é tão bom assim, eu posso aplicar agilidade em outros setores, como na construção civil? Sim, você pode. Mas faz sentido?

Para responder essa pergunta, vamos retornar às origens da agilidade.

O manifesto ágil nos dá 12 princípios que embasam os frameworks e métodos que aplicamos nas organizações hoje em dia.

Logo de cara, o segundo princípio já diz: “Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas”.

Agora, imaginemos uma situação em que uma empreiteira construiu um prédio de 20 andares, com 2 apartamentos por piso, para a empresa ‘X’. O prédio já tem todos os andares e apartamentos, e a estrutura está toda finalizada. O próximo passo seria iniciar as instalações elétricas e hidráulicas. Tudo caminha bem, até que, a partir de um estudo do time de negócios que avaliava o perfil do usuário final, a empresa entende que é melhor que o prédio tenha somente 10 andares com 4 apartamentos por piso. O custo de demolir 10 andares e reformar os outros 10 para acrescentar 2 apartamentos em cada um deles seria enorme, provavelmente, financeiramente inviável para a ‘X’.

Quando pensamos num cenário parecido, só que no contexto do desenvolvimento de um aplicativo por exemplo, o custo que uma mudança dessa representaria seria muito baixo e, se gerasse mais valor para o cliente, provavelmente seria executado.

Agora vamos a outros princípios: “Entregar software em funcionamento com frequência, desde a cada duas semanas até a cada dois meses, com preferência por prazos mais curtos” e “software funcional é a medida primária de progresso”.

Esses princípios passam a ideia de gerar entregas iterativas e incrementais, para que os clientes finais tenham acesso mais rápido a uma versão funcional do software.  E, a partir do feedback do usuário, o time faça evoluções e direcione o produto em desenvolvimento. Com isso, a partir das primeiras entregas, o cliente já tem algum nível de geração de valor.

Dito isso, no nosso exemplo do prédio de 20 andares: se, como uma das entregas, a empreiteira apresenta a estrutura da construção naquele estágio comentado anteriormente, de que adianta? Como as pessoas morariam em um prédio sem energia e água? Como seria possível colher feedback do usuário final e adaptar o prédio a esta altura da construção? Mesmo que a obra fosse acelerada e, por um milagre, a estrutura inteira tivesse sido construída em um ou dois meses, o prédio não estaria em condições de ser “testado”. O “produto” não seria funcional. Até que a obra estivesse completamente finalizada, não é possível que o prédio gere algum valor para o cliente.

Enfim, a lista é grande. Eu poderia citar mais exemplos e confrontá-los com os outros princípios do manifesto ágil, mas acho que é o suficiente. É importante entender que, de forma nenhuma, acredito que agilidade só é aplicável para a área de tecnologia. Com a atual experiência profissional, venho iniciando a aplicação da agilidade na área comercial e consigo observar ótimos resultados até agora.

Mas então, quando a agilidade faz sentido?

Para fugirmos da superficialidade que comentei anteriormente e não cairmos no conto dos “agilistas abraçadores de árvores”, entendo que é importante responder essa pergunta com alguma fundamentação técnica.

Quando olhamos para o lado direito, vemos os domínios “Óbvio” e “Complicado”. Quando estamos neles, tratamos de sistemas ordenados, ou seja, há previsibilidade, as coisas se comportam como esperado e você consegue controlar a situação, por mais que apareçam alguns empecilhos no caminho. Do lado esquerdo, temos os domínios “Complexo” e “Caótico”, onde as condições são incertas. Você precisa testar alternativas inovadoras, fora da sua zona de conforto, e coisas imprevisíveis de alto impacto acontecem o tempo inteiro. É nesse contexto que a agilidade é relevante. É aí que são necessárias respostas rápidas, mudanças em qualquer estágio, ciclos curtos, feedbacks constantes etc. Fora disso, o custo da aplicação da agilidade pode ser muito alto ou até mesmo inviável.

Obs.: A transição entre os domínios, quais aspectos devem ser considerados em cada um deles, como se comportar e como perpassar por eles. Por exemplo, parece óbvio que ninguém quer estar no domínio “Caótico”, mas, às vezes, imersões momentâneas nesse contexto podem gerar ótimos resultados, por meio da remoção de restrições e estímulo à liberdade criativa, fazendo com que os integrantes do sistema saiam de lá com soluções disruptivas (e de preferência eficientes). Dá para ver que tem muito mais coisa do que eu falei aqui, né? A forma como eu o apresentei foi bastante embrionária, com o objetivo de somente introduzir o assunto para sustentar a argumentação.

Conclusão: Você pode aplicar agilidade em qualquer coisa. É até legal ver a empresa se comportando de forma diferente e colorida por causa dos post-its na parede. Mas nem sempre a agilidade vai fazer sentido para o seu contexto. Projetos em que o escopo não tende a sofrer mudanças durante a execução; onde é fundamental que tudo esteja planejado desde o início; e em que seja possível ter um bom grau de previsibilidade, não demandam aplicação da agilidade. Você até pode aplicar algumas ferramentas, cadências e/ou técnicas conhecidas do mundo ágil, como as reuniões diárias ou o quadro kanban por exemplo. No entanto, a agilidade como estrutura de pensamento, ação e cultura provavelmente não funcionará bem para esse contexto, e o custo dela tende a ser muito alto.

Por outro lado, nos projetos em que é fundamental ter respostas rápidas às mudanças em curso; que estão inseridos em ambientes incertos; e que demandam geração de valor quase instantânea, a agilidade pode ser uma excelente aliada para gestão e uma ótima oportunidade para alavancar resultados.

Vamos caminhar de mãos dadas com a agilidade?

Eu acredito em você!

Que nossa semana seja ágil!

Por

leny.espinola@oestadorj.com.br

* Radialista, Fotógrafa e Palestrante Motivacional.

Comentários estão fechados.

http://api.clevernt.com/0d18126b-b33f-11e7-bb95-f213f22ad24e