Lift-off di progetto: uno strumento potente per creare comprensione comune

Che cos’è e a cosa serve il lift-off di progetto

Il lift-off è una pratica che ha 3 obiettivi principali:

dare forma al progetto e definirne chiaramente lo scopo (purpose)
creare allineamento tra le persone interessate dal progetto (alignment)
chiarire il contesto più ampio in cui il progetto si inserisce ed eventuali vincoli (context)

Generalmente il lift-off è un workshop che viene effettuato all’inizio di un progetto o anche in fase di avanzamento qualora uno dei tre elementi indicati sopra (obiettivi, allineamento e contesto) venga a mancare in corso d’opera.
Ad esempio potreste accorgervi di alcune perplessità durante i grooming del team…

Perché lift-off?

Il termine inglese lift-off indica il decollo.
Di fatto rappresenta una metafora dell’avvio di progetto.
E’ il momento in cui tanti aspetti devono essere coordinati a livello di sistema per garantire la riuscita dell’operazione.
Si sale tutti in aereo diretti nella medesima direzione.
Rispetto al più noto “kick-off” di progetto, il termine lift-off sottolinea il concetto che l’inizio del progetto è una fase collegiale, non individuale e che è fondamentale creare sintonia tra tutti i partecipanti.

Quanto dura?

Non esiste una regola fissa.
Il lift-off dura quanto serve e dipende dall’entità del progetto, dal grado di conoscenza del team e dai rischi.
Diciamo che la durata minima corrisponde a mezza giornata (è il tempo necessario per attraversare tutti gli step del workshop) ma in alcuni casi il meeting può essere esteso anche a una settimana.

Chi partecipa al lift-off di progetto

Ovviamente la composizione dei partecipanti può variare a seconda del tipo di progetto e quando viene fatto, ma in generale è utile mettere insieme tutti coloro che sono essenziali per il suo successo.
E’ particolarmente utile avere una composizione d’aula variegata: il business owner, il team, product managers, business analyst, in generale la comunità di progetto e – se possibile – i clienti stessi.
Avere nel lift-off solo le persone appartenenti al proprio team non vi consentirà di sfruttare a pieno la potenza di questo strumento.

Cosa preparare prima del meeting

Una serie di materiali fungeranno da supporto e da information radiator nel corso dell’incontro. Per questo motivo è opportuno che siano preparati prima dell’inizio. Possono essere lavagne o fogli di grandi dimensioni in cui andremo a raccogliere i post-it prodotti dai partecipanti.

Questi “contenitori” che vengono predisposti dal facilitatore verranno svelati mano a mano che il lift-off procede e riguardano i 3 aspetti principali sui quali verte l’incontro:
– il perché del progetto
– il cosa del progetto
– il contesto in cui il progetto si inserisce

Ovviamente devono poi essere disponibili tutti gli strumenti necessari per il lavoro: penne, post-it e generi di conforto vari per le pause.
La scelta della logistica è un aspetto importante di questo processo.

Come iniziare

E’ opportuno che l’incontro sia condotto da un facilitatore, possibilmente esterno al progetto.
All’inizio il facilitatore illustrerà ai partecipanti che cos’è la pratica del lift-off e quali benefici offre.
Ribadirà inoltre alcune regole (ad. esempio evitare l’uso di cellulari e laptop, scrivere sui post-it dubbie e domande, ecc.).
Non c’è un modo che va bene o no. E’ però importante che i partecipanti capiscano che il valore di questo meeting sta nel mettere a fattor comune i diversi punti di vista e farli dialogare; i post-it non sono altro che “gettoni di discussione”.

Come si svolge l’incontro

Non esistono delle regole fisse in questo senso e possono essere vari gli strumenti utilizzati nel lift-off.
Io vi racconto un format articolato in 4 fasi, che mi sembra particolarmente efficace.

1. Individuare lo SCOPO

Ai partecipanti viene posta una prima domanda:
qual è lo scopo del progetto?
In questa fase si lavora sul “perché” e sulla vision del progetto.
Ognuno ha qualche minuto a disposizione per scrivere le proprie risposte sui post-it.
Una volta terminata questa fase individuale i post-it vengono posizionati dove possono essere visibili a tutti.
Chi attacca il proprio post-it è invitato a spiegarlo agli altri e mano a mano le risposte vengono raggruppate per cluster.

2. Creare un ELEVATOR PITCH

Qui il facilitatore spiega che cos’è un elevator pitch, fornisce qualche esempio e invita ad utilizzare il formato standard, ovvero:

PER – [indicare il cliente]
CHE – [presentare i bisogni/le caratteristiche distintive]
il PROGETTO [nome del progetto in questione]
E’ – [definire la categoria di prodotto/servizio]
CHE – [indicare le caratteristiche distintive della soluzione proposta]

La condivisione dell’elevator pitch ha lo scopo di creare allineamento tra i partecipanti.
In questa fase ci si sta concentrando più specificamente sulla mission del progetto, sul cosa si sta andando a costruire.
Se vengono individuate diverse tipologie di clienti con bisogni differenti è opportuno seguire il format del pitch per ognuno di essi.

Al termine di questa fase il facilitatore può ripercorrere tutto ciò che è stato esplicitato per i vari clienti e prendere l’occasione di sottolineare cosa è stato scoperto di nuovo mettendo a fattor comune i diversi punti di vista.

3. Definire i VICINI DI CASA

Chi sono tutti i possibili stakeholder del progetto in questione?
Qual è il sistema complessivo in cui il progetto si inserisce?
E’ importante anche in questo caso arrivare a condividere la visione d’insieme.
Ai partecipanti viene chiesto di individuare tutte le parti coinvolte direttamente o indirettamente dal progetto al fine di esplicitarne dipendenze esterne, vincoli, confini, necessità in termini di risorse, ecc.

Una volta definiti i “vicini di casa” sarà molto più facile provare a formulare degli use cases.

4. Scoprire cosa non ci fa dormire la notte…

E’ questa la fase in cui – se non dovessero essere già emerse nella terza parte dell’incontro – vengono esplicitate le principali problematiche, i rischi e in generale tutto ciò che può andare storto.
Anche in questo caso ci avvaliamo dei post-it e delle idee individuali condivise poi con il gruppo.
E’ una fase molto importante per rendere esplicite le aspettative degli attori coinvolti che dovranno essere gestite durante il progetto.

Conclusione

Al termine dell’incontro è sempre buona norma chiedere un feedback ai partecipanti sull’utilità del meeting (in termini di ritorno per il tempo investito) e su come poterlo migliorare in futuro (chiedete cosa ha senso mantenere, aggiungere o togliere).

Se siete interessati ad approfondire l’argomento questo è il libro che fa per voi: “Liftoff: Launching Agile Teams & Projects” di Diana Larsen

22 Settembre 20155 Settembre 2021

PO Camp: 10 motivi per andare

Si è concluso da qualche giorno a Baratti il PO Camp 2015, evento dedicato ai temi della Product Ownership giunto ormai alla terza edizione.
Sulla scia dell’entusiasmo che questo appuntamento annuale mi lascia sempre alla sua conclusione ho deciso di raccontare perché mi piace e perché vale la pena spendere un week end in compagnia di alcuni tra i più appassionati agilisti italiani.

Ecco qui in ordine sparso i motivi per cui sinora non ho saltato alcuna edizione.

1. “Ma quanti Product Owner Madama Dorè…”

Quest’anno i Product Owner erano la rappresentanza più consistente tra i 46 partecipanti al PO Camp.
Che c’è di strano, direte voi?
Bè, innanzi tutto trovarsi 2 giorni in compagnia di una ventina di Product Owner italiani non capita spesso (… a me capita solo qui!).
Tanti Product Owner tutti assieme li ho visti solo al corso di certificazione, ma si teneva a Londra e lì è tutta un’altra storia…
In sostanza: i PO hanno spesso difficoltà, risorse e situazioni comuni. Potersi confrontare su questi temi con tante altre persone che vivono le medesime esperienze tutti i giorni per me è un lusso.

2. Open Conference

La formula del PO Camp è invariata sin dagli esordi.
Si tratta di una Open Conference, ovvero una conferenza in cui i temi trattati non seguono un’agenda predefinita ma emergono in base alle richieste, alle curiosità e ai dubbi dei partecipanti.
Chiunque può proporre un argomento che desidera presentare, approfondire o capire meglio grazie all’aiuto degli altri.
L’agenda viene creata collaborativamente all’apertura della prima giornata.
E’ una formula poco usata negli eventi in Italia che consente di trattare in un contesto informale ciò che sta davvero a cuore ai partecipanti.

3. La varietà dei temi

4 o più sessioni parallele ogni ora intervallate da pranzo, chiacchiere e coffee break. A volte è difficile scegliere tra le proposte concomitanti, tutte interessanti.
Si spazia dagli strumenti di lavoro del Product Owner al release planning, dai contratti agili ai framework per scalare in aziende di grosse dimensioni, dalle personas al change management.
Questi sono solo un esempio dei tanti temi proposti e se temete che il tono sia troppo serio per un weekend potete sempre dedicarvi a scoprire le similitudini tra il tango e lo Scrum (fantastica sessione “feet on”) o testare per primi un gioco da tavolo per insegnare lo sviluppo software ai bambini.
Qui si discute di tutto, anche a tavola o in serata davanti a una birretta.

4. Non solo Product Owner e non solo sviluppo software

Questo è un altro aspetto di grande interesse per me.
Al PO Camp non ci sono solo Product Owner (siamo tutt’altro che un circolo esclusivo!).
Sono presenti anche Scrum Master, Coach Agile, manager, product manager che si stanno avvicinando al mondo dell’Agile e vogliono farsi un’idea più precisa di cosa li aspetta ed anche professionisti che non hanno nulla a che fare con lo sviluppo software come architetti ed insegnanti.
Il bello è proprio mettere a fattor comune esperienze di utilizzo della metodologia in contesti differenti, una contaminazione di idee in grado di generare preziosi insight e soluzioni innovative.

5. Sessioni all’aperto

Il clima è ancora buono (cade sempre negli ultimi giorni d’estate) e la location ha ampi spazi all’aperto.
Per questo vi potrebbe capitare di discutere i problemi ricorrenti che incontra un Product Owner nella sua professione a bordo piscina o confrontare gli strumenti per definire le priorità al bar.
Quest’anno abbiamo saltato la sessione al mare (solitamente l’ultima della giornata di sabato) perché il vento era freschino, ma vedere gruppi in cerchio sulla spiaggia del golfo di Baratti che parlano assiduamente di Scrum mentre nonni e bambini fanno il bagno è uno spettacolo da vedere almeno una volta nella vita.

6. Interventi di valore

Quest’anno per la prima volta è stato introdotto un intervento di uno speaker d’eccezione.
Il concetto di valore è stato l’argomento del workshop tenuto da Andrea Provaglio, unica sessione predefinita in agenda.
Per quanto sia bello il confronto tra product owner, il punto di vista di chi ha grande esperienza e grande visione sistemica offre nuove prospettive… di valore appunto.
Il workshop è stato una gradita novità per i partecipanti!

7. I giochi serali

Il post-cena è sempre ludico e anche quest’ultimo anno non è mancato il divertimento.
Protagonisti 9 product owner, i rispettivi team e i Lego trasformer.
Nonostante la mia performance discutibile e la scarsa conoscenza dimostrata sul dominio macchine e motori (papà perdomani!), il gioco mi ha dato la possibilità di sperimentare in un ambito differente le dinamiche di team, così come i punti di forza e di debolezza nell’esercizio del ruolo.
Il gioco apre ad interessanti riflessioni che maturano nei giorni successivi.
E’ un’ottima dimostrazione dell’orgoglio del fare squadra e della creatività di ognuno… per non parlare poi dei virtuosi del product canvas, degli elevator pitch e delle presentazioni multimediali da far invidia al Google I/O.

8. La location

Si tiene a Baratti (provincia di Livorno), in uno dei tratti più belli del litorale toscano. A pochi chilometri dalle tombe etrusche di Populonia e dagli imbarchi per l’isola d’Elba.
Se partecipate forse non avrete tempo di visitare i dintorni, ma potrete apprezzare il profumo delle pinete, l’ottimo vino e i cieli tersi anche durante i lavori.
La location è stata scelta apposta in centro Italia per consentire a tutti i partecipanti da nord, sud, est e ovest di raggiungere abbastanza agevolmente il Camp.

9. La community

E’ la mia terza volta al PO Camp.
Ricordo la prima volta che sono venuta qui.
Non sapevo cosa mi aspettava, non sapevo chi avrei trovato, conoscevo solo una persona e temevo di essere “un pesce fuor d’acqua”.
Alla cena del venerdì sera mi sentivo già “a casa”.

E’ bello condividere le proprie passioni con chi è entusiasta tanto quanto te.
Pensavo che avrei preso contatto con altri professionisti del settore, ho incontrato degli amici.
E oggi ci si ritrova qua e là ai convegni o su hangout e si riparte ogni volta da dove ci si era lasciati.

All’inizio eravamo quattro gatti, oggi abbiamo quasi raggiunto la dignità di una community.

10. Sapere di non sapere

Tutte le volte che si chiude il PO Camp vivo questa sensazione: un misto di entusiasmo e di terrore.
Da una parte l’esaltazione di aver partecipato a qualcosa di unico, in compagnia di persone di valore che hanno dedicato tempo ed energia a mettersi in gioco; dall’altra la consapevolezza di aver ancora tantissima strada da fare per diventare davvero un bravo Product Owner.

Il sapere di non sapere mi fa compagnia.
Non resta che rimboccarsi le maniche…

15 Marzo 201512 Dicembre 2022

Cosa mi ha insegnato il mio team

“Cosa mi ha insegnato il mio team”?

E’ il tema di un talk corale che si è tenuto durante la giornata “Agile for innovation” al Politecnico di Milano il 3 marzo.
Il tema e l’idea dello speech collettivo è opera di Fabio Armani.
Io ho partecipato al lavoro insieme ad altri 3 compagni d’avventura perché quando è stata lanciata l’idea mi è sembrato un argomento interessante da sviscerare.
Ed ecco qui di seguito qualche suggestione sul tema dal punto di vista di un Product Owner, che è una figura borderline (in tutti i sensi!) tra prodotto e IT.

Facile dire siamo Agili, difficile esserlo davvero…

Mi è capitato di vedere spesso transizioni più formali che sostanziali.
E’ un passaggio faticoso per tutti (management, product manager, sviluppatori) perché le abitudini sono dure a morire.
Anche se siete entusiasti di questo cambiamento potreste scoprire di adottare comportanti di micro-management “nascosti” sotto nuove spoglie.
Qualche esempio? Se il vostro backlog è una costellazione di storie di dettaglio o le vostre user stories hanno criteri di accettazione che sono infinite liste di dettagli e minuzie… sono segni che qualcosa non funziona come dovrebbe!

Con queste riflessioni in testa mi sono chiesta cosa posso fare io per agevolare questo cambiamento?
La domanda più importante da farsi è questa:

Come Product Owner qual è il mio valore aggiunto nel team?

Nel caso degli sviluppatori è facile rispondere: loro realizzano incrementi di prodotto, software funzionante.
Io come PO sono di aiuto se entro nei dettagli? Direi proprio di no…
Ciò che posso offrire io è il contesto, gli scenari di mercato, la visione d’insieme.
Inquadrare il singolo incremento di prodotto – ed anche il task – in una prospettiva più ampia, comunicare il tema, l’epica, l’obiettivo e il bisogno a cui cerchiamo di rispondere.
Cercare di legare il particolare al generale e viceversa può essere un’attività molto utile per la consapevolezza del team e la percezione del valore del proprio lavoro.

Prima abbiamo parlato di “smells”, ovvero i segni di qualcosa che non sta funzionando a dovere, ma…

Come ci accorgiamo che le cose vanno nel verso giusto?

Nel corso degli anni ho imparato a riconoscere 2 segnali che per me sono molto indicativi.
Uno è di tipo organizzativo e riguarda l’equilibrio tra business e tecnologia.
Nel momento in cui si raggiunge una posizione dialettica, le esigenze di entrambe le funzioni trovano ascolto e vengono integrate nel prodotto stiamo già assistendo agli effetti positivi del cambiamento di mentalità.

Tutto questo si riflette anche nel prodotto… quando ci rendiamo conto che non è costituito solo da nuove funzionalità.
Se c’è un push eccessivo sulla delivery rischiamo di dimenticare che esiste anche altro.
Il debito tecnico non scompare da solo!
Aspetti come il refactoring, le performance e la scalabilità – su cui i team di sviluppo insistono particolarmente – sono parte essenziale della qualità del prodotto e della sua sostenibilità nel tempo.
Troppo spesso il business dimentica questo aspetto… sino a quando viene messo davanti all’evidenza che anche il rilascio di una funzionalità banale richiede mesi.

Co-creazione

Quando siamo sulla strada giusta condividiamo i medesimi obiettivi ed è su questi – come azienda – che dobbiamo rimanere focalizzati.
Non ci interessa fare la spunta su un elenco di funzionalità determinate a priori; vogliamo indurre cambiamenti nel nostro utente finale e vogliamo seguire passo passo queste modificazioni tenendo conto dei feedback.
Sentiamoci liberi di esplorare delle alternative con il team.
Se abbiamo lavorato bene come product owner e siamo riusciti a trasmettere i reali bisogni dei nostri utenti accogliamo le proposte dei nostri sviluppatori perché ci possono fornire ottimi spunti e aiutare a trovare soluzioni brillanti.

In sintesi una delle lezioni più importanti che ho imparato in questi anni è che come Product Owner una volta che sono riuscita a comunicare in maniera efficace qual è l’obiettivo finale da raggiungere è opportuno che io faccia un passo indietro per lasciare al team lo spazio di crescere, diventare grande e autonomo nell’utilizzo delle pratiche agili.