Il potere: quando l’autorità si impossessa della cerimonia

Ogni cerimonia agile presuppone condizioni di parità. Il potere entra in gioco proprio quando tali condizioni non sussistono.

Il Planning Poker supera l’effetto di ancoraggio solo se nessuno al tavolo può ignorare le carte. Una retrospettiva è sicura solo se l’onestà non comporta alcun costo. La velocità è una previsione solo se nessuno al di sopra del team la valuta. Eliminate tali presupposti — aggiungete un manager che approvi le promozioni, un indicatore che venga trasmesso ai livelli superiori, una stima che si cristallizzi in una promessa — e la cerimonia non solo non produce i risultati sperati, ma si inverte. Comincia a funzionare contro le persone per cui è stata concepita. Questo capitolo individua i tre modi più evidenti in cui ciò accade, poiché individuarli è il primo passo per rifiutarli.

Il cricchetto di velocità

Cominciamo con l’argomento più incisivo di tutti: la persona che ha inventato gli story point ne ha preso le distanze. «Mi piace dire che potrei aver inventato gli story point e, se così fosse, ora me ne rammarico», ha scritto Ron Jeffries nel 2019 — e, in particolare, «ritengo che confrontare i team in base alla qualità delle stime o alla velocità sia dannoso». Quando l’inventore di un’unità di misura vi dice che tale unità viene utilizzata per danneggiare i team, l’onere della prova ricade su chiunque continui a utilizzarla come parametro di valutazione.

Il meccanismo di ratchet della velocità è il modo in cui tale danno si manifesta. La velocità è concepita come un sistema di autocalibrazione interno al team — la media mobile dei punti completati, utilizzata per prevedere il tempo necessario per smaltire il backlog. Nel momento in cui esce dalla sala come obiettivo di produttività, diventa un meccanismo a cricchetto: il valore dello sprint precedente costituisce la soglia minima di questo sprint, e l’unica direzione in cui è consentito muoversi è verso l’alto. I team non sono stupidi, quindi reagiscono nell’unico modo consentito dall’incentivo: gonfiano i valori. Una story che nel trimestre precedente valeva 3, in questo trimestre vale 5; il numero sale, ma nulla viene consegnato più rapidamente. Persino Mike Cohn, l’autorità in materia di punti, ammette questo meccanismo: il minimo accenno al fatto che le velocità verranno messe a confronto produce un’inflazione graduale e costante dei punti.

La base più solida su cui fondarsi per mantenere la “velocity” nei giusti binari è DORA. Un decennio di ricerche su quali fattori predicono le prestazioni nella consegna del software ha portato all’individuazione di quattro metriche — frequenza di distribuzione, lead time, tasso di fallimento delle modifiche e tempo di ripristino — e la velocità è stata volutamente esclusa da questo elenco, poiché gli story point non sono comparabili tra i vari team e misurano lo sforzo, non il valore consegnato. Pertanto, la regola è semplice e giustificabile: utilizzate la velocità per le previsioni, ma non per valutare i risultati. Se qualcuno al di fuori del team chiede «la vostra velocità è buona?», la soluzione va ricercata a monte del dato: la risposta onesta è «cosa state effettivamente cercando di misurare?». Il nostro capitolo velocità illustra come mantenerla onesta, mentre velocità e pianificazione della capacità spiega come utilizzarla per l’unico scopo per cui è utile.

Riciclaggio di preventivi

La seconda distorsione è più sottile perché si presenta come un atto di responsabilità. Il “riciclaggio delle stime” consiste nella silenziosa trasformazione di una stima — un’ipotesi formulata sulla base del minimo di informazioni a disposizione — in un impegno, per poi pretendere che il team lo rispetti come se avesse firmato un contratto. L’ipotesi viene presentata durante la riunione di pianificazione; ne viene fissata una scadenza; e quando la scadenza non viene rispettata, la colpa ricade sullo sviluppatore per aver «mancato la propria stima».

Gli addetti ai lavori descrivono l’intero ciclo di “riciclaggio” senza bisogno di essere sollecitati: le stime si trasformano magicamente in impegni, e se non si raggiunge la cifra prevista, la responsabilità ricade su di voi. Le stime vengono respinte — «non può essere corretto, rifatela» — finché il team non fornisce una cifra qualsiasi che permetta di rispettare la scadenza, a quel punto la pianificazione diventa una farsa con un risultato predeterminato. Esiste persino un’asimmetria rivelatrice nel linguaggio: se si dice «ci vorranno dieci giorni», un manager insisterà chiedendo «è sicuro che non possano essere nove?»; se si dice «sono dieci punti», invece, per ragioni che nessuno riesce a giustificare appieno, lo stesso istinto non scatta. Gli story point erano in parte concepiti come una protezione proprio contro quella pressione — e il “riciclaggio delle stime” è la pressione che sconfigge tale protezione, convertendo i punti direttamente in una data.

Il principio correttivo di riferimento è quello di Mike Cohn, ed è antecedente alla nostra coniazione del termine: separare la stima dall’impegno. Una stima è una distribuzione di probabilità; un impegno è una decisione che il team prende riguardo a ciò che è sicuro di poter consegnare. Teneteli distinti, espressamente. Prevedete un intervallo e specificate le ipotesi su cui si basa. E fate attenzione al caso di «composizione»: quando l’ambito, i tempi e i costi sono tutti fissati in anticipo e il lavoro è semplicemente suddiviso in sprint di due settimane, non si tratta di agile con stime, ma di un modello a cascata travestito. Dave West di Forrester ha definito questo fenomeno «water-scrum-fall», e il “riciclaggio delle stime” ne costituisce il cuore pulsante. Il nostro capitolo story point vs ore spiega perché la conversione rappresenta la causa del fallimento, non la soluzione.

Gestione dei feedback

La terza distorsione è la più insidiosa, poiché trasforma quella che sembra la cerimonia più sicura in un elemento di rischio. Il feedback banking si verifica quando i commenti retrospettivi onesti vengono accumulati e successivamente utilizzati contro di voi in modo discreto — in occasione di una valutazione delle prestazioni, di una revisione dei bonus o di una conversazione informale sull’“adeguatezza”. La retrospettiva viene presentata come uno spazio sicuro in cui esprimersi con franchezza. Il «feedback banking» è la scoperta che la franchezza ha una data di scadenza.

Le storie di guerra sono concrete e fanno male. Un ingegnere ha descritto il riemergere dei propri commenti negativi durante una valutazione annuale come prova del fatto che “si lamenta troppo”. Un altro ha spiegato chiaramente il meccanismo: la direzione accumula tutte le lamentele per tirarle fuori in occasione della revisione annuale del bonus. L’effetto dissuasivo non richiede nemmeno malizia: la persona che approva le promozioni non deve dire una sola parola nella stanza. La sua sola presenza è sufficiente a rendere vaghi i contributi onesti e a insegnare a tutti che la mossa più intelligente è quella di fingere soddisfazione. Il nostro capitolo Perché le retrospettive falliscono tratta della progettazione della sessione in modo che l’onestà smetta di comportare un costo per la carriera.

È qui che la letteratura sulla sicurezza smette di limitarsi a vaghe generalizzazioni. Il lavoro di Amy Edmondson sulla sicurezza psicologica e il Progetto Aristotele di Google — due anni di studi su 180 team — hanno individuato nella sicurezza psicologica il più forte dei cinque fattori identificati, quello su cui si fondano gli altri quattro. Un team che ha compreso che il proprio feedback viene archiviato non gode, per definizione, di sicurezza psicologica, e la retrospettiva che finge il contrario è una messinscena che comporta un rischio legale. La Guida Scrum definisce la retrospettiva come un’occasione in cui il team esamina se stesso — allora perché il manager è presente nella stanza a prendere appunti?

Non fate affidamento su un eroe

All’interno della soluzione si nasconde una modalità di fallimento. Queste distorsioni vengono solitamente contenute perché una figura di riferimento — un responsabile, un EM con carattere — protegge personalmente il team: rifiuta di trasmettere i dati sulla velocità ai livelli superiori, ridefinisce le stime come previsioni e mantiene il contenuto del retrospettivo all’interno della sala. Funziona, ma solo finché quella persona rimane. Uno scudo non è un sistema. Se l’onestà delle vostre cerimonie dipende dalla disponibilità di un singolo manager ad assorbire la pressione, non avete cerimonie sicure: ne avete una temporaneamente benevola, e la farsa riprende il giorno in cui quella persona se ne va.

Questa è la differenza tra il Potere inteso come modalità di fallimento e il Potere inteso come elemento immutabile. Il capitolo sulla sicurezza psicologica tratta della creazione di un clima di franchezza che non dipenda dalle persone presenti nella stanza, mentre la Direttiva Primaria illustra la norma che ne garantisce la permanenza. Quando la cerimonia formalizzata finisce per produrre nient’altro che apparenze controllate, si giunge al vuoto di follow-through — la quarta modalità, quella in cui l’accumulo di feedback infligge il danno più silenzioso.

Domande frequenti

Come posso impedire alla direzione di utilizzare il parametro della velocità contro il mio team?

Mantenete questo dato all’interno del team. La velocità è un dato di input per le previsioni, non un indicatore di performance: la ricerca DORA la esclude deliberatamente poiché i punteggi non sono comparabili tra i vari team. Se un manager esterno al team vi chiede se la vostra velocità sia buona, la risposta onesta è una controdomanda: cosa state effettivamente cercando di misurare? Riferite i risultati e le consegne, non i totali dei punti.

Un feedback retrospettivo può essere utilizzato a mio sfavore in una valutazione delle prestazioni?

Succede, e il timore è razionale: i partecipanti riferiscono che i commenti sinceri espressi durante il retro emergono nuovamente mesi dopo sotto forma di osservazioni secondo cui si lamentano troppo. Si tratta del cosiddetto “feedback banking”, ed è proprio per questo che esistono l’anonimato, l’esclusione dei manager e la “regola di Las Vegas”. Una retrospettiva in cui la franchezza rappresenta un rischio per la carriera non è psicologicamente sicura, e nessuna tecnica di facilitazione può porvi rimedio. Si deve intervenire sulla struttura del potere, non sulla formulazione.

Come posso evitare che le stime si trasformino in scadenze?

Distinguete chiaramente, a voce alta e in modo consapevole, tra la stima e l’impegno. Una stima è una probabilità; un impegno è una promessa; confondere l’una con l’altro e poi pretendere che il team vi si attenga è ciò che compromette la fiducia. Prevedete un intervallo, specificate le ipotesi e non permettete mai che un’ipotesi formulata durante una riunione di pianificazione venga poi citata come una data a cui il team si è impegnato a rispettare.

Il mio responsabile dovrebbe partecipare alla retrospettiva o condurre la riunione quotidiana?

In linea di massima, no. La Guida allo Scrum definisce la retrospettiva come un’occasione in cui il team esamina se stesso, mentre il daily stand-up è inteso come momento di coordinamento tra gli sviluppatori stessi. La presenza di una figura autoritaria nella stanza non ha bisogno di proferire parola per inibire la sincerità: chi approva le promozioni rappresenta di per sé un fattore che incute timore. Condividete le azioni da intraprendere con i livelli superiori, non i posti a sedere.

Letture correlate

• Il vuoto del seguito — dove si incontrano il riscontro accumulato e l’impotenza.
• Spettacolo: la cerimonia che si mette in scena per il pubblico — il teatro che il Potere rende coercitivo.
• Velocità: a cosa serve e come calcolarla — utilizzare questo dato per le previsioni, mai per la valutazione.
• Story point contro ore — perché la conversione favorisce la manipolazione delle stime.
• Pianificazione dello sprint (la cerimonia) — in cui la stima deve rimanere una previsione di cui il team è responsabile, non un impegno.
• Come creare uno spazio psicologicamente sicuro — una franchezza che non dipenda dalle persone presenti nella stanza.
• Glossario del Teatro Agile — Definizioni di “riciclaggio delle stime”, “accumulo di feedback” e “ratchet della velocità”.