Non ogni gruppo di lavoro deve diventare uno Scrum team
Cinque gruppi con lo stesso assetto sembrano ordine, finché non guardi come lavorano davvero. Chi occupa un ruolo che non decide niente si inventa un lavoro, e quel lavoro lo chiamiamo burocrazia.
Capita di entrare in un'organizzazione che ha appena finito di riorganizzarsi e di trovare cinque o sei gruppi con lo stesso identico assetto: un Product Owner, uno Scrum Master, un backlog, sprint di due settimane, le stesse cerimonie negli stessi giorni della settimana. Sulla carta sembra ordine, e in effetti da lontano lo è. Poi guardi come lavorano davvero e ti accorgi che due di quei gruppi ci stanno dentro benissimo, uno ci sta scomodo e gli altri hanno smesso da mesi di usare metà di quelle cose, però le tengono in calendario perché sono state decise.
La lettura comoda, a quel punto, è che manchi disciplina. Per me il problema sta un passo prima, nel momento in cui si è deciso che tutti dovessero avere la stessa forma.
Un assetto non è un contenitore neutro
Scrum, per come è disegnato, dà per scontate alcune cose molto specifiche. Che esista un risultato che si può guardare a intervalli regolari e su cui qualcuno, fuori dal gruppo, abbia qualcosa da dire. Che il gruppo abbia abbastanza autonomia da cambiare rotta quando quello sguardo restituisce qualcosa di scomodo. Che ci sia una persona che può davvero decidere cosa viene prima e cosa aspetta.
Dove queste condizioni ci sono, le cerimonie hanno una funzione ovvia e nessuno deve ricordare a nessuno perché si fanno. Dove non ci sono, restano gesti. E i gesti, ripetuti abbastanza a lungo senza che producano una decisione, insegnano al gruppo una cosa precisa: che quel momento non serve. È un apprendimento difficile da smontare dopo.
I ruoli senza materia si riconoscono presto
Il segnale che leggo prima di tutti gli altri non riguarda la noia in riunione, che può avere mille cause. Riguarda i ruoli: quando un ruolo esiste sull'organigramma e non ha un contenuto reale, si vede quasi subito.
Un Product Owner che non può decidere niente, perché le priorità arrivano già decise da un altro piano, non è un Product Owner. Ha un titolo che lo espone a domande a cui non ha l'autorità di rispondere, e a lungo andare impara a difendersi: risponde in modo vago, oppure rimanda, oppure passa la domanda a chi decide sul serio, che però non è in quella stanza.
Uno Scrum Master assegnato a un gruppo che lavora a ticket di manutenzione, dove il flusso è noto e gli intoppi veri sono sempre gli stessi tre, si ritrova a facilitare conversazioni che non hanno niente da sciogliere. Una review senza nessuno a cui mostrare qualcosa diventa il momento in cui il gruppo racconta a se stesso quello che già sa.
Non è colpa delle persone, e nemmeno del framework. Quando un ruolo non ha materia, chi lo occupa la trova altrove: si mette a controllare, o a fare da tramite fra due parti che potrebbero parlarsi da sole. Nasce così una parte notevole del lavoro inutile che poi attribuiamo alla burocrazia interna.
Cosa distingue un gruppo dall'altro
Quando mi chiedono se un gruppo sia «pronto» per un certo assetto, la maturità è la variabile meno interessante. Ce ne sono altre che pesano di più e che quasi nessuno mette sul tavolo al momento di decidere.
La prima è quanta incertezza c'è nel lavoro. Se un gruppo sa già cosa deve fare e il problema è farlo bene e in fretta, ispezionare ogni due settimane costa più di quanto renda: si sta misurando l'esecuzione di una cosa su cui non c'è niente da scoprire. La seconda è quanto i pezzi dipendono l'uno dall'altro. Un gruppo di specialisti che portano avanti cose separate, e che si incrociano tre volte al mese, non ha bisogno di sincronizzarsi ogni mattina: gli basta sapere dove sono, le tre volte.
Poi c'è il tempo del riscontro, che secondo me è la più trascurata. Se quello che il gruppo produce riceve una risposta dal mondo dopo tre mesi, uno sprint di due settimane non misura l'effetto di niente. Misura l'attività interna, che è un'altra cosa e che tende a diventare il criterio proprio perché è l'unico disponibile.
Su questa variabile mi ha spostato una lettura, Accelerate di Forsgren, Humble e Kim. Le misure che quel libro prende sul serio guardano tutte allo stesso punto, cioè quanto tempo passa fra una cosa fatta e il momento in cui è davanti a chi la usa, e quanto ne serve a rimetterla in piedi quando si rompe. Presuppongono un giro che si chiude in fretta. Un gruppo che quel giro ce l'ha lungo per costruzione può usarle lo stesso, purché sappia che gli stanno raccontando come è organizzato dentro, e non che effetto sta facendo fuori.
La domanda che metto al posto del modello
Invece di chiedermi se un gruppo sia adatto a Scrum, mi chiedo qual è il minimo che serve a quel gruppo perché il lavoro che fa davvero diventi leggibile e correggibile. Qualche volta la risposta coincide con Scrum quasi per intero, e allora tanto vale usare un linguaggio che le persone conoscono già. Altre volte è molto meno: un posto solo da cui arrivano le richieste, invece di tre canali e un corridoio; un momento fisso in cui si decide cosa non si fa; una persona che ha l'autorità di sciogliere un blocco senza chiedere il permesso a due livelli.
Un gruppo può eseguire un framework in modo impeccabile e stare lavorando, con grande diligenza, sulle cose sbagliate.
L'assetto non protegge da questo. Anzi, quando è molto curato dà l'impressione rassicurante che la domanda sia già stata affrontata da qualcuno, prima, altrove.
Il rischio dell'argomento opposto
Non sto sostenendo che ogni gruppo debba inventarsi il proprio metodo. Ho visto anche quel film. Un'organizzazione in cui ognuno si organizza come preferisce paga un prezzo altissimo in traduzione: chi la attraversa deve imparare cinque modi diversi di chiedere una cosa, e ogni passaggio fra un gruppo e l'altro diventa una piccola negoziazione. L'uniformità serve.
Il punto è che è una scelta, con un costo, e chi la fa dovrebbe poter dire quale problema risolve. «Così siamo tutti allineati» non è una risposta a quella domanda, è la sua versione educata.
Quando istituiamo un gruppo e gli diamo una forma, stiamo rispondendo a una domanda che spesso non abbiamo formulato: di che tipo di lavoro è fatto questo gruppo, e che cosa gli serve per governarlo? Se la risposta che ci viene è «lo stesso di tutti gli altri», forse quella domanda non ce la siamo posta.
Riferimenti
- Nicole Forsgren, Jez Humble, Gene Kim, Accelerate (2018)
Commenti
Apri la conversazione
L'agile vive di conversazioni. Iscriviti a My Agile Stories e comincia questa.
Iscriviti ora