Il potere: quando l’autorità si appropria 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 approva le promozioni, un indicatore che viene trasmesso ai livelli superiori, una stima che si cristallizza 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ò avviene, poiché individuarli è il primo passo per rifiutarli.

Il cricchetto di velocità

Iniziamo con l’argomento più incisivo di tutti: la persona che ha inventato gli “story point” li ha smentiti. «Mi piace dire che potrei aver inventato gli “story point”, e se così fosse, ora me ne rammarico», ha scritto Ron Jeffries nel 2019. È stato molto chiaro: «Ritengo che confrontare i team sulla base della qualità delle stime o della velocità sia dannoso». Quando l’inventore di un’unità di misura afferma che essa viene utilizzata per danneggiare i team, l’onere della prova ricade su chiunque continui a utilizzarla come parametro di valutazione.

Il meccanismo di aumento progressivo della velocità è il modo in cui tale danno si manifesta. La velocità è concepita come uno strumento di autocalibrazione interna del team: la media mobile dei punti completati, utilizzata per prevedere il tempo necessario per evadere il backlog. Nel momento in cui esce dalla stanza come obiettivo di produttività, diventa un meccanismo a cricchetto: il valore dell’ultimo sprint 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 era un 3 nel trimestre scorso è un 5 in questo trimestre, il numero sale, e nulla viene consegnato più rapidamente. Persino Mike Cohn, l’autorità a favore dei 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 limiti è 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 deliberatamente esclusa da tali metriche, 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 di quel numero. La risposta onesta è: «Cosa sta 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, poiché 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 emerge una scadenza; e quando la scadenza non viene rispettata, la colpa ricade sullo sviluppatore per aver «mancato la propria stima».

I professionisti descrivono l’intero ciclo di “riciclaggio” senza che sia necessario sollecitarli: le stime si trasformano magicamente in impegni e, se non si raggiunge l’obiettivo, 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 del tutto, lo stesso istinto non scatta. Gli story point erano in parte concepiti come una difesa proprio contro quella pressione, e il «riciclaggio delle stime» è la pressione che sconfigge tale difesa convertendo i punti direttamente in una data.

Il principio correttivo canonico è quello di Mike Cohn e precede la 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 «compounding». 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 sotto mentite spoglie. Dave West di Forrester ha definito questo fenomeno «water-scrum-fall», e il “riciclaggio delle stime” ne è 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 onesti raccolti durante una retrospettiva vengono accumulati e successivamente utilizzati contro di Lei in modo discreto: in occasione di una valutazione delle prestazioni, di una revisione dei bonus o di una conversazione informale sulla “compatibilità”. La retrospettiva viene presentata come uno spazio sicuro in cui esprimersi con franchezza. Il «feedback banking» è la scoperta che la sincerità 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 necessariamente dire una parola nella sala. La sua sola presenza è sufficiente a rendere vaghi i contributi sinceri 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 la sincerità 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, che ha studiato per due anni 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 sta prendendo 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 lead, un EM con carattere) protegge personalmente il team: si rifiuta di trasmettere la velocità ai livelli superiori, ridefinisce le stime come previsioni e mantiene i contenuti del retrospettivo all’interno della stanza. 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 stabilità. Quando la cerimonia formalizzata finisce per produrre nient’altro che apparenze controllate, si è giunti al vuoto di seguito: 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à a sfavore del mio team?

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

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

Succede, e la paura è razionale. I partecipanti riferiscono che i commenti sinceri espressi durante le sessioni di retrospettiva riaffiorano 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 la rispetti è 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 citata come una data alla quale il team si è impegnato a rispettare.

Il mio responsabile dovrebbe partecipare alla retrospettiva o condurre la riunione stand-up?

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 rappresenta il momento di coordinamento tra gli sviluppatori stessi. La presenza di una figura autoritaria nella stanza può bastare, senza bisogno che pronunci una sola parola, a scoraggiare la sincerità. La persona che approva le promozioni costituisce, di per sé, una presenza che incute timore. Condividete le azioni da intraprendere con i livelli superiori, non i posti a sedere.

Approfondimenti

• Il vuoto del seguito: il punto in cui si incontrano il feedback 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 valore 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: franchezza che non dipenda dalle persone presenti nella stanza.
• Glossario del Teatro Agile: “riciclaggio delle stime”, “accumulo di feedback” e “ratchet della velocità”: definizioni.