Nel precedente articolo, abbiamo analizzato i vari tipi di complessità con i quali possiamo classificare i sistemi: gruppi di lavoro, team di progetto, progetti stessi e così via. Affrontare un sistema significa anzitutto cercare di vedere le tipiche dinamiche che si possono instaurare tra le sue varie componenti: gli elementi che interagiscono possono essere anche molti, possono avere maggiore o minore autonomia decisionale, e il comportamento del sistema è dato dal risultato della reciproca interazione e dall’influenza di numerosi fattori interni ed esterni. Abbiamo pertanto visto una prima spiegazione del perché determinati modelli di controllo non possono funzionare in ambiti dove la complessità supera una determinata soglia.

La sfida della complessità

Cari lettori, affrontereste una bella nuotata in mare vestiti in giacca e cravatta? O, per le lettrici, vi presentereste su una pista di sci abbigliate con un elegante tailleur e scarpe leggere con tacco? No? Eppure si tratta dell’abbigliamento “corporate” usuale, se non addirittura obbligatorio, in certi contesti lavorativi.

Che cosa c’è che non quadra? C’è che certe convenzioni sociali e certe tradizioni hanno per decine di anni ritenuto ottimale quel tipo di abbigliamento per quel tipo di contesto lavorativo. E probabilmente lo sarà ancora. Ma quando il contesto (il mare d’estate, la montagna innevata) cambiano, lo strumento (l’abbigliamento consono) con cui lo si affronta deve adattarsi.

Se trasportiamo questo strampalato esempio nell’ambito dei processi di produzione dell’organizzazione del lavoro si comprende bene come un modello organizzativo, magari ottimo e fruttuoso in un contesto, non può essere applicato sempre in maniera automatica a qualsiasi situazione: non è detto che le soluzioni di ieri siano ancora adatte ai problemi e agli scenari del presente e del futuro.

Negli articoli precedenti ci siamo concentrati su questo concetto analizzandolo dal punto di vista della complessità. Si è parlato di scenari semplici, complicati e complessi (nonche’ di quelli caotici). Si sono presentate in quel caso le caratteristiche principali dei domini semplici e complicati e di quelli complessi, illustrando brevemente quali siano i modelli organizzativi adatti a questi scenari.

Dal modello “prevedibile” a quello “non deterministico”

Senza ripercorrere tutta la trattazione, potremmo sinteticamente dire che il modello complicato è comunque un caso predicibile, ripetibile, dove l’organizzazione gerarchica è efficace; il team che lavora è più o meno dello stesso livello dal  punto di vista delle conoscenze, delle responsabilità e degli skill.

Il dominio complesso invece ribalta completamente queste ipotesi. Il sistema evolve secondo dinamiche non deterministiche per cui non è possibile fare alcuna assunzione su come il processo si sviluppa e su cosa accadrà. Non possiamo pre-definire il processo perche’ ciò significherebbe sapere a priori cosa accadrà: e qui, molto semplicemente, non lo sappiamo. Nel dominio complesso, inoltre, la gerarchia perde di efficacia: il lavoro può essere portato a termine solo vivendolo da dentro, e non pilotandolo da fuori.

Il team fa prima ad agire senza ricevere l’ordine dall’alto: perde di efficacia il paradigma command and control; il venir meno della gerarchia intesa tradizionalmente non è un’istanza da “figli dei fiori”, ma è la fredda presa d’atto che, per certi contesti, quel paradigma non è adatto.

Dalla gerarchia verticale al modello collaborativo

Il superamento delle gerarchie tradizionali può essere visto come la chiave evoluzionistica verso le metodologie agili. La frase forse è un po’ a effetto, ma probabilmente è quanto di efficace possiamo dire per sintetizzare l’analisi che segue.

Riprendendo le considerazioni dell’articolo precedente, partiamo dalla constatazione che ormai tutti viviamo in un contesto complesso: svolgere un’attività di rilevanza, che come nell’esempio classico Cynefin, vada oltre la semplicità del mangiare un gelato, richiede sempre più spesso un livello di specializzazione e di esperienza notevoli. Lo vediamo quando si tratta di realizzare un prodotto, non necessariamente software, sviluppare un progetto che coinvolga diversi team e così via.

Sistemi complicati: la metrica è il tempo

Prendiamo in esame un dominio complicato, ad esempio il tipico processo di produzione industriale a catena secolo scorso: il gruppo di lavoro nel suo complesso è composto da pochi dirigenti e controllori (paradigma Command & Control) e molti esecutori del lavoro, che possiamo chiamare riduttivamente e sinteticamente manodopera. Secondo questo modello il management sapeva in ogni momento cosa doveva essere fatto e come; la manodopera, invece, aveva, relativamente, poche conoscenze e competenze.

Il processo produttivo era ben conosciuto da dirigenti e controllori, e poteva essere considerato come un sistema blackbox che produceva oggetti, dall’aereo al “pezzo” di software, secondo un modello in cui era possibile fare previsioni sui dettagli produttivi, su costi e tempi.

Per questo, una volta stabilita la performance del sistema, l’unica metrica di rilevanza e di più immediato utilizzo è il tempo: se possiamo produrre n pezzi in tot giorni, e tale informazione è un dato non molto alterabile, fra tot giorni sapremo sostanzialmente quale sarà lo stato di avanzamento della produzione; ribaltando la funzione, sarà facile sapere in sostanza quanto tempo ci vorrà per terminare la produzione di un lotto.

Come si esercita il controllo sulla produzione? Sappiamo, tutto sommato, quanto tempo occorre per completare una attività (tempo stimato) e possiamo contare quanto tempo ci si mette effettivamente (tempo misurato): questo discorso vale in un contesto in cui si dà per scontato che il flusso di lavoro sia predefinito, e che una volta che ci si metta all’opera, si avanzerà in maniera predicibile di un tot nell’unità di tempo. Non ci inganniamo: al di là delle considerazioni inerenti i diritti della manodopera, l’industria è andata avanti così per decenni, conseguendo i suoi risultati, almeno finche’ il flusso di lavoro era ripetitivo e prevedibile, in uno scenario in cui c’erano solo pochi cambiamenti diluiti nel tempo e in cui il risultato finale era definito e ben conosciuto fin dall’inizio.

In questo modello quindi bastano pochi per gestire molti, e il controllo della produzione si riduce “banalmente” nel misurare l’avanzamento nel  tempo; i lavoratori sono valutati in base a quanto producono nel tempo, con una prevalenza nella misurazione delle prestazioni degli individui rispetto a quelle della qualità del prodotto finale..

Organizzazioni e strutture di questo tipo sono regolate da uno schema detto push dato che infatti sia gli input del lavoro ma anche i controlli arrivano dall’alto. Il lavoro è eseguito da figure professionali caratterizzate da un livello di specializzazione e professionalità medio o basso, alta disponibilità, perche’ sono facilmente reperibili sul mercato, e costo generalmente basso: per mantenere bassi i costi ne posso assumere molte a fronte di poche figure di livello alto.

Sistemi complessi: mutare paradigma

Come si è avuto già modo di vedere negli articoli precedenti sulla storia del management e sul Cynefin, con gli anni e l’evoluzione dei sistemi economici e sociali, la complessità dei sistemi produttivi è andata aumentando.

Passare da un modello complicato, che pur con qualche fatica è comunque predicibile, a uno complesso, in cui diventa molto difficile prevedere i risultati, comporta lo sviluppo di dinamiche diverse rispetto a prima: aumentano gli elementi del sistema così come  aumentano le interazioni fra essi e le componenti esterne.

Un aspetto importante di questa evoluzione è legato al sistema organizzativo: nel sistema complesso comincia ad assumere importanza il concetto di network, di rete tra i lavoratori coinvolti, e si dimostra sempre meno efficace la gerarchia intesa in senso tradizionale.

Infatti, lavorare in un dominio complesso richiede molte più competenze ed esperienza, su molti aspetti diversi. Tutte queste skill non sono in genere riassumibili in una sola persona: non può essere il solo manager/capo a sapere cosa deve essere fatto e a controllare che tutto sia fatto. Serve sempre più un team multidisciplinare con competenze ampie e distribuite. Perde di importanza l’organizzazione aziendale in senso tradizionale; prendono importanza la persona, le sue competenze e la capacità di interagire con gli altri.

Resistenze al cambiamento e irrigidimento dell’organizzazione

Come spesso accade, le organizzazioni hanno in molti casi reagito al cambiamento opponendosi ad esso, invece di adattarsi per accoglierlo positivamente. In molti casi si è pensato solo ad aumentare il livello di controllo e il potere della gerarchia: ma questo è comprensibile, dal momento che il salto concettuale richiesto era troppo forte.

Per molte aziende, è di fatto impensabile che il capo non possa continuare più a essere l’unico in grado di dirigere e controllare: però questo atteggiamento è di per se’ un primo livello di inefficienza, che porta a problemi dal punto di vista produttivo (scarsa qualità, scarse prestazioni) e negativi impatti psicologici sul gruppo (insoddisfazione dei “subordinati”, frustrazione di fornte all’evidente incapacità di rispettare requisiti e tempistiche etc.).

Le organizzazioni particolarmente rigide e restie al cambiamento non prendono atto del fatto che oramai ci sono troppe variabili che diventano aspetti fondamentali del sistema; anzi, spesso per mascherare l’evidente incapacità del management di dirigere e controllare introducono un ulteriore livello di mascheramento fra management e gruppo operativo. Succede esattamente l’opposto di quello che dovrebbe accadere: invece di avere un appiattimento della gerarchia, con il manager che va in produzione per capire cosa succede, si creano ulteriori livelli di disaccoppiamento e mascheramento, aumentando così il fattore di inefficienza.

La riorganizzazione collaborativa e le competenze “T-shaped”

Cynefin ci diceva che nei sistemi complessi, il network funziona più della gerarchia. Occorre pertanto strutturare l’organizzazione con una gerarchia più piatta e paritaria, composta da tante persone, e non più “risorse”, termine amato dal Taylorismo [1] ma criticato dal Lean. E queste persone devono possedere una forte specializzazione in alcuni aspetti, ma devono comunque essere in grado di svolgere diverse mansioni, o perlomeno devono comprendere il significato e le implicazioni del lavoro fatto dai colleghi.

E questo il concetto di T-Shaped skills. La T ha un significato metaforico: l’asta verticale della lettera rappresenta l’approfondimento delle competenze e dell’esperienza in un dato campo (competenza verticale), mentre la barra orizzontale (competenze orizzontali) rappresenta la capacità di spaziare su diverse discipline, soprattutto per il fatto di essere in grado di collaborare con esperti di altre aree di conoscenza diverse dalla propria.

Da questo deriva un altro concetto importante: se nel modello gerarchico è il management ad essere depositario del dove si deve andare e di come si deve fare per arrivarci, in questo caso abbiamo a che fare con un gruppo paritario e auto-organizzante. Per questo perde di significato il ruolo del comandante di vascello ma è più efficace l’adozione di strumenti che permettano a tutti di comprendere dove è il punto di arrivo, di conoscere la rotta, e di condividere il modo per raggiungere la meta.

È qui che entra in gioco il concetto di vision: la visione condivisa sul progetto da parte del gruppo diventa  “lo” strumento indispensabile per la buona riuscita del lavoro. Quindi il passaggio verso il  concetto di team  (paritario, contenente tutte le conoscenze necessarie per decidere e agire, auto-organizzante) e la presenza di una vision condivisa sono probabilmente due elementi essenziali per poter agire in un contesto complesso. Sono infatti alcune delle colonne portanti dei principi Lean e delle metodologie Agile.

Push vs. Pull

A fronte del modello in cui le informazioni arrivano dall’alto (push), nell’ambito Lean/Agile si instaura un modello in cui le persone ricavano informazioni “tirandole” dagli altri (pull) in un processo continuo fatto di domande, risposte, collaborazione e retrospettiva. In questo senso, i team di persone con competenze diversificate fra loro risultano più adatti a gestire i processi produttivi attuali, i quali sono sempre più complessi e richiedono una quantità e una varietà di competenze sempre maggiore. Tutto ciò giustifica lo spostamento di attenzione dal valore del singolo professionista a quello della squadra multidisciplinare.

La differenza tra push e pull sta anche nel fatto che non c’è più un management che impone dall’alto (push) l’elenco delle cose da fare e i tempi e i modi per farle, ma è il team che decide queste cose prendendole (pull) a partire dai requisiti e valutando anche le eventuali nuove conoscenze da acquisire.

Ne deriva quindi il fatto che il team agile deve essere in grado di auto-organizzarsi e di identificare ciò che nel progetto serve per portarlo a termine in maniera positiva. Pertanto è normale che ci sia una richiesta di ulteriori informazioni al committente, o che certi processi possano essere modificati, o che i comportamenti non siano sempre uguali a se’ stessi, in modo ripetitivo. In poche parole, conta più l’adattamento a un contesto mutevole che il mantenimento di un comportamento predefinito.

Assume poi grandissima importanza la comunicazione: comunicare ciò che serve al progetto, ciò che manca, quali sono i problemi che si incontrano aiuta i team a rispondere ai cambiamenti, modificando, se necessario, l’organizzazione e il processo. E in questo scenario, il manager non è più un piccolo dittatore, ma diventa una sorta di facilitatore il cui compito è comprendere le esigenze dei team e fornire assistenza e servizi.

C’è anche un cambiamento di focalizzazione: dal concentrarsi esclusivamente sul proprio limitato compito, il membro della squadra deve passare a una considerazione “olistica” dell’intero contesto in cui si muove, aumentando la propria consapevolezza sull’intero processo e sull’intera organizzazione.  

Il controllo nel processo empirico: il “done-done”

Quando ci troviamo in un ambito complesso, un processo deterministico e predeterminato non può funzionare. In questo caso infatti è preferibile, se non necessario, adottare un processo empirico, dove il controllo non è predeterminato dall’alto e non è basato sulla misurazione del tempo che passa. in questo caso, infatti, il controllo del flusso di produzione è basato sulla misurazione costante della quantità di prodotto finito, controllato e funzionante.

Fondamentale è il concetto di “finito e funzionante” (in agile si usa il termine “done done“): il prodotto (o una parte componente di esso), che sia software o un pezzo meccanico, deve essere completato in tutte le sue parti, deve essere funzionante, testato dal team e testabile dall’utente (utilizzabile) e deve essere qualcosa di valore e di senso per il cliente finale. Non sono ammessi rilasci completati a metà che poi in un secondo momento verranno ritoccati.

Solo contando quanti pezzi finiti si sono completati possiamo avere certezza di quanto abbiamo fatto fino a un certo punto: chiaramente stiamo parlando o di semplci prodotti completi, oppure di parti di prodotto, per quanto piccole, ma comunque complete. Da questo approccio alla consegna di un pezzo di prodotto, comunque finito, derivano alcune conseguenze:

• il “pezzetto” su cui si lavora volta per volta deve comunque avere un valore nel quadro del prodotto completo: non posso costruire qualcosa di inutile;
• i controlli devono essere frequenti, per ridurre il rischio di allungare i tempi fra un rilascio e l’altro;
• i rilasci devono essere frequenti (proprio perche’ su parti piccole).

Detto in altri termini, non si aspetta il rilascio di una milestone per testare con il cliente se una release di software è done-done: si può invece pensare di “smontare” il prodotto in tante parti, e procedere a rilasci piccoli che prevedano tempi di attesa ridotti. In questo modo, se per esempio rilascio e controllo si susseguono ogni una o due settimane, possiamo assumere che al massimo avremo l’incertezza di non sapere a che punto siamo a metà di una settimana.

La pratica corretta si basa sui principi

Torneremo più dettagliatamente su questi concetti quando parleremo più nello specifico di processi di gestione: per adesso è importante comprendere la filosofia di base per non finire a implementare Scrum o Kanban semplicemente scimmiottando alcune pratiche di lavoro: a tal proposito, l’antropologia culturale ci porta degli interessanti esempi in cui si imitano certe pratiche senza capirne il significato profondo e soprattutto senza avere consapevolezza dei principi che sono alla base di certe azioni, come nei cosiddetti Cargo Cults (“culti del cargo”) di cui avremo modo di tornare a parlare [2].

Pianificazione e piani d’azione

Una delle caratteristiche di un sistema complesso è l’impossibilità di prevederne  il comportamento nei minimi dettagli. Per questo si accantona ogni tentativo di pianificare e controllare in modo rigido, semplicemente perchè le variabili in gioco sono talmente tante che non è possibile definire un modello che le tenga tutte in considerazione per poter poi calcolare  il risultato finale. Questo concetto si potrebbe riassumere con il fatto che ogni tentativo di pianificazione sia all’atto pratico privo di significato.

Una celebre frase di Heisenhower, recita più o meno in questo modo: “Nel preparare la battaglia, mi son sempre reso conto che i piani sono inutili, ma la pianificazione è indispensabile”. Al di là della frase a effetto, il senso appare abbastanza chiaro, e viene spiegato bene da un esempio presentato nel libro “Essential Scrum” [3] in cui l’autore parla delle attività di sci estremo di un suo conoscente.

Rivolgendosi a questo sciatore estremo l’autore lo interroga sul modo migliore per scendere per la montagna a rotta di collo in mezzo a valloni, tra rocce e poi boschi. La domanda è precisa: “progetti e pianifichi ogni passaggio della tua discesa vero? Altrimenti come potresti rimanere incolume dopo tutti i rischi che ti prendi?”, e la risposta è illuminante e piuttosto attinente con la nostra trattazione: “Impossibile pianificare una discesa estrema. Troppe variabili e troppi imprevisti. Quando sono in cima alla montagna cerco di concentrarmi sul punto di arrivo e di tracciare una via di massima che mi ci porti. Ma da lassù è impossibile vedere ogni passaggio, scorgere ogni avvallamento del terreno, valutare tutte le possibili alternative. Senza contare che un cambio di vento improvviso o un tratto di neve soffice renderebbero vana ogni pianificazione. In genere lavoro molto sulla forma fisica e sulle mie attitudini da mettere poi in pratica al momento del bisogno”.

Questo è quello che dovremmo fare noi quando lavoriamo in un progetto: lavorare molto sulle abilità operative dei singoli, sulle competenze, sulla cultura. E poi prepare pianificazione, molto sensata ma anche molto flessibile, che possa definire nel modo migliore l’obiettivo finale e una via di massima per raggiungerlo. Le possibili variazioni per raggiungere tale obiettivo sono le tattiche che non possono essere pianificate, ne’ controllate, ne’ imposte dall’alto. La tattica è in carico al team non al management: e per questo il team deve essere consapevole e auto-organizzato, non un mero gruppo di esecutori alla cieca.

Quindi è fondamentale investire sulle persone e sulla conoscenza, più che sul controllo o sugli strumenti. Sull’avere un processo adattivo più che uno deterministico e fissato.

Agile manifesto

Tenendo ben presenti le considerazioni viste fin qui, spostiamoci da un generico “mondo produttivo” o “sistema industriale” a un ambito più specifico, quello dello sviluppo del software. Possiamo quindi comprendere come i concetti fin qui esposti si sposino perfettamente con il Manifesto Agile [4], alla cui base c’è proprio la presa di coscienza che la realizzazione di software è divenuta un processo industriale, e che la complessità delle variabili coinvolte in questa attività spinge per l’adozione di un modello organizzativo e di un processo di lavoro diversi rispetto alle metodiche classiche. È una serena presa d’atto dello scenario che si è andato concretizzando a partire dagli ultimi anni del secolo scorso e che ha portato alla realizzazione del manifesto all’inizio del nuovo secolo.

Partito inizialmente come iniziativa di un gruppo peraltro nutrito di progettisti software e personaggi di spicco dell’informatica, il Manifesto si è a poco a poco diffuso e i principi in esso contenuti si sono sempre più concretizzati in pratiche operative che hanno dato i loro risultati sul campo. Le metodologie nascono da questi concetti e da questi principi. Soddisfazione del cliente, abbattimento dei costi di sviluppo del software, tutela delle persone coinvolte nel processo, importanza della collaborazione, capacità di adattamento ai mutamenti dello scenario sono solo alcuni dei principi che, nello scorso decennio, hanno portato le metodologie agili da pratiche “di nicchia” a sistemi di sviluppo ormai mainstream.

Conclusione

Con questo articolo abbiamo visto in modo ulteriore alcuni importanti concetti legati alla complessità e come questi abbiano portato alla nascita del movimento agile, al ripensare completamente il modo con cui gestire in modo più efficace ed efficiente il nostro modo di lavorare e produrre beni e servizi. Lo scopo di questi tre articoli è stato di gettare delle fondamenta solide per poter passare ad affrontare più in dettaglio i temi di Lean e Agile, che vedremo nelle prossime puntate.

Riferimenti

[1] Frederick Taylor, “Principles of Scientific Management”, 1911 (trad. it., “L’organizzazione scientifica del lavoro”, ETAS, Milano, 2004)

[2] La voce “Culto del cargo” su Wikipedia

http://it.wikipedia.org/wiki/Culto_del_cargo  

[3] Kenneth Rubin, “Essential Scrum: A Practical Guide to the Most Popular Agile Process”, Addison-Wesley, 2012 

[4] Agile Manifesto 

http://agilemanifesto.org/