Metodologie Agile
L’Agile Project Manager non esiste
“Preparazione Esame di Certificazione Agile PMI-ACP®”
Per consultare questi approfondimenti, devi essere almeno registrato al sito (Registrati se non lo sei già)
L’Agile Project Manager NON esiste. Ecco perché. Nella filosofia Agile, responsabilità e ruolo tradizionalmente attribuiti al “project manager”, sono opportunamente distribuiti su tre figure:
- Scrum Master,
- Product Owner e
- Team di sviluppo.
Quindi, per non continuare a fare figuracce, smettiamola di nominare “Agile Project Manager” perché in ambito Agile, non ha senso.
Chi richiede un “Agile Project Manager” dimostra tutta la tua incompetenza o ignoranza sui principi basilari delle Metodologie Agile.
Se hai bisogno di una qualsiasi di queste tre figure (Scrum Master, Product Owner o Team di sviluppo), perché non la chiami con il suo vero nome (Scrum Master, Product Owner o Team di sviluppo)?
Ad un colloquio di lavoro, questo errore potrebbe costare molto caro a chi cerca lavoro: essere bollati per incompetenti o impostori.
Ma sarebbe ancora più grave se chi vi esamina parlasse di “Agile Project Manager“.
Quando nel 2003, iniziai a parlare di Metodologie di Project Management, un sedicente esperto Agile mi disse più o meno: “io son stato colpito dalle metodologie Agile, basta con il project management tradizionale”. E’ ancora lì, non si è ancora ripreso e non so se ha mai compreso una Metodologia di Project Management Agile.
Le metodologie di project management Agile hanno un enorme potenziale, ma vanno utilizzate correttamente senza mischiare ruoli e responsabilità retaggi della cultura tradizionale, ove acquisita.
Forse la cosa più difficile è riuscire a cambiare atteggiamento, non tanto apprendere un nuovo strumento software, sempre più alla portata di tutti.
L’approccio Agile è solo un problema di cultura aziendale. Nel periodo di transizione da Project Management classico (waterfall) all’Agile Project Management è normale che ci sia qualche sovrapposizione di ruoli, per questo bisogna evitare di cascare nelle trappole della letteratura e forzare il ruolo di un approccio precedente in una metodologia tutta nuova, compreso la revisione dei ruoli.
Project Manager tradizionale
La figura che si avvicina di più alla figura del project manager tradizionale è lo Scrum Master. Ma, al contrario del project manager tradizionale – responsabile al 100% del successo o del fallimento del progetto, lo Scrum Master non ha nessuna responsabilità degli obiettivi del progetto.
Lo Scrum Master ha solo autorità sui processi utilizzati.
In pratica, lo Scrum Master è un esperto dell’utilizzo del processo con lo scopo di rendere più performante un team di sviluppo.
Perciò, insisto, lo Scrum Master non ha nessuna delle responsabilità tipiche del project manager tradizionale: ambito, costo, persone, rischio, comunicazione, etc.
Ma allora chi è responsabile di un progetto Agile?
Il classico project manager aveva la responsabilità di gestire ambito, costo, persone, rischio, comunicazione, acquisti e molto altro. Questa posizione è incomprensibile nel mondo Agile. In effetti, la critica della filosofia Agile al ruolo del project manager tradizionale è più che fondata, in ottica Agile.
- Perché mai un project manager deve assumersi la responsabilità dell’ambito di un prodotto, se esiste anche un signor “Product Manager”?
- Perché mai un project manager deve rispondere della schedulazione, se esiste un team di sviluppo che può decidere quale e quanto lavoro portare avanti in ogni iterazione?
(citazione: “il vero dubbio è anche il dubbio rispetto al dubbio” Edgar Morin)
In Agile questi dubbi vengono risolti distribuendo le responsabilità tra Team di Sviluppo e Product Owner.
- Team di Sviluppo – schedula le attività sulla base del backlog di richieste accumulate.
- Product Owner – decide cosa richiedere assegnando le priorità alle singole “User Story”, che presenta al team alimentando il backlog.
La gestione della qualità, invece, è responsabilità di tutti: Team di sviluppo, Product Owner e Scrum Master.
Allo stesso modo vengono condivise eventuali altre responsabilità come ad esempio la sicurezza o la riservatezza.
La figura dello “Scrum of Scrum”
L’esigenza di un coordinamento è più sentita in presenza di progetti molto grandi, esattamente come per un grande progetto tradizionale dove il Project Manager ricorre alla nomina di una serie di “Team Leader” per governare da 10-15 unità fino a diverse centinaia.
Anche i progetti Agile possono aver diverse centinaia di persone. E’ evidente che in questi casi occorre molto più coordinamento.
Di solito, un grande progetto Agile viene suddiviso in tanti progetti più piccoli per rientrare nei parametri ottimali delle metodologie Agile e per coordinare i vari team (ognuno con il suo Product Owner, Scrum Master e Team di Sviluppo). In questi casi, nasce la figura del “Project Manager” meglio se proclamato “Program Manager.
Comunque, questo titolo genera un sacco di confusione.
E’ preferibile chiamarlo “Scrum of Scrum”, perché, in realtà, se i vari team Agile applicano correttamente i processi Agile, questa figura svolge solo un ruolo di coordinamento, senza interferire nella gestione di ambito, costo, tempi, rischi, etc., come ci si aspetterebbe da un project manager tradizionale.
Il primo che ha parlato di “Scrum of Scrum” è stato Jeff Sutherland nel 2001 in: http://www.controlchaos.com/storage/scrum-articles/Sutherland%20200111%20proof.pdf
Il compito dello “Scrum of Scrum” è più vicino a quello di un “Program Manager” in quanto deve solo risolvere eventuali interdipendenze tra i vari sotto progetti, dialogando con i rispettivi Scrum Master. Inoltre, potrà allocare e tracciare il budget, comunicare con gli stakeholder, curare gli acquisti comuni, occuparsi dei rischi comuni in supporto ai vari team di sviluppo dei sotto progetti. Lo “Scrum of Scrum” è il quarto ruolo dell’Agile Project Management. Ma, per favore, non dite più che è un “project manager”.
Esempio di Scrum of Scrum of Scrum
Modulo di Iscrizione
Modulo di Comunicazione
