Conosci il tuo team

Il motto socratico recitava “conosci te stesso”.
Profondamente convinta del sua valore, ho voluto reinterpretare questo insegnamento in “conosci il tuo team”, ottimo principio da applicare in un contesto agile.
Perché è importante?
Perché se non conosci con chi hai a che fare non sai esattamente quali risultati potrete raggiungere insieme… in termini quantitativi e – soprattutto – qualitativi.

Questo post un po’ sconclusionato è una riflessione “a ruota libera” tratta da qualche anno di esperienza con team molto diversi tra loro. Considerazioni che magari possono tornare utili a chi si trova a muovere i primi passi da Product Owner in un gruppo nuovo.
A me sarebbe stato utile per evitare qualche passo falso…

Non avere fretta
La relazione tra il team e il Product Owner (così come tra il team e lo Scrum Master) è qualcosa che si costruisce nel corso tempo. Non si può pretendere la fiducia da subito e non è possibile accelerare il percorso di conoscenza reciproca.
E’ normale che nel corso delle prime settimane – a volte anche per i primi mesi – ci si studi a vicenda per trovare il giusto equilibrio tra le parti.
Il mio consiglio in questo caso è non avere fretta, non tentare di affrettare il passo o forzarlo.
Siate voi stessi, con il vostro carattere e la vostra professionalità.
Esercitate il vostro ruolo stando aderenti al prodotto (la parte che dovreste conoscere meglio…) e, nel frattempo, non mancate di mostrare come un Product Owner può essere di valore per il team.
Qui non ci sono ricette precostituite! Ogni Product Owner è storia a sé e compie il proprio lavoro con uno stile personale. In ogni caso non siate impazienti di “entrare nel team”, datevi il tempo di capire come sono fatte le persone, come reagiscono a determinate situazioni e come interagiscono tra loro.

Ascolto
Inutile dire che questa è una componente fondamentale in qualsiasi relazione umana. Lo è tanto di più quando si lavora in team.
Per come la vedo io c’è sempre tempo per esprimere la propria opinione, mentre non è detto che l’ascolto abbia una seconda opportunità.
All’inizio più che mai è importante ascoltare il gruppo. Cogliere ciò che viene detto e stare attenti anche a ciò che non viene detto, saper leggere tra le righe insomma.
Capire se nel team avviene una conversazione di cui ancora non fate parte o se manca proprio una corretta comunicazione tra i membri del gruppo. Si tratta di situazioni molto diverse che richiedono approcci differenti.

Adeguare il vostro stile al team
Per muovere i primi passi assieme è opportuno creare quel minimo di sintonia che vi consenta di procedere insieme. Qui è importante capire dove il team ha più bisogno di supporto.
E’ un team composto da professionalità mature ed autonome?
In questo caso il vostro sforzo si concentrerà maggiormente nel trasmettere la vision, gli obiettivi di prodotto che intendete raggiungere e nel rimuovere eventuali impedimenti.
E’ un team poco autonomo che ha bisogno di essere più indirizzato? In tal caso all’inizio potrà rivelarsi utile focalizzarsi maggiormente sulle caratteristiche del prodotto da sviluppare attraverso la conversazione sulle singole user stories e sui criteri di accettazione. Mano a mano che le competenze, l’autonomia e la fiducia reciproca all’interno del gruppo cresceranno sarà possibile adottare uno stile più partecipativo.

Patti chiari
Mentre vi dedicate a  conoscere meglio il team non dimenticate di essere a vostra volta sotto osservazione.
E’ importante che trasmettiate nelle parole e nei fatti il messaggio che voi siete il Product Owner, avete determinate responsabilità e non intendete delegarle.
Lavorare in team può essere bellissimo, ma anche faticoso. E’ opportuno partire con il piede giusto e chiarire i ruoli, chi fa cosa e a chi spettano determinate decisioni.
Quindi non entrate nel merito delle modalità di sviluppo tecnico (sarebbe il modo più veloce per rendervi invisi al team!), ma concentratevi sugli obiettivi che volete ottenere, sul prodotto che volete portare alla luce, sul “cosa” vi aspettate.
E’ altrettanto fondamentale non scendere a compromessi sulle vostre responsabilità: sta a voi Product Owner definire gli obiettivi, dare un ordine di priorità a quanto dev’essere realizzato, pianificare i rilasci ed accettare o rifiutare ciò che è done.
Non siete soli in questo, ma certi compiti spettano a voi in prima persona. Non abdicateli e non fateveli scippare perché sarebbe l’inizio della fine…

Flessibilità sulle soluzioni
Avete un’idea chiara di cosa volete ottenere per il prodotto che gestite nei prossimi 3, 6 mesi? Siete in grado di esprimere questi obiettivi in termini misurabili?
Se sì, siete a un ottimo punto di partenza.
Discutete con il team delle alternative disponibili per raggiungere quei risultati. Sicuramente c’è più di una soluzione che può soddisfare le vostre richieste.
Fate in modo che le persone capiscano bene l’esigenza e si sentano libere di  proporvi soluzioni creative al problema.
E’ probabile che voi abbiate già un’idea abbastanza precisa in testa di come arrivare al risultato, ma non arroccatevi subito nella vostra posizione. Siate disponibili a mettere in discussione il vostro punto di vista.
Per esperienza i risultati più interessanti li ho portati a casa così, quando le idee sono emerse dal gruppo.

Attitudini personali
Ognuno di noi ha preferenze, curiosità ed interessi propri.
E’ così anche nel team di lavoro.
C’è il collega meticoloso, quello che sente  la pressione delle deadline, c’è il guru, quello intruppato per le tecnologie più improbabili, quello super-aggiornato sulle ultime novità e chi preferisce lavorare isolato.
Ognuno di noi ha una propria leva motivazionale con la quale affronta il lavoro, le sfide, in senso lato la vita stessa.
Imparare a riconoscere questa leva nelle persone del proprio team significa avere un asso nella manica.
Ovviamente non è sempre possibile assecondare i desideri di tutti, ma mostrare attenzione per le inclinazioni personali quando si organizza il lavoro è un atto di ascolto, di riconoscimento e di fiducia. Le persone vi dimostreranno che non è mal riposto!

Leggere il contesto
Potreste essere di grande aiuto al vostro team se siete in grado di interpretare adeguatamente il contesto aziendale in cui vi trovate ad operare.
Spesso il team di sviluppo si vive come un mondo a sé un po’ avulso da tutto il resto. Il vostro compito è essere portavoce del mondo esterno (così come del resto dell’azienda) verso il team e del team verso il mondo esterno.
Aiutate le persone a leggere il contesto, ad avere una visione realistica del mercato, dell’azienda, degli obiettivi e dei progetti sui quali si lavora.
Aiutate il gruppo ad adottare uno stile coerente con i valori aziendali. Ad esempio è determinante la qualità totale del prodotto al momento del rilascio? Stressate questo concetto, sottolineate l’importanza dei test ed enfatizzate l’importanza di rilasci bug-free.
E’ fondamentale il time-to-market? Aiutate il team a focalizzarsi sull’essenziale, a lavorare su minimum viable product e a cambiare rotta con estrema rapidità.

Quando sentirete  di conoscere davvero il vostro team potrete dire di far parte del gruppo. Avrete lavorato a lungo per questo, ma sarà solo l’inizio di una splendida avventura tutta da scrivere…

Come pianificare una release a partire dalla velocity

Pianificare una release di prodotto

“Quando rilasciamo?” Ecco la domanda con la quale convivono da sempre i Project Manager e la stragrande maggioranza dei Product Manager.
Anche lavorando in Scrum questa è domanda ricorrente per i Product Owner. 

I progetti inseriti in roadmap hanno un orizzonte temporale che può variare dai 3 ai 6 mesi e necessitano di una pianificazione accurata.
Diciamo allora che è necessario pianificare a livello di release per avere una stima della data di rilascio.

Per fare questo dovremo innanzi tutto stimare la dimensione del progetto da portare a termine (il size di tutte le user stories) e poi fare riferimento alla velocity del team.
Un’altra raccomandazione utile è esprimere la data di rilascio mediante un range di date (dopotutto si tratta di una stima, non di un calcolo matematico!).

Le situazioni che si possono presentare pianificando una release possono essere variegate, a seconda del tipo di mercato in cui è attiva l’azienda, il tipo di contratti utilizzati e l’organizzazione interna delle risorse.
Vediamo alcuni dei casi più frequenti.

Progetto interno, senza vincoli forti su date

Diciamo che il team ha già lavorato su altri progetti.
E’ questo il caso più semplice per effettuare delle stime.
Se il team è già struttuato e lavora su un domino noto con tecnologie conosciute abbiamo confidenza nel fatto che la velocity pregressa sia un buon indicatore del comportamento futuro.

Prendiamo le velocity degli ultimi 6 sprint (o più se sono disponibili ulteriori dati), eliminiamo il valore massimo ed il minimo e facciamo una media delle restanti velocity. Questo è il riferimento per la nostra stima.
Ricordate l’idea di esprimere la stima in un range? Teniamo conto del valore più alto e più basso che rimangono dopo la sottrazione iniziale.

Esempio: 

  •  il team negli ultimi 8 sprint ha avuto la seguente velocity:
    20 + 25 + 31 + 29 + 18 + 34 + 30 + 38
  • eliminiamo i valori 20 e 38 (il più basso ed il più alto)
  • prendiamo 34 come valore superiore e 25 come valore inferiore
  • se il backlog vale 150 story point in totale il progetto sarà terminato in un periodo che varia da 4,4 sprint (nel migliore dei casi) a 6 (nel peggiore).

Per molti un intervallo così ampio non è un’informazione utile… né comunicabile agli stakeholder.
In questo caso vi suggerisco di usare il buon senso.
Comunicare una durata di 4 sprint e mezzo significa  non lasciare respiro al team e non prevedere alcun intoppo o contingenza (ferie, malattia, formazione, ecc.). Sei sprint potrebbero tuttavia risultare poco “digeribili” dai committenti.
Se mi trovassi in una situazione di questo tipo punterei su 5 sprint sapendo sin dall’inizio che alcune funzionalità potrebbero essere oggetto di descoping.

Progetto con data di rilascio fissa

In questo caso il vincolo è dato dal timing, quindi sarà lo scope di progetto a rappresentare la variabile.
Il team parte col chiedersi: “Quante iterazioni abbiamo da qui al rilascio?

Esempio: 

  • la data ultima di rilascio è fissata per il 1° giugno (oggi è il 15 marzo)
  • il team lavora con sprint di 2 settimane
  • le velocity nelle iterazioni precedenti sono: 20 + 25 + 31 + 29 + 18 + 34 + 30 + 38
  • eliminiamo – come prima – i valori 20 e 38 (il più basso ed il più alto)
  • prendiamo 34 come valore superiore e 25 come valore inferiore
  • se il backlog di progetto vale complessivamente 150 story point per la data del primo giugno (5 sprint) saranno completati da un minimo di 125 ad un massimo di 170 story points.

Abbiamo quindi una buona confidenza che il progetto completo di tutte le sue funzionalità possa essere terminato per la data prevista.
O, per la precisione, garantiamo che 125 story points saranno completati per la data concordata e che i restanti 25 hanno buona probabilità di esserlo.
… ma attenzione! Potrebbero presentarsi casi in cui il calcolo evidenzi sin dall’inizio l’impossibilità di terminare per la data concordata.

Progetto con ambito fisso

Abbiamo un “capitolato” vincolante, è quindi la variabile tempo che può cambiare. Il team si chiede “Quanto tempo ci mettiamo a completare tutto?

Esempio:

  • dobbiamo necessariamente realizzare un progetto di 150 story points
  • le velocity precedenti: 20 + 25 + 31 + 29 + 18 + 34 + 30 + 38
  • eliminiamo i soliti valori 20 e 38
  • prendiamo 34 come riferimento superiore e 25 come inferiore
  • il progetto sarà terminato in un periodo che varia da 4,4 sprint (nel migliore dei casi) a 6 (nel peggiore).

In questo caso dato che lo scope è fisso per contratto comunicheremo che il progetto terminerà al più tardi in 12 settimane (6 iterazioni), ma prevediamo che possa anche essere chiuso prima (ad esempio nel corso dell’undicesima o della decima settimana).

Per chi fosse interessato ad approfondire il tema della pianificazione delle release sul sito di Mike Cohn sono disponibili diversi video sull’argomento.

Stime Agili: si parte dalla dimensione del progetto

Nel mondo waterfall la data di rilascio di un progetto – quando non è fissata da contratto – è il risultato di una pianificazione iniziale.
Con l’ausilio di un Gannt vengono messe in sequenza le varie attività da completare in base all’ordine logico di implementazione (concept, progettazione, sviluppo, test, ecc.).

Sulla base del Documento di Requisiti si fa la “lista della spesa” delle attività da realizzare, se ne evidenziano le dipendenze, si assegnano le risorse e mediando tra tempi, costi e ambito si tenta di contenere il più possibile la durata del progetto.

In questo caso le persone che prendono direttamente o indirettamente parte al progetto (gli sviluppatori in prima persona, ma anche i responsabili d’area o eventuali esperti di settore) forniscono una stima temporale delle singole attività.
La somma delle singole durate insieme alla sequenza delle stesse determina la data di rilascio finale.

Quando si utilizzano invece le metodologie Agili il primo passo per stimare la durata di un progetto consiste nel valutarne il size, ovvero la dimensione.
La domanda che si pone lo Scrum Team è:
Quanto è grande il progetto?

Per valutarne la dimensione il gruppo di lavoro deve avere un’idea condivisa  di cosa è necessario realizzare.
Una volta comprese le finalità del progetto nel suo complesso e tradotte le componenti chiave in user stories si procedere a valutarne il size mediante story points o in giornate di lavoro ideali.

Entrambe queste tecniche consentono di esprimere con un sufficiente grado di confidenza la dimensione di una user story, vale a dire l’effort necessario per realizzare la funzionalità in tutte le sue componenti.
Il team in questa fase di analisi deve porre attenzione al fatto che il peso relativo delle storie sia consistente piuttosto che alla precisione della singola stima.

Solo quando tutte le user stories del progetto sono state stimate – anche ad alto livello – si deriva una durata complessiva.
Per farlo è sufficiente dividere la somma degli story points per la velocity del team, ovvero la misura della progressione che è in grado di portare a termine in un singolo sprint.

Facciamo un esempio per chiarire: il team ha valutato che il nuovo progetto cuba in tutto 150 story points. In passato il medesimo team ha avuto una velocity media pari a 25 story points per singola iterazione. Il nuovo progetto durerà quindi 6 sprint.
A questo punto siamo in grado di prendere in mano il calendario e comunicare una data di rilascio: 6 sprint di 2 settimane significano 3 mesi di lavoro.

Ho volutamente portato l’esempio più semplice per far capire come avviene il calcolo della durata. Ci sono tuttavia occasioni in cui il team è totalmente nuovo e lavora per la prima volta assieme, oppure i confini del progetto non sono del tutto chiari in partenza.
E’ utile tener presente che le stime Agili possono esserci d’aiuto anche in questi frangenti, ma le casistiche sono variegate e meritano un approfondimento successivo.

Ricapitolando
Quando utilizziamo metodologie agili per la stima evitiamo di correre subito alle conclusioni assegnando ad ogni singolo task una durata prevista.
Partiamo sempre dalle funzionalità che rilasceremo al cliente finale (perché solo queste hanno reale valore) e seguiamo 3 step:

  1. stimiamo la dimensione di ogni user story e le sommiamo assieme
  2. dividiamo la somma degli story points per la velocità media del team (solo in questa fase iniziamo a parlare della variabile tempo!)
  3. il numero di sprint risultante ci consente di dire, a calendario, quando finiremo

Perché tanta enfasi sulle dimensioni?
Perché solo separando le due variabili di dimensione e durata possiamo garantire massima flessibilità al nostro piano di rilascio… e il Product Owner ed il Team saranno messi nelle condizioni migliori per valutare come procedere al termine di ogni sprint.