Nel periodo fra il 1999 e il 2003, sintetizzando i risultati di studi precedenti effettuati fra gli altri da Boisot e Cilleris, Snowden e Kurtz svilupparono l’ormai noto Cynefin framework, strumento tramite il quale è possibile formalizzare e visualizzare la complessità dei sistemi all’interno dei quali si.

Che cosa è Cynefin

Il Cynefin framework è un modello interpretativo dei diversi livelli di complessità dei sistemi; esso si basa sull’idea che tutti i sistemi all’interno dei quali abitualmente ci troviamo ad agire possono essere classificati in base a quanto è articolato il sistema interno e al tipo di ambiente in cui il sistema si trova, in un continuum che spazia dall’ordine al disordine; il Cynefin suddivide infatti il mondo in quattro contesti (o domini) di complessità:  dal caso semplice al complicato al complesso al caotico. In figura 1 è riportata una rappresentazione grafica di tale modello: in realtà la separazione fra i quattro casi non è mai così netta e definita come quella riportata nello schema.

Figura 1 – I quattro domini di complessità di Cynefin. Dal basso a destra, in senso antiorario, l’articolazione del sistema aumenta attraverso quattro “quadranti”: semplice, complicato, complesso, caotico.

Un modello per interpretare i sistemi

A scanso di equivoci, è importante notare che il Cynefin, differentemente da altri strumenti di valutazione, non ha lo scopo di indicare quale sia la “cella” migliore o più funzionale, per un sistema o gruppo di lavoro. È chiaro che il caso caotico andrebbe evitato, ma gli altri casi sono situazioni all’interno delle quali si può stare o meno, indipendentemente da una valutazione di bontà del sistema. In pratica, Cynefin non prescrive dove obbligatoriamente dobbiamo stare, ma ci insegna a riconoscere la tipologia di situazione in cui ci troviamo.

Lo scopo principale di questo modello, pertanto, non è di fornirci le risposte relativamente al contesto dentro il quale lavoriamo, quanto piuttosto di metterci a disposizione un sistema di sense-making, come lo chiamano gli autori, vale a dire un modo con il quale renderci conto delle possibili casistiche all’interno delle quali un sistema può ricadere.

Il Cynefin ci descrive in modo piuttosto pragmatico quelle che sono le dinamiche e i comportamenti tipici di uno o dell’altro quadrante: ci dice quindi cosa accade se siamo uno scenario semplice o complicato, ma non ci dice come dobbiamo comportarci per uscire da uno scenario caotico o ridurre la complessità se siamo in un sistema complesso.

Approccio pragmatico

Lo scopo di questo articolo è anche quello di evidenziare le indicazioni che il framework ci fornisce, per cominciare a prendere coscienza degli strumenti utili a valutare e classificare le dinamiche del caso specifico.

Il Cynefin si presta a innumerevoli contestualizzazioni pratiche, tanto che fra le altre cose è usato spesso durante sessioni di coaching agile per fornire ai partecipanti una prova pratica delle cose che si trovano nei vari manuali di teoria. A tal proposito una interessante e divertente implementazione è quella offerta dal Cynefin Lego [AG42], un gioco che rientra nella categoria dell’Agile Gaming (si vedano a tal proposito anche gli articoli di Giulio Roggero pubblicati in questi mesi su MokaByte) [GAM].

Figura 2 – Cynefin Lego: un’immagine della serata organizzata da MokaByte in collaborazione con ToscanaIn.

Vediamo di seguito di presentare i diversi domini previsti da questo modello interpretativo, illustrandone le caratteristiche, le dinamiche e l’approccio alla comprensione che li caratterizzano.

Semplice: sense, categorize, respond

Come dice la parola, il quadrante del “semplice” rappresenta il caso a complessità minore, dove causa ed effetto sono strettamente correlati e dove ogni azione da noi intrapresa porta a una conseguenza facilmente prevedibile: “Se rovescio un bicchiere di acqua sulla tovaglia, questa si bagna”. L’azione è ripetibile all’infinito e otterremo sempre lo stesso risultato finale. Il rapporto tra causa ed effetto è chiaro ed è facilmente comprensibile da chiunque: non è necessaria una competenza specifica.

In questo caso la variabilità è limitata, le possibili soluzioni o effetti finali sono veramente pochi e facilmente individuabili. In questo contesto la soluzione al problema è evidente a tutti e non è in discussione.

Siamo quindi nel contesto detto del known knowns (il senso è “sappiamo quali sono le cose da sapere”): le informazioni sono disponibili e noi le possiamo ottenere a patto di cercarle, oppure le abbiamo già.

L’approccio alla gestione del sistema semplice

I cosiddetti decision makers tipicamente mettono in pratica un processo del tipo sense categorize, respond: valutare, classificare e agire direttamente. I contesti semplici sono le classiche situazioni fortemente orientate al processo gestite tramite l’applicazione di pratiche standard. L’utilizzo di best practices è quindi una pratica consolidata, mentre la reingegnerizzazione è uno strumento di uso comune.

Sia chi coordina o comanda che chi esegue ha accesso alle informazioni e lo stile command-and-control è quello tipicamente preferibile: la gerarchia è importante, se non addirittura prevalente, rispetto al network, che è la rete di relazioni e di scambio di informazioni tra i vari attori del sistema, che presuppone un’ampia comunicazione. Se l’input arriva dall’alto, si riesce quindi ad agire in modo rapido ed efficace rispetto all’intavolare una discussione per stabilire quale sia la soluzione migliore di agire. Nel grafico questo è rappresentato dalla piramide con le palline e le linee che le uniscono: le linee dall’alto al basso sono continue (gerarchia importante), quelle orizzontali sono tratteggiate (rete meno importante).

Complicato:  sense, analyze, respond

Aumentando il livello articolazione del sistema, nel Cynefin framework troviamo il dominio complicato, noto anche come il dominio degli esperti (vale il know how); in questo ambito infatti non esiste una sola soluzione al problema, ma sono possibili molteplici alternative. La differenza rispetto al caso semplice è data dal fatto che la relazione fra causa ed effetto, benche’ ancora presente, potrebbe non essere così evidente a tutti; dipende quindi dal livello di conoscenza ed esperienza del decision maker. L’analisi della causa-effetto è utile in funzione della conoscenza che l’esperto ha del dominio in questione.

In questo contesto il numero di variabili, di incertezze e di perturbazioni aumenta rispetto al dominio semplice, facendo crescere l’articolazione dei problemi; aumenta pertanto il numero delle possibili risposte. Contrariamente al dominio semplice, qui sappiamo quali domande porci, ma non conosciamo le risposte, a meno di consultare gli esperti che possono trovarle.

Anche in questo caso la complessità del sistema si somma o meglio si compone con quella del sistema esterno nel quale esso risiede. Per il caso semplice, il sistema esterno può essere semplice o complesso, ma questo non ha implicazioni rilevanti sul sistema interno; nel caso complicato, le cose sono differenti: qui la complessità si compone.

Questo fatto ha portato spesso, nel tentativo di contenere la crescita esponenziale della complicatezza verso la complessità, a organizzare i sistemi in silos verticali, ognuno dei quali ha una elevata specializzazione sia operativa che delle persone che ci operano: si pensi alle unità di business di una azienda, ai reparti commerciali separati da quelli di produzione, e così via.

L’approccio alla gestione del sistema complicato

È anche per questo motivo che, sempre per affrontare problemi apparentemente difficilissimi, l’approccio preferito dagli esperti è quello dell’analisi: il problema viene scomposto in parti costituenti, con la consapevolezza che la soluzione dei singoli sotto-problemi porta alla soluzione del problema nella sua completezza. Scomporre il sistema, sebbene sia spesso un problema non banale, ha il vantaggio di gestire parti più piccole, più maneggevoli, con un grado di articolazione minore.

Tale scomposizione è fattibile perche’ i singoli componenti hanno una bassa interazione fra loro:  benche’ tutti i componenti lavorino insieme all’interno dello stesso sistema, il loro funzionamento e comportamento è indipendente da quello degli altri componenti vicini, vale a dire che non c’è influenza reciproca tra i diversi elementi. Il funzionamento del singolo elemento è lo stesso sia se preso isolatamente che quando inserito in un sistema; modificando uno dei componenti vicini non si hanno ripercussioni.

Altra conseguenza implicita dell’approccio analitico è che tramite il processo di scomposizione e ricomposizione si può non solo risolvere il problema completo, ma anche ottimizzare il sistema semplicemente regolando al meglio il funzionamento di tutte le sue parti. “Il tutto è la somma delle parti” è un assunto “scontato”, ma adatto a definire un sistema complicato, tanto che nel corso del secolo passato è stata esattamente questa convinzione che ha mosso verso la definizione del tipico processo di produzione industriale a catena, processo dove l’obiettivo primario era quello di massimizzare il controllo di ogni parte della lavorazione, nella convinzione che fosse possibile controllare e gestire ogni dettaglio.

Purtroppo, come già evidenziato nell’articolo precedente, la maggior parte delle attività umane (processi di produzione, attività di gruppo, organizzazioni sociali etc.) non sono riconducibili a un modello “solamente” complicato, ossia composto da parti indipendenti fra loro.

Scomposizione e ricomposizione

Deming, autore delle 14 regole sulla qualità totale, molto citate nella letteratura lean e nelle migrazioni agili, ha toccato questo aspetto della scomposizione e ricomposizione, ma in modo che ha generato spesso fraintendimenti.

Infatti, i 14 punti di Deming prevedono che tutti coloro che lavorano nell’azienda si impegnino per portare a compimento la trasformazione. Il lavoro di tutti consiste nella trasformazione. Ci sono molti indizi che indicano come Deming non volesse per i suoi punti una interpretazione basata sulla funzione dei singoli processi separati, quanto piuttosto un’enfasi sulla trasformazione. Per Deming l’importanza di pensare il sistema in maniera olistica e di ottimizzare l’intero sistema era chiara, ma questo suo messaggio è passato in secondo piano per i manager che avevano un approccio analitico e per i consulenti che erano al loro servizio. Il risultato che ne è conseguito, storicamente, si è concretizzato in un gran numero di metodi e strumenti per migliorare il processo,  ma in ben pochi strumenti per un miglioramento a livello di sistema.

Una delle caratteristiche distintive di un sistema complicato è la relativa stabilità sia del sistema stesso che del dominio di competenza.

Figura 4 – Il sistema complicato: in questo caso agire per best practice è la soluzione migliore. La comunicazione dall’alto è utile come quella del network.

Complesso: probe, sense, respond

Procedendo nella scala dell’articolazione, dopo il caso complicato troviamo il complesso; nell’uso comune i due concetti sono spesso confusi, tanto che i due termini ci sembrano molto simili fra loro; in realtà un sistema complesso è profondamente diverso da uno complicato.

In modo rapido e sintetico si potrebbe dire che la differenza fondamentale fra complesso e complicato è legato sia al concetto di adattabilità e dinamicità del sistema stesso, sia alla interrelazione dei singoli componenti del sistema stesso.

Prima di vedere come ci si comporta in un modello complesso e quali sono le dinamiche che si instaurano all’interno di uno scenario di questo tipo, vediamo quali sono gli aspetti che caratterizzano un sistema complesso.

La prima definizione che può dar soddisfazione ai matematici è che un sistema complesso non è modellabile per mezzo di equazioni lineari: definizione interessante, da sfoggiare in una serata con amici che hanno studiato fisica o matematica, ma che lascerebbe piuttosto indifferenti gli altri…

Proseguendo possiamo dire che in un sistema complesso gli output del sistema stesso sono rientranti (feedback, ossia retroattività cortocircuitata): quello che esce dal sistema, oltre a rappresentare il prodotto finito, rientra nel sistema stesso e ne influenza il comportamento. Un esempio tipico di sistema rientrante è il corpo di un atleta durante una prova di resistenza: più l’atleta spinge il suo fisico fuori dalla soglia aerobica, più questo produce uno sforzo e prima inizierà a produrre acido lattico.  Più produce acido lattico e più degrada la prestazione. Più l’atleta cerca di contrastare questa evenienza spingendo sul fisico, più il livello di acido lattico aumenta e la prestazione degrada. Se non ci si riposa, se non si abbassa il ritmo e se non ci si alimenta opportunamente, si arriva a  un punto in cui l’organismo non risponde più agli stimoli: crampi e crisi di fame portano al blocco (“il muro”).

Passando a un esempio più collegato alla realtà IT, si pensi al caso di un team che si trovi già in una situazione svantaggiata, dovendo compiere un lavoro sovradimensionato: per esempio deve implementare più use case o funzionalità di quelle che sono materialmente possibili per le capacità del team. Se per esempio il team si organizza il lavoro in modo da rilasciare pezzi per volta, per esempio in un contesto iterativo stile Scrum o anche RUP, è probabile che già al primo rilascio (o milestone) avrà accumulato un ritardo o un debito tecnico che verrà propagato alla seconda fase del lavoro. Quando quindi il team si ritrova a dover svolgere il lavoro della fase due, troverà sul suo percorso le difficoltà del 2e’ round più le cose irrisolte, i problemi, le mancanze (in una parola i debiti tecnici o funzionali) che si erano creati allo step precedente. Il lavoro in fase due quindi peggiora in funzione dell’output del team stesso.

Interconnessione

Strutturalmente un sistema complesso si caratterizza per il fatto che è composto da parti fortemente interconnesse fra loro: il funzionamento di ogni singola parte è strettamente legato a quello delle parti vicine e dipende dalla interazione che si instaura fra i componenti.

Data questa premessa, risulta difficile, se non impossibile, smontare il sistema: è arduo identificare i bordi delle componenti e “tagliare” dove serve, ma anche se si riuscisse in tale compito, quello che si otterrebbe sono componenti che o non funzionano pezzo per pezzo, oppure funzionano in modo completamente diverso rispetto a quando sono “montati nella macchina”.

Il sistema complesso è basato su un principio molto importante che i fisici chiamano principio di indeterminazione di Heisenberg: semplificando in maniera estrema, l’osservazione di un fenomeno spesso altera il comportamento del fenomeno stesso perche’ introduce dei “disturbi” nel sistema che deve essere osservato. D’altro canto, il sistema complesso è resiliente, resiste alle perturbazioni, si modifica si adatta ma non si rompe.

I sistemi complessi spesso hanno un elevato numero di componenti, detti agenti che interagiscono fra loro per adattarsi o apprendere. Gli agenti, o attori, all’interno dei sistemi complessi sono in grado di osservare l’impatto delle loro iniziative e di regolarle in maniera adeguata al fine di raggiungere i risultati voluti. I sistemi complessi sono quelli a cui Senge [PS] fa riferimento chiamandoli “organizzazioni in grado di apprendere”.

I confini del sistema non sono netti e facilmente identificabili e il sistema non è quasi mai in equilibrio stabile: dell’energia deve essere spesa per tenere sotto controllo il sistema (la centrale nucleare esplode se viene a mancare la corrente). Si pensi al team di lavoro sotto stress in cui il PM deve continuamente adoperarsi per tenere sotto controllo malumori, impedimenti che si manifestano. Se il PM smette di agire sul sistema interno (il team) o su quello esterno (cliente, insieme dei requisiti) probabilmente il progetto non arriverà a termine e il team si sfalderà.

L’approccio alla gestione del sistema complesso

Un sistema complesso è in genere governato dalla serie storica, ossia il comportamento di  oggi e le risposte di domani sono funzione di quello che è successo dentro e fuori dal sistema fino a ieri: la borsa valori è un esempio tipico, ma anche il nostro cervello e il modo di pensare e reagire che è frutto delle esperienze e degli apprendimenti del passato.

Esempi di sistema complesso sono le organizzazioni sociali dell’età contemporanea, i social network, le colonie di insetti sociali.

In un sistema complesso la conoscenza degli esperti è meno importante per la valutazione causa effetto, o comunque può funzionare solo per contesti marginali o per periodi limitati nel tempo. Non è detto che sia del tutto inutile, ma è poco efficace nel cercare di prevedere eventi futuri.

Come ci si comporta in un sistema complesso? In questo caso ha poco senso pianificare e classificare per cercare di ricondurre il caso in esame ad altri già visti o già risolti. Non è possibile infatti agire per best practice. Troppe le variabili che possono modificare il comportamento del sistema. In genere in questo caso si suggerisce di entrare nel sistema e iniziare a vederne il funzionamento dal di dentro, cioè sondare. Agire e risolvere il sistema pezzo per pezzo. Vedere l’effetto delle iniziative direttamente con il sistema. In una parola seguire un approccio agile (p.e., metodologia Scrum): Appelo usa lo slogan “Dance with the system”. In questo caso la comunicazione gerarchica funziona poco, mentre il network è rilevante (ricorda molto l’impostazione di Scrum).

Figura 5 – Il sistema complesso:  le best practice non sono più utilizzabili. La comunicazione del network è di gran lunga più utile di quella che viene dall’alto.

Caotico: act, sense, respond

Il legame che sussiste fra causa ed effetto forma uno strumento di valutazione e indagine particolarmente utile nel caso semplice e complicato. Anche nel modello complesso può fornire informazioni utili, a patto di assumere che la conoscenza acquisita ha effetto sul breve, e che spesso sia necessario ricreare tale conoscenza con nuovi cicli di indagine e raccolta di informazioni.

Ma, come il nome suggerisce, il dominio caotico è caratterizzato da uno scenario turbolento con un elevato grado di incertezza. Causa ed effetto spesso non sono minimamente riconducibili a uno stesso filo conduttore; nel caso in cui sia possibile trovare una qualche legge che ne regola la dipendenza, questa ha valenza limitata nel tempo e dopo pochissimo tempo diverrà inutile.

Questo è il dominio dell’ignoto (“unknown unknowns”, vale a dire che non so le risposte ma non so nemmeno le domande…) e probabilmente anche del non conoscibile.

L’approccio alla gestione del sistema complesso

Lavorare per far emergere pattern comportamentali riconoscibili, classificabili e quindi poi riutilizzabili può essere un inutile spreco di tempo, se non propedeutico per il disastro. Per questo spesso questo dominio viene chiamato il “Super Hero Domain”: solo un super eroe può (forse) risolvere il problema, entrare nel palazzo in fiamme e salvare tutti. Spesso accade che il super eroe non sia disponibile, che sia morto in una precedente missione impossibile, oppure che si sia stufato e all’ennesima emergenza non sia più disposto a mettersi in gioco per salvare il mondo. Il consiglio migliore che si può dare in questi casi è… scappare: tradotto in termini più di project management significa che, se si comprende che il progetto sta migrando nel quarto quadrante, quello del caos, la cosa migliore da fare, sia da un punto di vista economico che di convenienza aziendale, è abortire il progetto. Se la cosa non è possibile, aspettatevi un’elevata probabilità di fallimento.

Per concludere, si pensi alla definizione che i matematici danno di un sistema caotico: non è vero che si tratta di un modello non rappresentabile con leggi matematiche, non è vero che è semplicemente il caso dove c’è molta confusione all’ennesima potenza e non sono vere molte altre false credenze che si sentono nei film o al telegiornale. La definizione corretta è quella che ci dice che un sistema è caotico è sempre descritto da funzione matematica che ne mappa il comportamento e quindi ci permette di fare previsioni sullo stato finale del sistema (p.e., che tempo farà domani); tale funzione matematica ha in genere un elevato numero di parametri di input per i quali una piccola perturbazione dei dati in ingresso fa restituire una risposta completamente differente all’equazione caotica. È il cosiddetto effetto farfalla: “il battito delle ali di una farfalla in Brasile può scatenare un tornado in Texas”, come sintetizzò in maniera paradossale ma efficace il matematico statunitense Edward Lorenz agli inizi degli anni Settanta.

Quindi cosa possiamo fare se il sistema è caotico? Probabilmente nulla. Scappare o premunirsi con occhiali da sole e crema solare ma anche ombrello.

In sintesi

Il framework Cynefin rappresenta uno strumento utile prima di tutto per classificare i tipi di complessità di un sistema e dell’ambiente all’interno del quale tale sistema si muove.

Il framework però ci dice anche quali sono le dinamiche comportamentali degli attori che agiscono nel sistema, il modello comunicazione del team e quale è il tipo di atteggiamento funzionale in tale ambito.

Il Cynefin non ci dice come risolvere le problematiche, non dà soluzioni: ci dice dove siamo, non cosa fare per passare da un quadrante all’altro.

Figura 7 – Un ulteriore quadro riassuntivo del modello Cynefin.

Probabilmente la cosa più interessante che si può dedurre dal Cynefin è legato alla differenza fra scenario complesso e complicato: in un caso vale l’approccio analitico (complicato) che è basato sulla scomposizione del problema in sottoparti, perche’ la somma delle parti da luogo al tutto. Nell’altro caso il modello analitico non funziona: chi ha fatto sessioni di Cynefin Lego può essersene reso conto in modo chiaro.

Il motto del caso complicato è sense, analyze, respond: prima valuto da fuori, poi analizzo, poi agisco. È questo il classico caso di un approccio waterfall.

Il motto del caso complesso invece è probe, sense, respond: prima sondo (ossia tocco con mano entrando nel sistema), poi valuto, poi agisco. Quindi non è possibile applicare un modello che predetermini ogni aspetto del processo. Il modello a cascata, dove analisi, design e implementazione non sono solo preordinati ma nettamente divisi, non va bene. Quindi è più funzionale in questo caso un approccio in cui si inizia a risolvere il problema in modo concreto e pratico fin dal primo momento. In un caso come questo quindi appare piuttosto chiaro come funzioni meglio una metodologia agile dove l’approccio è quello di entrare fin dal primo giorno dentro il problema, per esempio eliminando le lunghissime fasi preliminari di analisi.

Probabilmente la considerazione più importante sul Cynefin che possiamo fare è che è un ottimo strumento per comprendere la differenza fra il campo di applicazione di una metodologia agile e quello di una tradizionale.

Riferimenti

[AG42] Sito della azienda Agile42, specializzata nel coaching dei processi agili

http://www.agile42.com

[PS] Peter Senge, “La quinta disciplina: l’arte e la pratica dell’apprendimento organizzativo”, Sperling & Kupfer, 1992

[14QT] Le 14 regole della qualità totale secondo Deming

http://goo.gl/hMM1c

[GAM] Giulio Roggero, “Agile Gamification: apprendere le metodologie giocando – I parte: Il gioco e le metodologie Agile”, MokaByte 182, marzo 2013 (e articoli successivi della serie)

https://www.mokabyte.it/cms/article.run?articleId=Q9H-FMA-FET-368_7f000001_26089272_3bd6fd77#