La progettazione di tipo Agile affonda le sue radici negli anni ’80, in particolare in un articolo di Hirotaka Takeuchi e Ikujiro Nonaka apparso su Harvard Business Review all’inizio del 1986. L’articolo dal titolo The new new product development game, affrontava i limiti di una pianificazione temporale portata avanti con fasi in serie e strumenti del project management tradizionali, in particolare nella progettazione aerospaziale. Gli autori dell’articolo evidenziavano come alcune aziende giapponesi particolarmente dinamiche quali Honda e Canon utilizzassero un approccio alla progettazione fatto di fasi in forte sovrapposizione e scambio di informazioni e dati.

Traendo spunto dal mondo del rugby, i progettisti assieme, formando uno SCRUM (traducibile dall’inglese all’italiano come mischia), si muovono velocemente passandosi di giocatore in giocatore la palla. L’aspetto fondamentale dello SCRUM è quello della gestione di progetti complessi per i quali è difficile prevedere quello che può succedere in termini di output. In particolare la complessità progettuale porta sovente al cambio repentino delle specifiche cliente, obiettivi aziendali, budget del progetto, tecnologie di utilizzo, tipologia di fornitori e così via. Utilizzando un termine abbastanza noto, possono cambiare velocemente i fabbisogni dei diversi stakeholder, in testa il cliente/mercato. Lo SCRUM, inoltre, aiuta le aziende a concentrarsi maggiormente sulle funzionalità e moduli del prodotto/servizio durante la progettazione e sviluppo. Nel 2001 un gruppo di sviluppatori, ricercatori e consulenti nell’ambito dello sviluppo software diedero vita alla Agile Alliance e al Manifesto per lo sviluppo software Agile.

Sostanzialmente il manifesto attraverso i suoi 12 principi mette in discussione i precedenti strumenti e principi del project management ed in particolare l’approccio waterfall nel quale blocchi di importanti tasks venivano gestiti in maniera molto strutturata da team con output molto precisi da ottenere. Questo classico approccio legato a progetti specifici nel settore delle costruzioni, aerospazio e certe commesse manifatturiere è ritenuto inadatto al mondo dinamico e mutevole dello sviluppo software. L’alleanza Agile non ha mai portato avanti in realtà strumenti alternativi a quelli del tradizionale project management. A quei tempi lo SCRUM era uno di quelli già utilizzati con successo in tale ambito, assieme ad altri meno noti. Lo SCRUM è diventato così lo strumento associato al mondo della progettazione e sviluppo Agile, in particolare nello sviluppo software. Lo SCRUM nasce però per gestire progetti anche in altri ambiti così come il movimento Agile ha nel tempo sperimentato altri strumenti di matrice Lean quali il Kanban.

Fasi ed artefatti dello SCRUM


Il flusso di gestione dello SCRUM ha inizio, così come nella tradizionale progettazione, tramite la definizione della Mission del prodotto. Questo documento contiene il cosa vuole il cliente o il mercato (requisiti funzionali, obiettivi di qualità ed affidabilità, etc.), quali sono gli eventuali vincoli di legge (ad esempio il rispetto di requisiti essenziali di sicurezza dati da direttive e norme armonizzate), vincoli di costi e temporali, considerazioni sulle tecnologie/processi di sviluppo prodotto, documentazione varia, etc. Sostanzialmente un documento di input che avvia l’iter di progettazione e sviluppo prodotto/processo.

In termini di DFSS, ad esempio, il documento può nascere da un primo utilizzo del QFD, che serve per l’appunto per catturare la voce del cliente, trasformandola in requisiti (cosa) e tecnologie/processi (come). A questo punto il tradizionale project management definirebbe una Work Breakdown Structure (WBS), ovvero un insieme di task che concorrono ad uno specifico obbiettivo. Alle WBS ed ai tasks, collegati fra loro, si assegnano per determinati periodi di tempo un responsabile e specifici output da ottenere (disegni, specifiche, distinte, calcoli, prototipi, process flow, piani di controllo, validazioni, etc.). Il tradizionale project management definisce inoltre milestone, ovvero momenti ben identificati della progettazione che, se non ottenuti, sovente bloccano l’avanzamento progetto. Ad esempio, la realizzazione di un prototipo sul quale effettuare controlli tramite un piano, l’ottenimento di una certificazione di tipo da parte di un ente terzo, oppure un’approvazione contrattuale intermedia a stati di avanzamento da parte del cliente.

Tramite lo SCRUM questo tradizionale approccio basato prevalentemente sullo sviluppo di un diagramma Gantt con relativa individuazione del cosiddetto cammino critico non è assolutamente necessario, anzi rappresenta proprio l’approccio maggiormente criticato dal movimento Agile. Molte aziende che utilizzano lo strumento SCRUM di fatto non utilizzano diagrammi Gantt, o al limite lo utilizzano come cornice per identificare le principali milestone e le relazioni macro fra le varie WBS, ma senza entrare nel dettaglio dei singoli task, la loro programmazione temporale e assegnazione risorse.

Seguendo il flusso della figura 1, lo SCRUM parte invece da una cornice generale di Mission prodotto e di milestone e produce un primo output o artefatto denominato Product Backlog. Quest’ultimo è un elenco di requisiti funzionali e non che il prodotto deve possedere per soddisfare la Mission. Quale secondo passo, una figura prevista dallo SCRUM denominata Product Owner assegna le priorità ai diversi requisiti del Product Backlog ed inizia una negoziazione con i SCRUM Team di progettazione e sviluppo ai quali assegna i requisiti secondo le priorità. Un aspetto interessante dello SCRUM è che le priorità assegnate ai requisiti possono cambiare dipendentemente dalle richieste dei vari stakeholders e la coda di requisiti dipende dalla velocità con cui i team riescono a smaltire i diversi Product Backlog. Questo aspetto differenzia particolarmente lo SCRUM dal tradizionale project management, dove spesso si assiste a vere e proprie rigidità temporali sui diversi WBS e task e i fra i vari team con il risultato di tempi totali più lunghi e risorse di progetto non perfettamente bilanciate.

Le attività vere e proprie di progettazione e sviluppo sono svolte dai team in unità temporali chiamate Sprint. Lo Sprint rappresenta un ulteriore artefatto e, dipendentemente da ciò che si progetta, può durare da una settimana ad un mese. All’inizio di ogni Sprint, il Product Owner negozia con il team a cui si assegna il requisito preso dal Product Backlog quanta parte del requisito (o di più requisiti) il team riuscirà a completare durante lo Sprint. La negoziazione avviene durante uno Sprint Planning Meeting che dura in media poche ore. Nella prima parte del meeting il Product Owner spiega nel dettaglio i requisiti del Product Backlog e le loro priorità e nella restante parte il team prende il requisito lo pianifica all’interno dei giorni dello Sprint, assegnando diversi task ai membri del team. Il team quindi è responsabile di quanto avviene durante lo Sprint in termini di output. Il team durante lo Sprint Planning Meeting può emettere un semplice programma chiamato Sprint Backlog nel quale, giorno dopo giorno, sono previsti i task da svolgere. Lo Sprint Backlog spesso dà luogo ad una board, un tabellone ‘visual’ nel quale compaiono i task suddivisi in task ‘da completare’, ‘in progress’ e ‘completati’. Tipicamente questo Sprint Board gestisce i task banalmente, tramite post-it colorati all’interno delle colonne del tabellone oppure tramite intuitivi software condivisi in rete.

Al termine di ogni giorno lavorativo il team si riunisce in un veloce meeting di circa 15 minuti chiamato Daily Scrum Meeting valutando:

  • Cosa è stato fatto realmente in termini di task durante la giornata e se ci sono degli scostamenti rispetto allo Sprint Backlog
  • Eventuali impedimenti nati
  • Cosa occorre fare nella successiva giornata
  • Aggiornamenti dei post-it (task) nello Sprint Board

Allo scadere dello Sprint, in una riunione veloce di max 4 ore denominata Sprint Review Meeting, il team presenta al Product Owner ed altri eventuali stakeholder ciò che realmente è stato progettato e sviluppato in termini di requisiti cercando di capire cosa fare nel successivo Sprint e valutando se sono cambiate le priorità nello Sprint Backlog.

fasi dello scrum
Figura 1: Fasi dello SCRUM

Ruoli nello SCRUM: lo SCRUM Master


Come visto nel paragrafo precedente, il Product Owner decide le priorità dei requisiti e negozia assieme allo SCRUM Team i requisiti da portare avanti nello Sprint Backlog. I team decidono invece autonomamente come scomporre il requisito in vari task creando uno Sprint Backlog e programmando di giorno in giorno i task.

Un’altra importante figura dello SCRUM è il cosiddetto SCRUM Master. Quest’ultimo è una figura che tipicamente necessita di un particolare training e funge per lo più da facilitatore. La sua autorità è, infatti, più che altro indiretta, nel senso che non impone scelte sui requisiti al Product Owner e quantomeno può mettere in discussione la programmazione quotidiana dei task fatta dal team.

Oltre a detenere il know-how sullo strumento, come sopra detto è un facilitatore, pertanto il suo compito principale è quello di risolvere gli eventuali impedimenti incontrati dal team e di mantenere viva l’attenzione sullo strumento stesso. Spesso, presi dal quotidiano e dalla velocità di gestione dello SCRUM, si dimentica quello che è un ulteriore vitale ruolo dello SCRUM Master, l’introduzione del miglioramento continuo nell’utilizzo dello strumento. A tal scopo, seguendo lo spirito del kaizen e del PDCA di Deming, lo SCRUM Master, al termine di ogni Sprint e prima di ogni Sprint Planning Meeting di apertura del successivo Sprint incontra il team. Durante questo Sprint Retrospective Meeting lo SCRUM Master discute assieme al team quanto si è imparato dalla gestione dello Sprint stesso cercando di evitare gli errori fatti ed enfatizzando gli aspetti positivi e quelle che possono diventare best practice.

Esempio di applicazione dello SCRUM

Il progetto in esempio è relativo alla progettazione di una centralina elettronica di comando per una poltrona elettrica. Il Product Owner emette l’elenco di requisiti del prodotto di cui in figura 2.

scrum - esempio di product backlog
Figura 2: Esempio di Product Backlog

Il Product Owner parte assegnando priorità massima alla progettazione della scheda elettronica. Tale requisito viene suddiviso nei vari task (il come) che servono per terminare il requisito. Data la tipologia di progettazione con un time to market medio di sei mesi il team assieme al Product Owner decide di utilizzare uno Sprint di due settimane lavorative. Tale orizzonte temporale permette di ottenere tipicamente incrementi di prodotto significativi, nonché sovente di completare un requisito o buona parte di esso. In maniera molto semplice il team durante lo Sprint Backlog Meeting ha suddiviso il primo requisito in due cosiddetti Product Backlog Item (prima colonna a sinistra). Questi ultimi permettono di dividere il requisito in item maggiormente gestibili dal team durante le due settimane di Sprint. Ogni Product Backlog Item si suddivide in vari task che il team si impegna a terminare entro la fine dello Sprint. Si fa notare come il numero di task legati al Product Backlog da portare avanti diventi una decisione interamente lasciata al team. Durante i Daily Scrum Meeting il team verifica, in ogni caso, quali task siano stati completati (post-it verdi nell’ultima colonna), quelli ancora in progress (post-it gialli) e quelli ancora da iniziare (post-it rossi).

Visual Board per il Daily Scrum Meeting
Figura 3: Visual Board per il Daily Scrum Meeting (fonte Chiarini & Associati)

Il Visual board di figura 3 aiuta visivamente il team nel monitorare l’avanzamento dei task durante i quindici giorni di Sprint. Le tre colonne (non iniziati – in progress – completati) sono di solito utilizzate in maniera semplice nel tabellone, ma non sono una prescrizione dello SCRUM. L’azienda dell’esempio ha scelto questa tradizionale suddivisione ma esistono numerose applicazioni con colonne del tutto personalizzate; ad esempio ‘Da fare’ – ‘Sviluppo’ – ‘Verifica’ – ‘Validati’ o altre a seconda del tipo di progettazione e prodotto/servizio.

Al termine del periodo stabilito dello Sprint il team nello Sprint Review Meeting presenta al Product Owner i risultati ottenuti in termini di incremento prodotto ovvero di completezza dei requisiti. In questo caso la progettazione della scheda deve essere completata assieme ai primi campioni del PCB (scheda) con montati i componenti elettronici. Questi sono gli impegni che il team ha negoziato con il Product Owner all’inizio dello Sprint. Tutto quanto non è completato in termini di task passa al successivo Sprint ed il Product Owner, chiaramente, monitora l’eventuale ritardo rispetto a specifiche milestone di progetto.