Questo articolo è apparso originariamente in inglese su agile monocle, la newsletter in cui parlo di agile non come un martello ma come di una lente attraverso cui osservare il lavoro che facciamo.

Questo articolo riguarda le dinamiche, in particolare le dinamiche di team e organizzative.

Molto spesso agile viene associato a delle mere meccaniche: sia Scrum che Kanban offrono più di un modo per essere resi stupidi e derubati dei loro valori e principi originari, al punto di diventare semplicemente delle checklist di cose da fare per essere agili — “fai lo standup, fai la retrospettiva, controlla la tua velocity, controlla il work-in-progress, girati a destra, girati a sinistra, fai un salto, sorridi, sorridi di più, #happynessatwork”.

Ti propondo di aprire la mente e gli occhi, e di dare un’occhiata a come davvero le cose si muovono all’interno di un team e di una organizzazione, ci stai?

Hai mai visto un team stabile?

Adoro il lavoro che Heidi Helfland ha fatto per sgretolare il mito del team piccolo, stabile, autonomo e cross-funzionale che non è mai esistito nella storia dei team.

In questo video di 15 minuti spiega i concetti di base del suo libro, “Dynamic Reteaming”, che ha scritto basandosi sulle sue esperienze professionali, non basandosi su qualche applicazione teoretica di Scrum o di, iddio che ne scampi, del Modello Spotify. Se sei interessato a qualcosa di più lungo e che entra maggiormente nel dettaglio dei concetti c’è una una versione più lunga:

“If change is constant, you better get good at it”

Mi ha fatto pensare a quanto, come consulenti, ci piace parlare del modello di Tuckman, ma non offriamo mai consigli pratici sul come gestire le differenti fasi di un ciclo di vita di un team. L’approccio di helfland mi ha fatto pensare che il modello di Tuckman potrebbe non essere nemmeno il miglior modo per imparare e insegnare come approcciare le dinamiche di team, mentre il modello ecocycle/panarchy è sicuramente più adeguate — ma questo è argomento per un altro articolo…

Quello che succede spesso che mettiamo troppo valore nella stabilità e nella permanenza di un team: i team non sono mai davvero stabili e dovremmo gestire questa dinamicità con approcci adeguate — ad esempio imparando a gestire le dinamiche senza forzare modelli statici e meccaniche prescrittive.

Hai mai visto un team cross-funzionale?

Sempre sul tema “cose che esistono solo nella teoria”, dopo il concetto di team stabile, vediamo quante volte abiamo sentito quanto fosse buona l’idea di organizzare l’intera azienda o il dipartimento sviluppo prodotti basandoli su un certo numero di team piccoli e cross-funzionali, e di come questo fosse un requisito obbligatorio per l’agilità.

Ma che succederà mai se non abbiamo un team cross-funzionale? Aspettate un momento: mi state dicendo che un team cross-funzionale è l’unica soluzione alla pandemia, alla fame nel mondo e per il raggiungimento della pace nel mondo?

Questo è un articolo interessante per molte ragioni: in primis, parla di tecnologia. Inoltre descrive una evoluzione organizzativa nel corso del tempo. Poi prende in considerazione sia problemi tecnologici che organizzativi (avete forse notate che, ad un certo punto, ci siamo dimenticati che la maggior parte dei principi agili arrivano dal mondo del software…). Infine: questo articolo affronta la realtà che non tutti i team sono e possono essere ricondotti al mitico team, piccolo, autonomo, e cross-funzionale che Scrum predica come essenziale al fine del raggiungimento dell’agilità

Un altro, ultimo punto, forse più importante dei precedenti, per chiudere: non viene prescritto un modello organizzativo, ma vengono aperte una serie di possibilità e scenari su come evolvere nel tempo, dato che saremo sempre e per sempre coinvolti nel processo di cambiare l’organizzazione.

Di nuovo: se devi cambiare costantemente, è meglio diventare molto bravi a farlo. Alcuni strumenti che ci possono venire in soccorso, sono il Wardley Mapping e i concetti di Team Topologies.