Categoria: Agile

Quando un Product Owner può definirsi veramente tale?

Pichler sostiene ci sia un test semplicissimo per capire se una persona sta ricoprendo davvero il ruolo di Product Owner.
Basta porre la fatidica domanda “Hai il diritto di dire no?”

Quando dire NO
Ci troviamo a dire no in tante diverse situazioni.
Non si tratta di un’attitudine negativa nei confronti del mondo o del lavoro da fare. 
Ci sono occasioni in cui i no fanno la differenza tra il successo ed il fallimento di un progetto.

Diciamo no quando una richiesta non è allineata con gli obiettivi che stiamo perseguendo, diciamo no quando un desiderata non porta reale beneficio all’utente o quando il valore di una richiesta non è in alcun modo misurabile o testabile.

Diciamo no quando i desiderata vengono dalla pancia ma non sono argomentati né analizzati alla luce di dati reali.

Soprattutto diciamo no quando ciò che ci viene richiesto non è indispensabile per l’esito positivo del progetto. Perché tutti noi combattiamo con risorse scarse (siano esse tempi, costi o persone) ed il nostro primo pensiero è rimanere focalizzati su ciò che è davvero essenziale per la riuscita di un prodotto o un servizio escludendo ciò che è “rumore di fondo”.
Più funzionalità difficilmente sono sinonimo di prodotto migliore, se mai più complesso…

Dire NO è un esercizio difficile
Diciamocelo: il Product Owner non è un mestiere per cuori teneri o per persone alla ricerca di conferme…
Non è mai bello dire di no e “fare la parte del cattivo”, ma se non siamo in grado di farlo perché per indole vogliamo compiacere i nostri interlocutori questo ruolo non fa per noi.

Ovviamente riuscire a dire no nel modo giusto richiede pratica e dedizione. C’è modo e modo di farlo!
Dobbiamo riuscire a far comprendere che l’accettazione o il rifiuto di un desiderata non è mai una questione personale, bensì una scelta ragionata per la soddisfazione dei nostri utenti.
Siamo disponibili ad ascoltare tutte le richieste, ne analizziamo la portata e il contesto però quando si rivelano incoerenti con la strategia o la roadmap gentilmente e con fermezza diciamo no argomentandone le motivazioni.

Quando dire NO è ancora più complicato
Come si suol dire “qui casca l’asino”…
Diciamo che avete raggiunto un buon grado di confidenza nel vestire i panni del Product Owner ed avete instaurato un rapporto di fiducia con il team e lo Scrum Master.
Avete anche gentilmente rimandato al mittente alcune richieste minori provenienti dagli utenti o da colleghi della vostra stessa azienda.
Che succede però quando le richieste arrivano dall’alto?
Siete in grado di dire no anche all’amministratore delegato? Al direttore vendite? In generale a tutti quegli stakeholder che potrebbero influire sulla qualità della vostra vita professionale?

Anche in questo caso se il desiderata è campato in aria, non ha alcuna attinenza con quanto state facendo o pensate possa essere addirittura controproducente dovreste dire no.
Più facile a dirsi che a farsi, lo so.
Ma vi invito quantomeno a non arrendervi a priori. Chiedete, fate domande e argomentate la vostra posizione. Potreste scoprire di non avere elementi validi per ribattere o di non avere tutte le informazioni chiave per prendere una decisione… oppure potreste fare breccia nelle idee del capo grazie ai vostri dati alla mano.
In ogni caso vale la pena tentare e ritentare.

Quando manca la delega
Infine, un punto dolente in molte realtà lavorative (quantomeno – nella mia modestissima esperienza – in quelle italiane).
C’è una situazione peggiore rispetto a quella di non sapere o non potere dire no.
E’ quando il no o il sì del Product Owner contano poco nulla.
Se non c’è sponsorship da parte del management, se le decisioni del PO vengono regolarmente contraddette da persone “più alte in grado”, se non vengono condivise le informazioni utili per decidere, se non si ha insomma “licenza di uccidere” (si fa per dire…), non ci sono le condizioni di contesto che consentono di fare veramente Scrum.

Non c’è niente di peggio di un Product Owner ridotto a fare il portavoce o il segretario. Non serve al team, non serve al cliente finale e – di fatto – neanche a se stesso.
Anche in questo caso è meglio portare alla luce con i propri interlocutori il tema della fiducia e della mancata delega per provare a capire quali azioni correttive possono essere messe in campo.

In sintesi…
E’ importante che il Product Owner abbia la libertà ed il diritto di dire dei no motivati al cliente finale, al cliente interno e al proprio management.
Senza questo potere non è posto nelle condizioni di fare al meglio il suo lavoro e di selezionare con cura ciò che è di maggior valore per gli utenti eliminando tutto ciò che è spreco.