Le parole sono importanti!

Tratto dal film Palombella rossa del 1989, divenne citazione frequente quella del dialogo tra il personaggio di Michele Apicella — alter ego di Nanni Moretti — e la giornalista che gli faceva rileggere l’intervista da lui rilasciata in precedenza. Il personaggio interpretato da Moretti criticava il linguaggio con cui era scritto l’articolo, infarcito di anglicismi e luoghi comuni. “Le parole sono importanti. Chi parla male, pensa male e vive male. Bisogna trovare le parole giuste. Le parole sono importanti” affermava sconsolato un ossessivo Nanni Moretti.

Con tutta la simpatia — e la nostalgia — per quella stagione morettiana, non siamo così ossessionati e non vogliamo certo scrivere alcune note che si basino sostanzialmente solo sulla pedanteria linguistica. Però, una qualche precisazione su una tendenza a cui assistiamo in questi ultimissimi anni la vogliamo fare.

Ma in fondo… è project management, no?

A essere precisi, no. E in questo articolo cerchiamo di capire perché parlare del Product Owner come di un Project Manager agile è scorretto e fuorviante.

Potremmo tagliar corto dicendo semplicemente che:

• in un caso (Product Owner, PO) parliamo di un responsabile di prodotto che deve massimizzare il valore del lavoro svolto da uno Scrum Team [2], nell’altro (Project Manager, PM) di un gestore di progetto che, giorno dopo giorno, gestisce il progetto per conto del Project Board entro specifici vincoli e con adeguate relazioni, lungo tutto il corso del progetto, con il Project Board e la Project Assurance [3];
• Scrum è un’infrastruttura metodologica leggera pensata per aiutare persone, team e organizzazioni a generare valore attraverso soluzioni adattive per problemi complessi; non va considerato come un metodo di Project Management: e infatti non prevede dei Project Manager, ma individua e definisce chiaramente altri ruoli, tra cui il Product Owner.
• le parole sono importanti, come diceva Moretti, nel caso ce lo fossimo dimenticato J

Con questo, si potrebbe chiudere, ma sarebbe ingeneroso, oltre che banale. In realtà, proviamo a chiederci anzitutto perché in molti parlano di un Project Manager agile quando fanno riferimento al Product Owner (PO).

Le ragioni della confusione

Sono diverse le ragioni per cui tale fraintendimento si è diffuso, alcune abbastanza ingiustificate, altre con un’oggettiva base comprensibile, a voler essere onesti intellettualmente e non “fondamentalisti dell’agilità”.

“Pigrizia” nel cambiamento di mentalità

Tra le prime mettiamo sicuramente il fatto che in svariati contesti il passaggio ai principi e alle pratiche Agile è stato recepito più come una “riverniciatura” di certe strutture preesistenti, che come un vero e proprio cambiamento di mentalità e di comportamenti radicale, per quanto progressivo.

C’è quindi spesso la tendenza a voler semplicemente “rimarchiare” certe figure e certe attività, tradizionalmente presenti in azienda, con nomi nuovi e legati al mondo dell’agilità, ma senza che poi cambino le strutture profonde ad esse sosttostanti. Così un Product Owner può venire percepito come un Project Manager in versione agile.

Questo è anche normale, ed è uno scotto che occorre pagare con la diffusione sempre più ampia e pervasiva delle metodologie agili nelle grandi aziende e con l’adozione — o il tentativo di adozione — di una “mentalità” agile in un ambito organizzativo e produttivo spesso lontano da quelli di sviluppo del software nei quali infrastrutture metodologiche come Scrum sono nate e si sono evolute.

Ma anche se si capisce il meccanismo, discorso ben diverso è accettare questa visione.

Coincidenza di competenze

Ben più sensato è l’argomento per cui, prendendo in esame alcune competenze che sia il Product Owner che il Project Manager hanno in comune, e anche alcune attività simili che essi svolgono, si finisce per concludere che, con certe sovrapposizioni, anche le due figure possono essere “confuse”.

E allora, prima di vedere le nette e sicure differenze, vediamo proprio questo aspetto.

Competenze e caratteristiche comuni a PO e PM

Alcune caratteristiche, certe competenze, persino determinati tratti “caratteriali” sono comuni sia a un buon Product Owner che a un Project Manager. Basterebbe citare la capacità di organizzazione, la leadership, la comunicazione efficace.

Capacità di organizzazione

Sia un PO che un PM devono essere persone capaci di autorganizzarsi, sul lavoro e nella vita in generale, ma non tanto grazie a una disciplina “militare”, quanto piuttosto alla capacità di vedere il quadro generale della situazione e comprendere sempre a che punto ci si trova e quali sono le relazioni con gli altri attori dello stesso scenario.

Leadership

Si potrebbe aprire un capitolo infinito sugli stili di leadership [4], e di sicuro esiste qualche differenza sul modo di concepirla tra Project Management di stampo “tradizionale” e ruoli previsti nelle varie pratiche Agile. È indubbio però che la leadership — intesa come capacità di prendere decisioni, di essere di esempio, di aiutare le persone a trovare la loro via e a dare il meglio in quello che fanno, di far crescere la motivazione — debba essere competenza comune sia al PM che al PO. Magari ci saranno aspetti su cui insisterà maggiormente il PM e altri su cui si concentrerà di più il PO. Ma di certo, senza una sana capacità di leadership — che non è semplice “comando” — le due figure non potranno dirsi complete e in grado di svolgere le loro attività.

Comunicazione efficace

Visto che devono costantemente relazionarsi con i diversi attori coinvolti nel processo, sia il PO che il PM devono essere in grado di comunicare efficacemente con clienti, management, componenti dei team di sviluppo, utenti finali, fornitori e, in definitiva, con tutti coloro che possano ricadere nell’ampio “contenitore” degli stakeholders.

Solo similarità?

Se quanto detto sopra sicuramente favorisce la “confusione” di denominazioni di cui stiamo parlando in questo articolo, è anche vero che, in aggiunta alle competenze comuni, ci sono invece degli aspetti che caratterizzano maggiormente l’una o l’altra figura.

Solo per citarle in breve, a un bravo PO è richiesto ad esempio un approccio maggiormente imprenditoriale: non è semplicemente il direttore di un progetto organizzato in gran parte da altri per “costruire” un prodotto pensato da altri ancora, ma svolge un ruolo in cui il legame con il prodotto da realizzare è più stretto, partecipativo, e in cui le decisioni che deve prendere richiedono un’ampia visione sull’intero ciclo produttivo, dall’idea al prodotto finito

Di contro, a un bravo PM, sono richieste, ad esempio, grandi doti di negoziazione, e di gestione del tempo, che chiaramente anche un PO deve avere, ma che, in un processo Scrum sono spostate maggiormente su altri ruoli.

Differenze sostanziali

Al di là della parziale coincidenza di competenze, ci sono alcune nette differenze tra il Project Manager e il Product Owner. Prima di vedere la diversità nelle attività che svolgono, soffermiamoci brevemente su un concetto spesso ripetuto, ma tante volte lasciato un po’ in sospeso.

Le parole sono importanti, ancora: la “responsabilità”

Torniamo ancora sul “tormentone” di questo articolo, perché è proprio dalla comprensione della differenza tra due parole che possiamo capire una prima e significativa differenza tra PO e PM. Le parole che ci interessano sono inglesi e, in questo caso, è davvero difficile scegliere un corrispettivo italiano che renda esattamente il loro significato.

Se infatti guardiamo ciò che la bibliografia corrente dice a proposito delle figure di PM e di PO, scopriamo che entrambi sono ritenuti “responsabili” delle attività che svolgono. Il fatto, però, è che si tratta di una responsabilità indicata con due diversi termini inglesi: responsibility e accountability.

Responsibility vs accountability

Per farla breve: il Project Manager è ritenuto responsible di gestire alcune attività e svariate persone [3], mentre il Product Owner è accountable [5]. Per quanto entrambi i termini siano traducibili in italiano come “responsabile” — e di fatto “responsabile” è la parola usata anche nella traduzione italiana della Guida Scrum — c’è una differenza neanche troppo sottile.

In inglese, responsible indica chi si prende carico di una determinata attività, o chi o cosa ha un’influenza nel far accadere un evento, ma non indica un’implicito obbligo di rispondere delle conseguenze.

Se invece si è accountable, si presuppone che si sia responsabili nel senso di dover rispondere personalmente delle conseguenze delle proprie azioni e/o omissioni. Non è pedanteria linguistica: è una differenza semantica significativa. E vuol dire che il Product Owner è davvero più “imprenditore” rispetto al Project Manager a cui sono demandati compiti di gestione più “esecutivi” — sicuramente di alto livello e di cui è responsabile — ma con l’accountability che nel Project Management tradizionale viene invece imputata a chi lo incarica, perché il PM non è il “proprietario” del prodotto.

Le attività di un PO

Oltre a questa sostanziale differenza nella responsabilità, un altro modo, probabilmente ancora migliore, per stabilire chiaramente che un Product Owner non è un Project Manager agile è porre attenzione alle attività che un PO è chiamato a svolgere e che appariranno in gran parte diverse da quel che invece fa un Project Manager già a una lettura semplicemente non superficiale.

Alcune attività che sicuramente rientrano tra quelle che un PO è chiamato a svolgere sono le seguenti.

• Essere “responsabile” del successo o del fallimento del prodotto che cura. E questo lo abbiamo spiegato diffusamente sopra.
• Avere una visione che, tenendo in considerazione tutti gli stakeholder, tracci una direzione “unificata” per quello che il prodotto deve diventare.
• Fornire le risorse necessarie allo sviluppo del prodotto, il che può significare essere in grado di autorizzare il necessario finanziamento.
• Garantire un supporto continuo e facilmente individuabile per il prodotto.
• Rendere massimo il valore del prodotto nei confronti di clienti, utenti e organizzazione che lo crea. L’abbiamo già detto: il PO è il “proprietario” del prodotto e diventa responsabile del fatto che questo prodotto crei quanto più valore possibile, in tutte le direzioni. Chiaramente, questo implica di doversi occupare del ROI (Return On Investment), del budget a disposizione, della cosidetta TCO (Total Cost of Ownership) e di altri aspetti che riguardano il ciclo di vita del prodotto.
• Il PO, poi, deve occuparsi della tenuta del Product Backlog, che è in molti casi individuata come la sua attività “istituzionale” principale, ma che non è l’unica, per quanto richieda grande dedizione: definire chiaramente gli item del Product Backlog, ordinarli secondo priorità, raffinarli in modo da ottenere elementi di dimensione lavorabile, e rendere tutto questo facilmente visibile e comprensibile agli attori coinvolti nel processo, assicurandosi che lo Scrum Team abbia il materiale su cui poter lavorare negli sprint successivi.
• Di non minore importanza è la tenuta dei rapporti con gli stakeholder, affinché tutti siano allineati alla visione del prodotto e agli obiettivi produttivi e di mercato. Significa, in pratica, invitare le persone giuste, nel senso di effettivamente interessate, alla Sprint Review, illustrare e discutere lo stato attuale del Product Backlog senza perdere di vista gli obiettivi, tener traccia del lavoro che ancora rimane da completare e, perché no, fare delle previsioni senza cadere nella trappola delle stime. Il tutto mantenendo il backlog sempre visibile a tutti gli stakeholder.

Quel che un PO non dovrebbe fare

Accanto ai suoi compiti, se elenchiamo brevemente quel che un Product Owner non deve fare, ci avviciniamo sempre più alla comprensione del perché il PO non è un PM “agile”.

Infatti il Product Owner non riceve gli input dai vari stakeholder per tramutarli in esecutività, ma piuttosto illustra la sua visione sul prodotto ai vari attori coinvolti e ne raccoglie il feedback: sembra una questione quasi sofistica, ma è invece un ribaltamento sostanziale rispetto a quello che dovrebbe fare un Project Manager.

E così, un PO non si occupa di creare e gestire una estesa documentazione di piani di progetto: non passa il suo tempo a scrivere documenti di avvio del progetto, piani predittivi a semestri o anni, diagrammi di Gantt o classica documentazione di questo tipo. E non si occupa neanche di controllare in maniera stretta i tempi e i progressi del team, magari allocando e riallocando continuamente “risorse umane” in un’ottica di ottimizzazione. L’abbiamo ripetuto allo sfinimento: il PO non è un PM dentro Scrum.

E infine, il PO non è un’“interfaccia” tra lo Scrum Team e il mondo esterno: per quanto a volte appaia svolgere questo compito, in realtà è l’intero Scrum Team che partecipa alle attività in cui sono coinvolti anche altri stakeholder, e il PO non svolge quindi alcun servizio di procura.

Conclusioni

Abbiamo visto un quadro — a onor del vero neanche esaustivo — sui motivi per cui un Product Owner non debba essere considerato un Project Manager agile. A di là di alcune competenze comuni tra i due ruoli e del fatto che alcune attività possano anche coincidere, le differenze sono sostanziali e tali da non consentire questa semplificazione: il PO è una figura non facile da svolgere al meglio ma che trova le sue caratteristiche principali nel suo tratto “imprenditoriale”, legato alla visione del prodotto e al suo ciclo produttivo, nella sua capacità di creare, ordinare e manutenere un Product Backlog — cioè un “manufatto” legato a un prodotto, più che un documento legato a un progetto — e, in ultima analisi, nel massimizzare il valore del prodotto per tutti gli attori coinvolti.

Riferimenti

[1] Ken Schwaber & Jeff Sutherland, The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game, november 2020
https://www.scrumguides.org/scrum-guide.html

[2] La traduzione in italiano della Guida Scrum, edizione 2020
https://www.scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Italian.pdf

[3] La voce “Project Manager” sul wiki Prince2®
https://prince2.wiki/roles/project-manager/

[4] Fabio Ghislandi, Accidenti! Non è command & control! Stili di leadership in un contesto agile. MokaByte 225, febbraio 2017
https://www.mokabyte.it/2017/02/stilileadershipagile/

[5] La figura del Product Owner come descritta nella guida in lingua inglese
https://scrumguides.org/scrum-guide.html#product-owner