L'agilità e la gallina dalle uova d'oro: Parte 2

Nella prima parte di questo memo ho parlato di come il livello e il potenziale produttivo debbano essere attentamente bilanciati per far sì che la gallina possa continuare a produrre uova d’oro. Abbiamo visto come sia il carico cognitivo (intrinseco, estraneo, genuino) il perno attorno al quale ruotano le decisioni relative al livello produttivo.

In questa seconda parte esamino come l’agilità si collega al dualismo tra livello produttivo e potenziale produttivo, con lo scopo di capire quali sono i fattori principali in cui si articola il collegamento, e quindi capire come poter operare.

L’agilità nello sviluppo del software implica che il team di sviluppo sia in grado di reagire efficacemente e velocemente a cambiamenti inaspettati. Il beneficio atteso dall’agilità è una garanzia contro una serie di rischi.

Rischi relativi al prodotto: se cambiano i requisiti, il team è in grado di cambiare rotta velocemente, mantenendo la capacità di erogare valore.

Rischi relativi all’implementazione: se si scopre di aver compiuto scelte errate progettuali, tecnologiche o di codifica, il team è in grado di cambiare rotta velocemente, mantenendo la capacità di erogare valore. Ad esempio, con un team agile le risoluzioni di bug richiedono mediamente poco lavoro.

Rischi relativi alle persone: se qualche membro del team se ne va, o altri si aggiungono, il team è in grado di sopportare questi cambiamenti mantenendo la capacità di erogare valore. Nel caso di fuoriuscite, qualche membro di quelli esistenti è in grado di coprire il ruolo di colui che è uscito. In certi casi membri esistenti sono in grado di crescere relativamente velocemente e coprire le responsabilità di quel ruolo.

Queste mitigazioni di rischi permesse dall’agilità sono possibili però solo se almeno due condizioni sono verificate.

Primo, occorre che l’azienda (il team, ma anche il management) presti continua attenzione alla qualità interna del prodotto, che ne determina la facilità di manutenzione. Solo con software di qualità e con un processo di testing sostenibile (efficace, snello, che dà valore ai suoi stakeholder) il team sarà in grado di cambiare rotta velocemente, mantenendo la sua capacità di produrre valore.

Secondo, occorre che l’azienda presti continua attenzione al potenziale produttivo. Se in un impianto industriale questo vuol dire fare una appropriata manutenzione preventiva dei vri macchinari per evitare dei fermo impianto molto costosi sulla produzione, nel caso del software si manifesta nella “manutenzione delle persone e del processo”. Spesso ci si illude che una modifica degli strumenti tecnici adottati possa fare miracoli (ad es. l’introduzione di un server di continuous integration o di un framework di test), ma quasi mai le tecnologie sono sufficienti ad ottenere dei risultati significativi e duraturi. Occorre lavorare sulle persone e sull’organizzazione del lavoro. Ma cosa significa in pratica? E come poter agire sul potenziale produttivo?

In un team agile significa curare il miglioramento continuo. Miglioramento delle capacità dei singoli, della loro abilità di lavorare insieme, e del processo in cui sono coinvolti. Questo si esplica in svolgimento e conduzione corretti di sessioni frequenti di retrospettiva (ad es. la “sprint retrospective” prevista da SCRUM), sessioni collaborative di “problem solving”, identificazione di azioni di rimedio, attività di miglioramento delle competenze, disponibilità di tempo e modo per poter sbagliare e imparare, attento monitoraggio del processo per identificare tempestivamente dei cambiamenti. Per ottenere questo è necessario sia un impegno dei singoli membri del team, ma soprattutto occorre che il management crei e sostenga una cultura di miglioramento continuo. Dove c’è, ad esempio, sicurezza psicologica che lo sbagliare non è di per sè negativo, se consente di imparare e quindi di migliorare.

Un aspetto raramente considerato, ma che ha enormi conseguenze sull’agilità, è l’atteggiamento e il potenziale di crescita dei membri del team di sviluppo (e del management) rispetto ai metodi di lavoro che sono stati adottati (Secondo la Treccani, il metodo èin genere “il modo, la via, il procedimento seguito nel perseguire uno scopo, nello svolgere una qualsiasi attività, secondo un ordine e un piano prestabiliti in vista del fine che s’intende raggiungere”).

I seguenti quattro livelli di autonomia possono essere utili per classificare i membri di un team di sviluppo rispetto allo svolgimento di un metodo.

Livello -1: si tratta di persone incapaci o che non vogliono collaborare coi colleghi. In un team agile non c’è posto per queste persone, che vanno allontanate.

Livello 1: persone capaci di eseguire procedure standard, secondo un metodo prefissato che deve e può venir svolto sempre nello stesso modo. Eventualmente, qualche saltuario passo discrezionale può essere incluso. Pochi membri di un team agile possono appartenere a questa categoria, in quanto sono la causa di rallentamenti e bassa agilità, dato che gli membri del team devono “prestare soccorso” nei momenti di necessità, distogliendoli dalle loro attività (e incrementando il carico cognitivo estraneo).

Livello 2: sono persone in grado di adattare un metodo a varie situazioni che sono già state incontrate (dal team) nel passato. La maggior parte dei membri del team devono appartenere a questa categoria per consentire al team di manifestare agilità.

Livello 3: si tratta di persone in grado di modificare un metodo per adattarlo a nuove situazioni mai incontrate prima. Persone di questo tipo sono relativamente rare e ovviamente più ce n’è in un team e meglio è.

Per i livelli di autonomia il management farebbe bene a coltivare e spingere il miglioramento continuo. In questo modo le persone progrediscono lungo una traiettoria di crescita e vengono messe in grado di affrontare via via situazioni più impegnative, in una cultura aziendale che consente l’apprendimento e gli eventuali inciampi che questo richiede.

Solo in questo modo il potenziale produttivo di un team viene progressivamente incrementato, e quindi l’agilità in azienda, e quindi la possibilità di mitigazione dei rischi delineati sopra.

La nostra gallina dalle uova d’oro sarà destinata a soccombere se il management, nell’agilità, mira ai soli aspetti formali ed esteriori (le cerimonie, la apparente carenza di pianificazione, di analisi, di design, di testing). Nel tempo il potenziale produttivo del team calerà perché a fronte delle emergenze e accresciuta pressione del management per soddisfare nuove esigenze di business, il team dovrà aumentare il livello produttivo a scapito del potenziale produttivo.

Il contadino astuto invece avrà bilanciato livello produttivo e potenziale produttivo in modo da garantirsi una rendita sicura di uova d’oro.

Pubblicato originariamente come Articolo LinkedIn.