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.

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.

I contenuti che troverai:

  1. Come funziona il metodo Waterfall
  2. Differenza tra approccio Agile e Waterfall
  3. Il product Backlog
  4. Scrum e Kanban: dove sono diversi
  5. Daily Scrum: il meeting Giornaliero
  6. Sprint Review e Retrospective: il miglioramento continuo
  7. Scrum e Kanban, la differenza principale
  8. Quale tra i due è meglio?
  9. 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. 

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:

  1. Il responsabile di prodotto definisce i requisiti di tutto il progetto
  2. Il team di sviluppo realizza il progetto per intero
  3. Il progetto viene consegnato al customer tutto in una volta

Tutto va nella stessa direzione. Dall’alto verso il basso. Sempre

metodo sviluppo software waterfall
Il processo di Sviluppo Waterfall

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.

Scrum vs kanban

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.
Il Product Backlog
Il Product Backlog

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.

Flusso di Lavoro in Agile Scrum
Flusso di Lavoro in Scrum

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:

  1. Cosa ho fatto ieri?
  2. Quali sono i task di oggi?
  3. 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.

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.

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.

Flusso di lavoro in Kanban
Flusso di Lavoro in Kanban

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.

1 reply on “ Le due metodologie Agile: Scrum e Kanban. Quale scegliere e perchè. ”
Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *