Pianificazione AGILE, SCRUM & Kanban Vs Waterfall

Applicazioni di SCRUM e Kanban per cliente Chiarini & Associati

Nel 2001 un gruppo di 17 sviluppatori di software scrisse il manifesto AGILE inconsapevoli di lanciare 12 principi che sarebbero stati poi seguiti in tutto il mondo, anche al di fuori del settore dell’information technology. Il manifesto ed i suoi principi è consultabile nella sua forma originaria a questo indirizzo: https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/

Fra i valori fondamentali di questo manifesto vogliamo concentrarci su tre in particolare che veramente hanno fatto la differenza: “Collaborazione con il cliente piuttosto che negoziazione contrattuale” ; “Individui ed interazioni più importanti dei processi e strumenti” ; “rispondere al cambiamento piuttosto che seguire un piano“. Leggendo bene il manifesto AGILE è chiaro che molta ispirazione proviene dai principi e strumenti Giapponesi del Toyota Production System. Ma vediamo il perché gli strumenti e principi AGILE sono diventati importanti anche in altri settori.

Innanzitutto, partiamo con il notare che il Toyota Production System, Lean che sia, non è mai stato forte nell’ambito Design Management. Gli strumenti del Design Management classici quali il QFD, il Design To Cost, il Design For Assembly and Manufacturing, la FMEA, etc. da decenni continuano ad esistere senza influenza alcuna da parte del mondo Lean. Date un occhio a questo nostro ulteriore articolo per capirlo da soli. Secondo, gli uffici tecnici e l’R&D sono diventati sempre più “turbolenti” riducendo drasticamente il Time-To-Market. Il mercato è sempre più agile e pretende risposte sempre più veloci; la messa appunto dei vaccini Covid è stata la dimostrazione per tutti. Dimentichiamoci, quindi, sempre di più, ambiti da società di ingegneria vere e proprie, con progetti su più anni, step ben precisi, requisiti negoziati con il ciente all’inizio e poi “scolpiti nella roccia”.

Nel passato ci siamo abituati ai metodi cosiddetti di Waterfall o di Stage & Gate dove il progetto, dal punto di vista temporale, è diviso in specifiche e distinte fasi (stage) separate fra di loro da un punto di decisione (una milestone o gate). Praticamente il punto di decisione è in mano ad un project manager o ad un team di manager che decidono se andare avanti o meno con le altre fasi in base al raggiungimento di determinati obiettivi e risultati. Tipicamente questo approccio porta a lavorare “in serie” piuttosto che in parallelo a dispetto del cosiddetto concurrent engineering e della riduzione del Time-To-Market.

La figura sopra mostra, schematicamente un waterfall classico del settore manifatturiero dove ogni macro fase in arancio è divisa dalle restanti tramite una milestone in azzurro. Le fasi in questo classico approccio sono gestite con strumenti noti del Project Management quali il Gantt, il PERT ed il CPM. La figura sotto mostra una parte di un Gantt dove un’intera fase di analisi di fattibilità è scomposta in varie attività (Work Package) ed una milestone finale divide la fase dalla successiva in waterfall (progettazione e sviluppo prodotto).

Al contrario, il movimento AGILE ha puntato su strumenti più idonei al continuo e veloce cambiamento sia delle attività sia dei tempi. Lo SCRUM è stato il primo strumento adottato in ambito AGILE. Ideato negli anni ’90 da Jeff Sutherland e Ken Schwaber, deve il suo successo alle prime applicazioni in Yahoo e Google. Il nome SCRUM (mischia dal gioco del Rugby) in realtà è stato portato all’attenzione di tutti dal Giapponese Ikujiro Nonaka in un famoso articolo apparso su Harvard Business Review, anche se lo SCRUM di oggi è particolarmente diverso come strumento applicativo.

Lo strumento SCRUM si basa su:

  • Brevi periodi di progettazione/sviluppo (es. Sprint)
  • Personale coinvolto in team
  • Clienti/fornitori a stretto contatto
  • Regolare e frequente ridefinizione dei tasks e delle priorità
  • Rapidità e flessibilità nei cambiamenti
  • Visual Management dei tasks (es. Tabelloni Visual o SCRUM Board)

Il flusso di gestione dello SCRUM ha inizio, così come nella tradizionale progettazione, tramite la definizione della Mission del prodotto. Sostanzialmente un documento di input che avvia l’iter di progettazione e sviluppo prodotto/processo. In termini di Design Management, 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). Molte aziende che utilizzano lo strumento SCRUM di fatto non utilizzano diagrammi Gantt o al limite li 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.

Lo SCRUM partendo da una cornice generale di Mission prodotto, 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, dipendentemente da ciò che si progetta, può durare da una settimana ad un mese. Il team è 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”. La figura iniziale, in testa a questo articolo, rappresenta un esempio di tale board. 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 quali il mitico Trello che offre una opzione free con un numero limitato di utenti e documenti. Esistono altri costosi software proprietari che, onestamente, valgono molto meno delle formule a pagamento del buon Trello.  

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 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.

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.

L’alternativa, ancora più “agile” e più recente per la gestione dei progetti è lo strumento Kanban, di chiara ispirazione Toyota Production System. Nel Kanban non esiste la figura dello Scrum Master o del Product Owner così come le regole riguardanti la gestione dei vari meeting. L’artefatto centrale del Kanban è il tabellone visual che è chiamato tipicamente Kanban Board. Il Kanban Board è comunque impostato su un determinato orizzonte temporale simile allo Sprint. La differenza sostanziale fra i due strumenti è che nello SCRUM il team decide il numero di task da portare avanti basandosi sul tempo a disposizione durante lo Sprint; il primo giorno dello Sprint tutti i task si trovano nella prima colonna dei non iniziati per poi muoversi gradualmente verso le due colonne sulla destra. L’ultimo giorno tutto deve essere nell’ultima colonna dei task completati, dopodiché si riparte da sinistra verso destra con un nuovo Sprint ed una nuova board.  Analogamente ai cartellini kanban utilizzati in produzione, si può limitare il WIP di task (numero totale di task) che il team si impegna a prendere in carico. A tal scopo, nella tipica kanban board nella colonna in progress si indica tramite un numero quanti task si possono al massimo prendere in carico, limitando in questo modo il WIP e bilanciando al meglio i compiti del team.

Lo SCRUM non è così immediato come potrebbe sembrare. Chiarini & Associati offre corsi sullo SCRUM & Kanban e consulenza sul campo specifica. Per quest’ultima potete richiedere un contatto con i nostri consulenti tramite questo form.

Per maggiori dettagli sugli strumenti AGILE potete anche vedere i nostri video su youtube.

Lascia un commento