'Facciamo Agile' è la frase che sento più spesso da clienti che in realtà fanno riunioni quotidiane senza alcun cambiamento reale nel modo di lavorare. Agile è una filosofia, non un metodo. Scrum e Kanban sono metodi concreti che implementano quella filosofia in modi molto diversi. Confonderli costa tempo, soldi e credibilità del team di progetto.
1. Agile: il framework mentale, non il processo. Agile è l'insieme di valori e principi del Manifesto Agile (2001): priorità alle persone sui processi, al software funzionante sulla documentazione esaustiva, alla collaborazione col cliente sulla negoziazione contrattuale, alla risposta al cambiamento sul seguire un piano rigido. Non dice come organizzare gli sprint, chi fa cosa, o come misurare l'avanzamento. Per questo 'fare Agile' senza scegliere un metodo concreto è quasi sempre teatro organizzativo.
2. Scrum: quando il lavoro è prevedibile e iterativo. Scrum funziona quando puoi pianificare blocchi di lavoro (sprint di 1-4 settimane) con un obiettivo chiaro e un backlog prioritizzabile. È il framework giusto per sviluppo prodotto, team stabili con ruoli definiti (Product Owner, Scrum Master, Development Team) e contesti dove il cliente può dare feedback a cadenza regolare. Scrum richiede disciplina di ruoli: se il Product Owner non ha reale autorità decisionale, o lo Scrum Master fa anche il PM tradizionale, il framework collassa rapidamente.
3. Kanban: quando il flusso conta più del piano. Kanban funziona quando il lavoro arriva in modo continuo e imprevedibile — supporto clienti, operations, team di manutenzione, o contesti multi-progetto con priorità che cambiano spesso. Non ci sono sprint: c'è un flusso continuo con limiti di work-in-progress (WIP) per colonna. La metrica chiave non è la velocity ma il lead time (quanto tempo un task impiega dall'ingresso all'uscita).
4. Come decidere in 3 domande. Il lavoro arriva a ondate pianificabili o in modo continuo e imprevedibile? Ondate → Scrum. Continuo → Kanban. Il team può isolarsi per 1-4 settimane su un obiettivo condiviso? Sì → Scrum. No → Kanban. Serve un cambio culturale profondo nei ruoli, o solo visibilità e controllo del flusso? Cambio profondo → Scrum. Visibilità → Kanban.
5. Il modello ibrido che funziona nella pratica. Molti team maturi usano Scrumban: struttura a sprint di Scrum per la pianificazione, board Kanban con limiti WIP per la gestione quotidiana del flusso. È l'approccio che consiglio più spesso a organizzazioni con team misti (sviluppo + supporto) perché non forza tutta l'azienda in un unico framework rigido.
Domande Frequenti. Posso passare da Scrum a Kanban a metà progetto? Sì, ed è più comune di quanto si pensi: il segnale è quando gli sprint vengono costantemente interrotti da richieste urgenti esterne. Serve certificarsi (PSM, CSM) per applicare questi framework? La certificazione aiuta con il linguaggio comune e la credibilità verso stakeholder, ma non sostituisce l'esperienza pratica di adattamento al contesto specifico.
Se il tuo team dice di fare Agile ma senti che qualcosa non torna, parliamone: in una call di 30 minuti ti aiuto a capire quale framework si adatta davvero al tuo contesto — senza venderti una metodologia preconfezionata.
