“Buongiorno a tutti team! Dice il product owner. Allora, vediamo quali storie abbiamo oggi. Ehm, abbiamo un bel backlog…
Team chiede: signor product owner quali sono le storie con cui vuoi partire in questo sprint?
Vediamole insieme, risponde il product owner…”
Così è iniziato il corso “Certified Scrum Product Owner” tenutosi a Milano, il 22 e 23 settembre 2016. Peter Stevens si muoveva disinvolto mentre, con il suo italiano dal marcato accento inglese, passava da un lato all’altro del muro indicando i diversi post it riportanti diciture “backlog”, “ready for dev”, “done”.
Passati una decina di minuti alcuni dei partecipanti hanno iniziato a guardarsi, non capendo bene se quella fosse una sorta di scenetta di Peter o se fosse davvero iniziato il corso.
“Ok team avete le storie, dice il product owner!
Perfetto, risponde il team.
Ora avete cinque minuti per parlare con il vostro compagno a fianco ed appuntarvi quanto avete appena visto”
Con queste parole Peter ha concluso la prima mezz’ora del corso, ha avviato un timer sul suo iPad, ben visibile a tutti, e si è messo in un angolo. I cinque minuti sono iniziati e, come tutti, mi sono messo a discutere di quanto appena visto con chi avevo a fianco. La discussione è stata la prima scoperta del corso: avevo a fianco una ragazza specializzata in sociologia ed il breve dialogo si è rivelato fin da subito contraddistinto da due punti di vista completamente differenti. Io mi concentravo sul metodo di Peter e su come affrontasse il contenuto del corso, mentre lei su come Peter si muoveva e comunicava. Punti di vista diversi, entrambi validi in un momento di confronto costruttivo.
Questa è un pò la sintesi della prima ora del corso a cui ho partecipato, propostomi da ABS all’interno del mio piano formativo: mai avrei immaginato che un corso formativo possa essere strutturato in tal modo. Probabilmente siamo stati tutti abituati al contesto scolastico e la possibilità di sperimentare qualcosa di diverso, fuori da canoni standard, non è affatto scontato.
UN NUOVO PUNTO DI VISTA
Il corso è stato quanto di più interattivo si possa immaginare, in cui gli stessi argomenti sono stati definiti strada facendo dai noi partecipanti, grazie ad una prioritizzazione condivisa. La struttura ha ripreso di pari passo le principali fasi logiche dello scrum: analisi delle storie, discussione tra team e product owner, presa in carico delle storie da parte del team, retrospettiva su quanto trattato/appreso e così via, in maniera ciclica fino all’esaurimento (o quasi) delle storie maggiormente prioritarie nel backlog. Ogni storia era un tema specifico del corso. Tutto esattamente come fosse uno sprint.
Questo metodo “simil sprint”, che Peter non ha affatto introdotto, ha generato nei partecipanti parecchio smarrimento, almeno per le prime ore. Normalmente ci si immagina un corso formativo nel senso più classico del termine: un corso, un professore, una dispensa e poi un esame scritto. Eppure, vi dirò, l’occasione d’aver sperimentato un metodo nuovo è stato forse uno dei maggiori stimoli di quei due giorni. Grazie alla comunicazione diretta e al continuo stimolo, le pause caffè erano sempre ricolme di domande: “Le storie da dove vengono? Come posso parlare di storie all’interno del mio contesto lavorativo in cui curiamo i processi degli istituti sanitari? Oppure parlare di storie all’interno di uno studio di design, di un istituto di recupero, di un’azienda manifatturiera, di un processo di acquisizione di due multinazionali…”. Non nego che questo era probabilmente uno tra gli obiettivi del corso stesso: stimolare persone diverse, in contesti diversi, a ragionare sull’applicabilità di alcuni principi che definiamo “Agili”. In fondo la formazione è esattamente questo, no? Cioè apprendere nuove nozioni ed aprire un confronto con altri e con se stessi su quanto appreso. Questo porta a un duplice beneficio:
- Migliorare il proprio metodo di lavoro grazie alle nuove capacità acquisite;
- Stimolarsi e tenere una mentalità più “aperta”, volta al cambiamento e al miglioramento.
A mio avviso il secondo punto è il vero cuore della formazione, ma non vorrei aprire qui questa parentesi. Quello su cui vorrei focalizzarmi ora è invece un particolare esempio discusso durante il corso, che ritengo possa essere utile in diversi contesti.
SCOPE E MODALITÀ DI RAGGIUNGIMENTO DI UN OBIETTIVO
Come ovvio il corso era rivolto a persone che volessero approfondire i temi inerenti al ruolo del product owner. Una conoscenza basilare sul tema “Agile” era data pressoché per scontata (motivo per cui alcuni partecipanti hanno avuto difficoltà a seguire all’inizio) e questa la daremo per tale anche in questo momento. Un tema che mi ha particolarmente colpito nella trattazione dei diversi temi è stato “l’approccio all’obiettivo”. Per spiegare questo concetto Peter ha sfruttato due esempi concreti, che riporto di seguito:
- Costruzione di un traforo: la costruzione inizia con due macchinari per la perforazione. Si utilizzano macchine molto costose e complesse, che avanzano di pochi metri ogni giorno. Una macchina parte da un lato, l’altra dall’altro. Dopo circa due anni di lavori le due macchine si incontrano. Inizia quindi un ulteriore anno di lavori per ultimare il traforo: la copertura, la strada, i dispositivi di sicurezza e quanto altro necessario.
- Recupero d’emergenza di minatori intrappolati dentro ad una miniera: il recupero inizia con la creazione di un foro molto piccolo. Ne fanno più d’uno, per individuare i minatori più rapidamente. Finalmente trovano i sopravvissuti e dal foro fanno passare i primi soccorsi: una radio per comunicare, del cibo e dell’acqua. Grazie alle radio i soccorritori si possono assicurare dello stato dei minatori ed avviano nel frattempo un’attività di allargamento progressivo del foro. Il foro si allarga e pian piano estraggono i minatori, a partire da quelli in peggiori condizioni.
Cosa c’entrano i due esempi con la nostra trattazione? In sintesi hanno due approcci alla soluzione ben differenti. In buona parte sono soluzioni dettate dalle esigenze: da una parte la realizzazione di un traforo duraturo nel tempo con elevatissimi standard di sicurezza, dall’altro l’emergenza nel soccorrere i minatori. Eppure gli esempi nascondono in sé due modalità di ricerca della soluzione contrapposte. Il primo si basa sull’avanzamento lento e progressivo, dove il traguardo è tangibile solo alla fine. Il secondo invece si avvale di una soluzione semplice, che rapidamente individua l’obiettivo e man mano si “allarga” fino al completo traguardo della meta.
Questi due “approcci” mentali possono essere alla base di tante scelte di prodotto. Mi spiego meglio. Ipotizziamo di voler iniziare un nuovo progetto: supponiamo ad esempio di voler perseguire un business simile al ben noto Amazon, per la compravendita di libri. Il primo metodo ci indurrebbe a partirebbe da uno studio approfondito di tutte le possibili varianti di processo, fino al minimo dettaglio. Inizieremmo con lo studio del mercato, poi fattibilità su alcune soluzioni logistiche, organizzazione interna ed analisi di possibili scenari. Arriveremmo poi ad avere un business plan di dettaglio, un numero non ben definito di stakeholder e, convinti tutti, si potrebbe avviare il business. Il tutto impiegherebbe diversi mesi (direi forse anni). Il secondo metodo invece cosa ci insegna? Forse non è poi così sensato partire “in grande”. Partiamo dal piccolo. Soluzioni? Ipotizziamo un semplice ritiro del libro, da parte del cliente, in una libreria del centro. Nessuna consegna a domicilio per partire. Il cliente si collega ad un sito, molto semplice, dove può selezionare un libro (da un catalogo contenuto) e poi selezionare la libreria dove intenderà ritirarlo. Tempi di esecuzione? Un paio di settimane per il sito, qualche accordo con le librerie… Insomma, in un paio di mesi l’attività può essere avviata. Poi si penserà ad arricchire il catalogo, a prevedere delle consegne a domicilio e pian piano ad ampliare il business includendo prodotti di elettronica, di arredo, materiale per l’ufficio e così via.
Forse ho estremizzato, ma è un pò quello che volevo. Di certo non esiste una via “ottimale” ed universalmente riconosciuta per tutti i problemi. E’ ovvio che per fare un traforo non posso partire da un piccolo foro e poi allargarlo! Ogni prodotto necessita di un proprio programma per la realizzazione, dettato dalle caratteristiche proprie del prodotto stesso. Traforo e fori a parte, quello che mi ha affascinato di questi due esempi è stato proprio l’approccio mentale, che poi è il metodo “Agile” in senso stretto: “consegnare un prodotto funzionante step by step al cliente”. Il confronto tra quanto sia realmente necessario e quanto si vorrebbe fare è un lavoro spesso difficile da svolgere. Personalmente si tende sempre a sopravalutare ogni minima caratteristica dei propri prodotti, dimenticando quali siano quelle che maggiormente apportano valore al cliente finale. Molti slogan di oggi proclamano a gran voce “Less is more”! Ma questa, a pensarci bene, è una mezza bugia. Non è assolutamente vero che “dare di meno” è automaticamente “dare di più”, bisognerebbe pensarci un poco sopra. Per ogni singolo prodotto bisognerebbe analizzarne più a fondo le caratteristiche, per coglierne quelle che maggiormente apportano valore. Solo in un secondo momento è possibile aggiungere le cosiddette “features nice to have”, quelle cioè che aggiungono un valore sempre tangibile ma marginale per il cliente. Prendere scelte di questo tipo, cogliendo in anticipo ogni possibile implicazione, non è certo facile, ma è il lavoro di un buon product owner. Per un product owner è sì vero che “Less is more” ma solo quando nel “less” ci sono le funzioni che maggiormente apportano valore al cliente e più in generale agli stakeholder con cui si relaziona. Per questo motivo il product owner si trova spesso a dire “no” a chi si relaziona con lui e richiede nuove funzionalità in continuazione: scegliere dove concentrare le forze non è un compito semplice ma è vitale per il successo del prodotto stesso. Si potrebbero aprire innumerevoli parentesi su questo tema, su come prioritizzare le funzioni, come individuare quale sia realmente il bisogno de cliente o ancora come definire una vision di prodotto… In queste poche righe spero di aver introdotto il concetto, vi sono diversi libri che spiegano (meglio di me!) tutte queste tematiche.
APPLICAZIONE IN PILLOLE
A qualche settimana dal corso mi è stata fatta una proposta.
“Perché non fare a delle mini sessioni di approfondimento su alcuni temi agili all’interno di ABS?”
La proposta mi è subito piaciuta. Non tanto perché avessi già in mente qualcosa, quanto perché l’idea di condividere internamente dei contenuti d’interesse comune mi sembrava un ottimo approccio per formare indirettamente il team e me stesso. Così, dopo qualche settimana, si è tenuta (per chi ha voluto liberamente partecipare) la prima “Pillola Agile”. Diciamocelo, il nome in sé non è gran che, ma esprime molto bene l’idea del format: una mezz’ora di condivisione su alcuni temi specifici e mirati. Mi è stato chiesto di tenere la prima pillola così, riportando alla mente come Peter aveva iniziato il suo corso, un sabato mattina mi sono messo a pensare all’impostazione del primo incontro.
Ora non voglio riassumerne il contenuto, che di per sé esulerebbe da quanto abbiamo trattato, semplicemente è stata l’occasione di poter implementare alcune cose di quanto appreso del corso. E’ stata un’occasione interessante, soprattutto dopo il corso stesso, poiché la possibilità di mettere in pratica quanto appreso è sempre una preziosa opportunità.
RIFLESSIONI A CONCLUSIONE
Cosa mi porto a casa da questo corso? Personalmente l’esperienza di un metodo di insegnamento “diverso” dal solito e più dinamico. Non da meno l’opportunità di confronto avuta durante le pause, con professionisti di diversi settori e mentalità (dal designer fino all’esperta di M&A).
A mio avviso la formazione non è mai solo e soltanto un “apprendere nozioni” (come già detto), anzi dovrebbe favorire una mentalità aperta al miglioramento, individuale e di gruppo. Il metodo di Peter Stevens è molto sfidante in tal senso, perché si pone davanti a ciascun partecipante in un modo inaspettato, esasperando (a volte) il confronto. Approcci di questo tipo, in ambito formativo e lavorativo dovrebbero essere sempre ben accetti, perché alimentano un processo di miglioramento continuo, sviluppando le potenzialità le persone nel proprio cammino professionale.
Certamente ci sarebbero innumerevoli altri aspetti di cui varrebbe la pena approfondirne il contenuto, ma lascio a voi il compito. Sfogliare il blog di Peter è senz’altro un buon punto di partenza ma, oltre a quello, vi consiglio un paio di video su YouTube a conclusione: il primo in merito alla figura del product owner, il secondo sull’importanza del “perché” in un prodotto.
Mi auguro, personalmente, di avervi instillato un pò di sana curiosità sul tema. C’è tanto da scoprire ed un confronto su qualcosa che ad una prima occhiata può risultare “nuovo e diverso” è sempre un’occasione, perché induce a cambiare il proprio punto di vista e (chissà) ad ipotizzare ad una qualche applicazione dei principi “Agili” nella propria realtà lavorativa.