O Scrum é visto como uma metodologia de desenvolvimento de software flexível e adaptável, que foca na melhoria do processo de desenvolvimento e à qual houve vários casos de sucesso atribuídos. Contudo, muitas equipes continuam a sentir um grau de inflexibilidade e rigidez. O problema seria do Scrum ou da maneira como vem sendo adotado?
Terry Bunio, na sua carta ao Scrum conta como se encantou inicialmente com os processos e procedimentos do Scrum. Aos poucos, no entanto, percebeu que a rigidez do framework não dava a liberdade necessária para o sucesso dos seus projetos.
Eu precisava de um processo ao qual pudesse adicionar tarefas e requisitos durante o sprint quando isso fizesse sentido. Não queria estar limitado pela duração das retrospectivas, se achasse que havia mais para ser discutido… não gostava de ser chamado de Scrum Master. O papel parecia diminuir o meu valor como gerente de projetos, tornando-me apenas um guardião do processo, ao invés de um membro importante. Sentia-me como se não fizesse mais parte da equipe.
Marek Blotny, demonstrou sentimento similar sobre as práticas dos standups diários. Blotny diz não gostar da ideia de membros da equipe ficarem “parados” aguardando a sua vez de falar. Isso acaba, de acordo com ele, com o compartilhamento espontâneo de conhecimento. Blotny também menciona que às vezes o limite de 15 minutos atrapalha. De acordo com ele, se uma boa discussão estiver acontecendo e toda a equipe estiver envolvida, a discussão deveria continuar.
Se me perguntassem se faz sentido impor uma estrutura rígida como as reuniões diárias, responderia que definitivamente não. Pode haver reuniões diárias úteis e efetivas que incentivam o trabalho em equipe – ou uma estrutura rígida em que se que seguem as regras estritamente.
Rod Claar diz que, embora o Scrum seja flexível, as equipes que o adotam pela primeira vez tendem a torná-lo mais rígido na tentativa de acertar com o Scrum já na primeira tentativa. Rachel Davies também destaca essa tendência:
Fico alarmada quando ouço falar de Scrum Masters ou de equipes tentando utilizar “Scrum como manda o manual”. Scrum é o ponto de partida da jornada de uma equipe pelo processo ágil de desenvolvimento; utilizá-lo não é o objetivo final. O Scrum é usado para entregar incrementos do produto. Nunca virão investigar se o trabalho de sua equipe está em conformidade com o Scrum.
Geoffrey Wiseman adiciona que a rigidez no processo e a agilidade não são necessariamente coisas opostas. O processo pode definir que não deve haver interferência depois que um sprint é iniciado. O sprint pode ser visto como padrão para planejamentos e implementações, mas é definitivamente aberto e flexível.
Este seria um caminho difícil de seguir? Talvez sim. Alguns vão argumentar que, se não é possível conviver com essas limitações, não se deveria utilizar o processo. Mas acredito que, na prática, um sprint pode sim sobreviver a uma realocação momentânea de recursos.
As consequências da rigidez do processo são tão fortes quanto a equipe quiser que sejam. Embora inserir algumas limitações possa impedir que todo o processo acabe no caos, ser rígido demais, ignorando condições práticas, é prejudicial tanto para a equipe quanto para o projeto.