Autonomia vs. Incarico

Nel mio ultimo articolo ho scritto dei compromessi tra i diversi obiettivi dell'autonomia e della direzione esterna nei team. Ho ricevuto alcune risposte in cui si diceva che questo è un tema molto sentito nelle aziende e alcune persone volevano saperne di più – ma più da una prospettiva di prodotto e design che da quella dello sviluppo. L'argomento è molto vario e per questo ho pensato che valesse la pena approfondirlo.

Ecco alcune domande che vorrei affrontare:

• Cosa succede se un team vede un'opportunità ancora migliore e decide di concentrarsi su un altro tipo di cliente?
• Cosa succede se un team non vuole svolgere il lavoro che dovrebbe supportare una grande iniziativa aziendale (ad es. l'internazionalizzazione del prodotto)?
• Cosa succede se un team è convinto di dover cambiare rotta per sfruttare le opportunità del mercato mobile, anche se il team è responsabile solo di una parte del tutto?
• Cosa succede se un team è convinto di dover passare a un diverso design della User Experience, anche se questo lo differenzierebbe da quello degli altri team?

In ciascuno di questi casi, team e management hanno probabilmente prospettive molto diverse. Molti team sostengono che, se potessero davvero lavorare in modo autonomo, sarebbero in grado di prendere queste decisioni.

La problematica

Nei team e nelle organizzazioni sane, si arriva normalmente a un compromesso tra queste due posizioni, dando alla leadership il controllo su due punti chiave nel processo decisionale. Il primo è la visione complessiva del prodotto e il secondo sono gli obiettivi aziendali specifici assegnati a ciascun team.

Tuttavia, possono sorgere problemi quando il management non formula questi due punti chiave con sufficiente chiarezza, perché allora si crea una zona grigia e non è più chiaro cosa il team possa decidere autonomamente e cosa no.

La visione del prodotto descrive il quadro generale dei clienti target e i servizi che si vogliono offrire a ciascun tipo di cliente. Questa visione del prodotto deve supportare la strategia aziendale. Se ad esempio avete una strategia aziendale basata su un modello di vendita low-touch (poco contatto personale con il cliente), questo favorisce un tipo molto specifico di visione del prodotto. Se un team vuole sviluppare un prodotto che si discosta dalla visione e da questo modello, sarà piuttosto difficile commercializzare il prodotto.

Gli obiettivi aziendali specifici vengono comunicati ai team sotto forma di KPI (Key Performance Indicator) prioritizzati – chiamati anche Product Scorecard – oppure sotto forma di OKR (Objectives and Key Results), che a loro volta si traducono in vari KPI. Se ad esempio l'obiettivo aziendale è ridurre significativamente il tasso di abbandono dei clienti, questo è l'incarico per il team.

I team ricevono la visione del prodotto e i KPI dalla leadership, ma non viene detto loro come realizzarli. È questo il punto in cui il team può lavorare in modo autonomo e flessibile. Mi piace descrivere i team di prodotto forti come comunità di lavoro per la risoluzione di problemi complessi. Ridurre il tasso di abbandono può essere sicuramente una grande sfida e probabilmente ci sono innumerevoli modi per raggiungere questo obiettivo. Lo stesso vale per l'aumento del "Customer Lifetime Value" (il valore che un cliente genera per l'azienda nel corso dell'intera relazione commerciale) o la riduzione dei costi di acquisizione clienti, ecc.

Quando la visione del prodotto e i KPI sono stabiliti, la differenza tra team autonomi e tutti gli altri è se esiste o meno una roadmap aziendale. Se il management o gli stakeholder presentano al team un elenco di funzionalità vincolanti, su cui clienti e stakeholder già contano fermamente, il team ha poco margine di manovra per trovare la soluzione migliore alle questioni aziendali sottostanti (per non parlare di temi davvero fondamentali).

Ed è proprio per questo che sono così contento della rinascita degli OKR. Quando vengono applicati correttamente, aiutano a riorientare la situazione dall'output (funzionalità nelle roadmap) all'outcome (risultati di business).

2 casi speciali

Ci sono due casi speciali che vale la pena menzionare, perché causano molto spesso stress in azienda.

Il primo caso speciale riguarda il design. Non c'è dubbio che avere un designer in ogni team (che si occupa di funzionalità orientate al cliente) sia un grande vantaggio per il team e per i clienti. Questi designer instaurano un legame davvero stretto con il loro prodotto e gli sviluppatori e sono membri del team a tutti gli effetti. Inoltre, non cercano di lavorare secondo un modello simile a un'agenzia di design interna. Ma come si può garantire che i designer vogliano migliorare l'esperienza per tutti gli utenti e non solo per gli obiettivi del proprio team? Agli utenti non interessa la vostra struttura di team. Come si promuove l'autonomia garantendo al contempo l'uniformità?

Per questo esistono vari metodi – dall'impiego di un "Design Manager" (o Senior Designer) che rivede e approva il lavoro di tutti i designer, fino alla massima automazione possibile con "Pattern Library", "Style Guide" e "Stylesheet".

In termini di autonomia e velocità, preferisco l'automazione, perché il team riesce così a gestire il design (Interaction e Visual) in modo relativamente semplice e buono. Naturalmente, occasionalmente si presenta anche del "Design Debt", ovvero ci accorgiamo che il design deve essere rivisto, e lo si fa non appena si identifica il problema. Mi piace questo approccio perché il Design Manager continua a comporre un gruppo di bravi designer ma non deve più essere presente per ogni piccola revisione (il che rallenta tutto e mina l'autonomia).

Il secondo caso speciale sono le iniziative aziendali. Sono quei progetti che coinvolgono sempre più team. Un caso abbastanza frequente è l'internazionalizzazione. Un altro è il cosiddetto "Responsive Design". Un altro ancora è prendere sul serio il mercato mobile. Credo che il concetto sia chiaro. Nel migliore dei casi, queste iniziative si allineano bene con i KPI prioritizzati di ciascun team e spesso c'è un obiettivo OKR concreto per questa iniziativa. Bisogna però essere consapevoli che un'iniziativa importante non è sempre un vantaggio evidente per ogni singolo team. Ciononostante, ogni team deve fare la sua parte, altrimenti l'iniziativa fallisce. In questi casi dico sempre ai team che a volte bisogna semplicemente fare la propria parte come parte del tutto. La cosa buona è che queste iniziative sono davvero fantastiche per il prodotto e il cliente, quindi possiamo almeno esserne soddisfatti.

Conclusione su autonomia vs. incarico

Se i vostri team non hanno la sensazione di avere sufficiente autonomia, allora dovete fornire a ciascun team una visione del prodotto chiara e obiettivi di business inequivocabili e prioritizzati. Il contesto che ne deriva è l'incarico del team. Assicuratevi che i team comprendano questo incarico e date loro il massimo margine di manovra possibile per poterlo portare a termine.

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

Creare la visione del prodotto

=> Product Vision Canvas - La guida alla visione del prodotto.

Scrum Master Training

=> Diventa Scrum Master certificato con Agile Academy!

Metriche agili: usarle correttamente

=> Quali metriche dovresti conoscere come Scrum Master?