Agile sta rovinando il tuo prodotto

La ricerca di team piccoli, veloci e autonomi sta creando esperienze frammentate, confuse e sconnesse.

Illustrazione di Joan LeMay

Guai in Paradiso

Nel mio lavoro come product coach e consulente, la prima domanda che di solito mi viene posta è: "Come possiamo essere più simili a [famosa azienda tecnologica X]?" Questa domanda ha avuto innumerevoli risposte in casi di studio ben pubblicizzati, come I "team a due pizze" di Amazon, il modello "squadra, tribù, capitoli e gilde" di Spotify e il mantra "ritirato velocemente e rompi le cose" di Facebook. Nel loro insieme, queste storie dipingono un quadro avvincente di come appare lo sviluppo del prodotto nelle migliori aziende digitali della classe: piccoli team autonomi che operano alla velocità della luce.

L'idea di piccoli team autonomi, fondamentali per molte metodologie Agile utilizzate dalle moderne società tecnologiche, offre un'alternativa allettante alle strutture burocratiche di comando e controllo che ancora dominano il mondo aziendale. Eppure, questo approccio comporta anche un rischio sostanziale: che i prodotti creati da piccoli team autonomi sembrino un insieme disconnesso di funzionalità piccole e autonome.

La sezione

Per esempi reali di questo anti-pattern, non c'è bisogno di guardare più lontano dei prodotti di punta realizzati da alcune di quelle aziende digitali molto "best-in-class". (Vedi la sezione "Esplora" sulla home page di Facebook per un esempio particolarmente irritante, o prova a navigare senza soluzione di continuità tra i prodotti una volta noti come "Google Apps".) Poiché i prodotti digitali diventano più grandi e complessi, è più importante che mai che guardiamo oltre le singole funzionalità e pensiamo al modo in cui queste funzionalità si combinano per creare esperienze fluide e coerenti. E farlo richiederà di riconoscere che le dipendenze stesse che rallentano il lavoro di piccoli team autonomi a volte possono essere buone per i clienti che quei team servono in definitiva.

Velocità operativa vs. necessità del cliente

I principi e le pratiche del movimento Agile si sono dimostrati particolarmente interessanti per le organizzazioni che cercano di stare al passo con un mondo in rapido cambiamento. E, senza dubbio, la suddivisione di team grandi e interdipendenti in piccoli team autonomi aumenterà probabilmente la velocità con cui ciascun team può apportare miglioramenti al particolare pezzo del prodotto di cui è responsabile.

Il problema, a quanto pare, è che l'attrito interno rimosso dai piccoli team autonomi viene spesso avvertito dai clienti esterni. Un articolo della Harvard Business Review del 2013 intitolato "La verità sull'esperienza del cliente" sottolinea un punto critico che spesso si perde nella conversazione su piccoli team autonomi: dal punto di vista del cliente, la parte più importante di un prodotto spesso non sono le sue caratteristiche individuali, ma piuttosto come queste funzionalità si uniscono per creare un'esperienza coerente e coerente.

Lo scopo, la definizione delle priorità e l'esecuzione di tale lavoro comportano necessariamente un alto grado di coordinamento tra e tra i team - e tale coordinamento richiede tempo e impegno. Per le organizzazioni che misurano il successo di ciascun team in base alla velocità operativa del proprio lavoro, ciò può creare una netta disconnessione tra il lavoro più importante per i clienti e il lavoro a cui è probabile che ogni piccolo team autonomo dia la priorità. Questo alla fine pone la domanda: l'autonomia è davvero l'obiettivo su cui vogliamo lavorare?

Rimetterlo insieme

Suddividere grandi prodotti in pezzi piccoli e maneggevoli non è un compito facile - ma risulta che riunire quei pezzi, risulta, è molto più difficile. Molti framework Agile in scala sono progettati in parte per bilanciare l'autonomia su piccola scala con il coordinamento di un quadro generale. Ma il passo più importante per mantenere i piccoli team collegati e coordinati, come ho scoperto durante la ricerca del mio ultimo libro Agile for Everybody, è meno una questione di organigrammi e strutture piuttosto che di collaborazione e cultura. Come mi ha detto il vicepresidente della crescita e del marketing di Spotify, Mayur Gupta:

Quando le persone si riferiscono al modello Spotify, di solito parlano di corporazioni, tribù e capitoli. Ma quelli sono solo rituali. Non credo che abbiate superato le barriere cambiando le righe dei rapporti. Quando si dispone di un team veramente interfunzionale, le righe di reporting diventano irrilevanti ... Mentre continui nella tua vita e carriera, ti rendi conto che ciò che guida veramente questi cambiamenti è la cultura.

In altre parole, semplicemente ridisegnando l'organigramma per seguire "Il modello Spotify" (o qualsiasi modello per quella materia) in realtà non ricreare la cultura che ha portato Spotify - o una di quelle "best-in-class" aziende a raggiungere le sue maggiori vittorie. Piuttosto che seguire un unico modello operativo pronto per l'adozione, quasi tutte le storie di successo che ho sentito durante la ricerca di Agile for Everybody hanno seguito tre principi guida di alto livello:

  • A partire dai clienti e dalle loro esigenze, non con un obiettivo incentrato sull'azienda
  • Collaborazione precoce e spesso tra più team (indipendentemente dal modo in cui tali team sono organizzati formalmente), per identificare grandi opportunità e dipendenze tattiche
  • Pianificare l'incertezza per incorporare effettivamente nuove informazioni mentre il progetto avanza

I team e le organizzazioni che avevano veramente abbracciato questi principi erano in grado non solo di scomporre grandi sfide in pezzi più piccoli, ma anche di ripensare dinamicamente il modo in cui quei pezzi si incastrano nuovamente. Il loro obiettivo non era quello di raggiungere la velocità operativa o la pura autonomia, ma piuttosto di lavorare insieme per risolvere i problemi più grandi e più importanti che devono affrontare i loro clienti.

Un percorso in avanti: dai proiettili d'argento alle organizzazioni elastiche

Il titolo di questo articolo vuole essere provocatorio, ma parla anche di un'importante verità: qualsiasi organizzazione che sia troppo focalizzata su obiettivi operativi, incentrati sull'azienda come la velocità, l'autonomia o "seguendo le regole di un framework Agile" il rischio di allontanarsi ulteriormente dai propri clienti. Mentre la ricerca di rimuovere l'attrito interno è degna, dobbiamo iniziare con la comprensione dell'attrito esterno sperimentato dai nostri clienti e lavorare instancabilmente (e collaborativamente) per minimizzare tale attrito.

Ecco alcuni passaggi che la tua organizzazione può adottare per evitare di perseguire velocità e autonomia a scapito dell'esperienza del cliente:

  • Resistere alla tentazione di misurare i progressi rigorosamente in base alla velocità operativa (ad es. Frequenza di rilascio o righe di codice). Invece, pensa alla velocità dal punto di vista dei tuoi clienti: li stai aiutando a raggiungere i loro obiettivi in ​​modo rapido e semplice? O li stai rallentando con esperienze complesse e frammentate?
  • Assicurarsi che gli incentivi individuali e di gruppo non siano così localizzati da scoraggiare implicitamente il tempo e gli sforzi per lavorare tra i team.
  • Differenziare chiaramente le "buone dipendenze" (cioè le opportunità di combinare gli sforzi o le funzionalità in un'esperienza senza soluzione di continuità per i clienti) dalle "cattive dipendenze" (cioè le dipendenze che rallentano inutilmente la capacità di un'organizzazione di soddisfare le esigenze dei clienti). Essere particolarmente vigili nella ricerca di situazioni in cui più team svolgono un lavoro duplicato o ridondante, un problema comune tra le organizzazioni che hanno cercato di eliminare le dipendenze e favorire l'autonomia.
  • Diffidare di tutti i menu e gli elenchi (come "Esplora" di Facebook) che possono diventare una discarica per le funzionalità disconnesse. Ricorda che ogni nuovo articolo che stai mettendo di fronte ai tuoi clienti ha un costo per il loro tempo e attenzione.
  • Al di là di "Agilità", le organizzazioni di maggior successo sono veramente elastiche; vale a dire, possono rapidamente sviluppare nuovi schemi e strutture organizzative senza un massiccio rimbalzo formale. Un modo immediato per costruire questa elasticità è formare "Squadre SWAT" temporanee con rappresentanti di più livelli, funzioni e team basati su funzionalità, incaricati esplicitamente di esaminare come il lavoro di questi singoli team può combinarsi per creare una migliore esperienza del cliente. Come bonus aggiuntivo, prova ad assegnare a tale team il compito di reinventare completamente l'intero prodotto da zero, indipendentemente dal set di funzionalità esistente. (Scriverò di più sulle organizzazioni elastiche e sull'approccio del "team SWAT" in un prossimo articolo.)

Per ulteriori informazioni su questo argomento, spero che darai un'occhiata al mio nuovo libro Agile for Everybody. Come sempre, sentiti libero di contattarmi direttamente a matt@mattlemay.com se hai pensieri, suggerimenti o suggerimenti!