Autonomia vs. Etero-determinazione

Praticamente ogni grande azienda tecnologica è ormai salita sul treno dei team di prodotto autonomi, impegnati/stabili, interfunzionali e ben collaborativi, e credo che questo sia positivo. Si vede raramente un'azienda che utilizza ancora i vecchi modelli (principalmente il modello Pool). Tuttavia, a volte non è facile trovare la giusta combinazione di autonomia ed etero-determinazione.

I risultati parlano da soli, tuttavia attribuisco la maggior parte dei vantaggi alla maggiore motivazione e alla vera comprensione dell'ownership che nasce quando i team hanno la sensazione di poter decidere autonomamente del proprio lavoro.

Ma anche se i team leader mi dicono per lo più che i loro team sono autonomi e auto-organizzati, molti membri del team la vedono spesso diversamente. Quando questo è il caso, cerco di scoprire cosa esattamente il team non può decidere da solo o in cosa si sente limitato.

Dove passa il confine tra autonomia ed etero-determinazione?

Di solito si riduce a una delle seguenti due risposte:

O il team non gode ancora pienamente della fiducia del management e quindi il management non vuole davvero dare mano libera ai membri del team.

Oppure il team vorrebbe cambiare qualcosa che il management considera parte delle basi fondamentali.

In linea di principio, tutti i team concorderebbero che ci sono sia alcune cose che possono decidere in completa libertà, sia altri ambiti che fanno parte dei prerequisiti comuni per tutti i team.

Un esempio

In quest'ultimo caso, sarebbe ad esempio molto insolito se ogni team scegliesse un proprio strumento di versionamento. Se il team di sviluppo ha fissato GitHub come standard, questo viene normalmente considerato parte dei prerequisiti fondamentali. Anche se un team avesse una forte preferenza per un altro strumento, i costi supererebbero di gran lunga i vantaggi per l'azienda.

Questo esempio è piuttosto chiaro, tuttavia ce ne sono molti altri dove non è così evidente.

Ogni team dovrebbe ad esempio poter gestire l'automazione dei test a modo proprio? I team dovrebbero poter scegliere individualmente il linguaggio di programmazione? E il framework per le interfacce utente? E la compatibilità con i browser? E le feature costose come il „supporto offline”? Dovrebbero poter decidere da soli quanto „agili” vogliono essere? E ogni team deve davvero essere coinvolto in più iniziative di prodotto aziendali?

Come spesso accade con i prodotti, alla fine si tratta di un compromesso – in questo caso è un compromesso tra autonomia e rispetto delle basi stabilite.

Anche se in linea di principio sono molto favorevole al principio dei team autonomi e indipendenti, ammetto anche di essere un grande sostenitore dell'investimento in buone basi. Con una solida base comune, i team possono creare prodotti ed esperienze eccezionali molto più velocemente.

Vorrei illustrare un po' più da vicino questo compromesso. Voglio però anche sottolineare che non sostengo che ci sia una sola risposta a questa domanda, ma che può essere diverso per ogni azienda e ogni team. Tutto dipende da diversi fattori che spiegherò qui:

Punti da considerare:

– La competenza del team:

Ci sono fondamentalmente tre situazioni diverse:

A-Team – un team esperto con persone intelligenti e creative, di cui ci si può fidare completamente per prendere buone decisioni.

B-Team – queste persone hanno le giuste intenzioni ma in molti casi non hanno ancora l'esperienza necessaria per prendere buone decisioni, motivo per cui hanno ancora bisogno di un po' di supporto.

C-Team – un team junior che forse non sa nemmeno ciò che non sa. Senza un accompagnamento intensivo, questi team possono involontariamente causare grandi difficoltà.

– Velocità:

Uno dei principali argomenti a favore di regole fisse è la velocità. La logica è che i team dovrebbero poter costruire sul lavoro dei colleghi, così da non sprecare tempo a reinventare la ruota. Tuttavia, in alcuni casi è generalmente accettato e usuale permettere ai team di lavorare anche un po' più lentamente e di fare qualcosa in duplice copia, se ciò favorisce l'autonomia. A volte però è essenziale per il business attenersi alle regole stabilite.

– Importanza dell'integrazione:

In alcune aziende, il portfolio è costituito da prodotti correlati ma per lo più indipendenti tra loro, dove integrazione e regole non sono particolarmente importanti. In altre aziende, il portfolio riguarda prodotti fortemente integrati, dove certe regole comuni sono indispensabili. In definitiva, dipende se un team debba concentrarsi su un'unica soluzione specifica o se debba trovare una soluzione ottimale dal punto di vista dell'intera azienda.

– Fonte di innovazione:

Se le principali fonti di innovazione futura si trovano già nelle basi, i team dovrebbero avere più libertà di ripensare questi elementi fondamentali. Se invece le origini dell'innovazione si trovano a livello di soluzione, il team dovrebbe concentrarsi meno sulle basi e più su innovazioni creative a livello applicativo.

– Dimensione dell'azienda e sedi:

L'autonomia diventa spesso difficile quando si verificano problemi di scalabilità. Quando le aziende crescono e i loro team sono distribuiti in diverse sedi, diventa più difficile ma anche più importante stabilire certe regole di base. Alcune aziende cercano di risolvere questo problema con il concetto di "Center of Excellence" (centro di competenza), riunendo un team che lavora insieme a un compito in una sede specifica. Altre provano con ruoli più olistici. E altre ancora aggiungono processi.

– Cultura aziendale:

Anche nella cultura del team il rapporto tra autonomia ed etero-determinazione gioca un ruolo importante. Più regole un'azienda impone, più i team hanno la sensazione di essere limitati nella loro autonomia. Per i B-Team e i C-Team questo può essere ancora accettabile, per gli A-Team è però già più problematico.

– Maturità della tecnologia:

Voler stabilire troppo presto una base unitaria per tutti è un problema frequente. Se la base non è ancora matura, non può offrire il supporto per cui era pensata. Insistere troppo sull'implementazione delle regole prima che le basi siano realmente pronte può davvero danneggiare i team, che devono potersi affidare alle basi. È come voler costruire qualcosa su un castello di carte traballante.

– Rilevanza per il business:

Se partiamo dal presupposto che la base sia solida, ci sono più rischi per un team che non utilizza queste basi. In alcuni casi potrebbe non essere grave. Quando però si tratta di prodotti o iniziative cruciali per il business, bisogna considerare bene su cosa concentrarsi.

– Grado di responsabilità:

Un ulteriore fattore è il grado di responsabilità che accompagna l'autonomia e l'indipendenza. Se i team non hanno responsabilità propria – e soprattutto se non ci sono team A forti – i team non hanno nemmeno un vero motivo per prestare particolare attenzione a questo compromesso. Si vuole però che i team riflettano su questo compromesso. Se so che il team è forte e pienamente consapevole dei rischi e delle conseguenze e tuttavia vuole ignorare o sostituire un componente essenziale delle basi, allora sostengo i membri del team in questa decisione.

Riepilogo

Come vedete, ci sono molti punti da considerare. A mio parere, la maggior parte dei team è però molto ragionevole quando si affrontano apertamente questi temi. A volte bastano al team alcune domande fondamentali sugli impatti per poter prendere decisioni migliori riguardo a questo compromesso.

Se però i team prendono permanentemente decisioni sbagliate in merito, dovreste riconsiderare il grado di esperienza nel team e forse investire più tempo per assicurarvi che i membri del team comprendano davvero tutte le correlazioni aziendali.

Questo testo proviene dal blog di Marty Cagan ed è stato tradotto in italiano da noi.