Já faz algum tempo que os métodos ágeis estão na moda. E com bom motivo. As ideias por trás deles são sólidas e vieram para ficar.

Mas, em muitos casos, a adoção de métodos ágeis não resolveu os problemas que se propunham a solucionar e ainda criaram problemas novos.

No auge de sua fama, criaram-se “igrejinhas” que iniciaram uma “Guerra Santa” entre Waterfall e Agilidade.

Essa guerra, na minha opinião, não faz sentido, porque ambos os lados estão parcialmente certos e apresentam argumentos sólidos para suas posições. A solução, como quase sempre, está em algum tipo de meio termo.

Mas, de qualquer forma, ambos os lados desta guerra sofrem com a falta de Visão Holística. Pode ser argumentado que a adoção em massa de métodos ágeis não só não resolveu, mas aprofundou o problema dos Silos de Informação que já existiam nos métodos mais antigos.

Histórico dos Métodos Ágeis

Os métodos ágeis surgiram no contexto do desenvolvimento de software e depois se expandiram para outras atividades dentro das empresas.

É bom lembrar que, no contexto do desenvolvimento de software, as ideias por trás dos métodos ágeis não podem de forma alguma serem consideradas novas. As discussões sobre o assunto se iniciaram na década de 1950. Meu primeiro contato pessoal com o assunto foi através do RAD (Rapid Application Development) e do “ciclo de vida espiral” de Barry Boehm (anos 80 e 90). Depois veio a moda do “desenvolvimento iterativo e incremental” e do “Unified Process“,  mais tarde o XP (Extreme Programming), o SCRUM, o PSP/TSP de Watts Humphrey e, finalmente, o “Manifesto Ágil” em 2001.

Em comum, todos esses métodos têm como características as seguintes ideias de fundo:  fazer “as coisas” de forma incremental, em ciclos curtos de tempo (normalmente fixos – Time Boxes), usando um time multidisciplinar que interage próxima e frequentemente com os usuários ou clientes das “coisas” que estão sendo criadas.

Coloco “coisas” entre aspas porque, no início, essas “coisas” eram exclusivamente software, mas, posteriormente, os sucessos alcançados levaram à expansão do conceito para outras áreas.  Hoje vemos Planejamento Estratégico Ágil, Desenvolvimento Ágil de Novos Produtos, Arquitetura Corporativa Ágil e até mesmo Gestão de Pessoas Ágil. O conceito, definitivamente, “pegou”.

Benefícios e Limitações dos Métodos Ágeis

De forma geral, os benefícios dos métodos ágeis são bem conhecidos: entregas mais rápidas e mais aderentes às necessidades dos clientes figuram entre as mais importantes. Há uma literatura imensa disponível na internet sobre esses benefícios e, portanto, não tenho intenção aqui de entrar em detalhes. 

Por outro lado, alguém importante no ecossistema de métodos ágeis (Scott Ambler talvez, mas não me recordo exatamente) disse alguma coisa como “métodos ágeis funcionam quando sua empresa tem um único software para ser desenvolvido”.  Pode parecer uma declaração bombástica e exagerada, mas não está muito longe da verdade, especialmente quando levamos em conta apenas a primeira geração de métodos ágeis. Esses métodos eram nada mais nada menos do que métodos de gestão de projetos e, portanto, aplicáveis individualmente a cada projeto, sem levar em conta a visão do todo, sistêmica, ou seja, aquilo que costumo chamar de Visão Holística.

Em um ambiente de muitos sistemas complexos e interligados, projetos ágeis tem grande dificuldade em prover a integração necessária e em reduzir ou impedir redundância e retrabalho.

Não demorou muito para que essas limitações fossem percebidas, especialmente quando os métodos ágeis começaram a ser usados em peso em grandes empresas.

Por conta disso, muitas soluções para essa questão foram propostas.

Soluções e suas Respectivas Limitações

Talvez a mais famosa dessas propostas de solução seja o SAFe (Scaled Agile Framework), embora existam muitas outras como o DAD (Disciplined Agile Delivery) – esse último do próprio Scott Ambler. Há algum tempo, fiz um webinar discutindo esses frameworks e sua aplicabilidade em relação a Arquitetura Corporativa de Negócio, especialmente diante da questão de se é possível ter uma Arquitetura Corporativa Ágil. Você pode rever essa discussão aqui.

Embora essas propostas ajudem a resolver várias das limitações dos métodos ágeis “puros”, elas ainda contam com as suas próprias limitações. Ou seja, não chegaram a uma Visão Holística completa por ainda estarem muito limitadas, por seu contexto histórico, a processos parciais dentro das empresas; em particular, à tecnologia da informação e o desenvolvimento de software.

Visão Holística: Agilidade com Contexto

A Visão Holística, como tenho defendido em vários artigos, parte da visão tripartite das organizações, ou seja,  da adoção da metáfora humana às empresas, vendo-as como um composto de Mente (Estratégia), Corpo (Arquitetura Corporativa de Negócio) e Alma (Propósito e Cultura Organizacional Intencional).

Embora o SAFe e outras propostas mais recentes toquem nos assuntos de arquitetura e cultura, eles ainda o fazem de maneira ambígua e superficial. Precisamos ir mais longe.

Para termos de verdade uma Visão Holística, Precisamos de colaboradores que sejam mais generalistas e tenham visão sistêmica e um conjunto de soft skills fundamental, do qual muito se fala, mas pouco se faz.

 Um possível caminho para atingirmos esse estado passa pelas seguintes etapas:

  1. Adoção de uma prática de Arquitetura Corporativa
  2. Adoção de práticas que levem a empresa a uma Cultura Intencional
  3. Modificação na forma atual de se fazer planejamento estratégico, passando a ver a Estratégia como algo inseparável da Arquitetura e da Cultura
  4. Desenvolvimento dos Soft Skills dos colaboradores

Já falei de alguns desses assuntos em artigos recentes (e nem tão recentes) que estão listados no link acima para quem quiser se aprofundar. Mas voltarei a eles todos entrando em mais detalhes sobre cada uma dessas etapas em artigos futuros.

Por enquanto, recomendo a minha playlist no YouTube “O que é um negócio” onde esses assuntos são tratados em mais detalhe.

Mas o resumo da Ópera é o seguinte: métodos ágeis são ótimos, mas, tomados isoladamente, são “sub-ótimos”, ou seja, soluções parciais que, se não tomarmos cuidado, produzem mais problemas do que aqueles que estávamos tentando resolver.

 

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *