Blog

Responsabilità condivisa e accountability nei team Agile

In quasi ogni discussione sulla trasformazione Agile emerge, prima o poi, una domanda ricorrente: “Se tutti sono responsabili, chi è responsabile quando qualcosa va storto?”

Si tratta di un interrogativo frequente nei board meeting, negli steering committee e nei workshop con manager abituati a gestire decisioni rilevanti e a rispondere direttamente al top management. La preoccupazione sottostante è chiara:

come garantire controllo, governance e accountability in un contesto che promuove responsabilità distribuite?

Questa domanda riflette la coesistenza di due approcci differenti:

• un modello gerarchico tradizionale, fondato su catena di comando e responsabilità individuali;
• un modello Agile, basato su team cross-functional, decisioni condivise e apprendimento continuo.

Per comprendere perché questa tensione sia oggi così evidente, è utile partire dai dati: nonostante l’evoluzione dei framework di project management e la diffusione dell’Agile, i tassi di insuccesso dei progetti IT restano elevati e la pressione sui leader per dimostrare controllo, mitigare i rischi e garantire ritorno sugli investimenti è in costante aumento.

Il contesto: perché oggi la responsabilità pesa di più

Negli ultimi trent’anni, nonostante framework di project management sempre più sofisticati, il tasso di fallimento dei progetti IT è rimasto sorprendentemente alto. I dati più recenti riconducibili al CHAOS Report mostrano che solo circa il 31% dei progetti può essere considerato un successo pieno (in tempo, in budget, con lo scope previsto), mentre circa il 50% è “challenged” (ritardi, extra costi, funzionalità ridotte) e quasi un progetto su cinque viene cancellato.

Altre letture dei dati Standish sottolineano che, a seconda di come si definisce “fallimento” e “successo parziale”, fino al 60–66% dei progetti tecnologici termina in risultati insoddisfacenti o falliti.

Se allarghiamo lo sguardo alle iniziative di trasformazione digitale, il quadro non migliora: diverse analisi stimano che circa il 70% delle trasformazioni non raggiunge gli obiettivi prefissati, nonostante investimenti di miliardi.

Parallelamente, Agile è diventato lo standard de facto nello sviluppo software. Gli ultimi State of Agile Report indicano che circa il 70% delle funzioni IT e dei team di sviluppo utilizza approcci Agile, e che in molti contesti l’adozione ha superato l’80% all’interno dei team di engineering e R&D.

Eppure, nonostante questa diffusione, le organizzazioni faticano ancora a tradurre l’Agile in miglioramenti sistematici di risultato. Lo stesso 17th State of Agile Report evidenzia come una delle barriere più ricorrenti sia proprio la mancanza di partecipazione e sponsorship della leadership: il 41% degli intervistati cita l’insufficiente coinvolgimento dei leader come ostacolo critico all’adozione.

Se incrociamo questi dati, emerge un quadro chiaro:

• i progetti continuano a fallire o a faticare;
• l’Agile si è diffuso, ma spesso in modo superficiale o “di facciata”;
• i leader sono sotto pressione crescente per giustificare ROI, ridurre i rischi e dimostrare controllo.

In questo contesto, la domanda “chi paga quando qualcosa va storto?” non è solo una curiosità teorica. È una preoccupazione legata a metriche concrete, audit, responsabilità verso azionisti e regulator.

Dal “chi ha sbagliato?” al “cosa nel sistema non ha funzionato?”

Nel modello tradizionale, responsabilità e colpa sono quasi sinonimi. Quando un progetto non rispetta budget o scadenze, la prima reazione tipica è cercare chi “non ha fatto il suo dovere”: il project manager che non ha controllato, lo sviluppatore che ha introdotto il bug, il fornitore che ha consegnato in ritardo.

Questa logica funziona discretamente in sistemi semplici, dove le relazioni causa-effetto sono lineari. Ma fallisce nei sistemi complessi, come un ecosistema digitale moderno, dove:

• esistono molteplici dipendenze tecniche e organizzative,
• le informazioni sono frammentate,
• le decisioni sono distribuite nel tempo e nello spazio,
• l’incertezza sul contesto (mercato, tecnologia, regolazione) è elevata.

La ricerca sui fallimenti dei progetti IT mostra che le cause non sono quasi mai riconducibili a un singolo individuo, ma a combinazioni di fattori: requisiti poco chiari, sponsor poco coinvolti, comunicazione carente, cambi di priorità, governance ambigua.

Continuare a ragionare in termini di “colpevole” in questo scenario produce due effetti collaterali molto concreti:

1. Le persone sviluppano una mentalità difensiva. Diventano più attente a proteggersi che a collaborare, si concentrano sul “non farsi trovare esposte” piuttosto che sul migliorare il sistema.
2. L’organizzazione smette di imparare. Se ogni incidente si chiude con la punizione di qualcuno, la vera causa sistemica resta nascosta, pronta a ripresentarsi al prossimo ciclo.

Le ricerche sulla sicurezza psicologica e sulle performance dei team vanno esattamente in questa direzione. Il famoso Project Aristotle di Google, che ha analizzato oltre 180 team interni, ha concluso che il fattore più correlato alle prestazioni elevate non era la somma dei talenti individuali, ma il livello di sicurezza psicologica percepita: la possibilità di prendere rischi interpersonali senza temere umiliazione o punizioni.

In altre parole, se la risposta sistematica a un problema è “chi puniamo?”, l’organizzazione si condanna a una produttività mediocre e a un continuo riemergere degli stessi errori.

Cosa intendiamo davvero per “responsabilità condivisa”

Quando parliamo di responsabilità condivisa nei team Agile, non stiamo dicendo che “nessuno è responsabile”. Stiamo dicendo che il risultato – positivo o negativo – è il prodotto di un sistema, non di un singolo eroe o di un singolo colpevole.

Immaginiamo una squadra di calcio. Ogni giocatore ha un ruolo chiaro: il portiere difende la porta, i difensori coprono le linee, i centrocampisti costruiscono il gioco, gli attaccanti finalizzano. Se la squadra perde, nessun allenatore serio si limita a dire “abbiamo perso perché il terzino ha sbagliato un intervento”. Quel singolo errore è visibile, ma dietro ci sono scelte di assetto tattico, tempi di pressione, sincronia tra reparti, livello di preparazione fisica.

Allo stesso modo, in un team Agile che sviluppa un prodotto digitale, esistono ruoli distinti come sviluppatori, tester, product owner, UX designer, tech lead, ma il valore consegnato al cliente è il risultato di come questi ruoli interagiscono, decidono, si coordinano nel tempo.

La responsabilità condivisa significa, in concreto, che:

• ogni membro del team sente di avere un pezzo di responsabilità per il risultato complessivo, non solo per il “suo pezzo di codice” o il “suo documento”;
• gli errori vengono analizzati in chiave sistemica, chiedendosi “come abbiamo lavorato come team” più che “chi ha commesso l’errore visibile”;
• le pratiche di collaborazione (refinement, planning, review, retrospettive) sono luoghi in cui la responsabilità si costruisce, non solo rituali da spuntare.

Le ricerche sul lavoro in team confermano che quando le persone percepiscono un forte senso di interdipendenza e appartenenza a un obiettivo comune, aumentano sia l’impegno sia la qualità delle decisioni.

Questo non significa però che tutti facciano tutto, o che i ruoli si dissolvano in una indistinta orizzontalità. Al contrario, la responsabilità condivisa funziona bene solo se i ruoli specifici e i confini decisionali sono chiari. Ed è qui che entra in gioco il secondo concetto chiave: l’accountability.

Responsibility vs accountability: la distinzione che cambia i comportamenti

In inglese, la distinzione è lessicale: responsibility e accountability. In italiano, usiamo praticamente sempre “responsabilità”, e questo genera molti equivoci.

Possiamo sintetizzare così:

• responsibility, in chiave Agile, è l’impegno operativo, quotidiano, di chi contribuisce al lavoro e al risultato;
• accountability è l’ownership formale di un esito, di un perimetro, di un insieme di decisioni.

Nei team Agile la responsabilità è, per definizione, condivisa. Tutti sono chiamati a contribuire alla qualità del prodotto, al rispetto delle pratiche, alla collaborazione con gli stakeholder. Nessuno può dire “non è un mio problema” quando emerge un rischio rilevante per il valore consegnato.

L’accountability, invece, è specifica. Per ogni ambito critico deve essere chiaro chi è la persona o il ruolo che “tiene il timone”. Non si tratta di una figura che decide tutto da sola, ma di chi ha il mandato di:

• prendere decisioni quando ci sono trade-off difficili,
• assumere un impegno verso l’esterno (stakeholder, clienti, management),
• orchestrare il contributo del team affinché un certo esito venga perseguito con coerenza.

I dati sulle trasformazioni Agile di larga scala aiutano a visualizzare l’impatto di questa distinzione. Analisi McKinsey mostrano che le organizzazioni che riescono a condurre trasformazioni Agile di successo sono circa tre volte più propense a posizionarsi nel quartile superiore di performance rispetto ai concorrenti. In questi casi, una caratteristica ricorrente è la presenza di ruoli di accountability chiari, sia a livello di team sia di leadership.

Altre ricerche indicano che le trasformazioni Agile ben impostate generano guadagni nell’ordine del 20–30% su efficienza, soddisfazione del cliente, engagement delle persone e performance operative. Questi risultati non derivano da un generico “siamo tutti responsabili”, ma da un disegno attento di responsabilità condivise e accountability esplicite.

Pensiamo a un team prodotto. Tutti sono responsabili della qualità del software. Ma il Product Owner (o Product Manager) è accountable per massimizzare il valore del prodotto su un certo segmento: è lui o lei che decide le priorità di backlog, che dialoga con il business, che accetta esplicitamente trade-off fra scope, tempi e debito tecnico. Analogamente, il Tech Lead può essere accountable per la coerenza architetturale su una parte del sistema, per le decisioni tecniche che avranno impatti di lungo periodo. Questa accountability non cancella la responsabilità degli altri membri del team, ma fornisce un punto di riferimento chiaro quando insorgono conflitti o incidenti.

Disegnare accountability chiare senza tornare al comando-controllo

Una obiezione frequente è: “se definiamo troppo rigidamente chi è accountable per cosa, non rischiamo di tornare a un modello gerarchico tradizionale, con il capo che decide e gli altri che eseguono?”

La risposta dipende dal modo in cui costruiamo l’accountability. Le ricerche sulle trasformazioni Agile mostrano un pattern ricorrente: le iniziative che falliscono sono spesso quelle in cui l’Agile viene introdotto come un insieme di cerimonie e tool, ma la governance resta opaca. Gli stessi studi evidenziano che una delle cause di insuccesso più citate è proprio la mancanza di allineamento del top team e la difficoltà a chiarire “come” debba funzionare il nuovo operating model.

Disegnare una buona accountability significa lavorare su tre piani.

Il primo è quello della chiarezza dei ruoli. Non si tratta di scrivere job description infinite, ma di esplicitare, per ogni ruolo chiave, quali decisioni rientrano nel suo mandato e quali no. Questo vale tanto per i ruoli “classici” dell’Agile (Product Owner, Scrum Master, ecc.) quanto per i ruoli manageriali in interfaccia con i team.

Il secondo è quello dell’end-to-end. L’accountability efficace evita di spezzare la proprietà lungo la catena del valore. Se un team prodotto è responsabile di una certa esperienza utente o di un certo servizio digitale, il suo mandato dovrebbe coprire l’intero ciclo: dall’idea al rilascio, dal rilascio alla misurazione, dalla misurazione alle iterazioni successive. Dove l’accountability si ferma a “consegniamo il codice in produzione e poi è problema di un altro dipartimento”, il rischio di rimbalzi e scarichi di responsabilità rimane altissimo.

Il terzo è quello dei mezzi. Non si può chiedere accountability senza fornire leve reali. Le analisi sulle trasformazioni di successo mostrano che le organizzazioni che ottengono risultati duraturi investono nel dare ai team autonomia reale, accesso ai dati, capacità di prendere decisioni rapide su budget e priorità entro confini chiari.

L’accountability, in questo senso, è l’opposto del capro espiatorio. Non è un nome da scrivere sulla lavagna quando qualcosa va male, ma un ruolo che ha mandato, risorse e supporto per guidare un pezzo del sistema verso risultati migliori.

Leadership, sicurezza psicologica e cultura del “dopo l’errore”

Arriviamo al punto che, spesso, fa davvero la differenza: cosa succede dopo un errore.

Le evidenze empiriche sono chiare. I contesti Agile che generano benefici misurabili nel tempo sono quelli in cui gli errori vengono:

• discussi apertamente,
• analizzati con approccio sistemico,
• trasformati in opportunità di miglioramento continuo, anziché in occasioni di punizione.

Il Project Aristotle di Google, già citato, è emblematico: i team con maggiore performance erano quelli in cui le persone si sentivano sicure di ammettere un errore, fare una domanda “banale”, proporre una idea non convenzionale. La sicurezza psicologica non è un lusso soft, ma una leva diretta di prestazione.

Qui il ruolo della leadership è cruciale. Sono i leader – a tutti i livelli – a definire il tono con cui si affrontano gli incidenti. Due riunioni di post-mortem sullo stesso tipo di problema possono avere effetti opposti a seconda di come sono condotte.

In un’impostazione tradizionale, il debrief può diventare una caccia formale al responsabile, con domande implicite come “chi avrebbe potuto evitare questo errore?”. In un’impostazione Agile matura, lo stesso debrief si trasforma in una retrospettiva estesa, dove si indagano:

• decisioni prese troppo in alto senza contesto sufficiente,
• dipendenze non gestite tra team,
• limiti strutturali degli strumenti,
• metriche di successo mal definite.

La differenza non è retorica: influisce sul modo in cui le persone percepiscono la propria possibilità di influenza. Se ogni errore può costare reputazione o carriera, l’incentivo naturale è quello a “non toccare nulla”, riducendo sperimentazione e innovazione. Se invece l’errore è riconosciuto come parte inevitabile dell’esplorazione in contesti complessi, l’organizzazione si dà il permesso di imparare.

Le analisi sui benefici delle trasformazioni Agile indicano, non a caso, miglioramenti significativi non solo in termini di time-to-market, ma anche di engagement delle persone: alcune ricerche riportano incrementi di 20–30 punti nelle metriche di engagement rispetto a contesti non Agile.

Questo aumento di engagement non è un effetto magico di Scrum o Kanban. È la conseguenza di un contesto in cui le persone sentono di avere un ruolo reale nel decidere, di poter contribuire al disegno delle soluzioni, di essere giudicate su risultati condivisi e non su errori isolati.

Rispondere alla domanda iniziale

Possiamo ora tornare alla domanda da cui siamo partiti: “Se tutti sono responsabili, chi è responsabile quando qualcosa va storto?”

In un’organizzazione Agile matura, la risposta completa ha più livelli.

• Il primo livello è quello sistemico.

Quando un progetto va storto, la responsabilità ultima è del sistema organizzativo: scelte di modello operativo, governance, cultura della decisione, modalità di allocazione delle risorse. I dati sulle trasformazioni fallite mostrano chiaramente che, nella maggior parte dei casi, non sono i team a “non essere abbastanza Agile”, ma la struttura complessiva a non supportare davvero l’agilità dichiarata

• Il secondo livello è quello dei team.

I team sono responsabili del modo in cui collaborano, decidono, comunicano. La responsabilità è condivisa nel senso che ciascun membro è chiamato a prendersi cura non solo del proprio task, ma del flusso complessivo di valore. Quando qualcosa va storto, il team ha il dovere di analizzare cosa avrebbe potuto fare diversamente, quali segnali ha ignorato, quali dipendenze non ha reso visibili per tempo.

• Il terzo livello è quello dell’accountability.

In ogni situazione critica, deve essere chiaro:

• chi è accountable per il perimetro di business o di prodotto impattato;
• chi ha il mandato di prendere decisioni tempestive (ad esempio, rollback, comunicazione al cliente, riprioritizzazione del backlog);
• chi deve farsi carico di rappresentare l’esito verso l’esterno, assumendosi la responsabilità delle decisioni prese.

Questa accountability non esclude la responsabilità degli altri, ma offre un punto di ancoraggio concreto al bisogno, molto reale, di governance che i manager avvertono.

Se vogliamo una formula sintetica, potremmo dire così:

1. la responsabilità è diffusa, quotidiana, condivisa;
2. l’accountability è assegnata, esplicita, legata a ruoli e perimetri;
3. la colpa è un concetto che, nei sistemi complessi e nei contesti Agile, ha sempre meno utilità operativa.

I dati ci dicono che le organizzazioni che riescono a fare davvero questo salto – dal dito puntato alla collaborazione, dalla colpa alla causa, dalla gerarchia rigida alla combinazione di responsabilità condivisa e accountability chiara – sono anche quelle che, nel medio periodo, migliorano performance, velocità e capacità di adattamento in modo misurabile.

La vera sfida per i leader, oggi, non è scegliere tra controllo e Agile, ma ripensare il modo in cui “stare nella responsabilità”: non più come garanti solitari di un risultato lineare, ma come architetti di sistemi in cui i team possano prendersi cura del lavoro insieme, sapendo che esistono ruoli chiari di accountability a sostegno, non a giudizio.

Fonti citate

Appelo, J. (2011). Management 3.0: Leading Agile Developers, Developing Agile Leaders. Addison-Wesley.

Denning, S. (2018). The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done. AMACOM.

Dikert, K., Paasivaara, M., & Lassenius, C. (2016). Challenges and success factors for large-scale agile transformations: A systematic literature review. Journal of Systems and Software, 119, 87–108.

Google Re:Work. (2015). Project Aristotle: Understanding Team Effectiveness. Google.

Hayward, S. (2018). The Agile Leader: How to Create an Agile Business in the Digital Age. Kogan Page.

Koning, P. (2020). Agile Leadership Toolkit: Learning to Thrive with Self-Managing Teams. Addison-Wesley.

Laloux, F. (2014). Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage of Human Consciousness. Nelson Parker.

Mainetti, S. (2024). Dal comando alla connessione: Il ruolo della vulnerabilità nella leadership. B&A Consulting.

Moe, N. B., Dingsøyr, T., & Dybå, T. (2010). A teamwork model for understanding an agile team: A case study of a Scrum project. Information and Software Technology, 52(5), 480–491.

Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016). Embracing agile. Harvard Business Review, 94(5), 40–50.

Schwaber, K., & Sutherland, J. (2020). The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game. Scrum.org.

Solga, M. (2021). The “Align–Empower” Model of Agile Leadership. cidpartners GmbH.

Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard Business Review, 64(1), 137–146.

Autore: Martina Pegoraro