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

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 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.

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”.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.