Introduzione

Nelle puntate precedenti abbiamo visto alcuni tipici comportamenti che possono rallentare — se non addirittura impedire — il processo di trasformazione agile di un’organizzazione. In quel caso il focus era sul management o più genericamente sulla modalità di conduzione dell’organizzazione stessa. Questo mese concentreremo invece l’attenzione sulla figura del Product Owner e vedremo quali possono essere i comportamenti dannosi per l’implementazione dell’agilità.

Antipattern per il PO

Il PO è un ruolo fondamentale all’interno della metodologia Scrum. Il suo compito è quello di impostare la rotta del lavoro tramite la compilazione del backlog e la sua prioritizzazione: cosa sta dentro il backlog, cosa rimane fuori e l’ordine degli elementi caratterizzano la strategia e la natura del prodotto da realizzare.

Un’errata interpretazione del ruolo del PO può avere ripercussioni anche gravi non solo sul processo di sviluppo del prodotto ma anche sulla capillare adozione della filosofia agile all’interno dell’organizzazione.

Attivare questo ruolo in una organizzazione è tutt’altro che banale: spesso capita che il ruolo del PO sia semplicemente assegnato a qualcuno che prima svolgeva un compito “simile”; e questo, purtroppo, accade a volte senza che si sia compreso a fondo che non si tratta di un semplice cambio di tecniche o strumenti di lavoro. Devono essere compresi il differente approccio, la filosofia di base, i principi dell’agilità.

Troppo spesso si incontrano figure di Product Owner che non sono altro che ex Project Manager “travestiti” da agilisti, con ancora un forte approccio dispositivo, gerarchico, orientato al comando e controllo.

I risultati scarsi, in questo caso, sono imputati a ipotetiche carenze dello strumento scelto e alla inadeguatezza della suddetta filosofia, quando in realtà si tratta di una mancanza di comprensione del significato del ruolo.

Ritenendo quindi di fondamentale importanza la giusta dimensione di questo ruolo, abbiamo provato a elencare alcuni comportamenti che possono portare a interpretarlo nel modo sbagliato.

Product Owner assente, sovraccarico, distante

Quando il PO è poco presente alla vita del team non riesce a contribuire in modo efficace alla definizione del cosa e del perché. I motivi possono essere molti, anche se spesso la causa è una reale mancanza di tempo per svolgere “anche” questo lavoro: magari ha ricevuto questo ruolo senza un incarico ufficiale che gli conceda il giusto tempo necessario per parlare con gli stakeholder e riportare le informazioni al team di sviluppo.

A volte egli riceve questo nuovo incarico che deve svolgere “insieme” al suo vecchio lavoro, cosa che porta all’errata convinzione che fare il PO sia un lavoro faticoso. Altre volte invece egli finisce per ricevere questo compito ma non può svolgerlo fianco a fianco con il team, sia per distanza geografica — e si finisce immancabilmente per comunicare tramite qualche video call — sia per distanza di visione e di intenti.

La mancanza di una collaborazione fianco a fianco aumenta i rischi di fare la cosa sbagliata: il team di sviluppo non riesce a chiarire tutti i dubbi sul contenuto del backlog e a innescare quindi un efficace ciclo di feedback; non si può quindi lavorare d’anticipo sulla riorganizzazione del backlog e raffinarlo preventivamente per migliorare la creazione del prodotto sulla base delle informazioni “dal campo”. Non potendo anticipare le modifiche, aumentano le rilavorazioni “dopo” che il prodotto è uscito in test.

Purtroppo queso porta a volte a un clima di sfiducia che compromette ulteriormente il lavoro: il PO non si fida delle scelte e delle valutazioni fatte dal Dev Team (stime, scelte tecniche, strategie per completare il lavoro); il Dev Team perde di stima e autonomia — “il capo/PO non crede che per fare questa cosa ci voglia questo tempo” — e viceversa non crede nella necessità di implementare alcune funzionalità o nelle urgenze per riordinare il backlog.

Separazione fra PO e team di sviluppo

Sebbene si dica spesso che il PO debba essere espressione del business — nel senso che deve conoscere il prodotto, deve conoscere le necessità del business e probabilmente aver “vissuto” in quel settore — a volte un PO troppo legato alle dinamiche politiche-organizzative del business può mostrarsi lontano dalle logiche di sviluppo del prodotto.

Finisce quindi che sia solo uno a proporre e sobbarcarsi il peso di fare esperimenti per il miglioramento: per esempio chi dovrebbe decidere se studiare o fare una prova per una nuova tecnologia o un nuovo modello di sviluppo che potrebbero portare miglioramenti al progetto? E se il progetto inizialmente, durante l’esperimento o durante le prime iterazioni, va piano, chi decide se è il caso di proseguire?

Non è raro assistere ad affermazioni da parte del PO del tipo: “OK ragazzi, comprendo che, se ci fermassimo per migliorare la piattaforma di rilascio automatico, tutta l’azienda ne trarrebbe beneficio, ma ora non possiamo fermarci. Il mio capo mi chiede di chiudere in fretta questo progetto. Facciamolo (= fatelo) con il prossimo progetto (e magari un altro PO)”, che tradotto significa “Facciamo in fretta a finire, che io sono valutato sul chiudere in tempo questo progetto il prossimo mese, non mi interessa la difettosità o quanto gli utenti si lamenteranno il prossimo semestre”.

Le separazioni sono sempre fonte di peggioramento: di fatto sarebbe ottimo che tutte le aree fossero unite e collaborassero. Paradossalmente a volte avere un PO lato business con un forte interesse verso il suo ramo gerarchico è peggio che avere un PO che sia alleato e vicino al Dev Team anche se meno partecipe delle dinamiche di business.

Frazionamento del Product Owner: il “comitato” di PO

Il PO dovrebbe essere in grado di indicare la rotta: cosa fare e perché, in che ordine farlo, ossia quale valore hanno gli elementi del backlog. E, nel comunicarlo, deve farlo in modo chiaro, univoco, deciso e senza indecisioni.

Spesso questo non accade; e, anzi, si dice spesso che un PO che sia in possesso di tutte le risposte alle domande del team è espressione (forse) di un basso coefficiente di innovazione: state facendo un prodotto già visto altrove oppure non utile…

Quando si crea un prodotto nuovo che risolva i bisogni di business dell’utente, è normale che molte cose non siano note o che si debba dedicare del tempo a indagare. Quindi, paradossalmente, se il PO cambia idea spesso o riformula le proprie proposte, potrebbe essere indice di un contesto di forte innovazione, frequenti feedback dall’utente e quindi un prodotto migliore.

Se invece queste incertezze non sono dovute a un processo sperimentale e di innovazione ma al fatto che il PO non è uno solo ma un gruppo di persone, un comitato, o peggio ancora un intermediario di qualcuno che opera altrove senza mai parlare col team…  be’ allora questo non va affatto bene.

Incertezze dovute al passaparola con relativa perdita di chiarezza, ripensamenti, interpretazioni, notizie concorrenti per cui al team arrivano le indicazioni di più persone: questo è certamente uno scenario sub performante che dovrebbe essere risolto quanto prima.

Conclusione

Nell’ambito di un processo di adozione di Scrum, il PO è una figura fondamentale. È un ruolo che tocca molti ambiti, dalla definizione del prodotto alla roadmap di sviluppo e rilascio. Deve conoscere aspetti di project management, marketing, finanziari, di strategia di business; deve inoltre essere a conoscenza del piano strategico aziendale.

Spesso un PO è una figura che prima seguiva i progetti da una prospettiva differente: magari è un ex Project Manager che prima si limitava a gestire tempi e persone e guidare gli analisti). Dal nostro punto di vista, passare da fare il PM al PO è certamente un percorso stimolante e interessante, certamente da considerarsi una crescita.

Non si devono sottovalutare gli impatti e le implicazioni di questo mestiere. Spesso è una figura importante per facilitare il cambiamento all’interno dell’organizzazione. Avere bravi PO in azienda è certamente un fattore che abilita e semplifica la trasformazione.

Gli errori che abbiamo qui elencato — anche se personalmente non amo chiamarli “errori”, ma al limite situazioni sub-ottimali — fanno parte di un normale processo di trasformazione. Non vedeteli come errori irrecuperabili, ma come momenti di passaggio, verso qualcosa di migliore e di più performante.

Se riuscirete a vedere il costo di un determinato comportamento e proverete a fare qualcosa per cambiare, allora avrete fatto un buon lavoro. In fondo, Agile significa miglioramento continuo, non significa evitare gli errori e uscire subito con la soluzione perfetta, che per definizione non esiste.