3 Tips per fare Agile PPM presi dal case Atlassian di Coopservice

Silvia Mantovani agile, atlassian, jira, plugin atlassian

All’evento Atlassian di Mestre che abbiamo organizzato il 18 Giugno è stato protagonista il case study di Agile Transformation e Agile PPM di Coopservice.
Gianfranco Scocco, CIO della società cooperativa e nostro referente di progetto, ha condiviso assieme al nostro Lead Agile Consultant Roberto Giari una dettagliata panoramica delle fasi del progetto e dell’articolazione dei nuovi processi attraverso tool mirati e implementazioni metodologiche dei flussi di gestione.

Non vogliamo limitarci a un “riepilogo” dello speech, che troverete integralmente sul nostro canale Youtube dalla prossima settimana e a cui Roberto dedicherà un articolo, bensì evidenziare 3 Tips importanti al cuore di questo Agile Scaling Model applicato al caso di Coopservice, che vanno tenuti in considerazione quando si vuole intraprendere un percorso di trasformazione. E quando si deve scegliere con chi farlo.

Il mio modello. Non il tuo.


Molte aziende che approcciano l’Agile, ma anche molti supposti professionisti, fanno riferimento a uno o vari modelli, su cui costruire le azioni concrete di cambiamento dei processi e dei metodi di lavoro.

Quale modello “va bene” per il mio business? Quale modello è statisticamente più efficace, o quale è stato utilizzato dal mio competitor di successo?
Domande sbagliate che portano ad altrettanti errati risultati.

Per realizzare un’Agile Transformation di successo, specialmente in ambito PPM e Asset Management, è necessario andare a definire il proprio modello.
Esatto, crearne uno su misura per le proprie esigenze, lavorando sull’identificazione dei needs e dei team / processi da coinvolgere.


Image

La slide mostra le 5 domande a cui dobbiamo dare una risposta per arrivare a creare il nuovo modello di cambiamento che vogliamo (e necessitiamo).
Partendo dallo Scope, chiedendoci cosa e perché vogliamo cambiare, e seguendo un flusso ciclico che ci permette di ridefinire eventualmente il nostro modello davanti alle necessità.

Ponete attenzione all’elemento centrale CHI: quello è il vostro centro di gravità, le persone e il dialogo con esse. Nessun cambiamento è realmente possibile senza il coinvolgimento diretto dei team e nessun nuovo processo sarà efficace se non partirà dai dati e dalle esigenze di tutti i soggetti coinvolti.

Documentation first!


Un errore di metodo lavorativo in cui incorriamo spesso è quello di sacrificare la documentazione a favore della definizione immediata degli step di lavoro per attivare subito l’operatività, in poche parole le issue.
Al contrario, la documentazione è essenziale e prioritaria, deve antecedere la suddivisione delle attività e raccogliere requisiti, dati e motivazioni che giustifichino proprio la suddivisione del lavoro.

Questo è un fattore chiave per tutti i livelli, dal management all’operation, ma diventa chiaro che alzando l’asticella della complessità e identificando delle figure di responsabilità, è soprattutto in ottica di PMO che questa esigenza deve essere percepita con chiarezza e diventare un cardine del processo di riqualificazione organizzativa, da comunicare poi a tutti i livelli.
Immaginate la “semplicità” di recuperare informazioni su stime e tempistiche, se ogni attività è frutto di un’analisi dettagliata e se questa analisi è sempre visibile e trasparente!

Ecco perché un’altra sostanziale implementazione diventa quella di integrare sempre la documentazione al lavoro operativo di sviluppo.


Image

Una schermata delle Activities su Jira collega a destra alla pagina Confluence di documentation

Framework Applicativo x3


La definizione del Framework Applicativo è il cuore della realizzazione del nuovo metodo stabilito, l’ossatura dei nuovi processi. In modo un po’ provocatorio, vogliamo portare la vostra attenzione su 3 caratteristiche che dovrebbe sempre avere:

  • Circolare. Soprattutto in presenza di aziende complesse e dotate di un service desk.
    Non significa solo che i processi del framework sono ripetibili, bensì che tutti i livelli del framework sono coinvolti e aggiornati. Si intende che al completamento di uno step o alla chiusura di un ticket, sia previsto – o addirittura automatizzato – l’update delle informazioni (e degli status) e la ri-attivazione del flusso. In questo modo assicuriamo controllo sulla visibilità delle attività e tracciabilità delle informazioni.
  • Implementato. Mutuando dal primo punto potremmo dire “a ciascuno il suo framework”, specialmente se utilizzando la suite Atlassian abbiamo a disposizione una riserva di estensioni come quella del suo Marketplace. Le moltissime App permettono di personalizzare ed estendere le funzioni dei software andando a tracciare gli elementi più sostanziali del nostro lavoro, come la budgetizzazione del tempo. Il framework viene così implementato “a misura” di business. O meglio, degli indicatori del nostro rendimento e dei driver delle nostro decisioni di cambiamento.
  • Customizzato. In questo caso però non inteso come “per il custom”, ma declinato in fase applicativa a misura di ogni tipologia di user. Permission e implementazione specifica dei tool permetteranno per esempio al PM o al PMO di avere accesso a dati e stime di avanzamento diverse rispetto a un team dedicato su un singolo progetto.

Image

Per qualunque approfondimento sui tool Atlassian e le metodologie Agile di Portfolio e Project Management, Service Desk e Asset Management i nostri consulenti ed esperti Atlassian sono a disposizione!


Scrivici