Tag: Agile transformation

Ieri mattina, durante una colazione con l’amministratore delegato di una delle principali istituzioni medicali in Italia, siamo finiti a parlare di organizzazione, modelli operativi e trasformazione. A un certo punto, ha tirato fuori un report sull’Agile che gli era stato condiviso da un consulente.

“Ma oggi ha ancora senso parlare di Scrum ed Agile oggi, ed in che modo?” mi ha chiesto.

Una domanda legittima. In fondo, anche io negli anni ho insegnato, implementato e osservato da vicino modelli agili in aziende di ogni dimensione e settore. Ma sempre con un principio chiaro: non esiste un modello unico che funzioni ovunque. L’agilità non si ottiene copiando un framework, ma comprendendo i principi e adattandoli al proprio contesto organizzativo, culturale e operativo.

E proprio negli ultimi anni sono emersi, con una certa costanza, segnali di disillusione verso Scrum e i ruoli ad esso associati. Pur rimanendo il framework Agile più diffuso (usato da circa il 63% dei team secondo il State of Agile Report 2024), la soddisfazione delle organizzazioni nei confronti di Agile/Scrum è in calo. Un sondaggio ha rilevato che la percentuale di aziende “molto o abbastanza soddisfatte” delle pratiche Agile è crollata dal 71% nel 2022 al 59% nel 2023.

Questa diminuzione indica che molte imprese adottano Scrum ma faticano a vederne i benefici attesi. Di conseguenza, si moltiplicano le discussioni sul “declino di Agile” e su cosa fare “dopo Scrum”.

Parallelamente, i ruoli tipici di Scrum (come Scrum Master e Agile Coach) sono messi in discussione. Nel 2023 molte big tech hanno ridotto o eliminato questi ruoli, inizialmente per motivi di taglio costi ma anche per dubbi sul loro valore aggiunto. Nei primi sei mesi del 2023 oltre 120.000 tech workers sono stati licenziati e «indovinate quali ruoli sono stati i più colpiti? Esatto: Scrum Master e Agile Coach». Numerose aziende hanno deciso di fare a meno di figure dedicate al processo, segno di un ripensamento profondo: stanno valutando se questi ruoli apportino davvero valore. Questo fenomeno è stato definito provocatoriamente “The Great Scrum Master Exodus”.

Un altro dato emblematico è l’adozione forzata di Scrum fuori dal suo contesto ideale. Spesso Scrum ha preso piede soprattutto in imprese tradizionali o consulenziali, mentre è “curiosamente assente nella maggior parte delle Big Tech”. Per esempio, Skype nei primi anni 2010 adottò Scrum su vasta scala formando tutti i team su sprint e cerimonie. Eppure, in quegli stessi anni un concorrente come WhatsApp non seguì alcun framework come Scrum – anzi, gli ingegneri evitarono deliberatamente qualsiasi processo pesante – e ciò non impedì a WhatsApp di innovare più velocemente, superando Skype nel mercato della messaggistica.

Emblematico anche il caso del team Skype for Web: partito seguendo pedissequamente Scrum (sprint di 2 settimane, Scrum Master a rotazione, daily stand-up, review, retro, ecc.), il team si accorse presto che i numerosi rituali di Scrum rallentavano il rilascio continuo. La soluzione fu abbandonare Scrum del tutto: niente più sprints fissi né cerimonie superflue, ma concentrazione solo su ciò che fare adesso e dopo. Come nota un membro del team: “Scrum intralciava la possibilità di fare deploy giornalieri… abbiamo smesso di occuparci degli sprint e delle ritualità di Scrum”, mantenendo solo ciò che serviva al flusso di lavoro. Nel giro di poco, quel team continuava a fare Agile delivery ma “ciò che restava non assomigliava più a Scrum”.

Scrum non è più visto come panacea universale.

Molte organizzazioni riferiscono di aver raggiunto un plateau nell’efficacia di Scrum, e iniziano a guardare oltre: alcuni adottano approcci ibridi o “fai-da-te” (il 22% delle grandi aziende dichiara di non seguire alcun framework agile prescritto a livello enterprise), mentre le aziende tecnologiche leader non hanno mai realmente sposato Scrum sin dall’inizio.

Questo ci porta ai nuovi modelli emergenti nelle Big Tech.

Modelli flessibili basati su autonomia

Le aziende tecnologiche di primo piano (Google, Meta/Facebook, Apple, Amazon, Netflix, Microsoft, Spotify, Basecamp, ecc.) hanno seguito percorsi Agile propri, spesso nati organicamente dalla loro cultura, anziché adottare Scrum “by the book”. In queste realtà generalmente non esiste uno standard unico imposto a tutti i team: ogni team può scegliere il metodo di lavoro che preferisce, con forte enfasi su autonomia, risultati da raggiungere e adattamento costante.

Netflix. “People over Process”: cultura prima delle regole

Netflix è noto per la sua cultura aziendale di Freedom & Responsibility, in cui si assume personale eccellente e lo si mette in condizione di operare quasi senza vincoli burocratici. L’idea è creare una cultura così forte che il processo formale diventi quasi superfluo. Uno dei valori dichiarati di Netflix è proprio “Le persone prima del processo”. Nel famoso Netflix Culture Deck, l’azienda afferma: «Si ottengono risultati migliori quando i dipendenti hanno le informazioni e la libertà per prendere decisioni autonomamente». Tradotto in pratica, Netflix evita il più possibile regole fisse e processi formalizzati: esistono solo quelle strettamente necessarie per compliance e sicurezza, e comunque “ci impegniamo a mantenere le regole al minimo… evitando il classico crescendo di burocrazia che soffoca la creatività man mano che l’azienda cresce”.

Nei team di Netflix si riscontra un’altissima autonomia operativa. Non c’è un framework di project management standard adottato in tutta l’azienda. Alcune squadre utilizzano board in stile Kanban, altre seguono cicli di sviluppo brevi simili a mini-sprint, ma in generale si pratica il continuous delivery e si privilegia il rapido rilascio di valore continuo. Netflix ha introdotto il concetto di “full-cycle developers”, sviluppatori responsabili end-to-end: chi scrive il codice lo deploya, monitora in produzione e reagisce ai problemi, senza passaggi di consegne formali. Questo elimina la necessità di cerimonie elaborate o di ruoli come release manager: il feedback loop dal codice all’impatto sul cliente è breve e gestito dallo stesso team, favorendo un miglioramento rapido del prodotto. Se qualcosa va storto, il team Netflix non convoca un lungo post-mortem burocratico per aggiungere nuovi controlli; semplicemente risolve il problema e condivide le lezioni apprese in modo informale. La cultura del blameless post-mortem (analisi degli errori senza colpevolizzare), comune anche in Google, fa sì che si impari dagli insuccessi senza introdurre barriere organizzative che potrebbero frenare l’innovazione.

In poche parole, Netflix ha successo essendo “anti-processo”: minimizza regole e procedure e punta tutto su persone di talento estremamente allineate sugli obiettivi. Un’azienda tradizionale, senza la talent density e la cultura di Netflix, rischierebbe il caos con così poca struttura; ma da Netflix questo approccio funziona proprio grazie alla qualità delle persone e alla chiarezza della vision. Come afferma la loro filosofia interna, ridurre al minimo regole e processi dando libertà alle persone è una ricetta di gran lunga superiore per il successo di lungo termine. Per Netflix, metodologie Agile formalizzate sarebbero troppo prescrittive: imporre dall’esterno regole e ruoli (es. un Scrum Master che fa rispettare il processo) in un contesto che “gira a cultura” sarebbe visto come un ostacolo inutile. Invece di Scrum Master, ogni team si auto-organizza nel modo che ritiene più efficace per produrre risultati, incarnando lo spirito Agile senza bisogno del framework Scrum in sé.

Google. Obiettivi (OKR) e innovazione bottom-up, niente “Agile by the book”

Anche Google non ha mai adottato Scrum in modo diffuso a livello aziendale. Cresciuta rapidamente nei 2000, non si vedevano molte Scrum board nei corridoi di Googleplex. Il successo di Google si fonda più che altro su solide fondamenta ingegneristiche (assunzione di programmatori eccellenti, rigorose code review, test approfonditi) e su una cultura che favorisce innovazione continua. In pratica, Google ha abbracciato l’agilità come aggettivo, non come metodologia formale: i team adottano i principi di iterazione rapida e feedback senza però seguire un singolo framework prescritto.

Uno degli strumenti centrali in Google è l’OKR (Objectives and Key Results). Fin dai primi anni, Google ha usato gli OKR per fissare obiettivi trimestrali chiari per i team, dando focus e allineamento senza dettare il processo con cui raggiungerli. Questo outcome-driven planning permette ai team di sapere cosa deve essere ottenuto (Key Results misurabili) lasciando libertà su come arrivarci. Nella quotidianità, lo sviluppo prodotto in Google si potrebbe descrivere come un mix di decisioni guidate dai dati, sperimentazione rapida e miglioramento iterativo continuo, più che l’applicazione di un rigido schema Scrum.

Un blog ufficiale di Google Cloud riassume così l’approccio di Google: “dare priorità ai bisogni degli utenti, decisioni basate sui dati, iterazione rapida e sviluppo collaborativo” per costruire prodotti. Questi principi incentivano innovazione, velocità di sviluppo e crescita, notate, senza menzionare Scrum o gergo Agile: contano gli outcome (capacità di iterare, collaborare, fare in fretta) non l’adesione ortodossa a un processo. La cultura di Google incoraggia le idee bottom-up: molti nuovi prodotti nascono come esperimenti o side project di ingegneri (Gmail e AdSense nacquero così). Si parla di una “cultura di autonomia bottom-up e innovazione, dove le nuove idee provengono da chi è più vicino ai problemi”. In Google ogni team ha significativa libertà su come lavorare, purché consegni risultati. Alcuni team hanno effettivamente usato board Scrum o Kanban, altri hanno operato in modo più informale; non c’è mai stato un decreto dall’alto tipo “Dovete fare Agile alla lettera”.

Ciò che Google ha investito fortemente è negli strumenti interni che abilitano lo sviluppo rapido in stile Agile. Ad esempio, Google tiene praticamente tutto il suo codice in un unico repository monolitico accessibile a tutti gli sviluppatori, con build automatiche e tool di test/integrazione continua all’avanguardia, ecc. Questo ambiente tecnico integrato (costruito in-house) consente iterazioni velocissime e collaborazione senza barriere, di nuovo, risultati simili a quelli promessi da Agile, ma ottenuti tramite infrastruttura e cultura, non imponendo Scrum Master o sprint planning centralizzati.

Google incarna i valori Agile (orientamento al cliente, iterazione veloce, autonomia dei team) “come cultura aziendale, non come metodologia”. L’agilità è nel DNA organizzativo (OKR, 20% time per progetti innovativi, strumenti condivisi, ecc.), non in un framework specifico uguale per tutti.

Spotify. Il “modello Spotify”: autonomia delle squadre e rete di allineamento

Un caso spesso citato di approccio alternativo è Spotify. Nei primi anni 2010 gli ingegneri Spotify condivisero col mondo il loro modo di organizzare i team, che divenne celebre come Spotify Engineering Culture (video e whitepaper del 2012). Il modello Spotify non è un framework rigido, ma “un approccio people-driven e autonomo per scalare Agile, che enfatizza l’importanza della cultura e delle reti informali”. L’idea chiave di Spotify è bilanciare autonomia e allineamento: “focalizzarsi su come strutturare l’organizzazione per abilitare agilità” invece di prescrivere pratiche specifiche. A differenza di metodologie di scaling formali (tipo SAFe, LeSS) dove sono definiti cerimoniali precisi, il modello Spotify punta sulla struttura organizzativa e sulla cultura per ottenere agilità su larga scala.

In Spotify, i team (Squads) sono piccoli e cross-funzionali (6-12 persone) con una missione chiara ciascuno, simili a scrum team ma completamente autonomi. Una caratteristica fondamentale è che ogni Squad sceglie quale metodologia agile adottare: alcuni usano Scrum, altri Kanban, altri un mix (“Scrumban”), a seconda di cosa meglio si adatta al loro contesto. Non c’è dunque un processo imposto dall’alto uguale per tutti i team, il che riflette un alto grado di fiducia nell’autonomia di ciascuna squadra. Per evitare però che l’autonomia degeneri in direzioni contrastanti, Spotify ha introdotto meccanismi di allineamento orizzontale: le Tribes, insiemi di squadre affini (tipicamente 40-150 persone) che condividono obiettivi più grandi e coordinano gli sforzi su un’area di prodotto, e le Chapters e Guilds, comunità trasversali rispettivamente per competenza specialistica e per interesse, che diffondono conoscenza e pratiche comuni tra squadre diverse. Queste strutture “a matrice” assicurano che, pur lavorando con metodi diversi, i team rimangano allineati alla strategia complessiva e condividano la cultura aziendale.

Il risultato è un’organizzazione che privilegia le persone e le interazioni (coerentemente col manifesto Agile) anziché aderire a un singolo processo. Spotify ha dimostrato che è possibile far crescere l’azienda senza introdurre gerarchie di comando pesanti o un unico processo burocratico, ma mantenendo i valori di agilità attraverso cultura di fiducia, responsabilità diffusa e comunicazione aperta. Non a caso, il Spotify model ha influenzato molte aziende che cercavano un’alternativa ai framework tradizionali, enfatizzando autonomia dei team e rete di allineamento al posto di ruoli rigidi e procedure uniformi.

Basecamp. “Shape Up”: niente Scrum, cicli lunghi e responsabilità al team

Un altro esempio illuminante viene da Basecamp (ex 37signals), azienda nota per il suo approccio radicale al product development. I fondatori Jason Fried e David Heinemeier Hansson hanno spesso criticato le metodologie agili tradizionali e forgiato un loro metodo chiamato Shape Up. Nel libro online “Shape Up: Stop Running in Circles and Ship Work that Matters”, Jason Fried mette in chiaro già nella prefazione la loro filosofia: “Noi non facciamo waterfall né agile né scrum. Non riempiamo i muri di Post-it. Non facciamo daily stand-up, design sprint, development sprint, né nulla che abbia a che fare con metafore di gente esausta alla fine. Niente backlog, niente Kanban, niente misurazione della velocity, nulla di tutto ciò.”. Invece, Basecamp “ha sviluppato un approccio interamente diverso” nel corso di 15 anni, in autonomia, attraverso tentativi ed errori continui. Shape Up prevede cicli di sviluppo lunghi 6 settimane (in contrasto ai classici sprint di 1-2 settimane di Scrum) durante i quali un piccolo team lavora focalizzato su un problema/progetto senza interruzioni né “riedizioni” di planning ogni pochi giorni. Non ci sono backlog interminabili: le iniziative vengono shaped (definite a grandi linee con soluzioni possibili) prima di impegnare un team sul ciclo, e se qualcosa non viene assegnato in un ciclo, torna nel limbo delle idee non pianificate. Non esistono Scrum Master: la responsabilità di consegnare è condivisa dal team stesso, che gode di un ampio spazio di autonomia su come portare a termine il lavoro entro le 6 settimane.

L’assenza di rituali formali da un lato chiede molta disciplina al team (che deve auto-organizzarsi e auto-correggersi), ma dall’altro elimina l’overhead amministrativo e lascia più tempo per il lavoro sostanziale. Basecamp ritiene che molte pratiche agili convenzionali siano in realtà controproducenti: ad esempio, fare stand-up meeting quotidiani o stimare ogni singola user story può portare a un falso senso di controllo e a micro-gestione, mentre il loro metodo punta a “dare alle persone tempo e contesto per fare davvero il lavoro, con la fiducia che consegneranno qualcosa di valido alla fine del ciclo”. Shape Up enfatizza la fiducia nei designer e sviluppatori nel prendere decisioni implementative, limitando la pianificazione dettagliata iniziale solo all’essenziale (evitando di “spaccare il capello” in anticipo, no backlog grooming) e accettando che il scope sia variabile pur di rispettare la deadline fissa di 6 settimane. Questo approccio, pubblicato da Basecamp nel 2019, è divenuto una fonte d’ispirazione per quelle aziende che vogliono uscire dalle meeting-heavy routines di Scrum e provare qualcosa di diverso, più batch-oriented e creativo.

Niente Project Manager, team auto-organizzati

Un tratto comune nelle grandi aziende e nei casi sopra è l’assenza di figure di coordinamento tradizionali a livello di team. Nelle organizzazioni classiche, ad esempio, ogni team progettuale potrebbe avere un Project Manager o un Product Owner dedicato che sovrintende i piani e le attività. In molte Big Tech, invece, tali ruoli non esistono o hanno un peso molto minore: “Una differenza notevole tra Big Tech e gli altri è il ruolo dei Product Manager, e la mancanza di Project Manager o Product Owner dedicati ai team. Il Product Manager in aziende come Facebook, Google ecc. definisce la strategia e il perché (cioè decide “che gioco giochiamo e come intendiamo vincerlo”), collabora con design, data science e business per creare la roadmap e le priorità, ma non micro-gestisce l’esecuzione quotidiana. La gestione del progetto in sé è affidata al team tecnico: tipicamente è il Tech Lead o l’Engineering Manager a facilitare l’organizzazione del lavoro, oppure gli stessi ingegneri si alternano nel ruolo di project lead su specifiche iniziative. Questo snellisce i processi e rafforza le relazioni dirette: quando non c’è un project manager esterno, gli engineering lead tendono a introdurre solo il minimo di processo necessario, perché è nel loro interesse rimanere agili. E quando devono collaborare con altri team (anch’essi senza PM tradizionali), sono incentivati a costruire relazioni dirette con i rispettivi lead tecnici, velocizzando comunicazione e decisioni inter-team.

Solo per progetti molto grandi o trasversali si trovano figure dedicate come i Technical Program Manager (TPM), che coordinano iniziative multi-team o di reparto. Ma si tratta di poche persone rispetto alla forza lavoro ingegneristica, ad esempio Uber aveva circa 1 TPM ogni 50 sviluppatori. Nella quotidianità del singolo team, quindi, non c’è un project manager a dettare metodologia: ogni team adotta l’approccio di project management che preferisce (come accennato prima, alcuni in stile Kanban, altri con cicli brevi tipo Scrum, altri con roadmap a medio termine tipo RFC, etc.). Questa libertà è possibile perché a monte l’azienda ha creato un ambiente di fiducia e competenza diffusa: “Big Tech può permettersi di assumere persone estremamente competenti e autonome, che hanno bisogno di meno struttura per produrre risultati di alta qualità. L’autonomia non è vista con timore, bensì come la leva per ottenere il massimo da team eccellenti: squadre di 5-15 persone con mission chiara, skill complementari e piena autonomia di esecuzione sono il blocco fondamentale di queste aziende.

Va sottolineato come questo modello richieda un certo contesto organizzativo: non è che in assenza di Scrum regni l’anarchia. Al contrario, le Big Tech investono molto in infrastrutture e piattaforme interne per facilitare il lavoro autonomo dei team (tool di sviluppo, integrazione continua, sistemi di monitoring e alerting self-service, ecc.). Inoltre, c’è trasparenza totale su obiettivi aziendali e metriche: impiegati di ogni livello hanno accesso ai dati di business in tempo reale, possono farsi dashboard da soli e capire l’impatto del loro lavoro. La comunicazione è diretta: gli ingegneri sono incoraggiati a parlare con altre funzioni di business e non restare isolati nel proprio silos tecnico. Si evita la triangolazione gerarchica delle informazioni (dove ogni comunicazione deve passare per vari manager) a favore di contatti diretti ingegnere-ingegnere e team-team, che accelerano le decisioni. Tutto ciò crea un ecosistema in cui l’auto-organizzazione funziona davvero: i team hanno contesto, strumenti e mandate chiare, quindi possono muoversi rapidamente senza bisogno di un layer di coordinamento esterno che “traduce” obiettivi o monitora ogni passo.

In questo scenario, figure come lo Scrum Master diventano ridondanti, spesso il ruolo equivalente è svolto dal Tech Lead o da un membro del team a rotazione, come responsabile di progetto pro-tempore, ma senza l’enfasi cerimoniale e senza separare la gestione dal lavoro tecnico. Ad esempio, in alcuni team di Microsoft/Skype il ruolo di Scrum Master veniva fatto ruotare tra gli sviluppatori stessi. In Spotify, ogni Squad ha un Agile Coach disponibile come facilitatore se il team lo desidera, ma non è un “master” che impone rituali, è più un mentor/servant leader sul miglioramento continuo. E molte aziende (Netflix, Amazon, ecc.) non hanno affatto ruoli assimilabili a Scrum Master a livello di team, ritenendo che un buon engineering manager possa già supportare il team su processi, oppure che il team debba auto-disciplinarsi sulle pratiche agili.

Del resto “Perché mai dovrei avere uno Scrum Master a far rispettare un processo quando posso fidarmi di ogni team di auto-organizzarsi nel modo che offre i risultati migliori?”.

Cultura dell’autonomia e focus sugli outcome

Emerge sempre di più una narrativa comune: le aziende più avanzate stanno spostando l’enfasi dagli strumenti e rituali ai principi e ai risultati. In particolare, quattro elementi chiave caratterizzano questa evoluzione dell’Agile nelle big tech: cultura, autonomia, responsabilizzazione sui risultati (outcome), e allineamento leggero ma costante:

• “Individuals and Interactions over Processes and Tools”, sul serio stavolta: le azinede prendono alla lettera il primo valore del Manifesto Agile. Invece di focalizzarsi sul controllare un progetto tramite Scrum/Kanban, si focalizzano sul mettere le persone giuste al tavolo e dare loro fiducia. Un articolo di ThoughtWorks riassume: “Essere agili non significa tenere un progetto sotto controllo attraverso Scrum/Kanban; significa assumere le persone giuste e permettere loro di scoprire naturalmente la configurazione ottimale per consegnare con successo. In pratica, l’agilità è vista più come un tratto culturale che come l’adesione a uno schema prestabilito. Questo comporta grandi investimenti su selezione e formazione del talento, sulla crescita della leadership diffusa, e sulla creazione di un ambiente sicuro in cui i team possano provare e adattare il modo di lavorare. Nota: la cultura aziendale diventa il principale fattore abilitante. “L’Agile vero” è quello che scompare in quanto norma, perché entra nel tessuto del lavoro quotidiano.

• Empowerment dei team e responsabilità distribuita: un mantra ricorrente è autonomous teams. Come ho già scritto, “team empowered e autonomi sono i mattoni fondamentali di tutte queste aziende… il loro principale fattore differenziante”. Ciò significa dare ai team un obiettivo chiaro e poi lasciare che decidano come raggiungerlo, fornendo supporto ma evitando micro-management. Quando i team sono davvero autonomi, succede qualcosa di notevole: col tempo tendono a semplificare i processi da sé. Gergely Orosz racconta che “nel tempo, i team che hanno l’autonomia di cambiare il proprio modo di lavorare finiscono per eliminare le regole pesanti di Scrum di cui non hanno bisogno e sviluppare uno stile personalizzato. In altre parole, se un’azienda si fida dei team e dà loro margine di manovra, questi spesso prenderanno l’iniziativa di migliorare il processo continuamente (kaizen), riducendo burocrazia e sprechi meglio di quanto potrebbe fare un framework imposto dall’alto. L’empowerment implica anche accettare qualche rischio in più (ad es. team diversi usano pratiche diverse) ma viene ripagato da maggiore motivazione, i membri sentono il progetto come “nostro”, e maggiore velocità di decisione ed esecuzione.

• Dall’output alla misurazione dell’outcome: forse il cambiamento più significativo nel nuovo Agile è il passaggio da una mentalità di output (attività completate, ore lavorate, story point bruciati) a una mentalità di outcome (risultati di business ottenuti, impatto sugli utenti, valore generato). Molti esperti hanno evidenziato che tante implementazioni Agile falliscono perché rimangono intrappolate nel misurare il lavoro invece che il valore. Nelle adozioni Scrum superficiali si rischia di “mettere attenzione nel completare task a scapito di creare valore”, con sintomi come backlog vissuti come liste di compiti, metriche di efficienza tipo velocity elevate a obiettivo di per sé, e scarso collegamento col cliente finale. Le aziende pioniere stanno invertendo questa tendenza: definiscono chiaramente gli obiettivi di outcome e giudicano i team sul valore prodotto, non sulla mera quantità di output. Ad esempio, nel report State of Agile 2024 solo il 29% dei team dichiara di essere valutato sul valore consegnato, mentre ben il 36% è ancora valutato principalmente sulla velocity (cioè quantità di lavoro svolto per sprint). Tuttavia, si osserva una graduale correzione di rotta: “Un numero crescente di organizzazioni sta collegando gli OKR alle epiche di sviluppo (+5% rispetto all’anno precedente)”, integrando quindi gli Objective & Key Results nel modo di pianificare e misurare il lavoro agile. Questa integrazione consente di tradurre gli obiettivi strategici aziendali in risultati misurabili fino al livello di feature/progetto, dando ai team una linea di vista chiara su come il loro lavoro impatta gli indicatori chiave.

• Allineamento leggero, trasparenza e feedback continuo: abbandonare i controlli centralizzati non vuol dire navigare al buio. Le aziende agili evolute implementano meccanismi di allineamento orizzontale e verticali molto efficaci. Alcuni esempi: trasparenza radicale delle informazioni (come detto, tutti possono vedere dati di performance, roadmap, avanzamenti degli altri team); community interne (guild, chapter, meet-up interni dove le best practice si diffondono spontaneamente anziché via processi imposti); e feedback loop frequenti con gli stakeholder e gli utenti. Quest’ultimo punto è cruciale: il vero Agile punta a incorporare il feedback degli utenti il prima e il più spesso possibile. In assenza di rituali formali, le Big Tech creano comunque spazi di confronto: ad esempio rilasciano funzionalità progressivamente (canary release, A/B test, beta program) e raccolgono dati e reazioni degli utenti reali in tempo quasi reale, aggiustando il tiro. Internamente, organizzano demo day, hackathon, o semplicemente usano strumenti di comunicazione aziendale dove ogni team condivide ciò su cui sta lavorando, ottenendo commenti dal management o da altri colleghi in modo asincrono. Inoltre, la trasparenza verso i team sui risultati di business (es. “come sta andando il prodotto, cosa dicono i clienti, etc.”) crea motivazione e allinea naturalmente le priorità senza dover tenere meeting strategici continui. In sintesi, queste imprese coltivano una cultura in cui l’apprendimento e l’adattamento costante guidano il processo, al posto di piani fissi a lungo termine.

Un vantaggio non indifferente di questo approccio culturale è che l’agilità diventa antifragile: mentre un framework rigido può funzionare bene in un contesto e fallire se cambiano le condizioni, una cultura agile sa adattarsi alle novità. Ad esempio, durante la pandemia molte aziende hanno faticato a mantenere i rituali Scrum in remote working, mentre aziende con cultura agile forte (es. GitHub, Netflix) hanno reagito meglio, avendo già pratiche di comunicazione distribuita e team abituati a gestirsi in autonomia.

Intelligenza artificiale e Product Operating Model

Il passaggio da framework a cultura non avviene in un vuoto tecnologico. Oggi, uno dei principali catalizzatori di questo cambiamento è rappresentato dall’Intelligenza Artificiale. Non tanto perché sostituisca processi umani, quanto perché trasforma profondamente ciò che è possibile, ciò che è misurabile e ciò che è anticipabile.

In molte aziende, le cerimonie Agile sono state mantenute solo per sopperire a inefficienze informative o decisionali. Ma quando i team hanno accesso a insight in tempo reale, assistenti AI che sintetizzano dati, scrivono ticket, generano analisi e supportano la prioritizzazione, molti dei passaggi di coordinamento rituale perdono la loro funzione. L’AI sta quindi accelerando l’abbandono delle forme e spingendo verso una nuova sostanza: una organizzazione che apprende, anticipa e agisce per impatto.

Questo shift è sempre più associato alla nascita dei cosiddetti Product Operating Model (POM): modelli operativi che mettono il prodotto e il valore che genera al centro dell’organizzazione, superando le divisioni tra funzione, processo e struttura. A differenza dell’Agile “a silos”, dove ogni team lavora secondo un proprio metodo ma con metriche scollegate, il Product Operating Model cerca di orchestrare il lavoro su base pervasiva, con team multidisciplinari, allineamento continuo sugli outcome, feedback loop potenziati dall’AI e una forte cultura del prodotto.

In questo modello:

• AI supporta il decision-making distribuito, fornendo insight predittivi, analisi comportamentali, cluster dinamici di utenti e validazione in real time delle feature.

• Il design organizzativo è adattivo, orientato non solo a consegnare, ma a sperimentare e apprendere velocemente.

• I team agiscono come unità semi-autonome collegate da scopi condivisi e metriche impattanti, spesso espresse in termini di outcome e misurate grazie all’infrastruttura dati e AI.

In pratica, il Product Operating Model non è un framework, ma una visione operativa che integra tecnologia, cultura e autonomia in modo coerente e fluido. Non sostituisce Agile: lo evolve, lo distribuisce e lo rende “invisibile” nei comportamenti quotidiani.

L’AI non “uccide Agile”. Ma uccide il bisogno di mantenerne le apparenze, restituendo centralità a ciò che davvero conta: persone competenti, contesto chiaro, metriche visibili e capacità di adattarsi velocemente.

Come evolvere verso questi modelli

Come possono le aziende più tradizionali o quelle che oggi sono bloccate in un Agile di facciata trarre spunto dai modelli delle Big Tech? Ecco alcuni spunti pratici e operativi emersi dalle ricerche e case study:

• Rimettere i principi al centro: prima di qualsiasi cambio di framework, è utile rileggere i principi Agile e chiedersi sinceramente se si stanno onorando. Individui e interazioni sopra processi e strumenti,  stiamo dando fiducia e voce ai team? Prodotto funzionante sopra documentazione esaustiva, stiamo consegnando valore tangibile frequentemente? Collaborazione col cliente sopra negoziazione contrattuale, stiamo coinvolgendo gli utenti/stakeholder continuo? Rispondere al cambiamento sopra seguire un piano , stiamo adattando piani e priorità in base ai feedback reali? Identificare dove l’organizzazione è caduta in una trappola da cargo cult (seguire Scrum meccanicamente perdendo di vista il perché) è il primo passo. Ad esempio, se ci si accorge che si fanno stand-up meeting quotidiani ma le informazioni cruciali non circolano comunque, forse bisogna agire sulla cultura della trasparenza anziché aggiungere un altro meeting.

• Coltivare l’autonomia gradualmente: per un’azienda abituata a modelli top-down, passare bruscamente all’auto-organizzazione totale può essere pericoloso. Si può procedere per gradi: empowerment controllato. Ad esempio, iniziative pilota creare uno/due team multifunzionali dedicati a un progetto innovativo, ai quali si concede esplicitamente di non seguire il processo standard ma di sperimentare un proprio modo di lavorare. Questi “team faro” devono però avere anche il giusto supporto: leader pronti a rimuovere impedimenti, accesso diretto ai decision-maker aziendali e magari un coach esperto che li aiuti nelle retrospettive. L’idea è mostrare che risultati producono in un contesto di maggiore autonomia. Se il trial ha successo (es. tempo di delivery dimezzato, miglior qualità, team più motivato), diventa un caso interno per convincere altri ad adottare pratiche simili.

• Allentare le pastoie del processo, ma mantenere guardrail chiari: le Big Tech insegnano che liberare i team non significa lasciarli allo sbaraglio. Significa piuttosto spostare i controlli ex-ante in controlli ex-post: invece di prescrivere ogni passo (input), si definiscono chiaramente obiettivi e limiti, e si verifica frequentemente il risultato (output/outcome). Ad esempio, un’azienda potrebbe decidere di abbandonare il rigido ciclo di sprint Scrum per alcuni team, lasciando che pianifichino in modo più fluido; tuttavia potrebbe fissare un guardrail tipo: “rilasciate qualcosa di testabile agli utenti almeno una volta al mese”, oppure “nessun progetto deve durare più di 3 mesi senza essere rivalutato”. Così si incoraggia l’agilità ma si evita il rischio di progetti che si trascinano indefinitamente. Un case study citato da McKinsey racconta proprio questo: un’azienda di prodotto consumer aveva suddiviso un grande progetto in tanti team specializzati, ma con forte controllo centrale, risultato, tutto fermo. La svolta è arrivata quando hanno spostato ogni decisione (anche di budget e architettura) nei team agili, fornendo solo una chiara visione dei risultati clienti attesi e alcune regole di base (es. rilasciare demo funzionanti a intervalli regolari). In pochi mesi, quei team empowered hanno lanciato uno dei migliori prodotti dell’azienda, in tempi record e con personale motivatissimo, proprio grazie a quella libertà entro confini chiari. La lezione: date ai team un obiettivo sfidante, contesto sul perché è importante, e poi fidatevi (con meccanismi di check-in sul cosa si sta ottenendo, non sul come preciso).

• Riformare i criteri di successo e le metriche di performance: se continuate a valutare project manager e team solo sul rispetto di tempi/costi e sul numero di funzionalità consegnate, state incentivando la vecchia mentalità output-driven. Occorre inserire metriche di outcome nei dashboard di progetto e nelle valutazioni. Ad esempio: customer satisfaction, tasso di adozione di una nuova feature, riduzione di churn, incremento di vendite, o anche metriche interne tipo tempo medio di risoluzione ticket, frequenza di deploy, ecc., a seconda della natura del team. Un’idea è utilizzare OKR formalmente: far sì che ogni team abbia 1-3 Objectives trimestrali con relativi Key Results misurabili, e valutare i progressi su quelli nelle review di fine periodo. Questo allena tutti a pensare in termini di risultati di business. Anche a livello individuale, potrebbe voler dire premiare un developer non solo perché ha chiuso 30 task, ma perché il modulo su cui ha lavorato ha retto a X utenti in più senza problemi o ha ricevuto feedback entusiasti. Spostare l’attenzione sulle metriche di impatto frena anche quella che McKinsey chiama “fissazione sulla piena occupazione”: in molte aziende tradizionali vige l’idea che un team che non è occupato al 100% su tasks assegnati stia “sprecando tempo”. Ma tenere tutti sempre occupati non è il fine! È preferibile avere momenti di analisi, esperimenti, brainstorming (quindi persone non impegnate su task pre-definiti al 100%) se questo porta a soluzioni più efficaci per il cliente. Come dice un esperto: “focalizzarsi sul tenere tutti occupati rimuove l’opportunità di collaborare per deliverare grandi risultati per il cliente”. Quindi i manager devono abituarsi a chiedere “che valore avete creato?” invece di “quanto siete occupati?”. Un’azione concreta potrebbe essere inserire nei report settimanali non solo i task completati ma anche un breve paragrafo su cosa hanno comportato (ad es. “abbiamo rilasciato la funzione X e 200 utenti l’hanno già utilizzata nelle prime 24h”). Questo sposta pian piano la conversazione.

• Re-immaginare il ruolo del management e dei coach: in un modello agile evoluto, il middle management tradizionale (Project Manager, etc.) può sentirsi disorientato. Gartner prevede che entro il 2026 “due terzi dei ruoli e delle competenze dei Project Manager saranno ridisegnati” per adattarsi al nuovo contesto operativo. Ciò significa che queste persone vanno aiutate a trasformarsi da controllori di Gantt a abilitatori di successo del team. Un ex-PM può diventare un Agile Coach interno focalizzato su rimuovere impedimenti, facilitare collaborazione tra team e assicurare che il cliente sia integrato nel processo. Oppure, molti PM stanno evolvendo in Product Manager (orientati alla strategia e al value delivery più che all’amministrazione del progetto). Le aziende dovrebbero investire in training mirato: ad esempio, formare gli ex Scrum Master/PM sui temi di Lean Product Management, Design Thinking, analisi di business, in modo che possano contribuire definendo meglio il perché e il cosa deve essere fatto (outcome), lasciando al team il come. In parallelo, gli Engineering Manager dovrebbero essere formati per assumere alcuni compiti di facilitazione che magari prima erano del PM: come condurre retrospettive efficaci, come leggere i segnali di burnout nel team, come bilanciare l’urgenza di delivery con la necessità di rifattorizzare codice, ecc. In sostanza, si passa da manager di processo a leader servizievoli. Anche la carriera di Agile Coach in sé va reinterpretata: non più garanti di cerimonie Scrum, ma agenti del cambiamento culturale. Questo può voler dire che un Agile Coach lavora più sul livello sistema (aiuta i dirigenti a capire dove la burocrazia sta frenando i team, influenza HR per modificare sistemi di incentivazione, etc.) invece che occuparsi di cronometrare daily stand-up. Infine, un approccio pratico è adottare la filosofia del “teacher/coach/mentor” per i manager di progetto di vecchio stampo: Gartner suggerisce che i PM evoluti dovranno giocare principalmente tre ruoli:

  • Teacher (educare team inesperti nell’agilità)

  • Coach (allineare stakeholders e guidare l’organizzazione del lavoro agile)

  • Leader di innovazione a seconda della maturità dell’organizzazione. Analizzare il proprio PMO (Project Management Office) e identificare chi può ricoprire questi ruoli è un buon esercizio per anticipare il futuro.

• Snellire gli strumenti e digitalizzare la collaborazione: molte aziende agili mature hanno costruito tool interni altamente integrati (issue tracker, wiki, sistemi CI/CD, ecc.) per supportare il lavoro dei team. Un’azienda più piccola o tradizionale può prendere ispirazione adottando strumenti moderni più leggeri o customizzando quelli esistenti per rimuovere complessità inutile. Ad esempio, diverse società lamentano che JIRA (pur usatissimo, ~62% delle aziende lo impiega come principale tool Agile) sia diventato sinonimo di overhead burocratico: troppi ticket, troppi campi, workflow rigidi. Un miglioramento può essere semplificare i workflow JIRA (ridurre stati e transizioni all’essenziale) o sperimentare alternative per certi team (es. usare una Kanban board più semplice come Trello, o addirittura soluzioni lightweight come fogli condivisi) per vedere se la velocità e la soddisfazione aumentano. L’importante è capire che lo strumento deve adattarsi al team, non viceversa. Scrum e JIRA tendono ad andare a braccetto, perché JIRA è ottimo per il tracking gerarchico e la reportistica per il management. Ma se l’obiettivo diventa la trasparenza reale e non il controllo, allora spesso bastano dashboard condivisi degli OKR e delle metriche di prodotto per allineare tutti, invece di infiniti ticket.

• Digital first: adottare strumenti che favoriscano la collaborazione asincrona (specie con lo smart working) è cruciale, es. documenti condivisi per specifiche al posto di meeting, canali chat dedicati cliente-team, registrazione delle demo e condivisione interna per feedback offline, ecc. Le grandi aziende adottano da anni Slack/Teams con bot automatici che postano aggiornamenti (build riuscite, metriche di ieri, nuovi errori in prod…), creando “ambient awareness” senza dover interrogare un project manager. Anche senza l’infrastruttura di Google, si può replicare questo mindset utilizzando API e integrazioni tra tool esistenti.

• Imparare dai dati e dagli esperimenti: non ultimo un consiglio chiave, trattare l’adozione di nuovi modelli come un esperimento Agile esso stesso.

  1. Misurate l’impatto delle modifiche organizzative. Ad esempio, se rimuovete la figura dello Scrum Master su alcuni team, osservate per 2-3 mesi metriche come: velocità di delivery, qualità del prodotto (bug in produzione), soddisfazione del team (survey interni), soddisfazione dei clienti. Se migliorano o restano uguali, potete considerare di estendere il modello; se peggiorano, analizzate il retro, forse il team aveva ancora bisogno di quel supporto e va reintrodotto in altra forma. Applicate l’idea di retrospective non solo ai progetti, ma anche al processo di trasformazione organizzativa: ad intervalli regolari, il gruppo dirigente (magari col supporto di coach esterni) dovrebbe rivedere cosa sta funzionando e cosa no nella nuova struttura e pivotare di conseguenza.

  2. Non abbiate paura di modificare radicalmente aspetti del processo se non servono. Come disse un coach: “Il nostro obiettivo come agile coach dovrebbe essere renderci superflui, quando una squadra si auto-gestisce e consegna valore senza il bisogno di coach, allora abbiamo avuto successo.” In quest’ottica, anche Scrum non deve essere visto come sacro: se serve come trampolino di lancio, bene, ma poi bisogna saperlo lasciare andare. In molti contesti (soprattutto aziende più piccole o settori non tech) Scrum all’inizio può essere utile per portare disciplina e cadenza dove c’era caos totale. Ma una volta che il team entra in performing, dovrebbe avere la libertà di evolvere il processo. Jeff Bezos di Amazon ha una famosa metafora: “Le aziende devono essere ferme nei principi, ma flessibili nei dettagli”. Applicato all’Agile: teniamo fermi i principi (customer focus, collaborazione, adattabilità) ma siate flessibili su pratiche e ruoli.

L’evoluzione dell’Agile nelle imprese più innovative suggerisce che il futuro non appartiene a un nuovo framework specifico, ma a un nuovo mindset. Un mindset in cui contano la cultura e gli outcome, dove i team sono piccoli centri autonomi di creatività allineati da una vision comune, e dove la metodologia è una conseguenza naturale di questi fattori più che un preludio.

Scrum non scomparirà dall’oggi al domani rimane uno strumento valido in molti contesti (specialmente dove c’è bisogno di introdurre un minimo di ordine e educare l’organizzazione al lavoro iterativo). Ma la sua centralità è destinata a ridursi mano a mano che le aziende maturano verso forme di agile più organiche. Come notato, “scelto il giusto talento e data la giusta autonomia, un team finirà per sviluppare un proprio sistema agile su misura”.

Il compito di chi vuole indirizzare i nuovi progetti e le nuove aziende è quindi creare l’ambiente adatto (cultura aperta, obiettivi chiari, feedback costante, strumenti adeguati) e poi mettersi al servizio dei team. In questo modo, le aziende potranno evolvere dai rituali alla sostanza, ispirandosi ai modelli vincenti delle Big Tech ma trovando la propria strada unica per essere agili, con la “a” minuscola, come attitudine quotidiana, e non solo fare “Agile” come etichetta.