Esecuzione della collaborazione AI 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 ottica 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 Suo team, questo mese, un assistente basato sull’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 è il quadro tipico dei problemi di attrito nelle sessioni di IA: si tratta di un fenomeno cronico e di lieve entità, che non dà mai luogo a un’analisi post mortem, ed è effimero, quindi svanisce al termine della sessione. La maggior parte dei team è già in grado di monitorarlo (circa il 90% strumenta le tracce dei propri agenti), ma sono ben pochi quelli che lo trasformano in soluzioni: 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.md gli 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 proprio agente, oppure una piattaforma e la sua flotta. Ciò che il livello di squadra aggiunge è l’aggregazione: un attrito che equivale a cinque minuti ignorati a testa 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 definisce 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 altrettanto bene da occasione per tale evento. Il retro, o la vostra cerimonia esistente di forma equivalente.

Informazioni utili per i facilitatori: Scrum.org affronta lo stesso argomento dal punto di vista delle metriche; la loro guida alla conduzione della 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: individua le cause alla radice e propone 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 che dispongono di un ampio parco di agenti potrebbero trarre vantaggio dall’adozione di elementi di entrambi gli approcci.

Come funziona la procedura, dall’inizio alla fine

1. Acquisizione, per sessione. Al termine di ogni sessione significativa assistita dall’IA, l’agente redige una breve nota strutturata: cosa ha funzionato bene, cosa ha rallentato il processo (con ogni punto contrassegnato 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 riunione retrospettiva già in programma, non una nuova riunione. Il team effettua una valutazione 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 rimane in sospeso. 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, che non riguarda, di proposito, una sessione di 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 in sé costituiva l’ostacolo: una struttura della 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 presso un fornitore? Sono proprio le etichette fisse a rendere le voci comparabili tra persone e sessioni diverse; «la documentazione era confusa» non può essere aggregata, ma ottomissing-documentationvoci 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, un’indicazione chiara di quale gruppo di cause alla radice prevalga (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

Mantenete un registro per ogni ambito di revisione: il confine entro il quale verrebbero applicate le correzioni. Per il lavoro di sviluppo si tratta solitamente 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 o del rapporto con il 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, alcuni elementi non devono mai essere inseriti: 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 costo che ne è derivato, 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 relativo a un ambito non può essere descritto senza un contesto sensibile, 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
È andata bene	In che modo il lavoro assistito dall’intelligenza artificiale ha consentito di ottenere risultati più rapidi o migliori in questo ciclo?	Solo i successi supportati da prove concrete: ciò che occorre tutelare e replicare, senza gonfiare le lodi.
L’attrito e la sua causa	In quale punto si è verificato il rallentamento e qual è 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.
Mantenere 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 è più redditizio 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 più adatte al contesto 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’adozione?” I suggerimenti ripetuti e non accolti rappresentano l’elemento più significativo in 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; ponete questa domanda ogni volta che una scheda viene ignorata.
5. “Questa correzione va inserita nella documentazione, nell’ambiente o nelle istruzioni di lavoro?” La questione cruciale. Se si punta troppo in basso, il problema si ripresenta; se si punta troppo in alto, si ingrossa l’artefatto sbagliato.
6. “A chi appartiene il reperto in cui viene collocata questa correzione?” Un’azione senza un proprietario è un oggetto della lista dei desideri. Se il proprietario non si trova nella stanza, anche questo costituisce un ritrovamento.
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’atteggiamento predefinito da evitare è quello di incolpare l’agente quando il problema risiede nell’harness o nelle istruzioni — occorre invece correggere l’harness (Osmani, Agent Harness Engineering).
8. “Quale gruppo di cause principali 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 individuazioni come prove di prim’ordine, non come interruzioni.
10. “Si tratta dell’ambito di competenza 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; dedicate i quindici minuti esclusivamente alle decisioni contestate: confermare o annullare, controversie sull’altitudine, priorità.
12. “Questa decisione va al di là delle competenze di ciascuno di noi?” L’acquisto di uno strumento, la modifica di un processo, il ricorso a un fornitore: l’elenco delle priorità ridefinito spesso supera i limiti delle decisioni individuali. È proprio per questo motivo che 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.