Esecuzione della collaborazione sull'IA in modalità retro

Noi di TeamRetro siamo interessati a ogni ciclo di miglioramento continuo intrapreso da un team. Il lavoro assistito dall’intelligenza artificiale è un nuovo ambito che stiamo analizzando attraverso la nostra prospettiva retrospettiva; questa guida illustra le conclusioni a cui siamo giunti finora. La invitiamo a prenderla, adattarla e applicarla a qualsiasi strumento o pratica già in uso.

Parte 1: la guida

Perché questo dovrebbe far parte di una cerimonia di squadra

Da qualche parte all’interno del vostro team, questo mese, un assistente di intelligenza artificiale ha dedicato quaranta minuti a verificare una campagna pubblicitaria “non funzionante” che era stata deliberatamente messa in pausa, poiché il brief non lo specificava. La persona che gestiva la sessione ha corretto l’errore, ha alzato le spalle e ha proseguito. Se quattro colleghi si imbattono in versioni dello stesso errore, si tratta di ore di spreco silenzioso al mese, e nessuno se ne accorge, poiché ciascuno ha dovuto far fronte a tale problema da solo.

Questo è lo schema tipico dei problemi di attrito nelle sessioni di IA: sono cronici e di lieve entità, quindi non danno mai luogo a un’analisi post mortem, e sono effimeri, quindi svaniscono al termine della sessione. La maggior parte dei team è già in grado di monitorarlo (circa il 90% strumentalizza le tracce dei propri agenti), ma sono ben pochi quelli che lo trasformano in correzioni: solo circa il 37–52% valuta sistematicamente i dati acquisiti (LangChain, giugno 2026).

I cicli di miglioramento esistenti sono validi e questa pratica si basa su tutti loro: AGENTS.mdgli aggiornamenti dei file di contesto, i sistemi di memoria, le pipeline di auto-miglioramento dei fornitori, l’analisi degli errori sulle tracce (Husain & Shankar, FAQ sulle valutazioni). Persino i fornitori ricorrono al termine «retro»: le linee guida di Codex di OpenAI recitano «quando Codex commette lo stesso errore due volte, richiedetegli una retrospettiva e aggiornate AGENTS.md» (migliori pratiche). Tuttavia, quasi tutti questi cicli sono individuali: una persona e il suo agente, oppure una piattaforma e la sua flotta. Ciò che il livello di squadra aggiunge è l’aggregazione: un attrito che ammonta a cinque minuti ignorati per persona diventa un costo rilevante per la squadra solo nella visione aggregata, e agire di conseguenza (riscrivere il modello condiviso, modificare il processo di acquisizione, acquistare lo strumento) richiede un livello decisionale che nessun singolo individuo possiede. Il «Feedback Flywheel» di Rahul Garg ne indica la sede: «un punto all’ordine del giorno nella retrospettiva di sprint esistente: cosa ha funzionato con l’IA in questo sprint?» (martinfowler.com), e questa guida rappresenta un modo per condurla.

Una sincera ammissione fin dall’inizio: ciò di cui si ha bisogno è una cerimonia ricorrente, imparziale e basata sui dati, alla quale partecipino i responsabili delle correzioni. Per la maggior parte dei team si tratta del retro, ma anche una sessione di pianificazione dello sprint, una revisione mensile delle operazioni o una revisione degli account da parte del team addetto ai media possono fungere da contesto altrettanto valido. Il retro, o la vostra cerimonia esistente di forma equivalente.

Informazioni utili per un facilitatore: Scrum.org affronta lo stesso argomento dal punto di vista delle metriche; la loro guida su come condurre la retrospettiva di sprint quando metà del team è composto da agenti di IA ridefinisce l’evento come una revisione basata sui dati delle prestazioni degli agenti (riscritture dei prompt, tassi di deviazione, consumo di token). La presente guida adotta un approccio complementare: individuazione delle cause alla radice e soluzioni a livello dell’intera collaborazione, con gli agenti che contribuiscono fornendo la propria descrizione del lavoro, archiviata tramite il server MCP di TeamRetro qualora utilizziate TeamRetro. I team con un numero elevato di agenti potrebbero trovare utile avvalersi di elementi di entrambi gli approcci.

Come funziona la procedura, dall’inizio alla fine

1. Raccolta dei dati, per sessione. Al termine di ogni sessione significativa assistita dall’intelligenza artificiale, l’agente redige una breve nota strutturata: cosa ha funzionato bene, cosa ha rallentato il processo (ogni elemento accompagnato da una causa principale e da una soluzione proposta), quali ipotesi ha formulato e la singola soluzione con il maggiore impatto. Un file per ogni voce, in un registro condiviso.
2. Sintesi, dopo circa 5 voci. Prima della cerimonia, l’agente sintetizza il registro in una sintesi di una pagina: temi ricorrenti ordinati in base alla frequenza × costo, una distribuzione delle cause alla radice, una verifica dell’adozione delle soluzioni adottate in passato e le tre azioni principali raccomandate.
3. Decidete entro 15 minuti. Il resoconto costituisce un punto all’ordine del giorno della vostra retrospettiva già in programma, non una nuova riunione. Il team effettua una selezione prioritaria: decide se mantenere o eliminare ciascun ostacolo, conferma a quale fase del processo debba essere assegnata ciascuna soluzione e assegna i responsabili alle azioni prioritarie. Nel resoconto del ciclo successivo si verifica se l’ostacolo è effettivamente stato eliminato.

Le fasi di acquisizione e sintesi sono implementate come competenze degli agenti open source nel nostro repository TeamRetro-skills, qualora desideriate partire subito.

L’agente riferisce senza filtri: un agente che necessita dell’autorizzazione per registrare gli attriti sottostima, e le correzioni umane a posteriori costituiscono un segnale aggiuntivo, non un punto di controllo in attesa del quale il ciclo si blocca. La decisione spetta al team, e non per semplice cortesia: le correzioni si concretizzano in budget, documenti, processi e strumenti di cui le persone sono responsabili e per i quali rispondono. L’agente fornisce prove e bozze; è la sala a decidere.

Come si presenta un buon contributo

Ecco un esempio concreto, volutamente non incentrato sulla programmazione:

# 2026-07-16: Monthly ads account review

**Session size:** ~25 turns, 1 deliverable
**Outcome:** shipped

## Went well
- Exec summary shipped in one pass; the account structure doc from last month held up

## Friction
- **[missing-context]** The brief didn't say the French campaigns were deliberately
  paused for Q3; ~40 min (est.) auditing a "broken" campaign that was fine.
  → Fix (altitude: process): add campaign-status flags to the monthly brief template

## Guesses made
- Assumed the target CPA unchanged from June, unverified

## Do this first
Campaign-status flags in the brief template. Kills the largest single time sink this month.

Si noti la rigorosità. Ogni elemento di attrito riporta un momento e un costo (stime approssimative contrassegnate con (est.)), è associato esattamente a un’etichetta indicante la causa principale, scelta da un vocabolario ristretto e fisso (etichette quali ambiguous-instruction, missing-context, missing-documentation, missing-access-or-tool, agent-error, o work-material-friction, dove l’elemento stesso costituiva l’ostacolo: una struttura di campagna intricata, un foglio di calcolo obsoleto, un modulo che nessuno vuole toccare, sempre indicando l’elemento concreto per nome), e si conclude con una soluzione delle dimensioni di un ticket che ne specifica la portata: questa soluzione deve essere inserita in una nota privata, in una procedura, nell’ambiente, nella documentazione, nel materiale di lavoro stesso, nel processo o a monte con un fornitore? Le etichette fisse sono ciò che rende le voci comparabili tra persone e sessioni diverse; «la documentazione era confusa» non può essere aggregata, ma otto vocimissing-documentation sì. La vaghezza è la modalità di errore; «nulla di rilevante» è una voce valida.

Un buon riepilogo si limita a una pagina: temi ricorrenti (“4 sessioni su 9”) ed esempi datati, una chiara indicazione del gruppo di cause principali predominante (briefing, documentazione, materiale di lavoro, strumenti o agente; è su questo che dovrebbe concentrarsi l’attenzione del team), la verifica dell’adozione dei suggerimenti passati e tre azioni assegnabili a un responsabile. Il briefing alimenta la conversazione, ma non la sostituisce.

Ambito: un log per ogni ambito di revisione

Si mantenga un registro per ogni ambito di revisione: il confine entro il quale verrebbero applicate le correzioni. Per il lavoro di sviluppo, solitamente si tratta del repository, poiché è lì che risiedono la documentazione, la configurazione e le convenzioni. Per il lavoro non legato al codice, si tratta dell’account pubblicitario, della casella di posta dell’assistenza, del coinvolgimento del cliente; il registro si trova nella cartella principale dei documenti di quell’area di lavoro. Una voce archiviata al di fuori del proprio ambito è una voce che il responsabile della correzione non troverà mai. Lo schema rimane identico ovunque; è lo schema, non l’archivio, a consentire l’aggregazione delle voci.

Le regole “never-log”

Le voci vengono registrate, condivise e sopravvivono al proprio contesto; pertanto, alcune informazioni non devono mai essere inserite: segreti, credenziali o chiavi in qualsiasi forma; dati dei clienti o informazioni personali; dati aziendali non ancora resi pubblici; e, aspetto fondamentale per la cultura retrò, nomi, ruoli o qualsiasi elemento che identifichi una persona. Descriva la lacuna e il suo costo, mai chi l’ha causata: «il brief ha lasciato il pubblico all’oscuro», non «il brief di X». Gli elementi di attrito criticano gli input e i sistemi, non le persone. Se l’attrito di un ambito non può essere descritto senza ricorrere a contesti sensibili, mantenga private tali voci e condivida solo il brief aggregato.

Parte 2: il modello “AI Collaboration Retro”

Un formato pronto all’uso: cinque spunti, basati sullo schema di partenza, utilizzabili in TeamRetro o su qualsiasi lavagna:

Rubrica	Prompt	Battuta
È andato tutto bene	In questo ciclo, quali attività sono state rese più veloci o più efficaci grazie all’assistenza dell’intelligenza artificiale?	Solo le vittorie supportate da prove concrete: ciò che occorre tutelare e ripetere, non elogi infondati.
L’attrito e la sua causa	In quale punto si è verificato il rallentamento e quale ne è stata la causa principale?	Ogni scheda indica il momento, il costo approssimativo e un termine tratto dal vocabolario prestabilito del team.
Ipotesi che lasciamo in sospeso	Cosa ha supposto l’agente (o noi) senza disporre di informazioni sufficienti?	Attriti latenti che non hanno ancora causato problemi; contrassegnare tutto ciò che non è ancora stato verificato.
Conservare o eliminare	Quali di questi attriti abbiamo scelto intenzionalmente?	Le fasi di revisione e le procedure di approvazione possono costituire punti di controllo deliberati (sintesi dell’intervento di Ronacher all’AIE Europe); la decisione di eliminarne uno spetta al team.
Si prega di procedere in questo modo per prima cosa	Tra tutte le opzioni qui presenti, quale intervento risulta più vantaggioso e a quale altitudine?	Al massimo tre voci, ciascuna con un responsabile e il livello a cui si colloca: documentazione, ambiente, processo, materiale o a monte.

Parte 3: Schede con suggerimenti per il facilitatore

Domande da porre quando un team presenta un brief relativo all’AI-retro durante la cerimonia. Una per scheda; utilizzi quelle necessarie allo svolgimento della conversazione.

1. “A quale sessione si riferisce e qual è stato il costo?” Le segnalazioni relative a modelli richiedono prove datate; una scheda priva di data e importo non può essere valutata.
2. “Questo attrito è un punto di controllo che abbiamo scelto?” Innanzitutto, la regola “mantenere o eliminare”: una certa quantità di attrito è fondamentale per la guida (riassunto dell’intervento di Ronacher all’AIE Europe), e l’assenza di attrito non è gratuita; Thoughtworks mette in guardia dal debito cognitivo che ne deriva (annuncio).
3. “Abbiamo proposto questa soluzione già l’ultima volta. Cosa ne ha impedito l’attuazione?” I suggerimenti ripetuti e non adottati rappresentano l’elemento più significativo di qualsiasi relazione; senza questa domanda, l’intero processo non è altro che una farsa.
4. “Questo è costato a ciascuno di voi dieci minuti; quanto costa al team ogni mese?” L’aggregazione rappresenta il vero punto di forza del team; ricorrervi ogni volta che una scheda viene ignorata.
5. “Questa correzione va inserita nella documentazione, nell’ambiente o nelle istruzioni di lavoro?” La questione della misura giusta. Se si punta troppo in basso, il problema si ripresenta; se si punta troppo in alto, si ingrossa l’elemento sbagliato.
6. “A chi appartiene il reperto in cui viene collocata questa riparazione?” Un’azione senza un proprietario è un oggetto della lista dei desideri. Se il proprietario non si trova nella stanza, anche quella è una scoperta.
7. “Prima di attribuire la colpa all’agente, ci si deve chiedere se i dati in ingresso fossero adeguati?” agent-errorè l’etichetta residuale, non quella predefinita; l’approccio predefinito, che va respinto, consiste nell’attribuire la colpa all’agente quando il problema risiede nell’harness o nelle istruzioni, pertanto occorre correggere l’harness (Osmani, Agent Harness Engineering).
8. “Quale gruppo di cause alla radice prevale nella distribuzione, ed è proprio su quello che stiamo concentrando la nostra attenzione?” I dati riportati nel briefing indicano se il problema riguarda il briefing stesso, la documentazione, il materiale di lavoro, gli strumenti o la configurazione dell’agente. L’attenzione dovrebbe seguire i dati.
9. “È stata una persona a individuarlo, o l’agente?” La correzione umana rimane ancora il sensore predominante: uno studio sulla produzione ha rilevato che circa il 70% degli errori silenziosi è stato individuato per primo da una persona che ha notato qualcosa di anomalo (arXiv 2606.14589). Considerate tali rilevamenti come prove di prim’ordine, non come interruzioni.
10. “Si tratta dell’ambito del nostro team o di quello di un altro team?” Le correzioni rientrano nell’ambito di revisione del proprio team; una scheda relativa al modello condiviso o al processo di un altro team dovrebbe essere inoltrata, non assorbita.
11. “Si tratta di una discussione o di una registrazione?” Le correzioni ovvie vanno inserite direttamente nel tracker; dedichi i quindici minuti esclusivamente alle chiamate contestate: confermare o annullare, controversie sull’altitudine, priorità.
12. “Questa decisione va oltre le competenze di ciascuno di noi?” L’acquisto di uno strumento, la modifica di un processo, il ricorso a un fornitore: l’elenco delle priorità riponderato spesso supera i limiti delle decisioni individuali. È proprio questo il motivo per cui l’argomento è stato sollevato in questa sede.

---

Capitolo successivo: Iniziate in dieci minuti. Installate le competenze ed eseguite la vostra prima acquisizione, oppure adattate il modello sopra riportato alla bacheca che il vostro team già utilizza. Parte della guida alle retrospettive degli agenti AI.