Muito já se disse sobre a dificuldade da utilização correta do Scrum, e, na verdade, de qualquer framework ágil. No caso do Scrum, no entanto, há um ponto extra bastante interessante.

O Scrum é um framework fechado, composto de artefatos, cerimônias e papéis, amarrado por regras. Por fechado eu quero dizer que ele está definido em um guia, o Scrum Guide, e se você não está seguindo suas recomendações, você não está fazendo Scrum. O Jeff Sutherland, um dos criadores do Scrum, chegou inclusive a recomendar o Nokia Test para saber se você está ou não usando Scrum.

Falhar em utilizar os conceitos do Scrum significa que você está fazendo Scrum-But, ou “Scrum-Mas”. Um ScrumBut, conforme explicado tantas vezes pelo Ken Schwaber (o outro pai do Scrum) e tão falado nos cursos de PSM, tem a forma de “Eu uso Scrum mas <algum conceito do Scrum não sendo respeitado> porque <algum motivo para evitar mudança > então <alguma gambiarra>”. Por exemplo: “Eu uso Scrum mas não temos o PO presente porque o cliente não quer participar do projeto porque ele acha que dá muito trabalho então o time faz o papel como PO.”, ou “Eu uso Scrum mas não fazemos retrospectivas porque o time conversa constantemente então todos já sabem como melhorar o processo e o produto”.

A única prática opcional do Scrum é a reunião de planejamento de relase, e segundo conversas que tive com o Ken na última semana, ela não deverá mais fazer fazer parte do Scrum em muito breve. Quando (e se) isso se confirmar eu aviso vocês. Todo o resto é obrigatório.

O fato de o Scrum ser fechado traz a ele muitas críticas. É comum vermos nos últimos anos artigos, palestras, pessoas, blogs, dizendo como algumas empresas modificaram o Scrum e sobreviveram ou até melhoraram, e completam que não mudar o Scrum é uma recomendação burra. Essas observações vem junto com críticas ao Scrum em si, por não permitir tais mudanças, e aos pais do Scrum, que detém a autoridade de dizer o que é ou não Scrum, por tê-lo criado e mantido-o fechado.

Tais críticas esquecem muitas vezes que o objetivo ao dizer que uma empresa está praticando ScrumBut não é dizer que ela é ruim, mas que ela poderia ser melhor.E a crítica só se aplica a empresas que estão iniciando no Scrum e estão falhando na sua aplicação por completo, e terão problemas causados pelo uso incompleto. O Scrum é fechado porque é muito dificil a uma empresa que nunca foi ágil, que está abandonando o waterfall e o comando e controle ter sucesso no uso do Scrum usando apenas pedaços dele. Idealmente a empresa vai usar o framework todo por um período razoável antes de fazer qualquer mudança, para que saiba exatamente o que deve mudar, evitando mudanças que atendem à conveniência de qualquer pessoa da empresa (time Scrum ou não) mas não à do projeto.

Criei então um modelo visual pra atender essa dinâmica. Um trapézio atende perfeitamente o que quero propor. Pensei em outros modelos visuais, mas nenhum me satisfez por completo; fiquei com o trapézio. O Trapézio representa as práticas e conceitos do Scrum, o quanto utilizamos do Scrum efetivamente.

Quando estamos na curva de subida do trapézio do Scrum estamos na adoção. Nesse momento a empresa ainda não usa todas as práticas do Scrum, está efetivamente fazendo ScrumBut, e vai buscar usar o que falta. Quando alcançar o uso correto do Scrum vai entrar na parte plana do Trapézio, e vai permanecer lá enquanto for conveniente. Somente depois de uma boa experiência nesse patamar, depois que as mudanças culturais estão consolidadas, a empresa pode começar a próxima curva, a de descida. Na curva de descida a empresa, livre e independente que é, pode modificar o que quiser no Scrum, para melhor atender suas necessidades, e de seus projetos. Nesse momento a empresa já sabe como melhorar constantemente, já aprendeu o que funciona, e já falhou com o que não funcionava. Nesse momento ela vai otimizar seu processo livre de qualquer framework, inclusive o Scrum, mas pode manter o que achar melhor.

O trapézio do Scrum
O Trapézio do Scrum

Só há uma observação a fazer: quando a empresa está fora do plateau, na subida ou na descida, ela não está praticando Scrum. Dizer que ela está criaria muita confusão sobre o que o Scrum é ou não é, e essa confusão não é benéfica a ninguém. E não usar Scrum não é um problema, desde que os valores e princípios ágeis estejam na cultura da empresa.

Essa maneira de encarar o processo se encaixa muito bem nos conceitos de níveis de aprendizagem baseados em Shu-Ha-Ri que o Alistair Cockburn menciona de vez em quando e aprofunda no seu livro “Agile Software Development, Cooperative Game”.

ShuHaRi
ShuHaRi em kanji

A subida é Shu, onde ainda estamos aprendendo, temos ainda dificuldade nos conceitos e temos que buscar fazer o básico direito. No Ha passamos a observar nossas opções e ficamos bons no que fazemos. No Ri as regras não importam mais, os conceitos fazem parte da nossa carne, e somos livres para nos movimentar como acharmos melhor. No fundo, é tudo uma questão de níveis de aprendizagem.

ShuHaRi no trapézio
Shu-Ha-Ri no trapézio

O próprio Ken Schwaber já encorajou no seu blog e em outros lugares que as empresas criem frameworks e processos diferentes do Scrum. Segundo ele isso é uma forma de evoluirmos como indústria. Suas palavras exatas são:

“If you don’t like Scrum, we welcome and invite you to devise something else. Just don’t call it Scrum.”

Ou em português:

“Se você não gosta de Scrum, o incentivamos e convidamos a conceber outra coisa. Só não chame-o de Scrum “.

Sendo ele um dos maiores proponentes do Scrum, vejo isso como um convite muito saudável a inovação, o que torna injustificável qualquer crítica ao Scrum ou a ele.

Vamos então entender o que significa de verdade um Scrum-But, lutar para eliminá-los, e usar o Scrum corretamente. Se eventualmente percebermos que precisamos mudar, depois da nossa adaptação cultural, vamos fazê-lo. E vamos parar com essa birra de reclamar sobre o que Scrum é ou não é.

Em tempo: este post estava agendado faz uns 5 dias, e o Felipe Rodrigues, que também é da Lambda3 e publica neste mesmo blog fez um post com uma forte relação com este, não deixe de ler “O que vem depois do Agile”.