Scrum
Scrum è un framework agile che aiuta i team ad affrontare lavori complessi in cicli brevi e iterativi attraverso ruoli, eventi e artefatti fissi.
Scrum è un framework agile per sviluppare e gestire prodotti complessi, nato originariamente nello sviluppo software e ora usato in molti settori. Si fonda sull'idea del controllo empirico dei processi: invece di pianificare un compito dall'inizio alla fine in anticipo, un team lavora in periodi di tempo brevi e fissi chiamati sprint, tipicamente da una a quattro settimane. Ogni sprint si conclude con un incremento di lavoro utilizzabile, il che crea spazio per il feedback e permette al team di adattare i propri passi successivi. Questa combinazione di trasparenza, ispezione e adattamento rende Scrum adatto a lavori in cui i requisiti sono incerti o soggetti a cambiare.
Scrum definisce tre ruoli fissi. Il product owner è responsabile del valore del prodotto e mantiene il product backlog, un elenco prioritizzato di tutto ciò che deve essere fatto. Lo scrum master mantiene il team all'interno del framework, rimuove gli ostacoli e facilita la collaborazione senza assegnare direttamente i compiti. Il development team pianifica ed esegue autonomamente il lavoro. Quattro eventi ricorrenti danno struttura a ogni sprint: lo sprint planning all'inizio, il daily scrum per un rapido allineamento, la sprint review per mostrare quanto è stato costruito, e la sprint retrospective per migliorare il modo in cui il team collabora.
Scrum funziona meglio per compiti in cui l'ambito o la soluzione non sono del tutto chiari fin dall'inizio, come lo sviluppo prodotto o progetti complessi con molti stakeholder. Si differenzia da Kanban per i suoi periodi di tempo fissi e i ruoli definiti, mentre Kanban si basa più su un flusso continuo senza iterazioni prestabilite. Rispetto alla pianificazione a cascata classica, il suo vantaggio è l'ispezione regolare: le valutazioni errate emergono presto invece che solo alla fine del progetto. Nella pratica, Scrum tende a fallire non per il framework in sé ma per un'esecuzione poco convinta, ad esempio quando le retrospettive vengono saltate o il backlog viene lasciato non curato.
Esempio pratico
Un'azienda di medie dimensioni costruttrice di macchinari sta sviluppando un nuovo software per monitorare le proprie apparecchiature di produzione. Il team di cinque persone lavora in sprint di due settimane: all'inizio di ogni sprint seleziona i dieci elementi più importanti tra circa 40 voci aperte nel backlog, allineandosi ogni giorno in un daily scrum di 15 minuti. Dopo dieci sprint, cioè cinque mesi, è pronta una prima versione utilizzabile, invece dei nove mesi di sviluppo senza alcun risultato intermedio che il team aveva originariamente pianificato. Le retrospettive rivelano che requisiti poco chiari sono costati al team circa il 20 percento della propria capacità durante i primi tre sprint, così da quel momento il product owner inizia a scrivere descrizioni del backlog più precise.
Come aiuta Leanshift
Nel suo nucleo, la sprint retrospective è semplicemente un ciclo Kaizen ricorrente: il team si ferma, guarda con onestà il lavoro appena concluso e apporta un miglioramento deliberato al proprio modo di lavorare prima di andare avanti. Questo è coerente con la visione Leanshift secondo cui il miglioramento non è un progetto una tantum ma un'abitudine regolare integrata nel lavoro quotidiano. I team che vivono in questo modo non migliorano solo il prodotto, formano più persone capaci di migliorare le cose da sole.
Domande frequenti
Scrum è utile solo per lo sviluppo software?
No. Scrum è nato nel software ma oggi viene usato in marketing, sviluppo prodotto, istruzione e altri ambiti, ovunque il lavoro sia complesso e i requisiti possano cambiare strada facendo.
In cosa Scrum differisce da Kanban?
Scrum si svolge in periodi di tempo fissi chiamati sprint con ruoli ed eventi definiti, mentre Kanban visualizza un flusso continuo di lavoro senza iterazioni prestabilite e si concentra sul limitare quanto lavoro è in corso contemporaneamente.
Un piccolo team ha davvero bisogno di uno scrum master dedicato?
Non necessariamente come ruolo a tempo pieno. Nei team piccoli, spesso qualcuno se ne occupa insieme al proprio lavoro abituale; ciò che conta è che la facilitazione e il framework stesso vengano effettivamente rispettati.