La stessa dashboard può controllarti o liberarti. Dipende da chi la legge

«La domanda da farsi davanti a qualsiasi cruscotto non è "è bello?" e nemmeno "è preciso?". È: a chi serve?»

Prendi una dashboard qualsiasi. Numeri, colori, qualche trend. Ora fatti una domanda che sembra banale e non lo è: per chi è fatta? Perché la stessa dashboard, con gli stessi identici dati, può essere due strumenti opposti. Uno che genera controllo. Uno che genera autonomia. La differenza non è nel cruscotto. È nel destinatario.

Quando i segnali sono chiusi in uno strumento del Management, e servono a decidere quando intervenire, quella dashboard produce controllo. Diventa un sistema di allarme: finché i numeri sono verdi si lascia correre, quando diventano rossi si entra. È una logica difensiva, e in certi momenti va benissimo. Ma ha un difetto strutturale: arriva sempre dopo. Fotografa un effetto già avvenuto.

C'è un'altra strada. Portare gli stessi segnali nello spazio comune, dove passano i team, il Product Owner, lo Scrum Master, chiunque lavori davvero sul prodotto. Renderli leggibili anche da chi non li ha costruiti. In quel momento la dashboard smette di essere un cruscotto privato e diventa quello che nel gergo Agile si chiama information radiator: un artefatto che dice come stiamo messi senza che nessuno debba chiederlo. Il termine non è mio: è di Alistair Cockburn, che chiamava così l'informazione esposta nello spazio comune, quella che leggi di passaggio, per distinguerla da quella che invece devi andare a chiedere a qualcuno.

Non è la stessa cosa, anche se sembra

Vale la pena tenere separate due parole che spesso usiamo come sinonimi. Una dashboard può benissimo essere uno strumento riservato, pensato per chi sorveglia. Un information radiator, no. Funziona solo se l'informazione è nello spazio condiviso e riduce il bisogno di chiedere "come siamo messi?". La forza non sta nel contenere dati. Sta nell'esporli in modo abbastanza chiaro da poter essere letti di passaggio, da chi lavora, da chi decide, da chi collabora.

Raffaele Mastantuoni, in un pezzo sulla capacità comunicativa degli information radiator, e Fabio Lisca, scrivendo su cosa c'entrino davvero con Agile, insistono sullo stesso punto da angolazioni diverse: mettono al centro la funzione comunicativa e di visibilità dell'artefatto. Non contano perché misurano. Contano perché fanno vedere. E far vedere, in un sistema di lavoro, è già un atto di governo.

Il punto non è estetico, è organizzativo

Trasparenza, ispezione e adattamento, i tre pilastri su cui Scrum dichiara di reggersi, non sono possibili se lo stato del lavoro non è leggibile. Sembra ovvio detto così. Nella pratica lo dimentichiamo di continuo, perché costruiamo strumenti bellissimi e poi li teniamo in un posto dove li guarda solo chi comanda.

Se i segnali restano lì, il sistema produce controllo. Qualcuno osserva, qualcuno interviene, gli altri aspettano l'intervento. Se invece gli stessi segnali diventano comprensibili anche ai team, succede una cosa diversa: le persone cominciano ad autoregolarsi. Vedono l'andamento prima che diventi un caso, aprono una conversazione, correggono la rotta senza aspettare che qualcuno scenda dall'alto. Lo strumento è identico. La governance che genera è opposta.

I numeri economici non bastano

C'è un'ultima trappola, ed è la più sottile. Molte dashboard mostrano soprattutto indicatori di risultato: fatturato, margine, consegne. Sono i cosiddetti lag indicator, e hanno un limite onesto: fotografano qualcosa che è già successo. Quando il numero diventa rosso, il fatto è compiuto.

Un buon information radiator non si limita a dire che qualcosa è andato male. Mostra abbastanza presto cosa sta cambiando. Per farlo servono anche lead indicator, segnali che precedono il risultato: la qualità del backlog, quante decisioni nascono davvero dai rituali, il grado di autonomia di un team, la sua capacità di correggersi da solo. Roba meno spettacolare di un grafico di fatturato, ma che parla prima. E parlare prima, in un sistema, vale più che avere ragione dopo.

Faccio un esempio concreto, di quelli che capitano. Un team ha un calo di qualità: aumentano i bug, rallentano le consegne. Se l'unico segnale è il numero di difetti che il Management guarda a fine mese, la conversazione parte quando il danno è fatto, e parte dall'alto, con il tono di chi chiede conto. Se invece il team ha davanti, ogni giorno, un segnale che precede quel calo, per esempio quanto lavoro entra in sprint senza essere davvero rifinito, allora la conversazione può nascere prima, dentro il team, con il tono di chi si corregge. Stesso fenomeno, stesso dato di fondo. Cambia solo chi lo vede e quando. E cambia tutto.

La domanda da farsi davanti a qualsiasi cruscotto, allora, non è "è bello?" e nemmeno "è preciso?". È: a chi serve? Se serve al Management per sapere quando entrare, resta uno strumento di controllo, legittimo ma sempre in ritardo. Se aiuta i team a vedere prima l'andamento del proprio lavoro, allora diventa un supporto alla responsabilità distribuita. Lo stesso oggetto, spostato di stanza, cambia natura.

Per me è una delle scelte di governance più sottovalutate che ci siano. Non decidiamo quasi mai in modo esplicito chi ha diritto di vedere lo stato del lavoro. Lo decidiamo per abitudine, e quasi sempre l'abitudine è tenerlo in alto. Sul piano degli strumenti, portarlo nello spazio comune richiede quasi niente. Cambia parecchio in termini di chi, nel sistema, può prendersi una responsabilità senza aspettare il permesso.

Riferimenti

• Alistair Cockburn, Crystal Clear
• Raffaele Mastantuoni, «La capacità comunicativa degli information radiator» (2022)
• Fabio Lisca, «Cosa hanno a che fare gli Information Radiator con Agile» (2023)
• Ken Schwaber, Jeff Sutherland, La Guida a Scrum (2020)