Agile Teams: stabilità, lunga durata e performance

Competere da protagonisti nel mercato digitale e globale significa essere in grado di fornire al cliente un flusso costante di valore, attraverso la realizzazione di prodotti e servizi di alta qualità. La prestazione dei team di lavoro che producono tali risultati è certamente un fattore chiave per il raggiungimento di quegli standard.

I team Agile sono stati pensati proprio in quella direzione: team piccoli, auto-gestiti, inter-funzionali,
preferibilmente co-localizzati e di lunga durata.

Uno degli elementi chiave dell’equazione è proprio la creazione di team stabili e di lunga durata.

I team stabili sviluppano, nel tempo, dinamiche comportamentali e legami personali e lavorativi più forti, raggiungono a loro interno un livello più elevato di trasparenza, che favorisce l’instaurarsi di un clima di fiducia e collaborazione.

Per raggiungere con successo quello stato, ogni nuovo team evolve passando attraverso una serie di fasi di sviluppo e maturità. Uno dei modelli più citati per descrivere questa evoluzione è il modello Tuckman Stages.

In questo articolo esploreremo quel modello, evidenziandone punti di forza e debolezza; descriveremo poi come creare i presupposti per il raggiungimento di ottime prestazioni, esplorando infine l’euristica 60-30-10.

Modello Tuckman Stages

Nel 1965, Bruce Tuckman sviluppò e pubblicò una ricerca sulle interazioni tra le persone appartenenti a un gruppo di lavoro e al suo successivo sviluppo in un vero e proprio team; questo studio portò alla creazione di un modello che prese il suo nome.

Quel modello prevedeva quattro principali fasi di maturazione di un team, in relazione al grado di produttività nel tempo:

• Forming: rappresenta la fase iniziale in cui, i membri del team, tendono a sviluppare un primo senso di appartenenza al gruppo; vengono condivisi valori di riferimento e allineati poi alla visione aziendale; si vivono le prime esperienze comuni e le persone si predispongono a fidarsi l’una dell’altra.
• Storming: fase successiva in cui i le persone appartenenti al gruppo iniziano a confrontarsi su ruoli, responsabilità e modalità di lavoro; possono verificarsi conflitti a causa del tentativo dei singoli di trovare il “proprio posto” e imporre proprie individualità e leadership. Le performance tendono a calare, anche in maniera importante.
• Norming: dopo aver superato con successo il passaggio precedente (da non dare per scontato), il team definisce finalmente norme, metodi di lavoro e affina ruoli e responsabilità. Il senso di unità del team (inizialmente solo superficiale) ora è reale, effettivo. Le performance ricominciano a salire.
• Performing: finalmente il team ha raggiunto una discreta stabilità nelle dinamiche interne; ciò rende possibile generare valore di business continuo, producendo ottimi risultati. Il team è in grado di auto-gestirsi; riflette e migliora costantemente il proprio processo e le pratiche di lavoro adottate.

Il modello sopra descritto è di facile comprensione: presenta una sequenza logica di fasi e mostra chiaramente l’impatto di ciascuna sulla produttività nel tempo.

Nella pratica, presenta però alcune aree di debolezza.
Innanzitutto, potremmo pensare che le fasi siano discrete e lineari nel loro susseguirsi. Non è così.

A seconda del contesto, delle persone coinvolte, delle loro competenze e del lavoro da svolgere, il team può passare da una fase all’altra del modello, più o meno rapidamente, regredire nelle dinamiche interne o crescere di maturità in pochissimo tempo rispetto all’atteso.

Negli anni seguenti alla sua pubblicazione, la comunità scientifica sottolineava che quel modello dovesse essere considerato più una “dichiarazione concettuale” che la realtà; sembra infatti che, ancora oggi, esso sia privo di una convalida effettiva sul campo.

Uno studio condotto dal Ministero della Difesa degli Stati Uniti in collaborazione con la Defense Acquisition University mostra che in team formati da pochi membri, con forte competenza e motivazione, le fasi descritte dal modello Tuckman, siano fortemente sovrapposte.

A ben vedere, in effetti, la fase Storming sarebbe molto limitata nella sua ampiezza ma estesa nel tempo, portandola ad essere chiamata “Brainstorming“: momenti in cui il team riflette in modo produttivo, non conflittuale, su come diventare più efficaci. Questo implica che la fase di Norming persista fino al termine.

Team agile: acrobati dell’incertezza

I team agili sono piccoli come dimensione (non più di dieci persone), composti da persone molto competenti, progettati per avere completa autonomia decisionale nel selezionare e applicare la modalità di lavoro più efficace. Condividono valori e principi ed hanno chiari missione ed obiettivi da perseguire.

Sono inter-funzionali, al fine di aumentare la competenza interna complessiva e, infine, sono co-locati fisicamente o “digitalmente” per favorire la comunicazione e accelerare la conoscenza inter-personale.

Sembra, quindi, che i team Agile si adattino naturalmente molto bene allo studio appena descritto.

Cosa possiamo dire rispetto alla loro stabilità e lunga durata?

Rimuovere o spostare persone da un team in un altro è, in generale, una pessima pratica.

Questa situazione interrompe i legami e le dinamiche creatisi e forza il team – qualsiasi team – a dover pagare un costo di adattamento alla nuova configurazione, passando nuovamente attraverso tutte o alcune delle quattro fasi del modello sopra descritto. Uno spreco di risorse importante, che impatta anche fortemente sulla motivazione del team stesso nel caso che circostanze come questa siano la norma.

Gli impatti di queste inefficienze si osservano quando i prodotti di quelle aziende arrivano sul mercato spesso in ritardo rispetto alle attese, con costi maggiori e qualità non impeccabile, palesandosi, in ultima analisi, con una scarsa soddisfazione del cliente.

È anche vero, però, che l’alta volatilità e incertezza dei mercati possono minacciare la stabilità di quei team a seguito, per esempio, di una delle seguenti motivazioni:

• nuove competenze necessarie nel team, per procedere nel lavoro;
• necessità di incrementare la produttività, aumentando il numero di persone;
• dimissioni di uno dei membri del team (oggi le persone tendono a cambiare lavoro con maggiore frequenza rispetto al passato);
• ri-organizzazioni aziendali, che accadono con maggiore frequenza.

Per queste ragioni, pur rimanendo la stabilità una condizione necessaria da perseguire sempre, i team – e quelli Agile più di tutti – hanno bisogno di incrementare adattabilità e velocità nel modo in devono “ricomporsi” a seguito di uno degli eventi sopra descritti.

Ogni team è infatti un sistema complesso adattivo, che dimostra la sua maturità resilienza proprio quando, a valle di un evento traumatico che ne ha cambiato il suo stato di equilibrio, è in grado di trovarne uno nuovo in tempi brevi.

I team Agile, grazie alla loro natura, sono in grado di adattarsi al meglio a simili circostanze.

Euristica 60-30-10

Esiste un fattore molto importante che influenza direttamente la stabilità dei team: come questi vengono progettati.

Una scarsa progettazione potrebbe avere conseguenze molto negative su performance e durata degli stessi; una mancanza di attenzione per quella fase può portare ad un aumento del livello di conflittualità interno, ben oltre la soglia del sano e critico confronto necessario a un gruppo di lavoro per eccellere.

Richard Hackman e Ruth Wageman hanno coniato un’euristica che aiuta a pensare a come iniziare con il piede giusto fin dal momento del concepimento di un nuovo team: la “regola del 60-30-10”.

Quella regola identifica delle percentuali di riferimento, in terimini di tempo ed energia, che dovrebbero essere spese per le seguenti attività:

• 60% a come i team vengono progettati, disegnati;
• 30% a come questi vengono “lanciati”;
• 10% a come vengono poi supportati attraverso il coaching.

Progettazione del team

Considerando l’enorme importanza che i due autori Hackman e Wageman danno alla progettazione dei team, approfondiamo di seguito la tematica.

Riguardo al favorire la stabilità, all’atto della creazione di un team è necessario analizzare e capire se, nel portfolio di iniziative e progetti correnti, ne esistesse un gruppo omogeneo (stesso prodotto o categoria di prodotti, stessa tipologia di clienti cui fornire valore anche attraverso prodotti diversi, ecc.) in grado di assicurare al team una buona continuità lavorativa nel lungo periodo.

O ancora se, per determinati prodotti o servizi, sussista una costante richiesta di aggiornamento da parte di un mercato particolarmente dinamico, da giustificare la creazione di team di lunga durata.

Nel passaggio successivo, si passa poi a stimare dimensione e composizione del team.

È inoltre consigliato, per chi si sta occupando di “disegnare” quei team, di compilare una prima versione della missione che il team dovrà perseguire (in seguito questa verrà rivista e affinata dai membri dello stesso) riportando anche gli obiettivi aziendali da raggiungere.

È quindi necessario identificare una persona lato business, esperta di dominio, che avrà il compito di lavorare a stretto contatto con il gruppo di lavoro per facilitarne il raggiungimento della missione. Questa figura, negli “ambienti” Agile, è rappresentata dal Product Owner.

In relazione al lavoro che ogni team dovrà svolgere verranno quindi identificate le competenze necessarie, fattore che può influenzare fortemente la dimensione dello stesso.

La fase di progettazione dei team viene spesso svolta dai manager. Essi selezionano le persone in base alla loro attuale allocazione, alla competenza e, talvolta, speculando anche sul rapporto personale che intercorre tra i futuri componenti. Constatiamo che non sempre vengono tenuti in considerazione alcuni fattori importanti quali, per esempio, le attitudini personali o gli interessi dei singoli ad acquisire nuove competenze. Più in generale, il rischio che si corre è che una scelta calata dall’alto, in mancanza di informazioni specifiche e rilevanti, possa portare a decisioni non corrette.

La risultante potrebbe essere “assemblare” team che si rilevano non efficienti, i cui scarsi risultati conducono spesso a una revisione della composizione dello stesso, situazione che avrebbe un effetto negativo proprio sulla condizione che stiamo cercando di creare: stabilità e lunga durata.

Auto-selezione del team

Una buona pratica, in tal senso, è l’auto-selezione del team di appartenenza da parte delle singole persone. L’idea sottostante è quella di consentire a tutte le persone coinvolte, di selezionare in autonomia i team di cui vorrebbero far parte, partecipando a workshop dedicati.

Nello specifico, durante questi eventi, a ogni team viene dedicato una spazio in una stanza dove su una parete vengono appesi stampe e cartelloni contenenti tutte le informazioni pertinenti missione, obiettivi ed eventuali vincoli che dovranno essere tenuti in considerazione per la formazione della squadra (es. numero massimo di persone, competenze, eventuali fattori di diversità, autonomia nella creazione e consegna di valore, ecc.).

I vari Product Owner rimangono negli spazi riservati ai loro team; le persone si spostano informandosi e parlando con essi ed eventuali altri esperti di dominio, raccogliendo informazioni di dettaglio e discutendo tra loro per comprendere quale possa essere il team in cui ciascuno può fornire il maggior valore.

A scelta effettuata, ogni persona appende la propria scheda personale (riportante foto, competenze, interessi, progetti cui si è partecipato, ecc.) nel rispettivo spazio del team prescelto. Il Product Owner e gli altri stakeholder interessati facilitano quindi la discussione per arrivare al perfezionamento finale e agli adeguamenti nella composizione delle squadre.

Questo approccio aumenta considerevolmente motivazione, responsabilità dei singoli e pone solide basi per una buona, futura resilienza del team.

Un ultimo, importante effetto positivo di questo approccio sta nel fatto che, anche qualora la stabilità del team fosse messa a rischio a cause di fattori esogeni, con buona probabilità il team stesso saprà auto-organizzarsi nella ricerca della migliore soluzione possibile.

 

Articolo a cura di Emiliano Soldi