Inspearit
image

Agile scaling e de-scaling

“Vogliamo fare Agile@Scale e stiamo adottando il framework X o Y”. A volte è questo che mi sento dire dai miei clienti quando si parla di agile transformation.

Aumento del numero di team e persone coinvolte, definizione e introduzione di nuovi ruoli nonché di processi per supportare l’adozione del nuovo approccio, in breve, ci si concentra sul cosiddetto scaling aumentando struttura e complessità per far fronte alle problematiche emergenti.

Il Martello di Maslow

Questo approccio credo sia vittima di una sorta di “bias di conferma” ben riassunto dal cosiddetto “Martello di Maslow” che il celebre psicologo americano Abraham Maslow definisce scrivendo: ”Suppongo che, se l’unico strumento che hai sia un martello, avrai la tentazione di trattare tutto come se fosse un chiodo.”.

Un’organizzazione tradizionale è basata su una struttura gerarchica, command&control e incentrata sui processi, tutti elementi essenziali alla definizione del funzionamento dell’organizzazione come “macchina”. In tale contesto il ventaglio di soluzioni possibili deriva da interventi che tendono a spostare i punti di controllo piuttosto che ad aggiungere struttura e complessità:

– Se abbiamo un problema di qualità, creiamo un quality manager e la preoccupazione se ne andrà… per il momento;

– Se non riusciamo a consegnare un prodotto con il team che abbiamo, aggiungiamo un altro team;

– Se il mio ufficio legale non è abbastanza veloce nel rispondere alle richieste degli agile team, creiamo un processo ad-hoc per queste casistiche, e così via.

Questo ovviamente porta in tutt’altra direzione rispetto alla possibilità di liberare la cultura agile e la velocità che può portare.

Cosa accadrebbe invece ponendoci nella prospettiva della sottrazione di complessità cioè del de-scaling organizzativo?

Cos’è il de-scaling

Fare de-scaling significa concentrarsi sulla riduzione della complessità derivante dal numero dei ruoli, le strutture organizzative, le dipendenze, le posizioni di management, i siti ed eventualmente il numero di persone, anche se su quest’ultimo aspetto torneremo nel dettaglio in seguito, viste le importanti implicazioni umane di sicurezza psicologica ad esso collegate.

Su questa idea punta in modo forte il framework di agile scaling creato da Craig Larman e Bas Vodde chiamato LeSS (Large Scaled Scrum). In modo apparentemente paradossale LeSS viene definito come il framework che permette di fare scaling con Scrum in modo da raggiungere il descaling organizzativo:

LeSS is about scaling up Scrum itself in order to achieve organizational descaling.

Ken Schwaber, uno dei due creatori di Scrum, sottolinea come una caratteristica essenziale di Scrum sia anzitutto quella di far emergere in modo chiaro i problemi e gli impedimenti del sistema all’interno del quale si muove un singolo team permettendone via via l’isolamento e la risoluzione. In LeSS questo aspetto viene amplificato andando ad abbracciare più parti dell’organizzazione e proponendo un approccio al cambiamento per sottrazione, atteggiamento ben espresso dal motto:

Do more with LeSS

De-scaling legato al prodotto

Per operare delle scelte realmente efficaci deve essere anzitutto chiaro l’obiettivo del descaling, vale a dire di creare quella flessibilità organizzativa che permetta di focalizzarsi sugli obiettivi più importanti visti dalla prospettiva del cliente al livello di prodotti e servizi e farlo continuamente man mano che emergono nuove informazioni dai feedback loop. Ecco che allora è necessario snellire per esempio strutture e processi di portfolio e program management che si basano su una rigida associazione, di lungo periodo, tra goal e investimenti e la relativa gestione della pianificazione.

Un motivo per cui nel caso di una agile transformation tendono a proliferare strutture, processi e ruoli è un eccessivo spezzettamento dei value stream in tanti piccoli prodotti o peggio ancora progetti a cui vengono assegnati i diversi agile team. In questo scenario frammentato infatti nasce la necessità del portfolio management, per la messa in priorità dei diversi prodotti/progetti, del project/program management per il coordinamento dei diversi team, il tutto all’interno di un involucro creato ad-hoc, il PMO.

E se invece avessimo un unico Product Backlog e un solo Product Owner per un intero prodotto o piattaforma di servizi alla clientela che può cambiare direzione e assegnare nuovi goal con un basso costo del cambiamento? Tale possibilità diverrebbe reale avendo team realmente autonomi e cross-funzionali senza confini fissi relativi a progetti e programmi e che lavorerebbero accrescendo continuamente la propria capacità e responsabilità di prendersi cura di parte o tutto un value stream.

L’agile team diverrebbe l’unità elementare di delivery del valore per il cliente e una rete di team presidierebbe end-to-end l’intero value stream, ecco che allora possono venire meno strutture separate dedicate ad aspetti quali ad esempio l’analisi, l’architettura, la UX o il quality assurance. Ecco che allora il de-scaling organizzativo diverrebbe possibile.

A questo si aggiunge il tema, che qui non possiamo che sfiorare vista la sua vastità, del de-scaling dell’architettura applicativa che deve andare di pari passo con le scelte di cui sopra, anzi essere lo specchio di un approccio consapevole delle influenze potenzialmente nefaste della struttura organizzativa sull’architettura applicativa (Legge di Conway).

De-scaling tramite descaling: una questione di leadership

La parola descaling tradotta in italiano significa decalcificazione e l’agile coach Olaf Lewitz ci gioca, in alcuni suoi articoli e interviste, confrontando ciò che avviene nelle organizzazioni in termini di rapporti tra le persone a ciò che avviene ad una macchina del caffè quando non è manutenuta correttamente e ha bisogno appunto di un’opera di decalcificazione. La comunicazione non fluisce efficacemente a causa di una struttura stratificata command&control che premia la politica più che l’onestà e l’apertura al cambiamento.

Secondo Lewitz la maggiore resistenza nei confronti del cambiamento deriva da una mancanza di onestà nella comunicazione dipendente dalla necessità di rispondere alle aspettative della macchina organizzativa. L’esempio che fa è paradigmatico: “Qualcuno nel team dice che lo stato di un progetto è rosso e il project manager dice oh, potremmo essere in grado di sistemarlo, e quindi è giallo e poi il capo dipartimento dice oh, no, è verde, giusto, le cose migliorano sempre, quindi siamo ottimisti. Quindi, abbiamo questa forte cultura di dire bugie mentre l’agile funziona quando le persone hanno una comunicazione onesta.

Ecco che allora il descaling può seguire anche un’altra strada, quella del confronto e della fiducia nel team. Continua Lewitz:”Quando le persone si fidano hanno più scelte, quindi il primo passo è fidarsi un po’, il secondo passo è invitare le persone a fare delle scelte e poi si può lasciare andare un po’ della propria struttura. Quindi se le persone sentono di essere invitate a fare una scelta invece di essere costrette a cambiare, il che porta alla resistenza, come abbiamo sperimentato molte volte, allora sono in grado di scoprire qualcosa di nuovo che ha bisogno di meno struttura e meno struttura porta di nuovo a più fiducia, quindi si ha un circolo virtuoso.”.

Il compito di un leader, in un contesto di cambiamento, diviene quello di creare le condizioni affinché il de-scaling sia possibile soprattutto grazie alla delega e alla corrispondente assunzione di responsabilità da parte delle persone. Questo non può in alcun modo avvenire senza investire una quota importante dei propri sforzi nella costruzione di un ambiente psicologicamente sicuro.

Sicurezza psicologica

Arriviamo qui ad un punto molto critico poiché la sicurezza psicologica è la vera chiave di volta su cui costruire le migliori condizioni per il cambiamento che, come abbiamo visto, nel caso della agile transformation significa soprattutto de-scaling organizzativo.

Resta inteso quindi che tale precondizione non possa sussistere nel momento in cui il cambiamento metta a rischio la sicurezza lavorativa delle persone.

De-scaling significa ridurre la complessità ed aiutare la flessibilità organizzativa il che si può tradurre in maggiore coinvolgimento e supporto nell’aiutare tutti a trovare il miglior modo di dare valore al cliente finale e quindi all’organizzazione. Ci potranno essere minori ruoli e livelli di management, un minor numero di uffici specializzati, ma questo deve essenzialmente significare avere un maggior numero di persone dedicate a soddisfare il cliente finale anziché focalizzate sul controllo di strutture e processi non necessari.

Conclusioni

Il primo obiettivo di una agile transformation è lo sviluppo della cosiddetta business agility, la capacità cioè di adattarsi in modo rapido, continuo e sistematico al mercato per guadagnare e mantenere un vantaggio competitivo. Tale adattamento evolutivo è strettamente legato ad una cultura agile che cozza con il modo in cui le organizzazioni tradizionali affrontano il cambiamento poiché questo tende ad aumentare struttura e complessità anziché diminuirla.

Un cambio di passo decisivo lo si attiene allora lavorando per sottrazione, facendo

more with less,

adottando la prospettiva del de-scaling organizzativo tramite una diversa visione del prodotto e del servizio al cliente piuttosto che del modo in cui i leader debbano lavorare soprattutto per creare le condizioni affinché individui e team si coinvolgano attivamente e collaborino con fiducia e senso di responsabilità.

L’adozione del mindset agile ed il de-scaling organizzativo aprono numerose opzioni che le organizzazioni tradizionali molto spesso non hanno a causa della rigidità della propria struttura e ogni manager ha quindi la possibilità e aggiungerei il dovere di cogliere queste ulteriori opportunità di valorizzare al meglio tutti i propri collaboratori. Si tratta della contrapposizione “do-agile Vs be-agile” che ci pone continuamente davanti la sfida di non applicare ricette preconfezionate ottenendo così orde di team con la faccia pitturata da fake-Scrum, bensì di fare propri principi e valori derivanti dal manifesto agile e imparare, un esperimento alla volta, qual è il modo migliore per creare più valore (per il cliente) con meno (strutture, ruoli, processi, ecc.) in sintesi doing more with less.

La selezione di corsi nella nostra pagina dedicata ad Agile People, mira a generare esperienza e competenza per supportare chi decide di voler diventare più agile.

RIFERIMENTI

Descaling Organizations with LeSS – by Viktor Grgić

De-Scaling Your Organization and Using Temenos – by Olaf Lewitz

How to Descale an Organization – by Savita Pahuja

Want to scale agile? Don’t. Descale the work first. Achieve big through small. – by Jonathan Smart

Pubblicato su 19/03/2021