Scrum Não é Bala de Prata: Como a Agilidade Mal Aplicada Destrói Equipes
Não sou o “pica das galáxias”, mas já passei por algumas empresas e contextos bem diversos. Trabalhei em grandes corporações, médias empresas e pequenas equipes, desenvolvendo sistemas em várias áreas, tanto no Brasil quanto nos EUA. E, sendo bem sincero, em quase todos esses cenários, os agilistas foram um baita pé no saco.
Vi pessoas que nunca escreveram um simples “Hello, World” dizendo como eu deveria desenvolver software. Vi Scrum Masters atuando como microgerentes, impondo regras e cerimônias goela abaixo. Vi sprints de 2 semanas abarrotadas de tarefas que, segundo eles, todas deveriam ser entregues “funcionais de ponta a ponta”. Ou seja: vi agilistas destruírem processos que funcionavam e transformarem o ambiente em um verdadeiro inferno.
Também presenciei projetos rodando apenas com um Kanban leve e sendo um sucesso. E vi projetos com Scrum super bem estruturado que também deram certo. Mas, da mesma forma, já vi o contrário.
O problema não é o Scrum. O problema são as pessoas que o implementam do jeito que querem, sem entender a dinâmica da equipe, sem respeitar o contexto. Muitas vezes caem de paraquedas no time com uma mala cheia de cerimônias e fórmulas "mágicas" — e o resultado é catastrófico.
Até hoje, não encontrei metodologia ou framework que seja bala de prata. Cada equipe deveria moldar seus processos de acordo com sua realidade. Agilidade de verdade é adaptação — não imposição.
O que vocês acham disso tudo? Já passaram por situações parecidas?
Agora conta a novidade :D Brincadeiras à parte esse relato é bom para mais pessoas entenderem isso.
E o Scrum é rum também, mesmo feito certinho, o que não costuma acontecer. Tem muitas pessoas bastante especializadas nisso que mostram como ele atrapalha por si só. E claro muitos vão defender até à morte porque está estão dentro e muitas vezes porque estão em um emprego de Master onde não se responsabiliza por nada e não faz nada de muito importante, geralmente ganhando bem.
Claro que ele pode ajudar um pouco na organização, mas sempre cria alguns problemas. EM alguns casos, como parece ser o relatado acima, cria um grande problema.
Tem outro ponto que ninguém fala e de fato essas metodologias costumam ter uma eficácia um pouco maior: quando as equipes são medíocres ou abaixo disso (se for muito abaixo nada salva). Pode ver, em equipes altamente funcionais não se adota essas metodologias ou adotam de forma muito simples, ou seja, podem ser Agéis, mas da sua concepção original, que é não ter muitas regras, é só o óbvio e simples. Agile foi criada para cortar a burocracia, não para criar novas como fazem por aí.
S2
Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).
Ótima reflexão! Já vi esse cenário várias vezes também. O problema não é o Scrum em si, mas a forma engessada como algumas empresas e agilistas tentam aplicá-lo sem considerar o contexto da equipe. A agilidade deveria ser sobre adaptação e melhoria contínua, mas muitas vezes vira uma receita de bolo imposta de cima pra baixo.
Já vi times que funcionavam super bem com processos simples serem atropelados por uma enxurrada de cerimônias desnecessárias. No fim das contas, o que realmente importa é entender o que funciona para o time e otimizar isso — e não seguir um framework à risca só porque está na moda.
Alguém mais já passou por essa dor?
Scrum já é bem criticado, hoje em dia.
Tem um talk no youtube do Allen Holub, onde ele fala que a frase "Scrum é Ágil" está tão certa quanto "Guerra é paz", vale a pena assistir (https://www.youtube.com/watch?v=F42A3R28WMU)
Uma provocação que ele faz é que o livro mais vendido de Scrum, tem o título de "Scrum: A arte de fazer o dobro do trabalho na metade do tempo".
2x💩 em 1/2 do tempo = 💩💩💩💩. Isso não é agilidade.