Agile & Dragons

Le sessioni di gioco di D&D…e l’Agile

Ogni sessione di gioco può essere tranquillamente paragonabile a uno sprint in Scrum, durante il quale ogni giocatore non solo cerca di portare a termine la propria storia, ma si impegna anche a supportare i propri compagni.

L’unione fa la forza, sempre

Gli ostacoli che i personaggi affrontano, dai nemici incontrati alle trappole da schivare agli enigmi da risolvere, sono una perfetta metafora di tutti i problemi e gli imprevisti che un team di sviluppo potrebbe essere costretto a fronteggiare.

I singoli individui da soli possono non essere capaci di superare una difficoltà, ma la collaborazione può rendere il totale maggiore della somma delle parti. Lo scopo di ogni sessione non è tanto quello di completare il proprio piccolo obiettivo personale, ma soprattutto collaborare per il raggiungimento di un goal comune.

Per esempio, se un guerriero non è abbastanza forte per colpire un avversario, il chierico può supportarlo con una benedizione che lo rende più competente nella battaglia. Allo stesso modo, se uno sviluppatore è in difficoltà con un task di sviluppo, può ricorrere all’aiuto del team organizzando una sessione di Pair Programming.

Dungeon Master, Product Owner e Scrum Master

Le sessioni di gioco sono organizzate preventivamente da un Dungeon Master (D.M.), che in quest’ottica ricopre un ruolo equivalente a quello del Product Owner (abbreviato in P.O.) in Scrum. Brevemente, un P.O. definisce degli obiettivi globali di una campagna (ovvero le Epiche) e obiettivi di ogni singola sessione (gli sprint), con le corrispondenti sfide (User Story) da affrontare. Come un bravo P.O., il D.M.:

• rimane disponibile durante la sessione per rispondere a dubbi e domande che emergono dal team;
• per rendere soddisfacente la campagna per tutti, deve tenere conto delle effettive possibilità (capacity) del team in modo da tarare le sfide al giusto livello.

Quando la sessione di gioco inizia, il Dungeon Master assume un ruolo da facilitatore, più simile a quello dello Scrum Master.

Un giocatore di D&D è come il membro di un team…

I giocatori, così come i membri di un team, hanno il compito di affrontare e realizzare le storie, portando a termine con la giusta priorità le missioni principali (storie di massimo valore) e le missioni secondarie (storie di media o bassa priorità).
Ogni sviluppatore ha delle competenze specifiche, un proprio background lavorativo, carattere e preferenze a livello di linguaggi o di tecnologie. 

L’analogo in D&D di queste peculiarità personali è rappresentato da razze, classi, background e carattere del proprio personaggio: difficilmente chiederemo a un mago di abbattere una porta a calci, a un ladro di lanciare una palla di fuoco, o a un barbaro di tradurre un antico manoscritto.

In questo senso, la collaborazione fra giocatori è indispensabile per superare sfide che risultano muri insormontabili se affrontati singolarmente, ma semplici ostacoli quando si collabora sfruttando le diverse abilità.

Apprendimento continuo e miglioramento

Nel corso della campagna, i personaggi guadagnano esperienza e salgono di livello, acquisendo nuove abilità. Questo permette al team multifunzionale di diventare sempre più efficace, sia perché i membri si specializzano nei propri punti di forza, sia perché imparano a colmare le proprie lacune, a volte riuscendo a diventare – almeno parzialmente – intercambiabili.

Per esempio, se il ladro trova affascinante la capacità del mago di lanciare incantesimi, può decidere di specializzarsi nel cosiddetto “archetipo” di “Mistificatore arcano”, che gli consente di apprendere alcune magie. Allo stesso modo,

perché uno sviluppatore specializzato in React non dovrebbe imparare a scrivere codice in Kotlin se incuriosito?

Un altro esempio: se uno sviluppatore, crescendo professionalmente, dovesse accorgersi che il suo interesse si estende dalle abilità tecniche anche alle soft skill, potrebbe iniziare a facilitare le retrospettive del proprio team, iniziando un percorso formativo da Scrum Master. Lo stesso può succedere a un personaggio multiclasse: programmatore/Scrum Master come paladino/bardo.

D&D e Agile – Cos’altro abbiamo imparato?

Grazie alla gilda D&D abbiamo imparato a essere empatici verso il personaggio che si sta interpretando, oltre che essere spronati a pensare come si comporterebbe in ogni situazione. Questo permette di abituarsi, nella zona sicura del gioco, a porsi sempre due domande:

“Cosa farebbe questa persona in questa situazione? Perché dovrebbe agire così?”

È un ottimo modo per allenarsi a comprendere e rispettare punti di vista totalmente diversi dal proprio.

In maniera inaspettata, ci siamo resi conto che la similitudine fra D&D e Agile funziona anche in metagaming, come dimostrato da un caso emblematico che ci è capitato.

D&D e Agile sono 2 mondi non così distanti…

In una sessione di gioco, una battaglia è andata per le lunghe perché un giocatore voleva usare un’abilità del suo personaggio, ma non aveva segnato con precisione il funzionamento né il nome corretto. Il Dungeon Master ha “minacciato” il personaggio con “1d20” (tradotto, 1 lancio di dado a 20 facce) di danni al ripetersi di una situazione del genere. Questo perché il tempo speso per cercare la soluzione nei manuali comporta per tutti il rischio di  chiudere l’appuntamento di gilda in ritardo (e non è mai una bella situazione, soprattutto per chi deve tornare a casa in auto in un’altra provincia il venerdì sera). Dato che la “minaccia” non ha sortito l’effetto sperato, siamo entrati istintivamente in modalità retrospettiva: dopo un’assunzione di responsabilità da parte di ciascuno, argomentando meglio le ragioni delle varie parti, con un brain storming collettivo abbiamo proposto delle soluzioni innovative e stabilito dei working agreement solidi per il resto della gilda.

Questo disguido ci ha dato l’opportunità di confrontarci e riflettere su una realtà del nostro lavoro: abbiamo dimostrato ancora una volta che i ritardi nel rilascio di un prodotto (o nel completamento di una missione) dipendono più dalla mancanza delle informazioni necessarie che dalle effettive performance del team nell’eseguire i propri task.

In conclusione:

D&D è un ottimo esercizio di team building, rafforzamento dei principi agili emersi in maniera spontanea, allenamento alla capacità di adattamento e improvvisazione in un contesto diverso da quello dello sviluppo software.