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…

Applicare la gerarchia al product backlog

Seguiamo o non seguiamo un processo iterativo nello sviluppo?
Se la risposta è sì controlliamo attentamente il nostro Backlog.
Non può contenere una miriade di user stories…

Un numero eccessivo di storie sono una trappola infernale perché il loro reale significato tende a stemperarsi. Apparentemente stiamo iterando, ma in realtà finiamo per seguire un piano stabilito mesi prima con le conseguenze nefaste del caso:

  • molto tempo impiegato nel dettagliare item che possono rivelarsi non necessari
  • rischio di buttar via lavoro già fatto se emergono nuove opportunità di mercato
  • rischio di nascondere nella massa di dettagli lo scope creep (o derive dell’ambito)

Se il processo è realmente iterativo non ha senso arrivare subito a questo livello di dettaglio o definire l’intero ambito con mesi di anticipo. Dobbiamo lasciarci un margine di flessibilità.
Teniamo anche presente che user stories di piccole dimensioni sono perfette nel momento in cui vanno in mano al team ma solitamente non offrono al management il giusto punto di vista in relazione ai macro-obiettivi di business.

Da qui l’idea di applicare livelli gerarchici nel product backlog che corrispondono a differenti livelli di astrazione.
Gojco Adzic – l’autore di “50 idee veloci per migliorare le vostre user stories” – propone di sperimentarne 4:

  1. i macro obiettivi di business (la cosidetta “big picture”)
  2. i singoli obiettivi di business che contribuiscono alla big picture (i cambiamenti che vogliamo indurre nel comportamento dei nostri utenti)
  3. i deliverable software che possono supportare il cambiamento
  4. deliverable più piccoli che possono essere rilasciati indipendentemente l’uno dall’altro (solo qui siamo al livello atomico delle user stories!)

Quali sono i vantaggi di questo approccio?
Sostanzialmente due: il team può realizzare uno sviluppo realmente iterativo perché lavora su item indipendenti e può reagire tempestivamente alle opportunità di mercato. Allo stesso tempo è possibile monitorare l’avanzamento in relazione agli impatti di business (l’unica prospettiva realmente rilevante per il management).

In sintesi l’esperimento che propone Adzic è di ridurre il numero di item nel product backlog e mantenere una connessione visibile con la “big picture così da poter monitorare, discutere e ricondurre in ogni momento le singole user stories ai macro-obiettivi di business.

Questo suggerimento arriva con un tempismo perfetto.
In questo momento sto proprio cercando di spostare la prospettiva del team e degli stakeholders dalla “lista dei progetti che dobbiamo fare” agli obiettivi di business che vogliamo raggiungere.
Il Backlog rivisitato in un’ottica gerarchica e multilivello potrebbe essere la risposta (c’è chi parla di 4 livelli per i requisiti). In ogni caso è un esperimento che intendo provare…

Liberamente tratto da “50 idee veloci per migliorare le vostre user stories”, ebook in progress che contiene spunti assai interessanti…

L’importanza di fare Sprint Demo

Perché fare demo del lavoro svolto nello sprint?
Si possono saltare? Meglio di no.
E’ importante tenerle con continuità per più motivi.

Descriviamo una situazione tipica…
Il vostro team fa Scrum, comincia ad avere una discreta conoscenza della metodologia ed è abbastanza rigoroso nell’esecuzione delle cerimonie.

Quindi si fa il planning, le review e le retrospective, ma – chissà perché – c’è una certa ritrosia nel fare demo aperte a tutti.
E magari vi ritrovate al penultimo giorno dell’iterazione con qualcuno che chiede: “ma dobbiamo proprio farla la demo?”.
Sì, assolutamente sì!
Non a caso la Sprint Review si chiama anche Sprint Demo…

Non è una questione di controllo (“vediamo cosa avete fatto in tutto questo tempo!”), di principio (“dobbiamo farla perché in Scrum si fa”) o di forma (“facciamo la demo così lo Scrum Master è contento”)…
Dal mio punto di vista è proprio un tema di sostanza.
Perché una review con una vera e propria demo estesa a tutti i potenziali interessati è, rispetto ad altre cerimonie, la migliore occasione che il team ha per interagire realmente con gli stakeholder e con tutti coloro che hanno una visione parziale del progetto.

Durante la demo viene illustrato l’incremento di prodotto realizzato nel corso dello sprint.
La finalità non è dimostrare agli altri quanto è stato bravo il team o esporlo al pubblico biasimo se non ha portato a termine tutto quello che era stato programmato.
Oltre all’accettazione formale delle storie da parte del Produt Owner, ci confrontiamo con il resto dell’azienda per ottenere dei feedback e far emergere aspettative che sino a quel momento non hanno avuto voce.

La finalità della demo è triplice: verificare cosa va bene, capire cosa eventualmente non va bene e capitalizzare idee.
Non accoglieremo necessariamente tutto quanto emerge dalla platea, ma avremo raccolto un piccolo patrimonio di osservazioni che potranno rivelarsi preziose nel seguito del progetto.
In alcuni casi la demo consente di portare alla luce effetti collaterali che non avevamo preso in considerazione o di cui non avevamo valutato a pieno la portata.

Mi è capitato proprio di recente.
Il team porta a termine un’iterazione e completa una user story con un elevato valore di business nell’arco delle canoniche due settimane.
Il manangement è interessato a rilasciare la funzionalità il prima possibile.
Nel corso della demo emerge che gli sviluppatori hanno trovato una soluzione semplice ed efficace per l’implementazione, ma questa scelta produce conseguenze inattese sulle altre properties. Qualcosa si è perso nella comunicazione tra il Product Owner ed il team. Nulla di grave. Può succedere e c’è sempre un modo per porvi rimedio.
Si decide di rimandare il rilascio di un’iterazione, il tempo utile per realizzare un piccolo incremento di prodotto e garantire la massima flessibilità a tutti gli altri gruppi di sviluppo.

Senza la demo questo problema non sarebbe emerso.
Avremmo rischiato di scoprirne le conseguenze solo in produzione. Avere tutti gli interlocutori seduti al medesimo tavolo ci ha consentito di intercettare per tempo la criticità e trovare la risposta più adeguata.

Inspect and adapt in ogni fase.

La comunicazione, la trasparenza e l’esporre il lavoro svolto sono passi fondamentali quando si intende perseguire un miglioramento continuo.