Gli antipattern nella Product Ownership

Cos’è un antipattern?

“Gli antipattern sono soluzioni comuni a problemi comuni in cui la soluzione è inefficace e può comportare conseguenze indesiderate. Un antipattern è diverso da una cattiva pratica quando:

• Si tratta di una pratica comune che inizialmente sembra una soluzione appropriata, finendo per avere conseguenze negative che superano qualsiasi beneficio
• C’è un’altra soluzione che è nota, ripetibile ed efficace”. 

(Agile Alliance)

Gli antipattern del Product Owner

Quando parliamo di Product Ownership, possiamo identificare due principali versioni di antipattern:

Product Ownership condivisa

Indica la situazione in cui non vi è un unico PO, ma un insieme di persone che complessivamente rivestono il suo ruolo. Dunque, non è presente un’unica guida decisa sulla visione e sulla strategia di prodotto; al contrario, prima di prendere una decisione, tutte le persone devono confrontarsi, discutere e allinearsi tra di loro.

Questo meccanismo comporta un rallentamento nel processo di decision making, inoltre tutte le decisioni devono essere negoziate e ciò vuol dire che una volta si propende per una alternativa, mentre la volta successiva la prospettiva considerata sarà un’altra a rischio di perdere un unico filo conduttore nella crescita del prodotto.

Nelle dinamiche di team, tale rallentamento ha effetti negativi, in quanto il gruppo è costretto a rimanere in attesa di risposte finché i diversi Product Owner non saranno allineati sulle priorità. Ciò potrebbe indurre il team a: evitare domande e coinvolgere il committee di Product Owner solo quando strettamente necessario, per limitare la nascita di ulteriori discussioni.

Queste dinamiche a lungo andare disincentivano la collaborazione tra Product Ownership e team.

Product Ownership divisa

Mentre nel primo caso la Product Ownership era condivisa allo stesso livello da un gruppo di persone, in questo caso è presente un unico PO che, però, non ha l’autorità per rispondere alle responsabilità del suo ruolo. Piuttosto, può essere definito come uno “scriba”: scrive le user stories e si occupa di interagire con il team partecipando agli eventi. Ma è privato della responsabilità di decidere su ciò che realmente impatta sul futuro del prodotto.

Invece, è un’altra figura, in genere un Product Manager, a occuparsi della visione di prodotto, della strategia di product marketing e di rimanere in contatto col mercato e con i clienti.

Questa dinamica può manifestarsi come soluzione a varie situazioni, per esempio quando il Product Owner è sovraccarico di lavoro o quando è distante dal team. In entrambi i casi, essa nasce dalla necessità del PO di avere una persona accanto che faccia da tramite con il team.

Vediamo i due casi nello specifico.

• Product Owner sovraccarico

Le cause del suo sovraccarico possono essere diverse:

• • l’assenza di tempo per i tanti altri progetti da seguire (non svolge solo il ruolo di Product Owner, ma segue anche altre attività)
  • è Product Owner di più team o di più prodotti (dunque, non è sempre disponibile)
  • il team non gli dà il giusto supporto (Scrum Master e team non lo supportano nella scrittura delle storie e nel preparare il Product Backlog Refinement).

A prescindere dalle varie motivazioni, un Product Owner sovraccarico porta a diverse conseguenze negative.

In primo luogo, egli diviene un collo di bottiglia nel prendere decisioni. Dunque, il team si ritrova spesso a dover aspettare per ricevere una risposta alle sue domande; in alternativa, deve evitare di chiedere e decidere per conto proprio (rischiando di trovare soluzioni non adatte per il business o per il cliente).

In secondo luogo, se non riesce a partecipare al Product Backlog Refinement, alla Review o al Planning il team deve continuamente cercarlo per sapere le priorità aggiornate.

Ancora, può capitare spesso che il Product Owner sia in ritardo, costringendo il team ad interrompersi per aggiornarlo su quanto fatto fino a quel momento durante il meeting.

Infine, spesso non prende parte alla retrospettiva con il team. Così, se anche il gruppo volesse affrontare il problema, egli non è presente per poter decidere come risolvere la questione.

• Product Owner distante

In questo caso, Product Owner e team si trovano in due contesti divergenti: in due uffici geograficamente separati o in due funzioni organizzative diverse. Oppure, in due time zone differenti con sole poche ore lavorative in comune ogni giorno.

La comunicazione, dunque, è difficile, vi sono rallentamenti nella presa di decisioni e sono pochi i momenti disponibili per condividere idee e informazioni. In una tale circostanza, qualsiasi domanda il team porga al Product Owner, probabilmente dovrà aspettare anche giorni per ricevere una sua risposta. Avere uno o più membri del team bloccati significa che inizieranno a lavorare su altre attività, aumentando il Work In Progress del team e di conseguenza molto probabilmente il lead time.

Ma può verificarsi anche un’altra situazione in cui un Product Owner è “distante”: quando lui e il team fanno parte di dipartimenti diversi (in una struttura a silos) che spesso si attribuiscono vicendevolmente le colpe dei fallimenti. Di conseguenza, anche team e Product Owner saranno portati (spinti dalla cultura aziendale) a non cooperare in caso di situazioni problematiche, ma piuttosto a cercare di attribuire le colpe all’altro con l’unico obiettivo di scaricare le responsabilità.
In questo caso si tratta di una distanza fittizia, che può, però, creare ancora più problemi di una distanza fisica reale.

Quali che siano le ragioni, come nel caso della Product Ownership condivisa, anche in quella divisa tale soluzione disincentiva la collaborazione tra team e Product Owner, portando addirittura ad una perdita di autorevolezza della Product Ownership di fronte al team.

Qualche consiglio

Ma come si possono risolvere tali dinamiche?

Il primo passo è sempre rendere evidenti le dinamiche disfunzionali e cominciare ad evidenziare gli effetti che ne derivano.

Nel caso di un Product Owner sovraccarico, per una soluzione nel lungo periodo, è consigliabile alleggerirlo da attività e/o progetti che non sono correlati al prodotto, al fine di permettergli di avere il giusto focus sull’evoluzione del prodotto. A tal fine, si potrebbero delegare o selezionare altre persone che possano prendere in carico le attività extra.

Nel breve periodo, invece, sarebbe opportuno rendere evidente il problema, cioè rendere trasparente cosa il Product Owner ha il tempo di fare e cosa no e prendere degli accordi di team per supportare le sue attività. Eventualmente, il team potrebbe pensare anche di accordarsi su come ricevere le informazioni necessarie in asincrono, senza rischiare di rimanere bloccati dall’assenza del Product Owner durante determinati meeting.

Conclusioni

Per risolvere questi antipattern è necessario dare ad un’unica persona l’autorità di decidere sull’evoluzione del prodotto e sulla strategia necessaria.
Il Product Owner è uno ed uno solo: è il responsabile del prodotto (e quindi delle decisioni a riguardo), idealmente controlla il budget, e può influenzare notevolmente la creazione di un ambiente di collaborazione aziendale (certamente, ciò dipende anche dalla cultura aziendale).

Il Product Owner, ovviamente, considera le opinioni di tutti gli stakeholder coinvolti e raccoglie le informazioni da tante persone e funzioni intorno a lui, ma è lui il responsabile della decisione finale. Egli deve poter avere il tempo di focalizzarsi sul prodotto e di consentire al team di avere le risposte necessarie per permettergli di lavorare in un flusso continuo.

Ovviamente è fondamentale anche il supporto del team nelle attività operative. Ogni team può trovare il giusto equilibrio definendo degli accordi chiari che lo aiutino ad evitare aree grigie in cui non si sa a chi tocchi una specifica attività e a definire le modalità di collaborazione che meglio gli consentono di lavorare verso un obiettivo comune.