{"id":1646,"date":"2021-12-03T09:54:00","date_gmt":"2021-12-03T08:54:00","guid":{"rendered":"https:\/\/brentasoft.com\/blog\/?p=1646"},"modified":"2026-06-04T11:16:02","modified_gmt":"2026-06-04T09:16:02","slug":"scrum-vs-kanban-pmi-2021","status":"publish","type":"post","link":"https:\/\/brentasoft.com\/blog\/scrum-vs-kanban-pmi-2021\/","title":{"rendered":"Scrum vs Kanban 2021: quale scegliere per la tua PMI"},"content":{"rendered":"

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

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

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\u00f9 comuni, un caso reale di transizione da Scrum<\/strong> a Kanban<\/strong> dopo il product-market fit<\/em>, e una roadmap di adozione di 60 giorni<\/strong> step-by-step.<\/p>\n

\n

TL;DR<\/h3>\n
    \n
  • Scrum<\/strong> \u00e8 un framework prescrittivo a timebox<\/em>: Sprint<\/strong> da 1-4 settimane, tre ruoli (Product Owner<\/strong>, Scrum Master<\/strong>, Developers<\/strong>), cinque eventi, tre artefatti. Ottimo per prodotti nuovi e team che devono imparare a consegnare in modo iterativo.<\/li>\n
  • Kanban<\/strong> \u00e8 un metodo evolutivo a flusso continuo: visualizza il lavoro, limita il WIP<\/strong>, misura lead time<\/strong> e throughput<\/strong>. Ideale per team di manutenzione, supporto, operations o prodotti maturi con flusso di richieste imprevedibile.<\/li>\n
  • Per una PMI<\/strong> tipica, la scelta dipende meno dalla “moda” e pi\u00f9 dalla prevedibilit\u00e0 del lavoro<\/strong>: se le richieste arrivano in modo irregolare, Kanban<\/strong> ha meno attriti; se serve disciplina e ritmo, Scrum<\/strong> aiuta a costruirla.<\/li>\n
  • Scrumban<\/strong> \u00e8 un compromesso pragmatico, non un fallimento.<\/li>\n<\/ul>\n<\/div>\n

    1. Manifesto Agile: vent’anni dopo, ancora attuale<\/h2>\n

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

    I quattro valori del Manifesto Agile<\/strong>, da rileggere ogni volta che ci si perde nel processo:<\/p>\n

      \n
    • Gli individui e le interazioni<\/strong> pi\u00f9 che i processi e gli strumenti.<\/li>\n
    • Il software funzionante<\/strong> pi\u00f9 che la documentazione esaustiva.<\/li>\n
    • La collaborazione con il cliente<\/strong> pi\u00f9 che la negoziazione dei contratti.<\/li>\n
    • Rispondere al cambiamento<\/strong> pi\u00f9 che seguire un piano.<\/li>\n<\/ul>\n

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

      2. Cosa \u00e8 Scrum, in concreto<\/h2>\n

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

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

      \n\"Post-it
      Il backlog visualizzato sui post-it: pratica nata in Scrum, diventata universale.<\/figcaption><\/figure>\n

      3. I tre ruoli di Scrum: Product Owner, Scrum Master, Developers<\/h2>\n

      La Scrum Guide 2020<\/strong> elimina la parola “team di sviluppo” e parla di Scrum Team<\/em> unico, formato da tre accountability<\/strong> (responsabilit\u00e0), non pi\u00f9 “ruoli”. La sostanza, per\u00f2, resta:<\/p>\n

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

        4. I cinque eventi Scrum: Sprint, Planning, Daily, Review, Retrospective<\/h2>\n

        Tutti gli eventi sono timeboxed<\/em>: hanno una durata massima, e quel limite si rispetta.<\/p>\n

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

          5. I tre artefatti: Product Backlog, Sprint Backlog, Increment<\/h2>\n

          Gli artefatti rappresentano lavoro o valore, e sono progettati per massimizzare la trasparenza<\/em>. Nella Scrum Guide 2020<\/strong> ciascuno ha un commitment<\/em> esplicito:<\/p>\n

            \n
          • Product Backlog<\/strong>: elenco emergente, ordinato, di tutto ci\u00f2 che serve per migliorare il prodotto. Il commitment \u00e8 il Product Goal<\/em>, l’obiettivo a lungo termine del prodotto.<\/li>\n
          • Sprint Backlog<\/strong>: lo Sprint Goal, gli elementi selezionati per lo Sprint e il piano per consegnarli. Il commitment \u00e8 lo Sprint Goal<\/em>.<\/li>\n
          • Increment<\/strong>: il passo concreto verso il Product Goal. Ogni Incremento \u00e8 additivo, deve rispettare la Definition of Done<\/strong>, che \u00e8 il commitment dell’Incremento stesso.<\/li>\n<\/ul>\n

            6. Cosa \u00e8 Kanban: dalla Toyota a David Anderson<\/h2>\n

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

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

            Sul piano teorico, Kanban<\/strong> si appoggia ai contributi di Mary e Tom Poppendieck<\/strong> (Lean Software Development<\/em>, 2003<\/strong>) e al lavoro di Don Reinertsen<\/strong>: \u00e8 pi\u00f9 “ingegneristico”, meno “framework chiavi in mano”.<\/p>\n

            \n\"Grafico
            In Kanban le metriche di flusso sostituiscono la velocity: lead time, cycle time, throughput.<\/figcaption><\/figure>\n

            7. Le sei pratiche fondamentali di Kanban<\/h2>\n

            Il Kanban Method<\/strong> codificato da David Anderson<\/strong> e ulteriormente sviluppato da Klaus Leopold<\/strong> 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\u00e0 e titoli attuali”). Le sei pratiche:<\/p>\n

              \n
            1. Visualizza il workflow<\/strong>. Una board, fisica o digitale, con colonne che rappresentano gli stati del lavoro: To Do<\/em>, In Progress<\/em>, Review<\/em>, Done<\/em>, oppure tutte le tappe reali (Analisi, Dev, QA, Staging, Deploy). L’obiettivo \u00e8 rendere visibile il flusso reale<\/em>, non quello desiderato.<\/li>\n
            2. Limita il WIP<\/strong> (Work In Progress). Ogni colonna ha un numero massimo di item contemporanei. \u00c8 la pratica pi\u00f9 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.<\/li>\n
            3. Gestisci il flusso<\/strong>. Misura come il lavoro scorre attraverso il sistema, identifica blocchi e attese, riduci i tempi di attraversamento.<\/li>\n
            4. Rendi esplicite le policy<\/strong>. Cosa significa “pronto per il dev”? Quando un task pu\u00f2 passare dalla review al done? Niente regole tribali non scritte.<\/li>\n
            5. Implementa feedback loops<\/strong>. Riunioni regolari di replenishment (riempimento della coda), delivery planning, retrospettive. Cadenze fisse, contenuti adattivi.<\/li>\n
            6. Migliora collaborativamente<\/strong>, evolvi sperimentalmente, usando modelli e metodo scientifico.<\/li>\n<\/ol>\n

              8. Le metriche Kanban: lead time, cycle time, throughput, WIP, CFD<\/h2>\n

              Le metriche Kanban descrivono il flusso<\/em>, non la velocit\u00e0 individuale<\/em>. Sono quattro le metriche chiave pi\u00f9 una visualizzazione:<\/p>\n

                \n
              • Lead time<\/strong>: tempo che intercorre fra la richiesta del cliente e la consegna del valore. \u00c8 la metrica pi\u00f9 importante per chi paga.<\/li>\n
              • Cycle time<\/strong>: tempo che intercorre fra l’inizio del lavoro su un item e la sua consegna. \u00c8 la metrica pi\u00f9 importante per chi lavora.<\/li>\n
              • Throughput<\/strong>: numero di item completati in un’unit\u00e0 di tempo (al giorno, alla settimana). Non confonderlo con la velocity di Scrum: il throughput conta item, non punti.<\/li>\n
              • WIP<\/strong>: numero di item in corso in un dato momento. La Legge di Little<\/em> ricorda che lead time medio = WIP medio \/ throughput medio. Ridurre il WIP riduce il lead time. \u00c8 matematica, non opinione.<\/li>\n
              • CFD<\/strong> (Cumulative Flow Diagram<\/strong>): 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\u00e0 \u00e8 sprecata.<\/li>\n<\/ul>\n

                9. Scrum vs Kanban: il confronto pratico per una PMI<\/h2>\n

                I due approcci coesistono pacificamente nello stesso settore da quindici anni. La domanda non \u00e8 “quale \u00e8 meglio” ma “quale \u00e8 meglio per questo<\/em> team in questo<\/em> momento”. Confronto sintetico:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
                Aspetto<\/th>\nScrum<\/th>\nKanban<\/th>\n<\/tr>\n<\/thead>\n
                Cadenza<\/strong><\/td>\nSprint timeboxed (1-4 settimane)<\/td>\nFlusso continuo, nessuna iterazione obbligatoria<\/td>\n<\/tr>\n
                Ruoli<\/strong><\/td>\nProduct Owner, Scrum Master, Developers<\/td>\nNessuno imposto; si parte dai ruoli esistenti<\/td>\n<\/tr>\n
                Planning<\/strong><\/td>\nSprint Planning a inizio ciclo<\/td>\nReplenishment on-demand quando si libera capacit\u00e0<\/td>\n<\/tr>\n
                Cambiamenti in corsa<\/strong><\/td>\nSprint Goal protetto; cambi in mezzo allo Sprint vanno evitati<\/td>\nPull system: il prossimo item si pesca quando si \u00e8 pronti<\/td>\n<\/tr>\n
                Metrica chiave<\/strong><\/td>\nVelocity (story point per Sprint)<\/td>\nLead time, throughput, WIP<\/td>\n<\/tr>\n
                Curva di apprendimento<\/strong><\/td>\nRipida ma codificata (Scrum Guide)<\/td>\nPi\u00f9 dolce; serve disciplina su WIP<\/td>\n<\/tr>\n
                Caso d’uso ideale<\/strong><\/td>\nNuovo prodotto, esplorazione, team junior<\/td>\nManutenzione, supporto, ops, prodotti maturi<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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

                10. Scrumban: l’ibrido pragmatico<\/h2>\n

                Coniato nel 2008 da Corey Ladas<\/strong>, lo Scrumban<\/strong> \u00e8 la combinazione di un team che gi\u00e0 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 \u00e8 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.<\/p>\n

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

                11. Tool Agile 2021: Jira, Azure DevOps, GitHub Projects e gli altri<\/h2>\n

                Lo strumento giusto dipende dal contesto, ma nel 2021<\/strong> il panorama \u00e8 abbastanza definito.<\/p>\n

                  \n
                • Jira Software<\/strong> (Atlassian, dal 2002, evoluto enormemente nelle ultime cinque versioni) \u00e8 ancora lo standard de facto per team di sviluppo medio-grandi. Supporta nativamente Scrum<\/strong>, Kanban<\/strong> 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\u00f2 diventare pesante.<\/li>\n
                • Azure DevOps<\/strong> (Microsoft, rebrandizzato nel 2018 dall’ex VSTS) \u00e8 la scelta naturale per chi \u00e8 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.<\/li>\n
                • GitHub Projects<\/strong> (versione “Projects beta”, rilasciata da GitHub a met\u00e0 2021<\/strong>) \u00e8 il nuovo arrivato. Pi\u00f9 leggero di Jira, integrato con issue e pull request, board Kanban-style con custom field. Non ha ancora la profondit\u00e0 di Jira per Scrum, ma per team che vivono dentro GitHub \u00e8 un’opzione interessante.<\/li>\n
                • Asana<\/strong>: ottimo per team cross-funzionali con timeline e dipendenze; Trello<\/strong> (Atlassian dal 2017) per il Kanban “puro” pi\u00f9 semplice; Monday.com<\/strong> molto visuale e personalizzabile; ClickUp<\/strong> ricco di feature (“one app to replace them all”); Notion<\/strong> come hub centrale per documenti e backlog leggeri.<\/li>\n
                • Linear<\/strong> (lanciato nel 2019<\/strong>): minimal, veloce, orientato a team di sviluppo software puri; cresce molto fra startup product-led. Pivotal Tracker<\/strong> resta usato da team XP. Altri nomi noti del 2021: Targetprocess<\/strong> per scaling, Shortcut<\/strong> (ex Clubhouse), ProductBoard<\/strong> per il product management.<\/li>\n<\/ul>\n

                  Consiglio operativo per PMI: non scegliere il tool prima di aver scelto il metodo<\/strong>. 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\u00f9 agile.<\/p>\n

                  12. Errori comuni nell’adozione di Scrum e Kanban<\/h2>\n

                  Vent’anni di pratiche agile hanno generato anche venti anni di cattivi esempi. I pi\u00f9 ricorrenti nelle PMI italiane:<\/p>\n

                    \n
                  • Scrum “fake”<\/strong>: Daily che diventano status report al manager, Sprint Planning che si trasforma in dettatura di task, Retrospettive saltate “perch\u00e9 c’\u00e8 troppo da fare”. Senza retrospettive non c’\u00e8 miglioramento; senza miglioramento non c’\u00e8 agile.<\/li>\n
                  • Velocity come KPI di performance<\/strong>: appena la velocity diventa un obiettivo, smette di essere una misura. Le persone gonfiano le stime, e il dato non vale pi\u00f9 nulla.<\/li>\n
                  • Kanban senza limiti di WIP<\/strong>: una board colorata con cento post-it in “In Progress” non \u00e8 Kanban, \u00e8 ansia istituzionalizzata. Senza limiti di WIP non si misura nulla.<\/li>\n
                  • Project manager travestito da Scrum Master<\/strong>: il PM “classico” che assegna task non sta facendo Scrum Mastering.<\/li>\n
                  • Mancanza di buy-in del top management<\/strong>: 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.<\/li>\n
                  • Sprint Goal vago o Kanban board che non si guarda mai<\/strong>: senza uno Sprint Goal chiaro, lo Sprint \u00e8 solo un elenco di task; se non si usa la board, non \u00e8 Kanban.<\/li>\n<\/ul>\n

                    13. Caso reale: una PMI tech romana passa da Scrum a Kanban dopo il PMF<\/h2>\n

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

                    A inizio 2021<\/strong>, 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<\/strong> in otto settimane<\/strong>:<\/p>\n

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

                      Dopo sei mesi<\/strong> i clienti riportano percezione di reattivit\u00e0 pi\u00f9 alta, il team riduce gli straordinari, il CFD mostra colli di bottiglia prima invisibili (la Code Review si rivela il punto critico). Scrum \u00e8 stato il framework giusto per la fase di esplorazione<\/strong>, Kanban \u00e8 stato il framework giusto per la fase di scaling operativo<\/strong>: cambiare framework dopo il PMF non \u00e8 un fallimento, \u00e8 maturit\u00e0.<\/p>\n

                      \n\"Sessione
                      La retrospettiva \u00e8 il momento pi\u00f9 potente di entrambi i framework. Senza retro, non c’\u00e8 agile.<\/figcaption><\/figure>\n

                      14. Roadmap di adozione Agile in 60 giorni per una PMI<\/h2>\n

                      Per una PMI che parte oggi (dicembre 2021<\/strong>) 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<\/strong>, divisa in quattro blocchi da due settimane.<\/p>\n

                      \n

                      Roadmap 60 giorni: come adottare Scrum o Kanban in PMI<\/h3>\n

                      Settimane 1-2 (giorni 1-14) \u2013 Assessment e scelta del framework<\/strong><\/p>\n

                        \n
                      • Mappa il flusso di lavoro attuale del team: da dove arrivano le richieste, chi le prioritizza, chi le esegue.<\/li>\n
                      • Misura grezzamente il lead time<\/strong> degli ultimi 20 task chiusi: aiuta a capire dove sei.<\/li>\n
                      • Scegli framework: se hai un prodotto nuovo da costruire e un PO disponibile, parti da Scrum<\/strong>. Se gestisci manutenzione o supporto, parti da Kanban<\/strong>.<\/li>\n
                      • Forma il team (anche solo con la Scrum Guide gratuita o “Kanban from the Inside” di Mike Burrows).<\/li>\n<\/ul>\n

                        Settimane 3-4 (giorni 15-28) \u2013 Setup tool e prime cerimonie<\/strong><\/p>\n

                          \n
                        • Configura board su Jira<\/strong>, Azure DevOps<\/strong> o Trello<\/strong> con colonne semplici (max 5-6).<\/li>\n
                        • Importa i task pendenti, scrivi una Definition of Done<\/strong> condivisa in 30 minuti di workshop.<\/li>\n
                        • Se Scrum: parti con Sprint di 2 settimane<\/strong>, fai il primo Planning, fissa i Daily.<\/li>\n
                        • Se Kanban: imposta i limiti di WIP (regola pratica: 1.5 \u00d7 numero di persone nella colonna Dev).<\/li>\n<\/ul>\n

                          Settimane 5-6 (giorni 29-42) \u2013 Primo ciclo completo + Retrospettiva<\/strong><\/p>\n

                            \n
                          • Vivi il primo ciclo completo. Scrum: porta a casa lo Sprint Goal, fai Review e Retro. Kanban: misura il primo throughput<\/strong> settimanale.<\/li>\n
                          • Inizia a tracciare le metriche chiave: velocity<\/strong> (Scrum) oppure lead time<\/strong> e throughput<\/strong> (Kanban).<\/li>\n
                          • Fai una Retrospettiva sincera: cosa ha funzionato, cosa no, cosa cambiare.<\/li>\n<\/ul>\n

                            Settimane 7-8 (giorni 43-60) \u2013 Stabilizzazione e miglioramento continuo<\/strong><\/p>\n

                              \n
                            • Affina i limiti di WIP, raffina il backlog grooming, normalizza la stima.<\/li>\n
                            • Coinvolgi gli stakeholder esterni nella Sprint Review (Scrum) o nel replenishment meeting (Kanban).<\/li>\n
                            • Pianifica una checkpoint a 90 giorni<\/strong> per decidere se serve uno scaling, una transizione a Scrumban<\/strong>, o un raffinamento del setup attuale.<\/li>\n<\/ul>\n<\/div>\n

                              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\u00ec in poi \u00e8 miglioramento continuo: il vero scopo di Scrum, di Kanban e di tutto l’agile.<\/p>\n

                              15. FAQ \u2014 Domande frequenti su Scrum e Kanban<\/h2>\n
                              \n
                              \n

                              Una PMI di 15 dipendenti ha senso che adotti Scrum?<\/h3>\n
                              \n
                              \n

                              S\u00ec, ma con criterio. Scrum \u00e8 progettato per team da circa 10 persone o meno; in una PMI di 15 dipendenti con un team di prodotto da 4-6 persone \u00e8 perfettamente applicabile. Il problema non \u00e8 la dimensione dell’azienda ma la presenza di un Product Owner reale (qualcuno che possa decidere cosa va e cosa non va nel prodotto) e di un team cross-funzionale che possa portare a termine un Incremento senza dipendere da terzi.<\/p>\n<\/div>\n<\/div>\n<\/div>\n

                              \n

                              Posso fare Scrum senza Scrum Master?<\/h3>\n
                              \n
                              \n

                              La Scrum Guide 2020 dice di no: lo Scrum Master \u00e8 una delle tre responsabilit\u00e0 del team. Nella pratica delle PMI, per\u00f2, il ruolo \u00e8 spesso assunto a rotazione da un Developer senior o dallo stesso tech lead. Funziona se la persona ha tempo dedicato e formazione adeguata. Non funziona se \u00e8 solo un cappello aggiuntivo per il project manager esistente.<\/p>\n<\/div>\n<\/div>\n<\/div>\n

                              \n

                              Kanban \u00e8 “Scrum senza Sprint”?<\/h3>\n
                              \n
                              \n

                              No, \u00e8 una semplificazione fuorviante. Kanban \u00e8 un metodo evolutivo che parte dal sistema esistente e introduce trasparenza, limiti di WIP, gestione del flusso. Non c’\u00e8 un Product Owner formale, non c’\u00e8 una Definition of Done universale (ma policy esplicite per colonna), non c’\u00e8 una cadenza fissa. Sono due modelli filosoficamente diversi, anche se entrambi sotto l’ombrello agile.<\/p>\n<\/div>\n<\/div>\n<\/div>\n

                              \n

                              Qual \u00e8 la differenza fra velocity e throughput?<\/h3>\n
                              \n
                              \n

                              La velocity, tipica di Scrum, \u00e8 la somma dei story point completati in uno Sprint: misura una stima soggettiva di complessit\u00e0. Il throughput, tipico di Kanban, \u00e8 il numero di item completati in un’unit\u00e0 di tempo: misura conteggio oggettivo. La velocity dipende da come stimi; il throughput no. Per fare forecast affidabili a medio termine, molti team Kanban usano simulazioni Monte Carlo sulla distribuzione storica del throughput.<\/p>\n<\/div>\n<\/div>\n<\/div>\n

                              \n

                              Si possono usare Scrum e Kanban contemporaneamente in azienda?<\/h3>\n
                              \n
                              \n

                              S\u00ec, e in molte aziende \u00e8 la norma. Tipicamente il team di sviluppo nuovo prodotto usa Scrum, il team di operations\/manutenzione usa Kanban, il marketing usa una board Kanban semplice. \u00c8 perfettamente coerente: ogni team adotta lo strumento giusto per il suo contesto, all’interno di una cultura agile condivisa.<\/p>\n<\/div>\n<\/div>\n<\/div>\n

                              \n

                              Quanto tempo serve perch\u00e9 un team diventi veramente agile?<\/h3>\n
                              \n
                              \n

                              Servono almeno 6-12 mesi per stabilizzare un team su Scrum o Kanban, e altri 12-18 mesi perch\u00e9 la cultura agile permei le funzioni di contorno. I primi 60 giorni sono la fase pi\u00f9 rumorosa.<\/p>\n<\/div>\n<\/div>\n<\/div>\n

                              \n

                              Conviene partire da Jira o da uno strumento pi\u00f9 leggero?<\/h3>\n
                              \n
                              \n

                              Per una PMI alle prime armi, partire da Trello o GitHub Projects \u00e8 una scelta saggia: il rischio di Jira \u00e8 iperconfigurare il tool prima di aver chiarito il processo. Quando il workflow \u00e8 stabile e servono automazioni e integrazioni CI\/CD, allora Jira o Azure DevOps diventano un investimento sensato.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

                              \n

                              Vuoi rendere agile la gestione operativa della tua PMI?<\/h3>\n

                              Adottare Scrum o Kanban \u00e8 un grande passo, ma non basta a coprire tutta la macchina aziendale: ordini, magazzino, fatturazione, CRM, supporto clienti restano spesso fuori dai framework di sviluppo. Con un gestionale personalizzato<\/strong> connesso ai tuoi strumenti di project management puoi finalmente avere un’unica fonte di verit\u00e0.<\/p>\n

                              \nScopri i gestionali Brentasoft<\/a>
                              \n                              Richiedi un preventivo<\/a>\n<\/p>\n<\/div>\n