Cos'è la gestione dei programmi Agile?

La gestione dei programmi Agile è un approccio alla gestione di più progetti correlati (un programma) che si basa su principi Agile come flessibilità, collaborazione, sviluppo iterativo, priorità al feedback dei clienti e miglioramento continuo.

Agile è una filosofia con un insieme di principi, più che una metodologia specifica. Tuttavia, esistono metodologie Agile consolidate che spesso fanno parte della gestione dei programmi Agile, tra cui Scrum, extreme programming (XP) e Kanban. La gestione dei programmi Agile è stata inizialmente progettata da e per i settori del software, al fine di offrire più valore ai clienti più rapidamente, tuttavia la sua applicazione si estende ora a più settori.

La gestione dei programmi Agile include in genere diversi progetti correlati. I singoli progetti possono essere gestiti con un framework Agile, ma la gestione dei programmi Agile incorpora una serie di progetti in un unico insieme coeso durante l'intero ciclo di vita. Salendo di livello, una serie di programmi e progetti sottostanti potrebbe essere organizzata secondo una strategia di gestione del portfolio più ampia.

La gestione dei progetti Agile si concentra su un progetto specifico e sulla gestione di obiettivi, tempistiche, risorse e team relativi a quell'unico progetto. La gestione dei programmi Agile supervisiona un gruppo di progetti correlati e la strategia che unisce questi progetti in obiettivi organizzativi più ampi. Queste due discipline condividono molte delle stesse funzioni, tuttavia variano nell'ambito; i program manager Agile assumono un ruolo più ampio nella strategia del programma, nel rischio, nella comunicazione con gli stakeholder e molto altro.

Un modo rapido e semplificato per spiegarlo è che la gestione del progetto è più interessata all'esecuzione tattica e tempestiva di un singolo progetto, mentre la gestione del programma adotta un approccio più strategico per coordinare il successo globale di progetti separati nell'ambito del programma.

La gestione dei progetti come disciplina ha iniziato a prendere forma negli Stati Uniti negli anni '50. Negli anni '90 furono formalizzati dei metodi noti come "a cascata", in cui ogni fase di un progetto deve essere completata prima che l'intero team si sposti alla fase successiva. Tuttavia, con l'aumentare della vitalità e della complessità del software, i metodi di gestione dei progetti tradizionali e a cascata si sono rivelati ingombranti e tutt'altro che ideali per i progetti che procedono rapidamente e subiscono frequenti modifiche.

Nel 2001, un gruppo di sviluppatori di software ha creato l'Agile Manifesto per la gestione dei progetti Agile, costituito da quattro valori chiave e 12 principi. I valori chiave sono:

• Individui e interazioni sono più importanti di processi e strumenti
  
  
• Il software funzionante è più importante di una documentazione completa
  
  
• La collaborazione con i clienti è più importante della negoziazione del contratto
  
  
• Reagire a un cambiamento è più importante che seguire un piano

I valori preferiti non richiedono l'abbandono di quelli non preferiti. Ad esempio, la filosofia Agile non vieta l'uso di un piano, bensì pone maggiore enfasi sulla risposta e sulla preparazione ai cambiamenti inevitabili.

Questi principi Agile sono diventati sempre più utilizzati per il processo di sviluppo del software, tuttavia la filosofia va ben oltre lo sviluppo del software Agile. I principi Agile sono ora impiegati in molti settori, dalla moda alle biotecnologie, fino alla pubblica amministrazione.

Ciò che rende l'approccio Agile diverso dai metodi precedenti come la metodologia a cascata è che i metodi Agile sono, fin dall'inizio, progettati per essere iterativi, cooperativi e flessibili. In un sistema di gestione dei programmi Agile, i progetti vengono creati rapidamente e sono regolarmente rivisti, discussi e modificati in base alla risposta del team o del cliente. Si presume fin dall'inizio che i piani e gli approcci debbano cambiare e che non ci sarà un'adesione incondizionata alla pianificazione iniziale. I singoli membri del team hanno il potere di parlare, senza una gerarchia così rigida come in altri approcci.

Poiché la gestione dei programmi Agile è una filosofia piuttosto che una metodologia concreta, le specifiche delle pratiche Agile possono variare notevolmente da organizzazione a organizzazione o da programma a programma. Ci sono tuttavia alcuni aspetti comuni nella gestione dei programmi Agile.

La gestione dei programmi Agile include più progetti individuali; sia l'intero progetto che ogni singolo progetto potrebbero essere organizzati all'interno di un framework Agile. La gestione dei programmi Agile incorpora una visione olistica e generale di un gruppo di progetti. Spesso include elementi non presenti nella gestione dei singoli progetti, come il budget, la strategia generale e l'analisi a lungo termine.

Rispondere rapidamente al cambiamento è un principio fondamentale della filosofia Agile. Pertanto, la gestione dei programmi Agile considera il cambiamento un'opportunità per modificare la rotta e apportare miglioramenti continui che offrano valore al cliente. La suddivisione dei progetti in incrementi più piccoli per il completamento consente alle organizzazioni di essere più flessibili e orientarsi più rapidamente.

Un aspetto chiave della gestione dei programmi Agile è il suo approccio iterativo. I singoli progetti all'interno del programma passano attraverso più versioni e i team di sviluppo del prodotto discutono e migliorano i risultati ogni volta. È fondamentale fornire continuamente output funzionanti, sia che si tratti di un intero progetto o di un singolo aspetto. È anche importante perfezionare il prodotto a ogni iterazione, in base al feedback dei clienti, ai KPI e ai requisiti in evoluzione.

Per la metodologia Agile, le conversazioni faccia a faccia sono più efficaci di lunghe e-mail o altre comunicazioni basate su testo. Mentre un thread tramite e-mail può richiedere ore, giorni o addirittura settimane, a causa dei vincoli di tempo o delle e-mail perse, una comunicazione faccia a faccia può portare a termine la stessa operazione in pochi minuti.

La gestione Agile del programma, come visione generale di un programma, deve mantenere l'attenzione sull'efficienza e sulla rimozione di elementi non necessari o ingombranti. La documentazione è un mezzo per raggiungere un fine, non il fine stesso, e dovrebbe includere solo ciò che è necessario.

L'onestà e l'apertura sono la chiave per il successo di un programma Agile. Le conversazioni dovrebbero consentire a tutti i membri del team di esprimersi. In questo approccio manageriale, la voce di tutti è valida e ascoltata.

Allo stesso tempo, deve essere accettabile filtrare le idee irrealizzabili senza scoraggiare chi ha formulato quell'idea dal parlare in futuro. Il successo delle "retrospettive" (o " retro", ovvero valutazioni post-progetto in cui viene raccolto il feedback) si basa anche sulla trasparenza del team.

La gestione dei programmi Agile, come filosofia, non richiede l'uso di alcun framework particolare. Tuttavia, molti framework di gestione dei progetti, tra cui Scrum e Kanban, sono diventati strettamente associati alla filosofia Agile. Ecco alcuni dei framework più utilizzati.

Scrum è un framework per il lavoro collaborativo di progetto in team. Il nome, anche se sembra simile a un acronimo, deriva in realtà dallo sport del rugby; in una "mischia", i giocatori si abbracciano in una spinta collaborativa contro i loro avversari. È una specie di carica della cavalleria, ma senza i cavalli.

In Agile, un team Scrum prevede tre ruoli:

• Project manager: l'anello di collegamento tra il team di Scrum e gli stakeholder, che potrebbero essere utenti, clienti o una società madre. Il project manager è responsabile della comunicazione di fattori esterni come budget, personale e feedback al team di Scrum, mentre comunica i progressi del team agli stakeholder.
  
  
• Scrum master: lo Scrum master è meno un "capo" tradizionale e più un insegnante del metodo Scrum, un direttore d'orchestra, che facilita l'orientamento, la comunicazione e la risoluzione dei problemi. Gli Scrum master non sono in genere responsabili delle assunzioni e dei licenziamenti.
  
  
• Sviluppatori o membri del team: questo termine può variare nei casi in cui, ad esempio, il team Scrum opera in un settore che non riguarda il software. Indipendentemente dal fatto che questo ruolo sia denominato sviluppatore, membro del team o membro dello staff, questo ruolo non ha gerarchia. Idealmente il team è composto da tre a nove membri; i gruppi più grandi tendono a essere più difficili da guidare per uno Scrum master. Ciò può includere anche team che si organizzano autonomamente, in cui le persone decidono esattamente chi e di cosa necessita il team per avere successo, senza un'eccessiva pianificazione da parte del management.

Scrum è caratterizzato da alcuni concetti specifici che lo distinguono da altri modelli organizzativi basati su team. Il product backlog è un archivio di tutte le attività, le idee, i requisiti, i risultati finali e le risorse di cui il team potrebbe necessitare durante lo scrum. Può (e dovrebbe davvero) essere costantemente aggiornato e monitorato dal team per contribuire a garantirne l'efficienza e la completezza.

In uno scrum, il lavoro viene separato in sprint, che in genere durano da una a quattro settimane. Nello sprint, i membri del team lavorano per raggiungere un obiettivo specifico e realizzabile. L'obiettivo potrebbe essere un modello di lavoro, un mockup, un prototipo o anche solo una funzione o un elemento del prodotto finito o della soluzione.

Durante lo sprint, i membri del team si incontrano una volta al giorno per uno "scrum giornaliero" o "stand-up". Queste riunioni, secondo i principi Scrum, devono essere di livello estremamente elevato. Non più lungo di 15 minuti, lo scrum giornaliero prevede che i membri del team annuncino brevemente i propri progressi e i blocchi che ostacolano il loro lavoro, con il minor numero di dettagli possibile. A volte, alcuni membri del team possono organizzare una riunione post-scrum per discutere ulteriormente di qualcosa annunciato nello scrum giornaliero.

Alla fine di uno sprint, l'intero team (membri del team, scrum master e project manager) si riunirà per esaminare e discutere ciò che è stato creato. Il project manager può comunicare eventuali modifiche apportate dagli stakeholder, come gli utenti o l'organizzazione e, dopo una discussione, il team può incorporare tali modifiche nello sprint successivo.

Kanban è un sistema visivo per la gestione e il monitoraggio dei progetti. Le bacheche Kanban offrono una rappresentazione visiva dei progressi di un team su un progetto, in cui le singole attività secondarie sono archiviate in una di poche categorie. Tali categorie solitamente includono:

• Backlog: tutte le attività che non sono ancora state spostate in un'altra categoria. All'inizio del progetto, tutte le attività sono nel backlog
  
  
• In corso: le attività in fase di svolgimento
  
  
• In revisione: attività per le quali è stata raggiunta la fase di completamento iniziale, che sono in fase di valutazione da parte di un altro utente
  
  
• Completato: le attività completate.

"Kanban" deriva dalla combinazione delle parole giapponesi che significano segno ("kan") e tavola ("ban") e insieme significano qualcosa di simile a un cartellone pubblicitario o a una bacheca. Il kanban può essere realizzato sia in forma analogica che digitale. In forma analogica, i post-it fisici sono spesso utilizzati per singole attività, le quali vengono poi spostate da una colonna all'altra una volta completate.

Esistono anche molte versioni digitali delle bacheche kanban, che possono essere particolarmente utili per i team di progetto in cui alcuni o tutti i membri sono lavoratori da remoto.

La programmazione estrema, o XP, è una metodologia Agile originariamente progettata per gli ingegneri del software per migliorare la qualità, la reattività e la velocità del software. Il concetto di base è una forma di Agile che si basa su sequenze di creazione ancora più piccole e verificabili.

In XP, ogni singolo elemento di un progetto complessivo viene ripetutamente testato, a volte anche bombardato da test destinati a romperlo. Questi singoli aspetti vengono poi testati insieme, spesso settimanalmente, per garantire la massima compatibilità.

Nella comunicazione, XP si basa sulla semplicità all'estremo. La documentazione deve essere il più minimale possibile per essere compresa dagli altri membri del team, con un linguaggio, concetti e metafore semplici. Questa semplicità si estende anche alla progettazione effettiva dell'attività; i progetti XP sono spesso formulati senza considerare caratteristiche aggiuntive in futuro, considerandole estranee al rilascio del progetto. A volte questo fenomeno è noto come YAGNI, ovvero You Aren’t Gonna Need It.

XP non è la soluzione giusta per ogni progetto; è importante usare XP solo per progetti che non richiedono scalabilità o rielaborazioni significative.

SAFe è un insieme di principi e pratiche basati sul metodo di sviluppo lean-agile, su DevOps e sul pensiero sistemico. Lo Scaled Agile Framework (SAFe) è progettato (come suggerisce il nome) per scalare i framework Agile in organizzazioni di grandi dimensioni, per allineare più progetti e contribuire a garantire funzionalità e interoperabilità trasversali. Questo avviene principalmente attraverso una struttura che include roadmap di Planning Increment (PI).

Le attività all'interno di queste roadmap sono indicate in vari modi per aiutare a identificarle da una visione d'insieme. Le identificazioni includono "enabler" (dipendenze da altre attività), "epiche" (iniziative più ampie progettate per una specifica esigenza aziendale) e "storie" (funzionalità desiderata, dal punto di vista dell'utente o dell'azienda).

Il Disciplined Agile (DA) è considerato un insieme di principi, promesse e linee guida piuttosto che una metodologia completa. Si tratta di un approccio leggero, minimale e ibrido alla gestione dei programmi, che lascia grande libertà ai singoli membri del team.

Alcuni framework Agile, come Scrum e SAFe, includono metodologie e passaggi prescrittivi. Questa specificità può essere ottima per alcuni progetti, tuttavia il DA mira a fornire maggiore libertà e agilità ai membri del team. Il concetto di base consente alle persone di scegliere quali concetti e framework sono ideali per il loro particolare workflow. Scrum potrebbe funzionare per alcuni, ma non per altri, soprattutto in una prospettiva più ampia del programma. Il DA mette molto potere nelle mani dei singoli, il che lo rende ideale per progetti con membri del team altamente competenti, indipendenti e che già conoscono i concetti Agile di base.

Il Large-Scale Scrum, comunemente noto come LeSS, è una versione di Scrum appositamente progettata per team più grandi, o gruppi di team, rispetto a quelli per cui Scrum è stato creato. Sebbene LeSS preveda ancora sprint, riunioni quotidiane di Scrum e recensioni, ha alcune linee guida aggiuntive per garantire che i team più grandi raggiungano i propri obiettivi scalando Agile senza perdere la propria anima.

In LeSs, tutti i team lavorano su uno sprint comune anziché, come nella gestione dei progetti Agile, su sprint individuali pianificati dai singoli team. C'è anche un backlog condiviso, completo di tutte le attività necessarie per l'intero programma. E la pianificazione dello sprint prevede due tipi di riunioni: una riunione di pianificazione generale per tutti i team e poi riunioni individuali di pianificazione dello sprint per i singoli team.

Nexus è un framework simile a Scrum, con alcune aggiunte, sottrazioni e modifiche. La differenza principale è l'aggiunta del Nexus Integration Team, un gruppo separato di membri del team che fungono da allenatori. Il NIT include spesso membri dei team Scrum ed è responsabile della risoluzione dei blocchi, della fornitura di assistenza e del coaching dei team attraverso processi agili. Il NIT ha le sue riunioni, separate dallo Scrum quotidiano.

Sebbene Scrum sia un concetto fantastico per progetti specifici nell'ambito della gestione dei progetti Agile, quando parliamo di gestione dei programmi Agile, in realtà parliamo di team composti da team. È qui che entra in scena Scrum@Scale.

In Scrum@Scale, tutti i membri del team Agile sono considerati parte di un team Scrum intercambiabile, consentendo quindi la collaborazione interdisciplinare. Per aiutare con le sfide presentate da un programma più ampio in tempo reale, ci sono alcuni nuovi membri del team. Il Chief Product Owner (CPO) crea un backlog unico per tutti gli scrum e si coordina con i singoli product owner. Un ruolo simile è quello dello Scrum of Scrums Master, che coordina gli sforzi tra gli Scrum Master.

Lean è una metodologia volta a ridurre le inefficienze e a creare miglioramenti continui della qualità dei risultati finali dei progetti. Spesso viene considerata parte di Agile. Tuttavia, mentre Agile è una filosofia, Lean è una metodologia, con strumenti e linee guida più specifici. Lean si preoccupa principalmente di ridurre al minimo l'inefficienza e gli sprechi, mentre Agile si concentra principalmente sull'iterazione, il feedback e la flessibilità.

Lean si basa su cinque principi fondamentali:

• Identificare il valore: in sostanza, capire esattamente qual è l'obiettivo ed eliminare tutto ciò che non aggiunge valore.
  
  
• Mappare il flusso di valore: utilizzare uno strumento di gestione come le lavagne Kanban per visualizzare la roadmap del prodotto. Di fatto, visualizzare il piano del progetto dall'inizio alla fine.
  
  
• Creare un workflow: costruire il processo di produzione con passaggi specifici, cercando tutti gli ostacoli immaginabili. L'obiettivo è quello di creare un workflow che sia il più fluido possibile.
  
  
• Stabilire un sistema pull: un sistema pull si basa sulla creazione di nuove attività solo in base alla domanda dei clienti e solo quando i membri del team sono pronti per altro lavoro. Questo viene spesso fatto attraverso una coda delle attività.
  
  
• Migliorare continuamente: utilizzare una varietà di tecniche per creare continuamente valore e migliorare il prodotto. Queste potrebbero includere metodologie e filosofie come Lean Six Sigma e Kaizen o framework strutturati come Scrum, che incoraggiano test persistenti e cicli di feedback vantaggiosi.

La gestione dei programmi Agile, con le metodologie associate, offre molti modi per migliorare la realizzazione dei progetti.

• Specificità: iterando continuamente, i team Agile possono restringere esattamente ciò che il cliente desidera, piuttosto che tentare di migliorare ciecamente l'intero progetto.
  
  
• Efficienza: la gestione dei programmi Agile include principi volti a ridurre gli sprechi, la documentazione e la burocrazia.
  
  
• Versatilità: con tempi di risposta rapidi al feedback dei clienti, la versatilità è una parte fondamentale della gestione dei programmi Agile. I team Agile sanno, prima ancora dell'inizio di un progetto, che verranno apportate modifiche durante il processo.
  
  
• Morale del team: la gestione dei programmi Agile incoraggia l'apertura e la trasparenza e consente ai singoli membri del team di parlare apertamente. La gerarchia è meno importante dell'onestà e del lavoro di squadra dedicato.