Seu Time Ágil está virando Zumbi? Veja 4 sinais
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 trazem 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 ideias do que aconteceu na etapa anterior. Esse pensamento de silo vai contra o 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 acrodo 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.
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 àoportunidade de testar na prática o produto para validar o que foi criado. Ao invés vez 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 trabalhando ainda.”
Um indicador mais sutil é a falta de interação durante o 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óximos 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.
3. Não há melhoria contínua no time
Assim como um zumbi não reclama quando seu braço cai, um time zumbi não reage a uma Sprint com diversas falhas ou até mesmo a uma Sprint bem-sucedida. A moral da equipe se torna baixa e itens do backlog são empurrados de uma Sprint para a próxima sem haver questionamento.
Isso pode ocorrer quando os itens do backlog da Sprint não estão vinculados a metas específicas, por isso o time passa a acreditar que esses itens podem ser concluídos sempre que a equipe quiser, levando os desenvolvedores a seguirem por um caminho sem rumo em meio a um deserto árido, sem demonstrar qualquer emoção ou desejo de mudança.
Não podemos culpar apenas o time de desenvolvimento se o Product Owner quase nunca estiver presente na Sprint Review ou na Planning. Nesse cenário a única coisa que acaba sendo discutida é o quanto de trabalho é realizado e não o quão útil e valioso esse trabalho é para os usuários e para o negócio em geral.
Bônus: Quando há instabilidade na dedicação dos desenvolvedores por conta de deslocamentos para trabalhos de outras squads para quebrar galhos técnicos.
Algumas estatísticas sobre esse tópico:
70% dos times nunca ou raramente usam métricas para identificar melhorias.
64% dos times não se envolvem ativamente com pessoas de fora da equipe para aprender algo novo ou ter discussões sobre suas profissões.
60% dos times nunca ou muito raramente comemoram pequenos ou grandes sucessos que alcançaram alcançou.
46% dos times nunca ou raramente incentivam as pessoas a aprender coisas novas, ler livros profissionais ou participar de encontros e conferências.
44% das Retrospectivas de Sprint da equipe não resultam em melhorias para a próxima Sprint.
37% das equipes acham difícil arriscar criar algo novo.
4. O time não se auto-organiza para remover impedimentos
Quando o time não consegue ter flexibilidade ou acesso às pessoas necessárias para executar os PBIs (product backlog itens). Nesse cenário, eles não podem escolher suas próprias ferramentas nem tomar decisões sobre o produto. Eles têm que pedir permissão por quase tudo, e seus pedidos muitas vezes são negados.
Tal falta de autonomia resulta numa falta de propriedade deveras compreensível; afinal, por que se importar com o sucesso de um produto quando não há envolvimento em sua construção?
Há situações em que em o gestor até lê algo na internet sobre agilidade e decide dar mais espaço ao time ágil. O problema é que a auto-organização não acontece apenas porque uma equipe obteve permissão para fazer isso. Os membros do time têm que desenvolver habilidades para essa autonomia, para que sejam capaezes de alinhar seu trabalho com a organização de forma mais ampla (OKRs podem ser uma boa alternativa aqui)
Sem esse apoio, o fracasso é inevitável e o gestor provavelmente irá estabelecer uma postura de comando e controle ainda mais rígida do que antes, pois agora ela tem mais provas de que essa coisa de “frameworks ágeis” não funciona.
Algumas estatísticas sobre esse tópico:
67% dos times possuem integrantes que atuam apenas ou majoritariamente em sua área de especialização.
65% dos times não são ouvidos pela gestão
49% dos times nunca ou raramente têm um objetivo claro para sua Sprint atual.
48% dos times trabalham em vários projetos ou produtos ao mesmo tempo
42% dos times não têm ou têm voz limitada em suas ferramentas e infraestrutura.
37% dos times têm redundância limitada em habilidades na sua equipe para se precaver contra a indisponibilidade de outros membros da equipe
19% das equipes têm muito pouco a dizer sobre como fazer seu trabalho durante um Sprint
E você, já vivenciou algum desses sintomas no seu time ágil? Você está numa zona segura ou no meio de uma horda?
