Scrum “vs” Kanban: differenze, similitudini, come scegliere

Il meetup di mercoledì 16 Giugno 2021, organizzato e diretto dall’Agile Coach Manuele Piastra, ha visto come protagonisti i concetti Scrum e Kanban. La discussione si è concentrata in primis sulle caratteristiche di questi due framework, per poi andare a chiarire quando, perché e come migrare da uno all’altro.

Cos’è Scrum?

Scrum è un Agile framework interattivo che nasce nell’ambito del software developement. La sua caratteristica peculiare è proprio l’interattività – la metodologia madre di per sé non presuppone necessariamente interconnessione – ben evidenziata dalla struttura d’insieme del processo.

I ruoli di Scrum

Il termine “scrum” viene dal mondo del rugby, in quanto l’intero processo viene eseguito da un cross-functional e self-organising team su più fasi che si sovrappongono, ma che cerca di raggiungere l’obiettivo come un’unità di lavoro.

Al di sopra, lo scrum master riveste il ruolo di servant leader, di supporto al team nel miglioramento della performance.

Accanto, il product owner è la figura chiave all’interno dello Scrum team, una sorta di “regista”: lavora con il team di sviluppo; decide le priorità sul lavoro del team, cosa deve essere fatto, quali funzionalità deve avere un prodotto o un servizio e indica quando rilasciarlo sul mercato; è responsabile dell’ordine e della comunicazione del product backlog, sia nei confronti del team che degli stakeholders.

Gli “appuntamenti” in Scrum

Il tempo viene diviso in interazioni brevi, definite sprint, ma di durata fissa solitamente a due settimane (time boxing).

Lo sprint planning è il meeting iniziale per la messa a punto del programma delle successive due settimane e dal quale derivano due outcomes (lo sprint goal e lo sprint backlog).
Seguono due sprint finali:

• lo sprint review – una demo del prodotto ottenuto fino a quel momento, che vede la partecipazione degli stakeholder, i quali dovranno offrire un feedback generale;
• lo sprint retrospective, un ragionamento sul lavoro svolto nelle due settimane e su potenziali strategie di miglioramento (cambio di approccio, di comportamenti…), che vede la partecipazione del solo team intero.

Infine, il daily scrum (o stand up) è un allineamento giornaliero di 15 minuti tra sprint planning e sprint review, per ragionare sulla massimizzazione del progresso e del tempo giornaliero disponibile in base agli obiettivi dello sprint goal.

Gli artefatti in Scrum

Tutto parte da un’idea di prodotto che viene spezzettata in parti più piccole lavorabili singolarmente, le quali successivamente vengono inserite in una lista ordinata per priorità crescenti, il product backlog.

Dallo sprint planning iniziale, poi, risultano due outcomes:

• lo sprint goal, ossia l’obiettivo a due settimane (fase orientata al business e all’impatto);
• lo sprint backlog, cioè la porzione del product sul quale si lavorerà nelle due settimane seguenti (in base alle capacità del team).

Il product increment, infine, è un prodotto potenzialmente rilasciabile (per funzionalità, improvement…), ma per il quale deciderà il product owner.

Cos’è Kanban?

Nonostante figlio anche lui di Agile e Lean, non è considerato un framework, bensì un method (migliora ciò che già esiste). Inoltre, i principi Kanban, rispetto a quelli Scrum, sono molto più simili ai principi madre.

Ricordiamone alcuni:

• visualizzazione della rappresentazione del ciclo di lavoro attraverso l’utilizzo della kanban board – difatti, “Kanban” è la parola giapponese per “segnale visivo”;
• client-orientation;
• self organisation del team, ragione e risultato dell’alta flessibilità della metodologia;
• reviews abituali, nonché essenziali;
• ottimizzazione e gestione del flusso di lavoro, per evitare una stagnazione del software.

I ruoli in Kanban

Kanban si contraddistingue, come già accennato, per l’alta flessibilità nell’organizzazione del lavoro. I ruoli rivestiti all’interno del processo non sono imposti in maniera definitiva – come accade per Scrum – tanto da poter risultare apparentemente inesistenti.

Il team è lasciato più libero di auto-organizzarsi ed è caratterizzato da una visione d’insieme dell’avanzamento del progetto, da una consapevolezza equamente diffusa tra tutti i collaboratori.

Le figure chiave all’interno di Kanban sono due, con responsabilità simili a quelle di Scrum:

• il service delivery manager, che rimanda allo scrum master;
• il service request manager, simile al product owner.

Gli “appuntamenti” in Kanban

L’alta flessibilità si riscontra anche nella gestione del tempo. Mentre gli eventi Scrum sono tutti obbligatori, in Kanban sono recommended. Si sottolineano principalmente:

• lo stand up meeting iniziale e di breve durata – proprio perché si resta in piedi – , che si svolge davanti alla kanban board e che serve ad evidenziare le attività in corso, terminate, bloccate o da far partire;
• il replenishment board meeting, di riempimento finale della board.

Il tempo in Kanban ha una gestione ordinata. I time-frame sono ben definiti, il che permette una drastica riduzione del lavoro, e l’utilizzo della metrica cycle-time permette di misurare l’efficacia del lavoro, quindi il tempo impiegato dal team per concludere un progetto o un’attività (cycle-time basso = maggiore efficienza).

Le tecniche in Kanban

Un ulteriore elemento chiave in Kanban è il WIP (work in progress), essenziale per migliorare la prestazione del team; si tratta di una legge “little”, secondo cui la quantità di prodotto che esce da un sistema è inversamente proporzionale al numero di items in progress.

Di conseguenza, il WIP limit indica il numero massimo (non fisso) di kanban board utilizzabili dal team, con l’obiettivo di ottimizzare il lavoro di sviluppo e produzione.

Pro & Cons di Scrum e Kanban

Pro

Cons

Qualche consiglio…Attenzione!

1. Scrum ha troppi meeting! → Il limite della capacity x meeting risiede al 5%.
2. Kanban non è un’evoluzione di Scrum! → NON bisogna optare per il Kanban method, più dispendioso, se prima non si riescono ad ottenere risultati con il framework Scrum, più semplice e disciplinato.
3. Risolvete i problemi alla base, per non rischiare di trascinare questioni nel tempo e nel corso del processo!
4. Applicate un metodo scientifico! → Qualunque cambiamento si voglia ottenere, bisogna prima costruire una buona ipotesi di partenza, seguita da un time box per la valutazione dell’esperimento (es: dei meeting), per poi proseguire con un’analisi dei risultati.
5. Evitate troppi esperimenti! → Potrebbe risultare difficile individuare ulteriori falle di sistema.
6. Preferite metodi evolutivi, piuttosto che rivoluzionari! → Scrum è un framework; Kanban un metodo.

Scegli Scrum se…

• Si sta lavorando ad un prodotto con poche interruzioni durante il percorso;
• Si possiede un team che riesce a cogliere i benefici della struttura organizzativa;
• Si sta coinvolgendo un team con poca esperienza pregressa.

Scegli Kanban se…

• Si è in possesso di un team disciplinato;
• Si ha accesso a varie tipologie di servizio;
• Si hanno priorità in rapida evoluzione;
• Se si desidera massimizzare il flusso di lavoro, a prescindere da ciò che si sta utilizzando.