Un mestiere complesso

Fra i molti compiti di uno Scrum Master ce ne sono alcuni che egli svolge con un profilo molto vicino a quello di un Agile Coach: il suo ruolo, in questo caso, non è di guidare o di decidere cosa fare — ricordiamo che non è il capo del team, non un manager che accentra in se il potere decisionale — ma quello di stimolare un pensiero critico o di favorire l’intelligenza collettiva dell’intero team.

Quando lo Scrum Master lavora come un Agile Coach è focalizzato sulla crescita del team a cui appartiene, aiutandolo a interrogarsi su come migliorare, quali azioni o esperimenti provare, come capire se abbia senso oppure no fare una cosa invece che un’altra.

Cosa fa un Agile Coach

Un Agile Coach è un coach con forti competenze agili ed esperienze di trasformazioni in organizzazioni di vario tipo, e che quindi applica il modello “coaching” all’interno di un processo di trasformazione organizzativa. In passato abbiamo pubblicato un articolo che consente di approfondire la differenza fra formatore, mentore e coach [1].

Coaching

In questo articolo, per dovere di sintesi, ci limiteremo a dire che, con il termine inglese coach, si indica una persona che aiuta il suo interlocutore a individuare un obiettivo e a raggiungerlo. Durante questo percorso egli non è una guida, quanto piuttosto qualcuno che fornisce supporto per il “trasporto”: e questo si capisce bene guardando all’origine del termine che vuol dire “carrozza”, e solo dalla seconda metà dell’Ottocento passa a indicare anche il “tutor” e successivamente l’allenatore.

Il coach fornisce un aiuto per avere sempre sotto controllo gli obiettivi (“Stiamo andando verso la direzione in cui volevamo andare?”), per chiedersi se abbia senso cambiarli (“Sono emersi nuovi fattori che possono farci pensare sia il caso cambiare direzione?”), o se gli strumenti in nostro possesso sono adeguati al tipo di percorso che dobbiamo percorrere.

Agile Coaching

Dato che Agile è miglioramento continuo, un Agile Coach, fra le molte cose che fa, stimola la crescita delle persone, delle competenze operative e della propensione a provare nuove cose, sperimentare nuovi modi di produrre valore per utente finale. In questo lo Scrum Master è pienamente coinvolto dato che fra i suoi compiti c’è quello di far crescere le persone: alterna momenti in cui è formatore ad altri in cui supporta tale processo di crescita aiutando il proprio interlocutore a comprendere cosa serva e quali possono essere le azioni da intraprendere. Per fare questo mestiere si interfaccia spesso con altre funzioni dell’organizzazione, come l’ufficio del personale e HR.

Avere una persona di questo tipo all’interno del proprio gruppo stimola la crescita delle competenze e sopratutto l’autonomia, l’auto-organizzazione delle persone come singoli e come team. Invece di decidere e di fare le scelte per il team, lo Scrum Master in veste di Agile Coach permette alle persone di prendere decisioni e di confrontare i risultati attesi con gli obiettivi prefissati. In questo contesto fornisce strumenti operativi — per esempio come definire un set di criteri di accettazione misurabili o come formalizzare un obiettivo, come progettare un esperimento — lasciando poi al gruppo le decisioni, le valutazioni, le considerazioni se tale azione sia realmente utile per il raggiungimento degli obiettivi.

Durante tale processo, uno Scrum Master dovrebbe potersi muovere con obiettività e distacco dal progetto, in modo che possa “fare le domande” senza influenzare risposte (“Sosa ne pensate se facciamo questa cosa? Sarebbe bello se ci riuscissimo, no?”).

Scrum Master come facilitatore

Abbiamo parlato di miglioramento continuo, che in Agile si costruisce tramite un processo fatto di prove, esperimenti, errori e correttivi. Azioni e correzioni. In tal contesto lo Scrum Master non è il giudice delle azioni o degli esperimenti, ma svolge un altro importantissimo compito.

Aiuta il gruppo a definire come una azione si potrà considerare conclusa (con successo o fallimento);  contribuirà a definire quali dovranno essere le valutazioni da fare per stabilire il raggiungimento di tali obiettivi.

Per fare un esempio, al termine di una retrospettiva spesso il team arriva a formulare una serie di azioni di miglioramento per indirizzare alcuni punti individuati dal team stesso. Lo Scrum Master in tal caso non dovrebbe esprimere un giudizio sulla bontà o sulla utilità di tali azioni ma dovrebbe invece stimolare il gruppo a rispondere a domande del tipo:

• Rispetto agli obiettivi che ci siamo dati (p.e. in che modo lavorare come team o in che modo realizzare il prodotto secondo le indicazioni del PO) quanto e come questa azione potrebbe aiutarci ad avvicinarci a tali obiettivi?
• Rispetto alle metriche di performance (p.e. tempo di chiusura di un bug, time to delivery/deploy), in che modo questa azione potrebbe permetterci di ottenere una prestazione migliore?
• E se questa azione risponde ai punti precedenti, come potremmo dire di averla fatta/conclusa?
• Se invece si tratta di un esperimento — per definizione difficilmente collegabile alle metriche di cui sopra, perché un esperimento è innovazione — come possiamo renderci conto che abbiamo avuto successo?
• E in caso di successo come potremo propagare? O, in caso di fallimento, come potremo limitare l’espansione del danno?

Queste domande sono spesso collegate agli obiettivi del team, del significato di miglioramento continuo, del contenuto dell’accordo che il team stabilisce quando inizia a lavorare. L’oggetto di questo accordo è di interesse e di responsabilità di tutto il team; lo Scrum Master si preoccupa di raccogliere e formalizzare questo accordo, rendendolo disponibile al team e proponendolo come elemento fondamentale ogni qualvolta il team debba prendere una decisione.

Scrum Master come negoziatore

Un altro caso in cui loScrum Master può attingere alle competenze dell’Agile Coach è durante quei momenti di discussione e di confronto fra le persone del team. Lo Sprint Planning è probabilmente, fra gli eventi di Scrum, uno di quei momenti in cui serve  una figura di moderatore o negoziatore; egli deve infatti aiutare a mettere d’accordo due bisogni differenti, apparentemente in conflitto: da un lato il PO ha spesso la necessità di mettere in lavorazione nello sprint il maggior numero di  elementi possibili, dall’altra il Dev Team deve invece capire cosa c’è da fare, provare a entrare nel merito per fare una stima in modo da accettare un monte lavoro compatibile con le proprie possibilità.

Due visioni in contrapposizione che, senza una sintesi comune e l’accettazione di un medesimo pensiero e degli stessi valori di collaborazione e co-creazione, non potrebbe mai funzionare. Lo Scrum Master è quindi quella persona che mette a confronto questi due punti di vista differenti e, tramite una attività di negoziazione, cerca di far giungere le persone a un accordo che permetta loro di lavorare. Non si limita a trovare l’accordo, ma lavora affinché le persone prima di tutto comprendano valori e principi che possono permettere a quell’accordo di stare in piedi.

Un esempio di negoziazione in Sprint Planning

Per comprendere meglio, vediamo un esempio: possiamo immaginare lo Sprint Planning come il processo di riempimento di uno scaffale della libreria. L’esatto numero di libri che riusciamo a metterci dipende dalla larghezza dello scaffale e dalla dimensione dei libri.

A volte capita che, dopo aver accettato alcuni item pechér essere messi in lavorazione nel prossimo sprint, il Dev Team consideri non fattibile l’accettazione del successivo elemento proposto dal PO: riprendendo la metafora della libreria, il libro potrebbe essere troppo grande per lo spazio rimasto a disposizione sullo scaffale.

Al PO serve per la fine dello sprint anche quell’item rimasto escluso; il Dev Team che ha il compito di stimare e di decidere quanti item mettere in lavorazione,  dice che non c’è rimasto spazio.

Un modo per uscire da questa situazione di stallo  potrebbe essere quello di capire meglio bisogni e trovare altri modi per ottenerli.

Lo Scrum Master, rivolgendosi al Dev Team, potrebbe fare domande del tipo:

• Vi vengono in mente soluzioni tecniche che potrebbero alleggerire la lavorazione di questo ultimo item escluso (o di uno dei precedenti)? In tal caso cosa rimarrebbe fuori?
• Farlo “più leggero” vorrebbe dire abbassare la qualità del prodotto finito, oppure potremmo completarlo in un secondo momento? Vi vene in mente un modo per togliere qualche funzionalità particolarmente complessa, rimandando a un momento successivo la sua implementazione?
• Se la rimandiamo a dopo, il costo complessivo aumenterebbe di molto (forse conviene fare tutto ora)?
• Ci sono delle propedeuticità tecniche che possono impedire questo “alleggerimento”?

Rimanendo nella metafora dello scaffale, è come se alleggerissimo i libri per farli più sottili, togliendo pagine non importanti o rimandandole a futura lettura, senza che si perda il senso del libro complessivamente.

Al Product Owner invece potrebbe chiedere:

• Fra le cose che sono già state messi in lavorazione (libri già presenti nello scaffale) c’è qualcosa di meno urgente rispetto a quello che resta fuori? Oppure potremmo fare uno di questi elementi in modo meno gravoso, con meno funzionalità, rimandando a un altro sprint il completamento?
• Pensi sia accettabile rimandare a poi l’implementazione di un pezzo di un item (come proposto dal team) facendo prima quindi la parte difficile e completandolala poi? Questo ti permetterebbe di andare a far vedere ai tuoi stakeholder intanto la parte difficile sulla quale tu hai più dubbi in modo da tornare poi con feedback necessari per raffinare e completare tale elemento.

Su questa falsariga potremmo proseguire con mille esempi; di fatto si tratta di capire quale sia il reale bisogno di ognuna delle parti coinvolte in questo lavoro incrementale: il PO vuole vedere pezzi del prodotto nascere e funzionare e poterli testare con gli stakeholder, mentre il Dev Team desidera poter lavorare su una quantità di funzionalità che è oggettivamente in grado di concludere per la fine dello sprint.

L’arte della negoziazione non è facile, e necessita anche di una certa predisposizione, ma è una competenza che si apprende e si esercita, come molte altre soft skills tecniche.

Conclusioni

L’abbiamo detto e ripetuto: quella dello Scrum Master è una professione che richiede competenze multidisciplinari e formazione continua. E anche una certa capacità di adattare il proprio modo di operare alle diverse fasi e ai diversi aspetti che costituiscono, tutti insieme, il processo di sviluppo gestito con Scrum. Per questo la vita da Scrum Master magari è molto impegnativa… ma non è monotona.