# My Agile Stories
> Storie e pratiche sull'Agile tratte da storie vere. Un diario aperto a chi lavora con l'Agile e ha una storia da raccontare.
Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts.
Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`).
## Pages
### Glossario
URL: https://myagilestories.com/glossario/
Last updated: 2026-09-03T14:22:16.000Z
Questo non è un dizionario. Un dizionario promette definizioni esaustive e neutre; qui trovi un glossario, cioè un insieme curato di termini, situati nel lavoro da cui vengono. Le voci sono brevi e crescono con gli articoli: ognuno può aggiungerne una o precisare una vecchia. Se una voce ti sembra più situata che neutra, è voluto: conta il senso che una parola prende sul campo, più della sua definizione da manuale. Qualche voce definisce una parola nata qui, scrivendo. Una parola così sta in glossario a una condizione: che un articolo pubblicato la usi come termine portante.

## Accountability (rispondere di una scelta)

Accountability non vuol dire essere colpevoli, e non vuol dire fare più di tutti. Vuol dire rendere esplicito chi sceglie, chi opera, chi valida e chi si prende le conseguenze. Finché restano nella testa di una persona sola, il sistema sembra funzionare. Poi quella persona manca, e scopri che l'accountability era solo inseguimento privato.

## Agile

Per me, prima di un metodo, è una direzione: tenere il lavoro leggibile e pronto a cambiare quando cambia quello che sai. È nato come la scelta di un gruppo di persone che non si ritrovava più nel modo in cui si costruiva software: un movimento. E la parola dice già molto, perché agile è qualcosa che si muove. Quando diventa un'etichetta da esibire, «facciamo Agile», o un pacchetto di cerimonie calato dall'alto, ha smesso di muoversi. Conta più l'aggettivo del sostantivo: lavorare in modo agile, prima che «fare Agile».

## Backlog

Non lo tratto come una lista di cose da fare. Per me è il posto dove si vede chi decide, chi lavora, chi valida e chi si porta dietro un impedimento. Quando serve solo a controllare chi sta facendo cosa, ha smesso di essere governance ed è diventato arredamento.

## Efficacia ed efficienza

Le tengo separate perché è comodo farle passare per la stessa cosa. L'efficienza mi dice se sto facendo bene un lavoro; l'efficacia se sto facendo il lavoro che vale la pena fare. Una lista, una dashboard, una milestone mi aiutano sulla prima. Per la seconda devo guardare gli outcome, e chiedermi se è migliorata la qualità delle decisioni.

## Governance

Governance è il modo in cui un'organizzazione stabilisce dove si prende una decisione e come il resto del lavoro viene a saperlo. Quasi mai è scritta da qualche parte: si impara guardando com'è andata l'ultima volta, e cambia insieme alle persone che ci sono. Per questo un gruppo può cambiare tutte le cerimonie del calendario e continuare a decidere esattamente come prima.

## Impedimento

Un impedimento blocca un lavoro e chi lo sta facendo non può toglierlo da solo: un accesso che non arriva, una scelta che spetta a un'altra area. La difficoltà tecnica non lo è, quella è il lavoro. La distinzione mi serve perché un impedimento non si scioglie con l'impegno di chi lo subisce: deve passare di mano, con un nome e una data. Senza quelle due informazioni resta un tema di cui si parla.

## Information radiator (radiatore informativo)

È un cartellone, una lavagna o uno schermo che mostra come sta andando il lavoro, messo dove le persone passano, in modo che si legga di sfuggita e senza chiederlo a nessuno. Serve prima di tutto a chi quel lavoro lo sta facendo: se ne accorge in tempo e può correggere da sé. Se per sapere a che punto siamo devo andare a chiederlo, non è un information radiator.

## Lead indicator e lag indicator

I lag sono il fatturato, i difetti di fine mese, e la bilancia se sono a dieta: dicono come è andata quando ormai è andata. Un lead invece lo posso ancora cambiare, e il lag ne dipende: quanto tempo una storia aspetta una risposta, quante volte a settimana mi alleno. Con soli lag sul cruscotto mi resta una mossa sola, entrare a numero già rosso; qualche lead accanto mi dice se c'è ancora margine per parlarne.

## Milestone

Una milestone mi interessa quando chiude un tratto di lavoro e mi costringe a fermarmi: guardare cosa è cambiato, capire se il sistema regge anche senza la persona che l'ha spinto. Non è una data elegante sulla roadmap. Se serve solo a far scendere task e scadenze, mi sta tirando nel dettaglio proprio quando dovrei tornare alla domanda più grande.

## Obiettivo-attività

Un obiettivo formulato come cosa da fare, «consegnare il nuovo sito entro giugno», anziché come cambiamento da ottenere. Si riconosce da una proprietà sola: ha stati di avanzamento e nessuna condizione che a fine periodo lo dichiari sbagliato. Lo uso più come domanda che come etichetta: davanti a un elenco chiedo che cosa potrebbe risultare falso, e conto le righe senza risposta.

## Owner

Owner è chi può dire cosa si decide, da cosa dipende quella decisione e cosa succede se non viene fatta. Non è il nome che scrivo accanto a un task. Quando manca, qualcuno compensa in silenzio e da fuori sembra un problema di organizzazione: è responsabilità che non ha ancora una casa.

## Product Owner

Il Product Owner decide in che ordine il lavoro viene fatto, e tiene in piedi la ragione di quell'ordine mentre il contesto cambia. Il termine si svuota quando quelle priorità sono già fissate un piano più su: il titolo regge e la delega no. Resta una sequenza che il gruppo esegue e che nessuno, dentro la stanza, sa più giustificare.

## Refinement

Non è la manutenzione del backlog. Serve a una cosa sola: che una persona possa prendere in mano un lavoro senza che qualcuno prima glielo traduca. Se dopo il refinement il lavoro dipende ancora da chi conosce il contesto, non ho raffinato niente, ho solo riscritto meglio.

## Retrospettiva

La retrospettiva è l'incontro in cui un gruppo guarda come ha lavorato nel periodo appena chiuso e sceglie che cosa fare diversamente in quello dopo. Ne esce un impegno che al giro successivo si può verificare. Dove si esaurisce nel raccogliere quello che ciascuno ha notato, diventa il posto più comodo dove rimandare, perché sembra che se ne sia già parlato.

## Scrum Master

Lo Scrum Master è il ruolo che in Scrum risponde di come lavora il gruppo: dagli accordi che il team si è dato agli impedimenti che gli restano addosso. Non ha nessuno alle proprie dipendenze, e la difficoltà sta lì, perché quello che ottiene lo ottiene chiedendolo. Per la stessa ragione è un ruolo difficile da valutare: il suo risultato porta sempre il nome di qualcun altro.

## Slicing (spezzare una storia)

Spezzo una storia quando è così grande o confusa che nessuno riesce a prenderla in mano senza farsela tradurre da chi conosce tutto il contesto. Non è fare tanti pezzetti per il gusto di farli. Una fetta è buona quando fa vedere presto qualcosa e lascia a qualcuno il modo di agire. Se moltiplica i ticket ma la decisione resta altrove, non ho ridotto il lavoro, ho solo distribuito la confusione.

## Working agreement

È il patto che un gruppo si dà sui propri comportamenti: quanto si aspetta una risposta prima di sollecitare, chi si avvisa quando si tocca qualcosa di condiviso, cosa succede se l'accordo salta. Nasce perché ognuno arriva con aspettative diverse e le crede ovvie. Un accordo scritto in valori, rispetto o fiducia, su un caso vero non dà niente da verificare; quello che regge dichiara comportamenti visibili, e le conseguenze.
### Racconta la tua storia
URL: https://myagilestories.com/scrivi-con-noi/
Last updated: 2026-07-17T15:53:59.000Z
Questo è un diario aperto. Se lavori con l'Agile e ti porti dietro una storia dal campo, una cosa che hai provato davvero e da cui hai tirato fuori una lezione tua, mi fa piacere leggerla. Il caso perfetto da manuale qui interessa poco. Quello che tiene una pagina è il vissuto, con le sue asperità.

## Cosa ci sta bene qui

Storie prese dal lavoro reale, più che teoria ripulita. Un problema visto da vicino, una pratica che hai messo alla prova sul serio e che ti ha lasciato qualcosa da raccontare. Va bene anche il dubbio non risolto: certe volte una domanda onesta tiene la pagina meglio di una risposta lucidata. Fatica invece a trovare spazio il pezzo che vende un metodo o gira largo attorno alle persone.

## Come proporre una storia

1. Mandami due righe sull'idea. Non serve il pezzo finito: mi basta capire di che storia parliamo e perché ti è rimasta addosso.
2. Ci sentiamo. Se l'idea ha una direzione, ne parliamo un momento e vediamo come tenerla in piedi: cosa vale la pena tagliare, dove serve un riscontro reale per non restare nella teoria.
3. La lavoriamo insieme. Da lì nasce una bozza, la rifiniamo con calma e, quando convince tutti e due, trova posto qui.

## Contatto

Due righe bastano per cominciare. Se ancora non conosci questo posto, fatti un giro tra le storie già pubblicate: capisci al volo il tono, e se ti ci ritrovi.

[Scrivimi](mailto:gaetano.frascolla@gmail.com)
## Posts
### Diamo per consegnata una decisione appena la spediamo
URL: https://myagilestories.com/diamo-per-consegnata-una-decisione-appena-la-spediamo/
Last updated: 2026-09-30T05:30:00.000Z
Scrivo una decisione in cinque righe. La mando a chi la porterà avanti. Poi passo ad altro. Da quel momento, per me, è consegnata. Il testo esiste, il destinatario ha un nome, la data è quella dell'invio. Sono tre cose che si controllano una per una, e tornano tutte. Fermarsi lì sembra pulito, perché quello che dipendeva da me è fatto.

Dove finisce la consegna, però, non lo stabilisce il testo. Lo stabilisce un'abitudine, e l'abitudine lo mette presto. Chi riceve la decisione non riceve le mie righe. Riceve quello che ne ha capito. Da lì ricava che cosa farà lunedì. Fra il testo e il lavoro c'è un passaggio in più, e in quel passaggio il contenuto si sposta.

## La lettura non lascia traccia

Quel passaggio non lascia niente dietro di sé. Chi esegue si costruisce una lettura, la usa e va avanti. Non ha motivo di scriverla. Per lui non è un'ipotesi, è la decisione. Dall'altra parte non arriva nulla, e l'assenza di domande viene contata come un accordo. Nessuno mette alla prova quell'accordo, perché metterlo alla prova costa una conversazione.

Così chi ha deciso resta tranquillo. La sua tranquillità non nasce da un riscontro. Nasce dal fatto che non è tornato indietro niente. Un silenzio dice poco. Può voler dire che il testo era chiaro. Può anche voler dire che chi l'ha letto ha rinunciato a chiedere, perché chiedere costa tempo a tutti e due e la risposta arriva domani.

> Il silenzio di chi ha ricevuto non è un accordo. È soltanto un silenzio.

Edgar Schein, in *L'arte di far domande*, lavora proprio su questo squilibrio. Chi afferma si mette un gradino sopra chi ascolta, e domandare costa a chi domanda. Il costo cresce con la distanza fra i due. Una decisione spedita è il caso estremo: arriva scritta, arriva da chi ha l'ultima parola e non prevede un turno di parola. Chi la legge paga per aprire bocca. Spesso preferisce provarci da solo.

## Nel caso che ho in mano la nota c'era

Un caso nostro ha spostato quel confine, e ne resta un'annotazione scritta. Il flusso in cui arrivavano le decisioni non dava il lavoro per chiuso appena la risposta era arrivata. La regola era esplicita. Chi riprendeva il lavoro doveva prima annotare come aveva letto la decisione ricevuta. Non era un consiglio: era una condizione per poter chiudere. Nel primo caso osservato la nota è stata lasciata davvero, e prima che il lavoro si chiudesse.

La regola aveva due parti, e la seconda è quella che pesa. Prima l'annotazione di chi eseguiva. Poi una verifica su quell'annotazione, come passo separato, collocata prima della chiusura e non dopo. È una differenza di posizione, e cambia la natura del controllo. Messo in coda avrebbe soltanto alimentato un archivio.

## Fin dove arriva questa prova

Quello che il caso dimostra è stretto, e conviene scriverlo in pagina. Dimostra che un criterio scritto può viaggiare insieme alla decisione. La nota c'era, ed era leggibile da una persona che non l'aveva scritta. Il criterio è arrivato. Non dimostra che il lavoro ripreso sia andato meglio: quel confronto nessuno l'ha fatto, e oggi non si ricostruisce.

## Sposto il confine di una riga

Per il lavoro che un gruppo consegna, la convenzione su quando una cosa è finita di solito esiste, ed è scritta. Regge perché sta scritta e non cambia da persona a persona. Per una decisione che sposta il lavoro di altri quella convenzione non l'ha messa giù nessuno. Si ferma all'invio. E ci troviamo d'accordo su questo senza averne mai parlato.

Spostarla in avanti costa una riga. Chi riceve scrive con parole sue che cosa farà, in due o tre frasi, nello stesso posto dove la decisione è arrivata. Chi l'ha presa legge quella riga. Se dice quello che intendeva, non risponde. Se dice un'altra cosa, correggere adesso costa un minuto. Fra tre settimane costa il lavoro già fatto.

> Una decisione arriva davvero quando torna indietro, riscritta con parole che non sono le mie.

La riga non è una conferma di lettura, e questa è la parte che si sbaglia più facilmente. Se ripete il testo ricevuto non aggiunge niente, perché si può ricopiare una frase senza averla capita. Deve essere una traduzione. Chi la scrive dice che cosa farà lui, con i nomi delle cose che ha davanti mentre scrive. È lì che le due letture si toccano, e quando non coincidono lo si nota senza doverlo cercare.

L'obiezione ovvia è che sia una formalità in più. Su gran parte delle decisioni lo è davvero. Molto di quello che decidiamo non chiede niente a nessuno: si capisce, si fa, finisce lì. Il metro che uso riguarda il costo di leggere male. Se una decisione tiene ferma una priorità nel backlog per due settimane, la riga si paga da sola la prima volta che serve. Se sposta la persona che risponde di un risultato, anche.

Un punto debole resta, e sta nella parte finale del giro. Se chi ha deciso legge e non risponde, siamo di nuovo davanti a un silenzio. La differenza è che adesso quel silenzio ha un oggetto stretto. Prima copriva tutto il testo spedito, ora copre due frasi che stanno scritte in un posto preciso. È ancora un silenzio che si può interpretare male. Ma è un silenzio che fra un mese qualcuno può rileggere.

Il segnale non arriva dalle decisioni contestate. Quelle si vedono, e si sistemano parlando. Arriva da quelle che nessuno ha discusso e che poi vengono eseguite in un modo che non riconosciamo. Lì il testo c'è ancora, identico, e non aiuta. Nessuno aveva scritto come l'aveva capita.

## Riferimenti

- Edgar H. Schein, *L'arte di far domande*
### Due nomi per un confine solo
URL: https://myagilestories.com/due-nomi-per-un-confine-solo/
Last updated: 2026-09-28T05:30:00.000Z
«Awareness» e «Acquisition». Si chiamavano così due fasi consecutive di un modello operativo. Nessun evento diceva quando una cosa passava dalla prima alla seconda. Non era successo niente, nel mezzo. C'erano due parole in fila.

Un'azione qualunque poteva quindi finire in tutte e due. Dipendeva da chi la registrava. I conteggi dicevano quante persone stavano in «Awareness» e quante in «Acquisition». Nessuno dei due numeri si poteva leggere, perché non si sapeva che cosa avessero contato.

C'era poi un secondo difetto, più difficile da vedere. «Acquisition» era una parola già in uso nel lavoro di tutti i giorni. Lì indicava l'acquisizione del contatto, cioè il punto che nel modello si chiamava «Capture». La stessa parola indicava due momenti diversi del processo, a seconda di chi la diceva. Nessuno dei due usi era sbagliato.

Un difetto così non produce errori. Nessuno sta sbagliando, quindi nessuno corregge niente. La discrepanza arriva dopo. Due persone guardano lo stesso numero e ne ricavano due cose diverse.

E non si vede finché si lavora a voce. A voce la distinzione la tiene chi parla, e chi ascolta la ricava dal contesto. Si vede quando qualcuno prova ad attribuire.

In quel caso si è visto due volte. La prima nelle misure, che non si potevano più attribuire a una fase o all'altra. La seconda nel lavoro di rifare un artefatto già prodotto.

## In asincrono il significato viaggia da solo

Un vocabolario ambiguo, in una stanza con dieci persone dentro, non è un problema. La traduzione avviene in tempo reale e non lascia traccia. Qualcuno chiede se intendiamo questa cosa o quell'altra, qualcuno risponde, si va avanti.

Poi il lavoro si sposta sulle richieste scritte e sui turni sfalsati. Lì la traduzione diventa un'attesa. Chi riceve una richiesta ambigua può interpretarla da sé. Rischia di fare la cosa giusta nel posto sbagliato. Oppure può chiedere. Allora il lavoro riparte quando chi sa la risposta trova il tempo di darla.

La parola difficile non c'entra: «Awareness» la capiscono tutti. Due parole chiare, una dopo l'altra, possono lo stesso non dire dove finisce la prima e comincia la seconda.

L'equivocità di cui scrive Karl Weick in *Senso e significato nell'organizzazione* è esattamente questo caso. I dati ci sono e ammettono più letture plausibili. Aggiungere dati non serve, perché ogni dato nuovo eredita l'ambiguità di prima. Si risolve mettendosi d'accordo su che cosa conta come che cosa. Due nomi che non separano niente danno quel problema a ripetizione. L'accordo non resta scritto. Si rifà ogni volta, con chi in quel momento è disponibile a rifarlo.

> Un confine che non separa niente non fa sbagliare nessuno. Sopravvive per mesi dentro un modello che tutti usano.

## «Raggiunto» e «Coinvolto»

L'artefatto è stato rifatto e i due nomi sono cambiati. «Awareness» e «Acquisition» sono diventate «Raggiunto» e «Coinvolto». Il termine che aveva già un altro mestiere è uscito dal modello.

I nomi nuovi sono due participi, e un participio registra una cosa già avvenuta a qualcuno. A separarli non è più il tipo di attività svolta, è un evento: l'arrivo su una proprietà controllata.

Un evento ha una proprietà che un aggettivo non ha. È successo oppure no, e per stabilirlo non serve interpellare nessuno. Quando le fasi si chiamano così, attribuire diventa un gesto meccanico. I conteggi tornano leggibili. Una richiesta scritta dice da sola dove si trova una cosa, e chi è l'owner del passo successivo.

C'è un controllo brutale che si fa in mezz'ora. Si prendono gli ultimi venti elementi passati nel processo. Si chiede a due persone di assegnarli a una fase, ciascuna da sola. Possono usare soltanto quello che è scritto. Dove le due assegnazioni divergono, il confine sta nella testa di chi ha scritto il modello. Ci resta, finché qualcuno non lo scrive in una forma che regge anche senza di lui.

## Le parole si correggono finché sono ancora parole

Finché il modello è una bozza, cambiare il nome di una fase è una riga. Quando quel nome ha circolato per qualche mese, non è più una riga. Vuol dire rifare l'artefatto e le misure che ci stavano appese. E disfare l'abitudine di chi lo usava, che intanto aveva imparato a leggerlo a modo suo.

Il segnale da guardare arriva prima dei conteggi sbagliati. È una domanda che torna: qualcuno chiede se una certa cosa rientra in una fase o nell'altra. Finché la domanda trova risposta in giornata, il modello sembra reggere. A reggere però è la risposta, e va data di nuovo ogni volta.

Non tutte le parole di un'organizzazione devono reggere questo standard. Un nome vago in una fase esplorativa serve, e serve proprio perché non impegna. Il metro riguarda l'uso. Su certe parole si attribuisce del lavoro, si contano delle persone o si decide un passaggio di mano. Quelle parole sono infrastruttura, e vanno trattate come si tratta l'infrastruttura.

Il passaggio da «Awareness» e «Acquisition» a «Raggiunto» e «Coinvolto» sposta la parola dall'intenzione al fatto. Poi un elemento va assegnato a una fase, e non c'è nessuno a cui chiedere. Lì si capisce quale delle due coppie stava facendo il lavoro.

## Riferimenti

- Karl E. Weick, *Senso e significato nell'organizzazione* (1997)
### Ricostruire un lavoro cominciato da altri
URL: https://myagilestories.com/ricostruire-un-lavoro-cominciato-da-altri/
Last updated: 2026-09-23T05:29:59.000Z
Ogni volta che qualcuno entra in un lavoro già cominciato, una parte di quel lavoro deve ricostruirsela da sé. Quanta, cambia molto.

Dipende da quanto si riesce a capire da quello che è rimasto, senza spiegazioni. È una proprietà del lavoro. Si vede solo quando arriva qualcuno che non c'era. E quando si vede, finisce addosso a lui: è nuovo, gli serve tempo per ambientarsi.

## Le tracce ci sono, e l'ordine no

Qualche anno di lavoro insieme lascia molto materiale. Decisioni prese dentro uno scambio di messaggi. Documenti aggiornati due volte e poi lasciati lì. Un *working agreement* scritto quando serviva. Richieste chiuse con due parole di commento. Chi entra trova tutto questo, e lo trova tutto insieme.

Il materiale c'è. Quello che non arriva con lui è l'ordine in cui va letto. Quale documento vale ancora. Quale è stato superato da una conversazione di cui non resta niente. Quale pratica ha una ragione, e quale è rimasta in piedi per inerzia.

Un working agreement lo mostra in piccolo. Un gruppo scrive che una risposta si aspetta due giorni, prima di andare a cercare chi deve darla. Lo scrive perché in quel periodo due persone si erano pestate i piedi proprio lì. Qualche anno dopo la riga è ancora al suo posto, e le due persone no. Chi la legge legge una regola. Non ha modo di capire se è un residuo o una protezione che serve ancora. E la differenza cambia tutto quello che ci si può fare.

## Il lavoro di ricostruzione era un incarico

Quella ricostruzione può essere la prima cosa chiesta a chi entra, e non un effetto collaterale dei primi giorni. In un caso di cui resta una traccia scritta era organizzata così. Prima di cambiare qualunque cosa erano previsti colloqui con tutte le persone del gruppo. Il passaggio di consegne andava letto. Storia, ragioni delle pratiche, relazioni, dipendenze e questioni aperte andavano ricostruite una per una. Insieme a quel lavoro era chiesto di mappare quello che si imparava. E di proporre un proprio modo di tenerlo consultabile.

Di quell'ingresso la fonte dice questo, e si ferma qui. Dice che la ricostruzione era richiesta, e come era organizzata. Non dice come sia andata, né che cosa il gruppo ne abbia ricavato. Il limite vale la pena tenerlo scritto. Quello che la fonte prova è la richiesta. E la richiesta, da sola, dice già qualcosa. Qualcuno aveva capito che quel lavoro c'era, e che toccava a una persona farlo.

Si potrebbe obiettare che così si chiede di scrivere troppo, e l'obiezione regge. Gran parte di quello che una persona ricostruisce entrando non dovrebbe finire in nessun documento. Sono relazioni, toni, cose che si capiscono stando in una stanza. Un archivio che provasse a tenerle dentro diventerebbe un magazzino in cui non si trova niente. La distinzione utile è un'altra. Certe cose hanno bisogno di una persona perché sono fatte di persone. Altre ne hanno bisogno solo perché la loro ragione non è mai stata scritta accanto alla pratica che ne è nata.

## Dentro, quella lettura non si riesce a fare

Le ragioni per cui un gruppo lavora così vengono dette mentre il gruppo se le sta dando. Si dicono finché c'è ancora chi deve impararle. Poi smettono, appena le sanno tutti. Succede a un'informazione quando non serve più, e succede senza che nessuno lo decida.

> Le ragioni di una pratica circolano finché qualcuno ha bisogno di sentirsele dire, e dopo restano dentro chi le ha vissute.

Lyssa Adkins, in *Coaching Agile Teams*, mette il lavoro di comprensione prima di qualunque intervento. La ragione che ne dà riguarda il gruppo più di chi ci arriva, cioè la storia che quel gruppo ha alle spalle. Quella storia spiega quasi tutto quello che oggi fa in un certo modo. Chi entra deve andarsela a prendere. E mentre se la prende, sta anche stabilendo quanto di quella storia era a disposizione.

Per chi è dentro questa lettura non è disponibile, e non dipende dall'attenzione che ci mette. Non si stabilisce la distanza da un posto in cui si sta già.

## Un archivio completo può restare illeggibile

Il controllo che facciamo, quando lo facciamo, è se una cosa risulta scritta. È una domanda legittima, e ha una risposta rapida. Risponde però a un'altra questione.

Un lavoro può avere tutto scritto e restare illeggibile per chi ci arriva. Fuori dai documenti resta la parte che serve a leggerli. È una condizione senza nome, e per questo non finisce in nessun elenco di cose da sistemare. Somiglia piuttosto a un gruppo in salute.

Chi entra fa una cosa che nessun altro, lì dentro, è in grado di fare. Rimette in ordine un lavoro senza sapere già in che ordine vada. Le domande che ha dovuto porre a una persona, e non a un documento, hanno un valore preciso. Dicono quali parti di quel lavoro oggi reggono perché le persone giuste sono ancora al loro posto. Sono domande che nascono a ogni ingresso, e quasi sempre restano dove sono state fatte.

## Riferimenti

- Lyssa Adkins, *Coaching Agile Teams*
### Quello che decidiamo dicendo «lo vediamo in retro»
URL: https://myagilestories.com/quello-che-decidiamo-dicendo-lo-vediamo-in-retro/
Last updated: 2026-09-22T07:19:57.000Z
Fra la riunione che rimanda una questione e la retrospettiva dove dovrebbe essere trattata passano due settimane. In quelle due settimane la regola che vale per metà del gruppo continua a valere per metà del gruppo, e chi si era irritato lavora irritato.

Nella riunione, però, nessuno aveva l'impressione di star decidendo qualcosa. Qualcuno aveva nominato la cosa che scotta, per due o tre secondi non aveva parlato nessuno, poi era arrivata la frase: «lo vediamo in retro». E la riunione era ripresa, con un sollievo che si sente nell'aria.

Il sollievo è la parte onesta della scena. La questione non è stata negata, non è stata sminuita, e ha perfino un posto dove andare.

## Una frase che non mente

Chi la dice ha ragione. La retrospettiva esiste, serve proprio a guardare come stiamo lavorando, ed è il posto dove certi discorsi vanno fatti. Rimandare lì è formalmente corretto, e questo la rende diversa da tutte le altre forme di rinvio, che invece qualche giustificazione la richiedono.

Rimandare, poi, è spesso la scelta giusta. Decidere a caldo, con metà delle informazioni e le persone irritate, è un modo affidabile per prendere decisioni che dopo si dovranno disfare. Un gruppo che chiudesse ogni questione appena si apre farebbe più danni di quanti ne evita.

E la frase protegge chi la pronuncia, il che non è disonesto: nessuno è tenuto a prendere posizione adesso, davanti a tutti, mentre la temperatura è alta. Nomina un'istituzione del gruppo e le affida il peso, e obiettare diventa difficile senza sembrare quello che vuole litigare a tutti i costi.

Tutto questo è vero, e resta vero fino alla fine di questo pezzo. La frase però non dice niente delle due settimane in cui la questione aspetta.

## Quello che intanto va avanti

Una questione rimandata resta in funzione mentre aspetta il suo turno. Se il disaccordo era su una regola, la regola resta in vigore; se era sul modo in cui due gruppi si passano il lavoro, il lavoro continua a passare in quel modo.

Delle due strade possibili, insomma, una viene percorsa e l'altra aspetta. Non stiamo spostando la decisione più in là: la stiamo prendendo adesso, nella versione che non chiede a nessuno di sostenerla.

La cosa notevole è che nessuno esce da quella riunione pensando di aver scelto. Chi ha sollevato la questione crede di aver ottenuto un appuntamento. Chi non voleva parlarne crede di aver evitato una discussione. Hanno ragione tutti e due sul proprio pezzo, e intanto la cosa si decide altrove, sul calendario.

## Il vantaggio di chi non deve convincere nessuno

C'è una ragione per cui va quasi sempre da quella parte. Perché qualcosa cambi serve qualcuno che lo proponga, in un momento in cui proporlo è possibile, e che accetti di essere quello che riapre un discorso chiuso. Perché niente cambi, invece, è sufficiente che nessuno faccia niente.

> Un periodo intero in cui tutto ha retto è un argomento che nessuno ha dovuto pronunciare.

C'è poi un secondo effetto, e si vede solo alla fine dell'attesa. Quando la questione arriva finalmente in retrospettiva, è cambiata. Ha alle spalle settimane di lavoro comunque consegnato, e in qualche caso è perfino andata bene. A quel punto la domanda ha cambiato oggetto: riguarda se convenga cambiare una cosa che nel frattempo sta funzionando, e a una domanda così è molto più facile rispondere di no.

## Che cosa arriva davvero alla retrospettiva

Una retrospettiva è costruita per una materia precisa. Esther Derby e Diana Larsen ne descrivono la struttura come una sequenza di passi, che parte dai fatti raccolti, ne ricava una lettura condivisa e si chiude decidendo che cosa fare. Poche cose, alla portata di chi è nella stanza, da provare subito. La Guida a Scrum si muove nella stessa direzione quando dice che i miglioramenti a più alto impatto vanno affrontati il prima possibile, anche entrando nel lavoro dello sprint successivo.

È un attrezzo pensato per ciò che un gruppo può cambiare da sé, come il modo di passarsi il lavoro o un accordo che avevamo preso e non stiamo rispettando. Quello che le arriva dopo un rinvio, invece, spesso sta fuori da quella portata: è una scelta che si cambia altrove, e quasi mai chi può cambiarla è seduto lì dentro.

Allora la retrospettiva fa quel poco che può. Prende atto che la questione è ancora aperta, ci si scrive accanto un punto generico sulla comunicazione con la sua azione di miglioramento educata, e si va avanti. E il gruppo impara una cosa sbagliata, che impara benissimo: la retro non serve a niente. L'ho sentito dire molte volte, quasi sempre da gruppi che ci avevano portato dentro per mesi questioni che non le appartenevano.

Poi, alla retrospettiva ancora dopo, qualcuno dice che era una cosa di due settimane fa e ormai è andata. Lo dice senza cattiveria, e ha ragione. Quella frase conferma una decisione che avevamo preso senza accorgercene, quando abbiamo detto che l'avremmo vista dopo.

## Riferimenti

- Esther Derby, Diana Larsen, *Agile Retrospectives: Making Good Teams Great*
- Ken Schwaber, Jeff Sutherland, *La Guida a Scrum* (2020)
### Nessuno chiude un gruppo di lavoro: smette e basta
URL: https://myagilestories.com/la-fine-di-un-formato-si-progetta-come-il-suo-inizio/
Last updated: 2026-09-22T07:19:56.000Z
In un'azienda ci sono formati fissi: gruppi di lavoro che si riuniscono a cadenza regolare. Di quasi tutti si riesce a risalire al giorno in cui sono cominciati. C'è un annuncio, di solito una mail. C'è un incarico scritto da qualcuno che aveva l'autorità di scriverlo. C'è un posto fisso in calendario, e una persona che convoca. Della loro fine, invece, non resta quasi mai niente di simile.

Un formato smette di riunirsi. Poi smette di essere nominato. E prima o poi chiedere se esista ancora diventa una domanda scomoda, perché nessuno sa dire da quando la risposta è no. L'inizio lo trattiamo come un progetto, con tutta la carta che gli serve. La fine la trattiamo come una cosa che capita, e che consiste nel non fare più qualcosa. È una differenza che vale la pena guardare da vicino. Perché quello che quel formato teneva insieme continua a esistere anche quando nessuno si riunisce più.

## Togliere qualcosa passa per una non decisione

Aggiungere qualcosa a un'azienda si vede. L'oggetto nuovo ha un nome, occupa uno spazio, e per esistere ha dovuto chiedere il permesso a qualcuno. Togliere, invece, libera spazio e non sembra chiedere niente in cambio. È anche per questo che quasi nessuno lo mette per iscritto.

Il modo più frequente in cui una di queste cose finisce, per quello che ho visto, è una correzione. Chi guida il formato si accorge che sta assorbendo responsabilità che dovrebbero stare altrove. Lo dice. E aggiunge che, a quel punto, il gruppo formale potrebbe anche non servire più. È un'osservazione giusta, e chi la legge la prende per quello che sembra: una conclusione.

In quello che viene dopo, però, non compare nessuna delle cose che avrebbero reso quella conclusione una decisione vera. Una chiusura detta chiaramente, con una data. Una persona che risponde della chiusura. L'elenco dei lavori che passano di mano, e a chi passano. Un momento fissato per verificare che ci siano arrivati davvero.

## Il confine resta dov'era

Un formato fisso occupa un'ora in calendario, e quell'ora è la sua parte visibile. Quello che tiene insieme, però, è un *perimetro*, cioè un confine. Da una parte l'elenco delle domande che avevano un posto dove essere portate. Dall'altra le responsabilità che quel confronto non poteva prendersi.

Quando il formato si ferma, quel confine non si sposta da solo. Le domande continuano ad arrivare come prima. E si fermano dove trovano qualcuno disposto a prenderle. La differenza con un passaggio di consegne è tutta qui: un passaggio di consegne l'ha scritto qualcuno.

Il lavoro che quel formato faceva, del resto, consisteva soprattutto in tre cose. Leggere un problema. Decidere dove andasse trattato. E reggere il passaggio finché non ci arrivava. La riunione ne era la parte più piccola. Quando l'ora in calendario sparisce, quel lavoro non sparisce con lei. Cambia soltanto posto, e per strada perde l'incarico che aveva.

## Lo smontaggio ha già il suo elenco

Il documento che ha aperto quel formato gli aveva assegnato cose precise. E quelle cose sono ancora scritte da qualche parte. Un *mandato*, cioè un incarico. Un elenco di temi. Un posto fisso in calendario. Una persona che convocava, e qualcuno più in alto che rispondeva di quello che il gruppo faceva e non faceva. Ognuna di quelle voci, per essere sciolta, ha bisogno di una riga che dica dove passa. I temi a chi. L'*accountability* a chi. E da quando.

> Se un formato ha avuto un atto d'inizio, quell'atto dice già che cosa va restituito, e a chi.

Detto così sembra burocrazia, e in parte lo è. Con un'attenuante. Questa burocrazia è già stata fatta una volta, all'inizio, quando a nessuno pareva eccessiva. Rifarla al contrario porta via meno tempo di quanto ne consumi un confine lasciato aperto per mesi.

Nemmeno la letteratura, su questo lato, ci aiuta molto. Le otto tappe con cui John P. Kotter ordina una trasformazione, in *Guidare il cambiamento*, coprono per intero il lato dell'inizio. Si parte dall'urgenza e si arriva al radicamento nella cultura, che serve a rendere la cosa nuova difficile da disfare. Togliere compare, ma come mezzo: si rimuovono gli ostacoli che intralciano la visione nuova. Non c'è una tappa in cui l'oggetto del lavoro sia la fine di qualcosa. Il libro parla d'altro, e non glielo si può rimproverare. Resta però una spia utile. Anche gli strumenti con cui pensiamo il cambiamento sono costruiti quasi tutti sul lato dell'aggiunta.

## L'incarico è ancora in vigore

Per sapere a che punto sia una di queste cose non serve convocare nessuno. Si recupera il documento che l'ha aperta: la mail, oppure l'invito che tornava ogni settimana. E lo si rilegge come se valesse ancora. Se niente di quello che c'è scritto è stato contraddetto altrove, quel formato è ancora in piedi sulla carta. Quello che è successo davvero è che ha smesso di riunirsi.

Fra le due condizioni c'è una differenza pratica. Un formato in piedi che non si riunisce tiene occupato un confine e non lo governa. Le domande che gli appartengono restano sue sulla carta e di nessuno nei fatti. E chiunque provi a trattarle altrove lo fa senza averne il titolo. Un formato chiuso, invece, quel confine l'ha lasciato a qualcuno che se lo può prendere.

Chi apre un formato lascia dietro di sé abbastanza carta da poterlo disfare. Ed è il punto a nostro favore, in tutta questa storia. L'elenco delle cose da sciogliere è già stato scritto il giorno in cui la cosa è nata. E da allora sta fermo dove qualcuno l'ha messo. Quello che di solito manca è la riga finale. Quella che dice chi potrà dichiarare chiusa questa cosa, e da che cosa ci accorgeremo che lo è. Sono due righe, il giorno in cui si comincia. Scritte allora, valgono per tutta la vita del formato. Scritte dopo, non si scrivono quasi mai.

> Le due righe che chiudono un formato costano niente il primo giorno. Più tardi non le scrive più nessuno.

## Riferimenti

- John P. Kotter, *Guidare il cambiamento*
### Mentre l'organigramma cambia, l'azienda sta in piedi grazie a poche persone
URL: https://myagilestories.com/lo-stress-arriva-prima-dellorganigramma/
Last updated: 2026-09-17T08:12:16.000Z
L'organigramma nuovo è quasi sempre l'ultimo documento a comparire. Prima ci sono un annuncio, qualche riunione e una lista di nomi che gira in bozza. In mezzo passano settimane. In quelle settimane ogni domanda sul lavoro ha due risposte possibili e nessuna ufficiale. E il lavoro, intanto, non va in pausa. Le richieste arrivano con lo stesso ritmo di prima, e le scadenze restano dove erano.

## Fra l'annuncio e la struttura c'è un periodo di lavoro

William Bridges, in *Managing Transitions*, lo chiama zona neutra. È il tratto che si apre quando la forma vecchia non vale più e quella nuova non funziona ancora. È soprattutto un tratto di tempo. Comincia prima di quanto sembri. Dura. E finisce quando le persone hanno ricostruito da sole come si lavora. La durata dipende da quanto ci mettono. Quel tempo raramente compare nei piani della riorganizzazione, che si fermano al giorno dell'annuncio.

Per tutto quel tempo l'azienda continua a consegnare. E lo fa appoggiandosi a una struttura che sull'organigramma non c'è, per l'ottima ragione che quell'organigramma non è ancora scritto. La struttura provvisoria non la decide nessuno. Si forma richiesta dopo richiesta. E prende la forma dei rapporti che c'erano già. Si chiede a chi l'anno scorso lavorava su quella cosa. Si scrive a chi risponde in fretta. Funziona, e funziona abbastanza bene da spiegare una cosa. Perché una riorganizzazione quasi mai si vede nei numeri del trimestre in cui avviene.

## Il carico si sposta sui punti di contatto

Una struttura che nessuno ha scritto si regge su poche persone. E sono sempre le stesse: quelle il cui lavoro è fatto di collegamenti. A volte hanno un ruolo con un nome, un capo progetto o un referente di area. A volte non hanno nessun titolo. È semplicemente la persona che sa a chi si chiede una cosa.

Quando una responsabilità si sposta, queste persone lo sanno per prime. Non per intuito. Il loro lavoro sta esattamente sul punto in cui si è spostata. Un confine che cambia si presenta nella loro giornata in forme molto concrete. Un passaggio che prima non serviva. Un'approvazione che nessuno riesce più a dare nei tempi di sempre. Un collega che risponde «guarda, adesso non è più roba mia».

Il lavoro che serve a colmare quella distanza non ha un mittente. E non entra in nessuna stima. Si accumula nelle giornate di chi lo fa. E da lì non esce, se non nella forma in cui esce di solito. Quella persona è stanca, e lo dice tardi.

> Chi tiene insieme due parti di un'organizzazione se ne accorge prima di chiunque abbia il compito di disegnarne i confini.

## Quello che la fatica dice sul disegno

In quella fase la stanchezza di chi sta sui punti di contatto è la prima informazione disponibile. Anche per un motivo poco nobile: è l'unica. Qualsiasi altra misura ha bisogno di un processo che la produca. E il processo nuovo non esiste ancora. I numeri diranno qualcosa fra un trimestre. Cioè quando il disegno sarà pubblicato da un pezzo, e correggerlo sarà tutta un'altra faccenda.

La domanda utile, allora, riguarda un punto di contatto preciso. Quale responsabilità sta reggendo quella persona al posto di una struttura? La risposta si trova quasi sempre, ed è precisa. Una decisione che ha perso il suo *owner* e adesso prende la strada più corta. Un'approvazione che è passata a un'altra area. L'*accountability* si è spostata, e il documento che la assegnava è rimasto quello vecchio. Un'informazione che prima arrivava per posizione, e che adesso arriva perché qualcuno si ricorda ogni volta di girarla.

Le risposte che vengono prima, di solito, sono altre due. Cercare qualcuno che regga meglio. Oppure aspettare che la struttura nuova sistemi le cose da sé. Nessuna delle due tocca il punto in cui il carico si è spostato. E tutte e due consumano proprio il tempo in cui quel punto si sposterebbe ancora parlandone.

## La finestra si chiude quando l'organigramma esce

Finché il disegno è una bozza, correggerlo è un lavoro qualunque. Si cambia a chi riporta un gruppo. Si assegna un'approvazione a chi la può dare davvero. Nessuno perde la faccia, perché non è ancora stato annunciato niente. Dal giorno in cui l'organigramma viene pubblicato, la stessa correzione diventa un'altra cosa. Chiede un motivo scritto. E qualcuno disposto a farsi correggere davanti agli altri.

Non tutta la fatica di una riorganizzazione dipende dal disegno, sia chiaro. Una parte è il costo normale del cambiare. La pagano tutti e passa. E trattare ogni lamentela come un errore di disegno è un ottimo modo per non finire mai una riorganizzazione. La fatica però si può guardare per destinazione. Quando serve a portare avanti il lavoro, è il costo del cambiamento. Quando serve a tenere insieme un punto di contatto, è un confine che si è spostato e che il disegno non ha ancora raggiunto.

Le settimane in cui una riorganizzazione si corregge a basso prezzo sono le stesse in cui qualcuno la sta reggendo con le proprie giornate. Chiedere a quella persona quale confine sta tenendo, mentre lo sta ancora tenendo, serve a spostarlo finché è una riga di bozza. Dopo restano un organigramma pubblicato e una persona che ha smesso di dirlo.

> Una riorganizzazione si aggiusta quasi gratis proprio nelle settimane in cui nessuno ha ancora voglia di parlarne.

## Riferimenti

- William Bridges, *Managing Transitions*
### Chi decide che il tuo lavoro deve aspettare
URL: https://myagilestories.com/chi-ha-il-diritto-di-farti-aspettare/
Last updated: 2026-09-17T08:12:16.000Z
Fra il momento in cui un lavoro è pronto e quello in cui serve davvero a qualcuno passa del tempo. Quel tempo è fatto di due materiali. Uno sono le ore in cui una persona ci mette le mani. L'altro sono i giorni in cui la cosa sta ferma. Su una scrivania. In una casella di posta. In una colonna che si chiama «in attesa di approvazione». Nelle aziende un po' grandi il secondo materiale occupa più spazio del primo, di solito con largo margine.

Quella coda ha un'origine precisa. Qualcuno ha stabilito che il lavoro passasse di lì. Che passasse dopo altre cose. E che a decidere l'ordine fosse una certa persona, o un certo tavolo. È una regola di precedenza, di chi passa prima. Decidere chi passa prima è *governance* esattamente quanto lo è decidere un budget. Con una differenza non piccola: di un budget si sa sempre chi l'ha approvato.

## Il tempo fermo appartiene a qualcuno

In quasi tutte le aziende si sa dire chi fa un certo lavoro. Molto più di rado si sa dire chi ha stabilito quanto quel lavoro deve aspettare prima di essere fatto. Eppure il diritto di far aspettare gli altri esiste, ed è distribuito. Ce l'ha chi può dire «questo prima» e viene ascoltato. Ce l'ha chi convoca il tavolo che si riunisce il giovedì. Fissando la data ha fissato anche l'attesa di tutto quello che quel tavolo deve guardare. Ce l'ha chi parla con i clienti, che passa davanti per una ragione che nessuno discute.

Chi esercita quel diritto quasi mai sa di averlo. Manda una richiesta, e la sua richiesta scavalca. Non ha ordinato niente a nessuno: ha soltanto scritto. L'ordine della fila però si è mosso. E quello che ha spostato è il lavoro di qualcun altro, che adesso arriverà tardi.

## Dove non c'è una regola scritta, decide chi sta più vicino

L'ordine con cui le cose vengono prese in mano si rifà da capo ogni giorno. E premia la vicinanza molto più dell'urgenza. Le cose che aspettano più a lungo sono quelle che non hanno una persona con voce a reclamarle. La manutenzione di un sistema che per adesso funziona. Il debito che qualcuno si è preso due anni fa. Il *working agreement*, cioè l'accordo che il gruppo si era dato su come lavorare, e che nessuno ha più tempo di applicare. Nessuna di queste ha un mittente che può alzare un telefono. Quindi restano indietro, e restano indietro ogni volta.

> Quando la regola di precedenza non è scritta, la fila si ordina da sola secondo chi ha il canale più corto verso chi decide.

Le file, va detto, esistono per una ragione seria. La capacità è finita, e quando è finita qualcosa aspetta. Metterlo in fila è più onesto che far finta che tutto proceda in parallelo. Quello che si può discutere non è l'esistenza della fila. È il criterio con cui viene ordinata. E un criterio si discute soltanto se qualcuno lo ha detto ad alta voce.

## La misura che conta è il tempo che passa

Nicole Forsgren, Jez Humble e Gene Kim, in *Accelerate*, guardano alla consegna del software con una misura semplice: il tempo trascorso. Lo contano dal momento in cui una cosa è pronta a quello in cui è in mano a chi la usa. E lo preferiscono al conteggio del lavoro prodotto. Quella misura descrive il sistema più che le persone che ci stanno dentro. È anche il motivo per cui nessuno la migliora lavorando più in fretta. La maggior parte di quel tempo non è lavoro: è attesa fra un passaggio e l'altro. E ogni passaggio sta lì perché qualcuno ha avuto l'autorità di metterlo.

C'è una loro conclusione che sta bene accanto a questo discorso. I controlli di approvazione affidati a chi sta fuori dal gruppo che fa il lavoro non producono la sicurezza che promettono. Intanto allungano l'attesa. Se è così, quel passaggio in più vale meno di quanto costa. E chiedere chi l'ha voluto diventa una domanda ragionevole.

Misurare il tempo trascorso, comunque, non lo accorcia. Fa una cosa diversa e utile. Un numero non toglie a nessuno la facoltà di scavalcare. Rende dicibile che qualcuno l'ha esercitata. Che è già parecchio più di quanto succeda adesso.

## Chi ha creato la coda deve poter comparire

Non serve un processo nuovo. Chi propone un processo per governare le code, in genere, ne aggiunge una. Un comitato che stabilisce le priorità è un altro posto in cui il lavoro si ferma, aspettando che qualcuno si riunisca. Serve qualcosa di più scomodo e più economico. Che l'ordine della fila abbia un nome sopra. E che quel nome sia una persona a cui si può chiedere in base a che cosa il proprio lavoro sta fermo.

Non per protestare, e nemmeno per ottenere il primo posto. Per sapere se la ragione esiste. Certe volte esiste ed è ottima, e sentirsela dire cambia perfino il modo di aspettare. Altre volte non esiste, e allora è già successo qualcosa di utile. Perché un ordine senza ragione, una volta esposto, difficilmente sopravvive intatto.

Un'azienda che sa dire chi ha messo in fila il lavoro sta governando, anche quando non lo chiama così. Una fila lunga, presa da sola, dice poco: dipende pure da vincoli veri, che non si tolgono per decreto. Dice molto di più, per me, se di quell'ordine si può chiedere conto. E se lo si può chiedere senza pagarlo. Dove quella domanda costa, la fila è protetta dalla posizione di chi l'ha ordinata, e nessuno la guarda più.

Alla fine c'è un'asimmetria che tiene tutto fermo. Chi aspetta sa benissimo di aspettare. Conta i giorni, e li conta davanti a qualcuno a cui aveva promesso una data. Chi ha creato l'attesa, quasi sempre, non sa di averla creata. Ha scritto una mail il martedì. Oppure ha chiesto una cosa urgente a una persona che in quel momento stava facendo altro. Finché quelle due informazioni non si incontrano, la fila resta com'è. Non perché qualcuno la difenda. Perché nessuno sa di doverla difendere.

> L'attesa di una persona è quasi sempre la comodità involontaria di un'altra.

## Riferimenti

- Nicole Forsgren, Jez Humble, Gene Kim, *Accelerate* (2018)
### Le decisioni che nessuno scrive si pagano due volte
URL: https://myagilestories.com/una-decisione-non-registrata-torna-in-riunione/
Last updated: 2026-09-17T08:12:17.000Z
C'è un modo abbastanza semplice per capire quanto tiene una decisione. Contare quante volte torna in agenda dopo essere stata presa. Non i suoi effetti, non gli aggiornamenti su come sta andando. Proprio quella scelta lì, rimessa sul tavolo da capo, con le alternative già valutate una volta e spesso con le stesse persone intorno. Succede più di quanto si ammetta, e quasi mai per malafede. Succede perché di quella decisione, fuori dalla stanza in cui è stata presa, non è rimasto niente che qualcun altro possa leggere.

Non tutte le riaperture sono un difetto, sia chiaro. Una decisione si rivede quando cambia il quadro intorno, e rivederla è un lavoro serio quanto prenderla. La differenza sta nel punto di partenza. Chi rivede sa che cosa era stato deciso e su quale ragionamento, e mette in discussione quel ragionamento. Chi ha dimenticato riparte dal foglio bianco. E paga una seconda volta un lavoro già fatto.

## Il verbale tiene l'esito e perde la scelta

Qualcosa, di solito, viene scritto. Ci sono le note della riunione, una riga su un canale, una scheda spostata di colonna. Quello che resta scritto, però, è quasi sempre l'esito: si è deciso A. Quello che non resta è come ci si è arrivati. Quali erano le altre strade. Quale vincolo le ha escluse. Che cosa si dava per vero quel giorno.

Sembra informazione superflua nel momento in cui la si scrive, perché lì ce l'hanno in testa tutti. Diventa l'unica che serve tre mesi dopo, quando qualcuno chiede perché non si è fatto B. Senza il ragionamento, a quella domanda non si può rispondere. Si può soltanto rifare la discussione.

E la discussione rifatta non è mai la copia della prima. Le persone in stanza sono altre. Le informazioni disponibili sono cambiate. Il tempo per pensarci è meno. Può atterrare in un punto diverso, e ogni tanto è perfino un bene. Il guaio è quando atterra in un punto diverso senza che nessuno se ne accorga. Da lì in avanti l'azienda ha due decisioni vive sulla stessa cosa, prese tutte e due in buona fede. E nessuno sa quale delle due stia governando il lavoro.

## Ogni conoscenza vuole un posto solo

Hunt e Thomas, in *The Pragmatic Programmer*, tengono molto a un principio che dentro il software è quasi ovvio. Fuori dal software non si applica quasi mai. Ogni pezzo di conoscenza dovrebbe avere un unico posto autorevole dove sta scritto. Il costo della duplicazione non è lo spazio che occupa. È che le copie, andando avanti, divergono.

Le decisioni di un'azienda vivono di solito nella forma peggiore di duplicazione. Parecchie copie, tutte dentro la testa di qualcuno. Divergono anche quelle, con una differenza. Nessuno se ne accorge, perché qui non c'è un compilatore che si ferma e segnala il conflitto. Il conflitto si vede molto più tardi. Due persone agiscono in modo incompatibile su una cosa che era stata decisa una volta sola, e ciascuna è convinta di stare eseguendo.

> Una decisione che vive solo nella memoria di chi c'era non sta coordinando il lavoro: sta aspettando di essere ridiscussa.

## Una traccia corta, e nessuno strumento nuovo

Basta poco, e non serve un programma nuovo né un formato buono per tutti. Serve che da qualche parte, in un posto che chi non era in riunione sa raggiungere da solo, restino cinque informazioni. Che cosa si è deciso. Quale vincolo o quale dato ha determinato la scelta. Quale alternativa è stata scartata, e per quale motivo. Chi ne è *owner*, cioè chi può dire oggi se quella decisione tiene ancora. E a quali condizioni va rimessa in discussione.

Sono cinque righe. Costano meno di dieci minuti in coda a una riunione. E sono proprio i dieci minuti che si tende a non spendere, perché ormai la cosa sembra chiusa e la stanza ha fretta di uscire. È lì, in quei dieci minuti, che si stabilisce se quella scelta verrà pagata una volta o tre.

L'ultima delle cinque righe è la meno intuitiva, ed è quella che fa più lavoro. Una decisione con scritto a quali condizioni va rivista non chiede fedeltà eterna a nessuno. Dichiara la propria scadenza. E toglie di mezzo l'idea che riaprirla sia un gesto ostile verso chi l'aveva presa.

## La traccia lavora per chi arriva dopo

Il valore di un registro non si vede mentre lo si scrive. Si vede quando entra una persona nuova. Quando qualcuno rientra da un mese di assenza. Quando un gruppo eredita un lavoro deciso da altri. In tutti questi casi la domanda che arriva è quasi sempre la stessa: perché qui si fa così?

Se a quella domanda risponde una persona, quella persona diventa un passaggio obbligato per chiunque. La conoscenza dell'azienda resta privata anche quando tutti sono in buona fede. Se invece la risposta è un posto, chi arriva ci va da solo. E chi sapeva torna a fare il proprio mestiere, invece di fare da memoria per tutti.

Un registro non fa prendere decisioni migliori, e chi lo presenta come uno strumento di qualità promette una cosa che non può mantenere. Fa un lavoro più piccolo e più affidabile. Fa in modo che una decisione presa una volta si paghi una volta sola. E che chi arriva dopo possa metterla in discussione, invece di doverla riscoprire.

Poi certo, esistono aziende dove le decisioni non si scrivono perché scriverle le renderebbe verificabili. Quello è un problema diverso, e nessun formato lo risolve. Ma nella maggior parte dei casi sotto non c'è niente di così sofisticato. C'è solo che alla fine di una riunione si ha fretta. Il conto di quella fretta lo paga qualcun altro, qualche settimana dopo, in una riunione che nessuno aveva messo in calendario.

> Chi arriva dopo non eredita le decisioni. Eredita soltanto quello che qualcuno ha avuto la pazienza di scrivere.

## Riferimenti

- Andrew Hunt, David Thomas, *The Pragmatic Programmer*
### Lo stesso metodo per cinque gruppi diversi
URL: https://myagilestories.com/non-ogni-gruppo-di-lavoro-deve-diventare-uno-scrum-team/
Last updated: 2026-09-17T08:12:17.000Z
Capita di entrare in un'azienda che ha appena finito di riorganizzarsi. E di trovare cinque o sei gruppi con lo stesso identico impianto. Un *product owner*, uno *scrum master*, un *backlog*. Sprint di due settimane, e le stesse cerimonie negli stessi giorni. Sulla carta sembra ordine, e da lontano in effetti lo è. Poi guardi come lavorano davvero. Due di quei gruppi ci stanno dentro benissimo. Uno ci sta scomodo. Gli altri hanno smesso da mesi di usare metà di quelle cose, e però le tengono in calendario, perché sono state decise.

La lettura comoda, a quel punto, è che manchi disciplina. Per me il problema sta un passo prima. Sta nel momento in cui si è deciso che tutti dovessero avere la stessa forma.

## Una forma non è un contenitore neutro

Scrum, per come è disegnato, dà per scontate alcune cose molto specifiche. Che esista un risultato che si può guardare a intervalli regolari. Che qualcuno, fuori dal gruppo, su quel risultato abbia qualcosa da dire. Che il gruppo possa cambiare rotta quando quello sguardo porta a galla qualcosa di scomodo. E che ci sia una persona che può davvero decidere che cosa viene prima e che cosa aspetta.

Dove queste condizioni ci sono, le cerimonie hanno una funzione ovvia. Nessuno deve ricordare a nessuno perché si fanno. Dove non ci sono, restano gesti. E i gesti, ripetuti abbastanza a lungo senza che producano una decisione, insegnano al gruppo una cosa precisa. Che quel momento non serve. È un apprendimento difficile da smontare, dopo.

## I ruoli senza materia si riconoscono presto

Il segnale che leggo prima di tutti gli altri non è la noia in riunione, che può avere mille cause. Riguarda i ruoli. Quando un ruolo esiste sull'organigramma e non ha un contenuto vero, si vede quasi subito. Un product owner che non può decidere niente non è un product owner. Le priorità gli arrivano già decise da un altro piano. Ha un titolo che lo espone a domande a cui non ha l'autorità di rispondere. E a lungo andare impara a difendersi. Risponde in modo vago, oppure rimanda, oppure gira la domanda a chi decide sul serio, che però non è in quella stanza.

Uno scrum master messo in un gruppo che lavora su richieste di manutenzione sta nella stessa posizione. Il flusso è noto, gli intoppi veri sono sempre gli stessi tre. Facilita conversazioni che non hanno niente da sciogliere. E una review senza nessuno a cui mostrare qualcosa diventa il momento in cui il gruppo racconta a se stesso quello che già sa.

Non è colpa delle persone, e nemmeno del metodo. Quando un ruolo non ha materia, chi lo occupa la va a cercare altrove. Si mette a controllare. Oppure fa da tramite fra due parti che potrebbero parlarsi da sole. Nasce così una parte notevole del lavoro inutile che poi chiamiamo burocrazia interna.

> Un gruppo può eseguire un framework in modo impeccabile e stare lavorando, con grande diligenza, sulle cose sbagliate.

## Cosa distingue un gruppo dall'altro

Quando mi chiedono se un gruppo sia «pronto» per una certa forma, la maturità è la variabile meno interessante. Ce ne sono altre che pesano di più. E quasi nessuno le mette sul tavolo al momento di decidere. La prima è quanta incertezza c'è nel lavoro. Se un gruppo sa già che cosa deve fare, il problema è farlo bene e in fretta. Guardarlo ogni due settimane costa più di quanto renda. Si sta misurando l'esecuzione di una cosa su cui non c'è niente da scoprire.

La seconda è quanto i pezzi dipendono l'uno dall'altro. Un gruppo di specialisti porta avanti cose separate e si incrocia tre volte al mese. Non ha bisogno di vedersi ogni mattina. Gli basta sapere dove sono, quelle tre volte. Il resto del tempo la riunione quotidiana è una tassa, pagata in nome di un'idea di squadra che lì non serve a niente.

Poi c'è il tempo del riscontro, che secondo me è la variabile più trascurata. Se quello che il gruppo produce riceve una risposta dal mondo dopo tre mesi, uno sprint di due settimane non misura l'effetto di niente. Misura l'attività interna. Che è un'altra cosa, e che tende a diventare il criterio proprio perché è l'unico disponibile.

Su questo mi ha spostato una lettura: *Accelerate*, di Forsgren, Humble e Kim. Le misure che quel libro prende sul serio guardano tutte allo stesso punto. Quanto tempo passa fra una cosa fatta e il momento in cui qualcuno la usa davvero. E quanto ne serve a rimetterla in piedi quando si rompe. Presuppongono un giro che si chiude in fretta. Un gruppo che quel giro ce l'ha lungo per costruzione può usarle lo stesso. Deve solo sapere che gli stanno raccontando com'è organizzato dentro, non che effetto sta facendo fuori.

## La domanda che metto al posto del modello

Invece di chiedermi se un gruppo sia adatto a Scrum, mi chiedo un'altra cosa. Qual è il minimo che serve a quel gruppo perché il lavoro che fa davvero diventi leggibile e correggibile? Qualche volta la risposta coincide con Scrum quasi per intero, e allora tanto vale usare un linguaggio che le persone conoscono già. Altre volte è molto meno. Un posto solo da cui arrivano le richieste, invece di tre canali e un corridoio. Un momento fisso in cui si decide che cosa non si fa. Una persona che può sciogliere un blocco senza chiedere il permesso a due livelli.

La forma non protegge da questo. Anzi, quando è molto curata dà l'impressione rassicurante che la domanda se la sia già posta qualcun altro, prima, da un'altra parte.

## Il rischio dell'argomento opposto

Non sto dicendo che ogni gruppo debba inventarsi il proprio metodo. Ho visto anche quel film. Un'azienda in cui ognuno si organizza come preferisce paga un prezzo altissimo in traduzione. Chi la attraversa deve imparare cinque modi diversi di chiedere una cosa. E ogni passaggio fra un gruppo e l'altro diventa una piccola trattativa. L'uniformità serve, eccome.

Il punto è che è una scelta, e ha un costo. Chi la fa dovrebbe poter dire quale problema risolve. «Così siamo tutti allineati» non è una risposta a quella domanda: è la sua versione educata. Quando istituiamo un gruppo e gli diamo una forma, stiamo rispondendo a una domanda che spesso non abbiamo nemmeno formulato. Di che tipo di lavoro è fatto questo gruppo, e che cosa gli serve per governarlo? Se la risposta che ci viene è «lo stesso di tutti gli altri», forse quella domanda non ce la siamo posta.

> Dare a cinque gruppi la stessa forma è una decisione. Quasi sempre viene presa come se fosse un dettaglio di ordine.

## Riferimenti

- Nicole Forsgren, Jez Humble, Gene Kim, *Accelerate* (2018)
### Un problema si muove solo quando ha un nome e una data
URL: https://myagilestories.com/un-impedimento-senza-destinatario-e-solo-una-lamentela/
Last updated: 2026-09-17T08:12:19.000Z
Ci sono impedimenti che nessuno nasconde, e restano fermi lo stesso. La scena cambia poco da un posto all'altro. Un gruppo commerciale ne parla da mesi, e ci sono persino due riunioni fisse alla settimana dedicate a quello. Le persone confermano la presenza, e poi non entrano. Quando qualcuno riporta la cosa in una riunione più ampia, di solito finisce in battuta. Nella call fra le due aree coinvolte resta una fila ordinata di lamentele, ciascuna vera. E alla fine non si decide niente: non chi se ne occupa, non entro quando.

Quello che colpisce, in una scena così, è che a quell'*impedimento* non manca visibilità. Nel gergo del mestiere un impedimento è un ostacolo che chi lavora non riesce a togliersi da solo. Questo lo conoscono tutti, ed è nominato in tre o quattro posti diversi. Gli manca qualcosa di meno ovvio. Non è mai stato consegnato a una persona che potesse riceverlo e rispondere. Gira. E finché un problema gira, non è una cosa di cui qualcuno risponde. È aria che passa da una stanza all'altra.

## Nominare non è consegnare

Una riunione in piedi di dieci minuti serve a rendere visibile, e lo fa bene. Ma rendere visibile e consegnare sono due gesti diversi. Il primo si traveste facilmente da secondo. Dire «c'è questo problema» davanti a otto persone sembra un gesto di responsabilità. Spesso è il suo contrario educato: ho detto la mia parte, adesso la cosa è di tutti. E una cosa di tutti, in pratica, non è di nessuno. Non perché chi la solleva sia in malafede, quasi mai lo è. È che una frase rivolta alla stanza non impegna nessuno in particolare a fare la mossa dopo. La stanza annuisce. Il problema resta dov'era, un po' più raccontato di prima.

> Un impedimento diventa una lamentela nel momento esatto in cui viene enunciato senza un destinatario.

## Un costo paziente

Questo tipo di impedimento raramente esplode. Non fa saltare una consegna in un giorno preciso, e per questo è difficile da addebitare a qualcuno. Fa una cosa più paziente: consuma. Le due riunioni settimanali diventano il posto dove il problema viene confermato invece che sciolto. E ogni lunedì si riparte da capo. Due spazi di coordinamento che dovrebbero produrre decisioni producono resoconti. Intanto la cosa continua a circolare intatta, e si porta via il tempo delle persone.

È un costo che non compare da nessuna parte, perché nessuno lo firma. Non risulta come un ritardo di un reparto. Risulta, se uno guarda bene, in un pezzo di azienda che parla moltissimo di una cosa. E non la muove mai. È il tipo di spesa che si sostiene volentieri per anni. È divisa fra tutti, e non pesa in modo visibile su nessuno.

## Cosa manca, ed è poco

La differenza fra una lamentela e un impedimento governato sta in due informazioni che quasi nessuno scrive. Chi lo riceve. Entro quando risponde. Con quelle due righe, lo stesso identico problema smette di essere un tema. Diventa una cosa che qualcuno deve trattare. C'è una data, oltre la quale perfino il silenzio diventa una notizia. Senza quelle righe resta un argomento di conversazione, per quanto sentito. E colpisce quanto poco costi scriverle, rispetto a quanto costa non scriverle.

## L'altra metà del sensore

In un pezzo precedente dicevo che uno *scrum master* fatto bene è un sensore. Rende leggibile un segnale e lo porta dove qualcuno ha il modo di trattarlo. Qui si vede l'altra metà della stessa cosa. Un sensore che rileva ma non consegna a una persona precisa non rende nessuno più autonomo. Aggiunge rumore al rumore. Il segnale conta quando arriva a qualcuno che può riceverlo, non quando viene emesso. È una differenza che in teoria capiamo tutti, e che in riunione sbagliamo quasi sempre.

## Perché prosperano sui confini

C'è un motivo per cui questi impedimenti prosperano proprio fra due aree. Matthew Skelton e Manuel Pais, in *Team Topologies*, insistono su una cosa semplice e scomoda. Le zone di confine fra due gruppi non restano mai vuote. Se nessuno le prende in carico, si riempiono di lavoro che appartiene a entrambi e a nessuno. Un impedimento che nasce lì eredita la stessa proprietà. Non ha un destinatario perché non ha un *owner*, cioè qualcuno che ne risponda. E non ha un owner perché il confine da cui viene non appartiene a nessuno dei due.

## Chi riceve questo, ed entro quando

Le riunioni in più, di solito, peggiorano le cose. La terza volta che sento nominare lo stesso impedimento senza che si sia mosso, porto al tavolo una domanda. Non «come lo tracciamo meglio», ma «chi lo riceve, ed entro quando risponde». È una domanda sgradevole, perché costringe qualcuno a prenderselo mentre finché girava non era suo. E funziona proprio per quello. Sposta la cosa dal registro delle lamentele a quello delle responsabilità. È quello che in inglese si chiama *accountability*: un nome accanto al problema, e una data entro cui quel nome risponde.

La prova, alla fine, è tutta lì. Un impedimento nominato tre volte e mai assegnato non è un problema di comunicazione, e infatti parlarne ancora non lo guarisce. È un problema di *governance* travestito da problema di comunicazione. La mossa che lo scioglie non è dirlo meglio. È darlo a una persona, con una data, e reggere il piccolo disagio di aver tolto a tutti gli altri la comodità di lamentarsene ancora.

> Il giorno in cui un problema prende un nome, qualcuno perde il diritto di parlarne senza muoverlo.

## Riferimenti

- Matthew Skelton, Manuel Pais, *Team Topologies*
### Un accordo di gruppo che funziona dice tre cose
URL: https://myagilestories.com/il-working-agreement-non-e-un-galateo-aziendale/
Last updated: 2026-09-17T08:12:18.000Z
Rispetto. Trasparenza. Fiducia. Ci aiutiamo a vicenda. Sono le parole che finiscono sui *working agreement* appesi alle pareti, cioè sugli accordi che un gruppo si dà su come lavorare insieme. Hanno una proprietà curiosa. Nessuno può dirsi contrario, e nessuno riesce a servirsene quando c'è un problema concreto. Non c'è modo di dire a una persona «stai violando il rispetto» senza che suoni come un'accusa. Così quelle parole restano lì: vere e inservibili.

Il giorno dopo la riunione in cui li avevamo scritti, il lavoro riprendeva come prima. Stesse aspettative non dette. Stessi piccoli attriti. Il documento non aveva cambiato niente, perché non chiedeva niente a nessuno. Era un galateo. Diceva come sarebbe bello comportarsi, e taceva su quello che avremmo fatto davvero. È una differenza che sul momento non si nota, e che si sente tutta il primo giorno in cui qualcosa va storto.

## La stessa stanza, contratti diversi

Il problema che un accordo dovrebbe risolvere nasce prima delle regole. In un gruppo ognuno entra con un contratto implicito in testa. Che cosa vuol dire «essere pronti». Entro quando si risponde a un messaggio. Chi va avvisato prima di cambiare una cosa condivisa. Quanto silenzio, dentro una call, vuol dire disaccordo. Nessuno lo dichiara, perché a ciascuno sembra ovvio. Sono ovvietà diverse, però, e restano invisibili finché non si scontrano.

A quel punto succede la cosa peggiore. Un malinteso su un'aspettativa scivola in un giudizio su una persona. Non più «non ci eravamo capiti su che cosa fosse finito», ma «lui non è affidabile». Un working agreement serve a portare quei contratti impliciti sullo stesso tavolo. Mentre sono ancora una questione di lavoro, e non di caratteri. Fatto così smette di essere una lista di buoni propositi. Diventa il posto dove un gruppo decide, per una volta ad alta voce, come vuole funzionare.

> Un accordo che nessuno potrebbe rifiutare non sta chiedendo niente a nessuno.

## Cosa dichiara un accordo che regge

La differenza fra un poster e un accordo si vede in tre cose che il primo non ha mai. Il foglio appeso in mezzo al gruppo vorrebbe essere un *information radiator*: un'informazione esposta che, passandoci davanti, ti dice come sta andando. Ma se a novembre dice esattamente quello che diceva a gennaio, qualunque cosa sia successa nel frattempo, non sta irradiando niente. Sta arredando. Ed è il tipo di arredo che tutti smettono di vedere dopo una settimana.

Un accordo che regge dichiara **comportamenti osservabili** al posto dei valori. «Rispetto» non dice niente di verificabile. «Se cambio un file condiviso lo scrivo nel canale prima di farlo» si può vedere se è successo o no. Un valore resta un'opinione. Un comportamento no. È il modo più sicuro per evitare le letture comode, il giorno in cui qualcuno ne ha bisogno.

Dichiara **i segnali**: come ci accorgiamo che l'accordo si sta incrinando, quando è ancora una piccola cosa. Una voce ferma da tre giorni senza una parola. Una decisione rimandata due volte. Una persona che smette di intervenire in *retrospettiva*, cioè nell'incontro in cui si guarda insieme com'è andata. Nominare i segnali in anticipo è quello che rende un gruppo capace di correggersi da solo, senza aspettare che qualcuno dall'alto se ne accorga.

E dichiara **le conseguenze**, la parte che quasi tutti saltano. Non conseguenze punitive. È una domanda spoglia: che cosa facciamo quando l'accordo non viene rispettato? Se la risposta onesta è niente, l'accordo era un desiderio. È il punto in cui smette di essere buona volontà e diventa *accountability*: qualcuno risponde di una scelta presa insieme. Basta poco, davvero. «Se salta, ne parliamo alla prossima retro, e lo trattiamo come un problema del patto, non della persona» è già una conseguenza. Ed è quella che dà peso a tutto il resto.

## Prima che diventi personale

La ragione per cui conviene farlo bene ha a che fare con il momento in cui lo si fa. Un accordo si scrive quando le cose vanno abbastanza bene da poterne parlare con calma. Se aspetti che serva sul serio, lo stai scrivendo nel mezzo di un conflitto. E lì ogni riga sembra rivolta a qualcuno in particolare. Nessuno legge più un patto, leggono tutti un'accusa.

Dichiarare comportamenti, segnali e conseguenze mentre nessuno è ancora sulla difensiva costruisce quella che Amy Edmondson chiama sicurezza psicologica. È la condizione perché in un gruppo si possa nominare un problema presto, prima che chi lo solleva ci rimetta la faccia. Più avanti, quando arriva la conversazione difficile, quella conversazione ha per oggetto l'accordo che ci eravamo dati. E si affronta con calma, perché era già scritto.

> Il momento buono per scrivere un accordo è quello in cui sembra che non serva.

Insisto su questo per una ragione, e la devo in parte a Edgar Schein. Le cose che contano in un gruppo raramente si sistemano dicendo alle persone come comportarsi. Si sistemano creando le condizioni perché certe aspettative si possano dire ad alta voce prima che facciano danno. Un working agreement, quando funziona, è una di quelle condizioni. Non è una regola calata dall'alto, ed è per questo che regge.

I modelli pieni di caselle da spuntare sono il galateo travestito da metodo. Per capire se un accordo è vivo uso una prova sola: lo rileggo dopo sei mesi. Mi dice ancora qualcosa su come ci comportiamo? Oppure è una cosa che abbiamo scritto una volta e che nessuno guarda più? La risposta, di solito, non dipende da come l'abbiamo formulato. Dipende da quanto eravamo disposti, quel giorno, a scrivere che cosa avremmo fatto per davvero. Invece di come sarebbe stato bello essere.

## Riferimenti

- Amy C. Edmondson, *Organizzazioni senza paura*
- Edgar H. Schein, *L'arte di far domande*
### Aiutare troppo un gruppo lo rende meno capace
URL: https://myagilestories.com/lo-scrum-master-e-un-sensore-non-un-management-parallelo/
Last updated: 2026-09-17T08:12:17.000Z
C'è un gesto da cui capisco se uno *scrum master* sta ancora facendo il suo mestiere: che cosa fa di quello che raccoglie. Un segnale arriva sempre. Due gruppi che dipendono l'uno dall'altro senza che nessuno l'avesse detto. Una decisione ferma da settimane che intanto costa a qualcuno. La domanda è che fine fa quel segnale. Se torna leggibile a chi ha l'autorità di trattarlo, il ruolo sta lavorando. Se si ferma lì, il segnale non è sparito. L'ha trattenuto chi l'ha raccolto, perché era la persona più a portata di mano. È solo diventato invisibile a tutti gli altri. E un gruppo che smette di vedere i propri *impedimenti* smette anche, piano piano, di rispondere di sé.

## Cosa fa un sensore

Un sensore non decide. Rende leggibile. Prendi quello di un'automobile: non guida, dice a chi guida che cosa sta succedendo. Il suo lavoro è portare in superficie quello che altrimenti resterebbe implicito. Dove il flusso si inceppa. Quale legame fra due gruppi nessuno aveva nominato. Quale conversazione necessaria continua a non avvenire. Applicato a una persona è già moltissimo, ed è più difficile di quanto sembri. Vedere un impedimento prima che diventi un danno chiede di stare vicino al lavoro senza entrarci dentro. E chiede di dire ad alta voce cose che la stanza preferirebbe lasciare non dette.

Riportare indietro, però, non vuol dire scaricare tutto sul tavolo di qualcun altro. Certi impedimenti il gruppo da solo non li raggiunge. Stanno più in alto, o più in là. È giusto che se li lavori lui in prima persona: fa parte del mestiere. Quello che non deve diventare suo è il posto di chi risponde della scelta. Se il segnale è «questa decisione è ferma», il compito è rendere visibile che è ferma, e ricordare su quale tavolo va mossa. Muoverla al posto di chi la deve prendere è un'altra cosa.

È il rovescio di un'abitudine molto diffusa, e il modo di dirlo lo devo a David Marquet. Invece di far salire l'informazione fino a dove sta l'autorità, si sposta l'autorità dove l'informazione già sta. Detta così sembra una massima da poster. In pratica è una scelta che si fa venti volte al mese, quasi sempre senza accorgersene. L'autonomia di un gruppo cresce esattamente lì: nella quantità di segnali che tornano leggibili senza che qualcuno debba assorbirli per farli sparire.

## Quando il supporto diventa dipendenza

Il guaio nasce con le migliori intenzioni. Una decisione che nessuno prende è scomoda da guardare. E chi sta accanto al gruppo è nella posizione più comoda per raccoglierla. Così, un impedimento alla volta, lo scrum master diventa il posto dove finiscono le scelte senza un padrone chiaro. Sembra efficienza. È invece un management parallelo che nessuno ha deciso di creare. E che nessuno può sciogliere, perché ufficialmente non esiste.

> Sbloccare al posto di qualcuno è un favore che si paga in autonomia.

Il costo non si vede subito, perché all'inizio le cose si sbloccano davvero. Si vede dopo, in una forma precisa. Il gruppo smette di portare i problemi a chi li deve decidere, e comincia a portarli a chi li fa sparire. La responsabilità cambia mano senza che nessuno l'abbia spostata. E un gruppo che ha imparato a far decidere un altro è meno capace di prima. Anche se sulla bacheca tutto scorre meglio.

## Di solito non è colpa della persona

Vale la pena chiedersi da dove venga questa deriva. Quasi mai è colpa di chi ci finisce dentro. Un ruolo assorbe decisioni quando intorno non c'è un posto pulito dove trattarle. Se non è chiaro chi risponde di che cosa, il dubbio scivola verso chi è disposto a farsene carico. Lo scrum master che diventa un capo di fatto sta quasi sempre tappando un buco di *governance* che avrebbe dovuto riempire qualcun altro. È raro che sia una questione di zelo.

## Il confine che provo a tenere

Alla prova dei fatti la differenza è un punto d'arresto: fin dove arriva il ruolo prima di fermarsi. Rendere visibile un impedimento è dentro il mestiere. Deciderlo al posto di chi ne risponde è fuori. Segnalare che una scelta è bloccata rende la stanza più capace. Prenderla per togliere l'imbarazzo la rende meno capace. Anche quando sembra la cosa gentile da fare. Quel confine non sta scritto da nessuna parte, ed è proprio per questo che va tenuto a mente.

Il segnale che mi mette in allarme più di ogni altro è una gratitudine sbagliata. Quando un gruppo è sollevato che qualcuno «se ne occupi lui», di solito il ruolo ha appena passato il confine. Il sollievo è vero. Ma è il sollievo di chi ha smesso di dover rispondere di una scelta. Non di chi è stato messo in condizione di prenderla. Un buon sensore quel po' di disagio lo lascia nella stanza, perché è lì che vive la responsabilità.

Quando un impedimento arriva sulla mia scrivania invece che su quella di chi decide, mi fermo prima di prenderlo in mano. E mi faccio una domanda sola. Sto rendendo questa cosa più leggibile, o sto solo togliendo a qualcuno il fastidio di guardarla? La prima è il mestiere. La seconda, ripetuta abbastanza volte, cambia natura a un ruolo nato per servire. Lo trasforma, senza che nessuno l'abbia scelto, nel comando che diceva di voler evitare.

> C'è un sollievo che somiglia moltissimo alla perdita silenziosa di una responsabilità.

## Riferimenti

- L. David Marquet, *Gira quella nave intorno!*
- Donella Meadows, *Pensare per sistemi*
### Gli stessi numeri cambiano se li vede anche chi lavora
URL: https://myagilestories.com/la-stessa-dashboard-puo-controllarti-o-liberarti-dipende-da-chi-la-legge/
Last updated: 2026-09-17T08:12:19.000Z
Prendi una dashboard qualsiasi. Numeri, colori, qualche freccia che sale o scende. Ora fatti una domanda che sembra banale e non lo è: per chi è fatta? Perché lo stesso schermo, con gli stessi identici dati, può essere due strumenti opposti. Uno che produce controllo. Uno che produce autonomia. La differenza non sta nel cruscotto. Sta in chi lo legge. È una cosa che ho visto succedere più di una volta, sempre con lo stesso stupore. Nessuno tocca un numero, e un gruppo intero cambia passo.

Quando i segnali stanno 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: ci sono situazioni in cui qualcuno deve poter entrare in fretta. Ma ha un difetto che non si toglie con un grafico più bello. Arriva sempre dopo. Fotografa un effetto già avvenuto e lo mette in mano a chi può reagire, non a chi avrebbe potuto accorgersene per tempo.

## Portare gli stessi segnali in un'altra stanza

C'è un'altra strada, e costa molto meno di quanto sembri. Portare quegli stessi segnali nello spazio comune, dove passano i gruppi, 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. Diventa quello che in gergo si chiama *information radiator*, cioè un'informazione esposta dove la gente passa. Il termine non è mio, è di Alistair Cockburn. Lo usava per distinguere l'informazione che leggi di sfuggita da quella che devi andare a chiedere a qualcuno. Detta così sembra una sfumatura. Nella vita di un gruppo non lo è per niente, perché chiedere costa, e chi deve chiedere aspetta.

## Non è la stessa cosa, anche se sembra

Vale la pena tenere separate due parole che usiamo come sinonimi. Una dashboard può benissimo essere uno strumento riservato, pensato per chi sorveglia, e va bene così se è quello che serve. Un *information radiator* no. Funziona soltanto se l'informazione sta nello spazio condiviso e se riduce il bisogno di chiedere «come siamo messi?». La sua forza non è contenere dati. È esporli in modo abbastanza chiaro da poter essere letti di passaggio: da chi lavora, da chi decide, da chi deve dare una mano. Un cruscotto pieno di dati che nessuno legge di passaggio resta un cruscotto, per quanto preciso sia.

Raffaele Mastantuoni ha scritto sulla capacità comunicativa di questi strumenti. Fabio Lisca si è chiesto che cosa c'entrino davvero con *agile*. Arrivano da due angolazioni diverse e battono sullo stesso chiodo: al centro c'è la funzione comunicativa, non quella di misura. Questi artefatti non contano perché misurano. Contano perché fanno vedere. E far vedere, dentro un sistema di lavoro, è già un modo di governare. Lo diciamo poco perché suona esagerato. Poi guardi chi, in azienda, ha il permesso di sapere come sta andando il lavoro, e capisci che esagerato non è.

> Un numero che vive in un cassetto ha già risposto, da solo, alla domanda su chi comanda.

## Il punto non è estetico, è organizzativo

Trasparenza, ispezione e adattamento sono i tre pilastri su cui Scrum dichiara di reggersi. Nessuno dei tre sta in piedi se lo stato del lavoro non si riesce a leggere. Detto così sembra ovvio. Nella pratica lo dimentichiamo di continuo, perché costruiamo strumenti bellissimi e poi li mettiamo in un posto dove li guarda soltanto chi comanda. Non è cattiveria di nessuno. È un'abitudine, e ha perfino una sua logica. Lo strumento nasce dalla domanda di chi lo ha pagato, e chi paga quasi sempre sta di sopra.

Se i segnali restano lì, il sistema produce controllo. Qualcuno osserva. Qualcuno interviene. Tutti gli altri aspettano l'intervento, e imparano ad aspettarlo. Se invece quegli stessi segnali diventano comprensibili anche a chi lavora sul prodotto, succede un'altra cosa. Le persone cominciano a regolarsi da sole. Vedono l'andamento prima che diventi un caso. Aprono una conversazione. Correggono la rotta senza aspettare che scenda qualcuno dal piano di sopra. Lo strumento è identico. La *governance* che produce, cioè il modo in cui le decisioni si distribuiscono, è rovesciata.

## I numeri di risultato parlano sempre in ritardo

C'è un'ultima trappola, ed è la più sottile di tutte. Molte dashboard mostrano soprattutto indicatori di risultato: fatturato, margine, consegne. Sono i cosiddetti *lag indicator*, i segnali che arrivano a valle. Hanno un limite onesto, che non è colpa loro: fotografano qualcosa che è già successo. Quando il numero diventa rosso, il fatto è compiuto, e alla riunione resta solo da cercare un responsabile. Un buon radiatore informativo non si limita a dire che qualcosa è andato male. Mostra abbastanza presto che cosa sta cambiando, mentre cambiare rotta costa ancora poco.

Per farlo servono anche i *lead indicator*, cioè i segnali che precedono il risultato. La qualità del *backlog*, cioè dell'elenco di cose che aspettano il loro turno. Quante decisioni nascono davvero dalle riunioni che esistono apposta per prenderle. Il grado di autonomia di un gruppo. La sua capacità di correggersi senza che nessuno glielo chieda. Roba molto meno spettacolare di un grafico di fatturato, lo ammetto. Però parla prima. E dentro un sistema di lavoro, parlare prima vale più che avere ragione dopo.

Faccio un esempio concreto, di quelli che capitano ovunque. Un gruppo ha un calo di qualità: aumentano i difetti, rallentano le consegne. Prima versione della storia: l'unico segnale è il numero di difetti che il management guarda a fine mese. La conversazione parte quando il danno è fatto, parte dall'alto, e ha il tono di chi chiede conto. Seconda versione: le stesse persone hanno davanti, ogni giorno, un segnale che precede quel calo. Per esempio quanto lavoro entra in sprint senza essere stato rifinito davvero. La conversazione nasce prima, dentro il gruppo, e ha il tono di chi si corregge. Stesso fenomeno. Stesso dato di fondo. Cambia chi lo vede, e quando. E cambia tutto.

## A chi serve

La domanda da fare davanti a un cruscotto qualsiasi, allora, non è se sia bello. Non è nemmeno se sia preciso. È un'altra, e mette a disagio: a chi serve? Se serve al management per sapere quando entrare, resta uno strumento di controllo, legittimo ma sempre in ritardo. Se aiuta i gruppi a vedere per tempo l'andamento del proprio lavoro, diventa un sostegno alla responsabilità distribuita. Lo stesso oggetto, spostato di stanza, cambia natura. E nessuno, di solito, si accorge di averlo spostato.

Per me è una delle scelte di governo più sottovalutate che ci siano. Non decidiamo quasi mai in modo esplicito chi ha il diritto di vedere come procede il lavoro. Lo decidiamo per abitudine, e l'abitudine è tenere tutto di sopra. Sul piano degli strumenti, portare quei segnali nello spazio comune non chiede quasi niente: uno schermo, una pagina, un muro. Cambia parecchio su un altro piano. Cambia chi, dentro l'azienda, può prendersi una responsabilità senza aspettare il permesso di qualcuno.

> Uno strumento non cambia natura quando lo migliori. Cambia natura quando cambi la stanza in cui vive.

## 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)
### Si riesce a decidere solo quando qualcosa è già andato male
URL: https://myagilestories.com/un-board-che-reagisce-non-e-un-board-che-governa/
Last updated: 2026-09-17T08:12:19.000Z
Un management board reattivo, di solito, lavora molto. Non è un board fermo. Risponde alle crisi, rincorre i casi, interviene quando qualcosa diventa evidente. Visto da fuori sembra perfino efficiente. C'è sempre movimento, c'è sempre qualcuno che si occupa del problema del giorno. Il limite non è la quantità di lavoro. È da dove arriva la direzione.

Quando la direzione nasce dal segnale esterno, e non da un accordo interno, il board non sta governando. Sta amministrando emergenze. La differenza si vede nei tempi. Le conversazioni importanti arrivano dopo. Dopo un blocco. Dopo che il peso su una persona è diventato insostenibile. Dopo una crisi dentro un gruppo, o un conflitto ormai esploso. Il board vede molto, questo va detto. Ma fatica a trasformare quello che vede in regole del gioco, aspettative, decisioni che restano scritte.

## Vedere non è decidere

C'è una qualità quasi seducente nel board reattivo: la diagnosi. In una stanza di persone esperte le analisi sono spesso brillanti. Ognuno legge bene il sistema, nota le ricorrenze, capisce che cosa non va. Il problema è che la diagnosi del singolo non diventa quasi mai responsabilità di tutti. Ci si ritrova a dire, uno dopo l'altro, che cosa si pensa del sistema. Raramente ci si ferma a decidere insieme che cosa si fa quando quella cosa ricompare.

È il passaggio su cui Esther Derby e Diana Larsen costruiscono *Agile Retrospectives*. Una *retrospettiva* che si ferma a quello che si è visto, senza decidere che cosa si fa, non ha ancora finito il suo lavoro. E le ricorrenze ricompaiono: è la loro natura. Se ogni volta le affrontiamo da capo, come se fossero notizie, restiamo dentro un ciclo. Crisi, diagnosi, intervento, sollievo. E di nuovo crisi.

La reattività ha questo di infido: dà soddisfazione. Ogni intervento riuscito conferma che il board serve. Peccato che confermi anche un'altra cosa, molto meno bella da dire. Senza la crisi, nessuno si sarebbe mosso.

> Un board che decide solo sotto pressione non è lento. È soltanto guidato da qualcun altro.

## Il contrario non è la rigidità

Attenzione, però, a non correre verso l'estremo opposto. Il contrario di un board reattivo non è un board rigido, che decide tutto in anticipo e poi applica le regole a prescindere. Sarebbe un altro modo di non governare, solo più cieco. Il contrario di un board reattivo è un board capace di nominare prima i criteri. Di dire, mentre le acque sono calme, che cosa faremo quando vedremo tornare quel segnale. Chi prende quale decisione. Quali conseguenze dichiariamo apertamente, così che non arrivino a sorpresa. Non è pianificare ogni mossa. È spostare un pezzo della conversazione dal momento della crisi al momento in cui si ragiona ancora a mente fredda.

Per me la formula è semplice da dire e scomoda da praticare. Meno «che cosa penso io di questo caso». Più «che cosa decidiamo di fare insieme quando vediamo tornare questa cosa». La prima frase mette al centro l'acume di chi parla. La seconda mette al centro un impegno che regge anche quando chi parla non c'è.

## Dalla diagnosi all'impegno

Il passaggio è dallo sguardo alla mano. Uno sguardo acuto sul sistema è prezioso, ma resta privato finché non si trasforma in qualcosa che vincola il gruppo. Un board matura quando accetta che le sue letture, per contare, devono diventare accordi. E un accordo, per essere tale, deve dire chi fa che cosa, con quali criteri, e che cosa succede se non accade. Nel lavoro dei gruppi un patto così ha un nome, *working agreement*, e vale anche quando a prenderlo è un board.

Questo non toglie spazio all'intuizione. La libera. Un board che ha già nominato i propri criteri può dedicare l'intelligenza ai casi davvero nuovi. Invece di consumarla ogni volta a rincorrere l'ennesima variante di un problema noto. Governare, alla fine, non vuol dire prevedere tutto. Vuol dire aver deciso prima abbastanza cose da non doverle decidere tutte sotto pressione.

Vale la pena dire da dove nasce, di solito, la reattività. Non da pigrizia. Da un eccesso di fiducia nelle persone. Un board fatto di individui capaci si convince che, quando arriverà il problema, sapranno gestirlo. E spesso è perfino vero. Solo che questa fiducia ha un costo nascosto: rende superfluo l'accordo. Perché prendersi la briga di nominare i criteri prima, se tanto poi ce la caviamo sempre?

Il risultato è che il board lavora sugli eventi invece che sulla struttura che li produce. È la distinzione al centro di *Pensare per sistemi*, di Donella Meadows. Il board diventa bravissimo a spegnere incendi e lentissimo a costruire l'impianto antincendio. E ogni incendio spento rimanda ancora un po' la conversazione noiosa su come evitare il prossimo.

La prova del nove è onesta e un po' spietata. Guarda le ultime decisioni importanti prese dal tuo board. Quante sono nate da un accordo preso a mente fredda? E quante da una crisi che ha costretto la conversazione? Se la seconda colonna è molto più piena della prima, il board sta lavorando. Ma non sta ancora governando.

Non serve ribaltare tutto in una volta. Basta cominciare da una ricorrenza sola, la più frequente, quella che torna ogni due mesi con una faccia diversa. Fermarsi, mentre le acque sono calme, e decidere insieme che cosa faremo la prossima volta che la vediamo arrivare. Chi la intercetta. Chi decide. Che cosa comunichiamo. Una ricorrenza nominata in meno è una crisi in meno da rincorrere. E quasi sempre è anche una persona in meno lasciata a reggere da sola, finché il costo non diventa personale.

> Ogni incendio spento è anche un rinvio. La prossima volta ci sarà di nuovo qualcuno da salvare.

## Riferimenti

- Donella Meadows, *Pensare per sistemi*
- Esther Derby, Diana Larsen, *Agile Retrospectives*
### Una lista ordinata può servire a non dirsi le cose
URL: https://myagilestories.com/quando-il-backlog-diventa-un-modo-per-non-parlare/
Last updated: 2026-09-17T08:12:18.000Z
Mi è rimasta addosso una riunione di *refinement*, la sessione in cui si prepara il lavoro che verrà. Non per quello che ci siamo detti, ma per quello che, con una precisione quasi perfetta, non ci siamo detti. Per un'ora abbiamo spostato voci, dato stime, spezzato storie troppo grandi, aggiunto criteri di accettazione. Alla fine la lista era più ordinata di prima. E la domanda che quasi tutti avevano in testa entrando — stiamo lavorando alle cose giuste? — era rimasta fuori dalla porta. Al suo posto, senza che nessuno l'avesse deciso, ne era entrata un'altra, più comoda: stiamo lavorando abbastanza?

## Efficacia o efficienza

È uno scambio che a un certo punto ho imparato a riconoscere. La distinzione che me lo ha fatto vedere la devo a Peter Drucker: efficacia è fare le cose giuste, efficienza è farle bene. Sono due domande diverse, e una non sostituisce l'altra senza che si perda qualcosa per strada. Un *backlog* — la lista del lavoro che aspetta — è bravissimo a misurare la seconda. Quante voci, quanto carico, quanto è stato chiuso. Sulla prima, per come è fatto, resta quasi muto. E man mano che la lista cresce e si perfeziona, la conversazione scivola. Si passa da «queste sono le cose che contano?» a «ci stiamo dando abbastanza da fare?».

La seconda domanda è più facile, e vale la pena dire perché. Si può contare, ordinare, mostrare su uno schermo in trenta secondi. Ma soprattutto non guarda nessuno in faccia. Una riga di elenco non ha un tono di voce. Non si offende. Non chiede a un collega perché ha cambiato idea. Chiedere se stiamo facendo le cose giuste, invece, chiama in causa qualcuno che quelle cose le ha scelte. È una domanda che ha un destinatario. Ecco perché costa.

## Uno strumento nasce da un problema

Il punto non è quella riunione presa da sola. Uno strumento, di solito, non nasce da una buona intenzione: nasce per risolvere un problema. Quando le cose vanno bene, nessuno sente il bisogno di costruirlo. Conviene allora chiedersi quale sia il problema vero. Una lista si allunga proprio mentre il lavoro diventa più incerto, o più litigioso. Spesso è questo: altrove, quel problema chiederebbe una conversazione scomoda su chi decide e su cosa conta davvero. La lista offre un posto molto ordinato dove appoggiarlo senza pronunciarlo.

## Rivelare o nascondere

C'è un uso della stessa parola per due cose molto diverse, e conviene tenerle separate. Una lista fa un lavoro prezioso quando rivela. Rende leggibili le dipendenze, gli *owner* di ogni pezzo, le decisioni già prese. Rende visibili gli *impedimenti* veri, cioè gli ostacoli che chi lavora non può togliersi da solo. Fa l'esatto opposto quando nasconde. Posso scrivere «progetto X» per tre mesi e rispondere ogni volta «tutto bene, stiamo lavorando», senza che cambi niente. Allora si aggiungono date e *milestone*, si scende nel dettaglio delle attività. E più si scende, più la domanda grande resta coperta: tracciata benissimo, e invisibile. È sempre la stessa lista. A seconda di cosa le chiediamo, illumina o mette in ombra.

La differenza, di solito, non si vede nello strumento. Si vede nel tipo di silenzio che lo circonda. C'è un segnale a cui ho imparato a fare attenzione. Una tensione su chi risponde di una scelta si ripresenta, puntuale, travestita da problema di metodo. «Dobbiamo tracciarlo meglio.» «Serve una voce in più.» «Mettiamolo in lista e decidiamo l'ordine.» Ogni frase, presa da sola, è sensata. Ripetute insieme sono spesso il modo educato in cui un gruppo si mette d'accordo per non nominare la cosa che conta. Non è malafede. Aggiungere una voce è più facile, e molto meno rischioso, che ammettere «non siamo d'accordo su chi decide».

> Nessuno decide di smettere di parlarsi. Si decide, una voce alla volta, di avere qualcos'altro di cui parlare.

## Non è colpa della lista

Non voglio però farne la colpevole, e qui vorrei essere preciso. Una lista che nasconde un conflitto lo sta comunque segnalando. Ci dice che quel conflitto esiste. E ci dice che non abbiamo un posto migliore dove trattarlo. Il problema non è che le persone siano sfuggenti. È che nominare una questione di potere o di fiducia, in molte aziende, costa molto più che aggiungere lavoro. Finché è così, la lista continuerà a raccogliere quello che le riunioni non reggono. Toglierla non toglie il motivo: toglie solo il termometro. Per lo stesso motivo anche la mossa opposta, «snelliamo, dimezziamo le voci», raramente basta da sola. Svuotare il magazzino non fa sparire quello che ci avevamo messo dentro. Lo lascia lì, senza più nemmeno la riga che ne teneva memoria.

## Le domande, prima delle tecniche

Così la domanda utile, per me, non è «il nostro backlog è fatto bene?». È più scomoda, e più precisa: che cosa stiamo chiedendo a questa lista di reggere al posto nostro? Quando facciamo *slicing* — spezziamo un lavoro grande in pezzi piccoli — stiamo chiarendo il lavoro o stiamo girando intorno alla decisione che viene prima? Se cancellassimo metà delle voci domani mattina, quali conversazioni saremmo costretti finalmente ad avere? E poi come misuriamo: non «cosa stai facendo questa settimana», ma «cosa hai portato a termine, e se non l'avessi fatto sarebbe cambiato qualcosa?». È il ritorno alla prima domanda di Drucker, quella che costa: non se ci diamo abbastanza da fare, ma se stiamo facendo le cose giuste.

Non ho una tecnica da offrire, e diffido un po' di chi la offre. Ho però un confine che provo a tenere. Il refinement serve a rendere il lavoro più leggibile, non a sostituire le decisioni che spettano a qualcuno. Quando una voce torna in lista per la terza volta senza muoversi, smetto di trattarla come un problema di stima. Mi chiedo di quale decisione sia il travestimento. Di solito basta riportare la domanda al tavolo giusto: non «come lo scriviamo meglio», ma «chi risponde di questo, e cosa gli serve per decidere». È un passaggio piccolo e sgradevole. Sposta l'attenzione dalle attività a chi risponde delle scelte. Cioè proprio la cosa che una lista, quando funziona male, ci aiuta a non guardare.

## Una promessa di ordine

Una lista, in fondo, promette ordine. La domanda è di che ordine si tratti. C'è un ordine che ci rende più capaci di vedere quello che dobbiamo decidere. E c'è un ordine che ci rende più bravi a rimandarlo con la coscienza pulita: tanto è scritto, è tracciato, è sotto controllo. Da fuori i due si somigliano moltissimo.

> Da fuori, l'ordine che fa decidere e l'ordine che fa rimandare si somigliano moltissimo.

Forse l'unica prova sta in una domanda che non compare in nessuna riga di elenco. Di che cosa non stiamo parlando, mentre parliamo così bene di tutto il resto?

## Riferimenti

- Peter F. Drucker, «Managing for Business Effectiveness» (1963)
### Le cose importanti vanno dette dove qualcuno può decidere
URL: https://myagilestories.com/la-stanza-giusta-dove-una-conversazione-diventa-una-decisione/
Last updated: 2026-09-17T08:12:18.000Z
Ci sono conversazioni che sembrano chiarezza e non lo sono. Qualcuno dice finalmente come stanno le cose, con lucidità, magari con coraggio. Tutti annuiscono. E poi non cambia niente. Non perché il contenuto fosse sbagliato. Perché è stato detto nel posto sbagliato. Capita anche a persone in gamba, e mi stupisce ogni volta.

La chiamo la questione della stanza giusta. La stanza giusta è il luogo in cui una conversazione produce *accountability*: qualcuno che risponde di quello che si è deciso lì dentro. Non è una metafora. È molto concreto. La stessa frase non pesa uguale dappertutto. In un incontro a due. Fuori dalla call, a microfoni spenti. Dentro il board. Oppure detta in faccia alle persone coinvolte. Cambia stanza, cambia effetto. E quasi sempre la stanza la scegliamo senza pensarci.

> La stanza giusta non è la stanza più dura. È la più onesta.

## Chiarezza privata contro decisione pubblica

Quando una cosa importante viene detta fuori dalla stanza giusta succede qualcosa di ingannevole. Sembra che si sia fatto un passo avanti. In realtà si è prodotto allineamento privato, oppure pressione laterale, oppure sfogo. Tre cose che danno sollievo e non spostano di un centimetro il patto su cui il sistema funziona.

L'allineamento privato è quando due persone si trovano d'accordo su un problema, fuori dal luogo dove quel problema andrebbe deciso. Si sentono meglio. Si sentono meno sole. Ma la decisione non l'ha presa chi doveva prenderla, e domani il problema è ancora lì. La pressione laterale è quando faccio arrivare il mio punto per vie traverse, sperando che qualcuno lo raccolga, senza esporlo dove conterebbe. E lo sfogo è umano, a volte perfino necessario, ma resta uno sfogo. Scarica la tensione, non cambia le regole.

Per me è uno dei motivi più sottovalutati per cui le aziende restano bloccate. Non è che manchino le idee giuste. È che le idee giuste circolano nelle stanze sbagliate, dove non possono diventare decisioni. Nessuno lo fa apposta, si capisce. Semplicemente, la stanza comoda è sempre più vicina di quella giusta.

## Non vuol dire alzare la voce

C'è un equivoco da togliere di mezzo subito. Portare una cosa nella stanza giusta non significa essere più aggressivi, o fare scenate, o mettere qualcuno con le spalle al muro. Significa una cosa più impegnativa. Significa accettare che quella conversazione avrà conseguenze. Per chi la ascolta. Per chi deve decidere. Per chi poi dovrà lavorarci.

Ed è proprio per evitare le conseguenze che spesso scegliamo la stanza sbagliata. Dirlo in privato è più sicuro. Dirlo dopo la call, fra due persone fidate, non espone nessuno. Dirlo nel board, davanti a chi ha il potere e il dovere di decidere, sì. Lì ci si mette in gioco. La stanza giusta è quasi sempre la più scomoda, e non è affatto un caso.

> Quasi tutte le cose importanti vengono dette. Poche vengono dette dove qualcuno dovrà farci i conti.

## La domanda da farsi prima di parlare

La formula pratica sta tutta in una domanda, da tenere a mente prima di aprire bocca su qualcosa di importante. Questa conversazione sta avvenendo dove può produrre una decisione? Oppure sta avvenendo dove permette soltanto a qualcuno di sentirsi, per un po', più allineato? Vale per tutti i livelli, e non risparmia nessuno.

Prendi chi guida un gruppo e ha una critica da fare al management. La sta portando dove può cambiare qualcosa? O la sta lasciando cadere in un corridoio? Prendi un board che discute di una persona. Lo sta facendo dove poi qualcuno se ne assume la responsabilità? O è diventato un modo per condividere un giudizio senza agirlo? Vale anche per il coach, che a volte è il primo a raccogliere confidenze nella stanza sbagliata. Diventa, senza volerlo, il deposito di conversazioni che non arriveranno mai dove servono.

C'è poi una responsabilità di chi le stanze le governa. Chi guida un board, o modera una call, ha più potere di quanto creda su dove vanno a finire le conversazioni. Può accogliere nella stanza sbagliata cose che andrebbero portate altrove, e così, senza volerlo, disinnescarle. Oppure può fare il contrario. Quando sente arrivare un discorso importante nel corridoio, lo rimanda con gentilezza al posto dove conterebbe. Non «non dirmelo», ma «questo dobbiamo dirlo dove qualcuno può decidere». È un gesto piccolo e per niente eroico. Sposta il sistema più di tante analisi brillanti.

E vale il contrario. Chi presiede la stanza giusta ha il dovere di renderla un posto dove dire le cose non costa una rappresaglia. È quello che Amy Edmondson ha chiamato sicurezza psicologica. Una stanza è quella giusta solo se dire una cosa scomoda non si paga. Altrimenti il corridoio vince, e vince meritatamente.

In fondo la *governance* di un'azienda passa anche da qui. Dal decidere, con la testa, in quale stanza vanno certi discorsi. Non è un dettaglio di galateo. È il meccanismo per cui una diagnosi diventa un impegno, invece di restare un'opinione ben formulata. Spostare una conversazione dalla stanza sbagliata a quella giusta costa pochissimo in risorse. Costa parecchio in coraggio. Ed è lì, mi sembra, che si gioca la differenza fra un sistema che parla molto di sé e uno che si governa davvero.

Un ultimo appunto, per chi teme che tutto questo renda le aziende più fredde. È il contrario. Portare le cose nella stanza giusta protegge le persone, non le espone. Toglie le decisioni dal terreno delle simpatie, delle voci di corridoio e degli accordi sottobanco. Le mette dove possono essere discusse alla luce, con criteri che valgono per tutti. Una stanza giusta, in fondo, è soprattutto questo. Un posto dove le cose importanti arrivano a chi può decidere. E dove chi ha il coraggio di dirle non resta solo a portarne il peso.

## Riferimenti

- Amy C. Edmondson, *Organizzazioni senza paura*
- L. David Marquet, *Gira quella nave intorno!*
### La riunione c'è stata. Che cosa abbiamo visto?
URL: https://myagilestories.com/abbiamo-fatto-la-call-lo-scrum-che-tiene-la-forma-e-perde-la-sostanza/
Last updated: 2026-09-17T08:12:20.000Z
C'è una domanda che gira nei gruppi più di quanto ammettiamo: «abbiamo fatto la call?». Sembra innocua, quasi diligente. Eppure, quando diventa la misura del nostro lavoro, è il segnale che qualcosa si è già spostato. La domanda utile non è se la call si è tenuta. È un'altra, e costa molto di più: che cosa è diventato visibile grazie a quella call? Le due si somigliano soltanto finché non provi a rispondere alla seconda davanti a qualcuno.

Mettiamola così. Un'organizzazione può prendere in prestito tutto l'apparato di Scrum. I ruoli: il *product owner*, che decide che cosa vale la pena fare; lo *scrum master*, che aiuta il gruppo a lavorare meglio; gli sviluppatori. Gli eventi: la pianificazione, la review, la *retrospettiva*, il *refinement*, cioè il lavoro di chiarire le voci prima che entrino in un ciclo. Il vocabolario, con i suoi incrementi e i suoi *backlog*. E può continuare a funzionare esattamente come prima. Stesso controllo dall'alto, stesse deleghe mai dichiarate. Stessi problemi risolti in privato fra due persone, fuori dalla stanza. La forma c'è tutta. La sostanza non si è mossa di un centimetro.

## Che cosa dovrebbe far emergere

Per me è qui che sta il fraintendimento più costoso. Scrum non è un insieme di riunioni da spuntare. È un modo per rendere leggibile un sistema di lavoro. Dovrebbe far venire fuori cinque cose. Com'è messo il prodotto. Chi ha in mano che cosa. Quali risposte arrivano da chi lo usa. Quali decisioni prendiamo, e dove passano i confini fra le persone. Se dopo tre mesi di eventi puntuali quelle cinque cose non sono più chiare, non è che ci manchi ortodossia. È il rito che sta girando a vuoto.

La guida di Scrum, del resto, appoggia tutto su tre pilastri: trasparenza, ispezione, adattamento. Senza trasparenza non c'è niente da ispezionare. Senza ispezione non si adatta niente. Gli eventi esistono per tenere in piedi questi tre, non per riempire un calendario. È una cosa che si dimentica in fretta, e c'è un motivo: il calendario si vede, i tre pilastri no.

## Il rischio non è l'assenza di Scrum, è lo Scrum che copre

Un rituale ha una qualità scomoda: rassicura. Se il calendario è pieno di eventi con il nome giusto, tutti possono dirsi tranquilli. Stiamo facendo *agile*. Il *refinement* è al suo posto, la *retrospettiva* pure. Eppure una retrospettiva può benissimo essere il luogo in cui non si decide niente. E il refinement può diventare un aggiornamento di stato travestito da confronto. Quando succede, la cerimonia smette di essere una lente e diventa una tenda. Copre. Ci fa sentire allineati senza che il sistema sia cambiato di un grammo. Ed è più pericoloso dell'assenza di metodo, perché l'assenza almeno si vede. La forma vuota, no: ha l'aria di essere sana.

> C'è un modo di rispettare il metodo alla lettera che serve soltanto a non doversi guardare.

## La salsa e il pesce

Ho in mente l'immagine della salsa e del pesce. Ci si trova per mangiare un buon pesce, che sarebbe il valore vero di quell'incontro. E ci si ritrova con un piatto pieno di salsa e niente sotto. La salsa è tutto quello che aggiungiamo intorno per farlo sembrare completo: la puntualità, il formato, il fatto stesso di averlo tenuto. Ottima, per carità. Nessuno di noi ha voglia di difendere le riunioni disordinate. Ma se copre il pesce, *abbiamo sbagliato pranzo*.

## Aggiornare non è ispezionare

La versione più diffusa di questo scivolamento è quando gli eventi diventano luoghi di aggiornamento invece che momenti di ispezione. Il product owner arriva e racconta a che punto è. Lo scrum master mette a verbale. Il management ascolta e, se serve, corregge. Sembra ordinato, e in effetti lo è. Ma nessuno sta ispezionando qualcosa insieme, e quindi nessuno sta adattando niente. Ci si scambiano fatti. Nessuna delle idee di partenza viene messa in dubbio.

La differenza è sottile, e cambia tutto. Ispezionare vuol dire prendere un risultato e chiedersi se stiamo andando dove volevamo. Aggiornare vuol dire dire dove siamo, senza che quel «dove siamo» produca una decisione. Il primo è una responsabilità condivisa. Il secondo è un rendiconto. E un rendiconto puntuale, ripetuto ogni due settimane, può convivere per mesi con un prodotto che sta andando nella direzione sbagliata. Nessuno mente, in tutto questo. Semplicemente, nessuno viene mai messo nella posizione di dover decidere.

## La prova, all'uscita

Non propongo di essere più fedeli alla lettera di Scrum: sarebbe curare il sintomo con altro sintomo. Propongo una prova più onesta, da fare ogni volta che un evento finisce. Chiediti se, uscendo da quella stanza, qualcosa è diventato più leggibile di quando sei entrato, oppure è passato nelle mani di qualcuno. Se c'è una decisione che prima non c'era. Se una zona grigia sul chi-fa-cosa si è chiarita. Se una parte del lavoro che stava sottotraccia è emersa e ha trovato un posto. Se la risposta è no, e capita più spesso di quanto vorremmo, quell'evento non ti sta servendo. Ti sta consolando.

Per come la vedo, la salute di un'adozione non si misura dal numero di cerimonie rispettate. Si misura da quanto il sistema, dopo quelle cerimonie, si vede meglio da solo. Un buon rito lascia dietro di sé più chiarezza di quanta ne avesse trovata. Un rito che gira a vuoto lascia soltanto la sensazione di aver fatto la propria parte. È una sensazione piacevole, e proprio per questo regge tanto a lungo.

Per me la cosa da riportare nei gruppi è proprio un cambio di verbo. Smettere di chiedere se l'abbiamo fatta. Cominciare a chiedere che cosa abbiamo reso visibile. È una domanda più scomoda, perché a volte la risposta è niente. E quel niente, quando qualcuno trova il coraggio di dirlo ad alta voce, è già l'inizio del lavoro vero. Non serve un metodo migliore per arrivarci. Serve che qualcuno faccia la domanda mentre gli altri sono ancora seduti.

> Una risposta vuota, pronunciata davanti a tutti, vale più di un calendario rispettato per un trimestre.

## Riferimenti

- Ken Schwaber, Jeff Sutherland, *La Guida a Scrum* (2020)
### Il lavoro che non si vede tiene in piedi il resto
URL: https://myagilestories.com/il-lavoro-sommerso-non-e-disordine-e-un-messaggio/
Last updated: 2026-09-17T08:12:20.000Z
In quasi ogni gruppo c'è un livello di lavoro che non si vede. Non compare nel *backlog*, cioè nell'elenco del lavoro riconosciuto. Non ha un *owner*: nessuno ne risponde. Non passa da nessun rito. Eppure senza quel lavoro il sistema non starebbe in piedi. Qualcuno tiene insieme le cose, ricuce, anticipa, compensa. E lo fa in silenzio, perché è la cosa più naturale del mondo: se manca un pezzo, lo metti tu.

Mi viene in mente la casa dove c'è sempre qualcuno che ricompra il latte quando sta per finire. Nessuno lo nomina. Nessuno lo ringrazia. E te ne accorgi solo il giorno in cui quella persona non c'è, e *il caffè te lo bevi amaro*. Chiamiamolo lavoro sommerso. La tentazione, quando lo scopriamo, è di trattarlo come un problema di ordine. Basta segnarlo. Diamogli una riga in lista, e il gioco è fatto. Ed è qui, secondo me, che si sbaglia mira.

Metterlo negli strumenti ufficiali non è la soluzione. Semmai è l'ultimo passo di una domanda che va fatta prima: perché quel lavoro un posto non ce l'aveva? È una domanda che non piace a nessuno, perché non si chiude in una riunione. Ma è l'unica che guarda il sistema invece delle persone.

## Il sommerso come sintomo, non come svista

Le attività sommerse non sono attività dimenticate. Sono un sintomo. Ci dicono che una parte del lavoro serve davvero a far funzionare gruppi, persone e ruoli. E che quella parte sta fuori da tutto ciò che l'azienda riconosce come lavoro. E allora la domanda seria non è «chi non l'ha segnato?». Quella cerca un colpevole e chiude il caso. La domanda seria è più scomoda: che cosa, qui dentro, rende conveniente che questo lavoro resti invisibile?

È il modo di guardare che Donella Meadows insegna a chi prova a capire un sistema. La struttura che regge certi comportamenti pesa più delle intenzioni di chi ci sta dentro. Il sommerso, di solito, non è casuale. C'è sempre una ragione per cui è rimasto sotto. Magari mancava un owner, e nessuno se lo voleva prendere. Magari mancava un incontro dove potesse venire fuori. Magari mancava una definizione di valore, e quel lavoro non «contava» abbastanza per meritarsi un posto. Oppure, ed è la versione più difficile da dire ad alta voce, il sistema dava per scontato che qualcuno compensasse in silenzio. E finché quel qualcuno compensa, il problema non si vede. Quindi non esiste.

## Perché il backlog da solo non salva

Nei gruppi si tende a pensare che il backlog e gli strumenti di gestione facciano emergere da soli il lavoro vero. Non è così scontato. Un backlog può benissimo diventare una nuova superficie ordinata, costruita sopra lo stesso sommerso. Bella da vedere, aggiornata, piena di righe. E sotto, intatto, tutto il lavoro che nessuno ha voglia o modo di rendere ufficiale.

Il backlog serve se fa risalire quello che stava sotto. Non serve, e a volte peggiora le cose, se diventa solo un altro livello che ci fa sentire a posto. Perché a quel punto abbiamo due sistemi. Quello ufficiale, ordinato. E quello vero, sommerso. Chi lavora nel secondo si sente più solo di prima, perché adesso c'è pure la prova scritta che il suo lavoro non conta.

> Una persona affidabile può reggere per anni un pezzo di azienda che nessuno ha deciso di costruire.

## Rendere visibile è già governare

Alla radice, portare a galla il sommerso è un gesto di *governance*, non di igiene della bacheca. Vuol dire prendere una posizione su che cosa, in questa azienda, conta come lavoro. Vuol dire decidere che la compensazione silenziosa non è un tratto di carattere da lodare a fine anno. È un buco di sistema da chiudere.

E ha delle conseguenze, se lo si fa sul serio. La prima è che qualcuno dovrà smettere di tappare i buchi, e per un po' le cose funzioneranno peggio. È scomodo, ma è sano. Solo quando il pezzo mancante si vede possiamo decidere chi se lo prende davvero. La seconda è che alcune attività, una volta emerse, scopriremo che non servivano. Le facevamo per abitudine, o per paura. Anche questo è un risultato. Il sommerso non è soltanto lavoro prezioso nascosto: a volte è lavoro inutile che nessuno ha mai osato discutere, perché non era mai stato nominato.

C'è anche una questione di giustizia, non solo di efficienza. Il lavoro sommerso ricade quasi sempre sulle stesse persone. Quelle che non riescono a lasciare un buco scoperto. Quelle che si sentono responsabili anche di ciò che nessuno ha assegnato loro. Sono spesso le più affidabili, e proprio per questo le più esposte. Il sistema impara che quelle persone reggono, e smette di chiedersi se dovrebbero. Rendere visibile quel lavoro serve anche a loro. Toglie dalle loro spalle la parte che non gli spetta, e la riporta a una decisione di tutti. Finché resta sottotraccia, l'unico riconoscimento possibile è privato, informale, e non cambia le regole.

La mossa pratica non è aggiungere una colonna alla bacheca. È cambiare la prima domanda. Non «come mai questo non era tracciato?», ma «che cosa ci stava dicendo il fatto che non lo fosse?». La prima cerca un responsabile. La seconda cerca un pezzo di sistema da capire. E succede una cosa piccola e vera. Chi fin qui ha retto in silenzio smette di essere l'ingranaggio affidabile che nessuno nomina. Torna a essere una persona con un carico che qualcuno, finalmente, ha visto.

> Il lavoro che non ha un nome non si può dividere fra due persone. Si può solo continuare a fare.

## Riferimenti

- Donella Meadows, *Pensare per sistemi*
### Abbiamo preso un movimento e ne abbiamo fatto un manuale
URL: https://myagilestories.com/agile-per-me-e-un-movimento/
Last updated: 2026-09-17T08:12:20.000Z
C'è una parola che mi torna in mente ogni volta che provo a spiegare che cosa sia davvero *agile*: movimento. Mi viene prima ancora di «metodo», prima di «framework», prima di tutte le parole che di solito ci mettiamo intorno. Agile mi fa pensare a qualcosa che si muove, che non sta fermo, che cambia posizione mentre lo guardi. Per un po' l'ho tenuta come un'immagine mia, di quelle che uso per capire le cose.

Poi mi sono fermato sulla parola, e ho visto che non era soltanto un'immagine. Agile è nato letteralmente come un movimento. Nel 2001 un gruppo di persone si è trovato e ha scritto un manifesto. Quattro valori e dodici principi, messi nero su bianco. Non un prodotto. Non una certificazione. Non uno strumento da comprare. Un manifesto: la stessa parola che usiamo per i movimenti veri. Quelli che nascono perché un po' di gente sente che il modo in cui si stanno facendo le cose non va più bene.

Mettiamola così. Agile non è una cosa che qualcuno ha inventato e venduto. È una cosa che qualcuno ha dichiarato. E fra inventare e dichiarare, per me, c'è tutta la differenza del mondo. So bene che i metodi c'erano già: Scrum e l'Extreme Programming venivano prima del 2001\. Il Manifesto però è il momento in cui quella roba è stata dichiarata come una direzione comune, e non soltanto praticata da qualcuno.

Ed è qui la cosa che mi piace di più: i due sensi non sono separati. Agile mi fa pensare al movimento, e insieme agile è un movimento. Il senso figurato, quello del muoversi, e quello letterale, il gruppo di persone con un manifesto, finiscono per dire la stessa cosa. Per questo la parola mi convince. Non la sto usando come metafora. La sto usando come descrizione.

> Un manifesto si può tradire. Un prodotto comprato si può soltanto usare male.

## Non me lo sto inventando

Quando dico che abbiamo trasformato un movimento in un metodo non sto sfogando un'insofferenza personale. È una cosa che, dentro il mondo agile, hanno detto persone ben più titolate di me. E l'hanno detta partendo proprio dal Manifesto.

Il Manifesto del 2001 mette al primo posto una frase semplice: gli individui e le interazioni più che i processi e gli strumenti. Non «al posto di», ma «più che». La direzione è già tutta lì. Gli strumenti servono, ma vengono dopo le persone. Buona parte di quello che oggi chiamiamo Agile ha girato quella frase al contrario, e ha messo davanti processi, strumenti e cerimonie.

Alcuni di quelli che il Manifesto lo hanno firmato se ne sono accorti presto. Dave Thomas, uno degli autori, qualche anno fa ha scritto un pezzo dal titolo volutamente brusco: «Agile Is Dead». Il suo punto non era che l'idea fosse sbagliata. Era che la parola «Agile», con la maiuscola, era diventata un'industria di certificazioni e di strumenti da vendere. E che per strada aveva perso l'agilità come modo di lavorare. Preferiva tornare al verbo e all'aggettivo: non «fare Agile», ma «essere agili».

Martin Fowler, un altro firmatario, ha usato un'espressione che mi è rimasta impressa: *agile industrial complex*. Descrive l'agile calato dall'alto, imposto ai gruppi come procedura invece che scelto da loro come modo di stare insieme. Che è, guarda caso, l'esatto contrario di quel primo valore. Quando dico movimento, insomma, mi ritrovo dalla stessa parte di queste voci. Non ho la pretesa di aver scoperto niente. Ho un modo mio di raccontarlo, che parte da una parola invece che da una diagnosi tecnica.

## Movimento e metodo non sono la stessa cosa

Quando penso ai movimenti, penso a qualcosa che si tiene insieme grazie a un'idea condivisa. Non grazie a un regolamento. Le persone di un movimento non fanno le stesse cose perché qualcuno gliel'ha imposto. Le fanno perché credono nella stessa direzione. Puoi anche non conoscere i dettagli, ma sai da che parte stai andando.

Un metodo è un'altra cosa. Un metodo ti dice i passi. Fai questo, poi quello, alla fine ottieni il risultato. È utilissimo, per carità, e non ho niente contro i metodi. Ma un metodo, da solo, non ti dice il perché. Puoi eseguirlo alla perfezione e non aver capito niente di dove volevi arrivare.

Il guaio, mi sembra, è che negli anni abbiamo preso un movimento e l'abbiamo trattato come un metodo. Abbiamo tenuto i passi e abbiamo perso la direzione. Ci siamo riempiti di eventi, ruoli, cerimonie. E a un certo punto ci siamo dimenticati che tutto quello era nato per servire un'idea, non per prenderne il posto.

## La differenza fra ballare ed eseguire i passi

C'è un'immagine che mi aiuta. Pensa alla differenza fra uno che balla e uno che esegue i passi di un ballo. Da fuori, per un istante, possono sembrare uguali. Stessi movimenti, stesso ritmo. Ma uno sta dentro la musica, e l'altro sta contando nella testa «uno, due, tre». Uno si muove. L'altro esegue.

Tantissimi gruppi agili, oggi, stanno eseguendo i passi. Hanno il daily. Hanno la *retrospettiva*. Hanno la bacheca piena di foglietti colorati. Contano «uno, due, tre» benissimo. Ma non stanno ballando. Non c'è più il movimento, c'è la coreografia. E la coreografia, quando la musica finisce, resta lì immobile, con le persone ferme nella posa giusta ad aspettare la prossima battuta.

È questo che mi interessa davvero. Non se un gruppo fa Scrum «bene», ma se si sta ancora muovendo. Se le cose cambiano davvero da uno sprint all'altro, oppure se cambia soltanto il numero sopra il grafico. Un rito rispettato alla lettera può darti l'illusione del movimento mentre sei fermo. Ed è un'illusione comoda, perché ti fa sentire a posto.

> Da fuori, chi balla e chi conta i passi si somigliano per qualche secondo. Poi la musica cambia.

## Governare il movimento, non incorniciarlo

Attenzione, non sto dicendo che serva meno struttura. Un movimento senza direzione si disperde. Diventa entusiasmo che non porta da nessuna parte, e ho visto anche quello: non è più sano del rito. La domanda non è «regole sì o regole no». È un'altra. Le regole che ci diamo servono a tenere vivo il movimento, oppure servono a sostituirlo?

Per me governare un sistema agile vuol dire proprio questo. Non mettere il movimento in una cornice, dove sta bello ordinato e non si muove più. Tenerlo in strada. Proteggere la direzione, rendere visibile dove stiamo andando, lasciare che le persone si muovano davvero invece di eseguire. La *governance* che mi piace è quella che serve il movimento e lo accompagna. Quella meno utile è quella che lo blocca, lo mette in ordine, e continua a chiamarlo movimento anche quando ormai sta fermo.

E allora forse il primo passo è ricordarsi da dove veniamo. Agile è partito come la scelta di alcune persone che hanno voluto provare a lavorare in un altro modo. E l'hanno messa per iscritto. Non come un catalogo di riti da rispettare. Se vogliamo che continui a significare qualcosa, credo valga la pena tornare a trattarlo per quello che è. Un movimento. Qualcosa che resta vivo finché si muove.

## Riferimenti

- Manifesto per lo Sviluppo Agile di Software (2001)
- Dave Thomas, «Agile Is Dead (Long Live Agility)» (2014)
- Martin Fowler, «The State of Agile Software in 2018» (l'espressione «agile industrial complex»)