Autonomia vs. Iniziativa

Per continuare la serie sull'autonomia dei team, dopo Autonomia vs. Incarico vorrei aggiungere questo importante aspetto all'argomento. Si tratta degli effetti che le grandi iniziative con molti team hanno nella pratica.

Cos'è un'iniziativa?

Quando dico “iniziativa”, mi riferisco allo sforzo lavorativo per un prodotto in cui sono coinvolti molti team. Potrebbe essere qualcosa del tipo: la revisione dell'usabilità di un sito web, il passaggio al Responsive Design, un'internazionalizzazione o l'ingresso in nuovi mercati significativi come ad esempio la Cina. Tutte queste sono fondamentalmente cose piuttosto importanti che però normalmente richiedono lo sforzo congiunto di diversi – se non di tutti – i vostri team di prodotto.

In linea di principio, anche la ristrutturazione di una piattaforma per una migliore scalabilità o prestazioni – come ad esempio una nuova architettura o nuove basi tecnologiche – è un tipo di iniziativa. Tuttavia, con questo debito tecnico si procede diversamente e quindi non ne parlerò in questo articolo.

Lasciamo da parte se sia fondamentalmente una buona o una cattiva idea portare avanti una determinata iniziativa. Questo argomento l'ho già trattato in un altro articolo. Supponiamo qui semplicemente che l'iniziativa sia una cosa buona e importante. Vorrei illustrare le tre possibilità con cui i team possono gestire queste grandi e complesse iniziative.

Si tratta di questo: per definizione abbiamo un progetto complesso di cui dobbiamo occuparci e in cui sono coinvolti molti team. Ogni team ha i propri dettagli da chiarire, ma la domanda è chi guida il tutto e come. Se l'iniziativa riguarda l'adattamento dell'offerta di prodotto al mercato cinese, mandiamo ogni singolo team in Cina per scoprire cosa deve essere fatto? Non sarebbe molto sensato e molto probabilmente ogni team troverebbe una soluzione diversa.

Strategia 1: Un team guida

Nella maggior parte dei casi, uno dei team viene scelto per assumere il ruolo principale e guidare l'iniziativa, ovvero assumere la guida della Discovery e della Delivery. Naturalmente questo team dipende dal lavoro degli altri team, ma guida e coordina anche questi lavori. Ad esempio, identificherebbe un gruppo di clienti per determinare con loro le modifiche necessarie al prodotto, e poi aiuterebbe a suddividere e affrontare i lavori necessari (Discovery e Delivery).

I vantaggi di questo approccio sono la chiara area di responsabilità e l'ownership. Naturalmente si dovrebbe cercare di scegliere un team guida su cui questo lavoro abbia un forte impatto.

C'è però anche uno svantaggio in questo approccio. Se il team guida non informa permanentemente gli altri team sulle nuove scoperte e decisioni, questi non saranno in grado di comprendere o contesteranno queste decisioni quando si tratterà di suddividere il lavoro. E a questo punto l'autonomia diventa davvero una sfida.

Strategia 2: Un team temporaneo

In questo approccio, nessuno dei team esistenti viene incaricato di guidare l'iniziativa. Viene invece creato appositamente (per la durata di questa iniziativa) un team di Discovery temporaneo che si occupa almeno dei lavori di Discovery. Normalmente un tale team è composto da un Product Owner, un UX Designer senior e almeno uno sviluppatore senior. Una volta che questo gruppo ha identificato i lavori di Delivery necessari e ha creato i Backlog Item, i membri di questo team temporaneo tornano nei loro team originali.

Il vantaggio è che si ha un team forte con persone impegnate che possono concentrarsi su questo lavoro. Lo svantaggio è che queste persone tornano relativamente presto nei propri team. Questo è in realtà positivo, perché possono poi comunicare ai loro team ciò che hanno scoperto e deciso. Tuttavia, non ci sono più aree di responsabilità chiare o ownership. E anche qui c'è il rischio che gli altri team non comprendano o non siano d'accordo con ciò che viene loro comunicato. Un ulteriore svantaggio è che, togliendo persone dai loro team, si mina l'obiettivo della stabilità dei team.

Strategia 3: Un team unito

La terza possibilità per affrontare queste iniziative è qualcosa che normalmente non raccomando. Devo però menzionarla perché capita di tanto in tanto. In questo approccio, alcuni team (non necessariamente tutti) si uniscono per svolgere il lavoro di Discovery insieme.

Il grande vantaggio è che tutte le nuove informazioni vengono condivise e questo ha un valore enorme.

Il più grande svantaggio, tuttavia, è che ci sono molte persone coinvolte nella decisione e, come si suol dire, troppi cuochi guastano il brodo.

Conclusione su Autonomia vs. Iniziativa

Qualunque cosa scegliate, dovete trovare una soluzione per l'iniziativa e anche attuarla. Queste sono le tre possibilità con cui i team possono gestire la situazione. È difficile dire che una di queste sia migliore delle altre in termini di autonomia, perché in un'iniziativa si tratta in fondo di fare qualcosa di buono per l'organizzazione, e non necessariamente della libertà decisionale dei singoli team. Forse è più appropriato dire che si può scegliere uno di questi approcci per minimizzare la sensazione di perdita di autonomia.

Ricordate che queste iniziative sono spesso estremamente preziose per i nostri clienti e la nostra azienda, quindi c'è davvero molto di cui essere orgogliosi quando portate a termine con successo l'iniziativa.

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