Questa pagina è stata tradotta automaticamente. Per una migliore esperienza di lettura, passa all'inglese.
Passa all'ingleseNo. L’IA può accelerare il lavoro, sintetizzare le informazioni e supportare lo sviluppo del software. Tuttavia, non sostituisce obiettivi di prodotto chiari, né la collaborazione, la garanzia della qualità o il miglioramento continuo.
Il DORA Report 2025 descrive quindi l’IA come un amplificatore: nelle organizzazioni che funzionano bene può aumentare l’efficienza, in quelle frammentate rende più evidenti le debolezze esistenti. Fonte: Google: DORA Report 2025.
Non esiste una quota affidabile basata sulle dimensioni dell’azienda. Tuttavia, Scrum è spesso più visibile e organizzato formalmente nelle grandi aziende, mentre le piccole imprese utilizzano più frequentemente pratiche agili in modo pragmatico o ibrido.
Nelle grandi organizzazioni, la necessità di coordinamento, gli approcci di scaling e i ruoli dedicati di Scrum Master favoriscono una maggiore istituzionalizzazione. I piccoli team di prodotto, d’altro canto, possono implementare Scrum più facilmente e spesso lo adattano in modo flessibile. Il fattore decisivo non è la dimensione dell’azienda, ma se il team ha responsabilità chiare, cicli di feedback brevi e dipendenze gestibili.
Fonte: 18° State of Agile Report 2025.
No. Il State of Agile Report 2025 non pubblica più tuttavia una quota d’uso attuale e globalmente comparabile specifica per Scrum. Lo studio descrive però esplicitamente l’agilità come adattabile anziché in calo: il 74 % degli intervistati utilizza modelli agili ibridi o sviluppati internamente. Scrum viene quindi più spesso combinato con altre pratiche, anziché essere sostituito in modo generalizzato.
Fonte: 18º State of Agile Report di Digital.ai e Inquadramento dei risultati dello studio del 2025.
Scrumban può essere una buona alternativa quando un team ha ancora bisogno di obiettivi di prodotto chiari e di una riflessione regolare, ma vuole gestire il flusso di lavoro in modo più flessibile. Tipicamente si usano una Kanban board, limiti WIP e principi di pull, integrati con adeguate routine di pianificazione, review e retrospettiva.
Scrumban non è automaticamente migliore di Scrum. Vale la pena adottarlo quando risolve meglio un problema concreto, come troppo carry-over, lunghi tempi di attesa o frequenti lavori non pianificati, e quando il team ne verifica l’efficacia tramite lead time, qualità e beneficio per il cliente.
Kanban si adatta spesso meglio quando il lavoro arriva in modo continuo e si lascia difficilmente raggruppare in obiettivi di sprint affidabili – ad esempio nel supporto, nelle operations, nella risposta agli incidenti o in molti piccoli compiti non pianificati. In questi casi, un flusso di lavoro visibile, un lavoro parallelo limitato e tempi di attraversamento brevi aiutano più di una cadenza di sprint fissa.
Scrum rimane sensato quando un team di prodotto stabile e cross-funzionale lavora in cicli brevi verso un obiettivo comune. Il passaggio a Kanban dovrebbe risolvere un problema concreto, non solo ridurre le riunioni.
Per i team con richieste imprevedibili e un flusso di lavoro continuo, Kanban è spesso una buona alternativa a Scrum. Per lo sviluppo di prodotto con obiettivi di apprendimento regolari, Scrum può continuare ad andare bene; integrato con pratiche Kanban, spesso nasce Scrumban. Ciò che conta non è il nome del framework, ma se migliori la prioritizzazione, la qualità, il feedback e il miglioramento continuo per il contesto კონკრეტo.
La tendenza attuale va verso approcci ibridi: il 74 % degli intervistati nel State of Agile Report 2025 utilizza modelli agili misti o sviluppati internamente.
Nel 2026 non esiste un singolo framework successore di Scrum. Le alternative o integrazioni più comuni sono Kanban per un flusso di lavoro continuo, Scrumban per una combinazione di obiettivi di sprint e principi di flow, e Extreme Programming (XP) per le pratiche di engineering tecnico. L’18th State of Agile Report mostra soprattutto una tendenza verso modelli ibridi e dipendenti dal contesto, non verso un sostituto uniforme.
Fonte: Inquadramento dello studio 18th State of Agile con il dato sull’Hybrid Agile.
I modelli ibridi aiutano i team ad adattare Scrum al loro contesto di delivery. Lo integrano ad esempio con Kanban per il flusso di lavoro, discovery continua o pratiche tecniche di engineering.
Nel 18th State of Agile Report, il 48 % degli intervistati ha utilizzato modelli ibridi o misti e un ulteriore 26 % un approccio sviluppato internamente. Questo non è un appello contro Scrum, ma contro la fedeltà acritica al framework. Fonte: 18th State of Agile Report di Digital.ai.
Gli Scrum Team non dovrebbero limitarsi a contare le funzionalità consegnate. Più significativo è il collegamento tra un chiaro obiettivo di prodotto, il feedback dei clienti e poche metriche di delivery come il lead time, la deployment frequency e il change failure rate.
I numeri non sono uno strumento di controllo. Aiutano il team a capire se sta risolvendo un problema rilevante, se può rilasciare in modo sicuro e dove si trovano gli ostacoli all’apprendimento o alla delivery. Fonte: Google: DORA Report 2025.
I rischi principali sono riassunti errati, problemi di protezione dei dati, mancanza di fiducia nelle registrazioni, un’eccessiva interpretazione delle metriche e un ulteriore overhead di strumenti.
Gli Scrum Master dovrebbero quindi usare i risultati dell’IA come spunto di discussione, non come verità automatica.
La performance dello Scrum Master si misura in modo sensato non con un singolo KPI, ma con una combinazione di metriche di delivery, salute del team, efficacia delle retrospettive, tracciamento delle azioni e osservazioni qualitative.
È importante che i numeri non vengano usati come strumento di controllo. Dovrebbero servire come spunto di conversazione: dove perde focus il team? Quali blocker si ripetono? Quali misure portano davvero a una migliore collaborazione?
Più contesto lo trovi qui: KPI della performance dello Scrum Master