Condividi l'articolo

Il Project Manager…

Il project manager svolge un ruolo fondamentale nella leadership di un team di progetto al fine di raggiungere gli obiettivi del progetto stesso. Questo ruolo è chiaramente visibile per tutta la durata del progetto.

(Project Managament Institute)

Il Product Owner…

Il Product Owner ha la responsabilità di massimizzare il valore del prodotto risultante dal lavoro svolto dal Team di Sviluppo. Il Product Owner è l’unica persona responsabile della gestione del Product Backlog

(The Scrum Guide)

La visione integrata del progetto

L’obiettivo del presente articolo è quello di fornire una mia personale interpretazione dei due ruoli, quello del project manager, figura cardine in un approccio tradizionale, e quello del Product Owner, uno dei tre ruoli che compongono lo Scrum team e figura legata al framework Scrum.

Le due figure hanno molto in comune e sembrerebbe quasi che la figura del PO abbia in qualche modo fagocitato la figura del PM e sia impossibile pensare ad una loro convivenza in un ambiente progettuale.

Si dia uno sguardo alla figura sottostante per capire la portata del ridimensionamento del ruolo del project manager nell’Agile:

Nell’approccio tradizionale il PM ha lo stesso ruolo di un direttore di orchestra, ha la responsabilità di raggiungere gli obiettivi del progetto (di ambito, di budget, di tempo e di qualità), si occupa della corretta identificazione, gestione e coinvolgimento degli stakeholder di progetto, assicura che la qualità venga rispettata ed implementata, gestisce il team di progetto curando aspetti relazionali e comportamentali, verifica costantemente che il team collabori e lavori in un sano ambiente di progetto.

Il project manager deve utilizzare una corretta e trasparente comunicazione con tutti, cliente finale in primis.

Come si evince dalla figura, il ruolo del PM in Scrum viene completamente annullato e tutte le sue responsabilità sono state ripartite nello Scrum team.

Considerando la figura del PO, queste le responsabilità ereditate dal PM:

  • Assicurare che il progetto raggiunga gli obiettivi;
  • Gestire ambito e budget;
  • Gestire la comunicazione ed il coinvolgimento degli stakeholder;
  • Gestire la Vision del prodotto e ridefinire la priorità sulla base delle esigenze acclarate dal cliente;
  • il PO è la voce del cliente.

I giochi sembrerebbero fatti..

Perché parlare allora di una visione integrata del progetto? Quale scopo?

Vorrei far notare che il framework Scrum, il suo life cycle, parte con il Product Backlog (la coda degli elementi in ambito del progetto) già pronta, e la domanda legittima è quella di sapere come si è arrivati ad una costruzione del Backlog, quali sono stati i momenti importanti che hanno condotto ad una sua realizzazione.

Il fatto è che il framework Scrum, come il suo cugino eXtreme Programming, sono due framework che si posizionano in un layer di sviluppo al di sotto di quello di Project Management.

Nella gestione dei progetti di cambiamento la metodologia Agile propone un metodo controllato e si pone come alternativa ai tradizionali approcci di Project Management.

Quando si parla di approcci o modelli Agili, talvolta si suppone che non esistano elementi di contatto con la metodologia tradizionale.

L’Agile non deve essere considerato come una estremizzazione del Project Management tradizionale bensì come sua evoluzione in contesti particolarmente difficili e turbolenti e non relegati ai soli progetti IT.

Secondo Jim Highsmith, autore del testo Agile Project Management (Highsmith, 2009) e cofirmatario dell’Agile Manifesto, un possibile Enterprise Framework dovrebbe prevedere quattro layer di sviluppo per un progetto:

  • Portfolio Governance: L’attività di Portfolio deve essere considerata attività strategica all’interno di qualsiasi organizzazione. Valutare a priori se una iniziativa possa o meno diventare un progetto o se un progetto in essere possa essere dismesso perché non più in linea con la strategia aziendale, sono tutte attività di buon governo. Per attività di Portfolio Management sarà possibile sfruttare sia un approccio tradizionale che un approccio Agile (SAFe  – Scaled Agile Framework – è un framework Agile dove vengono contemplate attività strategiche a livello di Portfolio Management);
  • Project Management: In base al contesto ed al contenuto, sarà possibile scegliere un approccio di gestione progetto tradizionale o un approccio Agile. I framework che si possono implementare potrebbero essere quelli relativi ad un approccio tradizionale (PMI o Prince2) o ad un approccio Agile (DaD o DSDM);
  • Iteration Management: Qualora fosse scelto un approccio Agile, è importante definire il framework che permetta la gestione delle iterazioni attraverso le quali il sistema verrà costruito attraverso continui rilasci incrementali di prodotto funzionante. L’approccio iterativo rappresenta una importante peculiarità della metodologia Agile e questo approccio può essere gestito attraverso Scrum o eXtreme Programming che rappresentano, nel panorama delle metodologie Agile, due framework che dettano regole precise per la gestione delle iterazioni;
  • Technical Practices: In base alla scelta del framework che si vuole seguire per la gestione delle iterazioni, è possibile derivare una serie di pratiche e tecniche per ottimizzare il lavoro da svolgere.

Pertanto, nulla vieta di far convivere simultaneamente un approccio tradizionale con uno Agile.

La presenza di una metodologia non implica l’assenza dell’altra, come la presenza di un Project Manager non deve far pensare all’assenza di un Product Owner.

L’elemento che non deve mai mancare per una corretta riuscita di un progetto è la presenza di una buona governance e di un approccio che sappia integrare diversi modi di lavorare traendo da ciascuno di essi la migliore sinergia in termini di processi e best practice che possa risultare utile ed efficace.

In Scrum non viene considerata minimamente la figura del PM in quanto Scrum è un framework che si pone ad un layer di sviluppo a livello di Iteration Management ed è sensato che parta con un Product Backlog.

In Scrum manca tutta la parte relativa alla prima creazione di un Backolg di progetto ed è qui che entra in gioco il layer superiore, quello di Project Management, in aiuto affinché le cose funzionino correttamente.

Per avallare il tutto, si considerino altri punti di contatto tra la metodologia tradizionale e quella Agile.

 

WBS come anello di congiunzione

Uno degli artefatti più importanti che viene elaborato durante la pianificazione in ambito tradizionale è la WBS (Work Breakdown Structure – struttura di scomposizione del lavoro). La WBS rappresenta una struttura gerarchica, ad albero rovesciato, e descrive tutto il lavoro che deve essere fatto nel progetto.

Le foglie della WBS vengono identificati con i Work Package, pacchetti di lavoro, e rappresentano uno o più deliverable che devono essere realizzati e consegnati.

La WBS è una struttura fortemente orientata al deliverable.

Il PM rappresenta il supervisore di questa struttura ed utilizza questo artefatto non solo durante la pianificazione per comprendere appieno l’ambito del progetto ma soprattutto durante il monitoraggio del progetto per comprendere e valutare un potenziale impatto di una change request.

La WBS viene utilizzata in un approccio tradizionale anche per assegnare unicamente responsabilità sui WP, le foglie della struttura, ai WP Owner che saranno i responsabili del delivery della soluzione.

E questa rappresenta un interessante punto di convergenza e di contatto con il framework Scrum.

Il WP rappresenta un deliverable che verrà consegnato e questa caratteristica la si può ritrovare anche nella gestione dello Sprint in Scrum.

Lo Sprint rappresenta un lasso di tempo predefinito, due – quattro settimane, al termine del quale il team si impegna a rilasciare un incremento di prodotto potenzialmente usabile dall’utente finale, quindi anche lo Sprint è orientato al deliverable come il WP.

Le figure che ho inserito nell’immagine all’interno del WP potrebbero coincidere con le figure dello Scrum team, in particolare:

  • Technical leader, il responsabile del WP, potrebbe essere il PO;
  • Team leader, potrebbe essere lo Scrum Master;
  • Team di sviluppo è il Development team di Scrum.

Questa lettura permette non solo di armonizzare ed integrare le due metodologie ma si riuscirebbe anche a raccontare la genesi di un Product Backlog che nel framework Scrum sembrerebbe essere orfano.

In progetti piccoli, la figura del PM potrebbe coincidere con la figura del PO, ma in progetti grandi e complessi, dove l’ordine di complessità può derivare anche dalla trasversalità del progetto a livello aziendale, sarebbe meglio far convivere le due figure utilizzando il meglio di entrabe le metodologie.