Ci sono progetti, come costruire un edificio o produrre un’automobile dopo una progettazione dettagliata, che operano in un contesto di informazioni note e definibili, caratterizzato da un basso livello di incertezza. In questi casi applicherai processi ben definiti che nel tempo hanno già dimostrato la loro efficacia.
Poi ci sono i progetti dove il livello di incertezza è alto, come sviluppare una nuova applicazione software da lanciare sul mercato o, più in generale, realizzare un prodotto o servizio innovativo. In questi casi è difficile, se non impossibile, determinare a priori tutti i requisiti e le caratteristiche di quello che devi realizzare, tenendo sotto controllo attraverso un processo strutturato tutte le varianti in corso d’opera.
I metodi Agili sono stati creati proprio per consertirti di affontare scenari di questo tipo, per esplorare la fattibilità di un risultato attraverso brevi cicli di lavoro e per adattarti in maniera tempestiva a situazioni che evolvono velocemente, sulla base di frequenti feedback dei committenti del progetto e degli utilizzatori del prodotto finale.
Puoi utilizzare framework e metodi Agili anche al di fuori dell’ambito dei progetti di sviluppo software, dove storicamente si sono evoluti. Tra questi il più popolare e diffuso è senza dubbio Scrum.
Scrum è un framework per la realizzazione di prodotti e servizi complessi e innovativi. Più che una specifica tecnica o processo puoi considerarlo come una cornice, all’interno della quale utilizzare strumenti e tecniche diversi.
Scrum ha una struttura leggera e, ovviamente,…agile. Per usare le parole dei suoi ideatori, Ken Schwaber e Jeff Sutherland, è “facile da comprendere ma difficile da padroneggiare”.
Quello di Scrum è un approccio empirico, dove prendi le tue decisioni in base a ciò che conosci. Spesso il problema dei progetti è proprio il fatto che all’inizio non ne sai molto di quel che devi realizzare. O meglio, credi di saperlo per poi scoprire in corso d’opera che le cose non stanno come pensavi.
Scrum utilizza due accorgimenti per diminuire i rischi derivanti dal fatto che le cose possono cambiare:
Iteratività => ti organizzi il lavoro in scatole temporali di durata fissa, chiamate iterazioni. All’inizio di ciascuna iterazione fisserai degli obiettivi realizzativi parziali e al termine verificherai il risultato conseguito. Acquisirai così man mano informazioni utili per pianificare il lavoro rimanente correggendo eventualmente il tiro.
Incrementalità => non costruisci il tuo prodotto/servizio tutto insieme, a valle di una unica grande e dettagliata fase di analisi e progettazione, ma in maniera progressiva, un po’ alla volta. In questo modo puoi far fronte meglio ad esigenze che potrebbero cambiare nel tempo.
È chiaro che una visione generale di ciò che vuoi realizzare dovrai averla sin dall’inizio. In altre parole, non puoi cominciare un progetto per sviluppare una app di prenotazione di ombrelloni e lettini, per poi rilasciare dopo tre mesi un software di gestione di paghe e stipendi.
L’approccio iterativo e incrementale ti consente però di controllare meglio i rischi, evitando di prendere troppe decisioni anticipate che potrebbero rivelarsi non efficaci nel prosieguo del lavoro, costringendoti a tornare sui tuoi passi. E se durante il progetto il cliente cambia idea? E se nel frattempo esce sul mercato una app simile alla tua, bruciandoti sul tempo e costringendoti ad aggiungere nuove funzionalità per essere competitivo quando la rilascerai?
Dicevamo che Scrum è semplice da comprendere. Le iterazioni vengono chiamate sprint e i suoi elementi fondamentali sono i ruoli, gli artefatti e le cerimonie.
In funzione del diverso coinvolgimento che gli attori hanno nel progetto, distinguiamo tra:
Scrum Team (ruoli core) => sono gli attori totalmente coinvolti nel progetto: Product Owner, Scrum Master, Development Team.
Altri Stakeholder (ruoli non core) => sono tutti coloro interessati al progetto: sponsor, cliente, utenti, etc.
Il Product Owner è colui che ha le competenze di dominio e la responsabilità del prodotto da realizzare, rappresenta la “voce del cliente” e garantisce che venga rilasciato il massimo valore di business ad ogni sprint.
Lo Scrum Master è il facilitatore del gruppo di lavoro, sia nell’applicazione della metodologia Scrum sia per garantire la focalizzazione al risultato.
Il Development Team è la squadra che sviluppa e rilascia gli incrementi del prodotto/servizio al termine di ogni sprint. E’ costituito da persone impegnate al 100% sul progetto, con competenze cross-funzionali e grandi capacità collaborative, di responsabilizzazione e di auto-organizzazione.
Ma come funziona Scrum? La figura alla pagina seguente ne riassume il flusso di lavoro.
Il ciclo Scrum inizia con una riunione degli stakeholder, durante la quale:
Viene creata la Vision del Progetto, accompagnata anche dal Budget e da un Charter, che ne definisce obiettivi e finalità.
Vengono pianificati i rilasci (release) del prodotto fissando i tempi.
Qui puoi notare un’altra importante differenza con la gestione di progetto tradizionale, dove all’inizio fissi e definisci dettagliatamente tutte le caratteristiche e funzionalità della tua app di prenotazione di ombrelloni, derivando poi di conseguenza tempi e costi (variabili). Con gli approcci Agili, e in particolare con Scrum, la prospettiva viene ribaltata. Fisserai a priori il budget (costi) e quando vuoi rilasciare la tua app sul mercato (tempi), identificando inizialmente una serie di funzionalità generali (il cosiddetto MVP, Minimun Viable Product) che però sarai pronto a dettagliare ed estendere in corso d’opera, anche e soprattutto in funzione dei feedback che riceverai da cliente e utenti.
Il Product Owner prepara un Product Backlog contenente l’elenco delle cosiddette User Story (e dei relativi criteri di accettazione) che esprimono in maniera formale ma sintetica i requisiti di business e di prodotto. Le User Story sono ordinate per priorità decrescente, in funzione del valore di business che ciascuna di esse apporta al cliente e agli utenti.
Dopo questo avvio, il progetto si sviluppa attraverso un certo numero di sprint di durata fissa (2-6 settimane, dipendente dalla durata e dal contesto di progetto) al termine dei quali sia dimostrabile un incremento di risultato sui deliverable finali.
All’inizio di ogni sprint, lo Scrum Team seleziona nel corso di uno Sprint Planning Meeting, le User Story che ritiene di poter completare nel corso del prossimo ciclo di lavoro (Sprint Backlog), rispettando l’ordine di priorità definito.
Durante lo sprint, il Development Team definisce in autonomia come distribuirsi le diverse attività ed ogni giorno si incontra per 15-20 minuti in apertura di giornata (Daily Standup Meeting), alla presenza dello Scrum Master, dove ciascun membro del team risponde alle seguenti 3 domande:
Cosa, del lavoro a me in carico, ho finito ieri?
Ci sono stati impedimenti di qualche tipo da segnalare?
Cosa prevedo di realizzare oggi?
In questo modo la pianificazione di dettaglio delle attività può essere aggiustata, con la eventuale redistribuzione di task tra i membri del team in funzione delle necessità.
Al termine dello sprint si tiene lo Sprint Review Meeting, durante il quale il Development Team presenta al Product Owner e agli altri stakeholder chiave il lavoro effettivamente “completato”, cioè l’incremento prodotto sul deliverable principale. Il Product Owner conferma l’incremento solo se soddisfa i criteri di accettazione concordati nel Product Backlog.
Il ciclo dello sprint termina con un Retrospect Sprint Meeting, nel quale il Development Team ripercorre assieme allo Scrum Master lo sprint appena concluso, individuando eventuali elementi di miglioramento per gli sprint successivi.
Come abbiamo già detto, puoi usare il framework Scrum in qualsiasi progetto con livelli di incertezza medio-alti e dinamiche di cambiamento rapide. Sono caratteristiche tipiche non solo dei progetti di sviluppo software, dove viene ormai adottato su larga scala anche in Italia dalle imprese ICT di qualsiasi dimensione, ma più in generale dei cosiddetti “Knowledge Projects”, ossia quei progetti dove la materia prima e il prodotto da realizzare sono di natura intellettuale e intangibile, tra cui attività di ricerca e progetti ad alto grado di innovazione.
L’evoluzione tecnologica e la trasformazione digitale stanno cambiando il business sempre più rapidamente. Per cavalcare il cambiamento senza farti travolgere non puoi semplicemente limitarti ad applicare un metodo o una tecnica agile, devi pensare e agire in modo agile.
Scrum può darti un utile schema di riferimento per farlo, per gestire progetti complessi adattandoti dinamicamente alle situazioni e realizzare prodotti più vicini alle esigenze degli utilizzatori in modo efficace e creativo.
Antonietta Fiorentino
Antonietta Fiorentino è imprenditrice e Transformation Leader. Bi-modal PMO nella digital transformation e per l’innovazione delle grandi, medie imprese. Per QRP è trainer e agile business consultant.
