“Essencialmente, todos os modelos estão errados; alguns são úteis!” A frase do estatístico britânico George P. Box, na década de 70, parece um tanto pessimista ou, até mesmo, radical, não é mesmo?
Há alguns dias, estava ministrando uma disciplina de “Introdução ao Gerenciamento de Projetos”, para uma turma de MBA em Gerenciamento de Projetos, em uma grande instituição de Belo Horizonte. Neste módulo, saímos um pouco do que é tradicional neste tipo de matéria. Abordamos questões de estratégia organizacional x projetos, o guia PMBOK, mas também muito de agile.
Em determinado momento, enquanto passava um visão geral das 10 áreas de conhecimento do guia PMBOK, um aluno questionou:
“Thiago, quer dizer, então, que o ágil não reconhece estas áreas? Escopo, cronograma, custos, etc?”
Então, o convidei a uma reflexão:
“É possível fazer um projeto sem pensarmos no que precisamos entregar ao nosso cliente? É possível, na realidade da sua empresa, implementar um projeto onde não se discuta quando ele começa e quando ele termina? É aceitável realizar um projeto sem se preocupar com o quanto se irá gastar? Pense nessa linha também em termos dos recursos que precisam ser utilizados e adquiridos, da qualidade exigida, etc.”
Se utilizo abordagem ágil, o problema passa a ter prazo de solução infinito?
Sua resposta foi:
“Você tem razão. Olhando agora para o que você nos explicou quanto aos ciclos de vida, preditivo e ágil, principalmente, o que me parece é que ambos precisam considerar estes assuntos, mas a maneira como cada abordagem lida com ela, o modelo mental, é que difere.”
Talvez, com esta provocação, eu tenha conseguido evitar que este aluno tivesse caminhado na infeliz direção de pensar que uma abordagem, modelo, método, ferramenta, etc fosse correta e a outra errada em qualquer contexto. Se você usa um martelo para tentar serrar uma tábua e fracassa, não pode colocar a culpa no martelo. Mas obviamente, se você só tem martelo, tudo vira prego.
Penso que algumas discussões em relação às abordagens de gestão vêm tomando um rumo não muito legal e nocivo ao mercado. A imagem acima me fez pensar: “então, se utilizo abordagem ágil, não precisa ter prazo pra entregar? Ou seja, basta utilizar a abordagem ágil, que o problema passa a ter um prazo infinito pra ser resolvido?”
Com o “advento do ágil”, bem como novas e excelentes práticas que vem surgindo recentemente, as vezes me parece estar surgindo também uma espécie de processo de “endeusamento / demonização” de práticas, modelos, ferramentas, métodos. E daí, aparecem também discussões inúteis.
De um lado, temos os “cavaleiros modernos”, que irão nos salvar das garras da “metodologia tradicional”, culpada de todos os nossos problemas. Tendo o guia PMBOK como ícone, passou a ser demonizada por muitos.
Na outra ponta, surge o “deus agile”, a bala de prata que salvará o mundo e nos libertará.
Então, as “organizações modernas e revolucionárias”, apoiadas por seus “Agile Transformation Yoda Highlander Chuck Norris Coach” passam a se “reinventar”. Começam a colar post-its na parede, contratam dúzias de Scrum Masters, criam ambientes com pufs coloridos e dizem que “mudaram o mind-set”. Há algo de mau em implementar tudo isso? Óbvio que não! Desde que não apenas se “use ágil”, como também “seja ágil”.
Porém, a discussão não é apenas sobre ferramentas e soluções. Mas sim, sobre problemas. A única “agilidade” do movimento deliberado que descrevi acima, obviamente, é a velocidade com a qual as pessoas se frustram com essa “mudança de mind-set”. E aí, o “deus agile” passa a virar o demônio que te levou ao fracasso.
Penso que tudo isso vem do fato de que, com o conhecimento de fácil acesso a todos atualmente, há muitas ferramentas que “estão na moda” e é bonito dizer que está utilizando o que há de “mais moderno” em termos de prática. Na minha visão, há duas “síndromes” que representam muito bem este tipo de pensamento.
Uma delas é a “Síndrome do Zé Especialista”. É o defensor ferrenho de uma abordagem. O “PMBOKIANO Xiita” ou o “Agilista Obcecado”. Não importa o problema, aquela abordagem resolverá. Uma espécie de “Organizações Tabajara” do mundo real. Implementa softwares, realiza obras, eventos, melhora unha encravada e trás o amor de volta em 7 dias. Basta “entender o mind-set” e ser feliz.
A outra é a “Síndrome do João da Caixa de Ferramentas”. Os principais sintomas são conhecer e fazer cursos de todas as abordagens, sobretudo as mais “descoladas e bonitinhas”. Sua “caixa de ferramentas” é mais poderosa que o cinto do Batman. Porém, as utiliza a “bel-prazer”, por mera subjetividade. E obviamente, não resolve os problemas.
A questão que se impõe não é quantas ferramentas você sabe ou se utiliza as mais novas, mas sim se você entende o problema que precisa resolver, o contexto e o ambiente onde o problema está inserido e as pessoas que estão ao redor. Einstein disse:
“Se eu tivesse uma hora para resolver um problema e minha vida dependesse dessa solução, eu passaria 55 minutos definindo a pergunta certa a se fazer”.
A sensação que tenho é que as pessoas aprendem uma nova técnica e correm em busca de qualquer problema para utilizá-la, em vez de compreenderem o problema existente e buscar a ferramenta ou o conjunto de ferramentas mais adequado.
Não é feio não usar Scrum ou Kanban, por exemplo, nos dias atuais se o seu problema não apresenta características de incerteza que lhe demandam abordagens mais empíricas. Não é necessário Scrum para construir um prédio. Depois da alvenaria construída, não vai ser possível deslocar o prédio 20 cm para o lado. Obviamente, você pode, por exemplo, utilizar uma abordagem de Lean Construction em sua obra, evitando desperdícios e sendo mais eficiente no uso dos recursos, e até uma construção incremental. Sem dúvida, neste aspecto, você está praticando, pelo menos um pouco, de uma parte fundamental da mentalidade ágil.
Os problemas que resolvemos hoje, características distintas e estão em um ambiente completamente diferente dos problemas que resolvíamos há 10 ou 15 anos. E é esse contexto que precisa ditar a escolha das ferramentas que vamos utilizar para resolve-los.
Por outro lado, se você quer lançar um produto digital no mercado, com pouca previsibilidade sobre os requisitos e até mesmo com incerteza sobre a real necessidade a ser sanada, com certeza, a abordagem ágil, com foco em entregas frequentes e ciclos curtos de feedback, será mais adequada. Mas não se alcança isso apenas rodando sprints, colando post-its na parede e com práticas isoladas de Management 3.0.
É preciso entender que novas práticas e abordagens não surgem apenas por modismo, mas sim por necessidade. Hoje, temos problemas que não tínhamos 10 ou 15 anos atrás. As características e o ambiente dos problemas que precisamos resolver hoje são distintas. É necessário compreender que, em muitas áreas, a janela de tempo entre o momento em que necessidade é identificada e o momento em que ela precisa ser sanada é cada vez menor. E que neste cenário, a incerteza que paira é enorme.
Neste tipo de situação, abordagens preditivas, onde se emprega um planejamento inicial bastante detalhado e que busca prever um horizonte muito distante, para só depois executar, não são adequadas. Nesse ambiente, não há receita de bolo. Não há modelos prontos que vão resolver o problema. E aí, provavelmente, haverá mais benefícios em se seguir uma linha de validação de hipóteses, fazendo com que o empirismo permita que as práticas que vão resolver este problema emerjam dos feedbacks das hipóteses que vão sendo validadas (ou não) a cada entrega e a cada ciclo frequente de feedback.
Demonizar ou endeusar ferramentas e técnicas é totalmente anti-ágil!Pois atribui-se mais valor a ferramentas e processos do que a indivíduos e interações. É como culpar o martelo por não conseguir apertar o parafuso.
A lição que venho tirando de tudo isso é que se apaixonar por ou odiar ferramentas, modelos, práticas e técnicas, sem entender o contexto no qual elas serão aplicadas, é um dos caminhos mais curtos para o fracasso. Conheça tantos (as) quanto puder. Mas dê sempre um passo atrás antes de utilizar. Entenda o seu problema, o seu contexto, e a que se propõe cada ferramenta. Caso contrário, você passará a ter dois problemas: o problema que já tinha e o problema criado pelo desperdício de tempo e recursos por utilizar algo que não resolveu o problema anterior. Aí sim, Scrum, Kanban, Management 3.0, Design Thinking, etc, podem sim ajudar bastante.
Mas lembre-se: não é sobre o processo, a abordagem ou as ferramentas utilizadas. É sobre como as escolhe, onde e como são utilizadas.
Se a frase do início do texto parece pessimista, que George. P. Box me permita parafraseá-lo, de uma maneira mais otimista, porém, com boa dose de realidade:
“Todas as ferramentas são úteis, desde que você não as utilize onde não se precisa delas!”
