L'agilità e la gallina dalle uova d'oro - parte 1

In questo memo voglio affrontare un aspetto che ha grosse implicazioni strategiche nello sviluppo agile del software e che spesso viene sottovalutato. C’entra anche con la favola di Esopo. 

In questa prima parte vedremo le conseguenze di non prestare la giusta attenzione al dualismo tra “livello di produzione” e “potenziale produttivo” e come questo si riflette sul comportamento dei team a lungo termine. 

Nella seconda parte affronteremo il legame con l’agilità.

La favola di Esopo racconta del contadino che non si accontenta della sua gallina che produce un uovo d’oro al giorno, e per avidità dopo qualche giorno l’uccide con l’intenzione di impossessarsi subito di tutte le uova future. Ma così facendo nulla stringe.

Consideriamo ora questo scenario concreto. 

Contesto: realizzazione di un sistema molto complesso, costituito da centinaia di servizi distribuiti, centrati su sottodomini diversi, tutti soggetti a frequenti aggiornamenti. Ci sono molti team, ciascuno che lavora in maniera agile su uno o pochi servizi.

Problema: i test di integrazione e di sistema stagnano, sfruttano una test harness cresciuta bottom-up per il contributo occasionale e opportunistico di qualche team e che quindi risulta complicata da usarsi e da mantenere. Da una parte questi test sono essenziali, ma dall’altra negli utlimi mesi non sono evoluti come ci si aspettava e ora sono un collo di bottiglia per il progresso dell’iniziativa. Che fare? 

Ci sono almeno 2 possibili strade.

Decisione 1: Spingere/costringere i team a rilasciare nuove versioni del sistema con la cadenza stabilita.

Decisione 2: Rivedere e ri-sviluppare la test harness per facilitare questo tipo di lavoro.

Scegliendo la prima strada, forzare i team a rilasciare di più, equivale al cercare di massimizzare il livello di produzione.

Livello di produzione = valore erogato per unità di tempo

Potenziale produttivo = la capacità di riuscire a mantenere o aumentare il livello produttivo al variare delle condizioni operative. 

Nell’esempio, la produzione riguarda l’erogazione di valore che si manifesta come rilascio di incrementi software che contribuiscono ai business goal del sistema. Ma anche se i team dedicano più tempo e sforzo a rilasciare nuove feature, sono costretti (per la Definition of Done) a comunque passare attraverso la realizzazione di test e uso della test harness. Queste attività tenderanno a consumare sempre maggiori risorse. E comunque la creazione di test automatizzati o di test harness sicuramente di per sè non produce valore. 

Siamo un po’ come il contadino che vuole impossessarsi subito di tutte le uova, nel nostro caso “spremendo” i team. Ma così facendo uccidiamo la gallina?

Dal punto di vista di un team, questa decisione comporta un aumento del carico cognitivo individuale e del team. 

Carico cognitivo di un’attività = sforzo mentale dedicato, grossomodo collegato alla quantità di cose da tenere a mente.

Nel caso dello sviluppo del software, il carico cognitivo si manifesta in tre modi diversi:

• quello intrinseco dell’attività: nel caso dello sviluppo del software, si tratta dello sforzo legato a saper usare il linguaggio di programmazione, gli strumenti di sviluppo, le librerie scelte, il sistema operativo. 
• quello estraneo: si tratta di tutte quelle cose che devo saper fare e gestire in modo da poter lavorare, ma che sono dei fastidi perché non mi aiutano a erogare valore: aggiornamento di documentazione, burocrazia di rendicontazione, meeting poco interessanti.
• quello genuino: le decisioni di progetto, la creazione di codice nuovo, il portare avanti un refactoring, lo svolgimento di sessioni di TDD.

Nell’esempio di prima, apportare modifiche alla test harness per consentirmi di scrivere un nuovo test di integrazione comporta aumento del carico cognitivo estraneo. Non è il mio lavoro normale, non vengo elogiato o premiato per questo lavoro, richiede che io collabori con altri team, non mi piace. 

Quindi cercare di massimizzare la produzione in questo caso comporta un aumento del carico cognitivo estraneo. Che di per sè non porta a un aumento della produzione. In generale la produzione forse aumenta un po’, grazie ai nuovi test che con fatica vengono realizzati che consentono di rilasciare gli incrementi. Ma al costo di un livello accresciuto di stress e del burnout dei membri dei team. Che porta alla lunga a de-motivazione e turn-over.

Il contadino ha alla fine ucciso la gallina. Il cercare di aumentare la produzione ha la conseguenza di aver ridotto il potenziale produttivo del sistema.

Scegliendo la seconda strada, migliorare la test harness, si può cercare di individuare un team (chiamiamolo T) a cui viene dato il mandato di realizzare e rivedere la test harness, in modo da produrne una che sia affidabile, comprensibile ed estendibile.

Questo team produce valore sotto forma di incrementi della test harness che i suoi clienti, gli altri team, sfruttano giorno per giorno. Il carico cognitivo genuino di questo team è legato a questi incrementi. Il team è specializzato e focalizzato in questo tipo di software, e quindi gli altri tipi di carico cognitivo sono sotto controllo.

Per un team generico, il dover usare una test harness implica un carico cognitivo estraneo. Ma se la test harness viene erogata con un alto livello di developer user experience (DX), questo carico viene tenuto sotto controllo. Un alto livello di DX vuol dire che il team T agisce da facilitatore, in maniera proattiva per favorire l’utilizzo da parte dei suoi clienti della test harness; fornisce supporto; documenta per bene la test harness per fare in modo che gli altri la possano usare as-is; ascolta le esigenze degli altri team, e favorisce l’acquisizione di feedback.

Quindi per T abbiamo elevato carico genuino; per gli altri team avremo basso carico estraneo, che quindi consente di sfruttare di più il carico genuino non ancora sfruttato. 

Per attività creative come lo sviluppo del software, aumentare il carico cognitivo genuino è la ricetta per aumentare la responsabilizzazione e motivazione delle persone, nonché per ridurre il rischio del turn-over.

In altri termini, stiamo aumentando il potenziale produttivo che, col trascorrere del tempo, consente di aumentare il livello produttivo. Nel breve la produzione non cambia, nonostante ulteriori risorse vadano spese nel nuovo team. Ma alla lunga, strategicamente, la produzione aumenterà.

Siamo come il contadino astuto che nutre meglio e cura la sua gallina per farle produrre più di un uovo al giorno.

Pubblicato originariamente come Articolo LinkedIn.