Digital revolution: La teoria

Digital revolution: La teoria

II parte: Approccio Scrum-like alle trasformazioni organizzative

Un articolo di approfondimento a supporto della narrazione della Digital Transformation nel primo articolo della serie.

La trasformazione agile di una organizzazione: un approccio per esperimenti

Questo mese parliamo dell’approccio che usiamo per supportare i nostri clienti nel processo di trasformazione di una organizzazione; per farlo prendiamo spunto dalla frase del mio collega Marco pubblicata nel racconto:

Il backlog delle iniziative

L’approccio descritto da Marco nella telefonata col cliente è quello che nel tempo abbiamo iniziato a proporre in modo ricorrente ai nostri clienti. Si basa sulla definizione di un elenco di “attività” da svolgere. Tale elenco deve avere le caratteristiche che vediamo di seguito.

  • Si parte definendo una lista di obiettivi strategici di alto livello che sono tipicamente agganciati alla visione strategica della trasformazione. Questi sono obiettivi ispiratori, difficilmente trasformabili in azioni concrete.
  • Per ogni elemento della lista precedente viene identificato uno o più obiettivi operativi che saranno perseguiti tramite alcune iniziative concrete.
  • Ogni iniziativa di questo elenco sarà portata avanti da uno o più persone coinvolte nella trasformazione. Una o più iniziative contribuiscono al raggiungimento degli obiettivi strategici di alto livello.
Figura 1 - Obiettivi strategici, obiettivi operativi, iniziative per implementarli, metriche per comprenderne l’effettiva realizzazione.
Figura 1 - Obiettivi strategici, obiettivi operativi, iniziative per implementarli, metriche per comprenderne l’effettiva realizzazione.
  • Questa scomposizione in tre livelli, non deve essere presa come una regola, ma solo come una semplificazione fatta per comodità di ragionamento.
  • Ogni iniziativa deve comprendere una descrizione delle attività da svolgere e deve definire nel modo più preciso possibile, le condizioni che ne decretano il completamento con successo. Prendendo spunto dalle metodologie agili, chiamiamo questa parte definizione del termine del lavoro, o più sinteticamente Definition of Done (DoD).
  • Tale elenco è ordinato per priorità in base alle necessità o urgenze del cliente. Per esempio se si ritiene più importante la realizzazione di un progetto pilota fatto in Scrum, rispetto alla progettazione del processo di rilascio di nuove funzionalità in produzione tramite Kanban, allora la formazione del team Scrum, il setup e la partenza del progetto saranno più in alto nella lista.
  • Anche le dipendenze e propedeuticità sono importanti per definire l’ordine della lista: ogni iniziativa deve avere una serie di precondizioni che ne abilitano la realizzazione. Se queste non saranno soddisfatte, tale iniziativa non potrà essere messa in lavorazione. Questa parte si chiama definizione di ciò che deve essere disponibile prima di iniziare o più sinteticamente Definition of Ready (DoR). Per esempio la misurazione delle performance nel processo di rilascio di nuove funzionalità sul mercato dovrebbe essere attivata dopo la creazione di tale sistema di controllo fatto con Kanban, ammesso che realmente le due cose siano connesse, ma in questo caso l’esempio serve solo per comprendere il concetto.

Mettere in ordine le iniziative da portare avanti é particolarmente importante è utile quando il lavoro impatta molte aree dell’organizzazione magari in momenti differenti e con strategie diverse: permette infatti di tenere sotto controllo le differenti aree e gli avanzamenti con un unico strumento di lavoro. Spesso infatti si associa il backlog (detto backlog di trasformazione vedi fig 2) a una board in stile kanban.

Figura 2 - Un backlog di trasformazione.
Figura 2 - Un backlog di trasformazione.

La pianificazione della trasformazione

La creazione della lista delle iniziative di trasformazione corrisponde a creare una sorta di pianificazione della trasformazione, cosa che può sembrare un ossimoro. In realtà la strategia che proponiamo ai nostri clienti mira a far coesistere la progettazione con la sperimentazione, la pianificazione con l’adattamento. Si tratta di creare di un percorso in continua evoluzione basato su un approccio sperimentale, iterativo e incrementale.

Nuovamente le analogie con l’infrastruttura metodologica Scrum tornano fortemente a farsi notare: se il product backlog definisce infatti il significato e il valore di un prodotto, il transformation backlog definisce cosa deve diventare l’organizzazione e come raggiungere tale obiettivo.

Sprint Plan

Anche il lavoro operativo si ispira a quello di un team che lavora per iterazioni: in questo caso gli “sprint” non durano alcune settimane ma qualche mese. Ogni iterazione inizia con una pianificazione che concordiamo insieme: partendo dalla testa del backlog si mettono in lavorazione per esempio per i due mesi successivi, alcune iniziative che pensiamo siano compatibili con la capacità del transformation team (vedi sotto); in questo caso la DoD è fondamentale per confrontare effort atteso e capacità del team, esattamente come nello Scrum di progetto del resto.

Una chiara definizione di cosa serve avere prima di iniziare (la DoR) contribuisce a stabilire se è il momento giusto per svolgere una determinata azione.

Raffinamento del backlog

Il backlog è un oggetto dinamico, in costante revisione, riorganizzazione, mutazione. Ai nostri clienti, durante uno sprint proponiamo infatti un lavoro di Transformation Backlog Refinement, un vero e proprio raffinamento in cui si suddividono attività troppo grandi, si cambia l’ordine della lista, si aggiungono o tolgono elementi.

Figura 3 - Il raffinamento del backlog di trasformazione è analogo a quanto si fa con il PBR in Scrum.
Figura 3 - Il raffinamento del backlog di trasformazione è analogo a quanto si fa con il PBR in Scrum.

Il gruppo di lavoro

Anche in questo caso ci ispiriamo a un approccio Scrum-based. Sebbene una trasformazione richieda il coinvolgimento di molte persone con differenti ruoli e responsabilità, nella nostra esperienza riteniamo essenziale la creazione di un team che supporti la trasformazione, coordini le varie decisioni che i vari attori devono prendere, monitori lo stato di avanzamento delle singole iniziative. È principalmente più un lavoro di coordinamento che di diretta decisione: spesso comunica le decisioni che sono però frutto di razionali definiti dagli attori direttamente coinvolti. Per esempio spesso, in un processo di partenza dei vari team Scrum, si definiscono i razionali per identificare il prossimo progetto/team. Tali razionali sono decisi in modo collegiale (per esempio tramite il coinvolgimento del business, di chi coordina i programmatori, dei fornitori esterni.

Quanto qui riportato fornisce qualche indicazione su come progettare e implementare una trasformazione aziendale. Non deve essere preso come un modello da seguire alla lettera, non modificabile, facente parte di un qualche framework certificato. Noi spesso lo seguiamo, tenendo sempre bene presente che il contesto del cliente è la parte importante: comprenderne la cultura, le usanze, le regole, le persone è fondamentale prima di iniziare qualsiasi percorso di cambiamento. Senza mai dimenticare che comunque si tratta di un processo fatto di esperimenti, verifiche, adattamenti.