TAILORED SCALED SCRUM

Dopo i primi Sprint di rodaggio, una volta a regime il progetto ha visto la collaborazione di circa venti tra membri effettivi dello Scrum Team, esperti di dominio e stakeholder. Considerando la grandezza del team di lavoro, si è deciso di suddividere il gruppo in due virtual team (secondo la two-pizza rule). Lo Scrum Team ha mantenuto obiettivi comuni, come la partecipazione alla medesima release e la cooperazione per realizzare un unico Minimal Marketable Product (MMP), ma ciascun team virtuale è stato indirizzato verso goal di Sprint specifici.

A livello di processo agile, è stata adottata una metodologia di scaling simile allo Scrum of Scrums, ma con qualche differenza rispetto alla letteratura. Il daily meeting, in base ai vari momenti di progetto, è stato condotto secondo due modalità:

• Daily meeting globale, con la partecipazione di entrambi i virtual team
• Daily meeting dedicato al singolo gruppo di lavoro

In particolare, la prima soluzione è stata privilegiata durante gli Sprint in cui si è ritenuto fondamentale mantenere costante allineamento dello Scrum Team rispetto agli obiettivi di release. Al contrario, è stata adottata la seconda soluzione nei momenti in cui i due gruppi di lavoro, focalizzati su obiettivi distinti, necessitavano di momenti di allineamento meno frequenti.

Per la realizzazione di alcune componenti ben definite e con impatti limitati sugli obiettivi del Development Team, sono stati definiti gruppi di lavoro con incarichi “on demand”.
L’allineamento tra lo Scrum team ed i gruppi esterni (“feature team” o “substream”), coordinati dall’Agile PMO, è stato garantito attraverso:

• Partecipazione al daily meeting da parte di un referente di ciascun feature team
• Tracciamento delle attività nel Product Backlog e nello Sprint Backlog
• Condivisione della test strategy e delle linee guida del progetto (tecniche e di processo)

AGILE PMO

Facendo leva sulla caratteristica di auto-organizzazione del Development Team, il framework Scrum non riconosce alcuna figura di gestione del progetto all’infuori dello Scrum Master (e del Product Owner, per particolari compiti). Tuttavia, dopo aver evidenziato la necessità di mitigare alcuni rischi legati ad attività di monitoraggio e condivisione degli obiettivi e della conoscenza, è stato definito un Agile PMO composto da focal point di ciascun team.

Alcuni dei compiti in carico all’Agile PMO:

• Assicurare la consistenza del MMP corrente
• Monitorare l’aderenza ed il raggiungimento degli obiettivi di release
• Definire la test strategy di Sprint e Release
• Sincronizzare le attività tra i due Development Team
• Condividere le informazioni (all’interno dello Scrum Team e verso l’esterno)
• Gestire tutte le attività fondamentali di release
• Pianificare ed eseguire il Product Backlog Grooming

DEVOPS

La transizione del processo di rilascio dal waterfall all’agile, definita ed attuata durante la conduzione del progetto, ha permesso allo Scrum Team di individuare la migliore strategia per garantire l’aderenza ai principi DevOps. Tra le caratteristiche della metodologia definita, vi sono elementi chiave quali:

• Automazione del deploy tramite pipeline, affiancata a test automation a livello di integration e code quality (Continuous Integration)
• Deploy automatico in ambienti di test (Continuous Deploy) e di Produzione (Continuous Development)
• Adozione di branching strategy tramite feature branch
• Canary Deployment Strategy

I rilasci in Produzione hanno seguito un approccio ibrido in termini di tempistiche: il progetto ha mantenuto una pianificazione generale definita su major release di 3 mesi, in stile waterfall, intervallate da rilasci settimanali di piccoli incrementi di prodotto, a carattere agile.

La qualità del lavoro e le performance generali di progetto sono stati monitorati attraverso specifici KPI derivati da Jira, il software di Agile Project Management utilizzato per la gestione del progetto.

ROLLOUT

Per evitare impatti su larga scala, tutti gli incrementi di prodotto sono stati attivati in Produzione secondo una precisa strategia di rollout, basata su:

• Switch “ON/OFF”, a caldo, delle singole feature
• Abilitazione progressiva, a caldo, per lotti di agenzie

La progressiva abilitazione delle nuove feature alla rete agenziale è stata coadiuvata da un insieme di “sfidatori”, soluzioni implementative con il compito di mettere a confronto (dunque, “in sfida”) il ramo logico-funzionale AS-IS attivo in Produzione con quello TO-BE, eseguito in background in forma silente. Grazie al monitoraggio della Produzione, le evidenze raccolte dagli sfidatori attivi sono state analizzate e classificate come anomalie (con rispettive priorità) o falsi positivi.

Tramite questi key factor è stato possibile monitorare lo stato della Produzione, attivando progressivamente, ed a piccoli step, tutta la rete della Compagnia Assicurativa. La possibilità di “spegnere” le funzionalità all’occorrenza ha inoltre permesso di mantenere isofunzionalità, evitando al contempo d'interrompere l’operatività degli agenti.

Nella stessa teoria ricade anche il concetto di Canary Development Strategy menzionata nel tema DevOps. Tale strategia di sviluppo è stata perseguita con l’intento d'incrementare la versione di un singolo microservizio disattivato in Produzione, per poi attivarlo al momento opportuno in modo trasparente all’agente e senza interromperne l’operatività.