Por que falhar Agile é tão fácil

Willian Corrêa Blocked Unblock Seguir Seguindo 5 de janeiro

F ou dos últimos anos, eu tive a chance de implementar Agile em muitos tipos e tamanhos de organizações diferentes, em dois países diferentes e até mesmo em minhas próprias empresas. Os sucessos e fracassos que acumulei ao longo do tempo me permitiram compilar uma lista de fatos e pensamentos que ajudam a implementação bem-sucedida de processos guiados pelos princípios e valores propostos pelo manifesto ágil.

Ser ágil antes de fazer Agile

Não importa qual metodologia a equipe esteja usando hoje. É mais importante entender como a equipe opera diariamente, como os membros colaboram para enfrentar os problemas e como eles aceitam e reconhecem mudanças e novas ideias. Em geral, uma equipe que não evolui no mesmo ritmo de seus colegas de mercado provavelmente não é adequada para uma prática Ágil – pelo menos não antes de fazer outras pequenas mudanças para melhorar a velocidade e a mentalidade voltada para o valor.

“Se você quer realmente entender alguma coisa, tente mudá-la.” – Kurt Lewin

Ágil é uma mentalidade, tudo sobre cultura. Mudar qualquer coisa relacionada a isso é difícil e doloroso para nós como seres humanos. Ela exige que nos mudemos de nossa zona de conforto para desafiar o status quo. Requer esforço e engajamento não apenas da equipe de desenvolvimento, mas de todas as outras partes interessadas. Se você está interessado em ler mais sobre os fatores humanos de mudar um comportamento, eu recomendo o livro Changing for Good escrito por Ph.D. James Prochaska .

Antes de fazer Agile, é necessário ser Agile. Toda vez que tentei implementar uma nova prática antes de promover os princípios e valores do Agile em cada pessoa que não estava acostumada com eles, experimentei um caminho tortuoso. Eu tentei isso muitas vezes e em diferentes ambientes, como setores público e privado, equipes pequenas e grandes, de startups a empresas. Pequenos passos e equipes sempre foram o melhor caminho a seguir e os menos prejudiciais para o relacionamento com o cliente – stakeholders e equipe de desenvolvimento incluídos.

Muitas vezes eu ouvi executivos dizendo que suas equipes já estavam fazendo Agile desde que eles tinham implementado reuniões em pé, kanban board ou sprints – algumas das terminologias mais conhecidas sendo jogadas fora. Investigando mais eu pude descobrir que, na verdade, eles não eram. Eles não estavam trabalhando na entrega de valor, mas apenas no trabalho planejado, a equipe não estava motivada, a aprendizagem contínua não fazia parte do processo, os prazos ainda eram cumpridos, os “sprints” duravam meses, os proprietários apareciam apenas para perder mais tarefas um processo doloroso, a comunicação entre a equipe e as partes interessadas não existia, entre outras coisas seguidas nos ambientes tradicionais.

O que faz com que essas equipes acreditem que estão fazendo o Agile? Agile não é uma receita ou um framework que você pode seguir os passos para implementar. Está aberto a interpretações, e esse é um terreno fértil para desenvolver equívocos em nome de estar na moda ou qualquer outra pseudo-motivação para adotá-lo. Se você nunca teve a chance de ler o Manifesto Ágil da fonte , peço-lhe para fazê-lo, apenas 4 valores e 12 princípios, uma leitura de cinco minutos que mostra Agile é toda sobre confiança, colaboração, aprendizagem, qualidade, comunicação , esforço de equipe e por último mas não menos importante: inovação.

Se você puder identificar em suas equipes dois ou mais dos itens a seguir, você não está fazendo o Agile:

  • Inúmeras iniciativas com prazos urgentes, em vez de atribuir a mais alta prioridade e escolher dois ou três para enfrentar
  • Gerentes derrubam decisões da equipe
  • Os melhores talentos estão espalhados por muitos projetos
  • Muitas reuniões com os membros da equipe, fazendo com que trabalhem menos no projeto
  • Camadas de revisão excessivas
  • Mecanismo de relatórios ou controles são criados ou já existem para garantir que os erros não sejam repetidos
  • Gerentes e liderança falam mais do que ouvem
  • Idéias não essenciais são promovidas, especialmente aquelas que a equipe considerou anteriormente e adiou.
  • Falta de comunicação causa conflitos ou retrabalho
  • Garantia de Qualidade não faz parte de todo o processo
  • Mudanças não são bem aceitas pela equipe
  • Solicitações de mudança parecem ser injustificadas ou não qualificadas
  • A entrega ou a implantação é penosa – exigem trabalho após o expediente, falta automação ou requisitos de aprovação em excesso
  • Os comentários de clientes ou usuários finais são negligenciados em favor do plano ou escopo original

O cenário em que os executivos acreditam estar agindo, mas na verdade não são, ainda é comum. Nesses casos, o desafio era muito mais trabalhoso, exigindo enorme esforço para convencer que eles estavam no caminho errado, mostrar o verdadeiro Agile e seus benefícios. Não é raro nesses casos ter alguém dizendo que o Agile é equivalente a anarquia, correndo sem direção e perdendo qualidade. Como mencionado anteriormente, a implementação do Agile requer uma mudança na cultura, principalmente em indústrias tradicionais que ainda são muito hierárquicas, e as decisões são tomadas exclusivamente pelo topo da pirâmide. Os executivos devem capacitar suas equipes para implementar o Agile com sucesso.

Uma decisão fácil com alto custo

Infelizmente, as decisões de cima para baixo ainda existem e ocorrem com mais frequência no setor público e nas organizações tradicionais. Eu não diria que ter um processo de decisão como esse é o mesmo que configurar a implementação para falhar. Na verdade, funcionou mais do que algumas vezes, principalmente por causa da pseudo-motivação criada por ser uma ordem da equipe de gerenciamento sênior. No entanto, toda vez que o processo Agile começou devido a esse tipo de decisão, era mais trabalhoso e demorado fazer com que toda a equipe participasse e seguisse a nova prática e a estrutura escolhida.

A decisão de cima para baixo é muitas vezes tomada usando KPIs de outras empresas como uma referência que mostra um aumento na satisfação do usuário, produtividade, qualidade do código, velocidade ou métrica semelhante. Minha experiência mostra que 5 em 10 equipes que implementam experimentos ágeis melhoram a produtividade, a satisfação do cliente e a qualidade aumentam no médio prazo e a redução total de custos a longo prazo – sem mencionar as outras melhorias do KPI. Esse número muda para 8 em 10 quando eu aponto meus dados para as equipes em que a decisão de implementar o Agile foi uma decisão democrática, fazendo com que todos os membros da equipe participassem do processo.

Vender a ideia, apresentando prós e contras, implementando como um teste em um projeto específico ou debatendo o tópico sempre mostrou ser o melhor caminho a seguir. Também é demorada, mas de um modo bom, já que a motivação e o envolvimento da equipe estão sendo construídos desde o primeiro dia, permitindo que participem do processo de decisão.

O ponto principal é que o Agile não é um framework ou um processo baseado em regras, bem estabelecido ou que dita como fazer as coisas. As equipes devem estar livres para implementar da maneira que melhor se adapte ao seu projeto, escolhendo uma estrutura existente (Scrum, Kanban, XP, Lean, SAfe …), até mesmo criando uma nova baseada nelas. Eles também devem ser livres para escolher as ferramentas que suportam melhor a prática diária.

O fracasso deve ser uma ferramenta para melhoria e aprendizado – não vergonha, nem punição ou desculpa para reverter a implementação do Agile. As equipes precisam estar livres para questionar cada processo, requisito e tentar novas abordagens. Quando falham, eles têm material suficiente para aprender com os erros e melhorar no próximo ciclo.

“O fracasso é simplesmente a oportunidade de começar de novo, desta vez de forma mais inteligente.” – Henry Ford

Às vezes, o Agile não é a resposta

O fato é que não existe uma maneira certa ou errada de trabalhar. Cada metodologia pode funcionar de maneiras diferentes, dependendo das equipes e da cultura organizacional. É importante dizer que o Agile pode ser aplicado a qualquer negócio, produto ou serviço – e não apenas para desenvolvimento de software. As empresas estão usando a filosofia para construir aviões, elevadores, criar novas campanhas de marketing ou até modernizar um conglomerado inteiro.

No entanto, há uma série de condições, não relacionadas a pessoas ou cultura, que cria cenários desfavoráveis para a implementação do Agile, são elas:

  • Os problemas podem ser resolvidos sequencialmente, em equipes isoladas ou a prioridade para resolvê-los é apenas uma questão de urgência.
  • Os usuários finais não podem começar a usar o produto ou serviço antes que seja feito completamente
  • A organização deve estar operando como uma máquina, muito hierárquica, onde mudanças constantes e inovação não são necessárias
  • Clientes ou usuários finais não estão disponíveis para colaboração
  • Fazer alterações tardias tem custo proibitivo ou é até impossível
  • Falhas e erros podem causar danos irreversíveis
  • O mercado é estável e previsível
  • As soluções existentes são estáveis e estão resolvendo o problema de forma que a inovação não mudaria nem causaria qualquer benefício.
  • A transformação digital não é necessária para o tipo de serviços ou produtos que sua empresa oferece
  • Alterações com base no feedback do cliente, se não forem implementadas de forma rápida e frequente, não causam danos ao negócio