Scrum vs Kanban 2021: quale scegliere per la tua PMI

L’agile non è più una rivoluzione: è il modo in cui da almeno vent’anni si costruisce software in gran parte del mondo. Il Manifesto Agile compie nel 2021 il suo ventesimo anniversario, e nello stesso anno la versione aggiornata della Scrum Guide firmata da Jeff Sutherland e Ken Schwaber (novembre 2020) consolida un linguaggio comune che ormai usano product manager, engineering manager, PMO e perfino reparti marketing.

Per le PMI italiane, però, agile resta spesso un concetto sfumato: si parla di sprint, di backlog, di standup, ma sotto la superficie convivono pratiche scollegate, Scrum “di facciata” senza retrospettive serie, Kanban senza limiti di WIP, e team che oscillano fra burnout da cerimonie e caos da assenza di processo. Nel 2021, mentre il post-pandemia spinge la digitalizzazione e la lean delivery entra finalmente nel vocabolario degli amministratori delegati, la domanda diventa concreta: Scrum o Kanban? Quale dei due framework conviene davvero alla tua azienda fra 20 e 250 dipendenti, con uno o due team di sviluppo, vincoli di budget reali e clienti che pretendono risposte rapide?

In questa guida confrontiamo i due approcci dal punto di vista di una PMI tech o di un reparto IT interno: storia, ruoli, eventi, metriche, errori più comuni, un caso reale di transizione da Scrum a Kanban dopo il product-market fit, e una roadmap di adozione di 60 giorni step-by-step.

1. Manifesto Agile: vent’anni dopo, ancora attuale

Nel febbraio 2001, diciassette firmatari fra cui Kent Beck, Martin Fowler, Jeff Sutherland, Ken Schwaber, Mike Beedle e Alistair Cockburn si incontrano a Snowbird, nello Utah, e scrivono il Manifesto for Agile Software Development. Quattro valori, dodici principi, una pagina sola. Vent’anni dopo, nel 2021, quel testo è ancora la bussola di milioni di team in tutto il mondo.

I quattro valori del Manifesto Agile, da rileggere ogni volta che ci si perde nel processo:

• Gli individui e le interazioni più che i processi e gli strumenti.
• Il software funzionante più che la documentazione esaustiva.
• La collaborazione con il cliente più che la negoziazione dei contratti.
• Rispondere al cambiamento più che seguire un piano.

I dodici principi insistono su consegna frequente di valore, accoglienza del cambiamento, self-organizing team, ritmo sostenibile e semplicità. Sopra il Manifesto si sono costruiti framework alternativi: Heart of Agile di Alistair Cockburn, Modern Agile di Joshua Kerievsky, e gli approcci di scaling come SAFe 5.1 (giugno 2021), LeSS (Bas Vodde) e Disciplined Agile Delivery (PMI). Per la PMI media questi modelli sono spesso sovradimensionati: due o tre team ben funzionanti bastano e avanzano.

2. Cosa è Scrum, in concreto

Scrum nasce nei primi anni ’90: nel 1995 Jeff Sutherland, Ken Schwaber e poco dopo Mike Beedle formalizzano il framework alla conferenza OOPSLA. Da allora la Scrum Guide viene riscritta più volte; la versione attualmente in vigore nel 2021 è quella di novembre 2020, più snella (13 pagine) e più centrata sul concetto di prodotto piuttosto che sull’IT.

Scrum è un framework, non una metodologia: definisce ruoli, eventi e artefatti, ma non dice come scrivere codice né quali strumenti usare. Si fonda su tre pilastri – trasparenza, ispezione, adattamento – e cinque valori: commitment, focus, openness, respect, courage. L’unità di lavoro è lo Sprint: una finestra fissa da 1 a 4 settimane (tipicamente 2) in cui il team produce un incremento potenzialmente rilasciabile.

3. I tre ruoli di Scrum: Product Owner, Scrum Master, Developers

La Scrum Guide 2020 elimina la parola “team di sviluppo” e parla di Scrum Team unico, formato da tre accountability (responsabilità), non più “ruoli”. La sostanza, però, resta:

• Product Owner: è la singola voce del cliente. Possiede il Product Backlog, definisce l’ordine degli elementi (non solo la priorità), massimizza il valore prodotto dallo Scrum Team. In una PMI italiana è spesso il product manager, il fondatore di una startup, oppure il business analyst più esperto. Non è un proxy: è un decisore.
• Scrum Master: è un servant leader che lavora per l’efficacia dell’intero team. Insegna Scrum, rimuove impedimenti, facilita gli eventi, protegge il team dal rumore esterno. Non è un project manager travestito, e non assegna task. Nelle PMI è frequente che lo Scrum Master sia anche tech lead: la Scrum Guide non lo vieta, ma la doppia funzione richiede maturità.
• Developers: tutti coloro che si impegnano a creare l’Incremento. Il termine include programmatori, tester, designer, devops, DBA. La dimensione consigliata è tipicamente 10 persone o meno nello Scrum Team complessivo. Una squadra più grande va spezzata.

4. I cinque eventi Scrum: Sprint, Planning, Daily, Review, Retrospective

Tutti gli eventi sono timeboxed: hanno una durata massima, e quel limite si rispetta.

• Sprint (1-4 settimane): l’evento contenitore. Inizia subito dopo la chiusura del precedente, senza pause.
• Sprint Planning (max 8 ore per uno Sprint di 4 settimane, proporzionalmente meno per Sprint più corti): definisce il perché (Sprint Goal), il cosa (elementi del Product Backlog selezionati) e il come (piano iniziale).
• Daily Scrum (15 minuti, ogni giorno, stessa ora): è una riunione dei Developers per ispezionare i progressi verso lo Sprint Goal e adattare il piano. Non è uno status report al manager.
• Sprint Review (max 4 ore per Sprint di 4 settimane): si presenta l’Incremento agli stakeholder, si raccoglie feedback, si aggiorna il Product Backlog. Non è una demo da vetrina: è un momento di collaborazione.
• Sprint Retrospective (max 3 ore): il team ispeziona sé stesso – persone, interazioni, processi, strumenti – e identifica miglioramenti. È l’evento più sottovalutato e più potente.

5. I tre artefatti: Product Backlog, Sprint Backlog, Increment

Gli artefatti rappresentano lavoro o valore, e sono progettati per massimizzare la trasparenza. Nella Scrum Guide 2020 ciascuno ha un commitment esplicito:

• Product Backlog: elenco emergente, ordinato, di tutto ciò che serve per migliorare il prodotto. Il commitment è il Product Goal, l’obiettivo a lungo termine del prodotto.
• Sprint Backlog: lo Sprint Goal, gli elementi selezionati per lo Sprint e il piano per consegnarli. Il commitment è lo Sprint Goal.
• Increment: il passo concreto verso il Product Goal. Ogni Incremento è additivo, deve rispettare la Definition of Done, che è il commitment dell’Incremento stesso.

6. Cosa è Kanban: dalla Toyota a David Anderson

Kanban ha una doppia origine. Il termine giapponese significa cartellino o segnale visivo, ed è una pratica nata negli anni ’40-’50 nel Toyota Production System insieme al concetto di lean manufacturing: si producono solo i componenti necessari, nel momento in cui il processo a valle li richiede. La parola chiave è pull: il lavoro non viene spinto dall’alto, viene tirato dal sistema in base alla capacità reale.

L’applicazione moderna al lavoro della conoscenza arriva nei tardi anni 2000 con David J. Anderson, che codifica il Kanban Method nel libro “Kanban: Successful Evolutionary Change for Your Technology Business” del 2010. Anderson parte da un’idea radicalmente diversa da Scrum: Kanban non chiede di cambiare ruoli, non chiede di cambiare processo. Chiede di rendere visibile ciò che già si fa, limitare il lavoro in corso e migliorare in modo incrementale.

Sul piano teorico, Kanban si appoggia ai contributi di Mary e Tom Poppendieck (Lean Software Development, 2003) e al lavoro di Don Reinertsen: è più “ingegneristico”, meno “framework chiavi in mano”.

7. Le sei pratiche fondamentali di Kanban

Il Kanban Method codificato da David Anderson e ulteriormente sviluppato da Klaus Leopold e altri si fonda su sei pratiche e quattro principi guida (“inizia da dove sei”, “concorda di perseguire il cambiamento evolutivo”, “incoraggia la leadership a ogni livello”, “rispetta ruoli, responsabilità e titoli attuali”). Le sei pratiche:

1. Visualizza il workflow. Una board, fisica o digitale, con colonne che rappresentano gli stati del lavoro: To Do, In Progress, Review, Done, oppure tutte le tappe reali (Analisi, Dev, QA, Staging, Deploy). L’obiettivo è rendere visibile il flusso reale, non quello desiderato.
2. Limita il WIP (Work In Progress). Ogni colonna ha un numero massimo di item contemporanei. È la pratica più trasformativa: chi non ha mai imposto limiti di WIP non ha mai fatto Kanban davvero. Il limite forza il team a finire prima di iniziare nuovo lavoro, e fa emergere i colli di bottiglia.
3. Gestisci il flusso. Misura come il lavoro scorre attraverso il sistema, identifica blocchi e attese, riduci i tempi di attraversamento.
4. Rendi esplicite le policy. Cosa significa “pronto per il dev”? Quando un task può passare dalla review al done? Niente regole tribali non scritte.
5. Implementa feedback loops. Riunioni regolari di replenishment (riempimento della coda), delivery planning, retrospettive. Cadenze fisse, contenuti adattivi.
6. Migliora collaborativamente, evolvi sperimentalmente, usando modelli e metodo scientifico.

8. Le metriche Kanban: lead time, cycle time, throughput, WIP, CFD

Le metriche Kanban descrivono il flusso, non la velocità individuale. Sono quattro le metriche chiave più una visualizzazione:

• Lead time: tempo che intercorre fra la richiesta del cliente e la consegna del valore. È la metrica più importante per chi paga.
• Cycle time: tempo che intercorre fra l’inizio del lavoro su un item e la sua consegna. È la metrica più importante per chi lavora.
• Throughput: numero di item completati in un’unità di tempo (al giorno, alla settimana). Non confonderlo con la velocity di Scrum: il throughput conta item, non punti.
• WIP: numero di item in corso in un dato momento. La Legge di Little ricorda che lead time medio = WIP medio / throughput medio. Ridurre il WIP riduce il lead time. È matematica, non opinione.
• CFD (Cumulative Flow Diagram): grafico che mostra l’accumulo di item in ciascuno stato del workflow nel tempo. Permette di vedere a colpo d’occhio dove si formano i colli di bottiglia (le bande che si allargano), dove il lavoro si blocca, dove la capacità è sprecata.

9. Scrum vs Kanban: il confronto pratico per una PMI

I due approcci coesistono pacificamente nello stesso settore da quindici anni. La domanda non è “quale è meglio” ma “quale è meglio per questo team in questo momento”. Confronto sintetico:

Una PMI che sviluppa un SaaS nuovo, con un product manager dedicato e un team da 4-6 persone, di solito ha più benefici da Scrum: gli Sprint danno cadenza, le retro maturano la cultura, il PO impara a fare priorità. Una PMI che gestisce manutenzione di un gestionale interno, con flusso irregolare di richieste e bug dal supporto, sta meglio con Kanban: nessuno ti chiede di rifiutare un’emergenza solo perché lo Sprint è già pianificato.

10. Scrumban: l’ibrido pragmatico

Coniato nel 2008 da Corey Ladas, lo Scrumban è la combinazione di un team che già praticava Scrum e che adotta progressivamente le tecniche Kanban: limiti di WIP, board visiva continua, replenishment on-demand al posto del rigido Sprint Planning. Nelle PMI italiane è spesso il punto di arrivo naturale dopo 6-12 mesi di Scrum: si tengono Daily, Review e Retro, ma si abbandona la pianificazione “tutto-o-niente” dello Sprint Planning.

Non è “Scrum diluito” né “Kanban con cerimonie”: è una scelta consapevole, e molti team più maturi vi convergono in modo naturale. La trappola è chiamare Scrumban un sistema in cui si è solo abbandonata la disciplina senza adottare le metriche di Kanban: in quel caso si è tornati al caos pre-agile.

11. Tool Agile 2021: Jira, Azure DevOps, GitHub Projects e gli altri

Lo strumento giusto dipende dal contesto, ma nel 2021 il panorama è abbastanza definito.

• Jira Software (Atlassian, dal 2002, evoluto enormemente nelle ultime cinque versioni) è ancora lo standard de facto per team di sviluppo medio-grandi. Supporta nativamente Scrum, Kanban e Scrumban, ha un buon ecosistema di plugin (Marketplace), prezzo abbordabile per team fino a 10 utenti (free plan rilasciato nel 2020). Va bene per chi ha bisogno di workflow personalizzati, ma può diventare pesante.
• Azure DevOps (Microsoft, rebrandizzato nel 2018 dall’ex VSTS) è la scelta naturale per chi è nell’ecosistema .NET o Microsoft 365. Integra repo Git, pipeline CI/CD, test plan e board agile in un unico prodotto. Forte sul lato enterprise, integrazione SSO Azure AD nativa.
• GitHub Projects (versione “Projects beta”, rilasciata da GitHub a metà 2021) è il nuovo arrivato. Più leggero di Jira, integrato con issue e pull request, board Kanban-style con custom field. Non ha ancora la profondità di Jira per Scrum, ma per team che vivono dentro GitHub è un’opzione interessante.
• Asana: ottimo per team cross-funzionali con timeline e dipendenze; Trello (Atlassian dal 2017) per il Kanban “puro” più semplice; Monday.com molto visuale e personalizzabile; ClickUp ricco di feature (“one app to replace them all”); Notion come hub centrale per documenti e backlog leggeri.
• Linear (lanciato nel 2019): minimal, veloce, orientato a team di sviluppo software puri; cresce molto fra startup product-led. Pivotal Tracker resta usato da team XP. Altri nomi noti del 2021: Targetprocess per scaling, Shortcut (ex Clubhouse), ProductBoard per il product management.

Consiglio operativo per PMI: non scegliere il tool prima di aver scelto il metodo. Un buon foglio di calcolo, una lavagna fisica o un board su Trello sono sufficienti per i primi tre mesi. Lo strumento sofisticato si introduce quando hai un processo da supportare, non per “sembrare” più agile.

12. Errori comuni nell’adozione di Scrum e Kanban

Vent’anni di pratiche agile hanno generato anche venti anni di cattivi esempi. I più ricorrenti nelle PMI italiane:

• Scrum “fake”: Daily che diventano status report al manager, Sprint Planning che si trasforma in dettatura di task, Retrospettive saltate “perché c’è troppo da fare”. Senza retrospettive non c’è miglioramento; senza miglioramento non c’è agile.
• Velocity come KPI di performance: appena la velocity diventa un obiettivo, smette di essere una misura. Le persone gonfiano le stime, e il dato non vale più nulla.
• Kanban senza limiti di WIP: una board colorata con cento post-it in “In Progress” non è Kanban, è ansia istituzionalizzata. Senza limiti di WIP non si misura nulla.
• Project manager travestito da Scrum Master: il PM “classico” che assegna task non sta facendo Scrum Mastering.
• Mancanza di buy-in del top management: agile fallisce quando l’AD continua a chiedere “data certa per il rilascio della v2.0 con tutte le feature”. O cambia il management, o l’agile resta una pantomima.
• Sprint Goal vago o Kanban board che non si guarda mai: senza uno Sprint Goal chiaro, lo Sprint è solo un elenco di task; se non si usa la board, non è Kanban.

13. Caso reale: una PMI tech romana passa da Scrum a Kanban dopo il PMF

Una PMI tech romana che opera nel SaaS B2B per agenzie immobiliari, 11 dipendenti di cui 6 nel team di prodotto. Nel 2018-2020 adotta Scrum: Sprint di 2 settimane, Product Owner co-founder, Scrum Master a rotazione. Funziona: velocity stabile a 38-42 story point, due deploy in produzione per Sprint, 50 primi clienti paganti.

A inizio 2021, superati i 200 clienti e raggiunto un PMF chiaro, i clienti chiedono modifiche tattiche urgenti, il customer success apre ticket che non si incastrano negli Sprint, i rilasci ogni 14 giorni diventano un collo di bottiglia, le Retro ripetono sempre gli stessi action item. Il team decide di transitare a Kanban in otto settimane:

1. Board Kanban su Jira: Backlog → Ready → Dev → Code Review → QA → Staging → Done; WIP limit 2 per persona, max 3 in Code Review, max 2 in QA.
2. Sprint Planning rigido sostituito da backlog refinement + replenishment ogni martedì, 45 minuti; Daily orientato al flusso; Retro mensile.
3. Deploy continuo: da 2 deploy per Sprint a 8 deploy a settimana entro tre mesi.
4. La velocity viene sostituita dal lead time mediano (sceso da 11 a 6 giorni) e dal throughput settimanale (stabilizzato a 14 item/settimana).

Dopo sei mesi i clienti riportano percezione di reattività più alta, il team riduce gli straordinari, il CFD mostra colli di bottiglia prima invisibili (la Code Review si rivela il punto critico). Scrum è stato il framework giusto per la fase di esplorazione, Kanban è stato il framework giusto per la fase di scaling operativo: cambiare framework dopo il PMF non è un fallimento, è maturità.

14. Roadmap di adozione Agile in 60 giorni per una PMI

Per una PMI che parte oggi (dicembre 2021) e vuole impostare in modo serio uno fra Scrum e Kanban senza dover assumere consulenti esterni, ecco una roadmap step-by-step di 60 giorni, divisa in quattro blocchi da due settimane.

Sessanta giorni non bastano a diventare un’organizzazione “agile matura”, ma bastano per superare l’inerzia iniziale e cominciare a misurare progresso reale. Da lì in poi è miglioramento continuo: il vero scopo di Scrum, di Kanban e di tutto l’agile.

15. FAQ — Domande frequenti su Scrum e Kanban