Abbandonare Agile? Quando a proporlo è uno degli “inventori” di Agile…

Nei mesi scorsi ha fatto discutere l’invito ad abbandonare Agile rivolto agli sviluppatori da uno dei padri del movimento agile. A bocce ferme, proponiamo qualche breve riflessione sull'argomento, che va oltre la provocazione dialettica.

C’è chi può…

Sarà colpa del bombardamento di informazioni cui siamo sottoposti ogni giorno e che costringe, per farsi notare, a trovare mezzi sempre più “estremi” — l’aggettivo non è casuale, come vedremo —, ma la boutade, lo spararla grossa, la provocazione sembrano diventate le uniche modalità per ricevere grande attenzione sui media — social e tradizionali — in un panorama comunicativo che ha spostato negli ultimi anni sempre più avanti il limite del paradossale.
"I’m Ron Jeffries, the same old one".
“I’m Ron Jeffries, the same old one”.
Però, se tra meno di due anni sarai ottuagenario, se sei uno degli inventori dell’eXtreme Programming, se sei tra i 17 estensori e firmatari del Manifesto Agile e, in breve, se ti chiami Ron Jeffries, forse la tua provocazione non va considerata una sparata, quanto piuttosto un interessante spunto su cui riflettere.

Gli sviluppatori dovrebbero abbandonare Agile

A maggio di quest’anno, sul suo blog, Ron Jeffries ha pubblicato un articolo dal titolo Developers Should Abandon Agile in cui ogni parola è soppesata e i termini vengono usati con estrema precisione. Se si tratti solo di polemica “terminologica” è questione che ogni lettore potrà valutare da solo, ma di certo ci sono alcuni punti che meritano una breve disamina.
A beneficio dei pochi che non avessero letto il post originale, ecco una sintesi di quel che afferma Jeffries.

Agile è diventato un “business” 

Ci sono ormai tanti corsi e certificazioni, anche di assoluta qualità, che “diplomano” coach Agile, forniscono formazione su leadership Agile o su project management Agile e così via: la parola Agile si accompagna a tante attività dell’ambito aziendale e non è più usata solo nella locuzione Agile Software Development.

Agile va bene per le grandi aziende…

La grande “disponibilità” di professionisti in grado di apportare “idee Agile” alle aziende è sicuramente un vantaggio per queste ultime: le organizzazioni trarranno dei benefici dal guardare con un’ottica Agile ai propri processi e dal porsi sulla strada per un miglioramento; i ruoli direttivi potranno migliorare nella loro capacità di prendere le migliori decisioni.
SAFe è uno dei vari framework per applicare "Agile" in maniera scalata alle grandi organizzazioni.
SAFe è uno dei vari framework per applicare “Agile” in maniera scalata alle grandi organizzazioni.

…ma diventa uno svantaggio per gli sviluppatori

Spesso però, un’introduzione dall’alto dei concetti Agile finisce per riverberarsi in maniera negativa sugli sviluppatori ai quali non viene fornita adeguata formazione, viene garantito meno tempo per concludere i lavori, viene imposta maggior pressione e la richiesta di andare più veloci, dal momento che si suppone che l’agilità garantisca automaticamente maggior produttività.
Queste dinamiche finiscono per deteriorare la qualità di vita degli sviluppatori, abbassare il livello del software, aumentare il tasso di abbandono del personale.
E ciò è abbastanza deprimente per chi, come Ron Jeffries e Kent Beck, ha speso una vita a cercare di migliorare le condizioni di lavoro degli sviluppatori, categoria a cui Jeffries ancora sente di appartenere, nonostante anche tutta la carriera da manager, consulente e autore di testi tecnici. È proprio con quello spirito che ha contribuito al Manifesto per lo sviluppo Agile del software.

Quale strategia per gli sviluppatori?

L’articolo di Jeffries non si limita a mettere in luce gli aspetti da lui ritenuti negativi, ma fornisce anche una serie di consiglipratici” che gli sviluppatori possono mettere in atto per contrastare queste forme di Agile non ben implementate (che Jeffries chiama Dark Agile o Faux Agile dove altri autori avrebbero probabilmente parlato di distorsioni in stile cargo cults).
Tra i “consigli agli sviluppatori”, emergono, in sintesi, i seguenti:
  • distaccarsi dal termine “Agile”;
  • concentrarsi sulle pratiche di sviluppo software, come eXtreme Programming, che si possono inserire senza problemi all’interno di qualsiasi metodo “agile”;
  • indipendentemente dal metodo o dal framework Agile che viene adottato dall’azienda, gli sviluppatori devono tenere sempre presenti i principi fondamentali presenti nell’Agile Manifesto
  • ciò si concretizza nel rilasciare a intervalli molto brevi di tempo (una o due settimane) software testato, funzionante e integrato; nel mantenere “pulito” il software nel suo complesso, anche grazie a pratiche di refactoring; nell’impiegare l’incremento apportato al software come base di discussione con il management e i portatori di interesse, concentrandosi sullo sviluppo di una funzionalità per volta e non sulla scrittura di un infinito elenco di richieste da parte dei ruoli apicali.
In breve, per gli sviluppatori, l’unico vero appiglio resta il software reale e funzionante, prodotto a ritmi sostenibili.
I metodi “agili” e le infrastrutture per scalare Agile sono qualcosa che l’azienda “installa” al proprio interno, ma che dovrebbero essere vissuti in maniera “agnostica” dagli sviluppatori che, in definitiva, devono produrre software funzionante a intervalli di tempo brevi.

Qualche considerazione

il lungo ragionamento di Jeffries rappresenta, più che altro, una puntualizzazione rivolta a un preciso ruolo, quello degli sviluppatori, che rischia di rimanere schiacciato da un’agilità imposta dall’alto con un approccio prescrittivo.
Il richiamo ai fondamentali — software funzionante e tecniche di programmazione razionali ed efficienti, come XP — è tutt’altro che provocatorio ed è anzi piuttosto “conservatore”.

Cosa si intende per “Agile”?

Appare chiaro però che la discussione verte molto sul significato — o sui molteplici significati — che si intende attribuire al termine “Agile/agile”.
Non possiamo certo affrontare tale questione in tutta la sua ampiezza anche perché ci sembra che il dibattito nella comunità “agile” — usando l’aggettivo nel significato più ampio — sia  ormai paragonabile alle dispute della filosofia scolastica medievale…
Un fotogramma dal film "Il nome della rosa" (1986).
Un fotogramma dal film “Il nome della rosa” (1986).
Però è chiaro che, ai due estremi, si possono collocare due visioni ben individuabili. Da un lato chi intende “agile” come strettamente legato al Manifesto per lo sviluppo agile del software e ai principi e alle pratiche tecniche (XP per prima) che consentono, in maniera sostenibile, di rilasciare software funzionanti a intervalli di tempo brevi e cadenzati, facendo sempre riferimento al prossimo incremento di software come base per la discussione con management e stakeholder.
Dall’altro lato si pone chi, dopo aver magari sperimentato l’efficacia dei principi e delle pratiche agile per lo sviluppo del software, ha ampliato lo spettro di azione portando certi valori e un determinato approccio a settori produttivi non strettamente software e all’intera organizzazione, magari partendo proprio dal management.

L’orizzonte allargato di Agile

Non si tratta, per rimanere alla metafora della filosofia medievale, di schierarsi tra “ortodossi” ed “eretici”, ma probabilmente solo di tenere presente dell’ampliamento dell’orizzonte in cui ci si muove.
E va poi considerato che possono esistere approcci differenziati, pur nel rispetto dei principi fondamentali, anche a causa delle differenze culturali e geografiche. Quando fu scritto l’Agile Manifesto, si faceva riferimento a una precisa realtà produttiva (l’industria del software) in un dato contesto economico e geografico (principalmente quello nordamericano). E l’articolo di Jeffries resta abbastanza legato a quel contesto. Rispetto al quale, per dire, la nostra realtà aziendale italiana, resta diversa ed è giunta “in ritardo” a scoprire principi e pratiche Agile.
Occorre prendere atto che oggigiorno siamo in presenza di una estensione a livello globale dei principi Agile e degli altri principi che, pur non essendo strettamente catalogabili come “Agile” in senso “ortodosso”, sono stati riscoperti e/o sviluppati proprio grazie al successo dell’agilità: dalla Lean Production con le pratiche che ne derivano come Kanban, a un modo nuovo di fare HR (per comodità denominato Agile HR); dall’attenzione alle competenze trasversali alla gestione del cambiamento e della trasformazione nelle organizzazioni.

In conclusione

Quasi venti anni sono passati dalla stesura del Manifesto Agile; da allora sono cambiati gli scenari produttivi e si è allargata la diffusione dei principi e delle pratiche “Agile”, intendendo questo termine nel modo più ampio possibile.
Che, di fronte al dilagare di innumerevoli “Agile qualcosa”, uno dei “padri fondatori” voglia richiamare l’attenzione su certe distorsioni di Agile e su come esse si ripercuotano sugli sviluppatori, è sicuramente lecito e sensato. Del resto Ron Jeffries, sempre attento alle sottigliezze terminologiche, ha recentemente precisato che Scrum non è un’infrastruttura per lo sviluppo agile del software
Ma diventa rischioso anche far derivare da tali riflessioni un “abbandono” in senso più lato di quanto il movimento agile ha risvegliato nel dibattito sull’organizzazione dei processi e sulla gestione del cambiamento nelle aziende. Che lo si chiami Agile in senso proprio o esteso, quel che conta è che tutti, alla fine, lavorino meglio, in modo sostenibile, con un continuo e cadenzato rilascio di valore, e con la realizzazione di soluzioni funzionanti che soddisfino le reali necessità del cliente.