CASE STUDY
Scalare il Product Development
Come (e perché) abbiamo accompagnato la trasformazione attraverso un approccio incrementale fatto di sperimentazioni e miglioramenti.
Le nostre attività hanno avuto un impatto su
0
persone
In 16 mesi abbiamo accompagnato
0
team
Da azienda di software ad azienda di prodotto, senza interrompere lo sviluppo
L’azienda si occupa di sviluppo prodotti software e consulenza in ambito finance da diversi anni. Nel 2019 ha iniziato il percorso per l’implementazione delle metodologie agili, al fine di accelerare i processi di industrializzazione e di evoluzione da piattaforma di servizi in prodotto e ottimizzare le lavorazioni su clienti eterogenei ma con esigenze affini, tipiche del mercato finanziario.
Le aree aziendali coinvolte nella gestione dei clienti e nello sviluppo del prodotto erano organizzate nella tradizionale struttura in silos (aree funzionali composte da commerciali, tecnici, analisti e PM) e distribuite su tre sedi operative. Le attività di comunicazione e di allineamento tra le parti erano percepite come molto impegnative. Un passaggio chiave per un’azienda di prodotto è quella di creare una visione unica dei molteplici obiettivi del prodotto, senza compromettere l’impegno costante nell’innovazione e nella ricerca.
Contesto iniziale
- Gerarchia tradizionale, distribuita in più sedi
- Management, team di analisi requisiti e team di sviluppo software separati
- Team di sviluppo organizzati per ambito professionale, coordinati da referenti
- Pianificazione verso il cliente non condivisa tra strutture
- Sforzo di coordinamento continuo (percepito come eccessivo)
- Più di quattro strumenti da manutenere per assegnazione e tracciamento delle attività
Necessità del cliente
- Visione di prodotto e sinergia tra le richieste di più clienti
- Accelerare il processo di industrializzazione interno per rendere la struttura scalabile
- Miglioramento continuo della qualità del software rilasciato
- Uniformare i metodi di sviluppo e rilascio attraverso un release management che contempli attività di demand, analisi, pianificazione, sviluppo e UAT
- Rispetto delle procedure di Quality Assurance dei rispettivi clienti
Come abbiamo accompagnato la trasformazione
Una squadra di coach ha accompagnato il cliente con attività di formazione, sperimentazioni incrementali, miglioramenti progressivi e infine con l’avvio di una community of practice.
L’incarico è iniziato a settembre 2021 e ha visto le ultime attività di chiusura a marzo 2023.
Per 9 mesi Agile Reloaded ha lavorato con il team di trasformazione interno: un gruppo aziendale composto da persone con competenze in ambito manageriale e di pianificazione, in grado quindi di accompagnare la trasformazione dell’azienda.
Questo approccio complementare e sinergico ci ha permesso di guidare la trasformazione insieme, concordando di volta in volta gli esperimenti e le iniziative da mettere in atto.
Da team pilota a nuovi team
Per i primi 3 mesi, un team cross-funzionale pilota ha introdotto Scrum, il software Jira, un backlog valorizzato in story points. Inoltre abbiamo introdotto i ruoli di Product Owner e Scrum Master, integrandoli con i ruoli pre-esistenti (Team Leader, Release Manager, Project Manager).
Nel periodo successivo – tipicamente ogni due o tre settimane – un nuovo team veniva formato con figure professionali delle rispettive aree funzionali e supportato nella rimozione di vincoli e dipendenze (tecniche e organizzative, ad esempio i riporti gerarchici).
backlog unico
In 9 mesi l’organizzazione dell’area prodotto è passata da uno a sei team. La costruzione dei team è avvenuta a fronte di un’analisi dei dati (rilasci su componenti, competenze di dominio) coinvolgendo le persone per impostare i percorsi di affiancamento.
È stato costruito un backlog unico, visibile a tutta l’organizzazione: un riferimento di product development univoco a cui tutti i ruoli da allora possono accedere, che contiene le informazioni sullo stato delle lavorazioni e sui clienti di riferimento.
Integrazione di Safe® e LeSS
L’approccio alla trasformazione è stato radicalmente personalizzato. Abbiamo integrato elementi di SAFe® e di LeSS per raggiungere risultati diversi:
- l’approccio LeSS per attivare cross-funzionalità dei team, l’autonomia sulla delivery e una centralizzazione della product ownership;
- l’approccio SAFe® per il governo dei diversi demand e della pianificazione della release. La ritualità del Product Increment Planning è risultata fondamentale per la collaborazione tra Project Manager (che mantengono la relazione con i clienti e le loro progettualità di medio-lungo periodo, nonché le informazioni di profittabilità dei servizi offerti) con i PO, gli SM e i referenti architetturali.
Vantaggi approccio ibrido
Uno dei principali vantaggi di un approccio ibrido e incrementale è stato il poter cogliere i vantaggi delle inevitabili ri-calibrazioni delle priorità: ha permesso al gruppo di lavoro di identificare insieme quale team può risultare meno occupato nelle lavorazioni della release in avvio e, di conseguenza, essere di supporto ad altri team.
L’incontro di release planning avviene ogni 3 mesi e consente di impostare in modo attendibile il lavoro di buona parte del quarter successivo, in base alle richieste del cliente e dell’azienda stessa.
Tempistiche e ciclo di vita del progetto
1
Valutazioni sul perimetro del team pilota
2
Inception e avvio del Transformation Team
3
Formazione e creazione dei team, estensione del processo di release planning
4
Co-creazione e documentazione dei diversi eventi e ruoli dei nuovi processi
5
Evoluzione del Transformation Team in Community of Practice
Risultati organizzativi e di business
- Team autonomi: dall’esigenza del cliente alla delivery della soluzione
- Meno riunioni: eventi Scrum sincronizzati tra più team, con allineamenti di raccordo
- Chiarezza: backlog unico e condiviso, visibile a tutta l’organizzazione
- Struttura: ruoli esistenti preservati e integrati con i nuovi (PO, SM)
- Cooperazione: processo di Product Governance che coinvolge business + sviluppo
- Evoluzione: architetture a supporto del ciclo di produzione del software, con responsabilità e perimetri distribuiti sui team
