Nel mezzo del cammin di nostra vita…

Per il titolo di questa serie di articoli abbiamo preso a prestito i versi del sommo poeta per tentare di comprendere perché “la diritta via era smarrita”. Succede infatti a volte che aziende che hanno intrapreso un processo di trasformazione agile si ritrovino a un certo punto “in una selva oscura”, laddove, proprio come per Dante, la prospettiva non appare più chiara e definita.

Come mai, dopo una partenza brillante, soldi spesi in formazione, ingaggio di coach esterni, organizzazione di team Scrum, progettazione di kanban board, bozze di modelli di scaling, poi le organizzazioni iniziano a rallentare o interrompere l’applicazione delle buone pratiche, dei ruoli, della filosofia di base? Quali possono essere i comportamenti che frenano e quali quelli che ne favoriscono il processo di adozione? Ci sono differenze nelle strategie — e negli errori — in una azienda da 20, 200, 2000 o 20000 persone?

Ecco, cercheremo di parlare proprio di questo, ma non solo. Cominciamo quindi a vedere qualche situazione tipica in cui “la diritta via era smarrita”.

Perdita di controllo (delle persone)

Fra le molte situazioni che possono rappresentare un freno al processo di cambiamento, ci sono gli atteggiamenti legati al modello organizzativo e alla implementazione della linea di comando/delega.

Spesso tali atteggiamenti sono freni proprio a causa di errate convinzioni o erronee valutazioni sugli impatti che il “modello agile” si dovrebbe portare dietro: e quando scriviamo “modello agile” diamo ormai per acquisita la consapevolezza che non esiste una soluzione “già pronta” e buona per tutte le occasioni, da rivendere a qualsiasi azienda; ma che ogni realtà deve sviluppare una sua cultura organizzariva, basata su principi agili e pratiche ben assimilate.

Una tipica lamentela che arriva dal management, a diversi livelli, è che “con Agile non c’è più controllo; i team andranno in anarchia e ne conseguirà una totale perdita del controllo di quello che stanno facendo le persone”.

Da un lato, possiamo certamente dire che questo genere di allarmismo è ingiustificato: in Scrum, per esempio, le regole da rispettare ci sono eccome e non è vero che si perde il controllo della situazione. Ma la domanda da porsi è piuttosto: “Come mai si pensa che sia così importante controllare cosa fanno le persone?”.

Spostare il focus dagli strumenti di controllo verso il prodotto finale

Un manager, un responsabile di area, un “capo” non dovrebbe forse avere a cuore a che punto è lo sviluppo di un prodotto? Sapere cioè se è in linea con le tempistiche, se ci farà guadagnare o se lo sviluppo richiede costi troppo alti…

Spesso i manager hanno sviluppato la loro attività soprattutto nel senso del controllo, e degli strumenti tradizionalmente utilizzati per gestire il controllo. I responsabili di progetto, abituati a tenere minuziosamente conto di ogni aspetto riguardante il gruppo di lavoro — chi fa cosa, a che ora e per quando — si trovano a disagio con un team che si auto-organizza e con la mancanza di un Gantt con i carichi e gli incarichi.

Spesso infatti vediamo atteggiamenti del tipo “Vorrei vedere nel dettaglio ogni singolo aspetto del backlog”, oppure “Mi fate vedere tutte le storie del backlog e chi le fara?”.

Il backlog di un progetto Scrum, per sua natura, invece è un oggetto vivo, dove troviamo un sacco di dettagli puntuali (storie piccole e relativi task) accanto a elementi grossi e poco definiti (le epiche o i temi).

Un commento che spesso ascoltiamo è “Avevo chiesto ai team che mi compilassero per bene tutte le storie perché non so come sta andando il progetto; ma, ora che mi hanno fatto vedere, non sto capendo. Questo modo di organizzare il progetto non mi è utile”.

L’osservazione è corretta: il backlog operativo non è pensato per fornire questo tipo di informazioni. Non deve dire agli stakeholder cosa sta succedendo, come verrà implementata la singola funzionalità o se il pulsante di avvio sarà in alto a destra e sarà arancione. Queste cose sono oggetti dell’interesse e del focus del Product Owner che ha in carico proprio la cura di questi aspetti.

Ma i responsabili di progetto non dovrebbero concentrarsi sul dettaglio del prodotto, né sul formato con cui requisiti e componenti sono descritti. Dovrebbero invece richiedere la presenza di una vista di alto livello, la roadmap di prodotto con milestone, e relativi costi di produzione per ogni step di milestone, con i benefici prodotti ad ogni rilascio e così via.

Vorrei questo perché mi dimentico di cosa dovrei realmente fare

Se da un lato la mania del controllo è un impedimento perché impone al team scelte e approcci che sono utili solo per controllare quello che il team fa, ma non per migliorare tempi e qualità del valore rilasciato, dall’altro il controllo diventa una distrazione per le persone del business che spesso finiscono per dimenticare il loro compito principale: indicare la destinazione e aiutare a tracciare la rotta.

Tradotto in maniera più esplicita, potremmo dire che un “capo”, quale esso sia, dovrebbe dare indicazione sulla vision dell’organizzazione, l’obiettivo di alto livello e quello di prodotto. Dovrebbe pretendere dal PO una roadmap di rilascio, con macro-milestone. E, conseguentemente, dovrebbe supportare la creazione e l’aggiornamento di un portfolio di alto livello, e il coordinamento fra linee di prodotto affinché sia possibile rispettare le macroscadenze.

Quando questo manca, spesso vediamo l’insorgere anche di un’altra serie di impedimenti: la mancanza del “fuoco sacro” che spinge il team verso il miglioramento continuo.

Miglioriamo continuamente! Miglioriamo continuamente?

Uno dei fondamentali principi ispiratori di un team Scrum — o più genericamente di chi segue un approccio Agile — è quello del miglioramento continuo. Un team dovrebbe sempre trovare il modo per migliorare qualcosa del suo modo di lavorare: aumentare la qualità, ridurre i tempi di risoluzione dei bug, accorciare i tempi di rilascio, accrescere la soddisfazione utente.

Purtroppo spesso accade che il team, dopo un primo periodo di “messa a punto” delle evidenti problematiche di processo, si fermi e non proceda ulteriormente nel miglioramento. Se inizialmente i problemi appaiono evidenti e i possibili margini di miglioramento risultano ampi, non appena le cose rientrano sotto la soglia di allarme — “OK, le cose adesso vanno abbastanza bene” — ci si interrompe nella continua ricerca di miglioramento.

Per esempio, se prima non si riuscivano a chiudere 10 storie (o 40 punti) a sprint, adesso che ci si è arrivati vicino grazie ai grossi sforzi, il team si “adagia” sugli allori.

Il livello della prestazione

In questo contesto è anche difficile comprendere se il team sta lavorando “abbastanza”oppure se il principio del ritmo sostenibile sia preso a pretesto per vivere tranquilli senza troppi affanni. Spesso sentiamo manager che si chiedono — e chiedono a noi — “Ma, secondo voi, il nostro team potrebbe fare di più? Non vi pare che siano un po’ troppo rilassati?”.

Rispondere immediatamente con un “sì” o con un “no” non è affatto facile e rischia di non prendere in considerazione tutto quello che nella domanda non viene chiesto. Dovremmo infatti rispondere almeno a un altro paio di interrogativi:

• “Ma questo livello di performance va bene abbastanza?”
• “I costi di produzione — costi diretti del team e indiretti infrastrutturali — sono compatibili con quanto viene prodotto sprint dopo sprint?”

Un rapporto tra costi e benefici

Detto altrimenti, e supponendo di lavorare in Scrum, se il team sta andando ad una determinata velocity, più che chiedere di stressare il team per aumentare tale velocity, abbiamo sotto controllo alcuni indicatori come il rapporto costo di produzione/ricavi-benefici? Invece che preoccuparsi di quante cose il team stia facendo, abbiamo idea del valore rilasciato e della relativa roadmap di valore? Perché magari potrebbe essere che la velocity sia bassa e che il team rilasci poche cose ma che il valore di quanto viene rilasciato sia altissimo: il cliente è contento, il progetto va bene.

Abbiamo provato a valutare il costo del ritardo prima di chiederci se stiamo andando piano o forte? Vale a dire: “Se rilasciassimo più velocemente, quali sarebbero i reali benefici che potremmo ottenere?” Normalmente questa domanda scatena una serie di dubbi e perplessità, se non addirittura nervosismi e critiche: sono infatti domande a cui non è banale rispondere. E allora è certamente più facile imporre al team di andare più veloce.

In fondo… va bene così

La mancanza di una pressione dettata da obiettivi di business, che vada oltre il semplice “Dobbiamo lavorare di più e più in fretta”, spesso si traduce in team che pensano di essere già abbastanza bravi e che quindi non sentono l’urgenza di migliorare ulteriormente.

Qui si aprono due temi: il primo è che ogni esperimento o tentativo per lavorare meglio — per esempio l’introduzione di nuove pratiche di test o il passaggio a un nuovo strumento di lavoro — deve essere avallato e supportato da chi chiede il miglioramento. Se un manager chiede al team di migliorare, dovrà sostenere l’esperimento e accettare che esso possa anche non dare i risultati sperati. Chi spinge per il miglioramento non deve solo sostenerlo esternamente, ma deve anche, in tutto e per tutto, essere parte di quell’esperimento.

L’approccio potrebbe essere una cosa del genere: “Vorrei che provassimo a migliorare questo aspetto (tempo medio di chiusura di bug, time to deploy etc.). Cosa possiamo fare? Cosa proponete? Cosa ci aspettiamo che succeda se le cose vanno bene? E se vanno male? E, nel caso l’esperimento fallisse, come possiamo limitare i danni? Cosa posso fare io per aiutare l’esperimento?”.

In assenza di questo approccio è piuttosto facile vedere il team che smette di sperimentare. La proattività, tanto decantata a parole, deve essere alimentata e sostenuta, non solo richiesta.

La seconda cosa che un manager dovrebbe fare per evitare che il team smetta di migliorare, è dare il senso, ossia fornire l’urgenza e la necessità di tale miglioramento, senza che sia solo stress.

Deve avere le risposte a domande del tipo:

• “Perché ora non basta quanto stiamo facendo?”
• “Come mai dovremmo fare di più?”
• “Tutto sommato le cose vanno bene; perché dobbiamo aumentare il passo?”
• “E se trovassimo un modo per provare a crescere, ma le cose inizialmente andassero peggio — in fondo, come tutti gli investimenti, all’inizio sono spesso un costo — che succede?”
• “Abbiamo il supporto del management?”

Quindi, fra le cause del fatto che la crescita rallenta, c’è sicuramente da un lato la mancanza di una visione sui motivi per proseguire e sulla necessità di investire (l’urgenza), dall’altro l’assenza di un adeguato supporto da parte di chi richiede il miglioramento. Ricordiamoci che non può essere solo un “Abbiamo bisogno che facciate di più” ma deve diventare un “Troviamo tutti insieme il modo per fare di più”.

Conclusione

Questo mese abbiamo introdotto il tema dei freni al cambiamento. Abbiamo posto il focus sulle responsabilità al livello del management nei confronti del cambiamento organizzativo. Nelle prossime puntate vedremo altri tipici antipattern che possono provocare rallentamenti alla trasformazione.