[RANT] SCRUM: Uma ideia ruim que deve ser enterrada
Introdução
Este post deveria ser emoldurado.
Eu preciso confessar: nunca me dei muito bem com o SCRUM. Desde que esse processo me foi apresentado, lá no longínquo ano de 2010, sempre senti que havia algo errado com ele.
Ao longo dos anos, eu fui doutrinado acabei aceitando que esse era o padrão da indústria. Afinal, todo mundo usava e todas as startups bacanas aplicavam, não é mesmo? Além do mais, as apresentações sobre a metodologia sempre começavam comparando o SCRUM com o detestável e ineficiente modelo em cascata (waterfall), certo?
O SCRUM se tornou sinônimo de agilidade e, se sua empresa não o utilizasse, estava ficando para trás.
Mas, com o tempo e a senioridade (uma forma bonita de falar que sou velho), o meu ranço com o SCRUM voltou. Passei a sentir que o SCRUM ficava no meio do caminho entre o time e a resolução do problema. Eram muitos ritos e cerimônias: daily meeting, sprint retrospective, sprint review, planning poker (este é o mais bizarro). No fim, ninguém discutia como resolver o problema; todo mundo estava mais preocupado com o processo do que com a solução.
Característica essa que fere o princípio fundamental do manifesto ágil:
"Indivíduos e interações mais que processos e ferramentas"
Outra coisa terrível do SCRUM são as reuniões diárias obrigatórias. Isso não faz sentido nenhum. Boa parte dessas reuniões vira desperdício de tempo, e as clássicas perguntas — "o que você fez?", "o que você está fazendo?" e "tem impedimentos?" — tornam-se redundantes se você possui um bom sistema de gestão de tickets.
Na minha experiência, o SCRUM apenas oferece uma ótima desculpa para empresas que gostam de microgerenciamento, mas que ainda querem se vender como modernas. Gráficos de burn down viram um porrete nas mãos de gerentes incompetentes e o planning poker é uma brincadeira de mau gosto. Sério, estimar atividades jogando CARTINHAS? Aliás, estimativas é um tema que merece outro artigo.
Mas agora que eu levantei todos os podres do SCRUM, você deve estar se perguntando: o que fazer no lugar dele?
A resposta inicial é: BOM SENSO. O manifesto ágil não prega nenhuma receita de bolo. Como falado no tweet no início deste artigo, agilidade é sobre construção incremental, validação frequente com o cliente e adaptação baseada nos feedbacks.
Mas, se você quer algo mais "sistematizado", pode usar Kanban ou, pelo menos, dar uma lida no livro Extreme Programming Explained do Kent Beck. Se você aplicar metade do que esse livro ensina, nunca mais precisará ouvir falar de SCRUM.
No final das contas, agilidade não é sobre seguir um manual cego ou ter um "Scrum Master" cobrando a movimentação de post-its. É sobre entregar valor de forma contínua e sustentável. Se o seu processo atual drena a energia do time em vez de facilitá-la, tenha a coragem de questioná-lo e mudá-lo. O desenvolvimento de software já é complexo o suficiente; não deixe que a burocracia disfarçada de metodologia o torne ainda mais penoso. Liberte-se das cerimônias vazias e volte a focar no que importa: o código e o usuário.
Vou deixar esse pequeno RANT que ilustra bem os meus argumentos contra o SCRUM