3 “fake news” que você já deve ter ouvido sobre o Scrum
--
O Scrum se tornou absurdamente popular, e boa parte desta popularidade se deve a sua simplicidade. Mas, como o Scrum Guide dizia em suas primeiras linhas da versão 2017:
Scrum is simple to understand, but difficult to master
Ou seja, existe um universo de distância entre entender Scrum e realmente dominá-lo. E é aí que mora o perigo: Esta distância é o habitat perfeito para as vítimas do efeito Dunning Kruger.
Do Wikipédia: O efeito Dunning-Kruger é o fenômeno pelo qual indivíduos que possuem pouco conhecimento sobre um assunto acreditam saber mais que outros mais bem preparados, fazendo com que tomem decisões erradas e cheguem a resultados indevidos; é a sua incompetência que os restringe da habilidade de reconhecer os próprios erros.
Dito isto, vamos às três fake news!
1 — O problema do Scrum é que ele é muito simples
O Scrum é um framework, mas é comum escutar pessoas se referirem ao Scrum como uma metodologia. Pode parecer implicância minha, mas essa simples troca de palavras diz muito sobre o entendimento do Scrum.
Afinal, o que é um framework? Bem, de acordo com o dicionário de Cambridge:
a supporting structure around which something can be built
O Scrum é uma estrutura sobre a qual você deve construir sua maneira de trabalhar. É como o Ruby on Rails, o ExpressJS ou o Hibernate: eles não funcionam sozinhos, mas te ajudam a trabalhar de uma forma mais estruturada e produtiva.
Frameworks são incompletos por padrão e de propósito. São criados para que você possa pensar e expandi-los da maneira que fizer mais sentido no seu contexto de trabalho. E é daí que surgem as práticas ágeis como Story Points, User Story Mapping, Priorização por Risco x Valor, User Stories, etc.
Como o Scrum implementa o ciclo PDCA, é possível adotar uma determinada prática ágil, validar seus efeitos e decidir se vale ou não a pena continuar com aquela prática. E claro, é preciso experimentar novas idéias e repetir esta reflexão ao final de cada Sprint.
Resumindo:
O Scrum é simples e incompleto de propósito para fazer você pensar em maneiras de complementá-lo.
Se alguém lhe disser que o problema do Scrum é ser simples demais, esta pessoa ainda não entendeu nada sobre o framework.
2 — Management 3.0 e DevOps vieram para substituir o Scrum
Em Minas Gerais temos uma expressão muito utilizada quando alguém diz algo assim:
MÉQUÉ??? — Do mineirês: como é que é?
Esta afirmação não faz o menor sentido se você já compreendeu o conceito de um framework: Management 3.0 e DevOps chegam para complementar, e não para substituir.
Afinal, o Scrum Guide diz que:
Os Scrum Teams são estruturados e empoderados pela organização para gerenciar seu próprio trabalho.
Sim, o Scrum não fala sobre automatizar deploys, por exemplo. Não fala em feedback wraps, delegation boards ou motivadores intrínsecos.
Porque o Scrum é um… framework!
Acredito que esta representação visual utilizada pelo Alexandre Magno em seus treinamentos ilustra muito bem esta idéia.
3 — Não temos mais times Scrum. Temos Squads.
Essa é bem interessante, e eu adicionei aqui porque cada vez mais vejo organizações utilizando termos do famoso modelo Spotify. E muitas vezes a justificativa é a de que os times são multidisciplinares e não segmentado por áreas de conhecimento.
Mas, o que o Scrum Guide diz sobre seu Scrum Team?
- Scrum Teams são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto.
- Individualmente os integrantes do Scrum Team podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence ao Scrum Team como um todo.
O conceito de Squads nasceu de maneira colaborativa no Spotify e foi parcialmente documentado em 2012 neste pdf Henrik Kniberg e Anders Ivarsson. No documento, disponível neste link, eles dizem que:
A Squad is similar to a Scrum team, and is designed to feel like a mini-startup. They sit together, and they have all the skills and tools needed to design, develop, test, and release to production. They are a self-organizing team and decide their own way of working.
É sempre válido refletir sobre o modelo adotado pela organização:
- Seu Scrum Team possui as características mencionadas no Scrum Guide?
- Sua organização provê o ambiente necessário para a existência de Squads/Scrum Teams?
- Qual problema está sendo atacado com a adoção de Squads?
- O que diferencia seu Squad de um Scrum Team?
Os Squads fizeram sentido no contexto de escala do Spotify, e talvez até sejam compatíveis na sua organização. Mas é fundamental compreender quais problemas o Scrum e o "Modelo Spotify" tentam resolver antes de fazer um CTRL+C / CTRL+V.
No final das contas, a desinformação sempre existirá e eventualmente as pessoas podem propagá-la mesmo com a melhor das intenções. A única forma que conheço de evitar essas armadilhas é seguir o conselho do sábio filósofo ET Bilu:
E aí, vamos separar um tempinho para reler as 16 páginas do Scrum Guide?
