Alcune frasi tipiche

Partiamo con una serie di affermazioni che, in forme più o meno simili e da parte di diversi ruoli nei dipartimenti, molti di noi avranno sicuramente ascoltato.

La mia divisione  XYZ si occupa di fare questa cosa, poi passo la palla alla divisione ABC che deve aggiungere la sua parte. Capita spesso che non ci capiamo e che quello che esce alla fine non va bene.

Tipicamente quando faccio la mia parte, da me va…

Abbiamo un problema perché le divisioni non si parlano.

Non sappiamo cosa succede quando il pezzo esce dalla nostra divisione e viene passato alle altre.

Come esperti verticali di ABC, veniamo spesso interpellati per fornire un contributo alla realizzazione del prodotto. Purtroppo il nostro contributo è solo puntuale perché gli altri proseguono poi senza interpellarci e quindi spesso va a finire che poi esce qualcosa di completamente differente da quanto ci aspettavamo.

Le varie unità organizzative lavorano su differenti componenti dello stesso prodotto/funzionalità e quindi abbiamo necessità di molta fatica per allineare i lavori, per produrre qualcosa in sincrono. Spesso però accade che le diverse componenti abbiano comunque delle diversità.

Vi suonano nuove? Oppure è qualcosa di familiare? Ecco, queste sono alcune delle frasi che, con i miei colleghi, sentiamo raccontare molto spesso durante la nostra attività di coaching agile nelle aziende.

Problemi di “comunicazione”?

Spesso l’analisi finale semplifica e sintetizza tutta la questione dicendo che si tratta di un problema di comunicazione. Attenzione però: in questi casi, non è quasi mai un problema di comunicazione; o, per dirla meglio, “avere un problema di comunicazione” non significa granché.

Infatti, queste dinamiche disfunzionali sono piuttosto legate a problemi di produzione, di valore prodotto, di qualità rilasciata, di attese e sprechi nel processo produttivo che sono spesso riconducibili allo stesso problema: la frammentazione o meglio l’organizzazione per aree funzionali.

Divisioni o dipartimenti

A partire dagli anni Cinquanta del secolo scorso, molte organizzazioni, all’interno di un percorso di crescita e complessità all’aumentare del volume della produzione, iniziarono a individuare aree funzionali simili , nel tentativo di mettere ordine e di razionalizzare o industrializzare il processo.

Per avvicinare risorse omologhe e gestirle in modo centralizzato, accomunare processi, standardizzare le procedure, nacquero aree funzionali (o reparti) che lavoravano su specifiche aree o fasi, passandosi poi il testimone: ufficio vendite, analisti, progettisti, costruzione, test, gestione della consegna, assistenza clienti post vendita, e cosi via.

Spesso questi reparti funzionali sono diventati delle vere e proprie “divisioni” aziendali — o linee di business — fino a trasformarsi quasi in aziende nelle aziende, a loro volta suddivise in reparti.

Un’organizzazione di questo tipo funziona bene quando il processo è ben compreso, stabile e modellato e non si prevedono variazioni, stravolgimenti, vale a dire quando ci si muove in un contesto tipicamente deterministico. Funziona bene quanto la fase A è chiara in termini di input e output: so quello che riceverò, e che funziona esattamente come mi aspetto, e devo produrre qualcosa esattamente definita, proprio come si aspetta che sia chi arriva dopo di me nel flusso produttivo. Il tutto poi si può assemblare e comporre dando vita a un tutto che funziona senza difetti, perché è corrispondente a quello che ci si aspettava. Le varie parti possono essere I componenti di una macchina, I layer applicativi di un software, le fasi di un processo o i capitoli di un libro.

Se ci ripenso, uno dei primi libri che ho contribuito a scrivere fu realizzato esattamente in questo modo: ogni capitolo parlava di un argomento specifico, le interazioni fra argomenti erano ridotte al minimo per non dover richiedere coordinamento o riferimenti incrociati fra capitoli. Fatta eccezione per una uniformazione redazionale e grafica, il lavoro fu svolto esattamente in modo asincrono, indipendente, autonomo.

I limiti dei dipartimenti

L’approccio per dipartimenti funziona meno bene in contesti di incertezza, dove non possiamo contare su un modello deterministico, dove non è possibili essere certi né del flusso sequenziale né degli input/output.

Il modello per divisioni mostra le sue limitazioni proprio in quei contesti in cui è difficile pianificare e controllare, dove dobbiamo continuamente cercare delle soluzioni nuove, dove serve un approccio iterativo e incrementale, dove non abbiamo un esperto a cui chiedere il modo migliore e già conosciuto per gestire la produzione ma dobbiamo lavorare in squadra per scoprire nuovi modi per fare le cose.

Questo è il contesto dove l’approccio agile fornisce quelle risposte che non possiamo avere altrimenti, dove Scrum con le sue iterazioni o Kanban con il suo scientifico pragmatismo orientato al processo provano a costruire un output che non è già del tutto chiaro al giorno zero di progetto.

Sempre più spesso le aziende organizzate per divisioni e reparti devono oggigiorno muoversi in contesti di incertezza dove si rende necessario un approccio sperimentale, iterativo e incrementale, basato sulla continua evoluzione e la collaborazione di persone organizzate in team. E le due cose spesso non vanno d’accordo.

La filosofia agile propone in tal senso di mettere intorno a un tavolo le persone direttamente coinvolte nel lavoro di sviluppo del prodotto; è importante avere tutte, o comunque le principali competenze necessarie per realizzare il prodotto finito.

In linea di principio la divisione in aree funzionali rappresenta un impedimento totale o un forte freno alla realizzazione di questo modello operativo.

Perché le divisioni sono un impedimento alla trasformazione agile

La “gestione” del problema dei silos è comunque sempre un costo organizzativo (mentale, economico, temporale) che può rallentare se non frenare il percorso di implementazione dell’agile. Per “aggredire” questo tema si vedono spesso strategie differenti ognuna con benefici e costi differenti.

“Fotografare” la situazione corrente: strategia K

Una prima implementazione “soft” è quella in cui si parte con la mappatura dei processi senza eseguire alcun intervento correttivo. Uno dei principi di Kanban parla proprio di rispetto: prima di portare qualsiasi tipo di correzione, fotografa la situazione.

Si parla di Value Stream Mapping o di installazione di un sistema  Kanban che metta in evidenza i colli di bottiglia, le attese, i passaggi di consegna, che in generale faccia apparire chiaro il modo in cui funzionano i processi e dove si possano trovare gli eventuali punti di miglioramento.

A questo punto si vedono azioni come “spostiamoci nella stessa stanza”, “creiamo un core team con le persone strettamente necessarie prese dai vari dipartimenti” oppure “quella fase, fatta dall’ufficio X, possiamo evitarla: la facciamo direttamente noi all’interno del team”. Il processo è sano se ogni esperimento — grande o piccolo che sia — porta a una riduzione delle attese, uno snellimento del processo, un aumento della qualità del prodotto finale. Chiameremo questa strategia K.

Modificare l’assetto attuale: strategia S

Un approccio differente parte invece dalla creazione di contesti che rompano lo status quo e mettano in funzione cellule autonome, crossfunzionali, in netta antitesi al modello verticale per silos. È il caso a cui assistiamo quando una grande azienda “installa” Scrum, creando team con persone prelevate dai vari reparti. Chiameremo questa strategia S.

Consapevolezza dei rischi

L’uso della tassonomia K e S è evidentemente una semplificazione rudimentale, che non tiene conto del fatto che anche in K ci sono dinamiche tipiche di S e viceversa, che K e S non sono separate in modo netto e definitivo. È quindi una semplificazione narrativa per facilitare la trattazione in questo articolo.

Lo scopo di questo articolo è però anzitutto raccontare alcuni degli effetti che una organizzazione per silos o reparti o divisioni si porta dietro e che possono frenare l’implementazione di principi e pratiche agile, indipendentemente dal fatto che si segua un approccio K o S.

Vediamo quindi rapidamente un elenco degli effetti dell’introduzione dell’Agilità in un contesto di divisioni verticali, condotto senza le dovute cautele o senza la cura necessaria.

Doppio lavoro

Le persone sono prelevate dalla propria “divisione” per lavorare nel team. A volte questo si traduce in doppio lavoro: dopo le ore nel team, ci sono mail, offerte, attività altri progetti da seguire. Questo comporta di dover rapidamente completare il proprio compito nel team perché il proprio capo che ti “ha prestato” al team Scrum reclama la tua presenza.

Vediamo spesso verificarsi questo antipattern nel caso degli SME (Special Matter Expert) come PO, analisti funzionali, sistemisti o simili. Accade per forza di cose quando si segue approccio S, ma per ovvi motivi anche con K.

Questo sintomo è riconducibile a una mancanza di supporto dal management che non crea le condizioni necessarie per sperimentare il nuovo approccio con serenità d’animo e tranquillità mentale.

Professioni distanti

Alcuni ruoli o divisioni sono culturalmente distanti dall’hot spot dove parte la trasformazione. Per esempio: inizia a essere sempre più condiviso il fatto che HR debba partecipare al processo di produzione agile, e non per nulla si sente oggi spesso parlare di Agile HR ossia di come Agile può aiutare HR e come HR può supportare la trasformazione agile.

Però restano purtroppo ancora molto distanti dal processo di produzione agile funzioni come procurement — in che modo ingaggiamo un cliente/fornitore in linea con la filosofia agile? — o il le attività svolte tipicamente dal “reparto vendite” o altri ancora.

Spesso questo significa che l’approccio S manca di un pezzo importante — “Potremmo avere una persona di provenienza sales o marketing nel team Scrum? Perché ci mancano informazioni importanti” — o che l’ approccio K si ferma nel processo di propagazione del nuovo mindset semplicemente perché non riesce a penetrare in un contesto distante da quello della produzione.

Mancanza di focus o di perseveranza

L’approccio K è certamente meno invadente e più rispettoso dell’organizzazione dato che non richiede un cambiamento radicale dal giorno zero. Questa strategia si basa su un processo di miglioramento continuo fatto di misurazione delle performance, esperimento, valutazione degli effetti e nuova misurazione. Misurare costa fatica, le risposte non si vedono immediatamente, gli esperimenti a volte non danno frutti. Spesso questo approccio si arena per mancanza di disciplina, di commitment o semplicemente di perseveranza.

La crescita è bloccata dall’alto

Se immaginassimo un grafico in cui riportare la crescita dell’organizzazione in termini di efficacia, efficienza, qualità e tempi di reazione, si noterebbe spesso un problema di blocco dall’alto. Sia seguendo un approccio K che S, a un certo momento i cambiamenti locali — per esempio all’interno del team o nel “vicinato” —richiederanno lo sblocco di altri vincoli, ossia il coinvolgimento di altri reparti.

Il tipico esempio è costituito dalle situazioni in cui diventerà necessario coinvolgere il ramo Operation che magari lavora alla vecchia maniera, o quello Audit che invece richiede controlli e verifiche delle quali non è chiaro il significato, ma che comunque si eseguono perché “si è sempre fatto così”.

In questo caso, è necessario un intervento dall’alto per evitare che ci si fermi o che dinamiche di altro tipo possano bloccare la crescita dal basso e la contaminazione verso altri reparti.

Conclusione

Quanto abbiamo visto è solo una piccola sintesi dei tipici problemi che una organizzazione fatta di divisioni verticali può incontrare quando si cerca di implementare un approccio organizzativo agile. Ricordiamoci sempre che essere agili — o come qualcuno dice erroneamente “fare agile” — non è un obiettivo, ma sempre uno strumento.

La sfida delle aziende oggigiorno è quello che abbiamo detto sopra, ossia muoversi in un contesto VUCA (Volatility, Uncertainty, Complexity, Ambiguity = “volatilità, incertezza, complessità e ambiguità”) dove stiamo imparando che le modalità e gli strumenti dell’approccio agile sono efficaci.