Retrospettiva: le cose cambiano

L’idea per questa “riflessione” mi è venuta leggendo lo speciale per il ventennale di MokaByte [1]. Gli articoli lì contenuti, infatti mi hanno “costretto” a una sorta di retrospettiva sull’evoluzione tecnologica di questi ultimi venti anni. Da lì a passare all’evoluzione di Agile in questi ultimissimi anni, il passo è stato breve.

Chi li ha vissuti in pieno, lavorando nell’ambito IT più o meno dal periodo di apparizione di Java, si sarà reso conto di alcune cose: che due decenni in ambito informatico sono l’orizzonte spesso definito come “lungo termine”; che l’IT si è trasformato da settore a servizio degli altri ambiti produttivi a vero e proprio motore propulsivo delle economie avanzate; che tutta questa accelerazione è coincisa con — o ha comportato — enormi mutamenti storici e sociali, vale a dire la piena affermazione della globalizzazione in campo economico con i vantaggi e i danni che essa ha causato.

E un’altra considerazione, solo apparentemente più “personale”, è che quasi nessuno, nel nostro ambito, fa più il “mestiere” che svolgeva anche solo quindici o dieci anni fa. Perché tutto questo discorso? Per dire che le cose cambiano, anche se spesso non ce ne accorgiamo che a giochi fatti, e che questo cambiamento è diventato davvero velocissimo.

Uno sguardo a Java

In ambito tenologico, quello che è successo con Java rappresenta un esempio di quello che cercheremo di vedere più avanti nell’articolo a proposito del mondo Agile. Inizialmente abbiamo visto in Java un nuovo linguaggio di programmazione che, a fronte di alcune rinunce di prestazione, ci avrebbe però risolto una serie enorme di problemi. Chi c’era non si nasconda: all’affermazione “write once, run everywhere” ci abbiamo creduto tutti. E, anche se ormai il solo suono della parola applet fa sorridere gli sviluppatori di tutto il mondo — almeno quelli di una certa età — anche lì in tanti ci siamo passati.

Poi si capì che occorreva concentrarsi sui componenti riusabili lato server, ma che forse le prime versioni di Java erano un tantino troppo ingegnerizzate, al punto che fu tutta una nascita e un fiorire di framework in grado di gestire diversi aspetti della programmazione: l’affermazione di Spring, ad esempio, rappresentò una rivelazione e una liberazione per molte persone che fino ad allora avevano dovuto studiare corposi tomi su EJB e affini…

Ma, mentre queste ulteriori novità si affermavano — e siamo già a quasi dieci anni dalla nascita di Java — molti di coloro che avevano fatto i “programmatori”, visto che queta parola si usava inizialmente più di “sviluppatori”, erano già alle prese con qualcosa a maggiore livello di astrazione: le architetture dei sistemi. A differenza di quello che sembrava inizialmente, il “rivoluzionario” linguaggio Java si era evoluto in una piattaforma completa e robusta, perfetta per applicazioni di tipo enterprise. Le architetture di integrazione, SOA e quant’altro divennero i principali problemi con cui confrontarsi per coloro che, ancora solo dieci anni prima, avevano provato quasi un senso di esaltazione al primo “Hello, world!”.

E dieci anni dopo ancora, alcune di quelle persone, insieme a schiere di giovani ed entusiasti professionisti, hanno nuovamente “cambiato mestiere” e si occupano di diffondere nuove metodologie per gestire i processi di sviluppo e non solo.

Java: una storia esemplare

Quanto raccontato a proposito di Java ci fa vedere come in venti anni si sia assistito a un’evoluzione che ha portato lontano rispetto al punto da cui si era partiti. Un’evoluzione che molti di coloro che hanno inizialmente partecipato a quel momento di rinnovamento tecnologico non avrebbero potuto prevedere. E se questo tipo di cambiamento è percepibile in una materia intrinsecamente più controllabile come i linguaggi di programmazione, figuriamoci quanto più marcatamente esso possa interessare discipline per loro natura più “fluide” come quelle che hanno a che fare con la gestione dei processi e il lavoro collaborativo delle persone. È in questo aspetto che c’è un parallelismo con l’Agilità.

L’Agile non esiste

Titolo volutamente provocatorio, ma che si spiega facilmente. Non esiste una “implementazione” ufficiale di tutto ciò che è agile. Esistono valori, principi, pratiche, approccio e mentalità agili, esistono metodologie codificate che a questi valori e principi si rifanno, come è per XP e Scrum che peraltro nascono prima del Manifesto Agile. Ma non si può dire che esista “Agile” come esiste, ad esempio, il linguaggio C++ che è quel linguaggio lì, con le sue caratteristiche e la sua sintassi.

All’inizio era XP

Di questa evoluzione di Agile si è cominciato a prendere coscienza da alcuni anni, con la progressiva diffusione dell’Agilità a livello sempre più mainstream, specie nella realtà produttiva statunitense. Quando fu pubblicato il Manifesto per lo sviluppo agile di software, però, molti di coloro che lo lessero al tempo finirono più per essere colpiti dai nomi dei firmatari, che non dalla reale portata delle quattro affermazioni e dei dodici principi. Ci colpiva che ci fossero gli inventori dell’eXtreme Programming (Kent Beck, Ward Cunningham e Ron Jeffries) perché questa metodologia era molto valida e applicabile nella realtà tecnologica dello sviluppo.

Anche l’affermazione di Scrum, nella cui guida più aggiornata [2] è fatto comunque esplicito riferimento ai valori, è stato inizialmente dovuto al fatto che la metodologia era strutturata bene, funzionava e consentiva a gruppi di lavoro disorganizzati e poco focalizzati di diventare ottimi team di sviluppo.

Ampliare lo sguardo

Ma non appena le metodologie agili hanno cominciato a diffondersi, a poco a poco si è andato stratificando un corpus di conoscenze, riflessioni, pratiche collaterali e così via che non si limitavano più solo strettamente alle metodologie. I tecnologi che inizialmente si sono occupati di Agile hanno dovuto “riqualificarsi” ricercando e approfondendo tematiche che esulavano dagli aspetti tecnologici e architetturali.

Un team che oggi partecipi a un corso / workshop per imparare a lavorare con Scrum, ad esempio, riceve una serie di input, di stimoli, di competenze molto più grande e ad ampio spettro rispetto a chi ha cominciato farlo anche solo cinque anni fa.

L’Agilità ha ampliato il suo sguardo anche perché ha cominciato a uscire dall’ambito ristretto dello sviluppo software e si è dovuta confrontare con prodotti, mentalità, strutture diversificate: in certi casi si è trattato proprio di lavorare in settori produttivi il cui core business non è quello di rilasciare software, ma in molti altri casi si è trattato di una “scalata” a dipartimenti aziendali che andavano oltre i team di sviluppo del settore IT.

Dalle “metodologie leggere” ai modelli organizzativi

La tendenza attuale cui assistiamo è l’aspirazione e il tentativo di portare un approccio agile alle attività dell’intera organizzazione aziendale: occorre che una cultura basata su valori, principi e pratiche dell’agilità si propaghi dai team di sviluppo al management e al business delle aziende.

Questa sfida comporta da un lato una proposta di Agile sempre più ampliata — e una conseguente maggiore e più variegata competenza dei professionisti che questa proposta devono portare nelle aziende — dall’altro un’accettazione da parte delle organizzazioni che Agile non è solo “quella roba lì informale adatta per gli sviluppatori di software” ma può diventare il cardine di una cultura aziendale contemporanea e innovativa, in grado di rispondere al cambiamento.

Molte indicazioni dell’evoluzione di Agile dal focus sulle metodologie per lavorare in gruppo in modo efficace ed efficiente a modello organizzativo che investe tutta la struttura aziendale ci vengono sia dai numerosi articoli e libri al proposito, sia dalla centralità del tema della scalabilità di agile a livello di grandi aziende: l’affermazione dei framework per scalare Agile (LeSS, SAFe, Disciplined Agile 2.x e così via) è un’ulteriore elemento in tal senso ed è un tema caldo già da qualche tempo. Tra gli articoli più “lineari” e semplici, ma che hanno il merito di dare il quadro attuale di questo cambiamento, ce ne è uno [3] scritto da Jeff Gothelf a inizio di questo anno in cui si affrontano i punti chiave per allargare l’agilità all’intera organizzazione aziendale.

Agile per tutta l’organizzazione

Nell’articolo appena citato, si prende atto della trasformazione che abbiamo descritto nei paragrafi precedenti e si enumerano una serie di azioni da adottare per “portare Agile in tutta l’azienda”. Sempre più aziende adottano pratiche agili per i loro dipartimenti di sviluppo software, e Scrum è ormai sempre più diffuso e conosciuto; DevOps — che è un insieme di tecnologie e pratiche, ma che si basa su concetti che possiamo sicuramente definire come agili — si sta affermando in modo pervasivo. Tutto ciò va molto bene, ma non può rimanere confinato al ramo IT.

“L’Agile è ottimo, finché riguarda solo sviluppo e rilascio software” sembra essere diventato il mantra di molti manager. È comunque un passo avanti rispetto a quando si pensava che Scrum fosse una perdita di tempo e denaro… ma non basta.

Ma, continua l’articolo [3], occorre alzare il livello puntando a una gestione delle risorse umane che sia agile (Agile HR) o a una gestione finanziaria basata sul miglioramento continuo (kaizen). Solo questo approccio a 360° può consentire di tenere testa a un mercato che è sempre più rapido, pieno di turbolenze e che richiede una capacità di decisione rapida e adattativa.

Agile HR

Uno degli elementi chiave in tutto questo processo di transizione è individuato nella gestione agile delle Human Resource, termine peraltro ben poco agile, poiché sarebbe il caso di parlare di persone, talenti, carriere, piuttosto che di “risorse”. Ma, per comprensibilità, continueremo a utilizzare il termine HR.

Probabilmente è proprio l’ambito HR quello in cui è necessaria la rivoluzione più significativa in senso agile per consentire a una azienda di funzionare al meglio, individuare e raggiungere i propri obiettivi di business, diventare un “organismo” resiliente o, come si dice adesso, antifragile.

A fronte del sistema tradizionale che ha individuato e selezionato il personale con un meccanismo di “incasellamento”, in cui persone dotate di certe competenze standardizzate andavano a ricoprire posti vacanti in cui erano necessarie — o meglio, si presupponeva che fossero necessarie — quelle specifiche competenze, una gestione dell’HR in senso agile propone qualcosa di decisamente diverso che meglio si adatta a creare un’organizzazione più funzionale.

Ogni persona possiede talenti, aree di miglioramento e ha delle necessità da soddisfare: questi elementi vanno tenuti in considerazione perché alla crescita personale e professionale dei lavoratori corrisponde un miglioramento del gruppo, e una positiva evoluzione organizzativa. Lo stile tradizionale di “reclutamento” del personale, invece, finisce per indebolire l’organismo aziendale, dal momento che approfondisce la specializzazione e anche la compartimentalizzazione, tutti aspetti che cozzano con una transizione in senso agile.

Certe caratteristiche che, almeno in passato, potevano essere viste quasi con sospetto dai responsabili HR nella fase di reclutamento vanno invece valorizzate con attenzione in un processo di Agile HR: la creatività, la curiosità, un sano anticonformismo, uno spiccato eclettismo sono tutte caratteristiche che contribuiscono a creare organizzazioni aziendali più reattive e capaci di affrontare un futuro che, di fatto… non possiamo conoscere.

Di pari passo al recruitment, un maturo processo di Agile HR deve porsi il problema di come trattenere in azienda i talenti più “speciali”: è certamente anche questione di denaro, perché se non si è pagati adeguatamente si è più tentati di andarsene a cercare “maggior fortuna” altrove. Ma è soprattutto questione di molto altro: gli incentivi non possono essere solo economici visto che la motivazione nasce anzitutto dalla consapevolezza di essere parte di un progetto più grande, di realizzare qualcosa di significativo, di continuare ad apprendere e migliorarsi. E questo vale ancor più per il tipo di persona di cui stiamo appunto parlando.

Finanziamento delle attività

Un altro aspetto cruciale per una adozione di Agile in senso globale nell’azienda, è rappresentato dal finanziamento dei progetti. Tradizionalmente, chi paga chiede: “OK, io vi alloco queste risorse finanziarie per questo periodo di tempo. Ma che cosa mi garantite in cambio alla fine dell’anno?”. Ora, chiunque

1. abbia lavorato a qualche progetto relativamente grande e complesso,
2. sia sano di mente,
3. sia intellettualmente onesto,

dovrebbe rispondere in modo tranquillo: “Precisamente… non lo sappiamo”.

Al di là delle battute, il problema è proprio questo: anche nel budgeting occorre adottare una prospettiva che non guardi al prodotto finale completo, ma si concentri su rilasci incrementali, ravvicinati e valutabili.

Qualche azienda ha adottato il paradigma della startup interna: sono finanziati per periodi relativamente brevi dei progetti che mirano a risolvere un problema di business dell’azienda. A intervalli regolari vengono valutati risultati e sviluppi sulla base di quello che i diversi team hanno realizzato. Questo impegna chi è finanziato a lavorare in modo cadenzato e orientato agli obiettivi, grantendo però al progetto le risorse necessarie per quell’iterazione. Al tempo stesso, in questo modo si evita di finanziare ad libitum attività che non creano valore e non rispondono a reali esigenze di business dell’azienda. E in questo modo si può anche reagire in maniera più veloce a eventuali “rovesci” del mercato che non dipendano dall’azienda.

Gerarchie e decisioni

Tema annoso, ma cruciale anche questo. Per anni — anzi, per secoli — siamo stati abituati a decisioni prese attraverso svariati livelli di gerarchia. Non è solo questione di “autocrazia” o decisioni a senso unico top-down. Anche laddove il livello decisionale più elevato decida di ascoltare sinceramente le osservazioni che arrivano dal livello più basso, i diversi passaggi che questo processo comporta rischiano di far prendere le decisioni

• sulla base di informazioni “vecchie” e non tarate sulla realtà del momento, perché i vari passaggi in alto e in basso richiedono tempi non compatibili con la rapidità che sarebbe richiesta;
• sulla base di informazioni “distorte” non perché — si spera — ci sia qualche “sabotatore” lungo la “catena di comando”, ma semplicemente perché i diversi passaggi di livello gerarchico finiscono per alterare/modificare certi significati, certi dettagli importanti, certe attribuzioni di valore ai diversi elementi.

In un’ottica agile, occorre che le decisioni siano prese quanto più in prossimità del feedback da parte degli utenti/clienti e quanto più possibile a livello del team che di fatto realizza il prodotto. Sia chiaro che questo può anche comportare al team di fare errori tattici, e ciò significa pure che l’organizzazione deve avere una capacità di assorbire le conseguenze di certi errori, imparando rapidamente da essi e riconducendoli a una più ampia strategia, questa sì da sviluppare a livelli più elevati della gerarchia.

Kanban reloaded

A chiudere questa riflessione, lo spunto derivante da un articolo di David Anderson [4], il fondatore del metodo Kanban applicato allo sviluppo software. Già che ci siamo, va detto che, a partire dalla seconda metà dello scorso decennio, probabilmente una delle accelerazioni più potenti all’evoluzione dell’Agilità in senso lato l’ha dato propriol’introduzione di tematiche provenienti da un ambito come quello della Lean Production di derivazione Toyota, nate in ambito automotive ben diverso da quello dello sviluppo del software.

Kanban si è fin da subito presentato come qualcosa di meno strutturato rispetto a Scrum e più adatto a gestire flussi di lavoro preesistenti, meglio se portati avanti da team piuttosto autodisciplinati. Una delle differenze che si notano subito, al di là proprio dell’approccio concettuale, è che nelle pratiche di derivazione lean non ci sono ruoli, o perlomeno non c’è la necessità di individuare delle persone che assumano esplicitamente un determinato nuovo ruolo all’interno del processo.

Nell’articolo citato invece, vengono individuati “ufficialmente” due ruoli ben precisi: il Service Delivery Manager e il Service Request Manager. Il primo, a dire il vero, è qualcosa di sempre esistito e chiamato spesso in modo informale flow manager o flow master in maniera speculare allo Scrum Master.

Il Service Request Manager è una figura di “Product Owner” che assume la responsabilità delle politiche di valutazione del rischio, di calendarizzazione, di sequenziazione e di selezione, posizionandosi al di sopra del flusso di lavoro.

Al di là della brutale semplificazione (rimandiamo all’articolo [4] per l’approfondmento), tutto questo per dire che… le cose cambiano e occorre adattare le pratiche a un mondo mutevole, individuando elementi emergenti e sapendo che tutto… continuerà a cambiare.

Conclusioni

In questi ultimi anni stiamo assistendo a una innegabile evoluzione dell’Agilità, in cui sempre più diversificate sono le competenze che concorrono a creare un quadro completo di ciò che consideriamo agile.

Il focus si sta spostando sempre più dal lavoro efficace ed efficiente nei piccoli team (per il quale abbiamo ormai metodologie e pratiche verificate da anni di adozione) alla risoluzione dei problemi legati alla scalabilità (per la quale si vanno affermando framework come SAFe, LeSS e DA 2.x). Il passo ulteriore — difficile ma fondamentale — è quello di portare la cultura Lean/Agile a tutti i livelli dell’organizzazione aziendale: non è un processo scontato, né tantomeno un’adozione facile ma, se si concretizzerà, questa potrà essere considerata una significativa rivoluzione; del resto una delle affermazioni del Manifesto Agile è proprio “Rispondere al cambiamento più che seguire un piano”.