"Depois de tudo o que vivemos, o que fizemos, não pode ser por nada".
– Ellie, The Last of Us -
O manifesto ágil certamente é um marco episódico na gestão contemporânea. Quando falamos de organizações inovadoras no campo da tecnologia logo remetemos a estruturas compactas, flexíveis e menos hierárquicas, com lotes de trabalho curtos e projetos pensados de forma iterativa e incremental. Mas o que fazer quando a Gestão Ágil falha? Como lidar com a falta de ‘mindset ágil’ do time?
O mero fato de aplicar um framework ágil como Scrum ou Kanban não é suficiente para tornar uma iniciativa exitosa, uma vez que uma ampla confluência de fatores da cultura organizacional interferem no gerenciamento de times de desenvolvimento. No meio de minhas leituras acabei me deparando com o excelente livro “Zombie Scrum Survival Guide”, e resolvi listar os principais sintomas de ‘zumbificação’ de times ágeis.
1. O time não conhece as necessidades dos Stakeholders
Ao contrário dos zumbis dos filmes que atacam os seres humanos, os times zumbis preferem se esconder das pessoas, sem se importar com o que está no upstream ou o downstream da cadeia de valor. Para eles, é bem mais seguro se esconder atrás de telas de seus PCs enquanto se mantêm ocupados com design, análise ou escrita de código.
Os Times Zumbi se veem apenas como uma engrenagem na roda, incapazes ou sem vontade de mudar qualquer coisa que possa trazer um real impacto. Em muitas organizações, sobretudo aquelas mais tradicionais, os desenvolvedores apenas escrevem código, assim como os gerentes apenas gerenciam, os designers apenas projetam e os analistas apenas analisam. Quando todos terminam as suas atividades, eles simplesmente passam o trabalho para outra pessoa que trabalha no próximo item, sem ter a mínima ideia do que aconteceu na etapa anterior. Esse pensamento de silo vai contra a ideia da gestão ágil centrada em equipes multidisciplinares que geram valor para os usuários.
Como consequência, as equipes apenas reproduzem um fluxo de produção cujo valor dos produtos é questionável. Os resultados finais podem não ser o que os stakeholders realmente precisavam ou ainda não trazem nenhuma contribuição do ponto de vista dos usuários finais.
Isso cria o que provavelmente é o maior desperdício no desenvolvimento de produtos de software: produtos medíocres que não oferecem valor.
De acordo com pesquisa feita pela zombiescrum.org com 1.764 times de tecnologia nos EUA entre Junho de 2019 e Maio de 2020:
➡ 65% dos times têm pouca interação com outros departamentos durante a Sprint (por exemplo, jurídico, marketing ou vendas).
➡ 65% têm um Product Owner que raramente rejeita trabalho ou diz “Não”.
➡ 63% nunca ou raramente removem itens do Product Backlog.
➡ 62% não veem interação frequente entre a equipe de desenvolvimento e Stakeholders durante a Sprint.
➡ 62% têm um Product Owner que é o único membro da equipe que interage com Stakeholders.
➡ 60% têm um Product Owner que não tem autoridade para decidir como gastar o orçamento.
➡ 59% possuem Sprint Reviews que são atendidas apenas pelo time ágil (sem stakeholders)
➡ 53% têm um Product Owner que não envolve ou raramente envolve Stakeholders no pedido ou atualização do Backlog do Produto.
2. O time não consegue entregar de forma rápida e tangível
Ocorre quando um time "zumbificado" se esforça para entregar algo de valor apenas no final de uma Sprint, sendo que às vezes não há sequer um incremento de produto ou quando o time leva meses para liberar novas features para os Stakeholders.
Uma outra situação ocorre durante as Sprint Reviews quando os Stakeholders não têm a oportunidade de testar na prática o produto para validar o que foi criado. Ao invés disso, a equipe liga o projetor e exibe uma apresentação sofisticada, mostra capturas de tela ou simplesmente fala sobre o que estava no backlog da Sprint.
Nos casos em que há inspecionamento do produto, essa tende a ser puramente técnica e com anotações do tipo “Temos que terminar isso na próxima Sprint” ou “Opa, isso não foi trabalhado ainda.”
Um indicador mais sutil é a falta de interação durante a revisão da Sprint. Não há opiniões expressas, sugestões levantadas ou novas ideias discutidas. Quando os Stakeholders raramente ficam presentes e o Product Owner parece não se incomodar com essa situação. Ao invés de se tratar de uma reunião para inspecionamento de uma nova versão do produto, a Sprint Review acaba servindo apenas para preencher checklists de especificações. Ninguém parece se importar.
As conversas durante uma Sprint Review são cruciais para dar visibilidade às entregas de valor de um produto e ter um alinhamento sobre a direção em que o desenvolvimento deve prosseguir. Isso só é possível quando o Time Ágil e os Stakeholders conseguem inspecionar as entregas e falar sobre resultados tangíveis. Essa construção coletiva tende a ser mais esclarecedora do que até mesmo uma documentação precisa.
Perguntas e comentários pertinentes são possíveis apenas quando as pessoas envolvidas têm a chance de experimentar o produto diretamente, sem ter que confiar em sua imaginação e suposições sobre o que deveria ser.
Algumas estatísticas sobre esse tópico:
➡ 62% dos times precisam executar um número significativo de etapas manuais para enviar um incremento.
➡ 61% dos Product Owners não usam ou raramente usam a Sprint Review para coletar feedback das partes interessadas.
➡ 57% experimentam estresse e pressão para fazer tudo durante os dias finais de uma Sprint.
➡ 52% frequentemente precisam empurrar problemas para a próxima Sprint que poderiam ter sido evitados com a realização de testes melhores.
➡ 43% não gastam tempo na Sprint atual para refinar o trabalho para as próximas Sprints.
➡ 39% geralmente não possuem um Incremento que possa ser enviado ao final de uma Sprint.
➡ 31% ocasionalmente ou frequentemente cancelam a Sprint Review.
