Tempo di lettura stimato: 16 minuti
Cos’è l’Agile Project Management
Agile project management (gestione di progetto Agile) è un termine generico per i metodi di sviluppo che adottano un approccio incrementale e iterativo. Anche se ha avuto origine nello sviluppo di software, e si trova ancora principalmente in questo ambiente, i suoi principi possono essere applicati ad altre discipline.
Negli anni si sono diffuse diverse metodologie per l’Agile Project Management, come ad esempio Scrum, AgilePM®, PRINCE2® Agile e Praxis Framework.
Le diverse sfumature nell’applicazione di Agile sono accomunate comunque da alcune caratteristiche fondamentali, riportate nell’Agile Manifesto:
- Brevi iterazioni di sviluppo note come sprint.
- Lavoro a stretto contatto tra gli sviluppatori e le parti interessate.
- Regolare ridefinizione delle priorità di lavoro.
- Approccio rapido e flessibile nell’indirizzare i cambiamenti di ambito.
Varie tecniche si sono evolute al fine di supportare l’implementazione di queste caratteristiche, come i timebox per la pianificazione, il metodo MoSCoW per l’assegnazione di priorità e le burn down charts per riferire sullo stato di avanzamento lavori. Un modo molto semplice per capire la differenza tra Agile e forme di sviluppo più tradizionali è identificare il loro rapporto con il triplo vincolo (ambito, tempi, costi), come illustrato nella figura di seguito.
Nei progetti tradizionali, l’enfasi è posta sull’ambito. Nei progetti Agile, l’enfasi è posta su tempi e costi. L’ambito è ricavato da questi in modo che la pianificazione stabilisca quale ambito possa essere considerato entro i vincoli posti da tempo e costi.
Di seguito in questo articolo ci focalizzeremo su AgilePM®, con un piccolo accenno anche a PRINCE2® Agile, per poi passare a Scrum. Infine parleremo di Kanban, che non è una metodologia Agile, ma i suoi sistemi vengono utilizzati nel lavoro agile.
AgilePM®
AgilePM® è un “pacchetto” completo, che include una metodologia di Project Management e una metodologia per la realizzazione e il rilascio di prodotti. Contiene tutto ciò che è necessario per gestire e realizzare progetti in modo agile ed è facile da comprendere e mettere in pratica.
AgilePM® è stato realizzato dall’organizzazione no-profit Agile Business Consortium (in precedenza nota come DSDM Consortium), ed è il risultato di 20 anni di esperienza e continui feedback da parte di progetti dei settori pubblico e privato.
Esistono parecchi approcci agile basati sullo sviluppo iterativo di prodotti, che consentono di raggiungere efficacemente l’obiettivo. AgilePM®, però, ritiene che le caratteristiche dei progetti siano differenti da quelle dello sviluppo iterativo di prodotti.
Il metodo tiene conto del fatto che i progetti hanno un ciclo di vita, e che il loro allineamento strategico e il relativo business case debbano essere approfonditi in modo da comprendere quali siano i benefici ed il valore che i risultati del progetto consentiranno di ottenere.
La filosofia dell’Agile Business Consortium prevede che ogni progetto debba essere allineato a obiettivi strategici chiaramente definiti, e debba focalizzarsi sul far ottenere rapidamente dei benefici concreti al business. La parola importante qui è “rapidamente”. Un approccio agile deve consentire di ottenere dei benefici più rapidamente di un approccio di project management tradizionale.
Il ciclo di vita di AgilePM® consente di raggiungere questo obiettivo durante le fasi di Pre-project, Feasibility e Foundations.
AgilePM® ha un ciclo di vita ben definito, che consente di mantenere sotto controllo il progetto dal momento dall’ideazione fino all’ottenimento dei benefici.
Come funziona AgilePM®?
In AgilePM® il progetto è suddiviso in periodi di tempo brevi e ben focalizzati, con degli obiettivi chiaramente specificati. Il lavoro è diviso in timebox con delle deadline inamovibili, durante le quali ha luogo lo sviluppo, in modalità evolutiva. L’uso della prioritizzazione MoSCoW garantisce che i deliverable siano costantemente rivalutati alla luce delle priorità di business.
I ruoli che devono essere ricoperti nei team di Project Management e di Delivery sono definiti chiaramente e hanno delle responsabilità precise; sono rappresentati tutti i ruoli di Business, di Project Management e di Sviluppo Tecnico necessari per gestire, realizzare e rilasciare i risultati del progetto. Per ottenere i migliori risultati dall’applicazione di AgilePM® si suggerisce di richiedere il supporto di un Coach.
Durante tutto il progetto devono essere applicati otto principi:
Sono anche indicati cinque fattori critici di successo che devono essere tenuti sotto controllo per garantire che lo spirito di AgilePM® sia mantenuto attivo durante tutto il progetto:
- Abbracciare l’approccio AgilePM
- Un team efficace per sviluppare le soluzioni
- Coinvolgimento del business
- Sviluppo iterativo, test integrato e rilasci incrementali
- Trasparenza
L’Agile Business Consortium ha messo anche a disposizione un Project Approach Questionnaire per valutare l’applicabilità dell’approccio AgilePM a uno specifico progetto. La guida AgilePM® fornisce anche indicazioni su come comportarsi negli ambienti in cui i benefici dell’approccio Agile non siano percepiti in modo chiaro.
A chi potrebbe servire AgilePM®?
L’approccio AgilePM® può essere applicato da tutte le organizzazioni che desiderano adottare un approccio Agile, sia nel caso stiano già adottando un approccio di Project Management strutturato, sia nel caso opposto. Il metodo può essere integrato facilmente con PRINCE2®, dal momento che i ruoli definiti nei due approcci sono complementari, e i cicli di vita sono simili; AgilePM® ha in più, rispetto a PRINCE2®, i ruoli necessari alla realizzazione dei requisiti.
È possibile applicare AgilePM® anche insieme agli eventuali metodi di sviluppo Agile già esistenti, come ad esempio Scrum, dal momento che i metodi di sviluppo Agile si somigliano un po’ tutti. Rispetto a Scrum aggiunge i ruoli necessari per dirigere e gestire il progetto.
Certificazioni disponibili
Per questa guida sono disponibili due diversi livelli di certificazione:
- Livello 1 – AgilePM® Foundation. questo livello di certificazione dimostra che il professionista conosce e comprende tutti gli elementi della metodologia.
- Livello 2 – AgilePM® Practitioner: questo livello di certificazione dimostra che il professionista è in grado di applicare gli elementi della metodologia a un caso di studio.
Scopri il corso AgilePM® Foundation in auto apprendimento
PRINCE2 Agile®
Si tratta di una nuova guida all’Agile Project Management, realizzata da Keith Richards, lo stesso autore della guida AgilePM®. PRINCE2 Agile® risulta particolarmente utile per chi applica Scrum e desidera ottenere una migliore governance dei progetti, o per chi applica PRINCE2® e desidera capire come integrare questo metodo con i framework Agile per lo sviluppo di prodotti.
Certificazioni disponibili
Per questa guida sono disponibili due diversi livelli di certificazione:
- PRINCE2 Agile® Foundation; questo livello di certificazione dimostra che il professionista conosce e comprende tutti gli elementi della metodologia.
- PRINCE2® Agile® Practitioner: questo livello di certificazione dimostra che il professionista è in grado di applicare gli elementi della metodologia a un caso di studio.
Scrum
Scrum è un metodo di Agile Project Management utile a completare progetti complessi. Il metodo è stato pensato in origine per progetti di sviluppo software, ma funziona bene per qualsiasi ambito di lavoro complesso e innovativo.
Quando Jeff Sutherland ha creato il processo Scrum nel 1993, ha preso in prestito il nome da uno studio del 1986 di Takeuchi e Nonaka, pubblicato nella Harvard Business Review. In quello studio, Takeuchi e Nonaka confrontano i team ad alte prestazioni e interfunzionali con la formazione di mischia utilizzata dalle squadre di Rugby.
Il Body of Knowledge ufficiale si intitola The Scrum Guide. La Guida è stata scritta da Ken Schwaber e Jeff Sutherland, co-creatori del framework. Potete scaricare gratuitamente da qui la versione più recente della Guida; disponibile anche in italiano.
Il processo Scrum
L’approccio di Agile Project Management Scrum è descritto nella figura riportata di seguito.
In questo approccio un product owner crea una wish list su base prioritaria chiamata product backlog. Questa lista può essere messa in priorità utilizzando tecniche come MoSCoW e dovrebbe essere soggetta ai principi fondamentali della gestione dei requisiti.
Durante lo sprint planning (pianificazione dello sprint), il development team seleziona un gruppo di prodotti ad elevata priorità che si impegna a completare durante uno sprint (timebox) dalla durata, generalmente, tra le 2 e le 4 settimane.
Il team si incontra ogni giorno per verificare lo stato di avanzamento lavori e questo incontro è facilitato da uno ‘Scrum Master’. Il ruolo dello scrum master è mantenere il team concentrato, tenere traccia dello stato di avanzamento e rimuovere gli ostacoli che potrebbero influenzare il raggiungimento degli obiettivi dello sprint. Le opinioni circa il fatto che questo ruolo possa o meno essere ricoperto dal project manager sono discordanti.
Lo stato di avanzamento nell’ambito di uno sprint può essere monitorato utilizzando un approccio kanban. Lo stato di avanzamento dello sviluppo di un prodotto durante molteplici sprint può essere visualizzato in una burn down chart.
Alla fine dello sprint, i prodotti scelti potrebbero essere pronti per essere dimostrati al product owner o effettivamente consegnati. Qualsiasi prodotto non completato viene reinserito nel backlog.
Uno sprint dovrebbe concludersi con una review (quasi come una review post progetto ma su una scala molto ridotta). Il team poi seleziona il successivo gruppo di prodotti per lo sprint a seguire.
Ruoli in Scrum
I due ruoli principali in Scrum sono il Product Owner, che rappresenta il cliente e gestisce tutti i requisiti (aggiunge requisiti con una descrizione dettagliata, dà priorità ai requisiti e pianifica i rilasci), e lo Scrum Master, che aiuta il team ad applicare il processo Scrum.
Lo Scrum Master facilita le riunioni quotidiane gestisce gli eventuali problemi, supporta il Product Owner e rimuove gli ostacoli al progresso del team.
Certificazioni disponibili
Tra i diversi corsi Scrum disponibili sul mercato abbiamo deciso di inserire nel nostro catalogo quello di ScrumStudy, dal momento che è l’unico provider a fornire materiale didattico standard e ben strutturato.
Sono disponibili certificazioni per ciascun ruolo presente nei team Scrum:
- SMC™ – Scrum Master Certified™
- SPOC™ – Scrum Product Owner Certified™
- SDC™ – Scrum Developer Certified™
Kanban
I sistemi Kanban sono sistemi di Visual Management che limitano il numero di elementi di lavoro in circolazione. Questo crea un “sistema pull”.
Esiste una grande varietà di sistemi Kanban; alla fine degli anni ’40 Taiichi Ohno impiegò un sistema di cartellini di segnalazione per mettere in pratica l’elemento just-in-time del Toyota Production System.
Più di recente le Kanban Board (vedi figura) sono diventate comuni quando si lavora in modo Agile.
Copyright © AXELOS Limited 2018. Reproduced under licence from AXELOS. All rights reserved.
Kanban è solitamente applicato non solo per migliorare il flow nel breve termine, ma anche per creare un cambiamento duraturo e continuo ai processi produttivi di un’organizzazione.
A cosa serve Kanban
Il primo principio fondamentali del metodo Kanban è “Inizia con quello che fai ora”.
Questo significa che Kanban non dovrebbe essere considerato come un’alternativa agli altri framework di Agile Project Management, ma come un modo per aumentare l’agilità grazie al miglioramento del processo decisionale, allo spostamento in avanti del momento in cui si prendono decisioni definitive, e alla riduzione dei tempi di esecuzione, con il conseguente aumento delle opportunità di feedback.
Kanban diventa applicabile con l’istituzione di un flusso di lavoro ragionevolmente ripetibile.
Le basi di Kanban
Il metodo Kanban è costituito da sei pratiche principali.
1. Visualizzazione
Rendendo il lavoro visibile, i team possono facilmente vedere come il lavoro sta procedendo, cosa è stato fatto, cosa c’è ancora da fare e quali problemi esistono che ostacolano l’avanzamento del lavoro
Il modo in cui il lavoro viene fisicamente visualizzato può variare, ma spesso si tratta di una semplice griglia (o “ticket”) che mostra i diversi stati attraverso i quali passa un elemento di lavoro e le informazioni che aiuteranno la prioritizzazione e la programmazione (ad esempio la registrazione del rischio associato).
Le informazioni sono solitamente registrate su schede o note adesive che sono aggiornate nel corso della giornata.
È possibile aggiungere “Swim Lane” per identificare tipi simili di lavoro o “classi di servizio”. Le Swim Lane sono rappresentate con righe orizzontali che attraversano le colonne verticali.
2. Limitare i WIP
Anche se questo è un concetto fondamentale nel Kanban, appare controintuitivo; in prima battuta sembra possa rallentare il lavoro.
È importante capire il ragionamento dietro la limitazione del WIP, poiché innesca molti eventi e risolve diversi problemi, come illustrato dalle due analogie seguenti:
- Ridurre la pressione: Introdurre limiti di velocità su autostrade e superstrade accelera il flusso del traffico nei momenti di maggior carico.
- Ridurre il task switching: Scrivere un documento richiede molto più tempo se l’autore riceve contemporaneamente notifiche e-mail con un avviso sul desktop o simili. Ogni notifica interrompe la concentrazione e i processi di pensiero in corso che poi devono essere ‘ricaricati’ e riavviati.
Il limite WIP applicato è di solito rappresentato come un numero in cima a ogni colonna sulla Kanban board. Questo numero limita la quantità di Post-Its™ che possono essere presenti nella colonna in qualsiasi momento.
L’uso dei limiti WIP è alla base del sistema “pull” che caratterizza il modo in cui Kanban evita di programmare il lavoro in momenti specifici (si parla di “sistema push”) ma avvia il lavoro solo quando esiste la capacità di portarlo a termine.
Limitare i WIP riduce l’impatto del task-switching e del multi-tasking. Se un team o un individuo sta lavorando su diverse cose contemporaneamente, un sacco di tempo produttivo viene sprecato quando si passa da una cosa all’altra.
I limiti WIP producono efficacemente i segnali visivi che indicano che il lavoro può essere tranquillamente avviato se è presente la capacità di trattarlo efficacemente.
3. Gestire il flusso
Un sistema Kanban mira a raggiungere il più alto livello di performance dal modo di lavorare esistente per consegnare qualcosa di valore il più velocemente possibile.
Di conseguenza il team è costantemente alla ricerca di modi per massimizzare l’efficienza del flusso e minimizzare i ritardi (per esempio rimuovendo gli ostacoli). Kanban evidenzia i problemi che la squadra deve risolvere.
Si tratta di un costante esercizio di squadra in cui l’obiettivo è quello di rimuovere gli sprechi il più rapidamente possibile. La Kanban board visualizza il lavoro che si muove attraverso il sistema e agisce come un cruscotto che permette al team di vedere i blocchi e le aree dove il flusso non è regolare. Il team può quindi intraprendere un’azione correttiva immediata.
4. Rendere esplicite le policy
Anche se l’empowerment, l’auto-organizzazione e la fiducia giocano un ruolo significativo in Agile sono comunque necessari confini chiaramente definiti entro cui i team possano operare.
Ogni team ha bisogno di definire chiaramente come lavora e rendere queste policy trasparenti. Queste potrebbero essere descritte come “regole” per creare un ambiente che è più obiettivo per il processo decisionale e dove può essere richiesto un controllo.
Le policy (o “pratiche di lavoro” ) dovrebbero evolvere ed essere costruite in modo collaborativo nel tempo per creare una serie di linee guida che poi diventano norme per il team.
5. Implementare meccanismi di feedback
In definitiva il valore rilasciato da qualsiasi processo (è giudicato dal consumatore finale o dal cliente finale. Essere in grado di valutare quantitativamente questo è molto vantaggioso perché influenzerà direttamente ciò che sarà rilasciato in seguito.
Di solito trascorre molto tempo tra l’aggiunta di una caratteristica alla lista delle cose da fare da parte di un team e la ricezione di un feedback quantitativo relativamente a tale caratteristica.
Cercare costantemente di accorciare questo ciclo di feedback in modo che il lavoro di maggior valore sia nel sistema Kanban è essenziale per fornire il maggior valore possibile.
Il metodo Kanban contiene quattro tipi di revisione per raccogliere il feedback (stand-up meeting, service delivery review, operations review e risk review).
6. Migliorare in modo collaborativo, evolvere in modo sperimentale
l metodo Kanban abbraccia l’idea che il miglioramento è un esercizio collaborativo. La sua trasparenza e la facilità con cui il sistema Kanban (e quindi il processo sottostante) può essere modificato crea le condizioni naturali per il miglioramento collaborativo.
Dall’osservazione del sistema in azione e dall’acquisizione di metriche chiave come i tempi di consegna e i tassi di consegna, il team è in grado di formulare ipotesi su ciò che può frenare il sistema e quindi concordare cambiamenti che possono essere testati sperimentalmente in modo sicuro.
Questa pratica implica un significativo cambiamento culturale per molti perché abbraccia il concetto di Kaizen della cultura Toyota; in altre parole:
Il miglioramento dei processi è affare di tutti, ogni giorno! Non ci sono specialisti di processo in Kanban, perché tutti si concentrano sulla gestione del risultato del loro processo. Vedono tutto ciò che ha un impatto sulla capacità o sulla performance come un problema che loro stessi devono risolvere, e non qualcosa da delegare a qualcun altro per risolverlo.