Quando o ágil vira o vilão

Por que os agilistas podem ser uma ameaça para o sucesso do seu projeto de desenvolvimento de software.

Em projetos de desenvolvimento de software, o método cascata (waterfall), que instrui um fluxo seqüencial e com fases de atividades do projeto, tem sido usado por décadas até que pesquisas e estudos de caso mostrassem que uma abordagem iterativa alternativa e, portanto, mais flexível (amplamente conhecida como Agile) seria mais adequada, promissora e com maiores chances de sucesso no projeto.

De fato, estatísticas e pesquisas mostraram que metodologias ágeis (com vários sabores, como Scrum, Kanban, XP, etc.) levam a uma maior satisfação das partes interessadas, principalmente porque é responsável pela dinâmica dos ambientes de negócios atuais e pelo fato resultante de que o escopo do projeto geralmente não permanece o mesmo durante o ciclo de vida de um projeto e, portanto, permite acomodar as mudanças ao longo do caminho.

Com alguns benefícios claros, a metodologia Agile se tornou bastante popular e eu sempre ouvimos o pessoal de TI dizer com orgulho: "Estamos ágeis agora!" avançando do modelo tradicional em cascata para o método ágil moderno e que agora podem ter mais sucesso com as entregas dos projetos.

Essa, porém, é uma maneira perigosa de pensar, que na verdade poderia levar ao contrário, ao fracasso do projeto.

O Agile não é uma metodologia de "tudo para todos", mas apenas outro método que pode ser escolhido para um determinado projeto. A ênfase aqui está no "poderia", uma vez que um gerente de projeto deve ter as habilidades e a capacidade de analisar vários fatores em um ambiente de projeto, para determinar a metodologia mais adequada que prometa um resultado bem-sucedido de um projeto.

A tabela abaixo mostra as características e os fatores a serem levados em consideração, para o gerente de projeto determinar qual metodologia é mais adequada para o projeto:

Portanto, é preciso ter cuidado com os chamados agilistas que afirmam que o Agile é o único caminho a seguir em qualquer projeto. Em alguns casos, você também ouve falar sobre empresas ou líderes de departamento de TI que determinam que suas equipes apliquem o Agile a qualquer projeto daqui para frente - certamente uma abordagem muito errada que indica que esses agilistas têm uma visão muito limitada e altamente tendenciosa dos conceitos de entrega do projeto.

O que é um Agilista?

Agilistas são geralmente as pessoas que têm forte entusiasmo e conhecimento de metodologias ágeis, geralmente também suportadas por várias certificações profissionais, por exemplo, Scrum Master, SAFe Agilist, etc. Em muitos casos, os agilistas desenvolvem um viés muito forte em relação às metodologias ágeis.

Podemos separar três tipos de agilistas e suas atitudes relacionadas:

O Agilista Autocrático - “O Agile deve ser aplicado a todos os projetos de desenvolvimento de software, sem exceção. É a única maneira de entregar um projeto com sucesso.”

Essa pessoa é fortemente direcionada à metodologia ágil, provavelmente devido às conquistas obtidas até agora em projetos de desenvolvimento de software usando o Agile. Ele/ela se tornou um especialista em gerenciar/liderar projetos ágeis.

O Agilista Desconhecido - “Nunca ouvi nada além de Agile.”

Esse tipo de agilista geralmente pode ser encontrado na geração mais jovem, alguns dos quais nem nasceram quando o manifesto Agile foi escrito (2001). Essa pessoa nunca fez parte de nenhum projeto não-ágil, nem tem conhecimento dos conceitos tradicionais do cascata.

O Agilista Democrático - "Sou especialista em métodos de entregas ágeis, mas também sou especialista nos métodos de entrega tradicionais”.

Ter uma sólida experiência em métodos ágeis não significa que é necessário limitar-se a apenas uma metodologia. Em vez disso, esse tipo de agilista tenta ser especialista em métodos de entrega ágeis e tradicionais, aprendendo continuamente sobre vários modelos de entrega e é capaz de aplicar os dois.

A menos que um gerente de projeto seja um agilista do tipo 3 (“Agilista Democrático”), ele deve ser rotulado como um risco crítico para o projeto, pois uma metodologia ágil pode ser potencialmente a escolha errada e levar ao fracasso do projeto.

Exemplo:

Imagine que você quer fazer uma viagem de A a B e precisa chegar o mais rápido possível. Você tem duas maneiras de alcançá-lo: usando seu carro ou usando uma bicicleta.

Alguém que sempre usaria o carro e desconsideraria qualquer outro meio poderia alcançar o objetivo perfeitamente. Mas isso provavelmente depende da distância entre A e B. Se demorar 160 km para ir de A a B, o carro provavelmente é a melhor aposta, mas se B estiver a apenas 2 minutos de A, provavelmente você deve bicicleta para chegar lá o mais rápido possível.

Portanto, deve-se tomar cuidado com os agilistas “autocráticos” e “desconhecidos” encarregados das entregas do projeto, que chegam rapidamente à conclusão de que um projeto deve ser entregue de maneira ágil.

Não interpretem mal este artigo, pois não somos contra o Agile, inclusive fornecemos cursos de certificação SCRUM em parceria com a SCRUMStudy, e acredito ainda que esta dinâmica realmente trás muitos resultados positivos para projetos de desenvolvimento de software e multidisciplinares. O que deve se ter em mente é nunca desconsiderar a metodologia cascata sem antes fazer uma análise técnica do projeto.

Simplesmente não há metodologias boas e ruins, pois quando se trata de escolher uma metodologia de entrega. É mais um "depende".

O gerente de projeto mais bem-sucedido é aquele que pode ser ambos: ágil e tradicional.

Tradução e adaptação original do artigo When Agile is Evil de Marcus Glowasz