Kanban vs. Scrum: Confronto Dettagliato

Presentazione di Kanban e Scrum

Kanban è un metodo per ottimizzare e gestire i flussi di lavoro, che ti consente di visualizzare i processi su una Kanban board ed elaborare continuamente gli elementi di lavoro. I limiti di avanzamento in ogni fase del flusso di lavoro permettono al team di utilizzare in modo ottimale la propria capacità lavorativa. In altre parole, Kanban aiuta a ottimizzare il processo esistente basandosi su una serie di principi.  

Kanban ha 2 tipo di principi e 6 pratiche principali: 

Principi:

Pratiche: 

1. Visualizzare il flusso di lavoro 
2. Limitare il work in progress 
3. Gestire il flusso 
4. Rendere esplicite le politiche di processo 
5. Generare cicli di feedback 
6. Migliorare insieme

Scrum è uno strumento di lavoro altamente prescrittivo rispetto a Kanban. Scrum richiede una pianificazione dettagliata e restrittiva, con processi e ruoli predefiniti. 

Lo strumento di lavoro Scrum si basa su 3 pilastri:

1. Trasparenza 
2. Ispezione 
3. Adattamento

In Scrum, il lavoro viene diviso in task più piccoli che devono essere completati in un periodo di tempo predefinito (sprint). Inoltre, l'aggiunta di nuovi elementi di lavoro durante uno sprint è altamente scoraggiata, poiché fa sì che il nuovo lavoro attendi un nuovo sprint e si riduce quindi la capacità del team di reagire al cambiamento. 

Ora che conosciamo le differenze fondamentali tra i due concetti, scaviamo un po' più in profondità e vediamo le somiglianze e le differenze tra le soluzioni software Kanban e Scrum. O possiamo dire Kanban VS Sprint?

Kanban vs. Scrum – Ruoli e Responsabilità

Scrum implica l'introduzione o piuttosto l'assegnazione delle seguenti responsabilità: 

• Titolare del Prodotto 
• Master di Scrum 
• Team di Sviluppo 

Il Titolare del Prodotto è responsabile del backlog e dà la direzione al team. Il Master di Scrum detta le linee temporali, e il team elabora il lavoro che viene concordato durante la pianificazione Sprint. 

Kanban consente di mantenere la struttura corrente senza apportare modifiche drastiche. Inoltre, ci sono due ruoli Kanban che puoi implementare ma che non sono obbligatori: 

• Manager di Consegna del Servizio 
• Manager di Richiesta del Servizio 

Il Manager di Consegna del Servizio deve garantire che gli elementi di lavoro passino in modo efficiente attraverso il processo tenendo d'occhio la board e assistendo i membri del team quando c'è un problema. La persona che occupa questo ruolo deve facilitare il miglioramento continuo all'interno del team e suggerire attività di miglioramento. 

Il Manager di Richiesta del Servizio è di solito un ruolo secondario del team manager. Questa figura è responsabile della gestione delle politiche di processo e della coerenza, del miglioramento della corporate governance e della riduzione del rischio associato a un singolo individuo.

Pianificazione Scrum vs. Kanban

La pianificazione in Scrum avviene iterativamente all'inizio di ogni Sprint. Un meeting dedicato facilita il processo. Lì, il team di sviluppo, il proprietario del prodotto e Scrum Master si riuniscono per suddividere le storie degli utenti in task. 

Poi, si stima quanto tempo sarebbe necessario per concludere tutti gli elementi sulla lista. Una volta stretto l’accordo, il team si impegna a concludere tutti gli elementi nel prossimo Sprint e inizia a lavorare. Se c’è un cambiamento di priorità a metà sprint, lo Sprint attuale va interrotto e viene riavviato il processo di pianificazione. 

Il metodo Kanban si basa su un approccio probabilistico per la pianificazione, che è fondamentalmente una prognosi basata sui dati del flusso di lavoro passati. Deve essere basato su tipi di lavoro, dimensioni, classi di servizio e vari altri fattori legati al lavoro stesso e non tanto sul team che lo elabora. 

In Kanban, il tuo flusso di lavoro è continuo. Pertanto, è una pratica comune estendere la sezione Da Fare di una Kanban board aggiungendo colonne della tabella di marcia (roadmap) come "Questo mese", "Prossimo mese", ecc. per visualizzare il programma di lavoro. 

Di conseguenza, una volta raggiunta la capacità disponibile, il tuo team sposterà un nuovo elemento di lavoro su “In corso” in base alle sue priorità. Infine, quando conoscerai il tempo medio richiesto per completare un determinato task e quanti elementi di lavoro il tuo team termina a settimana, ad esempio, puoi pianificare le date di inizio e fine di ogni task.

L'impegno in Kanban e Scrum 

Kanban cerca di allungare l’impegno lavorativo il più a lungo possibile per garantire agilità e fornire valore in modo più frequente e al momento giusto. Poiché i limiti di WIP impediscono ai membri del team di lavorare su più task, tutti si impegnano a concludere ciò che hanno iniziato prima di passare a un nuovo lavoro. 

In Scrum, l'impegno di uno Sprint è sotto forma di previsione. Quando il team non anticipa la propria capacità con precisione, o sorgono problemi imprevisti, o lo sprint fallisce, gli eroici membri del team sono tenuti a finire tutto in tempo.

Indicatori di Prestazione Chiave Fondamentali

Per quanto riguarda Kanban VS Scrum, non si possono ignorare gli indicatori di prestazione chiave (KPI) che diventeranno parte della tua vita lavorativa nel momento in cui effettui una scelta. 

KPI di Scrum 

Scrum ha due KPI specifici su cui dovresti concentrarti: 

• Velocità 
• Capacità pianificata 

La velocità si basa sui punti della storia effettivi completati, che in genere è una media di tutti gli sprint precedenti. Viene utilizzata per pianificare il numero di elementi arretrati che il team dovrebbe portare nel prossimo sprint. 

La capacità è la quantità di disponibilità del team per lo sprint. Questa può variare in base ai membri del team in vacanza, malati, ecc. Il team dovrebbe prendere in considerazione la capacità di determinare quanti elementi di backlog del prodotto pianificare per uno sprint. Se ci si aspetta che la capacità sia inferiore per lo sprint, il team deve prendere in considerazione l'assunzione di un minor numero di elementi dal backlog del prodotto. Allo stesso modo, se sono stati aggiunti di recente più membri del team, il team potrebbe voler assumere più elementi dal backlog del prodotto. 

Per controllarli, di solito, i team Scrum implementano un paio di grafici: 

• Grafico Burndown 
• Grafico di Velocità 

Il grafico Burndown è una rappresentazione visiva di quanto lavoro resta da completare rispetto alla quantità di tempo rimanente nello Sprint. D'altra parte, i grafici di Velocità sono di solito sotto forma di istogrammi che mostrano le prestazioni passate del team Scrum. 

KPI di Kanban 

In Kanban, le metriche più importanti sono: 

• Lead time 
• Tempo di ciclo 

Detta in breve, il Lead time è il periodo tra la comparsa di una nuova task nel flusso di lavoro e la sua partenza finale dal sistema. Pensala così: il lead time inizia a ticchettare non appena ci si mette a lavorare su un task o su un ordine del cliente. 

Dall’altra parte, il tempo ciclo inizia quando il nuovo arrivo entra nella fase "in corso", e qualcuno sta effettivamente lavorando su di esso. 

Il tuo obiettivo è quello di ridurre i valori di ogni metrica (che di solito vengono misurati in giorni) nel tempo e mantenere un processo sempre efficiente. Per tenerli d'occhio, ci sono due grafici primari che puoi implementare: 

• Diagramma di flusso cumulativo (CFD) 
• Istogramma del tempo di ciclo 

Il CFD mostrerà quanto è stabile il tuo flusso e ti aiuterà a capire dove devi concentrarti per rendere il tuo processo più prevedibile. D'altra parte, l'istogramma del tempo di ciclo aiuta a monitorare le prestazioni del processo nel tempo. 

Riunioni ed Eventi

Come abbiamo già detto, su Kanban, le riunioni sono facoltative. Tuttavia, se decidi di implementarle, puoi scegliere tra 2 tipi di riunioni: cadenze a livello di team e cadenze orientate al servizio per mantenere il tuo team allineato e il flusso di lavoro costante: 

• Riunione giornaliere 
• Riunione di ricostituzione e impegno 
• Riunione di pianificazione delle consegne 
• Revisione sulla consegna di servizio 
• Revisione delle operazioni 
• Revisione del rischio 
• Revisione di strategia 

Scendere nei dettagli di ciascuna riunione va oltre lo scopo di questo articolo, ma è importante capire che è possibile combinare o saltare gli incontri che non trovi necessari. Ad esempio, noi organizziamo una Revisione sulla Consegna di Strategia e una Riunione di Ricostituzione e Impegno ogni settimana. Quindi, finché il tuo team è d’accordo, hai la libertà di improvvisare. 

Ogni ciclo di Sprint consiste in 4 tipi di riunioni obbligatorie: 

• Pianificazione dello Sprint 
• Scrum giornaliero 
• Revisione dello Sprint 
• Retrospettiva dello Sprint 

*Affinamento del Backlog (anche se non si tratta di una riunione ufficiale nella guida di Scrum, molti team si incontrano verso la fine del loro sprint attuale per ridefinire le priorità e dare le giuste dimensioni alle storie degli utenti). 

La pianificazione dello Sprint viene eseguita all'inizio di ogni Sprint. Se il ciclo di Sprint è di 1 mese, non è raro che questi incontri durino fino a 8 ore. Una volta che tutto è stato delegato e concordato, il team si riunisce ogni giorno per discutere sui progressi e condividere eventuali problemi che sono emersi. Alla fine di ogni sprint, il team e le parti interessate si incontrano per rivedere ciò che è stato raggiunto.  Infine, la Retrospettiva è dedicata ad analizzare cosa è stato eseguito sullo sprint precedente e cosa potrebbe essere migliorato nella prossima iterazione.

Kanban Board vs. Scrum Board

Le schede di gestione visiva vengono applicate sia in Kanban che in Scrum. Tuttavia, ci sono alcune differenze fondamentali tra loro. 

La Scrum board è un'estensione del backlog del prodotto. Quando il team si impegna per una determinata quantità di lavoro, viene aggiunto al backlog Scrum sul board, e quindi il team inizia a segnare i lavori in corso a proprio piacimento. L'obiettivo è quello di avere tutto nella colonna Fatto entro la fine dello Sprint. Logicamente, la board viene resettata dopo ogni iterazione. 

D'altra parte, la Kanban board è una mappa continua del processo del team. Quando la crei, devi avere come obiettivo la creazione di un sistema Kanban sostenibile che possa superare la prova del tempo. Su una Kanban board corretta vengono visualizzati i limiti WIP. L'obiettivo è quello di controllare la quantità di lavoro che entra e lascia il processo in modo da poter migliorare la velocità di consegna. 

Soluzioni Software Kanban vs. Scrum 

Proprio come il metodo Kanban in sé, Il software Kanban si basa fortemente sulle Kanban board, dove il tuo team mappa tutti i suoi processi e tutti gli elementi di lavoro. Ciò consente una visibilità senza precedenti e la piena trasparenza nei progressi. 

Ogni unità di lavoro diventa una card su una board con colonne che aiutano a comunicare visivamente le fasi di lavoro e le swimlane che potrebbero mostrare la priorità o il tipo di lavoro all'interno di ognuna. 

Scrum Board 

Il software Scrum viene utilizzato per concentrarsi maggiormente sulle interfacce in gran parte focalizzate sul testo, trasformando la funzione epica del lavoro in qualcosa di più simile alle cartelle con gli elementi al loro interno. Recentemente, i popolari strumenti Scrum hanno iniziato ad integrare board simili a quelle del software Kanban per visualizzare visivamente le fasi di lavoro e gli elementi stessi di lavoro. 

Tuttavia, su una Scrum board, il tuo team dovrebbe aggiungere tutte le storie (unità di lavoro) all'inizio di ogni sprint e mantenere la lista intatta fino alla fine di uno sprint. 

Esempio di basic Scrum board

Solo quando tutti gli elementi saranno completati lo sprint può essere considerato compiuto con successo, e può essere rivisto e avviato qualsiasi nuovo lavoro. Dopo ogni sprint, c’è una riunione retrospettiva, e la board dovrebbe essere resettata e preparata per un nuovo sprint. Inoltre, la Scrum board è di solito di proprietà di un team interfunzionale con tutte le competenze necessarie per il completamento dello sprint. 

Ultimo ma non meno importante, in Scrum, i limiti di work in progress vengono predefiniti per ogni sprint. Questo perché il team si impegna a svolgere un numero esatto di task durante lo sprint. Rispettivamente, il numero totale predefinito di task corrisponde al loro limite WIP. 

Kanban Board 

D'altra parte, una Kanban board non deve essere posseduta da uno specifico team interfunzionale. Kanban punta più sull'efficienza di un flusso di lavoro. Inoltre, in Kanban, i limiti WIP vengono impostati per ogni fase del flusso di lavoro. Questo eviterà i rallentamenti nel processo di lavoro, o se appaiono, li si può facilmente identificare e agire di conseguenza. 

In un ottimo strumento software di Kanban, le colonne sulla board vengono etichettate per mostrare gli stati del flusso di lavoro e impostare un limite WIP per ogni colonna, limitando la quantità massima di lavoro che può entrare in ogni fase.

Esempio di base Kanban board

Inoltre, su una Kanban board non vi sono restrizioni di tempo (come la lunghezza di sprint negli strumenti Scrum), e possono essere aggiunte nuove card (elementi di lavoro) in qualsiasi momento se i limiti WIP (che rappresentano la capacità ottimale del team) lo permettono. Pertanto, una Kanban board non ha bisogno di essere ripristinata periodicamente. 

In altre parole, gli strumenti software di Kanban sono basati su e supportano attivamente il flusso continuo di lavoro. Le Kanban board avanzate consentono inoltre di raccogliere dati per ogni pezzo di lavoro che appare sulla Kanban board e di utilizzarlo per individuare i rallentamenti, migliorare i tempi di ciclo e così via.

Monitorare e Analizzare il Work in Progress

Scrum burndown chart

Esiste un backlog in uno strumento software Scrum in cui vengono posizionate tutti i prossimi task per lo sprint. Per mantenere un ritmo di lavoro coerente, gli strumenti software Scrum sono dotati di un Grafico Burndown. 

Si tratta di un indicatore fondamentale delle prestazioni di un sistema Scrum che illustra quanto lavoro resta da completare nel progetto. 

Generalmente, i Grafici Burndown potrebbero essere una risorsa per avere una rapida panoramica dei progressi attuali rispetto al programma, ma se vi è una lacuna nel processo, è difficile da individuarla attraverso il grafico. Dopotutto, mostra semplicemente un riassunto del lavoro per tutti i membri del team. In altre parole, quando qualcosa va storto, si noterà solo un calo del lavoro totale. 

Tuttavia, dedurre il motivo di quel calo dipende solo da te. La maggior parte degli strumenti Scrum non ti aiuterà a scoprire il vero blocco del tuo progetto. 

D'altra parte, il software Kanban non ha un Grafico Burndown perché non vi è un periodo di tempo predefinito in cui un backlog dovrebbe essere completato. 

Invece, le Kanban board digitali di solito hanno un diagramma di flusso cumulativo, che raccoglie automaticamente i dati per ogni attività che entra nel flusso di lavoro. 

Diagramma di flusso cumulativo

Questo dato viene quindi utilizzato per analizzare il tempo di ciclo di tutti i compiti assegnati. 

Di conseguenza, i CFD possono mostrare entrambi gli elementi di lavoro insieme al tempo trascorso in fasi specifiche. Questo permette al team di vedere immediatamente quando una specifica fase di lavoro inizia a bloccare le card: più a lungo ogni card rimane in una determinata fase, più ampia sarà la sezione di questa fase sul diagramma. 

Ciò significa che è possibile individuare direttamente le parti problematiche del flusso di lavoro e agire di conseguenza invece di ricevere semplicemente un avviso sul fatto che le cose non stanno andando secondo il programma.

Stima del Lavoro

Nelle soluzioni del software Scrum, la stima è una parte essenziale del processo, e il team le calcola di solito durante un backlog di perfezionamento. Quindi, i team si assicurano che i loro elementi di lavoro abbiano le dimensioni corrette e danno priorità al prossimo Sprint. Infine, i team pianificano la propria capacità (su cosa possono iniziare a lavorare) durante la riunione di pianificazione dello sprint.

Lo scopo principale del processo di stima è quello di fornire una dimensione agli elementi di lavoro (di solito utilizzando la sequenza di Fibonacci) e determinare quanti di questi elementi possono essere eseguiti dal tuo team entro il periodo predefinito dello sprint. Il software basato su Scrum consente di assegnare punti a ogni storia e tenerne traccia. 

Il processo di stima è un'attività che richiede tempo e il cui valore è spesso discutibile. Questo perché i team raramente possono prevedono la quantità esatta di lavoro che può essere completato per uno sprint, e la stima iniziale spesso si rivela quindi sbagliata. 

In Kanban, si consiglia di suddividere i grandi compiti in task più piccoli. L'idea è quella di mantenere i task i più piccoli possibile senza diminuire il valore del prodotto finale consegnato. Questo aiuta durante l'esecuzione dei task e supporta un flusso più stabile, che è molto più affidabile rispetto alle continue raffiche di lavoro. 

Invece di stimare, Kanban preferisce la raccolta dei dati sui lead time passati, tempo di ciclo e di throughput che le ottime soluzioni software di Kanban utilizzano come base per prevedere il flusso di lavoro. Poiché utilizza dati storici di elementi di lavoro effettivi, l'analisi avanzata della Kanban board può prevedere la quantità di lavoro che può essere completata entro un periodo di tempo predefinito in futuro. 

Ad esempio, il modulo di analisi in Kanbanize presenta la simulazione di Monte Carlo. Questo strumento è in grado di fornire un numero statisticamente corretto approssimativo di task che il team potrebbe completare entro un determinato lasso di tempo. Tutto questo viene calcolato matematicamente in base alla storia del lavoro precedente di uno specifico team. 

A differenza degli strumenti Scrum, il software Kanban fornisce previsioni basate su dati storici e non basate su ipotesi inaffidabili del team. 

Kanban o Scrum. Chi Vince?

Sia Kanban che Scrum sono stati creati per aiutare i team ad aumentare la propria efficienza e produttività. 

Scegliere un vincitore, tuttavia, dipende individualmente da ogni team in quanto entrambi i tipi di strumenti hanno ovviamente un metodo o un contesto collegato ad essi. 

Il software Scrum è utile per i team che hanno deciso di sottoporsi a una trasformazione Scrum completa, con l'adozione di pratiche, framework e le responsabilità (ruoli) che implica. Il problema è che il software Scrum non ti aiuterà a diventare più bravo a stimare il lavoro ma renderà solo più facile documentare le tue stime. 

Il software Kanban, proprio come il metodo Kanban in sé, è decisamente più facile da adottare. Senza requisiti di processo o modifiche alla struttura del team, il software Kanban ti consente di iniziare con quello che hai al momento e costruirci su. 

Il software Kanban è, in un certo senso, molto più flessibile, adattabile a diversi ambienti e utile durante la visualizzazione e l'ottimizzazione di qualsiasi flusso di lavoro, indipendentemente dal contesto. 

In Summary

Sia Kanban che Scrum hanno i loro fan e storie di successo. Dal punto di vista dei software, le principali differenze tra Kanban e Scrum sono: 

• Il software Kanban si adatta in modo flessibile a qualsiasi team, mentre gli strumenti Scrum si basano su un determinato contesto lavorativo. 
• Kanban si basa sul miglioramento continuo e il suo software aiuta ad analizzare continuamente il flusso di lavoro. A sua volta, Scrum si basa sulla pianificazione dei punti storia e i suoi strumenti aiutano solo a misurare il tuo successo nell’aver previsto la stima. 
• Il software Kanban consente di limitare i WIP per mantenere la produttività del team bilanciando il lavoro con la capacità reale. Il software Scrum impedisce al team di iniziare o cambiare la coda di lavoro una volta iniziato lo sprint, aiutando a concentrarsi sugli elementi attuali ma rendendo impossibile adattarsi a qualsiasi cambiamento al di fuori degli sprint.