Scalare l’Agile (con Giovanni Asproni di Zuhlke Engineering Limited)

Leggi la trascrizione:

Stiamo sperimentando la trascrizione dei nostri podcast tramite un programma software. Perdona eventuali errori, il bot non è sempre accurato al 100%.

Ben Aston:

Benvenuti al Podcast DPM, dove andiamo oltre la teoria per offrire consigli pratici per gestire meglio i progetti digitali. Grazie per averci seguito, io sono Ben Aston, il fondatore di The Digital Project Manager. Tutti sono entusiasti dell'Agile, ma come si fa a farlo funzionare su più team o progetti? Come si accelera il processo, e dove può andare storto? E come si può evitare che vada storto fin dall'inizio? Continua ad ascoltare il podcast di oggi per capire come possiamo scalare un delivery Agile e come possiamo far funzionare l’Agile su scala. Questo podcast è offerto da Clarizen, leader nei software di gestione progetti e portfolio aziendali. Visita clarizen.com per saperne di più.

Oggi sono con Giovanni Asproni. È consulente principale presso Zuhlke Engineering Limited. Probabilmente ho sbagliato a pronunciarlo, ma è basato a Londra. È un architetto software, programmatore, coach, consulente, con grande esperienza in diversi settori verticali tra cui telecomunicazioni, banche, petrolio e gas. Ha partecipato a molte conferenze e contribuito a diversi libri. Giovanni, grazie per essere con noi.

Giovanni:

Ciao. Grazie per l’invito.

Ben Aston:

E come si pronuncia il nome della tua azienda?

Giovanni:

In realtà è un nome svizzero, si pronuncia Zuhlke.

Ben Aston:

Ah, ecco. Non l’avrei mai indovinato.

Giovanni:

Anche io sbaglio spesso, quindi non ti preoccupare.

Ben Aston:

Ottimo. Allora, raccontaci un po' su cosa stai lavorando adesso, ne stavamo parlando poco fa, ma come si svolge una tua giornata tipica?

Giovanni:

Beh, la giornata tipica per me, almeno in questo periodo, è piuttosto impegnativa. Ho iniziato a giugno un nuovo progetto, in cui sto seguendo i miei stessi consigli, che sono molto saggi. Dopo una collaborazione con un grande cliente di Zuhlke, io e alcuni colleghi abbiamo fatto una valutazione di un programma su larga scala che hanno, parliamo di 500 persone, 57-60 team, qualcosa del genere, e ora stiamo attuando alcune delle raccomandazioni che sostanzialmente consistono nel fornire loro un sistema per raccogliere alcuni indicatori su progetto e programma per gestire meglio tutto l’effort. Quindi sono piuttosto impegnato, mi occupo... della leadership tecnica, dei requisiti, e poi faccio report a tutti i livelli di management del cliente, scrivo anche un po’ di codice, se necessario.

Ben Aston:

Bene, raccontaci un po' del processo di assessment che seguite. Mi sembra interessante che non entriate semplicemente in azienda a dire "fate Scrum" e provare ad applicarlo, ma fate prima una valutazione, giusto?

Giovanni:

Sì.

Ben Aston:

Come funziona?

Giovanni:

Durante la valutazione cerchiamo di capire cosa sta succedendo realmente.

Ben Aston:

Sì.

Giovanni:

Parliamo con le persone, rappresentanti dei vari team, manager a tutti i livelli, per capire cosa accade in concreto. Facciamo anche review coperte, vediamo tutti i processi che seguono i team, osserviamo come fanno il commit del codice nel [inaudibile 00:03:16], quello che fanno per la qualità—

Ben Aston:

Sì.

Giovanni:

Parliamo con i manager per conoscere la loro visione sull’andamento delle cose. Quindi ci creiamo una fotografia della situazione: questi grossi progetti hanno molte somiglianze, ma i dettagli del contesto sono sempre diversi.

Ben Aston:

E quindi sulle raccomandazioni: dopo queste valutazioni con grandi aziende, quanto cambiano le vostre raccomandazioni all’atto pratico? Sono simili oppure no? Giovanni: Dipende da quello che troviamo. Devo dire che alcune cose tendono a ripetersi—

Mm-hmm (affirmativo).

Giovanni:

Perché tendiamo a fare errori sempre negli stessi modi.

Ben Aston:

Sì.

Giovanni:

Di solito, quando si scala un programma su grande scala—magari 100, 200 o 500 persone, ho visto anche 1300 persone su un singolo prodotto—lo si fa sperando di andare più veloci, ma spesso non ci sono gli strumenti per capire se quello che si sta facendo porta davvero un vantaggio.

Ben Aston:

Quando parli di strumenti, quali sono quelli che usate per capire se "scalare" aggiungendo risorse funziona davvero?

Giovanni:

Guardiamo vari aspetti. Nel mio articolo, quando parlo dei prerequisiti per scalare, cerchiamo di capire se tutti abbiano chiaro cosa devono fare, se vanno nella stessa direzione. Spesso persone diverse hanno obiettivi diversi sullo stesso progetto.

Ben Aston:

Mm-hmm (affirmativo)

Giovanni:

E tirano da parti opposte. Cerchiamo l’uso di metriche, la presenza di team: come fai a sapere se vanno più veloci? Servono dati reali, non sensazioni.

Ben Aston:

Sì, chiaro.

Giovanni:

Valutiamo il design di sistema, l’architettura, se è allineata alla struttura dei team. La comunicazione: spesso nei grandi progetti tende a irrigidirsi in modalità molto formali, così i problemi si risolvono più lentamente.

Ben Aston:

Vorrei parlare della tua esperienza personale nello scalare Agile. Puoi raccontarci un tuo grande errore e cosa hai imparato?

Giovanni:

Uno degli errori più recenti, non era enorme ma comunque significativo: sono stato mandato a risolvere alcune situazioni difficili tra nostri team e team del cliente. Da Zuhlke spesso lavoriamo anche integrati nella struttura del cliente.

Ben Aston:

Capisco.

Giovanni:

Molte cose sono andate bene, ma poi una situazione politica interna del cliente ha fatto concludere il progetto per motivi sbagliati. La lezione è che, anche se crediamo di avere tutto sotto controllo, a volte ci sfuggono dei segnali.

Ben Aston:

Sì.

Giovanni:

C’erano giochi politici e siamo finiti nel mezzo.

Ben Aston:

Eh già, la politica conta sempre—volentieri o no.

Giovanni:

Sì, la politica non è né buona né cattiva, dipende da come la usi. Dove ci sono persone c’è politica.

Ben Aston:

Concordo. Se dovessi dare un consiglio a qualcuno che vuole iniziare con l’Agile, quale sarebbe la cosa più importante?

Giovanni:

Capire e chiarire le aspettative. Se un cliente dice "voglio essere Agile", cosa intende? Qual è il bisogno? Quale problema sta cercando di risolvere?

Ben Aston:

Sì.

Giovanni:

L’agilità non è l’obiettivo, è il mezzo per raggiungerlo. Spesso si pensa di voler essere agili perché lo fanno altri, ma così si perde il vero punto.

Ben Aston:

Mm-hmm (affirmativo)

Giovanni:

Quindi la gestione e chiarificazione delle aspettative è fondamentale.

Ben Aston:

Mi piace molto, perché non conta il processo, conta generare valore.

Giovanni:

Esatto.

Ben Aston:

E generare valore in modo più efficiente. Il fine è ottenere risultati, non il metodo in sé.

Giovanni:

Proprio così.

Ben Aston:

Parliamo del tuo toolkit: quali strumenti usi per valutare e aiutare i team ad essere più agili?

Giovanni:

Uno strumento molto analogico che uso è la mia Moleskin. Quando valuto un progetto prendo appunti a mano—aprire il laptop crea una barriera fra te e la persona davanti.

Ben Aston:

Giusto.

Giovanni:

Scrivere su un blocco note è molto meno minaccioso. Quindi penna e Moleskin.

Ben Aston:

Altri strumenti, magari digitali?

Giovanni:

Uso un software per riversare gli appunti: si chiama Scapple. Permette di scrivere concetti e collegarli tra loro in modo non lineare—puoi creare una specie di “bosco” di idee.

Ben Aston:

Interessante!

Giovanni:

Puoi collegare tutto con tutto, utile per organizzare i pensieri. Ecco, quando parli con le persone in una valutazione conta ascoltare non solo le parole, ma leggere l’atmosfera, capire se sono rilassati, tesi, per cogliere messaggi non detti.

Ben Aston:

Mm-hmm (affirmativo)

Giovanni:

E servono ambienti sicuri per queste interviste: se devo sentire gli sviluppatori, dico chiaramente che non voglio manager nella stanza. Vale anche per i manager. Anche dove tutti dicono di essere "aperti", nella realtà è sempre più complicato.

Ben Aston:

Vero!

Giovanni:

Quindi la sicurezza viene prima di tutto.

Ben Aston:

Software per la gestione agile dei progetti: hai una preferenza? O dipende dal contesto?

Giovanni:

Dipende dal contesto. Se tutti sono sempre in ufficio basta una lavagna. Si possono fare foto e condividerle. Se il team è distribuito meglio strumenti digitali. Uno diffuso è Jira, che non amo particolarmente, ma è più adatto di una lavagna se si lavora da più postazioni.

Ben Aston:

Quindi dipende dal contesto.

Giovanni:

Sì, sempre dal contesto.

Ben Aston:

Oltre a Moleskin e Scapple, altri strumenti utili?

Giovanni:

Non proprio. In questo periodo non cerco strumenti particolari. Spesso mantenere le cose semplici è meglio.

Ben Aston:

Consiglieresti quindi lo strumento più semplice che svolge il compito richiesto.

Giovanni:

Esatto, il più semplice possibile.

Ben Aston:

Parliamo del tuo articolo, molto interessante su come scalare Agile. È noto che aggiungere persone a un progetto software spesso non aumenta la produttività, anzi in molti casi la riduce, per via di confusione e difficoltà di integrazione. Ma deve esserci un modo migliore per ottenere più risultati. Giovanni ha scritto un articolo con regole, prerequisiti, e considerazioni sulla struttura dei team. Se non l’hai ancora letto ti consiglio di cercarlo su thedigitalprojectmanager.com.

Parliamo di perché è importante conoscere lo scaling Agile. Per chi pensa che non serva, perché dovremmo interessarcene?

Giovanni:

Prima o poi ti troverai ad affrontarlo. Anche nelle aziende medie accade spesso che i progetti crescano molto in termini di risorse. Il mio consiglio è: non scalare subito! Prima chiarisci perché lo vuoi fare. Ad esempio, nei prerequisiti scrivo che se non risolvi certe cose di base, scalare serve solo ad ampliare la confusione. Nella mia esperienza, anche nei più grandi progetti (1300 persone, 2000 repository…), di solito basterebbero 20-30 persone per fare un buon lavoro. Un amico mi diceva: il numero giusto di persone su un progetto è il minimo tra quante ne hai e quanto tempo hai a disposizione.

Ben Aston:

Quindi bisogna essere efficaci e efficienti prima di crescere.

Giovanni:

Sì, lavorare bene prima di aumentare il numero.

Ben Aston:

Quando si deve scalare Agile in organizzazioni grandi, serve un modello unico per tutti o team diversi vanno gestiti diversamente?

Giovanni:

Un modello unico non funziona mai. Soprattutto con tanti team, ognuno avrà esigenze e stili diversi. Detto questo, serve comunque un minimo di uniformità—ad esempio nei sistemi di reporting e nella trasparenza—fornendo interfacce comuni tra i team, altrimenti la gestione diventa impossibile.

Ben Aston:

Come si mantiene l’uniformità nel reporting se i team lavorano in modo diverso?

Giovanni:

Ci sono molte opzioni. Non serve imporre Scrum a tutti: alcuni team lavorano meglio in modalità flow/eventi. L’alto livello si può uniformare misurando storie, feature, epiche, mantenendo lo stesso tipo di analisi anche se le squadre adottano frameworks diversi. Si può anche analizzare il codice, i modi in cui i team interagiscono o si ostacolano tra loro.

Ben Aston:

Parliamo quindi di buono e cattivo scaling. Nel tuo modello ideale si dà autonomia ai team e si lavora sulla connessione fra loro e sulla chiarezza verso il management. Cos’altro caratterizza un cattivo scaling secondo te?

Giovanni:

Tipico: il top management decide che si va lenti, quindi aggiunge persone a caso. Questo porta a errori di pianificazione—come pensare: "progetto da 1000 ore/uomo, prenderemo 100 persone e finirà in un anno"—ma non funziona così. Bisogna invece coinvolgere le persone giuste con le giuste competenze: un team troppo giovane senza guida rischia di perdersi su dettagli poco utili. Chiedere ai team se serve davvero più personale è il modo migliore per iniziare la conversazione; loro sanno se c’è bisogno di aiuto.

Ben Aston:

Quindi consapevolezza.

Giovanni:

Sì, consapevolezza è fondamentale. Aggiungo una cosa controversa: nei progetti software, le uniche persone imprescindibili sono i programmatori (chi scrive codice) e gli utenti del sistema. Tutti gli altri—PM, consulenti, persino tester in certi casi—sono opzionali. Il vero ruolo dei "non programmatori" è permettere ai dev di lavorare meglio. Se il PM si domanda "cosa posso fare per te?", inizierà a lavorare diversamente.

Ben Aston:

Descrivi ora uno scaling Agile che ha funzionato al meglio: come era?

Giovanni:

L’ho visto davvero funzionare solo una o due volte, su sistemi non grandissimi (5-6 team, 50 sviluppatori e tester circa). Funziona quando tutti sanno cosa fanno e parlano molto, sia in modo formale che informale. Nei grossi progetti ci sono sempre grossi problemi; spesso servirebbe 1/10 delle persone.

Ben Aston:

Framework "out-of-the-box" come SAFe e Large-Scale Scrum: funzionano davvero?

Giovanni:

So di situazioni in cui hanno funzionato, ma sono rare e dipende dal contesto giusto. In generale non apprezzo i framework rigidamente calati dall’alto, perché "costringono" il progetto al loro schema e richiedono un contesto ideale per funzionare. Sono strutture pensate più per rassicurare il management che per aiutare il lavoro vero di chi sta sui progetti.

Ben Aston:

Sono d’accordo. A volte si segue un framework senza pensare al valore. Ci si concentra sulla forma invece che sull’essenza.

Giovanni:

Confermo. Quando implementai per la prima volta Extreme Programming, lo feci partendo da poche pratiche condivise e aggiungendo solo quello che dava valore. Iniziare con troppa teoria confonde; è meglio imparare un po’ per volta e adattarsi.

Ben Aston:

Altrimenti si finisce per seguire la forma, ma la sostanza non cambia—solo overhead.

Giovanni:

Sì. Spesso vedo stand-up dove ognuno "parla", ma nessuno ascolta; retrospettive che diventano solo lamentele. Si fanno le cose senza capire perché. Tante aziende adottano il "modello Spotify" senza sapere che perfino Spotify lo ha abbandonato.

Ben Aston:

Il modello Spotify "fa sembrare Agile sensato su larga scala", ma in realtà serve creare un processo che funzioni nel proprio contesto, senza paraocchi.

Giovanni:

Giusto. C’è un libro che consiglio: “Six Simple Rules”. La prima regola: prima di cambiare, osserva cosa fanno davvero le persone, poi costruisci soluzioni sensate per la realtà concreta.

Ben Aston:

Per i PM: qual è la cosa più importante da ricordare nel supportare il team Agile?

Giovanni:

Chiedi sempre come puoi aiutare il team, non dare cose per scontate. Il lavoro di project management è centrale, soprattutto nei progetti medio-grandi. Assumi che le persone stiano facendo il meglio che possono col contesto a disposizione. I programmatori vorranno occuparsi meno di burocrazia e budget; accetta questa realtà.

Ben Aston:

Nessuno vuole responsabilità di budget o statement of work! Eppure sono essenziali per il cliente che paga. Spesso in Agile si saltano questi aspetti ma servono chiarezza e trasparenza verso il cliente.

Giovanni:

Per questo sono scettico sul movimento "no estimate": ai clienti servono risposte. Quando il PM chiede una stima, non va chiesta una nuova stima solo perché la precedente non piace. Se non convince, chiedi spiegazioni genuine; e se la stima è confermata, difendi il team. Così il team ti apprezzerà davvero.

Ben Aston:

Fondamentale: comunicare sempre che una stima è solo una stima. Lo scambio trasparente tra team e cliente è il vero valore che il PM può portare, chiarendo vision, priorità e limiti di budget/tempo.

Giovanni, grazie per essere stato con noi oggi.

Giovanni:

Grazie a voi, è stato un piacere.

Ben Aston:

E tu cosa ne pensi? Hai provato a scalare Agile? Raccontacelo nei commenti qua sotto. Per approfondimenti o per unirti alla nostra community, visita thedigitalprojectmanager.com/membership per accedere al nostro team Slack, a template, workshop, ore d’ufficio, eBook e molto altro. Se ti è piaciuto il podcast lasciaci una recensione su Apple Podcasts. Alla prossima e grazie per l’ascolto.