AgilePM e Scrum: due metodi a confronto

Agilità significa flessibilità, rapidità, riflessi pronti nel rispondere e grande coordinazione. Non si può essere agili senza un’adeguata snellezza.

L’obiettivo di questo articolo è quello di introdurre i due metodi agili più conosciuti (AgilePM® e SCRUM), descrivendone in sintesi le caratteristiche principali e confrontandole. In aggiunta verrà proposta ai lettori una linea guida potenzialmente efficace nella scelta del percorso migliore da seguire per diventare agili.

Agile nel mondo del management è un termine molto generale, adatto a definire caratteristiche gestionali ispirate al “Manifesto per lo sviluppo agile del software“.

Proviamo adesso a mettere a confronto AgilePM® e SCRUM per analizzarne insieme differenze e vantaggi.

AgilePM

AgilePM è una metodologia agile sviluppata dal Consorzio universitario no-profit DSDM (Dynamic Systems Development Method) verso la fine degli anni Novanta, che partendo dal mondo agile dello sviluppo software ne eleva i migliori principi gestionali  ̶  unitamente alle tecniche più efficaci  ̶   fino a raggiungere il livello del Project Management.

Di conseguenza ci aspettiamo che le caratteristiche di AgilePM “rispecchino” questa sua peculiarità: l’essere un vero e proprio metodo di project management, ma snello e flessibile – dunque meno appesantito dalla formalità e dai vincoli presenti nelle più tradizionali metodologie di gestione progetti. Eccole elencate di seguito:

1. prevede la figura del Project Manager
2. prevede un Business Case, quindi i benefici che il cliente si aspetta dai nostri prodotti sono chiari e misurabili
3. prevede ruoli precisi all’interno di un vero e proprio team di progetto (People)
4. propone di gestire il progetto per FASI, ma fasi agili (Process)
5. suggerisce di seguire un Piano: il Delivery Plan (guardacaso un nome legato alla consegna al cliente)
6. suggerisce di mantenere un insieme di documenti (Products) adeguati al progetto: il loro numero e la loro complessità devono essere scalati e adattati a seconda dei casi
7. prevede l’utilizzo delle classiche tecniche agili (Practices) in combinazione e a supporto degli elementi che abbiamo menzionato poc’anzi
8. è possibile integrare prodotti da sviluppare con SCRUM (Sprint) all’interno di progetti gestiti con AgilePM senza penalizzare o vincolare la consegna della soluzione.

Cosa offre, ancora, AgilePM?

La perfetta integrabilità ‘sui due fronti’.

Precisiamo meglio: trovarsi nella posizione di AgilePM vuol dire posizionarsi ESATTAMENTE a cavallo tra il mondo tradizionale e quello agile.

Di conseguenza AgilePM è perfettamente integrabile SIA verso l’alto (es.: con PRINCE2, potendo sfruttare AgilePM per la consegna di un Pacchetto di Lavoro [workpackage] assegnato dal PM ad un Team Manager…) SIA verso il basso (es.: uno Sprint SCRUM può benissimo far parte di un progetto gestito con AgilePM, basta affiancare tale Sprint alle restanti Timebox strutturate invece secondo il metodo DSDM).

Purtroppo la monoliticità dei progetti tradizionali (es.: waterfall, ITIL… ecc.) come pure la loro formalità e impostazione gerarchica ci impediscono di ‘buttarsi a capofitto’ nel mondo Agile partendo dai metodi troppo agili.

SCRUM

Scrum è un framework agile per la gestione del ciclo di sviluppo del software, iterativo ed incrementale, concepito per gestire progetti e prodotti software, creato e sviluppato da Ken Schwaber e Jeff Sutherland nei primi anni Novanta.

Il termine SCRUM è mutuato dal termine del rugby che indica la ‘mischia’, ed è evidentemente una metafora del team di sviluppo che deve lavorare insieme in modo che tutte le parti interessate al progetto spingano verso un obiettivo finale comune (la ‘meta’).

Peculiarità di SCRUM è quella di rappresentare un metodo estremamente agile di Product Development.

Ecco alcune delle sue caratteristiche principali:

1. non prevede la figura del Project Manager, bensì quella dello Scrum Master: il coach che protegge la squadra dalle distrazioni, facilita l’esecuzione del progetto e funge da filtro verso influenze esterne
2. non prevede un Business Case, ma un artefatto chiamato Product Backlog: una lista ordinata dei ‘requisiti’ relativi al prodotto, ai quali il Product Owner assegna un codice di priorità
3. prevede solo i ruoli di Product Owner, Development Team e ScrumMaster
4. non prevede una gestione del progetto per fasi: si limita a suddividere il progetto negli Sprint che andranno a consegnare gli incrementi della soluzione
5. non prevede un piano di progetto, ma ogni Sprint planning meeting (ad es.: un incontro di otto ore per uno Sprint di un mese) pianifica il lavoro da fare producendo uno Sprint backlog
6. i documenti previsti (artefatti) sono tre
7. prevede l’utilizzo di alcune tecniche agili a supporto dello sviluppo del prodotto: per esempio lo sviluppo incrementale, la messa in priorità dei requisiti, e la presenza di eventi precisi (sia giornalieri che cadenzati a seconda degli Sprint)
8. non è possibile inserire nulla all’interno di SCRUM che alteri o influenzi la consegna del prodotto

AgilePM VS Scrum: il confronto

Passiamo adesso a confrontare alcuni dettagli di AgilePM con quelli di SCRUM:

1. Ruoli

AgilePM: sono previsti i classici ruoli di Management (Project Manager e Team Leader) ma affiancati da precisi ruoli di Business (che tipicamente arrivano dal cliente) unitamente a ruoli Tecnici (responsabili dello sviluppo della soluzione). La cosa importante è che non ci sia soltanto il team di sviluppo (SDT Solution Development Team) abbandonato a se stesso: ma che in equilibrio con esso vi sia un gruppo di coordinamento delle risorse, di cui fa parte anche il PM. In totale sono previsti dieci ruoli principali + tre opzionali.

SCRUM: prevede solo tre ruoli: Product Owner, Development Team e ScrumMaster. I Team Scrum sono auto-organizzati e cross-funzionali, pertanto scelgono come meglio compiere il lavoro organizzandosi e coordinandosi al proprio interno.

2. Documentazione

AgilePM: non sono previsti solo documenti legati al Prodotto (la soluzione), ma se necessario ci si può spingere a mantenere una vera e propria documentazione di progetto completa – garantita però snella e flessibile. L’importante è che i tre interessi principali (Business, Management e Soluzione) siano pienamente rappresentati da sei documenti principali (dinamici, quindi che seguiranno tutto il progetto).

SCRUM: i tre documenti previsti sono il Product Backlog (ved. punto 2), lo Sprint Backlog (la lista del lavoro da fare nello Sprint successivo) e il Burn down chart (il cronogramma)

3. Fasi

AgilePM: prevede sei fasi facenti parte di un vero e proprio ciclo di vita del progetto (DSDM Process). Tali fasi non riguardano soltanto l’effettivo sviluppo della soluzione (evolutionary development), ma anche le fasi iniziali (un mini studio di fattibilità e la preparazione dei documenti necessari).

SCRUM: suddivide il progetto in Sprint sui quali costruire il Burn down chart (il cronogramma)

4. Tempi

AgilePM: prevede due tipi di timeframe (intervalli temporali), le piccole Timebox (2-4 settimane) durante le quali eseguire una parte del lavoro, e gli Incrementi (che possono essere costituiti anche da più Timebox) alla fine dei quali  ̶ per ciascuno  ̶  vi è una fase di deployment, quindi di consegna di una soluzione parziale al cliente. All’interno di un Incremento possono tranquillamente coesistere sia Timebox che Sprint (SCRUM).

SCRUM: prevede che al termine di ogni Sprint corrisponda un Incremento, costituito dalla somma di tutti gli elementi completati nel Product Backlog e quelli completati negli Sprint precedenti.

5. Piani

AgilePM: prevede due veri e propri tipi di piano. Il Delivery Plan segue l’intero progetto fase per fase. Ogni Timebox Plan riguarda invece la sua singola Timebox.

SCRUM: prevede il solo Burn down chart (il cronogramma) costruito sulla base del lavoro da fare.

6. Priorità

AgilePM: prevede una PRL (Prioritised Requirement List) principale che segue l’intero progetto. Da questa dovranno essere derivate le singole PRL: una per ogni Incremento, e a sua volta una per ogni Timebox. Inoltre: la tecnica di messa in priorità deve essere il metodo MoSCoW, e la regola da seguire quella del 60-20-20 con la quale distribuire il più adeguatamente possibile l’effort da utilizzare, sia in termini di costi che in termini di tempi.

SCRUM: prevede il Product Backlog, la lista ordinata dei ‘requisiti’ relativi al prodotto, ai quali il Product Owner assegna un codice di priorità sfruttando tecniche di stima, le User Stories, ecc.

7. Comunicazione

SCRUM: prevede quattro eventi principali (Sprint Planning Meeting, Daily Scrum, Sprint Review e Sprint Retrospective) ai quali si possono aggiungere altri due eventi opzionali (Backlog Grooming e lo Scrum of Scrums).

AgilePM: prevede la tecnica particolare di Workshop facilitati dalla presenza di un Facilitator neutrale, unitamente ai Daily Stand-up da tenere giornalmente solo all’interno del team di sviluppo. Inoltre sono previste almeno tre Review all’interno di ogni Timebox, un kick-off con workshop di pianificazione (mantenuta collaborativa, non individuale) e un close-out formale di chiusura che contiene anche il Retrospective (quindi l’approvazione delle issue da risolvere nella prossima Timebox).

Giunti a questo punto potremo decidere quando ci serve un metodo, oppure l’altro, senza correre rischi e riuscendo persino ad integrarli tra di loro: mentre team diversi gestiscono molteplici progetti sfruttando le potenzialità dei metodi a loro più convenienti.