Olá a todos!
Hoje vamos falar sobre um tema muito controverso e, por vezes, muito criticado dentro do Scrum. Vamos falar sobre formas de utilizar o Scrum sem algumas das cerimônias que são preconizadas pelos criados do método. Essa forma de utilização já ganhou até apelido no mundo ágil, o ScrumBut. Neste Agile Brazil, estivemos com o palestrante Alexandre Magno, e ele falou sobre o assunto, então vamos lá.
Vamos começar com uma definição, segundo a revista Engenharia de Software Magazine 50:
“ScrumBut ocorre quando o Scrum expõe uma disfunção ou uma falha difícil de ser corrigida e que leva a empresa a modificar o Scrum com o intuito de tornar invisível o problema”
Normalmente as empresas saem dos métodos tradicionais de engenharia de software e passam a usar o Scrum acreditando nas melhorias e benefícios da agilidade, entrega contínua, adaptação e correção rápida, e todos os preceitos que conhecemos. Mas como podemos descobrir se alguma das cerimônias do Scrum pode estar atrapalhando o pleno funcionamento da organização?
Em primeiro lugar, não podemos retirar algo do Scrum só porque achamos ruim, ou chato, ou demorado. Tudo deve ser medido. Nada que não é medido não pode ser confirmado como problema. Isto é, se você não tem certeza que uma reunião ou outra atrapalha o andamento de um projeto, não ache que retirando essa reunião o andamento do projeto correrá bem. Tudo deve ser medido e devidamento documentado.
Uma ideia, que já foi aplicada aqui na empresa, foi levantar uma hipótese e testá-la. Em um dos projetos aqui, a hipótese levantada foi de que o planning 2 tradicional não tinha efeito prático no andamento das histórias. No caso do projeto em questão, a equipe estava trabalhando em histórias distintas, que é outro ponto que diferencia do Scrum tradicional, e as histórias não tinham uma especificação clara. Por isso, eles precisavam especificar as histórias ao decorrer da Sprint. Resumindo, eles estavam fazendo o planning 2, mas eles faziam durante a Sprint. Depois disso tudo, eles puderam verificar uma melhoria nas entregas.
Eles conseguiram identificar um problema, uma “falha” no Scrum, embora eu ache o termo falha muito forte. Com isso, podemos ver que o Scrum aceita mudanças. O Scrum é um framework e adaptação é seu lema. Então porque não podemos adaptar o framework? Mas é claro que isso deve ser feito com cautela.
A comunidade scrum.org descreve uma sintaxe particular para o ScrumBut, da forma:
(ScrumBut)(Razão)(Solução)
Vamos verificar como isso funcionaria no caso citado acima:
“(Nós usamos Scrum, mas)(não precisamos nos reunir no inicio da Sprint para fazer o Planning 2)(pois fazer ao decorrer da Sprint foi mais vantajoso e prático)”
Outros casos válidos, já testados aqui foram:
“(Nós usamos Scrum, mas)(histórias de design nem sempre são bem definidas)(então algumas histórias não precisam de definição de pronto)”
Mas é claro que, casos como esses devem ser evitados:
“(Nós usamos Scrum, mas)(não fazemos reunião diária)(porque é chato e parece ser perda de tempo)”
“(Nós usamos Scrum, mas)(retrospectiva são perda tempo)(então não fazemos)”
Claro que devemos estudar cada caso cuidadosamente. O que funciona aqui na empresa, pode não funcionar na sua empresa e assim por diante.
E você na sua empresa? Faz algo um pouco diferente do Scrum? Compartilhe com a gente como foi sua experiência.
