Ágil - Teoria vs. Prática

Quando processos ágeis falham?

Eu trabalhei em uma série de projetos ágeis ao longo de minha carreira de 13 anos, e minha experiência com Ágil tem sido um misto de satisfação e desafios. Eu estava, portanto, muito animado com a oportunidade de trabalhar com os geeks que escreveram o livro sobre Ágil, e desde então adquiri uma compreensão mais global de seus conceitos e práticas, juntamente de seus prós e contras.

Eu cheguei à conclusão que o principal motivo pelo qual muitos esforços para implantar processos ágeis falham, é que profissionais tendem a esquecer que o manifesto é uma declaração de ideais utópicos a se aspirar. Quaisquer práticas prescritivas que resultem dele, como Scrum e Kanban são simplesmente tentativas práticas de se progredir em direção a esse ideal. Entretanto, devido à natureza do princípio, nenhuma dessas práticas poderão realmente alcançar o ideal. Algumas aproximam-se mais que outras, mas a agilidade absoluta não poderá nunca ser alcançada na prática.

Na prática, ser ágil é simplesmente um compromisso máximo com limitação ambientais. Quando muitas gerências recentes ao princípio entram em armadilhas e frustrações na sua implantação de práticas ágeis (como por exemplo, programação pareada, TDD, Iterações etc.) elas infelizmente se sentem desencorajadas. Elas então, erroneamente, acreditam que essas frustrações podem ser resolvidas impondo rigidamente atividades ainda mais prescritivas ao time. Lentamente, o projeto entra em um ciclo vicioso em direção a um fracasso abismal. E quem elas culpam? Os processos ágeis.

Uma compreensão das limitações contextuais de metodologias práticas ágeis em se alcançar os princípios utópicos permite uma compreensão de como e por que esses projetos falham. Para se entender por que, quando e como estas falhas em processos ágeis acontecem, vamos examinar alguns dos princípios ágeis fundamentais, e ver onde o conflito ocorre. Como uma declaração sobre os princípios gerais que devem reger a entrega de sistemas de TI, o Manifesto Ágil pode ser resumido em três questões mais amplas: Transparência, Verificação e Adaptação.

#1 Transparência

Através da transparência nos empenhamos para garantir que todos os aspectos que afetam o resultado do projeto estejam visíveis e sejam de conhecimento de todos em todo o processo de entrega para a gerência do projeto. No entanto, em muitos cenários do mundo real, a transparência nos detalhes intrincados e complexos torna-se, na melhor das hipóteses, mais cara do que benéfica, e, na pior das hipóteses, impossível de se alcançar através da miríade de times e indivíduos envolvidos.

Vamos considerar a transparência ao se entregar um Sistema Nacional de Saúde (National Health System - NHS). Pela própria natureza do projeto, toda a população do país é agora um usuário. Pelo alto custo dessa operação, seria impossível fazer uma pesquisa que representasse os inúmeros pontos de vista e opiniões da população do país com todos os usuários. Então nós decidimos ignorar o problema interagindo com os membros do governo que alegam representar os cidadãos. Do ponto de vista do manifesto Ágil não conseguimos envolver completamente todas as partes interessadas. Ao sermos confrontados com um sentimento público negativo, estamos totalmente dependentes dos políticos para nos proteger das consequências. No entanto, eles também têm suas próprias segundas intenções e transparência não é algo comumente conhecido como uma característica popular entre políticos. Além disso, ainda existe o grande número de instalações clínicas privadas e públicas que precisam ser incluídas. Podemos realmente manter a transparência de uma maneira efetiva, em uma nação de dezenas de milhões de pessoas, suas entidades organizacionais, afiliações políticas e preocupações familiares, com o objetivo de entregar a solução requisitada? O governo do Reino Unido decidiu que tal situação seria melhor tratada por soluções como Prince2 e só utiliza Ágil para as entregas de software bem definidas. Dito isto, esta posição parece estar mudando.

Considere o desenvolvimento do Linux, que leva esta questão a um outro nível de complexidade - manter transparência entre todos os fornecedores de software, fabricantes de drivers, usuários do software, técnicos de sistema operacional (efetivamente, toda a população do mundo) - uma tarefa que significaria que o projeto nunca sairia do papel. O que Linus Torvalds fez foi colocar-se no núcleo do problema e gradualmente aumentar o número de pessoas introduzidas até que ele tivesse impulso para incluir todos. Ele era inicialmente a única parte interessada.

E isto não é necessariamente um problema em se escalar, mas com a cultura também. Eu trabalhei em projetos de menor escala, onde o time estava ansioso para adotar processos ágeis, mas a perspectiva de negócios tinha menos foco/dependência em tecnologia e era mais centrada em cumprimento de regras/normas. Neste cenário, gerências de tecnologia motivadas estavam introduzindo um novo processo de entrega de tecnologia que a empresa não estava convencida que era necessário. A participação da empresa seria essencial para se obter a transparência necessária para desenvolver este processo. Infelizmente, a empresa considerou-o menos importante que reuniões e decisões de conselho/políticas internas. Implantar Ágil nessa atmosfera foi em grande parte doloroso e um total fracasso.

#2 Verificação

Agora vamos considerar a Verificação. Desejamos que vários aspectos do projeto sejam verificados com uma frequência suficiente para identificar variações inaceitáveis do processo​. Gostaríamos de conseguir "falhar rápido". Usando o exemplo do NHS acima, o software é normalmente apenas uma pequena parte insignificante do projeto, dificultando, portanto, o envolvimento de uma massa crítica de partes interessadas em sua verificação regular, o que na prática dilui a atividade. Até mesmo definir o que seria um processo/resultado "aceitável" da verificação torna-se difícil. Adicionalmente, Variações do processo esperado provavelmente apresentarão erros e não podem ser normalizadas, mesmo se obtidas de um processo de verificação bem-sucedido, devido à magnitude e complexidade do projeto. Descobrir o que não é aceitável, torna-se então quase impossível devido às complexas questões acima. Então, como seria possível conseguir falhar rápido? O processo de se falhar rápido está ao menos definido nestas circunstâncias? Além disso, o processo de Verificação também pode ter consequências não intencionais no que foi verificado. É possível citar como exemplo, jogos de alto nível, e verificar apenas por verificar, uma questão que vi frequentemente até mesmo em projetos de pequena escala.

#3 Adaptação

Agora, suponha que os problemas de transparência e verificação sejam resolvidos, ainda temos mais um, a adaptação. Se a verificação determinar que um ou mais aspectos do processo está fora dos limites aceitáveis ​​para produzir um produto aceitável, então a pessoa que o verificou deve estar apta a ajustar o processo de forma rápida e eficaz. Como você se empenha em começar a ajustar com sucesso um processo que envolve milhões de partes interessadas, junto das suas interações complexas em níveis individuais, políticos e organizacionais? Neste caso, qualquer decisão adaptativa feita é na melhor das hipóteses uma ditadura das vozes que falarão mais alto por aqueles que não podem ser ouvidos. Na pior das hipóteses, é uma anulação de um conhecimento que não existe ou não pode ser alcançado, levando todo o processo a uma anarquia.

Há resultados que não podem ser alcançados usando metodologias ágeis de gerenciamento de projetos, como provar a teoria da Relatividade de Einstein, mas, em essência, o resultado evoluiu para um ambiente ágil e auto organizado. Outros, como o Linux, são inerentemente ágeis sem nenhuma metodologia ágil prescritiva que pode ser compreendida por gerentes de projeto. Ágil é uma grande aspiração utópica, e é inerentemente impossível realizá-lo completamente e perfeitamente através de uma prática doutrinária. Existem sistemas de gerenciamento de projetos de alto nível dentro dos quais é permitido que processos ágeis se concentrem em áreas/funcionalidades bem definidas, por exemplo, o Prince2/PMBOK. As razões pelas quais muitas gerências de projeto não conseguem ter sucesso em ágil é porque elas estão à procura de algo a se FAZER para alcançá-lo. Ser ágil não é manter o controle de um projeto através de Scrum/Kanban, trata-se de contratar as pessoas certas para a posição, e lhes permitir descobrir naturalmente a configuração ideal do projeto para entregar seu produto com sucesso.