Adottare Scrum in una organizzazione “tradizionale”: e il Project Manager?

Negli ultimi anni sono aumentate le organizzazioni che decidono di adottare metodologie agili abbandonando il project management: è una scelta oculata in grado di garantire la sostenibilità organizzativa dell’impresa e che ha positive ricadute in numerosi settori.

Però questo tipo di cambiamento impegna l’organizzazione a intervenire su aspetti molteplici, fra cui i ruoli e le mansioni delle persone. Il Project Manager è certamente il ruolo su cui si deve intervenire in modo più significativo: alcune delle sue mansioni sono spostate agli altri membri del team, alcune non servono più (sono anzi in antitesi con l’Agile), alcune restano in carico a una figura analoga anche se con prospettive e obiettivi differenti.

Che fine fa il Project Manager?

Di fatto, ci troviamo sempre più spesso a gestire questo tema “scottante” all’interno delle nostre attività di formazione e consulenza agile. In particolar modo su Scrum, dove ruoli e cerimonie sono ben definitii, occorre comprendere cambiano i ruoli e le gerarchie all’interno di una organizzazione che decida di muoversi verso l’adozione delle metodologie agili abbandonando un sistema basato sul Project Management tradizionale, dove vi è una forte strutturazione e gerarchia delle persone.

In particolare questo tema spesso esplode in tutta la sua forza quando si parla del ruolo del Project Manager, quello di stampo classico di scuola PMI. Un’interpretazione semplicistica di questo aspetto è che Scrum prevede tre ruoli — Product Owner (PO), ScrumMaster (SM) e squadra di sviluppo (DevTeam) — per cui non c’è posto per il Project Manager (PM) che anzi spesso viene visto come l’incarnazione dell’antitesi dei principi e dei valori tipici di Scrum e dell’agilità.

Se è vero che in Scrum si ha un differente approccio alla gestione del progetto, è altrettanto vero che buona parte delle mansioni del PM sono ancora svolte in un team Scrum; si tratta da un lato di capire chi le svolge al suo posto (rimappatura delle competenze), dall’altro vedere come cambia l’approccio allo svolgimento di determinati compiti.

Rimappare le competenze

In rete gira in questo periodo un’immagine che tenta quindi di dare questo tipo di risposta (figura 1).

Lo schema di figura 1 è certamente interessante e rappresenta un buon punto di partenza, ma ha il limite di semplificare eccessivamente la situazione. Da un lato si potrebbe dire che lo spostamento delle competenze dai ruoli tradizionali verso PO e SM è sommariamente corretta; dall’altro però quei ruoli dovrebbero essere svolti in modo diverso; per questo motivo ci sentiamo di sottoscriverla all’80%, però con molte precisazioni.

Punto per punto: come evolve il lavoro del PM in un team Scrum

Per rispondere alla domanda del titolo, tramite interviste e discussioni informali, abbiamo raccolto un po’ di pareri e informazioni da chi lavora sul campo su questo tema. Di seguito è riportato un elenco di attività che in un contesto di project management tradizionale sono attribuibili al ruolo del Project Manager (PM).

Riportiamo pertanto un’analisi puntuale delle varie attività tipiche di un PM tradizionale mostrando come tali attività sono inquadrabili in un team Scrum: sono ancora necessarie? Se sì, chi le svolge? Come cambiano?

Per rendere la lettura il più possibile ordinata e fruibile, abbiamo suddiviso l’elenco in aree di competenza: gestione degli stati di avanzamento, del team, dello scope di progetto, del contratto e dei risultati.

 

Responsabilità del Project Manager in ambito gestione del SAL e del team

Il PM è responsabile del gruppo di lavoro e delle risorse a lui affidate

in Agile non c’è una figura a cui viene delegata la responsabilità di gestire il gruppo di lavoro, ma tale responsabilità è distribuita fra PO, SM e DevTeam. La presenza di questi tre ruoli e le rispettive responsabilità sono garanzia che il gruppo si possa auto-organizzare e sia in grado di raggiungere gli obiettivi di progetto. A voler essere rigorosi la parola “risorse” è bandita, sostituita da “persone”.

Il PM garantisce la “disciplina” di processo

L’obiettivo del PM è quello di garantire un processo disciplinato, e per questo deve identificare, coordinare e mantenere focalizzate le risorse sul conseguimento degli obiettivi.

In Scrum è lo ScrumMaster che vigila che il gruppo segua le indicazioni della metodologia, ma con una accezione leggermente differente. Egli controlla che il gruppo segua le regole, ma non è lui che le impone ne’ che le definisce; le regole sono definite e concordata dal team. Qualora il gruppo senta il bisogno di variare qualcosa, lo farà nel pieno rispetto dello Shu Ha Ri e del Kaizen; in questo caso lo SM si preoccuperà di evidenziare le differenze, i cambiamenti e gli eventuali risultati positivi (o peggioramenti). Quindi non è un controllore che impone, ma è il coach del team che stimola la discussione sul cosa e come il gruppo decide di agire.

Il PM gestisce la comunicazione con gli stakeholder esterni

Per quanto riguarda l’aspetto della Product Ownership (ossia che cosa è e che cosa deve fare il prodotto) questa è una attività che viene svolta dal PO. Per quanto riguarda invece gli aspetti organizzativi legati al team di sviluppo, la gestione degli impedimenti, l’analisi dei problemi è questa una attività che normalmente svolge lo SM.

Il PM gestisce le “risorse”

Il PM assegna le responsabilità ai componenti del team, individua le risorse più appropriate, fornisce guida e direzione ai membri del team di progetto. Su questo punto il manifesto agile è chiaro: “Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano” e ancora “Fondiamo i progetti su individui motivati. Diamo loro l’ambiente e il supporto di cui hanno bisogno e confidiamo nella loro capacità di portare il lavoro a termine.”

Ne deriva che in Scrum i team si autorganizzano assumendosi la responsabilità di portare a termine il lavoro preso in carico. Quindi, in questo caso, il PM non dovrebbe svolgere alcuna mansione o avere alcuna responsabilità.

 

Responsabilità del Project Manager in ambito gestione del team

Il PM forma il team di progetto

il processo di formazione e di organizzazione del team dipende molto dal grado di maturità agile dell’organizzazione all’interno della quale ci si muove. In una organizzazione che sia ben avanti in questo percorso di crescita, probabilmente il gruppo si auto–forma e si organizza in maniera spontanea, accorpando quel giusto mix di persone e di competenze necessarie per portare a completamento il progetto con successo.

Altre volte invece il gruppo viene formato in base alle necessità dell’organizzazione (disponibilità, necessità logistiche, altro) o secondo le indicazioni di un qualche responsabile. Un team Scrum può essere considerato come un sistema in evoluzione il cui scopo è il raggiungimento di un sempre maggior grado di efficienza. Tuckman con il suo modello di evoluzione dei team, identificò quattro fasi all’interno di questo percorso di crescita: forming, storming, norming e performing. Come si può immaginare, è proprio nell’ultima fase che il team inizia ad essere performante.

Arrivare alla quarta fase richiede tempo ed energie. Per tale ragione in Agile si tende a mantenere i team i più stabili possibili facendoli sopravvivere a più progetti. Ne deriva che la formazione di un team è una cosa che non dovrebbe accadere di frequente. Quanto più l’organizzazione riesce a non interferire nel processo di formazione dei gruppi (le persone si scelgono da sole il gruppo e i colleghi con cui lavorare) minore sarà il tempo necessario per arrivare alla fase di performing; Interessante a tal proposito la lettura di un articolo di Craig Larman [1].

Il PM gestisce il team

Gestire un team è un concetto che si declina in molteplici interpretazioni e implementazioni. La maggior parte di tali declinazioni probabilmente sono estranee alla filosofia Agile e a Scrum. Le regole definite da Scrum relativamente ai ruoli, agli ambiti di competenza e al come devono interagire fra di loro sono di garanzia che il gruppo possa auto-organizzarsi e quindi gestirsi in autonomia. Di fatto un PM in questo caso non è di nessun aiuto.

 

Responsabilità del Project Manager in ambito scope

Il PM vigila sul raggiungimento degli obiettivi entro i vincoli prefissati

Il PM è la persona identificata a garantire il conseguimento degli obiettivi del progetto, entro i vincoli prefissati di tempo, costo e qualità di prodotto. Questa attività è svolta completamente dal team Scrum nei vari ruoli con differenti competenze. Il PO raccoglie i requisiti funzionali (la cui implementazione soddisfa i bisogni di business dell’utente finale) e non funzionali (il cui rispetto è necessario per rimanere all’interno degli accordi presi, delle linee guida aziendali o di altro ancora). In quanto owner del Product Backlog, ne definisce contenuti e priorità in modo da consentire sempre il rispetto dei requisiti o dei vincoli di progetto. Il PO è responsabile quindi di definire questi vincoli ed è responsabile di portarli al resto del team che coralmente agisce per il raggiungimento di tali obiettivi.

Il PM esegue la WBS del progetto

in Scrum non viene creata una Work Breakdown Structure, ma si scompone il prodotto in items, ossia cose da fare per arrivare al prodotto finito e che andranno a comporre il Product Backlog (PB). Il lavoro di preparazione del PB è frutto di un processo di analisi e modellazione che certamente è svolto da PO il quale si avvale della collaborazione degli altri stakeholder: qualcuno del team di sviluppo, qualche Subject Matter Expert.

Il gruppo, tramite attività e strumenti come lo User Story Mapping in cui il PO guida, consiglia ma anche ascolta e chiede, arriva alla definizione di quello che deve essere fatto. È quindi il PO il responsabile della lista delle funzionalità che andranno a comporre il prodotto finale, ma l’identificazione è frutto di un lavoro di gruppo.

Il PM consegna i progetti

Il PM consegna i progetti a lui assegnati, nei tempi previsti e all’interno del budget assegnato, soddisfacendo i requisiti e le specifiche concordate. In Scrum, analogamente a quanto visto nei punti precedenti, la consegna di un progetto non è responsabilità di una figura specifica, ma tutti i membri di uno Scrum Team si impegnano per ottenere questo obiettivo. È quindi vero che il focus su tempi, budget, scope è sotto la responsabilità del PO.

Il PM coordina il processo di stima

Il processo di stima in Scrum segue una procedura completamente differente. Come noto, quando il PO presenta gli elementi del Product Backlog per l’inserimento all’interno di uno sprint, il team ne valuta l’effort tramite un processo di stima adattivo e incrementale. Nel capitolo su Scrum del libro “Guida galattica per agilisti” [2] questo aspetto è ampiamente descritto: come stimare, come arrivare a una prima stima “grossolana” che si raffina successivamente. Anche in questo caso, PO e team di sviluppo cooperano per arrivare a una stima del backlog il più affidabile e corrispondente possibile. Dato che il PO dice cosa deve essere fatto e il team di sviluppo dice come e quanto, in estrema sintesi si potrebbe dire che la stima è una attività in carico al gruppo di sviluppo.

Il PM sviluppa un piano di rilasci

Questo è uno dei compiti principali del PO il quale si confronta assiduamente con gli stakeholder esterni (clienti, utenti, committenti) per realizzare un piano che soddisfi i bisogni di business di chi commissiona il lavoro; se il PO è interno all’organizzazione che sviluppa il prodotto, egli si confronterà anche con gli stakeholder interni (business dell’azienda che sviluppa il prodotto) in modo che il piano di rilascio massimizzi il ROI di chi deve svilupparlo.

Il PM stabilisce i misuratori

Per capire esattamente chi si occupa di questo aspetto in Scrum, andrebbe definito meglio il contesto e cosa si intende per KPI: di fatto anche il team stabilisce i KPI, per esempio quando in retrospettiva decide un miglioramento e un modo per misurarlo.

Ma, se da un lato la maggior parte delle metriche sono inserite all’interno della Definition of Done, altre se ne possono estrapolare dai vari information radiators: fra queste possiamo certamente valutare il confronto fra la velocity attesa e quella realmente eseguita — tale differenza esprime il grado di auto-coscienza del team—, il trend del numero di storie rifiutate alla demo, il tempo di lavorazione delle singole storie — la capacità di esprimere storie piccole che quindi richiedono poco tempo di lavorazione è anche in questo caso un buon misuratore della maturità del team e del PO — e altro ancora.

Queste metriche dovrebbero essere definite dal PO per quanto concerne la qualità intrinseca del prodotto — molti item della DoD sono di pertinenza del PO o del management con il quale si interfaccia — o della qualità del lavoro svolto dal team, tenendo presente che in questo secondo caso è lo ScrumMaster che ne tiene traccia.

Il PM definisce i punti di controllo

in Scrum i punti di controllo sono definiti per specifica al termine di ogni sprint. Tutti partecipano e collaborano per far funzionare al meglio la Sprint Review. Il PO svolge il ruolo di controllore: da un lato, stila l’elenco delle funzionalità da implementare (il Product Backlog Item), dall’altro definisce i criteri di accettazione da utilizzare per validare il lavoro svolto.

Lo ScrumMaster, in quanto owner del processo, è garante che siano rispettate le regole che il team si è dato; in tal senso lo SM si preoccupa quindi che i controlli siano eseguiti, il PO li esegue, il team di sviluppo ne è coinvolto. Al solito quindi un lavoro di gruppo.

Il PM tiene sotto controllo l’avanzamento lavori

Scrum fa uso di una serie di strumenti per monitorare lo stato di avanzamento dei lavori (SAL): se i biglietti che scodano sulla task board o la mappa bidimensionale prodotta durante lo story mapping permettono di vedere nel dettaglio il progresso sui singoli item, il Burndown Chart offre una visione d’insieme certamente molto efficace.

L’aggiornamento del Burndown Chart è una attività tipicamente in carico allo ScrumMaster, il quale raccoglie i dati di lavorazione ed eventualmente esegue quel minimo di elaborazione necessaria per poter compilare il diagramma. La task board invece viene aggiornata direttamente dalle persone che lavorano sui vari task. Il PO monitora quindi questi strumenti per verificare lo stato di avanzamento ed eventualmente comunicare agli stakeholder esterni al progetto eventuali ritardi o rallentamenti. Per cui anche in questo caso il processo di gestione dell’avanzamento è ripartito con varie mansioni e responsabilità fra le persone del team.

Il PM gestisce il rischio e l’ambito di progetto

Il PM gestisce proattivamente i rischi, gli issues e l’ambito del progetto per tutta la sua durata. In Scrum, la gestione del rischio viene svolta per mezzo di alcune attività il cui scopo è quello di anticipare la lavorazione di quelle parti per le quali si ipotizza possano esserci criticità; questa strategia si implementa per esempio tramite un opportuno ordinamento del backlog, dando priorità quando possibile alle attività con un maggior coeffciente di indeterminazione in modo da chiarirne prima possibile la fattibilità o individuarne i punti critici.

Anticipare vuol dire lavorare in modo intensivo sul Product Backlog Refinement per scoprire prima possibile — e in ogni caso per tempo debito — aspetti di difficile implementazione, in maniera da non ritrovarsi allo Sprint Planning con punti oscuri o dubbi non chiariti. Anticipare vuol dire che il team di sviluppo mostra al PO le cose fatte appena queste sono finite, senza aspettare la fine dello sprint. In tal modo si ha prima possibile un feedback sul risultato ottenuto.

Per ridurre l’indeterminazione (il rischio) infine è utile massimizzare gli incontri e gli scambi in informazioni con gli utenti e clienti per chiarire il più possibile eventuali dubbi o verificare la bontà delle cose fatte. Tutte queste strategie ricadono per la maggior parte nella sfera di pertinenza del PO, per cui possiamo affermare che il risk management è una attività di responsabilità del PO.

 

Responsabilità sul contratto

Il PM ottiene le risorse necessarie per il progetto

Questa parte rientra nell’ambito delle attività di contratto e accounting che non sono fra i ruoli del PO ne’ di alcun altro membro di un team Scrum.

Il PM si assicura della chiarezza del contratto

Nell’organizzazione tradizionale, il PM si assicura che la baseline di progetto sia specificata nel contratto in maniera completa, adeguata e accurata. In Scrum il team è prima di tutto focalizzato sul prodotto e sui bisogni degli utenti; definire in modo preciso e completo la baseline all’interno del contratto è probabilmente in contrapposizione con alcuni principi dell’agilità (“il cambiamento è benvenuto”). Detto questo, qualora si lavori in un progetto fixed scope, è compito del PO fare in modo che il prodotto finale rispetti tutte le richieste come da contratto.

Il PM garantisce che il lavoro sia assegnato e gestito secondo contratto

Nell’organizzazione tradizionale, il PM garantisce che l’assegnazione e la gestione del lavoro (attività, deliverables, responsabilità) avvengano secondo gli accordi contrattuali. Nella struttura produttiva organizzata secondo i principi di Scrum, invece, il PO si preoccupa che la vision e il piano di rilascio siano compatibili con quanto definito nel contratto. Ma non definisce assegnazioni.

Il PM consente cambiamenti solo come definito nel contratto

Nella azienda tradizinale, è prassi che il Project Manager consenta cambiamenti alla baseline solo seguendo le procedure definite nel contratto. In un contesto Scrum, il PO gestisce i cambiamenti nel backlog, non tanto per il rispetto di un contratto — che comunque è un vincolo importante deve essere onorato — ma per massimizzare ogni volta il valore rilasciato al cliente. In questo senso potremmo perfino azzardare che il contratto è più un impedimento che una risorsa per guidare il progetto.

Il contratto si cambia solo previa autorizzazione

Il PM “tradizionale” accetta cambiamenti al contratto solo dopo il compimento dell’iter formale di autorizzazione previsto: il rispetto di un processo di approvazione è il modo con il quale nel Project Management classico si prova a garantire che il contratto sia mantenuto valido. Un bravo PO è sempre focalizzato sul rilascio del valore e sa che ogni modifica al Product Backlog viene fatta per massimizzare tale valore. Il valore viene prima quindi del contratto, in linea con l’Agile Manifesto. Nel caso in cui il rispetto di un iter formale è un valore per l’organizzazione, il PO si spende perche’ ciò accada.

 

Responsabilità sui risultati

Il PM assicura la fattibilità del progetto

In Scrum, definire la fattibilità è un compito che in genere viene svolto durante le attività di inception, di definizione della vision del progetto o durante la trasformazione della vision in backlog di alto livello. Tutti sono impegnati per assicurare la riuscita del progetto, sebbene la responsabilità ultima sulla valutazione della fattibilità sia del PO.

Il PM definisce il contesto di progetto

In Scrum, questa è certamente una responsabilità del PO il quale cura e gestisce non solo il Product Backlog (cosa deve essere fatto) ma anche la Vision di prodotto (perche’ deve essere fatto, per chi, con quali obiettivi).

Il PM bilancia tempo, budget e scope

Compito “da manuale” del PM nella dottrina classica di gestione azienale è quello di bilanciare i tre vincoli (tempo, budget, scope) tramite l’analisi del SAL.

In Scrum, per rispondere a questa domanda, più che provare a capire se questo sia un mestiere del PO, può essere utile valutare se sia interesse in un progetto agile tenere sotto controllo queste tre grandezze. A tal proposito è utile riprendere un passaggio del libro che stiamo scrivendo “Guida galattica per agilisti” [2], che riportiamo di seguito

“[…] per quanto visto fino a questo punto, appare evidente che anche in agilità si possa parlare di stime, si possa provare a prevedere quando terminerà un progetto o quanto potrà costare. Anche in Scrum si può stimare tutto un Product Backlog e calcolare in base alla Velocity la data di consegna, aiutandosi con il Burn Down chart per tenere sotto controllo lo stato di avanzamento.

In agilità si pone però molta attenzione all’importanza di fare scope management, cosa che per esempio si traduce nel concordare con il cliente la priorità delle cose da rilasciare. Prioritarizzare l’implementazione delle funzionalità, in caso di ritardo nelle tempistiche di consegna, semplifica molto il descoping (ossia, che cosa può essere tolto dal progetto), perche’ la parte importante è già stata sviluppata testata e validata dal cliente/utente.

Anche nel project management tradizionale fare descoping è formalmente possibile, ma in realtà viene fatto raramente e solo in presenza di pressioni estreme. Tipicamente si ragiona con la regola “non si può togliere nulla”; dopodiche’, quando il tempo stringe e l’ultima feature importante è stata realizzata, centinaia di cose minori spariscono nell’arco di una notte. Quindi perche’ non far diventare questa pratica una regola di progetto?

Se si accetta la possibilità di fare scope management, il valore della stima di tutto il backlog diminuisce molto perche’ scope management va a influire proprio su quel valore: dov’è il limite del progetto? Da variabile immutabile universale, diventa un concetto molto fluido. Per questo in agilità lo scope spesso non viene visto come uno dei parametri fondamentali nella gestione del progetto; lo sono il tempo, il budget, ma lo scope viene messo in secondo piano in favore dei business objectives. Lo scope è un dettaglio tecnico, soggetto a cambiare, con cui si possono ottenere gli obiettivi di business, anche se spesso le due cose sono confuse, volontariamente o meno.”

Il PM monitora le attività

In Scrum, il PO non si preoccupa del come il progetto viene portato a completamento (responsabilità del team) ma solo del cosa. In questo senso, quindi, non ha alcun interesse a monitorare le attività, se non eventualmente per essere informato di eventuali impedimenti.

Il PM misura l’avanzamento

In Scrum, una delle responsabilità del PO è certamente quella di verificare costantemente lo stato di avanzamento del progetto, tramite strumenti come il BurnDown chart; è sua preoccupazione riferire al cliente o al businesss interno eventuali ritardi o impedimenti che possano precludere il raggiungimento degli obiettivi.

Il PM adotta misure correttive

Nella gestione tradizionale, il PM intraprende le azioni correttive necessarie per il rispetto dei vincoli di progetto. In Scrum, le azioni correttive che il PO può fare sono sulla struttura del backlog (composizione, contenuto, aggiunta e rimozione) nonche’ sull’ordinamento; come extrema ratio può eventualmente procedere per l’interruzione dello sprint (sprint abort) evento considerato di una certa gravità.

Il PM anticipa e gestisce il cambiamento

in Agile, il cambiamento è benvenuto: è un aspetto fortemente presente nell’ambito di un progetto agile. Per questo tutti sono impegnati nella gestione e nell’accettazione del cambiamento. Detto questo gestire le variazioni sullo scope (backlog), sugli obiettivi e sulla vision è una delle principali mansioni del PO.

Il PM gestisce fornitori e appaltatori

Sinteticamente possiamo dire che questo tipo di lavoro non è parte della Product Ownership per cui è una attività non in carico al PO; in questo caso si può pensare di lasciarla in carico a un PM. Detto questo, se è certamente vero che il PO non gestisce forniture e appalti dal punto di vista dell’accounting, dovrà però in qualche modo coordinarsi (insieme al team) se questi fungono da SME.

In tal senso un fornitore o un appaltatore rappresenta un punto di contatto (nel senso di una dipendenza esterna) con la quale il PO deve comunque interfacciarsi, sia per necessità di sincronizzazione del lavoro, sia per coordinare il flusso e lo scambio di informazioni o artefatti.

Il PM verifica l’accettazione dei deliverable

In Scrum, l’accettazione dei deliverable è certamente una delle responsabilità del PO che verifica, all’interno della Sprint Review, il lavoro svolto dal team di sviluppo.

 

Responsabilità sugli aspetti economici

Il PM controlla pagamenti e scadenze

Il PM ha piena conoscenza della tipologia di contratto (fixed price o time & material) dei termini di pagamento e della corrispondenza con determinate milestones. In Scrum, questa è una cosa che il PO deve conoscere e tenere sotto controllo in modo chiaro.

Il PM associa piano di progetto e budget dei costi

Il PM associa il piano di progetto a un budget dei costi, approvato dal management; poi deve gestire questi aspetti. In Scrum, questo è un lavoro che passa in carico al PO che svolge tali attività non tanto per rispettare un contratto ma per rilasciare valore.

Il PM associa piano di progetto e budget dei ricavi

Il PM associa il piano di progetto e a un budget dei ricavi, approvato dal Management. In Scrum, questa è un’attività legata più al flusso monetario che al concetto di Product Onwership; per questo resta un lavoro in carico al PM.

Il PM elabora dei consuntivi

Nella gestione di progetto classica, il PM raccoglie e consuntiva settimanalmente i timesheet del team di progetto. In Scrum, tutti contribuiscono alla raccolta dei dati: lo ScrumMaster produce degli Information Radiator oppure consolida i dati. Tipicamente lo ScrumMaster condivide questi artefatti (Product e Sprint Burndown Chart, Velocity trend, altri) e li consegna al PO; ma lo SM potrebbe andare a raccontare queste cose direttamente al management.

Il PM autorizza le note spesa del team di progetto

In questo caso, le cose possono cambiare molto da caso a caso; una organizzazione che abbia raggiunto un buon livello di maturità agile probabilmente potrebbe organizzarsi in modo che il team Scrum abbia a disposizione un budget che gestisce in autonomia. Altre invece potrebbero voler tenere slegate le due cose (project management agile e rendicontazione delle spese). In linea di massima possiamo quindi dire che questa attività non è un compito in carico al PO ne’ ad alcun altro membro del team Scrum. Potrebbe tranquillamente restare in carico al PM o a una persona facente le veci di PM.

Il PM prepara i report

Il Project Manager “classico” predispone mensilmente i dati e gli status report richiesti dalle strutture di controllo della propria azienda e dalla contabilità per l’emissione delle fatture al cliente. In Scrum, i dati per questi report vengono forniti dal DevTeam insieme allo SM, e poi vengono passati al PO.

 

Conclusione

Come si è potuto vedere in questo articolo, molte delle mansioni di un PM classico si trasferiscono al PO, e alcune sono condivise fra tutti gli attori di uno Scrum Team. Altre, infine, non sono contemplate in un contesto di Agile Project Management. In un prossimo articolo, prendendo spunto dalla teoria dei giochi (contract game), vedremo come in realtà Project Manager e gruppo di sviluppo abbiano spesso una visione e degli obiettivi in contrasto fra loro: in questo caso, la presenza di un Product Owner serve proprio per risolvere questa forma di conflitto per il bene del progetto.