Coopservice Agile Scaling Model. Un reale caso di successo.

coopservice agile_framework

Il 18 giugno 2019 all’evento Atlassian a Mestre, organizzato da GetConnected, ho presentato il caso di Coopservice Agile Scaling, un percorso di “Agile Trasformation” coadiuvato dalla testimonianza di Gianfranco Scocco, CIO dell’azienda.

È possibile supportare il PMO e il lavoro del Project Management per gestire la crescita aziendale con una comunicazione chiara e con visibilità sulle attività? 
Come si può lavorare con trasparenza e allineamento anche con team dislocati e cross-funzionali, incrementando l’efficienza dei processi e la comunicazione con gli stakeholder?

Devo ammettere che sono coinvolto parecchio nello scrivere questo articolo, perché sono parte attiva nel processo di trasformazione Coopservice Agile Scaling Model e non nascondo un certo grado di soddisfazione nel vedere i benefici che questo percorso, sicuramente lungo e complesso, sta portando con sé.


GLI OBIETTIVI – COOPSERVICE AGILE

Coopservice è una cooperativa emiliana molto articolata, che tocca settori come la Sicurezza e Vigilanza, Lavoro interinale, Energy & Facility Management, Servizi di Pulizia e sanificazione, Logistica e Movimentazioni, con un più di ventimila dipendenti e quasi seimila soci. In tutto questo, il mondo digitale, lo sviluppo tecnologico e software, sono parte integrante e fondamentale degli elementi di business e delle strategie aziendali.

Quando mesi fa è iniziato il progetto, i requisiti di base erano di fondo abbastanza semplici e contenuti: introdurre le metodologie agili nei team di sviluppo software.

E da questo in effetti siamo partiti con l’introduzione di nuove dinamiche, comportamenti, metodi e filosofie nei team (agile), applicando poi processi di base sulla piattaforma Atlassian, Jira e Confluence.

Di fatto era solo la punta dell’iceberg, perché in pochissimo tempo, è risultato evidente che i requisiti erano molto più vasti e coinvolgevano diversi ambiti aziendali in un percorso di trasformazione agile e, con la supervisione di Gianfranco siamo partiti per un viaggio molto più articolato e interessante.

E’ evidente che un’azienda di queste dimensioni, ha già nel suo DNA strategie e processi, con questa consapevolezza abbiamo analizzato come e quali cambiamenti potevano sostenere le richieste sempre maggiori.

L’assunto strategico descritto da Gianfranco, lo si può riassumere in due punti fondamentali:

  • Il digital business porta valore all’organizzazione attraverso processi abilitati dalla tecnologia, offuscando i confini tra il mondo digitale e quello reale.
  • Il reparto digital IT di Coopservice assume il ruolo di Digital Business Partner, attraverso un piano dedicato a supportare le iniziative del business sempre più digitale.

RIDISEGNARE I PROCESSI

È sempre molto stimolante affrontare questi livelli di complessità soprattutto quando coinvolgono “l’ecosistema aziendale dalla strategia allo sviluppo”, ricercando, in nuove filosofie e metodi, il cambiamento e la trasformazione”.

E così siamo partiti da un disegno organizzativo e di processi ponendoci queste 5 domande a cui, a mio avviso, è necessario rispondere per arrivare ad immaginare il cambiamento.

  1. Cosa e Perché? – per determinare lo scopo
  2. Come? – studio dei processi
  3. Chi? – le persone al centro; sono il motore principale del cambiamento
  4. Quando? – determinare e pianificare sviluppi e rilasci
  5. Quale? – misurare le performance perché il ciclo sia continuo

Ricercare la risposta alle domande, analizzando i vari elementi e processi, ha portato ad un nuovo disegno, un modello diverso a cui Coopservice poteva e voleva aderire.

Image

Nel disegno generale è evidente quanto l’impatto sia esteso e coinvolga manager, PMO, DEV nella ridefinizione. Quello che mi ha sorpreso è stata la consapevolezza di Coopservice che “agilizzare” solo i team di sviluppo non portava al risultato. Era necessario trasformare e cambiare in modo omogeneo, introdurre lo stesso cambiamento per creare un linguaggio comune e una condivisione trasversale a partire dalle strategie aziendali per arrivare ai singoli team, in modo ciclico e ripetitivo ma con rivalutazione continua dei processi.

Stava prendendo forma un vero e proprio percorso di Agile Trasformation, in cui introdurre tutti gli elementi sia di metodologia che di framework applicativo, per arrivare ad un vero e proprio Agile Project Portfolio Management.


I PRESUPPOSTI (AGILI)

Introdurre un framework applicativo basato su metodologie agili, senza averne condiviso la filosofia (almeno in parte) e la metodologia può diventare più uno spreco di tempo che un obiettivo raggiungibile, per cui siamo partiti proprio dalla condivisione e formazione sia della filosofia che delle metodologie agili, tenendo presente sempre quelli che possono essere punti oscuri a rischio di fallimento.
Riguardo a questo rimando all’articolo che ho scritto precedentemente “sviluppo agile: più veloci, più economici e risultati migliori, ma… a volte non funziona. perché?” in cui ho analizzato gli elementi di rischio che l’errata applicazione porta con sé.


IL FRAMEWORK APPLICATIVO

Negli ultimi anni mi sono occupato diverse volte di percorsi simili, affrontandoli sempre in modo diverso a seconda delle organizzazioni e delle esigenze che percepisco e analizzo, partendo però sempre dagli stessi elementi a mio avviso fondamentali per raggiungere l’obiettivo, ovvero creare una struttura applicativa che permetta di mantenere una connessione in tempo reale tra gli elementi di strategia e di business e quelli di programmazione e sviluppo.

È fondamentale che tutti abbiano a disposizione le stesse fonti informative, anche se viste da angolazioni diverse.

Il disegno del framework applicativo è stato interamente sviluppato sulla suite Atlassian sfruttando Jira per la parte di attuazione dei processi e Confluence come base documentale su tutto il processo di business.


SCHEMA APPLICATIVO CON LA SUITE ATLASSIAN

Dopo aver trovato gli elementi ed un vocabolario comune da un punto di vista organizzativo, di processo e di metodo, siamo passati all’implementazione del nostro modello.
Per quanto mi riguarda intravedo in Jira una sorta di database di oggetti che posso far interagire tra loro, dandone un ordine e degli elementi di processo, organizzandoli per rispondere alle esigenze dell’azienda.

Ovviamente ci sono delle regole di base dalle quali non derogo, per esempio quella di snaturare il significato e l’utilizzo di oggetti come Epic e User Story, che nella piattaforma hanno loro caratteristiche e connotati ben precisi.

Sfruttando le caratteristiche di “framework” di Jira, lo schema che abbiamo applicato (evidenziato nella figura successiva) permette di relazionare oggetti e processi in modo coerente.

CONTAINER DELLE INIZIATIVE

Quello che chiamo “container” di fatto è un progetto Jira – purtroppo si chiamano così… come purtroppo le issue si chiamano issue per poi essere tipizzate – che contiene solamente oggetti di tipo “iniziativa” e “change request”, a cui sono stati dedicati sia processi che valori (es. le pesature dei rischi, valutazioni macro economiche, ecc.) necessari poi alla gestione e alla vita dell’oggetto stesso.


CONTAINER DEI REQUISITI

Ogni “iniziativa” dopo una prima valutazione di “business” e una sorta di approvazione alla valutazione tecnica, viene scomposta in “requisiti” che sono all’interno di un container dedicato e anch’esso gestito in modo personalizzato.
I requisiti vengono poi scomposti in “epiche” che risiedono in container particolari, tipicamente definiti come “team”, in modo che le analisi tecniche, una volta approvata iniziativa e requisiti, possano essere poi scomposte in “user story” e portate in lavorazione.

Tutto questo processo di fatto si basa su diversi livelli di analisi, sia strategica, di business e tecnica che permette di pianificare correttamente la roadmap di rilascio.

Per poter arrivare ad una struttura coerente sono stati inseriti diversi addon fortemente integrati in Jira, in particolare:


ADDON PER GESTIRE IL PORTFOLIO

Structure for Jira

Permette di gestire in modo puntuale una struttura gerarchica in Jira degli oggetti, sfruttando appieno le caratteristiche di Jira e degli oggetti. Oltre a questo è stato molto utile per la potenza di calcolo che offre potendo infatti gestire all’interno delle board sia visualizzazioni personalizzate ma soprattutto delle colonne “formula” in cui poter costruire e calcolare dati a partire da informazioni degli oggetti, necessari per esempio al processo di valutazione.
Un esempio per tutti, il ranking delle iniziative viene calcolato attraverso delle formule che mettono insieme dei dati relativi ai rischi, alle valutazioni di business come il customer value o il business value, in modo che il backlog venga già proposto in modo preordinato.
In questo modo chi gestisce l’iniziativa è in grado di vedere in tempo reale, tutta la sua composizione, dall’iniziativa fino alla singola user story che la compone e allo stato di lavorazione a partire dal basso per salire man mano sulla gerarchia. 
Di fatto si genera un drill-down che permette di vedere i dati dal raggruppamento più alto (iniziativa) al singolo oggetto di lavorazione (user story).


Structure Pages

In un Portfolio che si rispetti non deve mancare un corretto aspetto documentale, integrato con gli oggetti operativi di Jira. Questo lo si ottiene sfruttando Confluence (integrato in modo nativo a Jira) e soprattutto utilizzando Structure Pages che permette di inserire nella gerarchia degli oggetti, le pagine relative di Confluence, vale a dire quelle dove gli oggetti sono descritti. Il risultato è che all’interno di Jira non solo è possibile vedere nella stessa gerarchia la relativa documentazione, ma questa è anche modificabile “inline” senza dover fare “switch” tra Jira e Confluence.

Structure Gantt

Gestire correttamente il portfolio delle iniziative non significa solo riuscire a vedere correttamente tutta la filiera dell’iniziativa ma bensì poterne identicare le roadmap ed eventualmente gli impegni. Questo mestiere lo svolge l’addon Structure Gantt che permette di visualizzare i dati in forma di roadmap, di vedere l’associazione degli oggetti di lavorazione alle persone e/o team e di valutarne la corretta capacity.


IL PROCESSO COMPLETO

Il Project Portfolio naturalmente è una parte del processo complessivo di lavorazione e manutenzione delle iniziative.
Per arrivare a dare una coerenza e una continuità ai dati sono stati inseriti Jira Service Desk, Insight Asset Management e Tempo Timesheet.

Jira Service Desk

Modulo sviluppato da Atlassian che permette la gestione del supporto e dei ticket con particolare attenzione alla gestione delle SLA e dei processi certificati ITIL.
Fortemente integrato a Jira Software, Service Desk offre una gestione del supporto dettagliata e puntuale permettendo di mantenere un forte controllo sulle tempistiche e sui risultati.

Insight Asset Management

Questo addon lo considero fondamentale per una corretta gestione delle informazioni in Jira. E’ un sistema di gestione degli asset aziendali, tipicamente utilizzato per gestire gli asset software e hardware, ma di fatto lo si può usare per mille scopi diversi.
Nella soluzione che sto descrivendo è stato utilizzato sicuramente per gestire gli asset hw e sw ma anche per gestire prodotti e servizi, software sviluppato e caratteristiche particolari dei singoli prodotti che non aveva senso inserire in ogni oggetto iniziativa.
Il risultato è che una volta messa in produzione un’iniziativa, questa viene collegata ad una sua “anagrafica” in Insight e questo permette di mantenere traccia di tutto ciò che a quella iniziativa accade sia in fase di sviluppo, ma anche e soprattutto in fase di rilascio e manutenzione, infatti ogni ticket generato, ogni change request valutata saranno sempre collegati al prodotto servizio di riferimento.

Tempo Timesheets

Nella valutazione delle iniziative come già descritto entrano molti parametri e pesature, tipiche del business, ma per avere un reale stato del progresso e degli effort effettivamente sostenuti, la gestione dei worklog è indispensabile, soprattutto, ma non solo, se come Coopservice le capacity dei team vengono gestite attraverso il tempo.
Tempo Timesheets è un addon ben costruito e utilissimo perché oltre alla gestione del tempo permette una serie di configurazioni aggiuntive che ad esempio nel nostro caso, sono state utilizzate per gestire l’imputazione delle ore lavorate sulle corrette commesse generate e allineate dal sistema ERP.


IN CONCLUSIONE

Alla domanda, è possibile gestire un Project Portfolio con la suite Atlassian, la risposta è sicuramente SI!
Vorrei mettere in risalto alcuni aspetti relativi alla soluzione descritta (a grandi linee) in questo articolo e adottata per Coopservice.

NON È LA SOLUZIONE, MA BENSÌ LA LORO SOLUZIONE.

Le scelte fatte in questo progetto potrebbero essere sicuramente riproposte in altre realtà, ma l’utilizzo degli addon, la loro integrazione e quali in effetti utilizzare potrebbe portare a scelte diverse. 
In altre realtà ad esempio ho preferito valutare ed inserire addon come Portfolio for Jira oppure BigPicture nella struttura del Project Portfolio, tutto dipende da quelli che sono i requisiti che studio nell’organizzazione, il tipo di risultato che ci si aspetta di ottenere e soprattutto dalle caratteristiche dei singoli addon più utili al raggiungimento dell’obiettivo.

Una considerazione particolare a questo articolo. Non sono entrato nel dettaglio delle singole configurazioni e del come piattaforma, processi e addon sono stati integrati perché non voleva essere un manuale tecnico, ma solamente un’indicazione sul come si possano gestire problemi complessi con una piattaforma come Atlassian, per il resto, se vuoi saperne di più… ne possiamo parlare.

Un particolare ringraziamento a Gianfranco Scocco per la collaborazione sia in termini progettuali che per la partecipazione all’evento di giugno in cui personalmente si è esposto a raccontare la propria esperienza.
Un grazie anche a Getconnected con cui collaboro in modo attivo da diverso tempo, per darmi la possibilità di affrontare progetti così interessanti e permettermi poi di raccontarli agli eventi, nei workshop.

Grazie a Roberto per averci permesso di pubblicare il suo articolo. Il post originale e altri contributi sono disponibili sul suo blog robertogiari.it.

Registratevi alla NEWSLETTER MENSILE per non perdere alcuna nuova uscita!

 

SUL NOSTRO CANALE YOUTUBE È DISPONIBILE LA REGISTRAZIONE DELLO SPEECH

Placeholder Video