Il Product Owner in un’immagine

Girovagando in rete ho trovato uno schema che riassume a colpo d’occhio il ruolo del PO, per riprendere un argomento che mi sta a cuore…

scrum-product-owner-role

Ha il pregio di sintetizzare le responsabilità del Product Owner all’interno dello Scrum Team.
Ripercorriamo gli eventi e gli artefatti Scrum con un focus su questa figura.

Con chi interagisce in PO

Il Product Owner è un focal point per tutti gli stakeholder di progetto.
E’ fondamentale che le richieste di clienti esterni ed interni all’azienda (ad esempio il management, i Product Manager, i Software Architect, ecc.) siano indirizzate al PO che funziona da collettore unico di richieste verso il team Scrum.

Responsabilità del Product Owner

Questo argomento richiederebbe un post dedicato data la vastità dell’argomento…
Lo schema descrive le principali responsabilità operative del PO:

Non approfondisce invece le attività di tipo più strategico quali – ad esempio – l’analisi dei bisogni degli utenti, lo studio degli scenari di mercato, la definizione della vision di prodotto, ecc.

Release planning

In questa fase il compito fondamentale del Product Owner è definire gli obiettivi della release e spiegare le principali funzionalità da rilasciare.
Un aspetto interessante – e spesso sottovalutato – presente nello schema è l’analisi dei rischi che deve essere compiuta dal PO e dal team in questa fase, attività che può migliorare sensibilmente la pianificazione.

Sprint Planning

In fase di Sprint planning il Product Owner descrive al team cosa deve essere fatto seguendo le priorità elencate nel backlog. Definisce l’obiettivo dello sprint e ripercorre le singole user stories con l’intento di rendere chiaro il tipo di utente che ne trae vantaggio, la funzionalità richiesta ed il beneficio atteso.

Daily Scrum

E’ opportuno che il Product Owner  sia presente al Daily Scrum, ma è il team ad essere protagonista di questo momento. Organizza la propria giornata e fa il punto sullo stato dell’arte.
Per questo motivo è utile che il PO ci sia (se non sempre spesso), che ascolti gli aggiornamenti e le esigenze del team senza far pesare la propria presenza.
E’ tendenzialmente un osservatore silenzioso nel Daily Scrum.

Sprint

Durante l’iterazione il Product Owner tiene d’occhio l’andamento dei lavori, verifica in corso d’opera quanto il team sta realizzando ed è disponibile per chiarimenti ed approfondimenti.

Sprint Review

Al termine dell’iterazione il Product Owner ha il compito principale di accettare o rifiutare quanto sviluppato dal team. Solo lui può decidere cosa considerare realmente “done”.
Nel corso della demo presenta agli stakeholder l’obiettivo dello sprint e contestualizza quanto realizzato all’interno della più ampia pianificazione di release.

Retrospective

Questo evento è presidiato dallo Scrum Master con l’obiettivo del miglioramento continuo. Mediante l’analisi di cosa ha funzionato e cosa non ha funzionato nel corso dello sprint vengono individuate una o più azioni per ottimizzare il processo.
Il Product Owner partecipa attivamente alla retrospective insieme a tutti gli altri membri del team Scrum, portando le proprie osservazioni e proposte.

Al termine della release

Così come per i singoli sprint il PO accetta o rifiuta le storie, al termine della release è colui che tira le fila dell’intero progetto, verifica i deliverable, decide il go/no-go finale e lo comunica a tutti gli stakeholder.

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.

4 livelli per requisiti agili

Recentemente ho avuto occasione di seguire un workshop di Sally Elatta dal titolo “4 levels of Agile Requirements”.
L’idea centrale della relatrice – fondatrice di Agile Transformation e Agile coach – è che sia fondamentale approcciare i requisiti agili secondo diversi gradi di astrazione.

Questo modus operandi non è una novità.
Abbiamo già parlato di come l’introduzione di una gerarchia nel Product Backlog possa essere d’aiuto sia per il team sia nei rapporti con gli stakeholder di progetto.

Sally Elatta ripropone questa idea sottolineando l’importanza di avere punti di vista sul progetto che vanno dal generale al particolare, ovvero:
epiche
funzionalità
user stories
– singole attività (task)

Considerare i requisiti secondo questi 4 livelli di astrazione consente di legare le singole attività implementative con la “big picture” del progetto e dare così valore alle scelte che dovremo effettuare nel corso dello sviluppo.

Livelli di progetto

La continuità tra i vari livelli è ben rappresentata nell’immagine.
In relazione al Backlog ci interessa concentrare l’attenzione sui 3 livelli centrali.

USER STORIES

Le user story rappresentano il secondo livello dal basso, quello in cui propriamente avviene l’azione o interazione.
Descrivono brevemente ciò che il sistema può fare per risolvere un problema specifico di un utente ben definito.
La caratteristica principale delle storie è essere focalizzate sul valore che producono per il soggetto, a differenza dei singoli task che sono invece una segmentazione delle attività ai fini della lavorazione da parte del team.

 

FUNZIONALITA’

Ad un livello superiore di astrazione rispetto alle user stories troviamo le funzionalità (features), che costituiscono una descrizione più tradizionale del comportamento del sistema.
Sono il livello intermedio tra i bisogni dell’utente e la soluzione progettuale complessiva.
Il concetto di funzionalità ha dal mio punto di vista un enorme pregio: collega le singole attività portate avanti dal Team Scrum con una terminologia utilizzata abitualmente da figure professionali quali Program Manager, Product Manager e manager in generale.
Mediante un elenco di funzionalità siamo in grado di descrivere il nostro progetto con un discreto grado di approfondimento e di spiegarlo anche ad interlocutori non avvezzi alle metodologie agili.

In alcune realtà aziendali di dimensioni medio-grandi anche i team di sviluppatori potrebbero essere organizzati intorno a queste feature.

 

EPICHE

Infine le epiche rappresentano il livello più alto di espressione del bisogno di un utente.
Sono i pilastri della big picture, le caratteristiche costituenti.

Le epiche sono i primi elementi che emergono dal concept di progetto. Si tratta di storie di grandi o grandissime dimensioni che
permettono di comunicare il perimetro di progetto in poche battute ma non consentono di effettuare una stima iniziale dato l’elevato livello di astrazione.

Il collegamento tra questi 3 livelli – storie, funzionalità ed epiche – ci consente di avere maggiore controllo sullo stato di avanzamento del progetto ed offre una chiave di lettura di immediata comprensione agli interlocutori.

Per questo motivo può essere molto utile verificare la consistenza del backlog salendo e scendendo attraverso questi 3 livelli.

Facciamo qualche esempio di “prova del 9“:

  • Possiamo ricondurre tutte le user stories ad un’epica corrispondente?
    Se non è così probabilmente potremmo avere “lavoro sommerso” e sprint goal poco definiti.
  • Ci sono epiche a cui sono collegate pochissime user stories?Verifichiamo di aver compreso bene le aspettative degli stakeholder. Potremmo aver perso qualcosa per strada o non aver spacchettato correttamente il lavoro.
  • Siamo in grado di tradurre il backlog della release in una lista di funzionalità? Possiamo sintetizzare con una percentuale di avanzamento a che punto sono queste feature ?

Potreste accorgervi – come nel mio caso – che non state utilizzando coerentemente o con continuità tutti e 3 i livelli.
Non resta che ispezionare e adattare il backlog, in perfetto spirito agile…