Velocity negativa: come innalzare il limite di complessità

Raggiungere il limite di complessità può sembrare inevitabile, ma alcuni segnali indicano ai team che si stanno avvicinando al limite. Non esiste una metrica assoluta che indichi quanto sia vicino il limite di complessità, ma è possibile capirlo grazie a questi indicatori.

L'indicatore più evidente che un team ha raggiunto il limite di complessità è quando dedica più tempo a gestire la complessità organizzativa che a risolvere i problemi intricati su cui dovrebbe concentrarsi. L'andamento dei lead time di DORA per le modifiche (velocità) e le metriche del tasso di errore delle modifiche (qualità) mostrano se i team rallentano o accelerano nel tempo. Anche se altri fattori influenzano queste metriche, sono un buon indicatore dell'efficacia del team.

La soddisfazione degli sviluppatori è un ulteriore indicatore della complessità organizzativa che i team software stanno gestendo. Gli sviluppatori, più di altri, preferiscono passare il tempo a risolvere problemi intricati piuttosto che affrontare attività inutili che intralciano il lavoro. La scarsa soddisfazione degli sviluppatori è un segnale che la complessità organizzativa rappresenta un problema per il team software.

Quando le aziende si rendono conto che i team sono sopraffatti dalla complessità, spesso avviano un "progetto di semplificazione" per ripristinare la semplicità nell'organizzazione. La semplificazione è una strategia perdente perché la complessità aumenta più velocemente di quanto qualsiasi organizzazione possa semplificare il proprio ambiente e questi "progetti di semplificazione" operano proprio nell'ambiente complesso che mirano a semplificare.

La semplificazione generalmente inizia riducendo il numero di applicazioni, disattivando o consolidando ove possibile. La disattivazione di un'applicazione richiede che il team comprenda tutte le dipendenze a monte e a valle, chi utilizza l'applicazione, come sostituire la funzionalità, dove e come verranno archiviati o migrati i dati e che affronti una serie di altre complicazioni derivanti da questo tipo di attività. Sfortunatamente, i notevoli sforzi richiesti per ottenere questo risultato non sono ricompensati da una riduzione altrettanto significativa della complessità. C'è un limite alla quantità di applicazioni che un'azienda può disattivare senza influire sulle attività principali o sull'esperienza utente, ma non c'è limite al numero di nuovi componenti software che gli ingegneri possono creare. È probabile che nei 12 mesi necessari per disattivare un'applicazione siano stati creati centinaia di nuovi microservizi. Poiché un ambiente tecnologico sano cresce nel tempo, non è consigliabile limitarlo a un numero fisso di applicazioni o componenti software per ridurre la complessità.

I progetti di semplificazione includono in genere la rielaborazione della struttura organizzativa per eliminare la complessità nel flusso di comunicazione. Le strutture organizzative meno complesse prevedono team gerarchici di grandi dimensioni con tutto il personale co-ubicato. Le strutture organizzative più complesse coinvolgono team piccoli, distribuiti e autonomi. La legge di Conway mostra quanto sia probabile che i grandi team gerarchici producano applicazioni monolitiche, mentre i piccoli team distribuiti producano applicazioni utilizzando architetture modulari come i microservizi. La produzione di software di alta qualità in tempi rapidi è resa possibile da modelli di architettura modulare come quella di microservizi; una struttura organizzativa più complessa ha quindi maggiori probabilità di successo. Se da un lato "semplificare" la struttura organizzativa ne renda più facile la comprensione, dall'altro è controproducente per l'obiettivo finale del progetto di semplificazione.

La semplificazione è importante e vantaggiosa, ma sarebbe più utile integrarla come miglioramento continuo, per i team software e di team, piuttosto che come attività una tantum; nonostante possa ritardare il raggiungimento del limite di complessità, non riporterà un'organizzazione alla libertà e alla dinamicità proprie degli ambienti delle startup.

Le organizzazioni devono aumentare il limite di complessità per ripristinare l'efficacia dei team software. Ciò significa essenzialmente aumentare la complessità organizzativa che ogni team può affrontare prima che influisca sulla soddisfazione lavorativa e sulla qualità e velocità con cui il team rilascia il software.

La progettazione della piattaforma è un concetto significativo nella ricerca di innalzare il limite di complessità di un'organizzazione. I team più efficienti di progettazione delle piattaforme si concentrano sulla riduzione del carico cognitivo dei team software astraendo la complessità organizzativa dal loro lavoro quotidiano. Se implementata correttamente, la progettazione della piattaforma consente ai team di riequilibrare la maggior parte degli sforzi per risolvere problemi intricati, dedicando meno tempo alla gestione della complessità organizzativa.