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:

gestione e aggiornamento continuo del backlog

prioritizzazione delle user stories

chiarimento dei requisiti

accettazione o rifiuto dell’incremento di prodotto sulla base dei criteri condivisi.

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 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.

“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.

Mese: Marzo 2015

Il Product Owner in un’immagine