Céticos do Scrum e alguns iniciantes frequentemente torcem o nariz para a ideia de que o Scrum não pode ser modificado.
Um questionamento comum — muitas vezes feito como uma armadilha — é o seguinte:
A exigência de que o Scrum não seja alterado não vai contra o primeiro valor do Manifesto Ágil?
Afinal, ao dizer que não se pode mudar o Scrum, não estaríamos valorizando mais o processo do que os indivíduos e interações?
A resposta curta é: não, não estamos.
E aqui está o motivo pelo qual o Scrum deve ser utilizado como foi concebido.
Escolher Só o Que Convém no Scrum Não É Scrum
Papéis, eventos, artefatos e regras do Scrum são imutáveis — e embora seja possível implementar apenas partes do Scrum, o resultado não é Scrum.
O Scrum só existe em sua totalidade e funciona bem como um contêiner para outras técnicas, metodologias e práticas.
O Scrum Guide diz claramente: você pode implementar alguns componentes do Scrum sem aplicar o framework completo.
Você é livre para omitir um evento ou mudar alguma regra.
O Guia apenas aponta que, ao fazer essas alterações, você não está praticando Scrum.
É como dizer: se você deixa um jogador pegar a bola com as mãos e sair correndo, isso não é mais futebol.
Obviamente, você pode mudar o Scrum — ninguém vai te impedir.
Mas a partir do momento em que isso acontece, deixa de ser Scrum, e essa distinção é crítica.
Essa diferença importa porque, assim como outros frameworks ágeis, o Scrum é um sistema complexo e adaptativo, que evoluiu ao longo do tempo para gerar um resultado bem específico:
um produto funcional, bem testado e potencialmente entregável.
Se você muda ou omite um componente, é bem provável que o resultado final também mude — e de forma indesejada.
Quebre as Regras de Forma Intencional e Significativa
Quando eu estava no ensino fundamental, minha professora de inglês me lançou aquele velho clichê:
“Você precisa conhecer as regras do inglês para poder quebrá-las.”
E eu, o engraçadinho que era — e ainda sou — respondi:
“Eu posso quebrar as regras bem.” Viu? Acabei de fazer isso.
E ela disse:
“Mas você consegue quebrá-las de forma significativa?”
O ponto dela também se aplica perfeitamente ao Scrum.
Você pode quebrar as regras, mas consegue fazer isso de um jeito que o resultado continue sendo relevante?
Você consegue quebrar as regras do Scrum e ainda assim entregar produto funcionando com frequência, em ciclos curtos?
Se a resposta for sim — vá em frente.
Se ainda não for o caso, você fará um favor a si mesmo, ao seu time e à sua organização ao implementar o Scrum como ele foi pensado e usá-lo para se tornar especialista em entregar software pronto.
O objetivo não é ficar bom em Scrum — é ficar bom em entregar software funcionando.
Depois, se você sentir que algum componente precisa ser mudado ou removido, pode tomar uma decisão informada, executar um experimento e ver se a mudança traz bons resultados.
No meu próximo post, vou me aprofundar no Daily Scrum, explicar por que as pessoas tendem a mudar esse evento e mostrar formas de corrigir o problema.
Enquanto isso, dê uma olhada no nosso blog sobre ágil e Scrum para outras dicas e insights úteis.
