La cultura manageriale dell’era contemporanea è erede di una visione “tayloristica”, secondo cui l’ottimizzazione operativa è conseguibile attraverso la specifica dettagliata di processi standard, la specializzazione del lavoro, il tracciamento formale delle transazioni, la misurazione “scientifica” della loro prestazione.
Con un ruolo centrale del manager, naturalmente, che controlla gli indicatori di processo e imposta le azioni correttive necessarie.

Questo vale anche per le direzioni ICT delle aziende, che nel tempo si sono mosse (e continuano a muoversi) verso livelli di strutturazione operativa crescenti. L’adozione di standard e best practice (es: ITIL, COBIT), gli investimenti in strumenti informatici sofisticati a supporto dei processi operativi e di governo, l’introduzione di modelli di gestione quantitativa (es: project e portfolio dashboards), sono iniziative comuni a molti ICT, e vanno tutte in questa direzione: più struttura, più regole, maggiori capacità di pianificazione e controllo.

Negli ultimi anni si è sviluppata però anche una tendenza contraria: spinte dalla necessità di essere rapide, esplorative, innovative nelle proprie strategie, le aziende hanno iniziato a richiedere alle proprie funzioni ICT velocità e flessibilità crescenti, in contesti di elevata variabilità, incognita ed incertezza del requisito. Tutti elementi poco compatibili con un’operatività strutturata: quando obiettivi, input e output cambiano continuamente, e le attività sono sempre nuove e diverse, il concetto stesso di processo smette di essere applicabile.
In questa situazione la struttura diventa rapidamente vincolo, disturbo, onere improduttivo, perché non riflette più la natura del compito per cui è stata progettata ed ottimizzata.

Le discipline Agile danno una riposta a questo problema, proponendo un approccio che riduce il livello di struttura, a favore di una valorizzazione delle capacità dell’individuo e del team di operare in modo responsabile, adattivo, pragmatico, creativo.

Nell’Agile, le gerarchie ed i ruoli dell’organizzazione funzionale si disarticolano nel team autonomo, che ripartisce lavoro e responsabilità al suo interno, secondo opportunità, variando configurazione e micro-ottimizzando in modo continuo.
I benefici della specializzazione sono sostituiti dai vantaggi che offrono figure esperte, multifunzionali, capaci di seguire il ciclo di vita della soluzione in tutte le sue fasi, senza tempi morti. Risorse sempre sature, adatte a svolgere lavori diversi, secondo le esigenze nel momento.
Il processo standard è sostituito da approcci operativi che il team configura dinamicamente in funzione dell’obiettivo e della contingenza, scegliendo di volta in volta gli strumenti e le procedure più appropriate. Il manager è sostituito dalla responsabilità distribuita del team, che trova coesione decisionale e motivazione a perseguire gli obiettivi dell’azienda, nella comunanza di interessi e nella coscienza della mutua interdipendenza.
La documentazione? L’Agile non elimina la necessità di redigere documenti, ma consente di ridurre drasticamente la documentazione finalizzata a supportare l’operatività in sé, eliminando tutto quello che è sostituibile da comunicazione diretta, informale, rendendo quest’ultima efficace ed affidabile grazie alla ridotta dimensione del team, alla continuità di relazione ed alla prossimità fisica degli operatori.

Più struttura o meno struttura? Esiste una contraddizione di fondo nelle strategie con cui l’ICT deve evolvere?

Nessuna contraddizione: l’esigenza di differenziare nei fondamentali il proprio funzionamento, è al cuore del concetto di “bimodalità”, e delinea scenari in cui operatività fondamentalmente diverse (la fabbrica e la strart-up, per intendersi) devono convivere all’interno della stessa funzione ICT, per poter servire il business in tutte le sue esigenze.

Il rischio maggiore a cui sono esposti i CIO nel guidare questo cambiamento, è proprio sottovalutare la misura di questa diversità, pensando ad esempio:

• che l’Agile sia una metodologia, implementabile con attività di formazione e con modifiche organizzative minori
• che la scelta di adottare l’Agile possa essere “trasparente” rispetto al business, e garantire gli stessi livelli di qualità, rischio, sicurezza
• che l’Agile sia implementabile in modo parziale, scegliendone gli aspetti che appaiono più facili da introdurre e gestire.

I principi Agile sono noti soprattutto per la diffusione di alcune metodologie di gestione dei progetti di sviluppo software, ma la piena adozione dell’Agile implica in realtà impatti profondi sull’organizzazione e sulla cultura manageriale, che trascendono gli aspetti di metodo. Le dinamiche di team, che garantiscono l’elevata prestazione al gruppo di lavoro Agile, non si sviluppano se il team non è realmente autonomo e responsabilizzato. L’autonomia richiede effettiva delega decisionale, e la responsabilizzazione richiede leve di incentivazione (e disincentivazione) forti. Spinto dall’obiettivo del risultato, è il team stesso che ricerca e seleziona “sul mercato” le risorse più adatte, ed “espelle” i membri che non operano nel comune interesse del team o con il livello di prestazione atteso (nessuno può farlo meglio del team stesso). Ma queste dinamiche, ed i livelli di autonomia che richiedono, non sono compatibili con gli inquadramenti contrattuali e le scelte di sourcing esistenti in molti ICT. E gli impatti sulla cultura manageriale? È evidente la difficoltà, per i manager, a supportare un modello che distribuisce (il loro) potere nell’organizzazione, e che cambia il concetto stesso di management, da “capo” a coach, moderatore, facilitatore.

L’Agile implica una diversa esposizione ai rischi, una diversa gestione della qualità. Parte della sua velocità deriva dalla confluenza nelle responsabilità del team di molte delle attività di processi di governo e supporto (change, qualità, sicurezza). La delega decisionale al team e l’affidamento a responsabilità e professionalità individuali, comportano inevitabilmente una componente di rischio residuo maggiore. Rapidità ed incrementalità possono implicare compromessi in qualità e sicurezza. Svantaggi in parte moderati (ma solo in parte) dalla velocità dell’iterazione progettuale, che è in grado di correggere rapidamente problemi ed errori. E quindi corretto che questi requisiti vengano messi in discussione e diventino essi stessi oggetto di una modulazione attenta dei parametri di costo/beneficio/rischio. L’Agile non è quindi un approccio adatto a tutti i progetti, ma richiede una gestione del portafoglio di domanda particolarmente matura, in cui il business è partecipe della scelta di una modalità di delivery differente, con tutte le sue implicazioni.

A fronte di queste diversità di modello e degli impatti che ne derivano, alcuni CIO rispondono con una comprensibile prudenza, giustamente consci di dover garantire la sostenibilità di un percorso di cambiamento.
Prudenza che si traduce frequentemente nella scelta di partire con gestioni Agile implementate solo parzialmente, o di cercare soluzioni ibride che si raccordino meglio con l’organizzazione e la cultura esistente. Soluzioni di compromesso spesso supportate anche dal consiglio di consulenti interessati a rendere la propria offerta rassicurante, appetibile.

Ecco l’ultimo punto di attenzione. Non ci permettiamo di affermare che sia sbagliato procedere incrementalmente, con prudenza; abbiamo però visto diverse iniziative Agile deludere le aspettative, capendo poi che in realtà esse replicavano in superficie soltanto alcune delle “liturgie” dell’Agile, senza implementarne realmente i principi. Adottare stand-up meeting mattutini e tecniche di visual management può essere produttivo, ma non può portare a risultati significativi, se sganciati dalle vere scelte di modello.

È la comprensione delle logiche di fondo dell’Agile e dei meccanismi da cui derivano i suoi maggiori benefici, a farci diffidare dal compromesso. Ciò di cui siamo sicuri è che può offrire vantaggi importanti, ma che, come ogni altro modello operativo, deve essere implementato in modo coerente e consistente, per poter funzionare.

Per guidare la trasformazione verso il bimodale, ai CIO è richiesta una visione davvero lucida dell’assetto futuro della propria organizzazione, e molta determinazione.
E, osiamo dire, anche una certa dose di coraggio.