Il Cambiamento Culturale che accompagna l’adozione della filosofia DevOps è un cambiamento verticale, interessando gran parte dell’azienda e difficilmente attuabile in pieno senza una reale azione di adozione da parte del Team Level e del Program Level (Middle Management).

In particolare, così come accade per l’adozione di Agile/Lean, attualmente è proprio il Program Level l’area in cui gli sforzi di Change Management sono più forti. Questo perché le nuove generazioni di Dev cominciano ad avere nel proprio DNA la propensione a lavorare in chiave Agile e il passo a DevOps è più naturale, anzi è spesso trainato proprio da loro.

Nel Middle Management, c’è invece maggiore resistenza al cambiamento, essendo molto spesso immersi in decine di procedure e processi estremamente burocratizzati, cosa che porta il manager ad occuparsi della relativa compliance, perdendo di vista l’obiettivo primario e fondamentale di supportare l’attività dei Team (e dell’azienda) nel produrre soluzioni di Valore per il cliente e gli stakeholder annessi.

Detto questo, per accompagnare il cambiamento è spesso indispensabile utilizzare e far leva su quello che è il know-how proprio delle persone. Facciamo un esempio: in un’azienda mediamente strutturata troviamo sicuramente qualcuno che si occupa del processo di release, sia che si chiami formalmente Release Manager o che abbia un titolo più generico.

Come spiegare e convincere un Release Manager (RM) a sperimentare il nuovo approccio DevOps, possibilmente in chiave Lean Change (o anche Popcorn Flow)?

Con molta probabilità questa figura sfrutterà i principi base di ITIL che contemplano (tra le tante cose) le best practice per la gestione del cambiamento. In particolare ITIL definisce in modo puntuale il concetto di Standard Change (associato a quello di Normal Change di cui non parleremo):

“Standard Changes are pre-approved changes that are considered relatively low risk, are performed frequently, and follow a documented (and Change Management approved) process. Think standard, as in, done according to the approved, standard processes.”

DevOps, Agile e ITIL

Partendo da questa definizione è possibile individuare più di una serie di elementi che avvicinano ITIL a DevOps:

• ·relatively low risk: questo aspetto è assolutamente fondamentale anche per DevOps. Tutte le attività di automatizzazione, da quelle relative ai test a quelle relative ai delivery, sono proprio pensate, studiate e concretamente realizzate per ridurre quanto più possibile il rischio di insuccesso nel deployment, della soluzione o di un suo progressivo e veloce aggiornamento;
• ·are performed frequently: la necessità di avere un ridotto Time-to-Market è all’ordine del giorno. Ma non è solo questo! Infatti, la “ripetitività” consente di affinare le proprie pratiche e i propri livelli di automatizzazione, rendendo l’intero ciclo di DevOps un artefatto in continua evoluzione;
• Think standard, […], standard processes: la standardizzazione, frutto di micro esperimenti, è alla base della House of Lean e quindi dello stesso DevOps.

Il punto, invece, che deve essere oggetto di pivot è “follow a documented (and Change Management approved) process.”. Infatti ITIL pone particolare enfasi sulla documentazione, puntuale e rigorosa, dei processi, al fine di fornire uno strumento non ambiguo che possa essere utilizzato per eseguire il processo stesso e verificarne l’attuazione.

In DevOps la “documentazione” cede il passo (attenzione: ciò non vuol dire non farla dove necessario!) all’automazione: lo sforzo è quello di creare e rivedere costantemente un full-automated workflow, che automatizzi quanti più step possibili dell’azione di delivery (test, test di integrazione, provisioning, solution availability, ecc.) e diventi una live-documentation del processo.

Tutto ciò spinge il Release Manager a ripensare il proprio ruolo, trasformandosi di fatto in un Quality Engineer o un Process Engineer che si occupa della governance della pipeline automatizzata di rilascio, focalizzandosi sui reali obiettivi: Qualità, Abbattimento del Rischio e Riduzione del Time-to-Market.

In pratica, il Release Manager non si preoccuperà più (esclusivamente?) di redigere documenti di conformità, ma di verificare se la pipeline di rilascio viene correttamente eseguita e rispettata. Un esempio per tutti: se la nostra DevOps pipeline prevede che nessun rilascio avvenga senza che i test di regressione siano superati, il Release Manager dovrà accertarsi che nessuno rilassi il vincolo. Attenzione, però, non si trattai di assumere il ruolo di controllore, ma il tutto va visto sempre in chiave “inspect-and-adapt”: nel caso appena presentato, l’obiettivo finale non è capire chi ha rilassato il vincolo, ma perché ciò è avvenuto, verificando il problema alla fonte (Root Cause Analysis) e attivandosi per modificare con il team la pipeline se ciò sia un’evidente necessità.

L’obiettivo manageriale è quello di raggiungere una High Trust Culture, ricordandosi sempre del mantra: Trust, but Verify!

Il Cambiamento Culturale che accompagna l’adozione della filosofia DevOps è un cambiamento verticale, interessando gran parte dell’azienda e difficilmente attuabile in pieno senza una reale azione di adozione da parte del Team Level e del Program Level (Middle Management).

In particolare, così come accade per l’adozione di Agile/Lean, attualmente è proprio il Program Level l’area in cui gli sforzi di Change Management sono più forti. Questo perché le nuove generazioni di Dev cominciano ad avere nel proprio DNA la propensione a lavorare in chiave Agile e il passo a DevOps è più naturale, anzi è spesso trainato proprio da loro.

Nel Middle Management, c’è invece maggiore resistenza al cambiamento, essendo molto spesso immersi in decine di procedure e processi estremamente burocratizzati, cosa che porta il manager ad occuparsi della relativa compliance, perdendo di vista l’obiettivo primario e fondamentale di supportare l’attività dei Team (e dell’azienda) nel produrre soluzioni di Valore per il cliente e gli stakeholder annessi.

Detto questo, per accompagnare il cambiamento è spesso indispensabile utilizzare e far leva su quello che è il know-how proprio delle persone. Facciamo un esempio: in un’azienda mediamente strutturata troviamo sicuramente qualcuno che si occupa del processo di release, sia che si chiami formalmente Release Manager o che abbia un titolo più generico.

Come spiegare e convincere un Release Manager (RM) a sperimentare il nuovo approccio DevOps, possibilmente in chiave Lean Change (o anche Popcorn Flow)?

Con molta probabilità questa figura sfrutterà i principi base di ITIL che contemplano (tra le tante cose) le best practice per la gestione del cambiamento. In particolare ITIL definisce in modo puntuale il concetto di Standard Change (associato a quello di Normal Change di cui non parleremo):

“Standard Changes are pre-approved changes that are considered relatively low risk, are performed frequently, and follow a documented (and Change Management approved) process. Think standard, as in, done according to the approved, standard processes.”

DevOps, Agile e ITIL

Partendo da questa definizione è possibile individuare più di una serie di elementi che avvicinano ITIL a DevOps:

• ·relatively low risk: questo aspetto è assolutamente fondamentale anche per DevOps. Tutte le attività di automatizzazione, da quelle relative ai test a quelle relative ai delivery, sono proprio pensate, studiate e concretamente realizzate per ridurre quanto più possibile il rischio di insuccesso nel deployment, della soluzione o di un suo progressivo e veloce aggiornamento;
• ·are performed frequently: la necessità di avere un ridotto Time-to-Market è all’ordine del giorno. Ma non è solo questo! Infatti, la “ripetitività” consente di affinare le proprie pratiche e i propri livelli di automatizzazione, rendendo l’intero ciclo di DevOps un artefatto in continua evoluzione;
• Think standard, […], standard processes: la standardizzazione, frutto di micro esperimenti, è alla base della House of Lean e quindi dello stesso DevOps.

Il punto, invece, che deve essere oggetto di pivot è “follow a documented (and Change Management approved) process.”. Infatti ITIL pone particolare enfasi sulla documentazione, puntuale e rigorosa, dei processi, al fine di fornire uno strumento non ambiguo che possa essere utilizzato per eseguire il processo stesso e verificarne l’attuazione.

In DevOps la “documentazione” cede il passo (attenzione: ciò non vuol dire non farla dove necessario!) all’automazione: lo sforzo è quello di creare e rivedere costantemente un full-automated workflow, che automatizzi quanti più step possibili dell’azione di delivery (test, test di integrazione, provisioning, solution availability, ecc.) e diventi una live-documentation del processo.

Tutto ciò spinge il Release Manager a ripensare il proprio ruolo, trasformandosi di fatto in un Quality Engineer o un Process Engineer che si occupa della governance della pipeline automatizzata di rilascio, focalizzandosi sui reali obiettivi: Qualità, Abbattimento del Rischio e Riduzione del Time-to-Market.

In pratica, il Release Manager non si preoccuperà più (esclusivamente?) di redigere documenti di conformità, ma di verificare se la pipeline di rilascio viene correttamente eseguita e rispettata. Un esempio per tutti: se la nostra DevOps pipeline prevede che nessun rilascio avvenga senza che i test di regressione siano superati, il Release Manager dovrà accertarsi che nessuno rilassi il vincolo. Attenzione, però, non si trattai di assumere il ruolo di controllore, ma il tutto va visto sempre in chiave “inspect-and-adapt”: nel caso appena presentato, l’obiettivo finale non è capire chi ha rilassato il vincolo, ma perché ciò è avvenuto, verificando il problema alla fonte (Root Cause Analysis) e attivandosi per modificare con il team la pipeline se ciò sia un’evidente necessità.

L’obiettivo manageriale è quello di raggiungere una High Trust Culture, ricordandosi sempre del mantra: Trust, but Verify!