Cinco Armadilhas na Escalabilidade da Agilidade

Grandes empresas buscam especialmente caminhos rápidos e simples para realizar a transição do desenvolvimento clássico para o ágil. Quanto mais rápida uma transição deve acontecer, mais perigosas são as armadilhas que passam despercebidas. O desenvolvimento ágil se baseia mais na sustentabilidade do que em simplesmente terminar rápido. Por isso, a gestão tem uma grande responsabilidade pelo sucesso da transição ágil. Quem não cuida das armadilhas mais comuns, muito provavelmente criará um culto de carga. Por fora, a transição parece bem-sucedida, mas por dentro os benefícios da transição não se concretizam.

Aqui reunimos cinco armadilhas comuns no caminho para a organização ágil:

1. Agilidade Fundamental

A mudança para processos ágeis é fácil. Você desregula um pouco e envia algumas pessoas para treinamento. Depois disso, as pessoas conseguem "fazer Scrum" – ou escolher outra abordagem ágil. Mas, no geral, talvez você tenha alcançado 1% – 99% do caminho ainda está pela frente. A jornada ainda é longa. No coração da agilidade está o processo Inspect+Adapt. Para que ele funcione, você precisa de um mindset especial. Todos devem questionar implacavelmente o que está acontecendo – e fazer mudanças quando as coisas estão indo na direção errada. Para ancorar o Inspect+Adapt de forma significativa na organização, você precisa de duas coisas: Primeiro, a forma de trabalho existente precisa ser desintoxicada. Elementos da cultura da empresa que desencorajam os desenvolvedores de assumir ownership pelos seus processos precisam ser removidos. Para isso, muitos processos de Command+Control precisam ser descartados e a gestão de desenvolvedores precisa ser fundamentalmente repensada. Mudança só acontecerá se você permitir! Depois, uma forma de trabalho saudável precisa ser criada. Você precisa de um sistema de gestão que encoraje os desenvolvedores a assumir responsabilidade por suas próprias ações, decisões, mudanças, fracassos e sucessos. Para isso, estruturas e processos precisam ser criados que valorizem honestamente a contribuição individual de cada pessoa – independentemente de a gestão estar satisfeita com a direção no momento ou não. As pessoas só vão contribuir se você deixar!

Até que a fundação para a agilidade seja estabelecida, não haverá agilidade. Times sem agilidade fundamental não terão benefícios da escalabilidade ágil – nem contribuirão para ela.

2. Ferramentas

Implementar as cerimônias do Scrum leva apenas um dia, incluindo o treinamento e a tomada de decisão. Isso estabelece a base para o "trabalho ágil". Planejamento de curto prazo, atualizações regulares do plano, feedback do produto e melhoria incremental do processo são essenciais. Assim, os desenvolvedores podem descobrir a forma ideal de trabalhar ao longo do tempo. Só é preciso reservar muito tempo para a otimização quando as práticas de engenharia ainda não estão estabelecidas. Os desenvolvedores precisam estar familiarizados com conceitos como controle de versão, Continuous Integration, automação de testes, design emergente, TDD, BDD, programação em pares, convenções de código – e muitas outras coisas que o XP tem a oferecer. Eles precisam decidir conscientemente quais dessas práticas são úteis no contexto atual. Enquanto os desenvolvedores não conhecerem essas práticas, é bem possível que sejam "ritualmente ágeis", mas não pratiquem agilidade de verdade. Uma equipe sem as ferramentas certas pode até desacelerar a implementação de um desenvolvimento escalado.

3. Espírito de equipe

O espírito de equipe, frequentemente ridicularizado como algo esotérico, é imensamente importante para a melhoria sistêmica na escalabilidade ágil. Muitos gestores acreditam que metas individuais (chegando até ao Stack Ranking) são úteis para obter colaboradores de alta performance. No entanto, a escalabilidade ágil serve principalmente para construir um sistema complexo e adaptativo, no qual muitas pessoas contribuem. A necessidade de contribuir para o todo é muito mais importante do que a contribuição para os próprios objetivos. Aqui, "espírito de equipe" significa que os indivíduos devem fundamentalmente subordinar seus próprios interesses para promover a missão da empresa. O espírito de equipe não se trata tanto de "fazer coisas divertidas com os outros" (como eventos de equipe como rafting, kart ou paintball). Trata-se principalmente de sentir prazer em fazer coisas que ajudam a avançar juntos. Para isso, os desenvolvedores precisam de duas coisas: Primeiro, eles precisam saber como podem contribuir. Como isso depende muito de cada caso individual, a contribuição surge principalmente através da auto-organização e motivação intrínseca. Segundo, eles precisam saber que a disposição para ajudar vale a pena. Tudo o que cria uma desvantagem pessoal quando se ajuda outros a alcançar um objetivo comum deve ser removido. Um exemplo clássico de "espírito de equipe" é o futebol: frequentemente vimos que o jogo não é vencido pelo melhor jogador. O vencedor é a melhor equipe. No desenvolvimento é igual: ases que tentam superar uns aos outros não vencem. Vence-se unindo forças, combinando ideias e avançando juntos.

Grupos de desenvolvedores sem espírito de equipe desperdiçam sua energia com "ocupação". Um grupo escalado que não é uma equipe utiliza apenas uma fração do seu potencial para alcançar o objetivo comum!

4. Transparência

Muitas organizações falham por falta de conhecimento do sistema como um todo. Elas não conseguem otimizar globalmente. Obstáculos clássicos à transparência existem em todos os níveis: desde o desenvolvedor que não sabe como o trabalho de um colega o afeta, até o gestor que não consegue dizer qual é a Prioridade Absoluta número 1. Essa falta de transparência leva a muitos problemas. Começa com o desenvolvedor que, sem perceber, sabota o trabalho dos colegas e vai até equipes inteiras trabalhando nas coisas erradas. Nada disso é desejável e quanto mais frequentemente isso acontece, mais crítico e importante é aumentar a transparência. Algumas organizações desperdiçam quase toda a sua capacidade gerenciando problemas causados pela falta de transparência. Em situações assim, "trabalhar até a exaustão" é provavelmente uma descrição mais adequada do que "escalar". Existem muitas alavancas para aumentar a transparência a ponto de a escalabilidade fazer sentido. Algumas delas são:

• Um Kanban configurado – que todos possam ver!
• Um backlog central do qual todas as equipes se servem
• Collective Code Ownership como base para "comunicação através do código"
• Usar Andons: Build Monitoring e "Stop the Line" baseado em testes automatizados
• Planning conjunto e Reviews conjuntas, onde apenas o Produto Integrado é apresentado

A transparência é inversamente proporcional ao overhead e aos problemas. Ou dito de outra forma: na escalada ágil, a transparência é diretamente proporcional ao ROI. Equipes ágeis que carecem de transparência não contribuem de forma significativa para os objetivos da empresa.

5. Foco

Em muitas organizações, um dos principais problemas é o foco errado na utilização: gerencia-se trabalho e leva-se tarefas aos colaboradores. A premissa básica aqui é que se cria valor quando todos estão maximamente "ocupados". Numa organização ágil, é exatamente o contrário: levamos as pessoas ao trabalho que vale a pena fazer. Sabemos que não há correlação positiva entre criação de valor e utilização. Concentramo-nos em entregar um produto utilizável – em concluir as coisas. Um problema clássico em muitas organizações é que, ao tentar manter os colaboradores ocupados, muitas coisas ficam "em andamento": isso exige troca de tarefas e coordenação. Mas mesmo nos cenários mais triviais, a perda de foco resultante leva a um ROI massivamente reduzido e tempos de ciclo significativamente maiores: passamos tempo demais a descobrir por que nada fica pronto – e tempo de menos a concluir algo. A ideia principal por trás da focalização é: custa significativamente menos fazer primeiro a coisa errada e depois a certa – do que fazer duas coisas ao mesmo tempo. Por mais trivial que isso soe, é difícil de implementar: toda a organização precisa de uma lista de objetivos claramente ordenada, e cada objetivo deve estar inequivocamente priorizado. Existe exatamente uma única Prio 1. Em seguida, o "Work in Progress" deve ser estritamente limitado. Foco exige que os gestores repensem fundamentalmente a sua mentalidade: é preciso aceitar que "tempo ocioso" custa menos do que sobrecarga. Também não se pode ter tudo ao mesmo tempo. Equipas sem foco estão "bem ocupadas", mas são altamente ineficazes. Quanto menos focadas, mais tempo precisam para criar valor.

As Armadilhas na Escalabilidade da Agilidade

"Escalabilidade ágil" que não se preocupa com as armadilhas mencionadas acima provavelmente se tornará um culto de carga. Por fora, a transição parece bem-sucedida, mas por dentro os benefícios da transição não se materializam. Para transições ágeis bem-sucedidas, uma abordagem comum é trazer especialistas experientes que já "lutaram na linha de frente" e conhecem as armadilhas.

Para evitar as armadilhas em um ambiente escalado, recomendamos:

• Apoio da gestão para a transição. Para fechar as armadilhas, muita coisa na organização precisa ser virada de cabeça para baixo. Isso requer apoio incondicional da gestão.

• Criar um Agile Transition Team (ATT), que inclua tanto gestores quanto desenvolvedores. O ATT tem um backlog de mudanças claro, no qual todos trabalham juntos.

• Executive Coaching para as pessoas-chave da transição. Isso inclui tanto gestores de linha quanto Product Owners e Scrum Masters. O coach externo precisa ter experiência em escalabilidade ágil!

• Coaching técnico ajuda as equipes a obterem mais rapidamente as ferramentas adequadas: Isso se paga muito rapidamente através de um produto de maior qualidade!

• Contratar um consultor para liderar a transição. Essa pessoa precisa saber exatamente o que está fazendo e deve trabalhar sem compromissos. Ela precisa ter poder para implementar mudanças impopulares.

• Formação para todos sobre agilidade. Num ambiente de treinamento seguro, o impacto da transição pode ser comunicado muito mais facilmente.