Team auto-organizzati – ecco come funziona

La capacità di auto-organizzarsi è fondamentale in tutte le metodologie agili, incluso Scrum. In effetti, i team auto-organizzati sono uno dei principi fondamentali del Manifesto Agile, che afferma che “le migliori architetture, requisiti e design emergono da team auto-organizzati”.

Quando si tratta di come raggiungere al meglio un obiettivo desiderato, alcuni team sceglieranno di lasciare le decisioni su tutte le questioni tecniche importanti a una persona nel team.

Altri team sceglieranno di suddividere la responsabilità per le decisioni tecniche lungo i confini tecnici: l’esperto di database prende le decisioni sul database e il programmatore con più esperienza in Python prende le decisioni su Python.

Altri team ancora potrebbero decidere che chiunque stia lavorando a una determinata funzionalità può prendere la decisione, purché comunichi i risultati della decisione al team.

Non tutti i team agili si auto-organizzano allo stesso modo

Ci sono due punti principali:

• Non tutti i team agili si organizzeranno allo stesso modo e questo va benissimo.
• Si organizzerà meglio il lavoro utilizzando la conoscenza collettiva del team, piuttosto che affidarsi solo alla conoscenza di un singolo responsabile del personale.
  Il vantaggio dei team auto-organizzati non è che il team trovi un modo ottimale di organizzare il lavoro che un manager non gli ha mostrato. Il vantaggio di permettere al team di auto-organizzarsi è piuttosto che il team si sente incoraggiato a essere responsabile del proprio lavoro.

Possiamo davvero aspettarci che i team agili siano auto-organizzati?

Una critica diffusa verso i team auto-organizzati è: “Non possiamo semplicemente mettere insieme otto persone qualsiasi, dire loro di auto-organizzarsi e poi aspettarci un risultato positivo”.

Beh, non sono sicuro che mettere insieme otto persone qualsiasi e aspettarsi un risultato positivo non sia fondamentalmente problematico, ma un team agile non dovrebbe comunque essere un gruppo di persone messe insieme a caso. In effetti, coloro che nell’azienda sono responsabili dell’avvio di un progetto Scrum dovrebbero selezionare con cura i singoli membri del team.

Il management esercita un controllo sottile sull’auto-organizzazione

Nel documento originale su Scrum, The New New Product Development Game, Takeuchi e Nonaka hanno identificato il “controllo sottile” come uno dei sei principi. Le decisioni sul personale vengono indicate come una delle principali responsabilità del management.

Scegliere le persone giuste per un team di progetto e al contempo osservare i cambiamenti nelle dinamiche di gruppo, aggiungendo o rimuovendo membri del team quando necessario, è una delle principali responsabilità del management.

“Inseriamo un membro del team più anziano e un po’ più conservatore se il team diventa troppo radicale”, spiegò un manager di Honda. “Dopo un’attenta riflessione scegliamo con grande cura i membri del nostro progetto. Analizziamo le diverse personalità per capire se vanno d’accordo tra loro.”

Inserire le persone giuste nel team agile

Se sei un responsabile del personale o influenzi in altro modo la composizione dei team nella tua azienda, ecco alcune cose a cui dovresti prestare attenzione:

Considera tutte le discipline necessarie nei team agili
Per i team interdisciplinari è importante che tutte le competenze necessarie dall’idea alla funzionalità implementata siano rappresentate nel team. Questo può significare che il team inizialmente sia un po’ più grande del desiderato.

Mix di diversi livelli di qualifica tecnica nei team agili

Quando si parla di dimensione del team, bisognerebbe sempre cercare di stabilire un rapporto equilibrato tra i diversi livelli di qualifica nel team. Se un team ha tre sviluppatori Senior e nessun programmatore meno esperto, gli sviluppatori esperti devono programmare anche funzionalità meno importanti che potrebbero annoiarli.
Non solo un programmatore Junior avrebbe probabilmente svolto volentieri questo lavoro, ma avrebbe anche beneficiato della collaborazione con il collega esperto.

Rapporto equilibrato di competenze specialistiche nei team agili

Oltre a un rapporto equilibrato delle competenze tecniche, dovremmo anche stabilire un buon equilibrio tra i membri del team che possiedono una profonda competenza specialistica e il problema che stiamo cercando di risolvere.
Questo non significa che non dovremmo mai avere un team composto interamente da esperti, se ne abbiamo l’opportunità. Piuttosto dovremmo considerare gli obiettivi a lungo termine dell’organizzazione.
Uno di questi obiettivi è sicuramente la costruzione di competenze specialistiche nell’azienda. Raggiungere questo obiettivo sarà difficile se tutti gli esperti sono nello stesso team.

Diversità nei team agili

Diversità può significare molte cose: genere, provenienza e cultura sono solo alcuni esempi. Altrettanto importante può essere il modo diverso in cui i membri del team affrontano i problemi, prendono decisioni, quante informazioni necessitano per una decisione ecc.
Le ricerche hanno dimostrato che i team omogenei raggiungono il consenso più velocemente dei team eterogenei. Lo raggiungono però solo perché non sono in grado di considerare tutte le opzioni possibili.

Perseveranza nella composizione dei team agili

Anche i membri dei team agili hanno bisogno di un po’ di tempo per imparare a lavorare bene insieme. Cercate quindi di mantenere nello stesso team i membri che hanno collaborato bene in passato. Quando componete un nuovo team, pensate anche a quanto tempo i membri del team potranno presumibilmente lavorare insieme prima che alcuni o addirittura tutti debbano dedicarsi ad altri impegni.

Obiezioni frequenti ai team auto-organizzati

Ci sono alcune obiezioni all’auto-organizzazione dei team:

1) Una persona dominante prende tutte le decisioni

Una preoccupazione frequente è che una personalità dominante – ad es. il responsabile tecnico – decida che auto-organizzazione significa che lui o lei prende tutte le decisioni.

Oppure una personalità dominante impone al team la sua opinione prima ancora che il team abbia avuto la possibilità di discutere l’argomento.

Non appena noti qualcosa del genere, dovresti prendere da parte la persona in questione e chiarire la problematica. Fai capire alla persona che, anche se pensa di conoscere la soluzione giusta, a volte dovrebbe trattenere la propria opinione e dare agli altri la possibilità di condividere i propri pensieri.

Chiedi alla persona se crede che il team sarebbe in grado di prendere la decisione giusta se formulasse i suoi pensieri più come un’opinione che come una decisione incontestabile.

Sfrutta l’aiuto di questa persona come mentore per il team – il suo compito non dovrebbe essere solo assicurarsi che vengano prese le decisioni giuste, ma piuttosto che i membri del team crescano e possano prendere le decisioni giuste anche in progetti futuri in cui questa persona potrebbe non esserci per loro.

2) Il mio team si aspetta che lo Scrum Master organizzi tutto

Una seconda preoccupazione che molti hanno è che il team sia troppo passivo per l’auto-organizzazione e si aspetti invece che lo Scrum Master o il coach prenda l’iniziativa e prenda decisioni importanti per loro.

Se ciò accade, assicurati che i membri del team comprendano che il compito dello Scrum Master è supportarli, non prendere decisioni al posto loro. Se tu stesso ricopri il doppio ruolo di Scrum Master/membro del team, naturalmente non devi sempre reprimere la tua opinione e puoi anche prendere la parola.

In ogni caso dovresti cercare modi per coinvolgere gli altri e non prendere tutte le decisioni da solo. Ad esempio, chiedi prima agli altri membri del team prima di esprimere la tua opinione.

3) Il team è troppo inesperto per l’auto-organizzazione

Una terza obiezione all’auto-organizzazione è spesso che i team sono troppo inesperti per organizzarsi da soli.

Non ho mai visto un team troppo inesperto per l’auto-organizzazione. Se i membri del team hanno abbastanza esperienza per costruire un prodotto software, molto probabilmente hanno anche abbastanza esperienza per capire come lavorare in modo auto-organizzato.

In caso contrario, dovresti supportare il team con training e coaching.

Nella maggior parte dei casi questa obiezione significa solo che non ci si fida che il team sia auto-organizzato come si vorrebbe. Peccato! Esercita un controllo sottile sul team; attraverso la composizione del team e l’obiettivo che dai al team, e non attraverso il “come” nel lavoro quotidiano del team.