L’organization design crea team disfunzionali

L’organization design crea team disfunzionali

Noi agilisti, Agile Coach, Scrum Master, Agile Consultant, etc ci occupiamo di cambiamento, o meglio di trasformazione delle organizzazioni. Stimoliamo, in pratica, il disegno organizzativo – organization design –  spesso in maniera implicita o addirittura in modo inconsapevole e a volte con presupposti ingenui, se non fuorvianti.
Questo articolo intende portare un punto di vista su come i principi agili vadano presi con spirito critico, mancando il quale l’effetto sia spesso un disegno organizzativo disfunzionale, se non addirittura dannoso. E, come conseguenza, un cambiamento solo abbozzato nel migliore dei casi.

Porterò alcuni esempi di come tali principi ci portino fuori strada, di come dovremmo dimenticarcene e di come l’intera proposta “agile” sia carente in aspetti che ritengo essere, invece, fondamentali se vogliamo cambiare intere organizzazioni e cioè la capacità di “vedere” l’organizzazione e non solo di vedere l’Agile.

Indice

  1. Come va Agile?
  2. Qualche definizione di organization design
  3. Approcci “standard” definiti
  4. Approcci agili
  5. I modelli di execution
  6. I principi di riferimento, le differenze
  7. Di cosa (non) parla il Manifesto?
  8. I principi (alcuni) ed effetti collaterali
    1. Comunicazione faccia a faccia
    2. Team cross funzionali
  9. Conclusioni e riferimenti
  10. Riferimenti bibliografici

Come va Agile?

Gli addetti ai lavori conoscono i vari report sullo stato dell’agilità prodotti da digital.ai (8). Tali report raccontano di una crescente adozione di pratiche agili, soprattutto Scrum, nel mondo dello sviluppo software in particolare. Allo stesso tempo ci raccontano di alcune difficoltà nell’adozione dovute a mancanza di leadership, resistenza al cambiamento, supporto insufficiente da parte dei manager.

In pratica, è colpa di qualcun’altro.

Vorrei provare ad allargare la visuale con elementi che sono al di fuori della nostra bolla.
Il mondo accademico e della ricerca ha iniziato da tempo a sfornare articoli e studi su Agile, con una certa libertà, bisogna dirlo, nell’accomunare principi e pratiche. Agile è spesso associato a Scrum, che è il framework più diffuso. Studi e articoli rendono più scientifico quello di cui ci siamo accorti presto e cioè che Scrum non è neanche lontanamente sufficiente se si vuole lavorare al cambiamento di un’intera azienda.
Uno dei lavori che voglio segnalare ci racconta come “Il nostro studio di 5 anni … suggerisce che, contrariamente alle intenzioni, Agile (ma ci si riferisce a Scrum) può essere dannoso per l’apprendimento organizzativo … se la sua implementazione non tiene conto i bisogni dell’organizzazione per meccanismi formali e informali di integrazione ….” (1)

Leggendo lo studio non sono rimasto affatto sorpreso. Offro due considerazioni ( si tratta di cose che già sappiamo o che abbiamo intuito da tempo):

  1. Innanzitutto che c’è una sostanziale sovrapposizione tra Scrum e Agile (si veda anche il rapporto sullo stato dell’agilità).
  2. La seconda considerazione, magari ovvia agli addetti ai lavori, è che Scrum semplicemente non tratta temi di integrazione e coordinamento: la guida Scrum si riferisce a team di sviluppo autonomi e non a tematiche di cross team o meccanismi di integrazione.

La mancanza dell’approfondimento di tali temi in Scrum, e nel Manifesto, non li fa sparire. Ha l’effetto di rendere la posizione degli agilisti più ambigua rispetto a temi organizzativi. Tanto più, aggiungo, qualora si parli di Business Agility, ovvero dell’agilità portata fuori  dal mondo dello sviluppo software e lontano dal contesto di un team singolo, quindi all’interno di dinamiche di integrazione e processi organizzativi.
Scrum e Agile creano le domande per lo sviluppo organizzativo. Fatalmente, rispondere a tali domande equivale a occuparsi dei meccanismi di integrazione e dell’intera azienda: vuol dire occuparsi di design organizzativo, indipendentemente dal fatto che lo si faccia in maniera esplicita o meno.

Qualche definizione di organization design

Prima di inoltrarci in alcuni esempi, proverò a dare alcune definizioni di disegno organizzativo e ad illustrare il contesto nel quale il mondo Agile si trova ad operare su questo tema.
Quando si parla di disegno organizzativo, ci si riferisce ad una serie di principi e pratiche per “.. la creazione di strutture in grado di allineare ruoli, processi e relazioni agli obiettivi aziendali(2).
Si tratta quindi di principi e pratiche che servono a raggiungere gli obiettivi. Si tratta di una definizione molto concreta.

Aggiungo un punto di vista che ritengo interessante sul tema. Secondo Nicolay Worren: “However, organization design is much more than “boxology”.…..finding the right design often requires inventing a new solution to resolve a dilemma. And decisions …….. directly impact the jobs and careers of employees – and the ability of the firm to realize its strategic objectives.” (3)
Worren aggiunge un elemento di creatività e di unicità delle soluzioni. Se le aziende sono diverse, i loro obiettivi sono diversi e saranno diverse anche le soluzioni. La definizione di unicità e creatività delle soluzioni è, tra l’altro, qualcosa a cui noi agilisti siamo piuttosto affezionati.

Un ulteriore aspetto da sottolineare nella citazione è come il disegno organizzativo non sia un banale esercizio di “caselle” da creare e riempire. C’è senz’altro  questo aspetto, a cui però si aggiungono tecniche che hanno un impatto significativo sulla vita professionale delle persone, sulla loro crescita come elementi indispensabili al raggiungimento degli obiettivi di un’azienda. 

Per far questo è necessario comprendere che toccare un elemento dell’organizzazione (ad esempio l’assetto dei team) vuol dire considerarne molti altri, se si vuole aiutare l’azienda a raggiungere i propri obiettivi, e non è possibile lavorare su un aspetto in maniera totalmente indipendente. Su quali siano le relazioni da tener presente ci sono differenti punti di vista, diversi su aspetti di dettaglio ma non nell’approccio complessivo. La figura sotto evidenzia uno degli approcci complessivi al disegno organizzativo:

Rappresentazione degli ambiti dell'organization desgin: Strategy, People, Operations, Law

Gli ambiti del disegno organizzativo (3)


Lo schema di figura che, ricordo, è solo uno dei contributi originali al disegno organizzativo, ci porta naturalmente ad esplorarne rapidamente altri, nel prossimo paragrafo.

Approcci “standard” definiti

Il disegno organizzativo è nato con le organizzazioni complesse, a partire dagli anni 70 del secolo scorso, e ha visto una notevole produzione di modelli, schemi, framework di riferimento. Lo stato dell’arte oggi vede la presenza di una serie di best practices, tutte molto simili come approccio complessivo.

Approcci al disegno organizzativo, in senso orario: Il modello 7S di McKinsey, Il modello Start di Galbraith, il modello di congruenza di Nadler e Tushmans e il modello causale di Burke-Litwin

Approcci al disegno organizzativo, in senso orario: Il modello 7S di McKinsey, Il modello Start di Galbraith, il modello di congruenza di Nadler e Tushmans e il modello causale di Burke-Litwin (10)


Degli approcci in figura non si vuole dare una descrizione minuziosa in questo articolo e si rimanda alla bibliografia chiunque fosse interessato ad approfondire.
Vorrei porre l’attenzione sugli elementi in comune: considerare l’organizzazione attraverso modelli di relazione tra le varie componenti: Struttura, Strategia, Persone, Valori, etc. Indipendentemente dallo specifico framework, tutti raccontano il disegno organizzativo come un esercizio di bilanciamento tra le varie componenti di un’azienda.

L’organizzazione va quindi considerata, secondo l’approccio classico al disegno organizzativo, come un intero. Ogni azione di modifica dei processi e dei ruoli, influenza altri punti dell’organizzazione stessa. Non è quindi possibile procedere con ottiche locali. Anche questo è un concetto caro alla comunità agile.

Approcci agili

Anche il mondo Agile contiene riferimenti cui attinge ed utilizza quando si confronta con il cambiamento organizzativo. Sono riferimenti che, in maniera simile a quelli classici, tentano di approcciare il cambiamento di una organizzazione da un punto di vista globale. 

Nella figura alcuni approcci: Kotter, Management 3.0 di Appelo e l’approccio integrale di Spayd.

Nella figura alcuni approcci: Kotter, Management 3.0 di Appelo e l’approccio integrale di Spayd


Sono approcci che, graficamente, suggeriscono l’idea di una maggiore semplicità, in sintonia con la prospettiva iterativa e incrementale. L’approccio di Spayd è probabilmente quello più in linea con gli approcci classici nel senso che propone una visione dell’azienda come un insieme di elementi interconnessi rispetto ai quali è necessario trovare un bilanciamento.
Kotter e Appelo preferiscono un approccio più “implementativo” con i loro step da mettere a terra, monitorare e su cui iterare continuamente.

I modelli di execution

Un modello di riferimento non racconta granchè su come sia possibile implementare il cambiamento. Affinché sia possibile passare alla parte di execution è necessario avere dei riferimento metodologici più precisi.
L’approccio “standard”, tradizionale prevede modalità di execution altrettanto tradizionali con le classiche analisi dei gap organizzativi fino ai principi di disegno all’esecuzione etc. Molte fasi sequenziali di messa a terra. Qualunque consulente organizzativo ha, cioè, degli elementi molto chiari su quello che è necessario decidere e fare per avviare, e sostenere, il cambiamento. L’accento viene posto senz’altro sull’analisi dell’AS IS, sulla raccolta di informazioni, sulle domande organizzative e sul piano di migrazione.

L'approccio all’execution del cambiamento

Approccio all’execution del cambiamento (5)

L’approccio Agile all’execution di un cambio organizzativo risulta essere caratterizzato da tre aspetti:

  1. una certa ricchezza di framework relativi al modello “to be”
  2. una decisa focalizzazione sul concetto di team
  3. una scarsa propensione a concetti come un piano di adozione/migrazione (a parte il SAFe)

Il punto che determina una forte differenza tra gli approcci è il punto 2, il team.

Alcuni dei framework Agili più diffusi: LeSS, Scale, Spotify, SoS

Alcuni dei framework Agili più diffusi

L’unità atomica della struttura Agile, il team, viene configurato in modalità diverse in base ai framework. La centralità dei team rappresenta allo stesso tempo un elemento di novità (o lo ha rappresentato all’inizio degli anni 2000) ed un limite.
I framework mostrati evidenziano uno scarso interesse per il resto dell’organizzazione. Come se, grazie all’introduzione dei team non esistessero più strutture e processi aziendali: HR, Procurement, Operations etc.
I tentativi, ancora piuttosto incerti, di tener in conto dell’organizzazione rimandano a strutture degli anni 70 (il modello spotify è stato già descritto da Galbraith nel 1974 (9)) o, addirittura, ritengono che cambiare il modello di delivery non abbia impatto sul resto dell’organizzazione (è il caso di SAFe).

I principi di riferimento, le differenze

Ad un primo sguardo gli approcci Agili, sia pure con una notevole forza dirompente e coerenza sul concetto di team, scontano una visione un po’ parziale delle organizzazioni ed il loro funzionamento. Ci sono diverse ragioni: storia professionale degli agilisti, focalizzazione sulla scrittura e rilascio di codice etc. Ne aggiungo una: l’approccio e la considerazione del Manifesto nella comunità.

In qualche modo i principi classici di disegno organizzativo si riferiscono alla necessità di progettare  per privilegiare l’efficienza, la velocità, l’indipendenza di aree geografiche, la decentralizzazione delle decisioni e così via. Sono cioè principi orientati all’obiettivo. I principi Agile sono contenuti nel manifesto e sono stati utilizzati come un riferimento immutabile. Le stesse implementazioni, i framework, si rifanno più o meno direttamente ai principi del manifesto.

La differenza è sostanziale per due motivi principali: l’ambito di applicazione e la modalità di utilizzo dei principi.
Per quanto riguarda l’ambito, è evidente che il movimento agile nasce e si sviluppa nel mondo del software, vedremo meglio nel prossimo paragrafo. Il disegno organizzativo classico non fa distinzioni di industry o settore merceologico.
I principi di design organizzativo sono principi laici e dipendono dallo scopo.

Sulla modalità di utilizzo, i consulenti organizzativi li utilizzano in maniera strumentale. I principi agili vengono invece presi come dati, in una modalità di accettazione poco critica e portati in qualunque aspetto della vita delle organizzazioni, o della vita privata addirittura. Ho spesso sentito la frase “non è allineato al Manifesto” per giustificare scelte non sempre ragionevoli, come vedremo in alcuni esempi più avanti.

Di cosa (non) parla il manifesto?

Il manifesto parla, essenzialmente, di team e di sviluppo software. Prendiamo in considerazione l’undicesimo principio: “Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano.”.

Si tratta, naturalmente, di:

  • Architettura software, non architetture organizzative
  • Requisiti di un prodotto software, non requisiti di funzionamento di una organizzazione
  • Progettazione software, non progettazione organizzativa

Nè in questo principio, nè negli altri si parla dell’estensione del concetto all’intera organizzazione. L’estensione è una cosa che non ha senso, in ogni caso. Applicare un principio ad un contesto differente vuol dire elevare tale principio quasi a legge di natura, o principio religioso.Utilizzare i principi del manifesto all’interno di dinamiche di cambio organizzativo, soprattutto quando ci muoviamo al di fuori di team o al di fuori dello sviluppo software è, utilizzo ancora lo stesso aggettivo, ingenuo e, di conseguenza, rischioso per l’organizzazione.

Anche il ruolo di noi agilisti risulta ingenuo, poco utile o, nel migliore dei casi, quello di teorici di cose belle ma che non c’entrano con le esigenze dell’organizzazione. Un po ‘ come la collezione “The uncomfortable, gli oggetti di design inutili” di Katerina Kamprani.

I principi (alcuni) ed effetti collaterali

Estenderei il concetto di principi anche al mondo Scrum per riflettere quella che è una comprensione diffusa e cioè che Agile e Scrum siano la stessa cosa. Sappiamo che non è vero, anzi si tratta di enunciazioni che si muovono su piani diversi.
E’ invece piuttosto diffuso il considerare i principi e le indicazioni di Scrum come ugualmente importanti. Entriamo nel vivo di alcuni esempi, visti presso clienti e che hanno causato difficoltà e danni ai team cui sono stati applicati.

Comunicazione faccia a faccia

Il sesto principio del Manifesto è uno dei più noti: “Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare  con il team ed all’interno del team.” 

Dipende.

Vi porto il caso di un’azienda manifatturiera che ha personale sparso in tutto il mondo, dal Messico alla Cina. Per ragioni strategiche e di competenza è necessario che persone su fusi orari (e culture) diversi lavorino insieme. Nel momento del nostro ingaggio molti team erano stati formati e organizzati con il framework Scrum.

In fedele osservanza del principio sulla comunicazione faccia a faccia tutti i meeting di Scrum sono stati organizzati in maniera sincrona. In questo specifico caso il problema, e l’effetto, immagino sia ovvio: alle persone dei team veniva chiesto di essere sincroni con fusi orari con diverse ore di differenza. Era diventato normale che le persone si collegassero per il daily alle 22 ora locale.

Nel framework Scrum, il concetto di comunicazione faccia a faccia è implementato attraverso la lente della co-locazione. Il framework Scrum si basa su team co-locati. Co-locazione significa “nella stessa stanza”.
La co-locazione è fondamentale per la sincronizzazione e la comunicazione informale tra le persone. Tutte le riunioni di Scrum hanno senso grazie alla comunicazione informale e veloce che avviene.
Lo stesso edificio, ma a piani diversi, descrive a un team non co-locato. La dislocazione può essere misurata in base al costo (tempo e impegno mentale) di porre una domanda.
Allen ha descritto il fenomeno della riduzione, parzialmente limitata da strumenti IT, della comunicazione al crescere della distanza fisica tra i membri di un gruppo di lavoro: più siamo lontani, meno comunicheremo.

La curva di Allen

La curva di Allen

Nell’esempio che porto la migliore approssimazione di un team co-locato è rappresentata dai team che si trovano all’interno dello stesso fuso orario.

Nel caso di team non co-locati dovremmo utilizzare modelli di comunicazione e strutture diverse. Lo Scrum puro, con riunioni e daily e comunicazione sincrona non è applicabile. Crea un falso senso di appartenenza e un sovraccarico. Le persone sentono l’affiliazione non in base alla struttura, ma in base alle vie di comunicazione esistenti e a quanto queste vie di comunicazione siano difficili. Strumenti, fusi orari, lingua e cultura sono tutti elementi da considerare quando si pensa ai team Scrum.
I team Scrum si affidano fortemente alla comunicazione sincrona per creare affiliazione. Se l’affiliazione non può essere perseguita, dobbiamo pensare attentamente al tipo di team che stiamo creando, per gestire le aspettative e adattare lo sforzo di coaching.

Meccanismi di affiliazione (6)

L’esperimento di cambiamento, che ha avuto un certo successo in termini di soddisfazione delle persone e bilanciamento del carico, è stato il passaggio a comunicazione asincrone. Ad esempio il daily veniva fatto su Teams, alle 9 del mattino per ogni fuso orario. I meeting di team sincroni sono stati quasi azzerati, mantenendo solo una retrospettiva ogni due.

In sintesi abbiamo dovuto riconoscere che i principi di comunicazione faccia a faccia erano scritti per un contesto diverso e quindi non erano applicabili.In questo caso: “Una conversazione faccia a faccia NON è il modo più efficiente e più efficace per comunicare  con il team ed all’interno del team.” 

Il concetto di comunicazione faccia a faccia è stato cioè contestualizzato e ritenuto non utile al raggiungimento dell’obiettivo del team, e dell’azienda. Di conseguenza è stato ignorato.
Abbiamo ottenuto una struttura più Agile? Non lo so e trovo francamente tediosa e poco utile la domanda.
Una domanda migliore è: abbiamo ottenuto un team più funzionale, persone più contente (o meno insoddisfatte) e maggior probabilità di raggiungere gli obiettivi? Penso di sì.

Team cross funzionali

Questo è un principio del Manifesto, ripreso in Scrum con la precisazione “Gli Scrum Team sono cross-funzionali, ovvero i membri del team hanno tutte le competenze necessarie a creare valore ad ogni Sprint” (7). Questa indicazione ha senso solo considerando risorse infinite e non è quasi mai applicabile a realtà esistenti di sviluppo software.
Supponiamo di essere all’interno di una organizzazione che ha deciso di intraprendere un cambiamento e di creare dei team Scrum. Probabilmente tale organizzazione partirà con un solo team. Nella figura un team ipotetico con una persona che si occupa, per esempio, di UI.

Una persona del team, di colore rosso, si occupa di UI

Una persona del team, di colore rosso, si occupa di UI

Probabilmente l’esperimento ha un certo successo e si decide di estenderlo creando altri team. Il primo problema che l’organizzazione affronta è che non tutte le professionalità sono presenti con la stessa frequenza. Ad esempio, potrebbero non esserci sufficienti UI designer. Ma il mantra è il team cross funzionale quindi la tentazione è di procedere come segue:

Rappresentazione di due team dove la professionalità scarsa viene condivisa

La professionalità scarsa viene condivisa

 

E così via, per esempio, con tre team:

Esempio con 3 team in cui la persona viene condivisa da più team

La persona viene condivisa da più team

 

L’effetto sui team è disfunzionale, a dir poco. Senza considerare l’effetto sulla persona che deve dividersi e, sempre seguendo il mantra, partecipare a: 3 daily, 3 planning, 3 retrospettive, 3 processi di costruzione del team.

Anche in questo caso, una possibile via d’uscita è quella di rinunciare al mandato del team cross funzionale e accettare che le risorse scarse possano risiedere in gruppi diversi e servire i vari team con logiche più di flusso e a servizio.

Oltre a temi di carico, capacity, vorrei alzare lo sguardo dalla dinamica di un singolo team e mettere in discussione la stessa necessità di crearlo, il team cross funzionale.

Esistono ricerche che ci raccontano come la creazione di team potrebbe non essere sempre una buona idea. La presenza di un team o la separazione, ad esempio, dovrebbe essere decisa sulla base del lavoro da fare, del grado di interdipendenza e del potenziale conflitto di obiettivi. Nell’esempio di prima, UI designer e dev sono fortemente interdipendenti ma hanno obiettivi potenzialmente distinti. I dev sono legati al backlog, gli UI sono legati, ad esempio, ad uniformare/migliorare l’intera ux experience. Forse è meglio avere due team diversi e lavorare sui meccanismi di coordinamento.

Ricerche sul grado di interdipendenza di processo e obiettivi dei gruppi di lavoro(2)

Ricerche sul grado di interdipendenza di processo e obiettivi dei gruppi di lavoro (2)

In ogni caso, la stessa decisione di creare dei team merita un approfondimento sulla natura degli obiettivi dei gruppi che andiamo a creare.
Ritengo che la proposta di disegno organizzativo di noi agilisti sia sempre più appiattita su concetti semplici come i team cross-funzionali, o end to end, e stia perdendo di profondità e di interpretazione della realtà. In sintesi, siamo sempre più visti come quelli che, indipendentemente dal problema, propongono la creazione di team cross funzionali come soluzione. Se l’unico strumento che hai è un martello, vedrai solo chiodi.

Conclusioni

Questo articolo è una trasposizione della presentazione effettuata durante gli Italian Agile Days 2023 nei quali si è discusso del ruolo del Manifesto Agile dopo più di vent’anni. Ho voluto portare un punto di vista ed una interpretazione non tanto del manifesto stesso quanto della nostra capacità di continuare ad utilizzarlo… laddove abbia ancora senso e di porlo sotto una lente critica nel pieno spirito originario: “stiamo scoprendo….”.

 

Riferimenti bibliografici

(1) When Agile Harms Learning and Innovation: (and What Can Be Done About It), California Management Review, Annosi, Foss and Martini

(2) Gartner glossary (https://www.gartner.com/en/finance/glossary/organizational-design)

(3) Worren (2018), “Organization Design” (Routledge) and Worren, N. & Pope, N. (2024). Connected but conflicted: Separating incompatible roles in organizations, Academy of Management Review

(4) https://www.organizationdesign.net/whatisorganizationdesign

(5) Courtesy of Caliber Academy

(6) Rothman & Kilby (2019), From Chaos to Successful Distributed Teams

(7) Scrumguides.org

(8) 16th State of Agile, Digital.ai

(9) Jay R. Galbraith, “Organization design: an information processing review”, Interfaces, vol. 4, Maggio 1974

(10) Alcuni approcci al disegno organizzativo

(11) Curva di Allen: https://en.wikipedia.org/wiki/Allen_curve

Articolo scritto da Pino DecandiaLinkedin

Leggi altri articoli della stessa categoria: Organizzazione e strategia

O esplora altre categorie Organizzazione e strategia Pratiche e strumenti per team Prodotti e progetti agili