Agile, ma senza Sprint?

"Fede, ci serve un po' di Agile Mindset in azienda e ci piace molto Scrum, però... è proprio obbligatorio fare gli Sprint? Cioè, prendere 8 persone e staccarle dal lavoro per due settimane, è proprio impossibile. Non passerà mai. Che si può fare?"

Questa è una delle domande in cui mi imbatto molto frequentemente facendo consulenza su Agile.

Scrum senza Sprint è un po' come la botte piena e la moglie ubriaca: tutti vorrebbero che ci fosse una magica bacchetta con cui avere un'azienda più agile, purché però non si debba cambiare troppo il modo di lavorare.

Da Scrum Master, dovrei dare una risposta abbastanza semplice: no. Almeno non in prima battuta, non senza aver testato il metodo nella sua interezza. Lo Sprint è centrale nell'economia di un progetto Scrum perché permette alle persone di lavorare in modo coordinato, sincrono, focalizzato, senza "context switching" ed avendo un obiettivo scontornato: un "working increment". Posso fare a meno di questi elementi ed agire in modo comunque Agile?

Agile nasce da Lean e ne eredita la missione di fondo: eliminare gli sprechi e così facendo massimizzare il flusso del valore verso il cliente. In particolare, Agile guarda ad alcune tipologie specifiche di spreco (Muda):

• I rework - ogni Sprint termina con un Working Increment, con un prodotto in qualche modo "funzionante" che il cliente (interno o esterno) può provare e su cui darà un feedback, nel corso della Sprint Review. Ottenere feedback frequentemente su un prodotto "semi-finito" consente di minimizzare il rischio che il prodotto differisca dalle attese del cliente - e quindi la quantità di rework necessaria se il feedback lo otteniamo solo a fine progetto.
• Il Context Switching - il fatto che uno Sprint sia un periodo di lavoro dedicato e focalizzato da parte di tutto il team di progetto limita la necessità di "saltabeccare" fra un compito e l'altro. Questo switch continuo è devastante sulla produttività: lo psicologo Gerald Weinberg stima un calo di produttività fino al 50%, man mano che si sommano i progetti che vengono portati avanti in contemporanea. Scrum cerca di evitare questo problema rimuovendolo alla fonte: un team, un progetto. Context switching limitato al minimo. E quindi? Quindi evitiamo il problema di "tornare nel flusso" - quel fenomeno per cui riguardiamo un testo con gli occhi vacui per riprendere il filo logico. Ad esempio: se ora smetto di scrivere questo articolo per fare mezz'ora di lavoro su un altro task, aver cambiato contesto mi farà perdere più tempo della mezz'ora necessaria a fare l'altro lavoro: avrò anche 5, 10 minuti necessari per rileggere ciò che ho già scritto e riprendere il filo del testo. (Nel grafico, in blu è il tempo produttivo, in verde il tempo perso a causa del Context switching)

• I tempi d'attesa (wait times) - se sul progetto io lavoro il Lunedì ed il mio collega il Martedì ed ho bisogno di un confronto, i casi sono due: o lo interrompo mentre sta facendo altro (context switching) oppure devo mandare una mail ed aspettare la sua risposta. E se il Martedì io non lavoro su quello, perché sono su 4 progetti diversi, va da sé che riprenderò la cosa in mano Mercoledì. Quindi anziché una soluzione immediata ad un problema, si aspettano due giorni. Questa è una delle ragioni per cui, spesso, i progetti falliscono lato temporale - oppure per cui abbiamo bisogno di pianificazioni "per eccesso". Se invece lavoriamo tutti allo stesso progetto negli stessi giorni, la collaborazione è più immediata ed i tempi d'attesa più limitati.
• I colli di bottiglia (bottlenecks) - analogamente al punto precedente, in un team Scrum i colli di bottiglia vengono eliminati alla radice tramite allineamenti giornalieri (Daily Scrum, Kanban Board) ed il fatto che le persone lavorino in modo dedicato e colocato consente lo "swarming": più membri del team si mettono a lavorare sullo stesso task, in modo da rimuovere l'ostacolo che potrebbe comportare un collo di bottiglia. Va da sé che se le persone non lavorano in modo dedicato e sincrono, lo swarming non è un'opzione.

Quindi, no Sprint no Agile?

Non proprio: essere talebani non aiuta. Se l'obiettivo è condurre progetti in maniera Agile con Scrum, meglio non saltare gli Sprint, ma se l'obiettivo è aumentare l'agilità organizzativa in team che lavorano su una grande quantità di mini-progetti, o su progetti "secondari" rispetto al Business as Usual, si può cercare una soluzione diversa, salvaguardando i punti che abbiamo evidenziato sopra.

I mini-sprint

Se anche il team di progetto non può dedicarsi full time per interi sprint di 5 giorni, proviamo a trovare la minima durata in cui ha senso chiedere alle persone di lavorare assieme. Poi, proviamo a costruire dei "mini-sprint" in questo lasso di tempo.

Possiamo dedicare al massimo una giornata al progetto (20%FTE)? Scegliamo un giorno in cui tutto il team lavora sul progetto, contemporaneamente e proviamo a ricreare la struttura di uno Sprint.

1. Prevediamo un veloce meeting di Sprint Planning (1 ora) come ultimo meeting della giornata precedente al mini-sprint. Questo serve a riprendere il filo del discorso, definire lo Sprint Goal, dividerlo in task e prendere qualunque decisione altra che sia necessaria per il successo dello Sprint. Bisogna coinvolgere, in questo meeting, anche uno stakeholder rilevante col ruolo di Product Owner.
2. Eleggiamo a turno uno Scrum Master. Difficilmente in un team Scrum "part-time" sarà possibile prevedere questo ruolo in maniera dedicata. Quindi, organizzazione pratica degli ambienti di lavoro, timekeeping, facilitazione delle riunioni, aggiornamento delle kanban saranno delle responsabilità "aggiuntive" di un membro.
3. Chiudiamo con Review e Restrospective come ultimo momento dello sprint. Se possibile, facciamolo la mattina del giorno dopo il mini-sprint, in modo da lasciare la giornata intera per il lavoro sul progetto e presentare il lavoro al cliente (interno/esterno) quando è ancora molto fresco. La Retro, su uno sprint di un giorno, sarà breve: due ore complessive per entrambe le riunioni dovrebbero essere sufficienti. Review e Retro devono essere pianificate in anticipo, in modo da non rischiare che vengano saltate, o che si creino situazioni di attesa o di context switching.
4. Usiamo Kanban. Se possibile, una Kanban ben fatta è ancora più importante, perché funge da traccia e "memoria" anche a distanza di tempo. Se poi - cosa frequente - non tutti i membri del team dedicano lo stesso tempo al progetto, la Kanban è un buon modo per allineare quei membri del team che lavorano sul progetto in maniera meno dedicata.

In conclusione

Se vogliamo trarre il meglio da un progetto Scrum, meglio che sia fatto "come si deve". Introdurre sprint, PO e Scrum Master è spaventoso all'inizio, ma porta benefici che, altrimenti, non vengono raggiunti facilmente. Eppure, la ricerca dell'Agilità accomuna ogni azienda, in ogni settore, con ogni tipologia di progetto. Prima di guardare a Scrum come ad un framework "troppo impegnativo", o come una generica "mentalità", vaga e disincarnata, proviamo a procedere per gradi, così da familiarizzare l'organizzazione con un metodo di lavoro diverso e mostrare i benefici di una trasformazione anche così "piccola".

Hai esperienza di portare gli Sprint in azienda? Scrivilo nei commenti!

Questo articolo parte di una serie dedicata ad Digital e Agile HR. Qui puoi trovare gli altri.

Costruire una Digital People Strategy

La Digital Culture in Azienda

Creare la Digital Culture in azienda: un decalogo

Agile HR

Agile Learning Organization

HR Come Scrum Master

Agile Performance Management