Flight Levels in Action di Klaus Leopold

La quarta conferenza del primo Agile100 ha invitato i partecipanti a volare. Klaus Leopold ha mostrato con "Flight Levels in Action" come migliorare un'organizzazione a diversi livelli con il suo modello.

I Flight Levels comprendono tre livelli che trattano i seguenti argomenti:
- Flight Level 1: Livello operativo
- Flight Level 2: Coordinamento
- Flight Level 3: Gestione strategica del portfolio

Klaus lo spiega più in dettaglio nelle sue slide, disponibili nel Recap di maggio dell'Agile100. Inoltre, la presentazione qui sotto mostra bene come i Flight Levels funzionano in azione.

Flight Levels in Action

Altro su Klaus Leopold

Il Dr. Klaus Leopold, informatico, pioniere del Kanban e creatore del modello dei Flight Levels, ha molti anni di esperienza come consulente di top management con circa 1000 partecipanti ai workshop all'anno. Consiglia aziende in tutto il mondo su come agire in modo agile sul mercato. Klaus è autore del bestseller Rethinking Agile, Practical Kanban e co-autore dell'opera di riferimento Kanban Change Leadership. È co-fondatore della Flight Levels Academy e pubblica i suoi pensieri ed esperienze attuali nel mondo dei Flight Levels e dello sviluppo organizzativo sul suo blog www.LEANability.com.

“La teoria senza pratica è inutile. La pratica senza teoria è costosa.”

Flight Levels in Action (Trascrizione)

Sohrab: Bentornati a tutti. È fantastico avere Klaus Leopold con noi oggi. Klaus e io in realtà non ci siamo mai incontrati di persona prima, ma abbiamo molte persone che hanno frequentato i suoi corsi e i miei corsi. Nei miei corsi, si riferivano sempre a Kanban Klaus, e forse nei suoi corsi si riferivano a Scrum Sohrab, non lo so, forse Klaus ce lo può dire. Ma sono molto, molto felice di avere Klaus con noi.

È uno degli autori che seguo da un po'. Mi è piaciuto particolarmente il suo ultimo libro "Rethinking Agile" dove parla dei Flight Levels. Sono sicuro che oggi ne tratterà un po'. E se siete interessati a saperne di più, andate allo stand della sua azienda dopo il suo talk, non durante il suo talk, e interagite con alcuni dei suoi colleghi, penso che Catherine e Cliff saranno lì. Klaus, il palco è tuo.

Klaus: Perfetto. Fantastico. Grazie mille, Sohrab per questa gentile introduzione. Sì, beh, "Rethinking Agile" è il titolo del mio libro, e questo è anche il titolo della mia presentazione di oggi. E penso che il sottotitolo sia più o meno il messaggio che cerco di trasmettere, perché i team agili non hanno nulla a che fare con l'agilità aziendale. Allora di cosa si tratta? Beh, vorrei condividere una storia. Vorrei condividere la storia di un'organizzazione. E questa organizzazione aveva dei problemi. Il problema principale era, almeno secondo loro, che volevano migliorare il loro time to market. Dicevano: "Ok, i nostri progetti impiegano troppo tempo per essere completati. Dobbiamo davvero accorciare il nostro lead time verso il mercato."

E beh, sento spesso questo tipo di desideri, "Vogliamo migliorare il nostro time to market." Ma da una prospettiva aziendale, c'è molto di più dietro alla riduzione del time to market. In questa particolare organizzazione, si trattava molto di essere proattivi sul mercato. Una volta erano leader di mercato, ma ora cercavano solo di stare al passo con i concorrenti. Non è una bella sensazione. E dicevano: "Ok, vogliamo davvero essere di nuovo proattivi, vogliamo sfruttare le opportunità." Intendo, sanno cosa succede sui mercati. E dicevano: "Ok, il problema è che quando cerchiamo di avviare uno dei nostri progetti, l'opportunità è già passata." Quindi, non una buona cosa.

E ovviamente volevano essere preparati per il cambiamento discontinuo che è in corso, giusto? Tutti conosciamo questi nuovi modelli di business che spuntano, non facciamo più progetti, facciamo prodotti, non facciamo più prodotti, facciamo soluzioni, facciamo servizi, facciamo non so cosa. C'è la blockchain là fuori, l'intelligenza artificiale e così via. E dicevano: "Beh, il futuro molto probabilmente accadrà. Ma se continuiamo a lavorare come facciamo oggi, molto probabilmente senza di noi." E dicevano: "Ok, dobbiamo cambiare fondamentalmente quello che stiamo facendo qui." E beh, se senti qualcosa del genere, cosa fai? La risposta è facile, giusto? Diventiamo agili, giusto? Con l'agilità possiamo facilmente affrontare tutti questi argomenti. Beh, e questo è fondamentalmente quello che hanno cercato di fare. Hanno iniziato una trasformazione agile.

Cosa faceva parte della trasformazione agile? Beh, come in ogni manuale Agile, sappiamo che dobbiamo combattere i silos funzionali. I silos sono cattivi e malvagi, quindi dobbiamo costruire team cross-funzionali. Dicevano: "Riorganizzazione con team cross-funzionali." Cos'altro? Hanno fatto un passo in più e dicevano: "Ok, dobbiamo avere team di prodotto. Vogliamo team di prodotto cross-funzionali." Questo significa che un team lavora solo su un prodotto alla volta. Buona cosa, se ci pensi. Quindi quello che stiamo facendo è, in qualche modo riduciamo le dipendenze in modo da poter consegnare direttamente al mercato, e questo ovviamente accorcerà il nostro time to market. Beh, personalmente mi piace abbastanza questo.

Dicevano: "Non siamo troppo dogmatici quando si tratta del metodo Agile che i team usano. Possono scegliere il loro metodo agile preferito, ci sono solo alcuni requisiti di cui dovrebbero occuparsi. Ogni team deve avere una visualizzazione, una board. Vogliamo vedere cosa succede nei team." Quindi l'idea era, se vedo cosa fanno tutti i team, posso facilmente andare da un team, iniziare una conversazione sul loro lavoro e discutere i loro problemi. Quindi ogni team deve avere la board, vogliamo vedere cosa succede nei team. Un altro requisito erano le riunioni standard. Ogni team ha bisogno di uno strumento di feedback rapido dove possono adattarsi rapidamente alle cose che emergono, quindi stand-up meeting, ogni team.

Ogni team deve fare retrospettive, che è fondamentalmente un motore di miglioramento, il che ha anche molto senso, giusto? Quindi vogliamo migliorare. Diventare agili non è solo un miglioramento, vogliamo migliorare continuamente. E come ultima cosa, e mi piace anche questa, dicevano: "Vogliamo vedere alcune misurazioni." Sai, una cosa è se ci si sente bene, l'altra cosa è, qual è il risultato effettivo di ciò che stiamo facendo qui? Quindi il lead time all'interno del team dovrebbe scendere e il throughput dovrebbe salire, giusto? Queste erano le due metriche. E beh, se guardi qualcosa del genere, e hai letto anche un solo manuale Agile, probabilmente pensi: "Fantastico. Intendo, capiscono davvero cosa fare, giusto? Intendo, è quello che devi fare. Nulla può andare storto."

Beh, è quello che hanno provato. Allora come hanno affrontato questa trasformazione? La primissima cosa che hanno fatto è stata creare un progetto di trasformazione di un anno e mezzo. Lo sentite? Questo è il mio tipo di umorismo, giusto? Vogliamo diventare agili, e la prima cosa che ci viene in mente, definiamo il piano waterfall su come diventare agili. Non sono così sicuro che sia il modo migliore. Ma, ok, è quello che hanno fatto. Un piano di progetto di un anno e mezzo, come diventare agili. E una delle primissime cose in questo piano di progetto era, stiamo parlando di 600 persone qui, non è troppo grande, ma comunque 600 persone, un bel po' di persone. Dicevano: "Tutti questi, beh, devono ricevere una qualche formazione agile di base."

Immagino che tutti qui ne abbiano sentito parlare, l'agilità non riguarda tanto le pratiche. L'agilità riguarda molto il mindset. Preoccupati di questo? È il mindset. Se solo le persone hanno il mindset giusto, tutto è fantastico. Quindi non riguarda le pratiche. Riguarda il mindset. E questo è quello che hanno fatto. Hanno avviato questo programma di mindset agile di un giorno, in cui tutte le 600 persone sono passate, e poi potevano fondamentalmente spuntare la casella nel piano di progetto "mindset agile stabilito". Possiamo pensare se funziona così, ma forse serve una formazione di due giorni, giusto?

Cos'altro? La riorganizzazione è stata attuata. Cosa significa? Le persone sono state fondamentalmente lanciate in aria, sono atterrate da qualche altra parte nell'organizzazione in questi team di prodotto cross-funzionali, e poi hanno iniziato a implementare l'agile team per team.

Quindi i team Scrum hanno ricevuto la loro formazione Scrum, formazione Product Owner, e i team Kanban hanno costruito dei sistemi e cose del genere. E beh, all'inizio, tutto questo processo era supportato da 16 coach esterni, il che è fantastico quando gestisci una società di consulenza. Ma se guardi cosa sta succedendo qui, stiamo parlando di 600 persone. Quindi davvero... se pensi solo a quanta formazione è necessaria, hai probabilmente bisogno dei 16 coach esterni.

Cos'altro? Mi piace questa. Dicevano: "Dobbiamo costruire capacità interne." Hanno formato 11 coach interni e l'idea era: "Ok, dobbiamo mantenere la conoscenza nella nostra organizzazione", perché l'ho visto così spesso, finché i consulenti esterni sono qui, tutto è più o meno ok. E quando i coach e consulenti esterni se ne vanno, molte persone dicono: "Finalmente, possiamo tornare alla normalità." Quindi, beh, probabilmente non vuoi tornare alla normalità se investi così tanti soldi. Allora, questo era il piano, più o meno. Qual era il rapporto sullo stato? Il rapporto sullo stato dopo circa un anno diceva che l'80% dei team era completamente trasformato. Mi piace questo linguaggio, giusto? Erano completamente trasformati. Cosa significa che l'80% dei team era completamente trasformato?

Beh, potevi fare molti di questi controlli nel tuo piano di progetto: retrospettiva, check, supporto, ovviamente riunioni standard, check, check, check. C'era una casella chiamata metriche. E dicevano: "Sì, i team stanno facendo metriche, ma... ok, spuntiamo la casella, ma diamo un'occhiata alle metriche. Questo è il motivo per cui le abbiamo." Ora diventa un po' interessante. Questo è un cosiddetto grafico di Velocity degli Sprint Scrum. Vi mostro questi grafici di velocity e lead time un po' dopo, e quello che vedete qui sono le tendenze dei team. Quindi è un grafico di tendenza non di un team ma di più team. E l'idea è che vogliamo vedere, in generale, stiamo migliorando o no? È una filosofia di misurazione del throughput. Fondamentalmente significa quanto un team sta consegnando.

Quindi vediamo l'asse del tempo sull'asse X, e sull'asse Y vediamo i punti storia fantasia, credo si chiamino, di Scrum. Questa è la velocity. E la tendenza, è quello che si aspettavano di vedere. Volevano vedere che, ovviamente, la velocity saliva. All'inizio, forse non c'è molta velocity, perché tutto è nuovo, i team devono imparare come funziona tutto, ma poi deve decisamente salire. Bello. Questo è il risultato atteso. Il risultato effettivo era così. Quindi, sì, è migliorato un po', ma poi è sceso di nuovo. Dicevano: "Cosa sta succedendo qui? Non siamo sicuri. Questo non è quello che ci aspettavamo." E beh, le prime voci, potevi sentire le prime voci in questa organizzazione, e dicevano: "Beh, sai, te l'avevamo sempre detto, Scrum non funziona. Questa è la prova, giusto? Kanban è molto meglio di Scrum, giusto?"

Quindi, se Kanban è meglio di Scrum, diamo un'occhiata ai grafici Kanban. Questo è il grafico del lead time Kanban. Il lead time è fondamentalmente la velocità, quanto velocemente stiamo consegnando. È di nuovo un grafico di tendenza di più team. Vediamo la tendenza sull'asse X, e sull'asse Y la velocità, quanto sono veloci. E ovviamente volevano vedere qualcosa del genere: il lead time scende, giusto? E beh, il risultato effettivo era così. Dicevano: "Beh, è un po' fantasia. Possiamo dire che non sta peggiorando. Ma è abbastanza difficile dire che sia molto meglio." Erano un po' sconcertati. Dicevano: "Ok, non sappiamo cosa sta succedendo qui." Questo è il problema con questi grafici.

Il problema è che è abbastanza difficile graficare se non c'è miglioramento, perché stiamo parlando di grafici di team e di grafici dopo una riorganizzazione. Questo significa che questi team non esistevano prima. Quindi non posso confrontare perché i team non esistevano prima. Ma c'era un grafico che esisteva prima che diventassero agili e dopo essere diventati agili. Ed è il time to market delle loro iniziative. Ricordate, questo è il motivo per cui hanno fatto tutto, perché il time to market stava salendo. E facevano iniziative prima di diventare agili. E stavano ancora facendo iniziative dopo essere diventati agili.

Quindi il time to market continuava a salire e dicevano: "Ok, dobbiamo cambiare questo. Dobbiamo far scendere questa linea." Quello era il risultato atteso. Il risultato effettivo era così. E questo fa davvero male perché quello che vediamo qui, non è che non vediamo miglioramento. È che sta peggiorando. Sono diventati agili e ci voleva più tempo per consegnare al mercato. E poi dicevano: "Ma che fenomeno sta succedendo qui?" Intendo, questo non ha senso per loro, giusto? E beh, mi hanno sentito parlare a una conferenza dove parlavo di ottimizzazione locale versus ottimizzazione globale e cose del genere. E dicevano: "Beh, forse ha qualcosa a che fare con quello di cui stavo parlando."

[La trascrizione completa continua nell'articolo originale in inglese. Per la versione completa, consulta la registrazione video sopra.]

Sviluppo organizzativo

=> Offriamo molte formazioni per l'agilità organizzativa. Se vuoi saperne di più sull'offerta, dai un'occhiata a Sviluppo organizzativo

Corsi online self-paced

=> Scopri i nostri corsi online self-paced su argomenti agili e Scrum