Scrum è diventato assurdamente popolare, e buona parte di questa popolarità è dovuta alla sua semplicità. Ma, come diceva lo Scrum Guide nelle sue prime righe della versione 2017:
Scrum is simple to understand, but difficult to master
- Scrum Guide, versione 2017
In altre parole, c’è un universo di distanza tra capire Scrum e padroneggiarlo davvero. Ed è lì che sta il pericolo: questa distanza è l’habitat perfetto per le vittime dell’effetto Dunning-Kruger.
Immagine creata da www.investificar.com.br
Da Wikipedia: L’effetto Dunning-Kruger è una distorsione cognitiva a causa della quale individui poco esperti in un campo tendono a sopravvalutare le proprie abilità autovalutandosi, a torto, esperti in quel campo.
Detto questo, andiamo alle tre fake news!
1 — Il problema di Scrum è che è troppo semplice
Scrum è un framework, ma è comune sentire persone riferirsi a Scrum come una metodologia. Può sembrare pignoleria, ma questo semplice scambio di parole dice molto sulla comprensione di Scrum.
Dopotutto, cos’è un framework? Beh, secondo il dizionario Cambridge:
A supporting structure around which something can be built
- Dizionario Cambridge
Scrum è una struttura sulla quale dovresti costruire il tuo modo di lavorare. È come Ruby on Rails, ExpressJS o Hibernate: non funzionano da soli, ma ti aiutano a lavorare in modo più strutturato e produttivo.
I framework sono incompleti per default e di proposito. Sono creati affinché tu possa pensare ed espanderli nel modo che ha più senso nel tuo contesto lavorativo. Ed è da lì che vengono le pratiche agili come Story Points, User Story Mapping, Prioritizzazione Rischio x Valore, User Stories, ecc.
Dato che Scrum implementa il ciclo PDCA, è possibile adottare una certa pratica agile, validare i suoi effetti e decidere se vale la pena continuare con quella pratica. E ovviamente, è necessario sperimentare nuove idee e ripetere questa riflessione alla fine di ogni Sprint.
In sintesi:
Scrum è semplice e incompleto di proposito per farti pensare a modi per completarlo.
Se qualcuno ti dice che il problema di Scrum è essere troppo semplice, questa persona non ha ancora capito nulla del framework.
2 — Management 3.0 e DevOps sono arrivati per sostituire Scrum
In Brasile abbiamo un’espressione comunemente usata quando qualcuno dice qualcosa del genere:
COSA??? — Traduzione: scusa, cosa hai appena detto?
Questa affermazione non ha senso se hai già capito il concetto di framework: Management 3.0 e DevOps arrivano per completare, non per sostituire.
Dopotutto, lo Scrum Guide dice:
Gli Scrum Team sono cross-funzionali, il che significa che i membri hanno tutte le competenze necessarie per creare valore in ogni Sprint.
- Scrum Guide
Sì, Scrum non parla di automatizzare i deploy, per esempio. Non parla di feedback wrap, delegation board o motivatori intrinseci.
Perché Scrum è un… framework!
Credo che questa rappresentazione visiva usata da Alexandre Magno nelle sue sessioni di formazione illustri molto bene questa idea.
Rappresentazione del framework Scrum completato da tecniche emergenti, creata da Alexandre Magno
3 — Non abbiamo più team Scrum. Abbiamo Squad.
Questa è piuttosto interessante, e l’ho aggiunta qui perché vedo sempre più organizzazioni usare termini del famoso modello Spotify. E spesso la giustificazione è che i team sono multidisciplinari e non segmentati per aree di conoscenza.
Ma, cosa dice lo Scrum Guide del suo Scrum Team?
-
Gli Scrum Team sono cross-funzionali, il che significa che i membri hanno tutte le competenze necessarie per creare valore in ogni Sprint.
-
All’interno di uno Scrum Team, non ci sono sotto-team o gerarchie. È un’unità coesa di professionisti focalizzati su un obiettivo alla volta, il Product Goal.
Il concetto di Squad è nato in modo collaborativo a Spotify ed è stato parzialmente documentato nel 2012 in questo pdf da Henrik Kniberg e Anders Ivarsson. Nel documento, disponibile a questo link, dicono:
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.
Vale sempre la pena riflettere sul modello adottato dall’organizzazione:
-
Il tuo Scrum Team ha le caratteristiche menzionate nello Scrum Guide?
-
La tua organizzazione fornisce l’ambiente necessario per l’esistenza di Squad/Scrum Team?
-
Quale problema viene affrontato con l’adozione degli Squad?
-
Cosa differenzia il tuo Squad da uno Scrum Team?
Gli Squad hanno avuto senso nel contesto di scaling di Spotify, e potrebbero anche essere compatibili con la tua organizzazione. Ma è essenziale capire quali problemi Scrum e il “Modello Spotify” cercano di risolvere prima di fare un CTRL+C / CTRL+V.
Alla fine della giornata, la disinformazione esisterà sempre e alla fine le persone possono diffonderla anche con le migliori intenzioni. L’unico modo che conosco per evitare queste trappole è seguire il consiglio del saggio filosofo E.T. Bilu:
E.T. Bilu leggerebbe lo Scrum Guide prima di iniziare a usare Scrum
Allora, ci prendiamo un po’ di tempo per rileggere le 16 pagine dello Scrum Guide?
