L'Agile ti sembra frustrante? Forse perché il tuo team non è un team

Contenuto articolo

Lo standup dura dodici minuti. Cinque persone, ognuna recita il suo aggiornamento guardando un punto imprecisato dello schermo. Nessuno commenta quello che dicono gli altri, perché non c’è motivo: ognuno lavora sulla propria feature, in un angolo diverso del codebase. Finisce lo standup, tutti tornano a fare esattamente quello che avrebbero fatto senza. Poi c’è la retro. Ne escono tre post-it con “migliorare la comunicazione”, gli stessi del mese scorso. E lo sprint planning, che in pratica è un’assegnazione di task individuali con un timer di due settimane.

Se ti riconosci, non sei solo. Il 17th State of Agile Report di Digital.ai (2024) riporta che solo l’11% dei praticanti si dichiara “molto soddisfatto” delle pratiche Agile nella propria organizzazione. La frustrazione è così diffusa che due firmatari del Manifesto Agile originale hanno preso posizioni pubbliche contro ciò che Agile è diventato: Ron Jeffries, co-creatore di Extreme Programming, ha scritto che gli sviluppatori dovrebbero abbandonare Agile, o almeno la versione che le organizzazioni ne hanno fatto. Dave Thomas, un altro firmatario, ha dichiarato che Agile è morto, svuotato di significato dal marketing e dalla certificazione di massa.

La diagnosi più comune è che Agile sia diventato burocrazia: troppi rituali, troppo processo, troppo poco codice. Ha senso. Chi non l’ha pensato almeno una volta, uscendo dall’ennesimo planning infinito?

Ma c’è un’altra possibilità. Una che non ha a che fare con Agile in sé, ma con qualcosa di più basilare: la struttura su cui lo stai applicando.

J. Richard Hackman ha passato 40 anni a studiare team reali: equipaggi di volo, orchestre, team di intelligence, squadre chirurgiche. La sua ricerca, condensata in Leading Teams (2002) e Collaborative Intelligence (2011), arriva a una distinzione che nel mondo software quasi nessuno fa: quella tra un team e un gruppo di lavoro. Sono cose diverse. Funzionano in modi diversi. E richiedono strumenti diversi.

Le pratiche Agile sono progettate per team. Se le applichi a un gruppo di lavoro, il risultato è esattamente la frustrazione che stai provando. Il problema non è il metodo. È un mismatch strutturale.

La parola più abusata nel software

Nel mondo del software “team” è la parola predefinita per qualsiasi gruppo di persone che lavora nello stesso progetto. Cinque sviluppatori che condividono una board Jira? Team. Due backend, un frontend e un designer che riportano allo stesso manager? Team. Otto persone sparse su tre fusi orari che si vedono allo standup delle 9? Team.

Hackman non sarebbe d’accordo. In Leading Teams definisce un “real team” attraverso tre proprietà minime, tutte necessarie.

La prima è avere confini chiari: tutti sanno chi fa parte del team e chi no. Sembra banale, ma nella pratica software non lo è. Il designer “condiviso” tra tre team è dentro o fuori? Lo sviluppatore “in prestito” per due sprint, è un membro? Se non riesci a fare una lista senza esitare, i confini non sono chiari.

La seconda è una composizione stabile. Le persone restano le stesse abbastanza a lungo da sviluppare modi di lavorare condivisi. Hackman studiava equipaggi di volo: i dati della NASA, che lui riporta in Leading Teams, mostravano che gli equipaggi appena formati commettevano più errori di quelli che volavano insieme da tempo, anche con piloti meno esperti. Nel software, la rotazione trimestrale delle persone tra team distrugge questo effetto. Ogni volta si ricomincia da zero.

La terza, e la più sottovalutata, è l’interdipendenza reale. Il risultato del team dipende dalla collaborazione tra i membri, non è la somma di contributi individuali. Questo è il punto dove la maggior parte dei “team” software crolla. Cinque sviluppatori che lavorano su cinque feature indipendenti, con cinque code review incrociate per formalità, non sono interdipendenti. Il lavoro di uno non cambia il lavoro dell’altro. Se togliessi tutte le riunioni e li mettessi in stanze separate, il risultato sarebbe lo stesso.

Il test è brutale nella sua semplicità: se domani eliminassi standup, retro e planning, e ognuno lavorasse per conto suo, il prodotto finale peggiorerebbe? Se la risposta è no, se il risultato sarebbe identico, magari persino più veloce senza le interruzioni, allora quello che hai non è un team. È un gruppo di individui con un manager in comune.

Non è un insulto. È una diagnosi. E la diagnosi è il primo passo per smettere di applicare gli strumenti sbagliati.

Le condizioni strutturali: il 60/30/10

Hackman non si è fermato alla definizione. Ha studiato cosa rende un team efficace, e la risposta è meno intuitiva di quanto sembri.

La ricerca di Hackman e della sua collaboratrice Ruth Wageman identifica cinque condizioni che abilitano la performance di un team: essere un team reale, avere una direzione convincente, una struttura abilitante, un contesto organizzativo di supporto e un coaching competente. Non le approfondisco tutte qui, ognuna meriterebbe un articolo a sé. Il punto rilevante è un altro: quanto contano queste condizioni rispetto a quello che un leader fa giorno per giorno?

La risposta di Hackman, formulata in Collaborative Intelligence (2011), è il 60/30/10: il 60% dell’efficacia di un team dipende dal design, le condizioni strutturali messe in piedi prima che il team cominci a lavorare. Il 30% dipende dal lancio: come il team viene avviato, i primi giorni, le norme iniziali. Il restante 10% dal coaching in corso d’opera.

Una precisazione: Hackman presenta questa ripartizione come una “best estimate”, non come il risultato di un singolo studio con quelle percentuali esatte. È un’euristica che sintetizza decenni di ricerca. Non un dato puntuale.

Ma l’ordine di grandezza ha un ancoraggio empirico solido. Il Team Diagnostic Survey (TDS), sviluppato da Wageman, Hackman e Lehman e pubblicato nel 2005, è stato somministrato a 2.474 persone in 321 team. Il risultato: le condizioni strutturali spiegano fino all’80% della varianza nell’efficacia dei team (Wageman, Hackman & Lehman, 2005). Non il 20%, non il 50%. L’80%.

Uno studio precedente di Wageman (2001) su 43 team autogestiti a Xerox aveva già mostrato lo stesso pattern: le attività di design del leader influenzavano la performance del team. Le attività di coaching quotidiano, no.

L’implicazione per chi lavora nel software è diretta. Quando un team non funziona, la reazione istintiva è lavorare sulle dinamiche: facilitare meglio le retro, migliorare la comunicazione, fare team building. Il framework di Hackman suggerisce che la leva più potente è a monte. Chi fa parte del team? Qual è il mandato? Come è disegnato il lavoro? Il contesto organizzativo lo supporta? Se queste condizioni non ci sono, nessuna quantità di facilitazione compenserà.

Ma la prima di quelle cinque condizioni, “essere un team reale”, apre una domanda che nel software quasi nessuno si pone.

Team o gruppo di lavoro: la distinzione che cambia tutto

Va chiarito un punto che Hackman ripete spesso e che viene frainteso altrettanto spesso: la distinzione tra team e gruppo di lavoro non è un giudizio di valore. Non è “team = bene, gruppo di lavoro = male”. Sono due modalità organizzative diverse, ognuna con i suoi vantaggi.

Un gruppo di lavoro è un insieme di persone che riportano allo stesso manager e possono coordinarsi, ma il cui output è principalmente individuale. Ognuno ha i suoi obiettivi, le sue responsabilità, i suoi deliverable. Il manager coordina, assegna, rimuove ostacoli. Non c’è bisogno di interdipendenza profonda.

Un team produce un output collettivo. Il risultato non è scomponibile nella somma dei contributi individuali: richiede collaborazione continua, decisioni condivise, aggiustamento reciproco. Il costo è più alto, servono confini stabili, norme condivise, tempo per sviluppare modi di lavorare insieme. Ma per certi tipi di problemi, è l’unica configurazione che funziona.

Il danno nasce quando confondi le due cose.

Un gruppo di lavoro gestito come team genera overhead senza beneficio. Le riunioni di coordinamento esistono, ma non c’è nulla di sostanziale da coordinare. Le retrospettive non producono azioni perché non c’è un processo condiviso da migliorare: ognuno ha il suo flusso, le sue priorità, i suoi blocchi. Il cerimoniale Agile diventa un costo fisso su un’attività che non lo richiede.

Il danno, però, è bidirezionale. Un team reale gestito come un gruppo di lavoro è altrettanto disfunzionale. Se hai persone che devono collaborare su un problema complesso e le tratti come contributori individuali, assegnando task separati, valutandoli singolarmente, senza proteggere il tempo per il lavoro congiunto, stai sabotando l’unica cosa che rende quel team efficace: l’interdipendenza.

Ho visto entrambi gli scenari. Il primo è più comune nel software, perché l’organizzazione predefinita tende ad essere il gruppo di lavoro (sviluppatori assegnati a feature individuali), ma l’infrastruttura di processo è quasi sempre quella del team (Scrum, Kanban con standup, retro, planning).

La domanda operativa non è “come migliorare il mio team?”. È più basilare: quello che guido, è un team o un gruppo di lavoro? La risposta cambia tutto ciò che viene dopo.

Il mismatch Agile: strumenti giusti, struttura sbagliata

Torniamo alla frustrazione di partenza. Le pratiche Agile, Scrum in particolare, non sono nate nel vuoto. Sono progettate attorno a un’assunzione precisa: che un piccolo gruppo di persone lavori in modo interdipendente su un obiettivo condiviso, iterando insieme. Lo sprint presuppone un goal comune. Lo standup presuppone che sapere cosa fanno gli altri cambi il tuo lavoro. La retro presuppone un processo condiviso da ispezionare. Il planning presuppone decisioni collettive sulla priorità.

Sono tutti strumenti che presuppongono interdipendenza. Senza, perdono senso.

Ora guarda la configurazione tipica di un “team” di sviluppo in molte organizzazioni. Le persone vengono assegnate, spesso ruotate, a un “team” che è in realtà un contenitore organizzativo. Ognuno lavora sulla propria user story, con interazioni limitate al code review e a qualche domanda su Slack. Il “goal dello sprint” è la somma delle story individuali. L’interdipendenza è minima o assente.

Se applichi strumenti da team a questa struttura, il risultato è prevedibile. Lo standup diventa un giro di aggiornamenti che nessuno ascolta. La retro produce lamenti generici. Il planning diventa burocrazia. Non perché Scrum sia burocrazia, ma perché lo stai usando su una struttura per cui non è progettato.

I firmatari del Manifesto lo dicono, anche se con parole diverse. Jeffries parla di “Dark Scrum”, organizzazioni che usano i rituali Agile come strumenti di controllo, svuotandoli di collaborazione. Thomas dice che “Agile” è stato trasformato in un sostantivo commerciale, quando era pensato come un aggettivo che descrive un modo di lavorare. La loro critica è legittima. Ma la diagnosi che propongono, “le organizzazioni hanno corrotto Agile”, è incompleta. Il framework di Hackman ne offre una più strutturale: molte organizzazioni non hanno corrotto Agile. Lo hanno applicato a strutture che non sono team.

Ne parlo perché l’ho visto accadere più volte di quante vorrei ammettere, anche in contesti con persone competenti e buone intenzioni. La risposta standard al malessere era sempre la stessa: cambiamo facilitatore, proviamo un altro formato di retro, aggiungiamo una cerimonia. Il framework di Hackman mi ha dato un vocabolario per dire quello che sentivo ma non riuscivo a formulare: il problema non era l’esecuzione. Era la premessa.

Questo cambia la diagnosi e le soluzioni. Se il problema è “Agile è diventato burocrazia”, la risposta è meno processo, meno rituali, più autonomia. A volte è giusto. Ma se il problema è un mismatch strutturale, la risposta è diversa: o trasformi la struttura in un team reale, con i costi che questo comporta, o accetti che hai un gruppo di lavoro e adotti strumenti coerenti con quella realtà. Entrambe le opzioni sono legittime. Quello che non funziona è restare nel mezzo.

Riprendiamo lo standup di dodici minuti da cui siamo partiti. Cinque persone, cinque aggiornamenti, nessuna interazione. La diagnosi ovvia è che lo standup sia mal facilitato, o che Scrum non funzioni, o che il team abbia bisogno di “lavorare sulla comunicazione”. Sono tutte risposte che agiscono sul sintomo.

La domanda di Hackman è diversa, e viene prima: quelle cinque persone hanno bisogno di parlarsi ogni mattina per fare il loro lavoro? Se il lavoro di ciascuno non dipende dagli altri, lo standup non è mal facilitato. È inutile per design. E la retro non produce azioni perché non c’è un processo condiviso da migliorare. E il planning è burocrazia perché non ci sono decisioni collettive da prendere.

Non è una questione di esecuzione. È una questione di struttura.

La prossima volta che pensi “Agile non funziona”, prova a riformulare. Non chiederti come migliorare il processo. Chiediti se quello che guidi è un team o un gruppo di lavoro. La risposta non è un giudizio. È una diagnosi. E dalla diagnosi dipende tutto il resto.

Fonti

• Hackman, J.R. (2002). Leading Teams: Setting the Stage for Great Performances. Harvard Business School Press.
• Hackman, J.R. (2011). Collaborative Intelligence: Using Teams to Solve Hard Problems. Berrett-Koehler.
• Wageman, R. (2001). How Leaders Foster Self-Managing Team Effectiveness: Design Choices Versus Hands-on Coaching. Organization Science, 12(5), 559-577.
• Wageman, R., Hackman, J.R. & Lehman, E.V. (2005). Team Diagnostic Survey: Development of an Instrument. Journal of Applied Behavioral Science, 41(4), 373-398.
• Digital.ai (2024). 17th State of Agile Report.
• Jeffries, R. (2018). Developers Should Abandon Agile.
• Thomas, D. (2014). Agile is Dead (Long Live Agility).