No mês passado Jeff Sutherland e companhia publicaram um pacote de expansão para o Framework Scrum (vou chamá-lo de SGEP para abreviar). E verdade seja dita, meio que flopou. Tivemos cerca de meia semana de posts no LinkedIn (principalmente reviews negativos) e acabou.

Não queria escrever nada superficial sobre isso, então tentei ler cuidadosamente, com baixas expectativas, e fiz algumas anotações ao longo do caminho.

Não é perfeito…

Scrum é um framework e portanto é incompleto por natureza. Ele nos dá a tarefa de completá-lo com práticas, técnicas e ferramentas, e essa é a melhor parte do Framework Scrum na minha opinião.

Quando ouvi pela primeira vez sobre o pacote de expansão, temi que ele preencheria as lacunas e tornaria a coisa toda mais prescritiva, e acho que a maioria das pessoas compartilhou o mesmo sentimento. Os autores conseguiram evitar esse problema muito bem, porém, havia outros problemas que encontrei.

Não é um pacote de expansão

Ao invés de apenas adicionar novas informações, os autores também mudaram alguns conceitos originais (ex: revertendo para o uso da palavra roles ao invés de accountabilities).

Também diz que o Product Backlog Refinement pode ser um evento, o que realmente não aprecio já que na minha experiência esse tipo de linguagem fomenta um comportamento mecânico.

Não é um único documento. Como os autores afirmam logo no início:

“Este documento é uma coleção de trabalhos independentes. Cada seção mantém sua licença original ou status de copyright, conforme indicado.”

Então a leitura é uma estrada cheia de lombadas, e às vezes repetitiva.

Fora isso, eu diria que é praticamente inofensivo.

Na verdade pode ajudar quem está tendo dificuldades com Scrum

Venho ensinando desenvolvimento de software e Scrum desde 2013, e ouso dizer que uma boa parte das perguntas que as pessoas me fazem durante sessões de treinamento podem ser respondidas pelo pacote de expansão.

E na maioria das vezes o SGEP conseguiu fazer isso expandindo o PORQUÊ das coisas, com um enorme foco em empirismo.

Mais palavras facilitam o entendimento

Deixe-me dar um exemplo concreto: a Sprint Review. O Scrum Guide original é um tanto quanto críptico quando diz:

O propósito da Sprint Review é inspecionar o resultado da Sprint e determinar futuras adaptações

Scrum Guide, 2020

Também diz que O Product Backlog também pode ser ajustado para atender novas oportunidades.

Nas minhas aulas frequentemente levo algum tempo para discutir isso: precisamos determinar futuras adaptações, o que significa mudar o Product Backlog de alguma forma. Portanto, uma Sprint Review que não muda o Product Backlog é algo que deveria causar alguma reflexão. Além disso, se a Sprint Review é um evento obrigatório, significa que o Scrum Team não está passivamente aberto a mudar o Product Backlog: eles estão ativamente buscando essas mudanças.

O SGEP usa mais palavras para descrever isso:

“O Product Backlog (o quê) É adaptado” - Não “também pode ser ajustado”, mas um forte “É.”

Esse é o tipo de diferença que importa para mim. Reforçando que Scrum é sobre aprender através de experimentação para que possamos usar informação fresca para desenvolver coisas.

Foco em Empirismo

O principal problema que a maioria das pessoas tem com Scrum, às vezes sem nem perceber, é que usam o framework acreditando que vai aumentar a velocidade de desenvolvimento. Isso frequentemente coloca Product Owner e Developers em confronto ao invés de colaboração. Esse problema é tão comum que a última atualização do Scrum Guide mudou o termo “Development Team” para “Developers”, e a explicação de por que fizeram isso foi:

O objetivo era eliminar o conceito de um time separado dentro de um time que levou ao comportamento de “proxy” ou “nós e eles” entre o PO e Dev Team.

Agora existe apenas um Scrum Team focado no mesmo objetivo, com três diferentes conjuntos de responsabilidades: PO, SM e Developers.

- Scrum Guide 2020 Revisions

Não me entenda mal: eu gosto dessa mudança. Mas para iniciantes ou mesmo pessoas que têm usado o Framework Scrum de forma disfuncional por muito tempo, isso não vai resolver nenhum problema. Quer dizer, nem o SGEP resolve, mas pelo menos acho que fez um trabalho melhor tentando alcançar isso.

Por exemplo, o SGEP:

• Afirma claramente que ser uma feature-factory ou uma discovery factory não é desejável

• Estabelece que o Product Owner precisa comunicar efetivamente os resultados

• O Produto se torna um artefato com métricas baseadas em resultados

O SGEP também cria a Definition of Outcome Done, e tenho sentimentos mistos sobre isso. Por um lado adiciona mais uma peça ao quebra-cabeça e torna o framework Scrum mais prescritivo, mas por outro lado pode ser especialmente importante para aqueles começando ou tendo dificuldades com Scrum.

Falando nisso, o SGEP também fornece alguns insights valiosos para aqueles começando ou tendo dificuldades com seu trabalho como Scrum Masters.

Fornece melhores direções para Scrum Masters

O Scrum Guide original descreve o Scrum Master em meia página. E se você tem uma boa dose de experiência com o framework, isso é mais que suficiente.

O SGEP, porém, entra mais nos detalhes específicos, mas sem limitar muito do seu trabalho. Afirma, por exemplo, que o Sprint Backlog deve ter trabalho suficiente para começar, ex: comece com um ou dois Product Backlog Items em direção ao Sprint Goal. E você pode ler essa frase como: “não existe Definition of Ready”.

Outro exemplo é o Product Backlog: enquanto o guia original afirma que o Scrum Master deve encontrar técnicas para definição efetiva do Product Goal e gerenciamento do Product Backlog, o SGEP adiciona algumas informações valiosas em cima disso, como: Um Product Backlog menor frequentemente fornece mais Transparência ou até a sugestão de usar um Outcome Criteria para Product Backlog Items.

Mais uma vez, sei que essas são notícias velhas para alguns. No entanto, torna óbvio algumas das coisas que as pessoas frequentemente têm dificuldade em aprender.

Então, é valioso?

Pode ser. Mas não para todo mundo. Mas ler é um bom exercício de qualquer forma, então vá em frente. O foco em empirismo é o que me fez gostar, e é um pacote de expansão, o que significa… é opcional de qualquer forma. Você também pode pegar algumas das ideias e aplicá-las se não quiser adicionar tudo.

Então, se você está indo bem com Scrum, não precisa. Afinal, você provavelmente já está fazendo a maioria das coisas descritas lá.

Se você sente que o Scrum Guide é críptico e te deixa com a sensação de que deveria elaborar um pouco mais em alguns aspectos porque você está travado, então o Scrum Guide Expansion Pack pode ser uma boa coisa para você.