Istantanee dal POCamp 2016

Si è svolta nel secondo finesettimana di settembre l’edizione 2016 del POCamp, la “non conferenza” dedicata al tema della Product Ownership e al “mestiere” di Product Owner. Si è trattato di un incontro con un buon numero di partecipanti, che ha fatto emergere interessanti riflessioni.

Impressioni di settembre

Anche quest’anno abbiamo partecipato al POCamp, svoltosi dal 9 all’11 settembre al Resort Poggio all’Agnello, nei pressi di Baratti in provincia di Livorno.

location

Come sempre accade quando si prende parte a queste manifestazioni, volerne fare un resoconto “obiettivo” è piuttosto difficile e si finisce, peraltro giustamente, per riportare una serie di impressioni legate più che altro a ciò a cui si è assistito o che ci ha coinvolto in prima persona.

Al di là di questo, però, un’idea generale ce la siamo fatta, anche grazie allo spirito di collaborazione e allo scambio di idee favorito dall’ambientazione piuttosto rilassata della tre giorni — alcune discussioni sono avvenute direttamente in piscina — nonché per merito del format della unconference su cui si basa il POCamp.

Unconference

Il programma si è andato configurando con lo svolgimento di 4 sessioni parallele.

Programma giornata

Vediamo di esporre queste esperienze in una rapida carrellata.

 

La Product Ownership esce allo scoperto

Per anni, il ruolo del Product Owner e i suoi compiti hanno avuto contorni un po’ sfocati. Pur riconoscendo la centralità della Product Ownership in ogni progetto gestito con approccio Lean/Agile, è stata necessaria una certa dose di riflessione per mettere a fuoco comportamenti, responsabilità, aree di intervento dei PO. Il POCamp è nato proprio con questo scopo, vale a dire per far emergere da una dimensione “esoterica” il PO e collocarlo più precisamente accanto alle altre figure coinvolte nei progetti.

Anche grazie a una partecipazione nutrita, Il POCamp 2016 ha segnato in tal senso un punto fermo per la presa di consapevolezza da parte dei Product Owner e delle altre figure coinvolte. A dimostrazione di questo, ci sono alcuni fatti: tra i presenti, c’erano diverse “facce nuove”, ossia professionisti che non sono tra i frequentatori soliti delle numerose conferenze a tema Agile che si tengono durante l’anno; poi circa una metà dei partecipanti si è presentata esplicitamente come Product Owner e non come altri ruoli/figure; infine, una sessione intera è stata dedicata al racconto della giornata tipo del Product Owner.

In particolare, da quest’ultima attività si è visto come, a fronte di comportamenti comuni, esistano ormai già anche degli approcci diversi al modo in cui si svolgono certe funzioni del PO. Per esempio, per quanto riguarda il raffinamento del backlog, la discussione ha fatto emergere che c’è chi lo effettua su base quotidiana, chi lo fa a scadenze fisse ma non tutti i giorni, e chi infine preferisce operare sul backlog on demand. La conversazione intorno a questi temi si è svolta in maniera molto franca e veritiera, senza alcun atteggiamento “inquisitorio”: a prevalere era un desiderio di condivisione dell’esperienza e non certo un giudizio di merito.

 

Product Owner e business

Un tema che è stato toccato a più riprese, in maniera differenziata, è stato quello del rapporto tra Product Owner e ramo business dell’azienda. In che modo i due “mondi” interagiscono e si influenzano?

PO e business

Come in altre situazioni, si è parlato molto concretamente sulla base di esperienze dirette: si sono raccontate situazioni dalle quali poi sono nate riflessioni e idee. Per esempio, partendo dal caso di una app sviluppata per un servizio ferroviario regionale, sono emerse alcune considerazioni.

La prima — che dovrebbe essere data per scontata, ma che è sempre bene esplicitare — è che il PO, per la sua natura di figura a cavallo di più realtà, è quello cui compete trovare l’equilibrio, non sempre facile, tra le esigenze dell’utente finale del prodotto e le aspettative del business che investe affinché il prodotto sia effettivamente realizzato. Altra area di competenza del PO è quella di trovare un equilibrio tra obiettivi prefissi e scadenze obbligate: ad esempio, se c’è una data di pubblicazione del prodotto, al PO tocca il difficile compito di stabilire che cosa resterà fuori.

PO e Business

Ma una delle riflessioni emerse, meno scontata, è stata quella che vede per il PO il compito di inviduare il vero business del prodotto che si va a “fabbricare”: non sempre infatti, i vari settori dell’azienda sembrano averlo presente; essi infatti perseguono degli obiettivi di business che, per quanto leciti e comprensibili per quel settore, possono risultare decisamente parziali rispetto a un business globale. In tutto questo, una pratica assolutamente fondamentale, che ogni buon PO dovrebbe seguire, consiste nel mostrare costantemente quello che si sta facendo, in modo che la soluzione sia sempre chiara e sotto gli occhi di tutti.

Sempre rimanendo in “area business”, è stato interessante il tentativo di trovare insieme degli strumenti alternativi al classico business plan. C’è un modo per ottenere gli stessi risultati senza realizzare un documento che prende tanto tempo ed energie per essere realizzato? Anche se i risultati ottenuti sono stati solo preliminari, visto il tempo limitato a disposizione, questo argomento merita senza dubbio un approfondimento perché un flusso migliore nella realizzazione dei prodotti si ottiene anche con questo tipo di piccole rivoluzioni che vanno a migliorare o a sostituire strumenti “insostituibili”.

Business Plan

Infine, anche se non strettamente legato all’aspetto business, citiamo qui il fatto che si è discusso di come migliorare il rank di una app all’interno di uno store digitale: magari non sarà proprio un tema Agile, ma è sicuramente indice del fatto che il formato della “non conferenza” aiuta i partecipanti a parlare di argomenti che li interessano da vicino.

 

Product Owner e Operations

Altro tema interessante che è emerso è quello del rapporto tra Product Owner e mondo Ops. Con l’affermazione di DevOps e il suo definitivo inglobamento nel flusso produttivo, emerge sempre più chiaro un possibile problema: il Product Owner è in genere una figura legata al mondo del software e dello sviluppo, ma che magari sa ben poco degli aspetti connessi al ramo Operations.

In un’ottica “olistica” il cui il prodotto è uno, dall’idea allo sviluppo alla messa in opera, per un Product Owner diventa importante avere una certa conoscenza non solo del ramo Dev ma anche degli aspetti legati alle Ops. Chiaramente non dovrà essere un tecnico esperto, ma certi concetti e certe conoscenze legate allo hardware, al firmware, agli strumenti di deploy, e così via, devono entrare a far parte del bagaglio di competenze di un PO. Una ulteriore frontiera per l’evoluzione di questa figura nei prossimi anni.

 

Product Owner e scaling

“Scalare” è ormai diventata una parola d’ordine del mondo Agile. Al POCamp è stato quindi naturale di come la figura del PO si inserisca e si muova nell’ambito dello scaling. In particolare, ci sono stati due interventi che hanno affrontato due diversi framework metodologici creati per gestire lo scaling agile: LeSS e SAFe.

PO e scaling

Ma il discorso non è rimasto confinato alle sessioni “specifiche”, visto che è tornato fuori in altre occasioni, a dimostrazione del fatto che “scalare” non è solo una parola, ma rappresenta una esigenza reale che va affrontata: possono cambiare le modalità con cui la si affronta e la si risolve — e in questo senso il confronto fra approcci e framework metodologici diversi è aperto — ma di certo “scalare” resta una costante da conoscere e gestire.

PO e scaling

 

Per concludere…

Nonostante la stanchezza delle ultime ore, avvertibile in molti dei partecipanti, ne è valsa la pena, e non solo per la piscina… Un POCamp, quello appena vissuto, che ha rappresentato un momento di crescita, non solo in termini numerici, quanto in termini di consapevolezza e di progettualità, per una figura chiave e in evoluzione.