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 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 darà i risultati sperati, ma si ribalterà. Inizierà 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à

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 in base alla qualità delle stime o alla 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 a cricchetto della velocità è il modo in cui si verifica tale danno. 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 la velocità esce dal contesto come obiettivo di produttività, si trasforma in un meccanismo a cricchetto: il valore dello sprint precedente diventa il limite minimo per lo sprint attuale, 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 storia 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 è rappresentata dal DORA. Un decennio di ricerche su quali fattori predicono le prestazioni nella consegna del software ha portato all’individuazione di quattro metriche chiave (frequenza di distribuzione, lead time, tasso di fallimento delle modifiche e tempo di ripristino), e la “velocity” non è tra queste; gli story point non sono comparabili tra i vari team e misurano lo sforzo, non il valore fornito. 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 dato. La risposta onesta è: «Cosa sta effettivamente cercando di misurare?». Il nostro capitolo dedicato alla velocità illustra come mantenerla onesta, mentre la pianificazione della velocità e della capacità mostra 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».

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 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 invece si dice «sono dieci punti», per ragioni che nessuno riesce a giustificare appieno, lo stesso istinto non scatta. Gli story point erano stati concepiti in parte proprio come una protezione contro quella pressione, e il “riciclaggio delle stime” è la pressione che sconfigge tale protezione convertendo i punti direttamente in una data.

Il rimedio canonico è 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, esprimendoli ad alta voce. Prevedete un intervallo e specificate le ipotesi su cui si basa. E prestate attenzione al caso di accumulo. 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 un approccio agile basato sulle 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 dedicato ai story point rispetto alle ore spiega perché la conversione rappresenti una causa di 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 Lei in modo discreto: durante una valutazione delle prestazioni, una revisione dei bonus o una conversazione informale sull’«adeguatezza». La valutazione 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 come il feedback negativo gli sia stato rinfacciato 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 poi 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 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 dedicato ai motivi per cui 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, che ha studiato 180 team nell’arco di due anni, 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 allo Scrum definisce la retrospettiva come il momento in cui il team esamina se stesso. Allora perché il manager presente nella stanza prende 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: si 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 in carica. Uno scudo non è un sistema. Se l’onestà delle vostre cerimonie dipende dalla disponibilità di un singolo manager ad assorbire la pressione, non disponete di 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 entità fissa. Il capitolo dedicato alla sicurezza psicologica tratta della creazione di un clima di franchezza che non dipenda da chi si trova nella stanza, mentre la Direttiva Primaria riguarda la norma che ne garantisce la permanenza. Quando la cerimonia formalizzata finisce per produrre nient’altro che apparenze controllate, si giunge al vuoto di attuazione: 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. Non rientra tra le metriche di consegna di DORA e, in ogni caso, i punti 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 di 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 citata come una data a cui il team si è impegnato a rispettare.

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

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 può, anche senza proferire parola, inibire la sincerità. La persona che approva le promozioni rappresenta, di per sé, un fattore che incute timore. Condividete le azioni da intraprendere con i livelli gerarchici superiori, non i posti a sedere.

Approfondimenti

• Il vuoto del follow-through: il punto d’incontro tra 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 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 questa fase, 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 dell’agile theatre: “estimate laundering”, “feedback banking” e “velocity ratchet”: definizioni.