Bentrovati con i meetup targati eXtreme Programming User Group Bergamo, la community che permettere a tutti gli appassionati, o anche solo curiosi, di eXtreme Programming e metodologie di sviluppo Agile del software d’incontrarsi e scambiare esperienze e conoscenze.
Ospite di questo appuntamento è stato Andrea Balducci, founder di Proximo S.r.l., che ci ha raccontato la recente esperienza vissuta insieme al suo team di sviluppo composto da Giuliano Latini, Gian Maria Ricci, Alessandro Giorgetti, Federico Benedetti, William Verdolini e Stefano Leli come Agile Coach. La storia di due esperimenti che hanno portato il team a performare bene e in totale serenità nelle ultime quattro settimane senza Product Owner (PO) prima e senza Backlog poi.
Ricordate la celebre scena del film “Matrix” in cui Morpheus offre un’alternativa a Neo sotto forma di pillolina colorata? Parafrasando il testo di quella scena, Andrea ha introdotto il suo talk dal titolo “Backlog revolutions”:
“È la tua ultima occasione, se rinunci non ne avrai altre. Pillola azzurra, fine della storia: domani ti sveglierai con il tuo solito backlog, e crederai alla pianificazione. Pillola rossa, resti nel paese delle meraviglie, e vedrai quant’è profonda la tana del bianconiglio. Ti sto offrendo solo la verità, ricordalo. Niente di più.”
Per dovere di cronaca, lo speech nacque ufficiosamente da un post pubblicato dallo stesso Andrea su LinkedIn, in cui venne riportato lo stato di due dashboard riassuntive delle attività a seguito di una riorganizzazione del team. Da questo post scaturì l’interesse della community dei PO, perché non organizzare un meetup?
Buona lettura.
Contesto
Proximo è un’azienda di sviluppo software che negli ultimi sei anni si è dedicata allo sviluppo e alla vendita di un prodotto, ma che nei precedenti dieci ha lavorato per conto terzi. Già questo fa capire il grande passo che Andrea e i suoi hanno deciso compiere a livello di riorganizzazione aziendale.
Il prodotto, una piattaforma di digital transformation per knowledge worker, era inizialmente composto da diversi moduli per offrire tutte le funzionalità del caso. Per Andrea questi moduli erano tanti, e da qui la decisione di eliminarne uno per riprogettarlo da zero.
Qual era il tipico flusso di lavoro dei team? Tenendo conto delle esigenze dei rivenditori e degli utenti finali, Andrea insieme al team definivano diverse milestone di valore e da queste derivavano le Epics e le User Stories, o storie. Di settimana in settimana il team lavorava allo sviluppo delle storie e verificava l’operato in meeting di avanzamento, tenendo conto che ogni milestone era orientata in iterazioni di 8-10 setimane.
Cosa è successo nel 2021?
Tutte le milestone portate a termine, ma sforando in tempo e contenuti.
Dalle retrospettive era emerso che alcune cose fossero andate bene e altre no, come per esempio la gestione del backlog. Anziché gestirne uno unico ogni team era arrivato a crearne uno generando caos d’informazione e disallineamento.
Era necessario fare qualcosa, e subito.
Il primo esperimento
Innazitutto è stato introdotto Azure DevOps per migliorare la pianificazione e la collaborazione e Kanban come metodo per avere una visione chiara e condivisa dell’informazione.
Il vero “Game Changer” è stato quando Andrea ha deciso di vestire i panni del cliente, o meglio del PO, e dare al team un’unica specifica:
Arrivare a San Valentino con uno dei moduli dell’applicazione in produzione per uso interno.
Tutto era in mano al team.
Come si è organizzato il team?
Dovendo gestire in completa autonomia la realizzazione da zero di uno dei moduli dell’applicazione, il team si è preso in carico le attività tipiche di un PO, la figura che ha una visione a lungo termine del prodotto e che sa “dove si deve andare”.
Prima di partire con lo sviluppo vero e proprio, sono state svolte tutte le attività di analisi per capire chi è l’utente (i suoi bisogni, cosa si aspetta dal prodotto, quali sono i pain point utilizzando l’attuale versione ecc.). In seguito il team ha realizzato interviste con alcuni utenti e, con l’aiuto di un’azienda esterna, sono stati svolti degli studi sulla User Experience e realizzati dei prototipi dell’applicazione.
Terminata questa prima fase di analisi e progettazione, il team si è organizzato settimanalmente per lavorare alle storie in maniera verticale: un team cross funzionale quindi, dove tutti riescono a fare più o meno tutto, e non più team suddivisi per competenze, come per esempio “team front-end” e “team back-end” o “team mobile” e “team desktop”.
I due PO e lo Scrum Master Light
Trasferendo una parte della responsabilità dal PO al team si sono create due figure:
- un PO strategico, focalizzato sullo sviluppo del business, ruolo svolto da Andrea.
- un PO tattico, il team, che definisce come e quando implementare qualcosa.
Perché è importante trasferire la responsabilità? Secondo Andrea, se una storia è scritta da una persona esterna, si perde il focus sulla parte tecnica. Permettendo al team di partecipare alla scrittura della storia questa lacuna si colma perché viene aggiunto valore dal punto di vista tecnico. Il team inoltre è più consapevole nel tenere aggiornato e ordinato il backlog a ogni iterazione.
Questa nuova configurazione del lavoro è un processo che si è evoluto nel tempo, a tal punto che in quattro settimane il team ha deciso in completa autonomia di riprogettare completamente un pezzo di dominio e riscriverlo da zero, assumendosi il rischio di sforare ma non avere debito tecnico. E sono riusciti nell’intento, presentando il modulo funzionante internamente per la demo prevista il 14 febbraio.
A ulteriore riprova della riuscita di questo esperimento di “team autogestito senza PO” Andrea ha mostrato alla platea i dati di una retrospettiva svolta il 4 febbraio 2022. Dal team stesso era emerso che i daily meeting fossero migliorati nella gestione e organizzazione, il backlog era più ordinato, le demo erano fissate e rispettate…il tutto grazie anche alla figura dello “Scrum Master Light“. Questa persona, scelta internamente dal team, oltre a promuovere Scrum così come è stato definito nella Guida, garantisce che il team viva valori e principi del Manifesto Agile e segua i processi e le pratiche concordati e fa da tramite tra il team e il business.
I takeaway
Che cosa hanno imparato Andrea e il team da questo primo grande esperimento?
Lato business, Andrea ha capito che è molto importante spiegare chiaramente gli obiettivi al team focalizzandosi sul perché si deve fare qualcosa e quali sono gli effetti attesi e non su come fare. Coinvolgere un team a livello strategico e sul valore del prodotto è importante, permette al team di prendere le migliori decisioni perché ha il quadro completo della situazione.
Per quanto riguarda il team, lavorare in piena autonomia e con una visione chiara ha permesso a ogni componente di sentire il prodotto come proprio e non come qualcosa ordinato da un PO.
La figura dello Scrum Master Light, rinominata in metronomo, è stata molto apprezzata perché supporta il team nello sviluppo, nelle review e mette in relazione le persone giuste in base al problema. Grazie al metronomo è stato messo ordine al backlog, che ora è unico. L’allineamento viene fatto insieme, e questo favorisce lo scambio d’informazioni e di feedback.
Il secondo esperimento
Dato l’affiatamento del team che lavora in autonomia sulla base dei macro obiettivi e una visione chiara del futuro del prodotto, Andrea ha dato vita a un secondo esperimento, un’altra vera e propria sfida:
Chiedere al team di implementare una nuova specifica entro una settimana, partendo da un semplice mockup.
Andrea ha tenuto a sottolineare che il mockup era davvero una bozza, ed era l’unica documentazione in mano al team. Non c’era altro, nemmeno un backlog con le storie.
Il team non solo ha implementato la specifica, ma l’ha mostrata funzionante ad Andrea nel giro di un paio di giorni!
I takeaway
Sperimentare è importante. Lato business, Andrea ha avuto conferma che è importantissimo favorire il più possibile la sperimentazione, mentre per il team è stato utile poter sperimentare direttamente sul prodotto e non su qualcosa che molto probabilmente non verrà usato dall’utente finale.
Cosa ha funzionato per invertire così velocemente la rotta?
Concedere al team piena autonomia sulla gestione del prodotto ha rappresentato il vero motore di questo cambiamento. Essere consapevoli del futuro di un prodotto ha permesso al team di lavorare con più energia e convinzione, perché appunto ognuno sente il prodotto come suo.
Lavorare con questa consapevolezza ha aumentato anche la qualità del lavoro sia da un punto di vista umano (meno stress, più tranquillità) sia tecnico, con codice molto più pulito e manutenibile.
Andrea non ha fatto mistero di ammettere che ora
“È il team che guida, e il business che corre dietro al team! Il business in questo modo si preoccupa di sviluppare il business.”
Prima di salutarci, Andrea ci ha ricordato che tutto è nato durante una loro giornata di team building insieme all’Agile Coach Stefano Leli durante la quale ogni componente del team ha dato il suo personale contribuito per delineare ciò che sarebbe stato il prodotto.
E’ IL NOSTRO PRODOTTO, SAPPIAMO DOVE VOGLIAMO ANDARE, ABBIAMO CHIARA LA VISION, QUINDI PARTIAMO.