Muitos de nós já fomos à academia e, inicialmente, obtivemos bons resultados. Depois que seu corpo estiver adaptado, a mesma rotina pode ajudá-lo a manter, mas você não verá nenhum ganho adicional e poderá até mesmo começar a retroceder.
Acho que o scrum como metodologia para entregar projetos de software está sofrendo do mesmo problema. O ciclo do scrum, ou a forma de praticar o scrum, é entendido muito literalmente ou aderido de forma muito rígida.
Qual é o propósito do scrum?
O Scrum deve ser sobre a definição de um meta de sprint alcançável por duas semanas . O Scrum deve encorajar as equipes a aprender com a experiência, se auto-organizar enquanto trabalha em um problema e refletir sobre suas vitórias e derrotas para melhorar continuamente.
Na minha experiência, o Scrum, infelizmente, acabou destruindo a central princípio do ágil, que é o processo das pessoas. Muito disso se resume ao mau gerenciamento e à ascensão do scrum master certificado.
Standups são para gerentes
O scrum diário deve durar 15 minutos, evento em caixa para a equipe de desenvolvimento planejar para as próximas 24 horas. Infelizmente, os standups se tornaram um meio de fixar os tíquetes do JIRA que se movem pelo tabuleiro.
Mover os tíquetes por um conjunto de raias é um pouco como contar linhas de código como uma métrica de sucesso. Um desenvolvedor pode parecer produtivo simplesmente por causa da rapidez com que moveu seus tickets. Por outro lado, um foco no quadro pode reduzir bons desenvolvedores que trabalham em problemas desafiadores para parecerem medianos.
Equipes auto-organizadas
Se bem feito, o scrum incentiva as equipes a aprenderem. experiências, se auto-organize enquanto trabalha em um problema e reflita sobre suas vitórias e derrotas para melhorar continuamente.
Em scrums defendidos pelo infame scrum master, você precisa limpar os tíquetes. Além disso, não há verificar a qualidade do trabalho, que muitas vezes é determinada por um proprietário de projeto não técnico. Isso incentiva ir para o vazio e focar na saída de código.
Os pontos da história míticos não são míticos
Os pontos da história são unidades de medida para expressar uma estimativa do esforço geral necessário para uma implementação completa um item do backlog do produto. Ou, pelo menos, deveriam ser.
Na minha experiência, os pontos da história podem incentive as equipes a manipular o sistema . Depois de não atingir suas metas em vários sprints, gerentes de projeto experientes ficarão com medo de trazer muito em um sprint.
O medo do fracasso leva a pequenos sprints de história em que apenas pequenos itens de tickets são colocados em jogo para garantir a sua conclusão. O panorama geral torna-se irrelevante e focar em pequenas coisas acabará tirando o projeto dos trilhos.
Eu vi isso em primeira mão em um projeto em que cada história tinha que passar por um teste de automação. Esses testes vêm com um alto orçamento de manutenção e os testes de automação para este projeto desaceleraram o desenvolvimento até quase a paralisação. Quando o teste de automação se torna o foco, ajustar os processos de desenvolvimento e manutenção em uma janela de duas semanas escalou o tempo de construção de integração contínua para duas horas. O pipeline parou e a mudança foi forçada.
O oposto de trazer muito pouco para o sprint é carregar muito para o sprint. Desenvolvedores e testadores economizam enquanto acumulam dívidas técnicas. A dívida nunca é paga, e as placas giratórias acabarão caindo no chão, causando um repensar massivo e caro.
Em vez de contar com os pontos da história, devemos rastrear o trabalho concluído e não o que estimamos. Acho isso impressionante. Se eu quiser saber quanto tempo levou um trabalho semelhante, quero saber o tempo real e não a estimativa. Se todas as suas histórias são pequenas o suficiente, você não precisa de estimativas.
Retrospectivas são chatas
O objetivo da retrospectiva é apenas isso: refletir. Vemos o que funcionou, o que não funcionou e que tipos de experimentos queremos tentar.
Infelizmente, o que se resume é colocar os mesmos Post-its de “bom trabalho em equipe” e “ muitas reuniões ”nas mesmas raias como“ o que deu certo ”,“ o que deu errado ”e“ o que faremos melhor ”.
Depois do primeiro retrô, é entediante. A falta de imaginação do mestre SCRUM certificado é uma grande parte disso, mas acho que o retrô agora é uma perda de tempo cansada e monótona.
Hackathons e atividades práticas podem servir melhor do que um retrô para experimentar novos paradigmas. A colaboração está implícita em um hackathon, e a única maneira de ter sucesso é com um bom trabalho em equipe. Trabalhar em um problema divertido com um prazo imposto garante o aprendizado.
Retros forçam as pessoas a uma sala duas vezes por semana com uma mentalidade de”vamos ser retrospectivos agora”. Torna-se repetitivo e enfadonho e não há dinamismo. As equipes precisam de novos estímulos, não os mesmos sprints redundantes de marmota de duas semanas.
Vamos retro scrum
O Scrum costuma ser o inimigo da produtividade e faz ainda menos sentido remotamente, mundo pós-COVID.
A premissa do scrum não deve ser que um cortador de biscoitos se adapte a todas as equipes de desenvolvimento do planeta. Muitas equipes estão apenas fazendo as coisas mecanicamente e sem nenhuma evidência de sua eficácia. Um pesadelo sempre recorrente de standups, sprint grooming, sprint planning e retrospectiva só pode levar ao envelhecimento. Scrum não promove novas formas de trabalhar; em vez disso, ele defende a repetição.
Deixe boas equipes de desenvolvimento se auto-organizarem de acordo com seu contexto. Rastreie o que é enviado para a produção, adicione o tempo que levou (em dias!) Após o fato e rastreie isso.
Concentre-se na realidade e não em algum gráfico de burndown vagamente inteligível. Automatize tudo o que puder e tenha um pipeline ultra-suave. Erradique todos os resíduos. Constantemente re-estime conforme você sabe mais. A ideia de que você está estimando e se apegando à sua história mítica aponta quando você sabe o que menos no início do trabalho não tem muita repercussão.
Adultos jogando pôquer de planejamento é tão ridícula quanto parece. 
