Falsa agilidade: O que é? Onde vive? Do que se alimenta?

Unlike other posts, this one will be in portuguese because it is a translation of an awesome article entitled What is Fake Agile? Understanding the Dark Side of Agile and How to Avoid It. The company I work is migrating to agile and this article seems to describe everything it's happening here. 😅


A empresa em que trabalho vai começar a usar Agile, de uma hora pra outra vamos do Waterfall pro Scrum, sem meio termo. Tem tudo pra dar certo, não é mesmo? Não sei se por causa das conversas que tenho tido aqui, mas o Google me sugeriu esse artigo e ele destrincha muita coisa que acontece aqui e que com certeza acontece por aí também. Senta que lá vem textão...

O que é o falsa agilidade? Entendendo o lado negro da agilidade e como evita-lo

Agile é um chavão. Hoje em dia todo mundo está "fazendo agile". Ou é o que eles dizem.

Apesar de mais de 90% dos executivos seniors declarar que a adoção do agile é uma prioridade máxima, menos de 10% realmente considera que suas companhias estão performando com um alto nível de agilidade.

Por mais que as pessoas adorem usar o crachá da agilidade, existe muita confusão entre o grande abismo que é querer implementar o agile e a realidade.

Então, o que é agile?

Basicamente é uma filosofia de desenvolvimento de software que prioriza desenvolvimento iterativo de soluções e sistemas funcionando através de colaboração e equipes auto-organizadas.

É também um termo guarda-chuva para várias ferramentas de desenvolvimento, agilidade não significa simplesmente kanban ou scrum.

Muita confusão vem do fato de times equalizarem a abordagem agile com o uso de uma "ferramenta Agile" (geralmente em letra maiúscula mesmo).

Essas ferramentas são atrativas por que são vendidas como soluções simplificadas para problemas difíceis de gerenciamento de projetos e processos.

Claro, essas ferramentas são uma parte importante da implementação do agile, mas é preciso mais. É preciso uma base firme para se sustentar.

Não é suficiente apenas seguir a maré e esperar que essa abordagem "apenas funcione", especialmente quando se está migrando de uma ferramenta mais rígida e tradicional como o cascata.

Para ter sucesso na agilidade, os times precisam adotar a filosofia ágil. Eles precisam mudar a forma de pensar sobre a posse do trabalho, gerenciamento e sua relação com os consumidores.

Sem essa força vital, ferramentas como scrum e kanban caem duras no chão.

Nesse artigo irei investigar o que separa a verdadeira agilidade da falsa, que é o diferencial entre sucesso e falha do time de desenvolvimento.

Bem vindo ao obscuro teatro da agilidade...

Céticos da agilidade parecem ter uma obsessão com o macabro. Aqui estão alguns termos que surgiram para descrever o fenômeno ao qual esse artigo se refere como "falsa agilidade".

A lista continua. O que eles tem em comum, além da metáfora grotesca, é a falta da centelha necessária para facilitar o verdadeiro sucesso da agilidade.

O que é a falsa agilidade?

Primeiro, não existe uma avaliação padronizada para medir agilidade. Agilidade é uma filosofia, mais do que é uma ferramenta. Ou pelo menos era, originalmente.

Isso fica claro na sentença "seja ágil", em contraste com "faça agilidade".

A diferença aqui é que "sendo" ágil, não deveria importar qual ferramenta você usa, por que certos valores chave são encorajados. Basicamente, todas as "verdadeiras" ferramentas ágeis irão compartilhar desses mesmos valores.

Aqui está um diagrama útil do Departamento de Defesa dos Estados Unidos ilustrando a diferença fundamental entre uma ferramenta ágil de sucesso e o que eles chamam de "Agile BS":

Gráfico detalhando o Agile BS de acordo com o Departamento de Defesa dos Estados Unidos fonte

Por outro lado, a falsa agilidade é um desperdício. Um processo quebrado.

Quando times produzem uma grande quantidade de trabalho com a intenção de facilitar o feedback do cliente, haverá muito desperdício; muitas coisas que apenas não atingem o objetivo.

Seja devido a uma gestão pesada e não democrática forçando suas agendas ágeis sobre os desenvolvedores que simplesmente não estão prontos para isso, ou a líderes de projeto bem intencionados buscando melhorar a produtividade dos seus times através da implementação da metodologia da moda, a raiz da falsa agilidade é um sistema que não está performando tão bem quanto poderia.

Mais especificamente, a falsa agilidade é falsa por que não está de fato defendendo os princípios da agilidade. Agilidade falsa é mudar o nome de metodologias tradicionais como o cascata com jargões.

Modelo cascata por trás de uma fachada de agilidade Fonte

Por que a falsa agilidade é prejudicial para os seus times

Parafraseando Ron Jeffries, que cunhou o termo Dark Scrum em um contexto levemente diferente:

"O scrum, mesmo feito razoavelmente bem, é um bom framework. Sou bastante sincero quanto a isso. É bom ter uma forte conexão com a área de negócio decidindo o que precisa ser feito e o que precisa ser adiado. É bom ter todas as habilidades que você precisa para desenvolver o produto diretamente no time. É bom construir um produto tangível testado a cada poucas semanas, e é bom mostrar isso para os investidores, e é bom revisar como as coisas aconteceram e como melhorar. Eu estudei, trabalhei e pensei sobre Scrum por anos, e tudo sobre ele é realmente bem bom. Não é perfeito, mas é bem bom."

-- Ron Jeffries, um dos criadores da metodologia de desenvolvimento de sistemas Extreme Programming

Jeffries estava falando especificamente sobre scrum, mas o ponto pode ser extrapolado para os abusos da agilidade em geral. Como um ideal bem executado, a agilidade pode ser muito boa, mas a realidade muitas vezes não está alinhada com o conceito.

Essa incompatibilidade é chamada de falsa agilidade. O que tem de tão ruim nisso?

Vamos dar uma olhada em algumas crenças comuns de times que defendem a tão falada abordagem ágil:

"Somos muito mais produtivos agora que somos ágeis"

"Pessoas sobre processos!"

"Software funcionando é mais importante que documentação!"

"Adaptabilidade e desenvoltura são habilidades mais valiosas do que sua capacidade de seguir um plano!"

Mesmo que exista verdade nessas declarações muitas implementações ágeis torcem elas em uma meia verdade bruta que falta a força vital que todo time ágeil precisa - um entendimento adequado por trás do ágil.

Gabrielle Benefield dá uma clara explicação dos perigos dessas abordagens ágeis em sua conferência intitulada Frankenbuilds; se agilidade é tão bom, por que nossos produtos são tão ruins?

Eu recomendaria toda a apresentação, mas para resumir, o ponto dela é a super simplificação da agilidade em um sistema que prioriza quantidade sobre qualidade.

Ela argumenta que essa abordagem "metralhadora ágil" que pressiona os times a entregarem mais funcionalidades para aumentar as chances de entregar alguma coisa certa cria muito lixo.

Para melhor entender o perigo de uma abordagem de falsa agilidade inapropriada, considere esse exemplo:

Imagine um gerente de projetos que acabou de anunciar durante o encontro diário que, graças a sua nova abordagem ágil, o time entregou com sucesso 35 novas funcionalidades, dentro do prazo e do orçamento.

Estatísticas impressionante, mas quem vai usar essas funcionalidades? Como elas irão ajudar a empresa a fornecer mais valor aos clientes, e a fazer mais dinheiro? Por que 35 funcionalidades? Poderia o mesmo resultado ser atingido com duas ou três funcionalidades?

Falsa agilidade é "construir a coisa errada de forma certa". Não importa se você está usando kanban, scrum ou sua própria ferramenta se você não está construindo a coisa certa para início de conversa.

Falsa agilidade versus verdadeira agilidade: Como diferenciar

Linha do tempo da falsa agilidade Fonte

Mas chega de faíscas e caprichos, como você de fato diferencia entre agilidade real ou falsa?

Tem algumas coisas que você pode procurar. Eu listei algumas áreas chave e esclareci como a abordagem falsa pode se diferenciar da verdadeira.

Essa informação vem de várias fontes, mas principalmente do documento do Departamento de Defesa dos Estados Unidos, publicado em 9 de outubro de 2018.

Ignorando usuários

Verdadeira agilidade: desenvolvedores entendem a importância de comunicar e envolver os clientes e usuários no processo de desenvolvimento e entrega . Eles compartilham o progresso do desenvolvimento e buscam ativamente o feedback para que possa melhorar o processo ou o produto.

Falsa agilidade: desenvolvedores não estão interessados em se comunicar com os verdadeiros usuários da aplicação (teste e avaliação do programa não contam); Se existir algum feedback, não é contínuo (acontece apenas no começo do projeto, por exemplo).

Gestão do tempo e retornos decrescentes

Verdadeira agilidade: prioriza entregas funcionais e entende a importância de iterações rápidas. Novos incrementos de forma semanal ou pelo menos ao final de cada sprint.

Falsa agilidade: Atenção a requisitos sobre rápida entrega de alguma coisa útil. Raramente tem uma entrega funcional ao final da sprint; a entrega funcional é empurrada para uma sprint de ajuste ou para "a próxima sprint".

Responsabilidade

Verdadeira agilidade: Os desenvolvedores estão ativos e dispostos a assumir a responsabilidade por sua função de fornecer valor ao cliente e melhorar sua oferta.

Falsa agilidade: Desenvolvedores rejeitam a responsabilidade e agem como se não fosse o trabalho deles.

Processos simplificados

Verdadeira agilidade: Processos são automatizados tanto quanto possível para eliminar tarefas manuais tediosas e focar em entregar valor para o cliente.

Falsa agilidade: Processos são em sua maioria manuais; amplo espaço para automatização.

Importância da funcionalidade

Verdadeira agilidade: Foco em desenvolvimento iterativo de software funcional, onde o feedback dos principais patrocinadores são fundamentais a cada passo.

Falsa agilidade: Foco em conformidade e requisitos onde o software funcionar é um bom bônus que é normativamente empurrado para "outro sprint".

Liderança ágil equivocada

O papel da liderança ágil é muitas vezes mal interpretada. Muitas vezes os times terão papéis como scrum master e product owner, apenas para descobrir que, na prática, esses indivíduos estão executando as mesmas funções do gerente de projetos em qualquer ferramenta de desenvolvimento.

Um tema comum desse problema é a ideia de que deve haver "apenas uma garganta para apertar". Isso é esperado em estruturas tradicionais de desenvolvimento, onde o gerente de projetos é o responsável de certificar que cada membro do time está fazendo seu trabalho.

Agilidade é diferente por que a natureza da responsabilidade é fundamentalmente diferente. Pessoas envolvidas em um time de desenvolvimento ágil de alta performance devem ter um senso compartilhado de responsabilidade.

Nesse caso, a "única garganta para apertar" é a garganta coletiva de todo o time de desenvolvimento.

Product owners e scrum masters estão lá para executar papéis chave como se reportarem aos donos dos negócios e se comunicarem com os patrocinadores, mas seus papéis são fundamentalmente diferentes de um típico gerente de projetos.

Estrutura de um time ágil Fonte

Essa diferença na abordagem gerencial também destaca a diferença na atitude sobre punições e medo no ambiente de trabalho.

Se as pessoas tem medo de punição elas vão ver que se falharem sua criatividade e inovação serão suprimidas. Esse tipo de medo não motiva; simplemente gera números e desencoraja experimentações.

O medo da punição também afasta as pessoas da responsabilidade. Se seu time sabe que será escaldado se eles não performarem, eles inevitavelmente falharam mais por que as pessoas gastarão mais energia evitando a responsabilidade do que focando em fazer seu melhor trabalho.

Em busca da "verdadeira" agilidade

Filosofia ágil Fonte

"Nós queremos restabelecer um equilíbrio. Nós incluímos modelagem, mas não para arquivar algum diagrama em um depósito corporativo empoeirado. Nós incluímos documentações, mas não centenas de páginas de bíblias nunca atualizadas e raramente utilizadas. Nós planejamos, mas reconhecemos os limites do planejamento em um ambiente tumultuado."

-- Manifesto Ágil

O Manifesto Ágil foi escrito em 2001, na virada do século. É um começo óbvio para tentar entender o que significa "ser" ágil versus "fazer" ágil.

Para simplificar um pouco, pense dessa forma: "Ser" é a filosofia. "Fazer" é a ferramenta.

No fundo, é a filosofia que precede qualquer ferramenta ou metodologia individual. Cada ferramenta irá aplicar os valores e princípios de forma diferente, mas a fundação se mantem a mesma.

Por fim, o objetivo da "verdadeira" agilidade é guiar o desenvolvimento oportuno de sistemas funcionais e de alta qualidade com o melhor interesse do cliente em mente.

Quatro valores centrais da agilidade

O Manifesto Ágil descreve quatro valores centrais:

  • Indivíduos e interações sobre processos e ferramentas
  • Sistema funcionando sobre documentação completa
  • Colaboração com o cliente sobre negociação de contrato
  • Responder a mudanças sobre seguir um plano

Os 12 princípios da agilidade

E ele segue declarando 12 princípios adicionais:

  1. Clientes satisfeitos através da entrega contínua e adiantada de trabalho de valor
  2. Quebrar grandes trabalhos em pequenas tarefas que podem ser completadas rapidamente
  3. Reconhecer que o melhor trabalho surge de times auto organizados
  4. Prover a pessoas motivadas um ambiente e apoio que eles precisam e confiar que eles farão o serviço
  5. Criar processos que promovem esforços sustentáveis
  6. Manter um passo constante de trabalho completo
  7. Receber bem mudanças de requisitos, mesmo com o projeto adiantado
  8. Reunião diária entre os times de negócio e projeto por todo o projeto
  9. Fazer com que o time reflita em intervalos regulares sobre como se tornar mais efetivo, e então ajustar o comportamento de acordo
  10. Medir o progresso pela quantidade de serviço completado
  11. Buscar excelência continuamente
  12. Aproveitar a mudança para obter vantagem competitiva

Perguntas para ajudar a identificar um falso time ágil

Além de se perguntar sobre como a falsa agilidade se difere da verdadeira agilidade, você faria bem em perguntar diretamente aos seus times.

Geralmente você pode obter uma visão geral da forma como eles trabalham com perguntas simples como essas.

Pergunta 1: "Como você obtêm feedback?"

Agilidade depende de feedback dos clientes para funcionar direito.

Times de desenvolvimento menos experientes podem ficar satisfeitos com uma ou duas formas de feedback (que levam cerca de um mês para retornar) mas na verdade isso não é bom o suficiente.

Feedback ágil deve ser contínuo e presente em cada passo do ciclo de lançamento.

Times que vêem feedback como exceção são os que não estão fazendo ágil direito.

Pergunta 2: "Quanto o time planejou no projeto para acomodar feedback do cliente?"

Receber feedback é o primeiro passo, mas a menos que o time tenha uma infraestrutura funcional para avaliar e implementar esse feedback como parte do seu ciclo de desenvolvimento, é tão bom quanto uma folha de papel em branco.

Uma parte importante dessa consideração é o planejamento da equipe.

Quanto do planejamento é reservado para se dedicar ao feedback, ou em outras palavras, quanto é reservado para o desconhecido?

A resposta para essa pergunta pode ser confusa, nesse caso fica claro que falta um entendimento correto da agilidade.

Verdadeiros times ágeis administram as implicações dos feedbacks dos clientes por que eles reconhecem esse retorno como um trabalho base para prover o cliente com o máximo de valor possível.

A necessidade de treinamento ágil

Os empregados precisam entender a filosofia por trás da abordagem ágil.

É importante que todo mundo entenda como "ser" ágil bem como "ser" ágil.

Muito da confusão e das falhas da abordagem AINO (Agile In Name Only) vem da falta de treinamento ágil apropriado.

Segue alguns motivos pelo qual é super importante que você gaste tempo em treinamento ágil.

Alto custo, zero recompensa

Você tem certeza de que está de fato se beneficiando da sua implementação ágil? Mudar para uma ferramenta de desenvolvimento ágil incorre em sobrecarga extra e, se não houver treinamento apropriado, esse custo adicional se torna um gasto.

Simplesmente adicionar uma reunião em pé e chamar o mês de sprint não vai magicamente transformar seus processos em ágeis. Falar para o seu time que eles são auto organizáveis enquanto você continua delegando trabalho da mesma forma que antes, vai confundir e frustar eles.

Treinamento ágil é necessário para evitar essas confusões e certificam que o potencial máximo da agilidade é liberado para todo o time.

Más práticas procriam e se multiplicam

Caia fora de más práticas tão cedo quanto possível. Quanto mais péssimos hábitos forem negligenciados mais eles vão se estabelecer e mais difícil será de se livrar.

Treinamento ágil ajuda a eliminar essas más práticas antes que elas cresçam e virem grandes problemas.

Você provavelmente tem alguma ideia do que significa ser ágil. Muitos desenvolvedores provavelmente tem. Quando falta informação, nosso cérebro preenche os vazios.

Um grande exemplo é o scrum master tipicamente caindo no papel do gerente de projetos.

Quando os times não são propriamente educados sobre seus papéis e responsabilidades em uma ferramenta ágil, eles farão o que sabem, velhos hábitos demoram a morrer.

Uma boa parte do treinamento ágil é ajudar pessoas a desaprenderam maus hábitos que eles se acostumaram.

Isso não significa dizer que ágil é "melhor" que o que quer que seja que acontecia antes, mas maus hábitos podem certamente interferir com a forma como a agilidade funciona, e é importante mudar certos comportamentos com treinamento apropriado.

Evite o Frankenstein ágil

Isso é similar a necessidade de eliminar velhos maus hábitos, mas a diferença é que aqui envolve a consciência sobre o que cada pessoa pensa que é a melhor forma de fazer as coisas.

Eles poderiam estar fazendo um tipo de agilidade na empresa anterior, e acreditam que é a melhor (ou única) forma de fazer isso.

Geralmente isso vai se manifestar na forma de metodologias Frankenstein que misturam partes do scrum com cascata e todo tipo de abordagens diferentes, como fazer compras em um mercado.

Esse tipo de mistura pode ser evitado com treinamento apropriado. Quando todo mundo está na mesma página sobre os processos e princípios da abordagem ágil, mais serviço será feito e terá menos atrito no time.

No Comments Yet

Add a comment