Quando l’agilità diventa solo un’etichetta

Nel mondo dello sviluppo software, proclamarsi agili è diventato quasi obbligatorio. Ogni azienda tecnologica che si rispetti inserisce nel proprio sito web riferimenti a Scrum, Kanban o Extreme Programming. Eppure, dietro questa facciata di modernità metodologica, si nasconde spesso una realtà ben diversa: processi rigidi mascherati da terminologia alla moda, riunioni infinite che sostituiscono il lavoro effettivo, e una distanza abissale tra teoria e pratica.

L’illusione della trasformazione

La peculiarità delle metodologie agili rispetto ad altre innovazioni tecnologiche sta nella loro natura: a differenza del cloud computing o di nuove architetture software, l’agilità può essere adottata solo nominalmente. Non serve cambiare realmente nulla, basta rinominare le attività esistenti con nuovi termini. La riunione settimanale diventa sprint review, il coordinamento quotidiano si trasforma in daily stand-up, e improvvisamente l’organizzazione può dichiararsi agile senza aver modificato un singolo processo sostanziale.

Questo fenomeno ricorda l’approccio alle diete: tutti possiedono le app di tracking più avanzate, seguono influencer del fitness, conoscono a memoria le calorie di ogni alimento, ma continuano a mangiare esattamente come prima. La differenza è che mentre con una dieta i risultati sono visibili sul proprio corpo, con le metodologie di sviluppo si può mantenere questa illusione indefinitamente, nascondendo l’assenza di vera trasformazione dietro cerimonie rituali e reportistica colorata.

Waterfall non è morto, si è solo camuffato

Nonostante decenni di letteratura sul fallimento del modello a cascata, molte organizzazioni continuano ad applicarlo. Il risultato sono progetti che richiedono anni, producono qualcosa che forse somiglia vagamente a quanto richiesto, ma soprattutto escono perché ormai è stato investito troppo per fermarsi. L’importante è aver fatto qualcosa, non che funzioni davvero.

Anche nei contesti più piccoli, dove una singola persona gestisce tutto, il waterfall puro rimane un mito teorico. Nessuno riesce ad avere tutto chiaro fin dall’inizio senza iterazioni continue. Figuriamoci quando il progetto coinvolge decine di persone, ciascuna con la propria interpretazione degli obiettivi e delle priorità.

Il micromanagement tecnico come killer della produttività

Se c’è un fenomeno che contraddice ogni principio agile, è il micromanagement tecnico. Questa pratica trasforma sviluppatori competenti in esecutori demotivati alla velocità impressionante. La figura tipica è il responsabile che non scrive codice da anni, ma rimane convinto di sapere esattamente come implementare ogni singola funzionalità.

Le domande sono sempre le stesse: “Perché non usi questo pattern?” riferendosi a tecnologie del 2003 applicate a framework moderni. “Quando sviluppai quel sistema funzionava così” ignorando che il contesto tecnologico è completamente cambiato. Il fatto che gli smartphone fossero fantascienza all’epoca diventa un dettaglio irrilevante.

Gli effetti sono misurabili: per ogni ora di supervisione invasiva, la produttività crolla e gli sviluppatori aggiornano silenziosamente i propri curriculum. È l’equivalente di qualcuno che ti guarda digitare la password chiedendoti perché sei così lento.

I sintomi di un ambiente microgestito sono evidenti: riunioni che durano più del lavoro effettivo, risposte del tipo “come preferisci tu” a qualsiasi domanda tecnica, e un turnover talmente alto che le risorse umane hanno automatizzato il processo di uscita. Gli sviluppatori sopravvivono sviluppando tecniche di adattamento: il “dico di sì ma poi faccio diversamente”, il commit del venerdì sera quando nessuno controlla, e documentazione volutamente criptica per proteggersi da interferenze.

La tirannia delle riunioni

Le riunioni nell’IT sono come le tasse: inevitabili, dolorose, e tendono ad aumentare nel tempo. Ma mentre le tasse hanno almeno una scadenza, le riunioni si moltiplicano occupando ogni spazio disponibile nel calendario.

Esistono due categorie principali. Le riunioni programmate si ripetono con regolarità svizzera, come appuntamenti fissati mesi prima che, quando arrivano, nessuno ricorda più perché fossero necessari. Diventano rituali vuoti dove quindici persone spendono un’ora per comunicare informazioni che potrebbero stare in due righe di email. O peggio, che potrebbero essere aggiornate sul task manager che nessuno consulta mai.

Poi ci sono le riunioni urgenti, organizzate con cinque minuti di preavviso, costringendo tutti a rivoluzionare la propria giornata. La soluzione ottimale sarebbe nel mezzo: riunioni quando servono davvero, ma programmate con anticipo sufficiente. Questo richiede però una maturità organizzativa rara, che molte aziende sostituiscono con la calendario-crazia, quel sistema dove il potere si misura dal numero di riunioni che puoi convocare.

Il problema vero non è la frequenza, ma l’utilità effettiva. Troppe riunioni dove si ripetono le stesse cose della settimana prima, o dove si convocano altre riunioni per discutere di quello che si sarebbe dovuto discutere. Un loop temporale dove l’unica via d’uscita sembra essere organizzare un’altra riunione per ridurre le riunioni.

Nel mondo IT, dove la concentrazione è preziosa quanto rara, ogni riunione dovrebbe essere un investimento: se non produce ritorno concreto, è solo un costo. Le riunioni sono strumenti, non fini. Come gli antibiotici: utili quando necessari, ma l’abuso crea resistenze ed effetti collaterali.

I veri ostacoli all’agilità

Implementare davvero l’Agile è difficilissimo. Serve disciplina ferrea: basta un solo elemento che non collabora per far crollare l’intero sistema. I team veramente agili si ritrovano a compensare continuamente, e con l’aumentare delle dimensioni il peso della gestione rischia di superare quello dello sviluppo.

La mancanza di visione a lungo termine è un classico. I puristi direbbero che questo è il punto – adattarsi invece di pianificare – ma provate a spiegarlo al management che deve giustificare budget triennali.

Il coinvolgimento del cliente è una storia tragicomica. L’Agile presuppone un cliente sempre presente, come se non avesse altro da fare. La realtà somiglia a un gioco dove il cliente appare solo quando c’è un problema, per poi scomparire quando serve il suo contributo costruttivo.

La gestione di team non autonomi è un altro punto dolente. L’idea di gruppi cross-funzionali è bella sulla carta, ma spesso ci si ritrova con sviluppatori che considerano il testing una punizione, e tester che vedono il codice come arte oscura da evitare.

Gli strumenti inadeguati completano il quadro. Molte aziende credono che essere agili significhi comprare una licenza software e riempire pareti di bigliettini colorati, dimenticando che automazione e ambienti ben configurati sono fondamentali.

La verità scomoda

Probabilmente nessuno afferma sinceramente “siamo agili” senza aggiungere un “anche se”. Forse l’unico modo per essere veramente agili è ammettere che l’agilità non è scienza esatta, ma un processo di compromessi. Ogni decisione porta con sé quell’inevitabile “anche se” che, ironicamente, dimostra come tutti siamo imperfetti ma in evoluzione.

L’Agile è come la democrazia: un sistema imperfetto ma il migliore disponibile. Il trucco non sta nell’applicarlo alla lettera come un manuale, ma nell’adattarlo al proprio contesto accettando imperfezioni inevitabili. L’importante è mantenere lo spirito: capacità di adattamento, focus sul valore per il cliente, e volontà di miglioramento continuo.

La best practice per fallire con stile? Affermare di applicare il manifesto Agile alla perfezione. Così si può vendere un corso senza aver mai lavorato su un vero progetto tecnologico.

Questo articolo è tratto da “Non funziona niente! – I progetti IT in crisi”, il primo libro della collana Nothing Works! — una tragicommedia aziendale per chi ha visto troppi Gantt chart trasformarsi in fiction.

Scopri la collana completa, gli altri libri e le prossime uscite su nothingworks.it

Vuoi il libro subito? Compralo su Amazon

Potrebbe interessarti anche

• Sistemista IT in una PMI: mansioni e competenze
• DIRETTORE ACQUISTI
• Perché documentare gli interventi IT potenzia la posizione del Sistemista?
• Da sistemista IT a IT Manager: un, possibile, percorso di carriera nell’ambito manifatturiero
• I problemi quotidiani di un Sistemista IT e come risolverli
• SISTEMISTA
• Quanto guadagna un Sistemista a Torino?
• SISTEMISTA IT
• Cosa fa un Sistemista in un Managed Service Provider: ruolo e giornata tipo
• Dieci clienti, un solo Sistemista: come si gestiscono le priorità in un Managed Service Provider