Premessa: la storia e la teoria che ci sta dietro

Su MokaByte stiamo pubblicando una serie di articoli scritti nello stile del cosiddetto business novel. Si tratta di un genere piuttosto diffuso nel panorama nordamericano dell’editoria specializzata, in cui si affrontano temi di tipo professionale e aziendale non con un saggio, ma con racconti o un romanzo in cui problemi, ipotesi per risolverli, soluzioni adottate e riflessioni teoriche si intrecciano alle vicende dei personaggi, alle loro azioni.

Più che spiegare un tema, si racconta una storia, allo scopo di parlare di argomenti complessi ma con un taglio leggero e vicino all’esperienza, sperando di rendere il tutto più coinvolgente per il lettore.

In questo caso, la nostra storia parla della creazione di ecosistemi digitali e di come le organizzazioni e le aziende adottino dei cambiamenti che portano allo sviluppo di tali ecosistemi digitali.

Per agevolare la comprensione della teoria inserita all’interno del racconto, abbiamo pensato di estrapolare dalla nostra narrazione i concetti teorici e di inserirli in articoli di approfondimento a sé stanti, come quello che state leggendo.

Sia gli articoli narrativi che quelli “teorici” fanno riferimento al mio lavoro di agile coach all’interno dell’azienda di consulenza e coaching per cui opero.

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:

[…] noi abbiamo un particolare modo di intervenire”, spiega Marco ai manager, “che punta anzitutto a rilasciare del valore per il cliente. Questo vuol dire che, se per qualsiasi ragione, a un certo punto si decidesse di interrompere il rapporto, al cliente deve comunque rimanere qualcosa di concreto e non l’idea di aver perso del tempo […]  insieme a voi cercheremo di tradurre la vision ad alto livello in una serie di attività, una lista di iniziative, di cose da fare per soddisfare determinate esigenze di business. E questo, che non è un semplice elenco, si chiama backlog. Poi ci daremo dei criteri che permettano di definire con certezza se e quando una determinata iniziativa sia completata oppure no.

Il backlog delle iniziative

L’approccio descritto nel racconto dal mio collega è 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 operativi.

• Questa scomposizione in tre livelli, non deve essere presa come una regola, ma solo come una semplificazione fatta per comodità di ragionamento. Ricorda la divisione in epiche, features, storie di un product backlog in Scrum.
• 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. Questa parte si chiama definizione della conclusione dei lavori, o più sinteticamente Definition of Done (DoD).
• Tale elenco è obbligatoriamente ordinato per priorità. 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 (DoD). 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.

Per tutte queste caratteristiche, in perfetta analogia con il framework metodologico Scrum, tale elenco ordinato di priorità prende il nome di Backlog di trasformazione di cui è riportato un esempio nella figura 2.

La pianificazione della trasformazione

La creazione della lista delle iniziative di trasformazione corrisponde a creare una sorta di pianificazione della trasformazione. Pianificare il cambiamento sembra un ossimoro. E, in effetti, ciò che noi proponiamo ai nostri clienti è più articolato di una semplice pianificazione: la nostra strategia mira a far coesistere la progettazione con l’improvvisazione— in senso jazzistico, non nell’accezione negativa di pressapochismo — e la pianificazione con l’adattamento. Si tratta della definizione 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

Analogamente a uno Scrum team che lavora per sprint,  proponiamo un approccio 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.

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.

Conclusione

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.