Ottobre 10, 2019 - di Marco Imperato
Le due metodologie Agile: Scrum e Kanban. Quale scegliere e perchè.
Nel post precedente abbiamo esplorato i principi di base dell’Agile, abbiamo capito cosa è l’Agile, ma soprattutto cosa non è. In questo articolo affrontiamo la “concretizzazione” dei principi dell’Agile nelle due metodologie più diffuse, ovvero Scrum e Kanban, esplorandone le principali differenze.
L’obiettivo di questo post non è quello di andare nei singoli dettagli dei due framework, ma di dare una visione d’insieme, evidenziare le principali differenze e aiutarti a scegliere quello più adatto a te nel caso in cui fossi alla ricerca di un modo per organizzare il tuo team di prodotto.
Se invece vuoi approfondire la metodologia Agile Scrum in tutti i suoi dettagli ti consiglio di leggere questo post che abbiamo scritto da poco: Agile scrum, la metodologia, cosa è e a cosa serve.
I contenuti che troverai:
- Come funziona il metodo Waterfall
- Differenza tra approccio Agile e Waterfall
- Il product Backlog
- Scrum e Kanban: dove sono diversi
- Daily Scrum: il meeting Giornaliero
- Sprint Review e Retrospective: il miglioramento continuo
- Scrum e Kanban, la differenza principale
- Quale tra i due è meglio?
- Un consiglio molto importante
Per capire ancora meglio come funzionano le due metodologie è utile vedere brevemente come funziona il processo tradizionale di sviluppo software, chiamato anche Waterfall.
Se vuoi scaricare il post che stai leggendo in PDF e accedere ad oltre 70 pagine su Agile, Team Cross-funzionale, User Story, Backlog, etc. ti presento Agile Starter Kit, una cartella condivisa su Google Drive pensata per gli eroi come te che stanno iniziando il proprio viaggio nel Digital Product Management.
Come funziona il metodo Waterfall
Il termine stesso Waterfall sintetizza perfettamente la metodologia classica.
In una cascata (waterfall), infatti, l’acqua cade sempre dall’alto verso il basso e così funziona nello sviluppo software Waterfall:
- Il responsabile di prodotto definisce i requisiti di tutto il progetto
- Il team di sviluppo realizza il progetto per intero
- Il progetto viene consegnato al customer tutto in una volta
Tutto va nella stessa direzione. Dall’alto verso il basso. Sempre
Differenza tra approccio Agile e Waterfall
Secondo i principi dell’Agile, come abbiamo visto nel post precedente, il software viene consegnato al customer in piccoli pezzi che incrementano il valore del software progressivamente, inoltre il feedback dal customer viene preso costantemente in considerazione e diventa parte essenziale del ciclo di sviluppo.
E’ proprio compito del responsabile di prodotto, chiamato Product Owner, prendere i feedback del customer e dei vari stakeholder, combinarli insieme dentro quello che viene chiamato Product Backlog.
Il Product Backlog: la lista ordinata di tutto quel che bisogna fare
Il Product Backlog è la lista prioritizzata di tutto ciò che si vorrebbe fare (occhio a queste due parole!) all’interno del progetto. Qui sta una delle prime intuizioni semplicissime, ma geniali, dei due metodi.
Il fatto che un Item sia in backlog non vuol dire che verrà sicuramente affrontato, sviluppato e rilasciato.
Per esperienza, posso dirti il contrario: solitamente una piccola parte del backlog è quella che vede effettivamente la luce.
Questa lista può essere composta da user stories, ovvero lo sviluppo di una funzionalità dal punto di vista dell’utente (capirai meglio nel prossimo post), Task tecnici, Bug o Knowledge Task (discovery, spike, etc.).
Alcune caratteristiche del Product Backlog:
- Ogni Item in Backlog deve aggiungere valore all’utente finale
- Il Backlog deve essere ordinato e prioritizzato
- Il Backlog è un documento vivente. Il processo di revisione e modifica giornaliera del Backlog da parte del Product Owner si chiama Backlog Grooming
- I dettagli di ogni Item dipendono tipicamente dalla loro posizione sul Backlog: in alto tanti dettagli, in basso pochi dettagli.
Puoi approfondire qui:
Agile Scum vs Kanban: dove sono diversi
Quello che accade tra il product backlog, ovvero la mega-lista di cose da fare, e il customer, ovvero l’utente che userà il tuo prodotto, è quello che distingue Scrum da Kanban.
Ogni metodo ha le sue routine, rituali e definizione di ruoli.
In entrambi c’è una persona che aiuta il Product Owner e il team di sviluppo a mantenere le buone abitudini. Nello Scrum questo ruolo è chiamato Scrum Master, in Kanban, se c’è (non sempre è presente), è chiamato Agile Coach.
Entrambi i framework vengono definiti: Pull Systems, capirai dopo il perché di questa definizione, ma per semplicità diremo che i Pull Systems fanno in modo che gli Item passino dal Backlog al Customer nel minor tempo possibile e aiutano il team ad individuare eventuali colli di bottiglia.
Focus su Agile Scrum
Lo Scrum è Tempo-Centrico. Tutto ruota intorno alla più piccola unità di tempo in cui è possibile rilasciare software di valore al customer. Questa unità minima di tempo viene chiamata Sprint la cui durata varia dalla 2 alle 4 settimane solitamente.
La Sprint e lo Sprint Planning
La Sprint inizia con un meeting detto Sprint Planning, diretto dallo scrum master a cui partecipano Product Owner e Team di prodotto. Team e PO Insieme selezionano item ad alta priorità dal Backlog che il team pensa di potersi impegnare a rilasciare all’interno della sprint. Ogni Item viene spacchettato alla sua unità più semplice e viene pesato in termini di “tempo di sviluppo necessario”.
Stai molto attento a questa frase! Per quanto sembri banale è davvero rivoluzionaria rispetto al metodo Waterfall. Rivediamola e commentiamola:
A – “Team e PO Insieme selezionano item ad alta priorità dal Backlog”: Il PO lavora con il team, Insieme!
B -“Il team pensa di potersi impegnare a rilasciare all’interno della sprint”: è il team stesso a scegliere cosa portare in sviluppo e si impegna a rispettare la deadline. Non c’è un blocco di feature che viene “calato dall’alto”.
Qui è facile vedere come senza rispettare i principi cardine dell’Agile sia impossibile seguire questo metodo.
Fiducia e Ownership del team sono la base.
Il Pull nella metodologia Agile Scrum
Questa parte è il Pull di cui stavamo parlando prima, ovvero gli item vengono “tirati” dal backlog e non “pushati” da qualcun altro.
Per l’intera durata della sprint il team si focalizza soltanto sull’obiettivo di sprint e sugli item nello sprint backlog. Solo su quello! Non è possibile aggiungere altro. Nel mondo dei sogni… nella realtà è una battaglia contro Bug, nuove priorità, cambi in corsa, etc.
La bravura del Product Owner e dello Scrum Master sta proprio nel lasciar libero il team di fare focus sulla sprint e di tararsi sull’obiettivo di sprint.
Per tracciare i progressi si usa una board chiamata Scrum Board, Agile Board o per fare un po’ di casino Kanban Board.
Di solito ci sono 4 colonne: To Do, Doing o Progress, Test o QA, Done. La premessa di tutto è che queste due metodologie non sono prescrittive per cui ogni team poi può decidere di aggiungere o rimuovere colonne in base alle proprie esigenze.
Il Movimento ideale degli Item sulla scrumboard è da sinistra verso destra, se il movimento è al contrario c’è qualcosa che non va.
Il Daily Scrum: il meeting giornaliero
Ogni giorno c’è un meeting chiamato Scrum Meeting, Daily Scrum o semplicemente Scrum in cui l’obiettivo è quello di muoversi avanti verso la parte di done, della board. Durante lo Scrum Meeting viene discusso il progress, vengono spostati i Task e vengono identificati gli impedimenti.
La durata massima è di 15 minuti.
Ogni persona nel meeting solitamente risponde a tre domande:
- Cosa ho fatto ieri?
- Quali sono i task di oggi?
- Che impedimenti non mi permettono di andare avanti?
Lo Scrum master coordina il Daily Scrum.
Rilascio e Sprint Retrospective in Agile Scrum
Alla fine della sprint il lavoro completato viene impacchettato e rilasciato.
Tutti gli item incompleti ritornano al product backlog. Anche qui mega-rivoluzione: niente crocifissioni in sala mensa o mega “prediconi” di fine release se qualcosa non viene rilasciato.
Si parte sempre dalla fiducia nel team per cui se qualcosa non va come previsto c’è sicuramente un motivo valido.
Tra i principi di Agile c’è proprio quello del miglioramento del modo di lavorare tra una sprint e l’altra. Tipicamente non si arriva a completare la sprint perchè non si conosce la velocity (ovvero il quantitativo di “cose” che il team riesce a completare dentro una data sprint), o perchè sono entrati nuovi task a gambatesa.
Questo è il motivo per cui a fine Sprint c’è sempre una Retrospective ovvero un’analisi di: quello che è andato bene, quello che è andato male, quello che può essere migliorato. L’obiettivo della retrospective è proprio quello di assicurare che la prossima sprint sia più efficace ed efficiente (Ti ricordi il principio 3 di Agile?) di quella passata.
[Puoi approfondire la Sprint Retrospective da questo post di Donato Barbagallo, Product Manager & Agile Coach in Oval:
L’importanza della demo nella sprint review
Il completamento della Sprint viene sancito dalla sprint review, ovvero una dimostrazione delle funzionalità aggiunte agli stakeholders. Lo so può sembrarti uno spreco di tempo, visto che l’importante è dare valore all’utente, ma come saprai se lo stai già facendo o come imparerai se stai cominciando, la comunicazione intra e inter-Team è decisiva.
Spesso in un’azienda che cresce e va veloce la principale causa di casini è la comunicazione gestita in modo approssimativo.
Se vuoi approfondire su Agile Scrum, puoi farlo da qui:
Focus Su Agile kanban
Nel Kanban tante cose sono simili come il product backlog, la board, il PO, il meeting giornaliero, retrospective, demo per stakeholder.
La principale differenza tra Agile Scrum e Kanban
La principale differenza è che nel Kanban non esistono le sprint. Il processo di sviluppo è continuo.
Il Pull system funziona in modo diverso, ovvero con un limite sul numero di elementi inseribili in ogni singola colonna della board, questo limite viene chiamato WIP Limit, ovvero Work in Progress Limit.
Il Work In progress limit in Agile Kanban
Avere un limite su ogni colonna ti assicura che gli Item si spostino velocemente da una colonna all’altra, visto che questo è l’unico modo per inserire nuovi Item.
Per esempio con un team di 3 sviluppatori e un PO, il team decide che il limite è 5 elementi contemporanei sulla stessa colonna. Nel giorno di avvio dei lavori vengono spostati 5 elementi sulla colonna “To do”.
Successivamente sarà possibile spostare un altro elemento dal Backlog alla Board solo nel momento in cui viene liberato uno spazio nella colonna “To Do”, perché un elemento si è spostato in avanti nella colonna “Doing”. Se ciò non accade non si potranno aggiungere altri elementi.
La regola di base è che ogni volta che uno spazio in una colonna viene liberata, solo in quel momento e non prima, è possibile muovere un altro item nella colonna successiva. Questo è il Pull nel Kanban
Non c’è un giorno specifico per rilasciare, il team decide quando farlo. Di solito si aspetta che una feature sia completata o che ci sia qualcosa che aggiunga valore all’utente finale.
Non c’è uno sprint planning, né una metodologia specifica per spostare item dal backlog alla To Do list.
Il Kanban è molto meno rigido e il team è lasciato libero di auto-organizzarsi.
Se nello Scrum il Tempo è la priorità, nel Kanban di solito è lo Scope ad essere prioritario. Per farla ancora più semplice, nello Scrum hai solo quella sprint a disposizione per raggiungere l’obiettivo quindi il numero di cose che devi fare è variabile, perché il tempo è fisso.
In kanban è il contrario, visto che ti puoi muovere in avanti solo al completamento di tutti gli elementi il tempo deve essere variabile.
Agile Scrum vs Kanban: qual è meglio?
Non esiste un metodo migliore dell’altro. Solitamente chi ti dà una risposta netta su uno dei due è perchè ne ha usato prevalentemente uno.
Per quanto mi riguarda, con i miei team, abbiamo usato molto di più Scrum che Kanban, questo per un paio di ragioni.
Scrum è Tempo-centrico, io ho sempre lavorato su prodotti proprietari con un discreto grado di innovazione. Quindi spesso non sapevamo se una cosa avrebbe funzionato o meno per cui il tempo era la componente decisiva. Prima rilasciavamo, prima avevamo informazioni, prima sapevamo se le cose su cui stavamo lavorando avevano senso.
Kanban l’ho usato quasi esclusivamente su prodotti già maturi in cui facevamo quella che viene chiamata “manutenzione evolutiva”, ovvero ci si assicurava che il servizio/prodotto non andasse mai giù, si dedicava tanto tempo al customer support, avevo meno risorse a disposizione e le nuove feature venivano tirate fuori da palesi richieste degli utenti. Di base non era una corsa contro il tempo, come tutto il resto.
Mi è capitato di usare Kanban anche quando ho sviluppato prodotti per conto di terzi, in un ruolo più di project manager che di product. Kanban è molto più semplice da comprendere per un cliente che è fuori dalla tua azienda, è più elastico e allo stesso tempo lo costringe ad essere più disciplinato fissando un WIP limit, senza bisogno di incasinarsi in sprint planning, sprint backlog, etc.
Un consiglio molto importante
Per chiudere ti dò un ultimo consiglio, che dovrai tenere sempre a mente, soprattuto se stai iniziando adesso.
La cosa più importante che devi sempre tenere a mente è che entrambe le metodologie possono essere modificate e migliorate in base alle tue esigenze, allo stadio di maturità del prodotto e dell’azienda.
Devi considerarle come delle basi di riferimento da modificare e adattare in base alle tue esigenze. Oggi esiste anche un ibrido chiamato Scrumban, che non ti spiego semplicemente perchè non l’ho mai usato.
Studia tanto, leggi, confrontati e approfondisci ma, a meno che tu non si una fase di scaling importante in un’azienda ormai consolidata, non impiegare mesi per trovare l’organizzazione perfetta, soprattutto se stai iniziando adesso, perchè dopo pochi mesi sarai costretto a ri-organizzarti in base alle sopraggiunte novità.
Cerca di essere Lean/Agile anche nell’applicazione dei principi Agile :): definisci degli obiettivi, applica un framework, cerca di capire cosa crea progresso e cosa invece rallenta, poi in base alle evidenze decidi come procedere.
Update 20-01-2020: Se ti interessa l’argomento abbiamo dedicato un intero post al Mindset Agile.
Lo trovi qui > Agile Mindset: cosa è, esempi reali e casi pratici.
5 replies on “Le due metodologie Agile: Scrum e Kanban. Quale scegliere e perchè.”
Domenico Damato
Complimenti, ottimo articolo!
Chap Luz
Ottimo articolo, ma contiene un’imprecisione di fondo: Scrum e Kanban non sono le metodologie Agile più diffuse, sono framework metodologici Agile, esclusivamente dedicati al Project Management (non gli unici). Scrum e Kanban sono oggi molto diffuse, ma è improprio dire che siano le più diffuse.
Questo perché non si tratta di metodologie complete, ma di framework, ovvero contenitori, che rappresentano l’1% delle pratiche, ma non dicono nulla sulle buone pratiche ingegneristiche da utilizzare, che sono l’effettivo contenuto del progetto, il 99% delle pratiche. Per chiarire questo concetto, quando pensiamo a User Stories, Planning Games, Iterative Development, Velocity, dobbiamo essere consapevoli che queste pratiche non sono parte di Scrum, come molti erroneamente credono, sono pratiche importate nel framework Scrum ma provenienti da un’altra metodologia Agile che è XP (eXtreme Programming), la quale a differenza di Scrum e Kanban ha al suo interno robuste pratiche ingegneristiche come CI/CD, TDD/ATDD, CRC, Pair Programming, ecc. Pertanto, è XP ad essere la pratica Agile più utilizzata, anche se spesso solo in parte, anche se spesso sotto forma di pratiche importate in altri framework, anche se in modo inconsapevole da parte dei loro fruitori.
Fabrizio
Se tutti gli startupper veri condividessero queste informazioni l’Italia sarebbe un paese più digitalmente più avanzato.
Marco Imperato
Grazie Fabrizio! Il problema principale credo sia la consapevolezza, bisognerebbe partire da quella. In Italia siamo abbastanza indietro quindi credo che tutti prenderemo consapevolezza di quello che serve per fare start-up (sul serio) tra qualche anno.
Chap Luz
Al momento mi trovo a far fronte ad alcuni progetti Agile dove la metodologia che il cliente chiede di applicare è Kanban (ma potrebbe essere Scrum è irrilevante), salvo poi fare richieste tipicamente legate a una visione Waterfall. Ad esempio: <>, <>, <>, <>, <>. Per chi sviluppa SW oggi la difficoltà vera non è tanto l’usare Scrum, Kanban, Scrumban, o altro, sono i fraintendimenti sull’Agile, sono le ipotesi non supportate su cosa significhi Agile, per i team e per il business, che possono compromettere pesantemente il progetto e in qualche caso farlo fallire, il che è esattamente l’opposto di quello che le metodologie Agile si prefiggono.