Bilanciare le priorità tra competenze diverse in un team: oltre la massimizzazione della capacità

Parliamo di una situazione comune nei team Scrum, dove sviluppatori front end e back end cercano di bilanciare il carico di lavoro per riempire al massimo il tempo disponibile, a discapito delle priorità aziendali. Spesso, per evitare che alcuni membri del team rimangano “scarichi”, vengono assegnati compiti meno prioritari, il che rallenta il completamento delle funzionalità realmente necessarie. Questo essere parzialmente o momentaneamente “scarichi” può, invece, diventare un’importante risorsa per il miglioramento dei processi.

Cosa osserviamo come Agile Coach

Lavorando come Agile coach, negli ultimi anni, mi sono trovata spesso di fronte alla stessa situazione: un team Scrum formato da professionalità diverse, tra le quali sviluppatori back end e sviluppatori front end, che cerca di far quadrare i conti al planning. Cerca cioè di bilanciare il carico tra back end e front end per far sì che tutti siano ugualmente carichi durante lo Sprint.

Purtroppo in molte aziende resiste ancora l’idea che se tutti non sono carichi al 100%, o più, qualcosa non stia funzionando. Capisco che questa convinzione sia profondamente radicata, e che sembri comune buon senso, ma in realtà porta i team a preoccuparsi di più di riempire al massimo il loro tempo piuttosto che assicurarsi di concludere il prima possibile ciò che realmente serve all’azienda.

La metafora della lavatrice

Immaginate di aver appena comprato una lavatrice nuova. Avreste bisogno di lavare alcuni panni bianchi perché vi serviranno a breve ma non sono abbastanza per riempire la lavatrice. Fare un lavaggio con solo i panni bianchi sarebbe uno spreco perché non utilizzereste al massimo il suo carico. Per cui decidete di riempirla con i panni colorati e fare un primo lavaggio, lasciando da parte quelli bianchi. Terminato questo lavaggio vi si ripresenta la stessa identica soluzione. Preferite quindi, di nuovo, riempire la lavatrice, sfruttando al massimo la capacità, dando precedenza ai panni colorati. E così andate avanti per diverse settimane. Siete molto soddisfatti dell’elettrodomestico nuovo e di come lo state utilizzando al massimo delle sue possibilità. Però vi rendete conto che i famosi panni bianchi, che sono rimasti accumulati accanto alla lavatrice perché erano troppo pochi per riempire un lavaggio, adesso vi servono per davvero. Per cui i vestiti che vi servivano puliti per primi ancora non ce li avete pronti. Avete sempre dato più importanza allo sfruttare al massimo la capacità della lavatrice, piuttosto che a ciò che era realmente prioritario per voi (i panni bianchi).

Una conversazione reale

La metafora cerca di rendere l’idea di quello che vedo continuamente succedere ai Planning. Vi faccio l’esempio di una classica conversazione:
Sviluppatore: “Qual è la priorità di questo Sprint?”
Product Owner: “La funzionalità A”
Sviluppatore: “Questa attività è solo front end”
Product Owner: “Ok allora cosa possiamo aggiungere lato back end?”
Sviluppatore: “Possiamo mettere la funzionalità G che si trova molto più in basso nel backlog ma è la prima che richiede del lavoro back end”
Product Owner: “Ok così avremo tutti qualcosa da fare”

Nel migliore dei casi l’attività G richiede solo lavoro back end, così gli sviluppatori back end lavorano a qualcosa che non è prioritario per riempire le loro giornate, mentre i tester che avrebbero dovuto focalizzarsi sul chiudere l’attività A devono terminare anche l’attività G.
Se invece l’attività G richiede anche un minimo effort lato front end, anche gli sviluppatori front end devono lavorare su qualcosa che è decisamente meno prioritario di tante altre attività.

Quindi massimizzare l’utilizzo della capacity porta inevitabilmente a ridurre il focus e la capacità di chiudere le priorità di business nel più breve tempo possibile.

Questo scenario spesso si verifica per tanti sprint di fila finché, a un certo punto, si inverte la situazione, cioè con l’inizio degli sviluppi di una nuova macro-funzionalità saranno, per seguire il nostro esempio, gli sviluppatori front end ad essere scarichi. E il ciclo ripartirà a parti invertite.

Voi a questo punto direte: “Ok, ma non possiamo di certo lasciare le persone senza niente da fare!” Le persone del team senza attività legate alla loro specifica competenza possono dedicarsi a migliorare il processo, risolvere blocchi e dipendenze, lavorare su debito tecnico o bug. Pensate a tutto quello che spesso rimane bloccato durante lo sprint perché in attesa di qualcuno o qualcosa, qualcuno all’interno del team finalmente avrebbe il tempo di provare a risolvere quei problemi una volta per tutte. Oppure le persone scariche potrebbero affiancarsi a chi è carico e imparare le competenze necessarie per riuscire a supportarli in futuro. Gli sviluppatori back end potrebbero imparare il minimo necessario per sviluppare a front end e viceversa. Gli sviluppatori potrebbero imparare a lavorare come tester. I tester potrebbero imparare a lavorare come analisti e così via. Idealmente tutti potrebbero mantenere la loro specializzazione verticale ma imparare a lavorare anche negli altri ambiti (senza per forza diventare degli esperti).

Anni fa si trovavano ancora team con sviluppatori full stack. Quando ho iniziato a lavorare era normale e richiesto saper sviluppare sia su front end che back end. Ovviamente non è possibile essere degli esperti su tutto, ma è possibile saper mettere le mani su più fronti. Oggi invece anche se qualcuno ha competenze su entrambi gli ambiti viene addirittura assunto dalle aziende con titoli specifici come “sviluppatore back end” o “sviluppatore front end” e non gli vengono nemmeno dati gli accessi ai sistemi che non competono alla sua specializzazione.

Ci colleghiamo quindi al tema di figure professionali verticali rispetto a figure trasversali. Nonostante le esigenze di business richiedono persone in grado di adattarsi e imparare a fare un po’ di tutto, aziende e mercato del lavoro si muovono nella direzione opposta. Da un lato le aziende cercano sempre più persone altamente specializzate in un’unica competenza, dall’altro anche il mercato offre figure verticali a causa del continuo aumento della complessità degli stack tecnologici.
E’ importante affidarsi a degli esperti, ma i team di un’azienda non possono essere formati solo da esperti. La combinazione all’interno dei team e dell’azienda di figure verticali e trasversali è fondamentale. Altrimenti ci preoccupiamo sempre di più di cosa far fare alle persone per riempire il loro tempo invece di cosa serve fare per soddisfare i clienti.