di Alessandra Filippetti

Nell’articolo precedente abbiamo fatto una sorta di identikit dell’azienda agile cercando di capire che caratteristiche, culturali e strutturali, abbia una ”Agile Company”.

Frugando nella nostra cassetta degli attrezzi, abbiamo trovato un bel po’ di strumenti che un’organizzazione ha concretamente a disposizione per stimolare un mindset agile e creare una struttura organizzativa che ne sostenga i valori e i principi:

  • Small Teams
  • T-Shaped People
  • Value Units
  • Semi-stable Teams
  • Replace Job Titles
  • Communities of Practice
  • Open Allocation
  • Double Linking
  • Team Number One
  • Local Rules.

Come promesso, proviamo ora a vedere insieme di cosa si tratta.

Small Teams.

È abbastanza intuitivo comprendere che un team piccolo sia più agile di uno grande e che la produttività individuale diminuisca all’aumentare delle dimensioni del team.

E, se l’intuito non bastasse a convincerci, possiamo ricordare alcuni studi e leggi che supportano questa tesi in modo (diciamo) più “scientifico”:

  • il Ringelmann Effect descrive la tendenza dei membri individuali di un gruppo a divenire sempre meno produttivi quando la dimensione del loro gruppo aumenta
  • il Numero di Dunbar quantifica il limite cognitivo teorico relativo al numero di persone con cui un individuo è in grado di mantenere relazioni sociali stabili. Per l’antropologo Robin Dunbar sono mediamente 150 le persone che possono far parte del nostro gruppo sociale e, di queste, meno di 15 quelle con cui riusciamo a mantenere relazioni intime
  • La formula C = (N x (N – 1)) / 2 (con C che rappresenta il numero di canali di comunicazione e N il numero di membri che compongono un gruppo) ci permette di calcolare il Numero di Canali di Comunicazione che ogni singolo membro deve gestire all’interno di un gruppo per comunicare con tutti gli altri.

Dato che un esempio vale più di mille parole, in un team composto da 3 persone dovremo mantenere 3 canali attivi ma se le persone diventano 9 i canali di comunicazioni diventano ben 36. Ca va sans dire!

Trovare la giusta sintesi è una questione di buon senso (e buona volontà): manteniamo i team abbastanza piccoli da rimanere agili ma sufficientemente grandi da coprire un flusso di valore riducendo al minimo le dipendenze da team esterni: piccoli team cross-funzionali che hanno al loro interno tutte le professionalità, le skill e le competenze necessarie a completare end-to-end il proprio lavoro in modo autonomo.

Come “regola del pollice” diciamo che oltre la decina di persone sarebbe meglio non andare.

T-Shaped People.

Una persona T-Shaped è uno “specialista-generalista” che affianca alla propria specializzazione verticale (come il ramo verticale della lettera T) un set ampio di competenze trasversali (come il ramo orizzontale della lettera T). Sa fare tante cose e, almeno su una, è un vero guru.

È invece I-Shaped (verticale come la lettera I) lo “specialista puro”, a cui ci hanno abituati i grandi team e i silos delle organizzazioni tradizionali, super esperto di qualcosa ma che ignora tutto il resto.

Ne accennavo parlando di Specialization VS Generalization: la vera innovazione è compatibile solo con persone che hanno maturato quella visione sistemica, la capacità di vedere olisticamente il tutto oltre la parte, che è tipica della connotazione T-Shaped.

L’essere T-Shaped, inoltre, protegge un team agile da una sua caratteristica che è al tempo stesso il suo punto di forza e il suo punto di debolezza: la sua dimensione.

Un team piccolo è, infatti, estremamente fragile in condizioni di incertezza e può entrare più facilmente in crisi per l’assenza, più o meno temporanea, di uno dei membri del team (in un team piccolo avremo meno persone con skill sovrapponibili).

Il “Bus Factor”, concetto popolare nella comunità agile, ci aiuta a rispondere alla domanda (un po’ splatter alla Quentin Tarantino): “Quanti membri del tuo team possono essere investiti da un autobus e uccisi prima che il tuo team vada in crisi?”. Se la risposta è 1 (Bus Factor = 1) meglio accendere un cero a Sant’Antonio perché l’autobus assassino avrà probabilmente ucciso l’unico collega in grado di svolgere una certa attività.

Stimolare la contaminazione e la cross-pollination nei nostri team ci aiuterà a superare più “agilmente” i momenti di difficoltà.

Value Units.

Piuttosto che organizzare le persone per progetto o, peggio ancora, per aree specialistiche verticali, allochiamo i team su processi core inter funzionali e flussi di valore, eventualmente supportati da unità specialistiche condivise.

Semi-stable Teams.

I team più performanti sono quelli che rimangono stabili più a lungo (long-lived teams).

Diversi sono gli studi e i modelli (Satir’s Curve e il Modello Kübler-Ross tanto per citarne due)  che mostrano come la produttività diminuisca se la composizione del team cambia e/o a causa di cambiamenti organizzativi.

Ovviamente un numero limitato di piccole variazioni può essere fisiologico e salutare anche per i team stabili ma evitiamo di fare il gioco delle tre carte con le persone nell’illusione di aumentare la produttività: squadra vincente non si cambia!

Replace Job Titles.

Il concetto di ruolo fisso è obsoleto e tende a limitare il contributo delle persone alle attività che si pensa siano congruenti rispetto al perimetro tracciato dal ruolo formale. Spingiamo piuttosto le persone a coltivare la capacità di adattamento, flessibilità e trasversalità, doti imprescindibili per cogliere le opportunità in contesti mutevoli e liquidi come quello attuale.

Communities of Practice.

Stimolare le persone a creare e a partecipare a Community of Practice (CoP): gruppi di persone che condividono problemi, interessi, passioni e, interagendo costantemente, accrescono le proprie conoscenze e competenze, trovano soluzioni, trasformano scoperte locali in miglioramenti globali.

Open Allocation.

Nessuno può convincere qualcun altro a fare qualcosa, meno ancora convincerlo a farla bene, imponendo la scelta dall’alto: possiamo portare un cavallo al fiume ma non costringerlo a bere!

Lasciare che le persone scelgano i progetti che li stimolano di più e il team di cui far parte è il modo migliore per incoraggiare la motivazione, l’impegno e la responsabilità.

A meno che non si tratti di una questione di vita o di morte, alle persone dovrebbe essere lasciato questo margine di discrezionalità se vogliamo davvero che diano valore.

Double Linking.

Cerchiamo di ridurre al minimo le dipendenze tra i team ma, tra team dipendenti, creiamo e manteniamo vivi i collegamenti: link bidirezionali che, come ambasciatori, connettono i team, accorciano il feedback loop e aiutano a prendere decisioni basate sul consenso.

Team Number One.

Il multitasking va scoraggiato sempre: idealmente ogni persona dovrebbe essere 100% dedicata ad un obiettivo alla volta.

Il nostro cervello non è multitasking e il continuo context switching penalizza la produttività, la concentrazione, ci impedisce di raggiungere lo “stato di flusso” e compromette il raggiungimento degli obiettivi.

Che ci piaccia o meno, multitasking vuol dire iniziare tante cose e non chiuderne nessuna.

Tuttavia, in casi eccezionali e per un tempo limitato, è possibile che si debba fornire un contributo su più iniziative contemporaneamente.

In questi casi assicuriamoci almeno che le persone sappiano esattamente a quale team o iniziativa rivolgere la loro priorità.

Local Rules.

Lasciamo che ogni team si auto organizzi e operi secondo le proprie regole, a patto che queste siano in armonia con l’ecosistema organizzativo e culturale in cui operano.

Per concludere.

Nessuno ci obbliga a diventare agili: ben al di là delle buzzword e delle mode del momento, l’agilità è una scelta.

Una scelta, strettamente connessa al nostro “Why”, alla nostra sopravvivenza e alla nostra crescita, che dovremmo fare quando realizziamo che quello che funzionava ieri, 3 mesi fa o 5 anni fa, semplicemente, oggi non funziona più.

Non c’è una ricetta preconfezionata per diventare agili e la strada da percorrere per diventarlo è irta di ostacoli e difficoltà, costellata da successi, fallimenti e ripartenze.

Un obiettivo ambizioso da perseguire con coraggio, dedizione, serietà e impegno perché l’agilità è una questione profondamente umana che ha a che vedere con le persone molto più che con gli strumenti, gli approcci o i tool.

Linkografia:

https://management30.com/

https://hbr.org/2011/05/two-structures-one-organizatio

https://hbr.org/2004/04/the-ambidextrous-organization

https://www.linkedin.com/pulse/hierarchies-networks-naomi-stanford/?trk=articles_directory

https://hbr.org/2018/05/agile-at-scale

Alessandra Filippetti

Sono Alessandra Filippetti, appassionata Agile Evangelist. Adoro la birra artigianale, mangerei sushi anche a colazione e sono Queen e Freddie Mercury dipendente. Odio annoiarmi, sono curiosa come un gatto e allergica alla banalità, alla burocrazia e alla mancanza di gentilezza e coraggio. Dopo aver maturato un’esperienza ventennale come manager IT ed aver guidato molti progetti come Project Manager nel 2010 sono “inciampata”, quasi per caso, negli approcci agili ed è stata illuminazione sulla via di damasco! Da allora ho fatto dell’agile il mio mestiere e, da Project Manager “pentita”, ho abbracciato il lato agile della forza. Socia e volontaria del PMI Central Italy Chapter dal 2013 e, dal 2018 del’Italian Agile Movement, ho fondato AgilePlaza, la mia startup totalmente focalizzata su servizi di Formazione, Consulenza e Coaching Agile & DevOps. Ma questo è solo … il primo Sprint!  Se volete rimanere in contatto con me, mi trovate su Linkedin e su Facebook oppure scrivete a alessandra.filippetti@agileplaza.it