Os mitos que sustentam a ignorância ágil
É comum ouvir que agilidade é bagunça, entrega-se o que quer quando quer.
Quem desconhece — não faz questão de conhecer — e pensa de forma linear com o mindset enraizado em solo da era industrial no quintal de Henry Ford, realmente tem dificuldades ou resistência para entender os motivos por trás dos benefícios da metodologia ágil.
Para contextualizar, em um processo linear ou sequencial inicia-se uma nova fase somente após o término da anterior. Há uma longa distância entre o levantamento de requisitos e a entrega ao cliente, com pouquíssima margem para mudanças e alto risco de não atender as necessidades que o cliente nem lembra mais quais eram. O gerenciamento está mais no controle e no cumprimento do prazo a qualquer custo do que na entrega em si.
A metodologia ágil consiste em ciclos curtos e feedback constante do cliente. Além disso, promove a integração e colaboração de todos os envolvidos. O gerenciamento é no fluxo, não na atividade. E o foco está na entrega de valor.
Jeff Sutherland, um dos criadores do Scrum, em seu livro A Arte de Fazer o Dobro do Trabalho na Metade do Tempo diz que…
Processos ruins estão tão enraizados em nossa forma de pensar que, como alternativa, precisamos de um processo o mais leve possível e com maior impacto no trabalho. O que o Scrum faz é se concentrar na tentativa de eliminar os desperdícios.
O pior não é falta de conhecimento ou a resistência, mas os impactos catastróficos causados por decisões tomadas sem fundamentação teórica, ausência de experiência ou ainda com base em informações superficiais e tendenciosas.
A influência desse comportamento pode levar ao uso indevido das práticas ágeis, descaracterizando a metodologia e sabotando inconscientemente seus resultados. E quanto mais enérgicas são essas pessoas ou mais alto seu nível hierárquico, mais influência ela exerce. Cuidado!
Para exemplificar podemos comparar a aplicação de um método ágil a uma receita culinária. Qual o resultado esperado ao seguir a receita pela metade ou utilizar ingredientes diferentes daqueles mínimos obrigatórios? Assim é praticar agilidade.
Antes de qualquer coisa deve-se ter como referência o Manifesto Ágil. Quem for aplicar agilidade sem conhecer seus valores e princípios precisará contar com a sorte antes de obter êxito. Voltando ao exemplo, é como fazer a refeição sem experiência na cozinha ou sem seguir os princípios básicos da culinária, na tentativa e erro até dar certo ou acabarem os recursos. E depois não adianta reclamar do gosto amargo e culpar a panela!
MITO #1 — Vou fazer mais rápido!
Definitivamente não! Evite falar isso, nem pense. Não! Nem pense.
Agilidade não significa “fazer mais rápido”, mas sim evitar o desperdício de fazer mais do que o necessário, em outras palavras “fazer certo na primeira vez” buscando assertividade através do envolvimento de todos e no feedback constante do cliente ou seu representante.
O “fazer” somente não garante o valor da entrega.
E como entregar mais rápido? Principalmente gerenciando o fluxo, não a atividade isoladamente. E eliminando o desperdício com o que não vai gerar valor para o cliente. Não construa aquilo que não irá vender!
Um exemplo simples para diferenciar o “fazer” do “entregar” é você no alto de um prédio em chamas, precisa chegar ao chão o mais rápido possível, como fazer? Pular pela janela (fazer) ou descer por uma rota segura (entregar)?
MITO #2 — Vou fazer somente a metade!
Fazer pela metade não é fazer. Um carro pela metade só serve para desperdiçar recursos que poderiam ter sido usados para criar algo de valor ou economizar dinheiro. Qualquer coisa que esteja “em processo” custa dinheiro e energia, sem entregar nada. — Jeff Sutherland
Priorizar o que tem mais valor para o cliente não pode ser entendido como “entregar pela metade”. Quando falamos de software é possível quebrar uma funcionalidade em várias entregas e priorizar aquilo que é essencial e deve ser feito primeiro.
No exemplo do carro, na citação acima, se a expectativa do cliente é “locomover-se dentro da cidade” podemos entregar um carro sem vidro elétrico num primeiro momento, mas não sem as rodas ou sem o volante. Ainda neste exemplo, podemos considerar entregar qualquer meio de transporte, não necessariamente um carro. Será que o cliente aceita andar de bicicleta?
Um estudo realizado pela Standish Group chegou a conclusão de que cerca de 45% das funcionalidades de um software nunca são utilizadas. Há então um grande desperdício de tempo no desenvolvimento dessas funcionalidades e é aqui que a metodologia ágil contribui fortemente com sua abordagem incremental e iterativa, com a estratégia de construir somente aquilo que fará sentido para o cliente.
MITO #3 — Não tem documentação!
Tem, mas somente daquilo que faz sentido ter. Tudo que é documentado deve fazer sentido para o cliente ou para o time.
A documentação que não existe é aquela substituída pela comunicação e interação entre as pessoas do time, que inclusive se torna muito mais efetiva do que ler e interpretar uma especificação de requisitos escrita por alguém que não se sabe quem.
Não há necessidade de especificar nos mínimos detalhes uma funcionalidade como se não conhecesse a equipe que irá executar o trabalho. Quem encomenda (Product Owner) e quem constrói (Dev Team) fazem parte do mesmo time (Scrum Team) e compartilham as mesmas responsabilidades.
A interação deve ser constante, assim como o feedback com relação àquilo que está sendo entregue.
Software em funcionamento mais que documentação abrangente. — Manifesto Ágil
MITO #4 — Não tem métricas nem controle!
Métricas, sim. Punitivas, não!
As métricas precisam fazer sentido principalmente para acompanhar a evolução do time e refletir o quanto estão atingindo os seus resultados.
Medir e acompanhar faz parte do processo de inspeção e adaptação, dois dos três pilares do Scrum. Por isso é importante desenhar métricas de resultado, que venham a partir dos feedbacks dos clientes, e usar métricas intermediárias para acompanhar a evolução do trabalho do time rumo ao cumprimento de seus objetivos.
É importante que a cada sprint — ou iteração — o próprio time perceba onde pode melhorar. Há um momento de “lições aprendidas” específico para isso, realizado obrigatoriamente ao término de cada sprint.
Métricas de resultado promovem o engajamento dos times, que naturalmente buscam evolução e melhoria contínua, resultando em aumento da produtividade, previsibilidade e qualidade das entregas. Isso faz estreitar a relação de confiança permitindo mais autonomia e também responsabilidade. Temos então times comprometidos, focados e auto-organizados!
MITO #5 — Agilidade é coisa de Startup!
Sim. É também, mas não somente.
Este talvez seja o mito mais top trends dos usados como desculpa pelos céticos, conservadores e resistentes por agilidade. É possível aplicar um método ágil em praticamente qualquer porte de empresa, talvez qualquer área. O Scrum é uma abordagem, mas há também o método Kanban que pode ser aplicado sozinho ou junto com o Scrum.
Em empresas com muitos times podemos aplicar o Scrum e escalar com um framework específico como o Nexus ou o SAFe. Depende muito do contexto e do que se deseja resolver.
É importante ter em mente que agilidade não resolve todos os problemas do mundo, não é bala de prata, varinha de Fênix ou chapéu de Presto. Agilidade apenas simplifica problemas complexos!
É isso!
Compartilhe esse texto com aquela pessoa que precisa de salvação.
Obrigado!
