Agile e Robotic Process Automation (RPA), parte 4 – Retrospettiva finale

Eccoci giunti al quarto ed ultimo post della serie dedicata all’Agile nel mondo della Robotic Process Automation (RPA).

Abbiamo visto insieme come si sono svolte le diverse Iterazioni, cosa è stato introdotto come miglioramento progressivo ed evidenziato le lesson learned che riportiamo per avere un quadro d’insieme del tutto:

  1. Essendo l’obiettivo dell’RPA l’automazione della mimica relativa ad un processo, non si ha nella sostanza un utente utilizzatore, ma solo un “committente” che si aspetta un lavoro finito
  2. La priorità delle Technical Story (TS) è implicitamente dettata dal flow del processo e deve essere possibile rivederla liberamente senza vincoli, in funzione delle esigenze di sviluppo. Quindi non è più utile che sia nelle more del PO!
  3. La review tradizionale non è particolarmente utile nell’accezione comunemente nota. Dimostrare il valore di una TS in modo isolato non ha un grande valore, inoltre il PO, Process Owner(come detto nel post precedente), accompagna il team giornalmente nell’analisi degli elementi di dettaglio del processo, per cui alla fine avrà già una visione completa di quanto realizzato
  4. L’uso di un Flow Chart Mapping (FCM) rende subito visibile il flusso dati e i gate di input/output di ogni storia, consentendo una facile valutazione dei risultati

I Valori ed i Principi Agili si sono dimostrati, ancora una volta, assolutamente adatti nell’ambito complesso, soprattutto per aiutare il team promiscuo a trovare armonia interna.

A questo punto facciamo una considerazione sul risultato finale in funzione degli obiettivi ipotizzati.

L’intera azione di sviluppo prevedeva inizialmente l’obiettivo di realizzare 6 Robot, ovvero di automatizzare 6 flow che precedentemente venivano eseguiti manualmente con il coinvolgimento di diverse risorse e Persone, aziendali e non.

Come abbiamo descritto nel primo post, all’inizio del percorso sono stati utilizzati una serie di strumenti (Product Canvas, Elevator Pitch, ecc) per allineare tutto il team intorno a quello che è risultato essere il cuore di tutto il discorso: “creare sistemi in grado di mimare il comportamento umano“.

Quello a cui non abbiamo minimamente accennato sono stati eventuali aspetti di pianificazione annessi. Ebbene, nessuna azione di stima o previsione è stata necessaria perché l’iniziativa era di per sé completamente allineata con il ben noto Iron Triangle rovesciato:

iron triangle planning

Nel dettaglio, si avevano a disposizione 8 mesi di tempo e un budget determinato dal costo delle Persone coinvolte e pochi elementi variabili di incidenza tollerabile. L’approccio è stato quindi quello di iniziare lo sviluppo, capire la velocity (non tanto in termini di una metrica specifica, ma di quanto il team realisticamente fosse in grado di realizzare) e tarare di volta in volta gli obiettivi.

Dopo le prime 3 iterazioni è parso subito chiaro che l’obiettivo dei 6 processi non era raggiungibile, per cui il PO ha cominciato ad esercitare le giuste leve verso gli stakeholder per riallineare le attese, mentre tutto il team (PO compreso, nel ruolo di Process Owner) ha fatto dei ragionamenti per capire come ottimizzare lo sviluppo.

E qui è nata una soluzione interessante: guardando i processi restanti nel loro insieme, è risultato evidente che una parte degli step costituenti relativi era praticamente comune per 4 dei 5 flow rimanenti.

Questo elemento è stato illuminante per rivedere tre elementi strategici:

  • Pianificazione, si è deciso di ri-pianificare il contenuto del portfolio backlog, non più in funzione della sola importanza (valore relativo) del processo, ma adottando un approccio value-reuse driven, in cui si è dato precedenza ai processi che avrebbero consentito di sviluppare per primi i componenti comuni, abbattendo di conseguenza anche i rischi dello sviluppo relativo
  • Metriche di Effort, per supportare una migliore stima dell’effort necessario per le Techincal Story, si sono stabilite una serie di TS campione (5 nello specifico) rispetto alle quali effettuare una stima massiva (Affinity Grouping) di quanto ipotizzato per le iterazioni a seguire. Le TS di riferimento erano caratterizzate da:
    • Numero di oggetti in ingresso
    • Numero di fonti dati sottese
    • Numero di sistemi terzi interrogati
    • Numero di oggetti in uscita 
  • Deep Analysis, il Process Owner ha modifica il suo approccio al refinement, non limitandosi alla sola rappresentazione tramite Flow Chart Mapping (FCM)del processo ma passando ad una vera e propria reingegnerizzazione. Infatti, il PO ha analizzato quali aspetti del processo consentissero allo stesso di superare la soglia del 90% degli impatti positivi, rimuovendo gli step relativi al resto.

Questi tre elementi hanno consentito di avere una visione più chiara di quanto stesse succedendo, rendendo inoltre possibile diminuire lo scope, del singolo processo e complessivamente, in modo da raggiungere un obiettivo finale realistico in chiave iterativa: ovvero, di quello che resta fuori ce ne occupiamo in seguito se serve!

Si chiude qui questa serie di post dedicati ad una esperienza pratica di adozione di un approccio Agile scrum-like nell’ambito della Robotic Process Automation.

Stay tuned J

Comments are closed.