Agile Team Coaching

Intelligenza emotiva, presenza, ascolto, domande potenti e feedback sono alla base della postura di coaching. Le applicheremo nei contesti Agile per generare consapevolezza senza giudicare, suggerire soluzioni o sostituirci alla responsabilità delle persone.

Dall’identificazione del tema all’esplorazione, fino alla scelta di un’azione concreta. Impareremo a condurre una conversazione completa su situazioni Agile, aiutando il cliente a trasformare consapevolezza e apprendimento in un impegno scelto autonomamente.

Fare mentoring non significa distribuire consigli. Impareremo a mettere a disposizione esperienza e competenza, offrire possibilità con chiarezza e preservare la libertà del mentee di scegliere ciò che è più adatto al proprio contesto.

L’Agile modifica responsabilità, identità professionali e relazioni. Esploreremo i cicli individuali del cambiamento, le principali transizioni di ruolo e le resistenze, imparando a distinguere quando fare coaching e quando offrire mentoring.

Impareremo a progettare esperienze formative utilizzando modalità diverse, contenuti accessibili e verifiche reali della comprensione. Alleneremo la capacità di far sperimentare i cambiamenti di mindset e di spiegare con chiarezza almeno un framework Agile.

Dopo aver visto le quattro posture — coach, mentor, facilitatore, formatore — arriva la domanda che ogni Agile Team Coach si pone: come si arriva all’alta prestazione? La risposta è scomoda: non ci si arriva, non in modo definitivo. L’alta prestazione non è una destinazione, è un momento che emerge, dura, svanisce e — se il team lavora bene — riappare. È un sistema vivente, non una macchina da ottimizzare: il coach non “porta” il team all’alta prestazione, lo accompagna nel viaggio.

Tre verità da tenere ferme: non tutti i team ci arriveranno (a volte il problema è il sistema, non il team); l’alta prestazione è temporanea, fragile, ciclica; e non è l’unico obiettivo — senza sostenibilità, alta prestazione è solo sfruttamento.

Il lavoro si articola su quattro piani: riconoscere le sei caratteristiche osservabili dell’alta prestazione (fiducia e sicurezza psicologica, chiarezza di scopo, autonomia, gestione sana del conflitto, collaborazione, miglioramento continuo); accettare che il viaggio è una spirale, non una linea retta — regressioni comprese, normali e non fallimentari; valutare la salute del team come sistema, usando insieme la piramide di Lencioni, il Team Health Check di Spotify e l’osservazione diretta dei pattern, senza ignorare i fattori ambientali (distribuzione geografica, cultura, impedimenti organizzativi); e infine adattare il proprio stile — Directing, Coaching, Supporting, Delegating — alla maturità del team, muovendosi lungo il continuum da “leading from the front” a “leading from the back”.

Prima dell’incontro: leggo i paragrafi 6.3.1–6.3.4 — le sei caratteristiche dell’alta prestazione, i cicli di sviluppo/energia/apprendimento, i tre modelli di valutazione della salute del team, i quattro stili di coaching situazionale.

In aula: ogni partecipante porta un team reale e lo colloca su tre assi — dove si trova nel ciclo (Forming/Storming/Norming/Performing), quale disfunzione di Lencioni è più presente, quale stile di coaching sta usando oggi rispetto a quello che il team richiederebbe. Confrontiamo le letture in piccoli gruppi: spesso emerge un disallineamento tra lo stile agito e la maturità reale del team.

Trappola ricorrente: trattare una regressione come un fallimento da correggere in fretta invece che come una fase normale da attraversare — restando nello stile Directing molto oltre il momento in cui il team ne avrebbe bisogno.

Domanda-manifesto: Il mio stile sta rendendo questo team più autonomo, o più dipendente da me?

Dopo l’incontro: scelgo un team che accompagno e applico un Team Health Check (o l’osservazione diretta dei pattern) per una fotografia onesta della sua salute attuale.

Ogni team ha conflitti, ogni team ha disfunzioni — chi dice il contrario lo sta nascondendo. Il conflitto evitato non scompare: si accumula, diventa tossico, esplode. Il compito dell’Agile Team Coach non è eliminare il conflitto, ma trasformarlo da distruttivo a sano, lavorando su tre livelli integrati: i comportamenti (far emergere e facilitare il conflitto in superficie), le capacità (autoconsapevolezza e autoregolazione del team, con la Self-Determination Theory e la Finestra di Johari), e la prospettiva (vedere il team come sistema umano, dove il conflitto tra due persone spesso è il sintomo di una dinamica sistemica — priorità non allineate, incentivi sbagliati, mancanza di trasparenza — non una colpa individuale).

Prima dell’incontro: leggo i paragrafi 6.4.1, 6.4.2 e 6.4.3 — segnali del conflitto nascosto e conflict competency; SDT e Finestra di Johari; team come sistema e dinamiche ricorrenti (free-riding, blame shifting, specializzazione profonda).

In aula: ogni partecipante porta un conflitto reale osservato in un team. Insieme lo leggiamo su tre livelli: cosa è visibile (comportamenti), cosa rivela sulla consapevolezza del team, e quale dinamica sistemica potrebbe starci dietro. Proviamo poi una tecnica per far emergere disaccordo latente (Fist to Five o Pre-Mortem) su un caso portato in aula.

Trappola ricorrente: risolvere il conflitto al posto del team — “ok, facciamo così, problema risolto” — lasciandolo dipendente invece che più competente.

Domanda-manifesto: Sto trattando questo conflitto come colpa di una persona, o come segnale di un sistema?

Dopo l’incontro: osservo un team che accompagno e provo a nominare — senza risolvere — un conflitto che finora è rimasto sotto la superficie.

Fin qui abbiamo lavorato dentro i confini del team — postura, mentoring, teaching, alta prestazione, conflitto. Ma ci sono ostacoli che il team non può sciogliere da solo, per quanto competente: strutture rigide, processi lenti, incentivi individuali, una leadership che non capisce — o non sostiene — il cambiamento. Non sono eccezioni: sono il paesaggio normale in cui la maggior parte dei team agili opera.

Il lavoro dell’Agile Team Coach qui si articola su due piani. Il primo è riconoscere e catturare: usare SCARF per leggere le reazioni emotive come minacce percepite (status, certezza, autonomia, relazione, equità) e non come cattiva volontà; rendere gli impedimenti visibili su una impediment board; categorizzarli per livello di risoluzione; raccogliere dati che trasformino una lamentela in un business case; distinguere ciò che è risolvibile da ciò che va solo mitigato. Il secondo piano è saper coinvolgere la leadership quando serve — distinguendo impedimenti di team (risolvibili dall’interno) da impedimenti organizzativi (che richiedono autorità e risorse fuori dal perimetro del team), riconoscendo i segnali che chiedono escalation, e portando la richiesta con dati, proposte di direzione, tono collaborativo e follow-up — mantenendo l’ownership nel team, non nel coach.

Prima dell’incontro: leggo i paragrafi 6.5.1 e 6.5.2 — identificazione e cattura degli impedimenti (SCARF, impediment board, strategie di mitigazione) e il coinvolgimento della leadership (le quattro domande diagnostiche, i segnali di escalation, come formulare la richiesta).

In aula: ogni partecipante porta un impedimento reale del proprio team. Applichiamo le quattro domande diagnostiche per classificarlo (team vs organizzativo), poi — se organizzativo — costruiamo insieme in piccoli gruppi una richiesta di escalation: dati, impatto quantificato, proposta di direzione, canale e momento giusti.

Trappola ricorrente: il coach che si trasforma in postino, portando lamentele alla leadership al posto del team — invece di aiutare il team a formulare e presentare la richiesta in prima persona.

Domanda-manifesto: Questo ostacolo è davvero fuori dal perimetro del team, o stiamo evitando di provare a risolverlo dall’interno?

Dopo l’incontro: scelgo un impedimento ricorrente in un team che accompagno, lo classifico con le quattro domande diagnostiche e, se organizzativo, preparo — insieme al team, non al posto suo — i dati per una possibile escalation.

Fin qui abbiamo lavorato dentro le posture del coach — cosa fare quando sei nella stanza con il team. Questo incontro chiede una domanda diversa, che viene prima di tutte le altre: da dove comincio, e a quali condizioni? Definire i confini non è burocrazia né un atto difensivo — è chiarezza. Senza di essa, rischi di diventare tutto per tutti: facilitatore, project manager ombra, psicologo del team, capro espiatorio quando le cose non vanno. E quando sei tutto, non sei niente.

Due strumenti distinti lavorano insieme. Il coaching contract è la cornice: cosa farai e cosa non farai, obiettivi (performance, non outcome — il team controlla la performance, non il KPI di business), informazioni che cercherai, ruolo tuo e altrui, consegne, cosa ti serve da loro, tempi, confidenzialità, feedback reciproco. La coaching alliance è il quadro vivo dentro quella cornice: la conversazione bidirezionale — con il team, non solo con l’individuo — su come volete essere accompagnati, come preferite ricevere feedback, quali segnali indicano che sto sfidando troppo o troppo poco. Non si firma una volta: si rinegozia dopo le prime sessioni, a metà percorso, quando qualcosa non funziona, quando il contesto cambia.

A questo si aggiunge una distinzione strutturale che cambia tutto: essere coach interno o esterno non è un dettaglio logistico. L’interno ha accesso e continuità, ma deve esplicitare limiti di neutralità, confidenzialità e capacità di sfidare lo status quo. L’esterno ha neutralità e libertà di sfida, ma deve negoziare l’ingresso, rispettare il ritmo del sistema, e lavorare per la propria obsolescenza. In entrambi i casi, il principio è lo stesso: dire ad alta voce chi sei, cosa puoi fare, cosa no.

Prima dell’incontro: leggo i paragrafi 7.1.1, 7.1.2 e 7.1.3 — il coaching contract, la progettazione dell’alleanza (con l’individuo e con il team), le differenze tra coach interno ed esterno.

In aula: ogni partecipante scrive in dieci minuti il proprio coaching contract per un team reale (3 righe: cosa farò, cosa non farò, cosa mi serve da loro). Poi, in coppia, si prova la conversazione di alleanza usando due o tre domande chiave — “come vuoi essere accompagnato”, “quali segnali ti dicono che sto sfidando troppo” — e si dà feedback su quanto suonava paritario e concreto.

Trappola ricorrente: saltare il contratto e l’alleanza perché “sembrano poco Agile”, per poi ritrovarsi dopo poche settimane a interpretare ruoli mai negoziati — project manager ombra, mediatore, capro espiatorio.

Domanda-manifesto: Ho reso esplicito cosa farò, cosa non farò, e cosa mi serve da loro — o sto lavorando su un’aspettativa che nessuno ha mai dichiarato?

Dopo l’incontro: scelgo un team che accompagno (o inizierò ad accompagnare) e scrivo il coaching contract, distinguendo obiettivo di performance da KPI di contesto.