Metodologias ágeis: a “doutrinação ágil” e seus exageros

Certamente não é um título de artigo que os “agilistas puro-sangue” , como gosto de chamar os radicais, gostam de ver. Tudo bem; expor a opinião, principalmente em tempos de polarização no Brasil é complicado mesmo. Mas antes de discorrer sobre o assunto, quero dizer algo importante. Me considero também um agilista, adoro o conceito ágil e tudo o que ele representa. Porém não sou um “agilista puro-sangue“. Se eu pudesse quantificar a minha composição como profissional em gerenciamento de projetos, eu diria que sou 50% “tradicionalista”e 50% “Agilista”. Eu entendo que o ágil é muito mais que um manifesto ou frameworks… é uma forma de pensar e de agir. Whatever, vamos ao que interessa.

Acho o conceito ágil ótimo! É dinâmico, inovador e de fácil entendimento. O Ágil coloca o foco no cliente e suas necessidades, dá empoderamento ao time, entende que o planejamento é importante, porém as mudanças acontecem, os resultados são transparentes a todos. Isso é fantástico! Por isso também me preocupei em conhecer melhor as metodologias, principalmente o Scrum, onde inclusive me certifiquei. Enfim, as palavras que seguirão abaixo dão conta apenas a minha humilde opinião sobre o contexto onde o ágil está empregado hoje, tudo bem? Não levem pro lado pessoal. Vamos analisar, primeiramente, o conceito em si!

O Manifesto Ágil (2001) nasceu claramente de uma insatisfação de alguns profissionais com a forma em que os projetos de desenvolvimento de software eram conduzidos e o que eles efetivamente produziam como valor. Porém é claramente mal-interpretado pela maioria dos seus seguidores. Isso é tão evidente que, tanto no curso que fiz em 2015, quanto em conversas com amigos “agilistas”, todos são categóricos em dizer que o Agile abomina documentação, processos, ferramentas, planos e gerentes de projetos (segundo os agilistas, ‘o cara que só quer mandar’). O que não é verdade. Ao acessar o site do AgileManifesto.org, fica muito claro que há uma preferência em alguns valores em detrimento a outros, porém não excluem sua importância.

“Indivíduos e interações MAIS QUE processos e ferramentas;
Software em funcionamento MAIS QUE documentação abrangente;
Colaboração com o cliente MAIS QUE negociação de contratos;
Responder a mudanças MAIS QUE seguir um plano.

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.“

Então é possível observar que é apenas uma questão de interpretação do texto; e estão interpretando erradamente. Não é que não precise de planejamento, processos ou documentações, mas para os “agilistas puro-sangue”, responder à mudanças é mais valorizado, por exemplo!

Essa má interpretação levou algumas pessoas a instituírem um certo maniqueísmo quando se trata do método de gestão: “de que lado você está?”… “você é ágil ou lento?”. Imediatamente os métodos ágeis começaram a ser rotulados como O FUTURO… aquilo que há de mais moderno. Uma série de consultores “brotaram dos confins da terra” para desenvolver produtos (palestras, metodologias, ferramentas e treinamentos) visando ganhar um trocado nesse nicho de mercado. Aproveitaram também a moda de se auto-intitular Coach e já existem os Agile Coaches! Artigos e posts diários enfatizando a necessidade da adoção dos métodos ágeis para geração de valor nas organizações. Imersão, “Gameficação” e treinamentos usando Leggo® são apenas algumas das mais diversas abordagens quando se trata da comercialização da agilidade no mercado. Ao mesmo tempo o modelo de gestão, ao qual muitos chamam de “tradicional”, começou a ser rotulado como antiquado, rígido, ineficiente, etc.

Mas por que rotular o certo e o errado? O bom e o ruim?

Na verdade, essa rotulagem é boba e notoriamente forçada. Li um artigo do Steve Messenger, diretor da Agile Business Consortium, onde ele deixa a entender que, sem a implementação das metodologias ágeis, muitas organizações perderão espaço no mercado. Obviamente essa afirmação de cunho apocalíptico é expressamente regada de paixão, quase um show do Wando rodeado de calcinhas no palco. A metodologia de gestão adotada, obviamente, pode influenciar nos resultados das empresas, porém não é um método ou padrão de gestão de projetos que vai definir se uma empresa e seu portfólio de produtos e serviços vai perder força no mercado ou não.

Uma parte desta “evangelização” dá conta de que todo e qualquer tipo de projeto pode ser gerenciado utilizando métodos ágeis puros. Por mais que eu adore o mundo ágil, este é um sério ponto de divergência, pelo menos da minha parte. Para projetos de software e P&D, por exemplo, os métodos ágeis caem como uma luva. Isso se deve muito ao fato desse tipo de projeto não ter um escopo muito bem definido, visto que muitos clientes moldam o escopo durante a execução do projeto. Mas é preciso avaliar o todo. Você acha, por exemplo, que seria viável eu (como Gerente de Projetos) abrir mão de documentação e  negociação de contratos em projetos de capital, como uma Hidroelétrica ou uma Plataforma de Petróleo? Imagina gerenciar tudo isso apenas com post-its, daily scrum e retrospectivas? Seria bem complicado, não acha? 

– Então eu não poderia usar cerimônias e artefatos dos métodos ágeis em um projeto de construção de uma hidroelétrica, por exemplo?

– Claro! Se valer do que há de melhor nos métodos ágeis para agregar na gestão de megaprojetos como este é super bem-vindo. Mas não dá pra usar a metodologia pura porque, geralmente, ela é pensada para atender uma demanda específica, tipo o desenvolvimento de softwares, por mais que se tente incansavelmente provar que não.

Quer um exemplo prático? Vamos lá… o conceito ágil diz que o importante é entregar valor através de funcionalidades e não esperar para entregar tudo no fim do projeto, perfeito? Ok, pensa no seguinte… quando gerenciamos um projeto de criação de um ERP, por exemplo, temos várias entregas, vários módulos. Cada módulo tem uma série de funcionalidades e entregando uma série de funcionalidades ao cliente no final de cada sprint, ele já poderá usufruir, de alguma forma, do produto contratado. Se eu pego uma hidroelétrica, do que adianta, no final de um sprint de 4 semanas ou até mesmo 8 (para se adequar a realidade), entregar uma comporta sem turbina ou geradores? Como calcular o tempo de cada atividade de forma a pontuar a velocidade do Team Scrum em cada sprint, se boa parte das estórias (entregáveis) tem dependência com fatores externos ao time como equipamentos, meteorologia, licenças e maquinário?

– E sobre as equipes auto-gerenciáveis? Não precisaremos mais de um GP, correto?

Talvez não, talvez sim! Essa questão foi um ponto que o Scrum e outras metodologias baseadas no Ágil tentaram excluir, porém o Management 3.0 (que também foi baseado no Manifesto Ágil) trouxe o entendimento de que o gestor não deve deixar de existir, porém a gestão deve ser compartilhada. Ser auto-gerenciável não é fazer o que você quer no tempo que você acha que dá pra fazer, e sim, saber exatamente o que fazer e como fazer. Por isso que eu considero o Management 3.0 a peça do quebra-cabeças que faltava para que o Manifesto Ágil fizesse realmente sentido para todo e qualquer tipo de projeto e organização.

Portanto, acredito que os métodos ágeis trouxeram ótimas ideias que podem ser aproveitadas por todo tipo de indústria, não só a de desenvolvimento. Trabalhando em qualquer outro tipo de projeto fora do universo do desenvolvimento de software, eu prefiro ser um pouco mais cauteloso com a adoção de metodologias ágeis puras, como o Scrum! Acho que o melhor sempre é utilizar o que cada método ou padrão tem de bom, sem paixões, sem maniqueísmo e sem previsões apocalípticas. No fim das contas, o importante mesmo é entregarmos nossos projetos e satisfazermos nossos clientes, não importa qual tipo de método ou padrão você irá utilizar.

Sobre o Colunista:

Wagner Borba, Gerente de Projetos da Tecnoset IT Solutions. Graduado em Gestão da Tecnologia da Informação pela FG/Laureate International Universities de Pernambuco e MBA em Gestão de Projetos pela Universidade Estácio de Sá. Possui certificado Project Management Professional (PMP®) pelo PMI, Certified ScrumMaster (CSM®) pela Scrum Alliance, International Product Owner Foundation (IPOF) pela Scrum Association e Lean Six Sigma Yellow Belt (SSYB). Possui 10 anos de experiência em projetos nas áreas de Telecomunicações e Tecnologia da Informação em empresas multinacionais como Alcatel-Lucent, Isolux Corsan e Huawei Technologies, atuando em projetos de grande porte para as maiores operadoras de telefonia do país. Também atuou como consultor em gerenciamento de projetos para empresas das áreas de TI, Saúde Ambiental, Construção Civil e Logística. Hoje atua com projetos de TI e Serviços voltados para o setor público e preside o Conselho Fiscal do PMI-PE. Email de contato: wagner.borba@pmipe.org.br /wborbaconsultoria@gmail.com

Se você tem comentários, sugestões ou alguma dúvida que gostaria de esclarecer, aproveite o espaço a seguir.