Si sente spesso dire “sì, noi facciamo Scrum, ma abbiamo fatto qualche aggiustamento, per adattarlo alle nostre esigenze”. E’ quello che in letteratura è chiamato “Scrum-But“. E’ bene o male?
La risposta è chiaramente: “dipende”, ma tende al male.
Team molto navigati, che hanno praticato Scrum per diverso tempo (1-2 anni) hanno sicuramente la percezione del valore di ogni singola prescrizione e sono in grado di “aggiustare” Scrum senza snaturarlo. Conoscono le ragioni che stanno dietro il Daily Scrum, dietro una Retrospective e possono ricercarle in molti modi diversi, non necessariamente legati alla cerimonia specifica e un po’ prescrittiva che qualsiasi libro di Scrum suggerisce.
Ma un team alle prime armi, che vuol iniziare ad usare Scrum, non deve per nessun motivo cambiare una virgola del framework. Scrum è stato studiato per funzionare e per avere relativamente pochi vincoli. Toglierne alcuni significa smontare la struttura portante del framework, con un risultato insoddisfacente o comunque minore di quello che si otterrebbe applicandolo in pieno. Non solo: i ruoli di Scrum (Product Owner, Scrum Master, Development Team) hanno alcune responsabilità specifiche e ben circoscritte: seguirle alla lettera significa risparmiare moltissimo tempo in discussioni inutili su chi deve prendere alcune decisioni.
Vi faccio alcuni esempi
Scrum senza il Daily Scrum
Probabilmente il team lavorerà scoordinato per tutto lo sprint, proprio perché non ha occasione di fare Just-in-time planning o di far emergere in maniera collettiva gli impedimenti. Lo Scrum Master non sarà a conoscenza di tutti i problemi e tutto il team rischia di arrivare alla review con pochissime cose fatte semplicemente per mancanza di coordinamento. Portare una user story in Done in maniera coordinata richiede un grande lavoro di focalizzazione da parte di tutto il team, specialmente all’inizio quando il concetto di cross-funzionalità è ancora sconosciuto.
Scrum senza Product Owner
Il team perderà ore a decidere cosa sia meglio per il prodotto, perché chiaramente non è facile mettersi d’accordo sulla strategia in 8 persone. Alla fine sarà più il tempo speso in chiacchiere che quello nello sviluppo. Non solo: quando arriverà il CEO a dire “perché avete scelto questa strategia” nessuno sarà responsabile in maniera diretta.
Scrum senza Scrum Master
Beh, è un po’ come avere una palestra di arti marziali senza l’insegnante 🙂 Il team inizia a fare Scrum by-the-book, trainato da qualcuno più motivato di altri. Se tutto va bene, i primi 2 sprint saranno divertenti, ma poi il team tenderà a tornare a lavorare come prima. La transizione verso Scrum è scomoda e faticosa, perché va a rompere molte abitudini: lo Scrum Master, con la sua capacità di servant leader e di facilitatore, ha il compito, ogni giorno, ogni meeting, di riportare il team sulla giusta strada
Scrum senza Review
Il team tenderà a fare cose “non-done” perché tanto non c’è bisogno di mostrarle a nessuno. Conseguentemente, quando il Product Owner chiederà di fare una Release, il team avrà ancora moltissimo lavoro da fare per portare a Done le cose lasciate a mezzo. Preparare una review “forza” il team ad assicurarsi della bontà del lavoro fatto. Qualcuno addirittura, all’interno dello Sprint, fa una pre-review il giorno prima, intorno ad un tavolo con tutto il team.
Scrum con Sprint di 2 mesi
Questa è una delle cose che succede più spesso. Si crede che Sprint più lunghi riescano ad ammortizzare meglio il tempo “sprecato” nelle cerimonie di Planning e di Review, oppure che ci sia bisogno di 2 mesi per portare un lavoro tangibile in Review. Niente di più sbagliato. Il team deve sforzarsi di riuscire a costruire qualcosa di “shippable”, di consegnabile e tangibile in 15 giorni, eliminando le cose che non servono. Quante righe di codice sono davvero importanti per user story che stiamo lavorando? Potrei rimandare lo sviluppo di qualcosa al prossimo sprint? Fare bene Scrum significa anche imparare a dividere il lavoro in piccole parti di valore. E questa è una delle cose più difficili di Scrum. Aggiungo anche: Sprint lunghi riducono molto la possibilità di fare “inspect and adapt”. Alla fine di uno sprint ci si può rendere conto di dover dare una sterzata significativa al Release Plan, grazie ai feedback degli stakeholders: più lungo è lo sprint, più tardi daremo questa sterzata, più soldi avremo sprecato.
Potrebbero esserci molti altri esempi, ma mi fermo qui.