OKR, cadenze in Kanban e Flight Levels: come uscire dalla trappola dell’agilità locale?

Che si tratti di Scrum o Kanban ci si rende rapidamente conto che lavorare a livello di un solo team è esempio di ottimizzazione locale: presto o tardi emergeranno innumerevoli frustrazioni legate a cosa succede “fuori dal team”.

Questo articolo non copre aspetti avanzati di Kanban e OKR, ma vuole illustrare un possibile approccio integrato di diverse pratiche, affrontando anche l’argomento “obiettivi”.

Di obiettivi se ne parla sempre poco, sia in Scrum che con Kanban, dove si tende a focalizzarsi troppo sull’output (velocity e numero di funzionalità prodotte da una parte, lead time e throughput dall’altra).

OKR: Tutti nel parlano, nessuno li sta davvero utilizzando

OKR significa “Objective and Key Results”: è un framework per creare allineamento sugli obiettivi e sui risultati attesi in ottica strategica, con una cadenze di breve-medio periodo. 

È importante sottolineare che gli OKR non sono un sistema di performance management, motivo per cui è sconsigliabile calare gli OKR a livello individuale: fermiamoci a livello di obiettivi di team.

Parlo di “livelli” perché, gli OKR sono strutturati per facilitare la condivisione degli obiettivi: è quindi possibile spezzare un obiettivo strategico, a livello aziendale o di dipartimento, in un risultato tattico per una linea di business o di team.

No alt text provided for this image

Objective: è un obiettivo espresso come una piccola “mission”, temporanea e qualitativa. Pensate all’obiettivo come all’effetto che le nostre attività avranno sul mercato, o al cambiamento nel comportamento dei nostri clienti.

Key Result: è un risultato chiave quantitativo che permette di raggiungere l’obiettivo. Deve essere numerico e quindi specificità e misurabilità del risultato sono d’obbligo.

Un esempio di obiettivo a livello strategico potrebbe essere:

  • Obiettivo: Rinforzare la presenza su un settore automobilistico debole
  • Risultato chiave: Il veicolo vince premio come migliore della categoria
No alt text provided for this image

A scopo esemplificativo riporto solo un risultato chiave associato all’obiettivo: è ovvio che al raggiungimento di un obiettivo, soprattutto di alto livello, concorrano più risultati chiave – restando nell’esempio, altri risultati chiave potrebbero coinvolgere marketing e vendite, oltre alla produzione.

Proviamo a calare il questo primo risultato chiave ad un livello organizzativo inferiore, trasformandolo in un obiettivo per il team che coordina lo sviluppo del prodotto e quindi supervisiona il il lavoro di più team (ad esempio: un team per gli interni, un team per il sistema di trasmissione, ecc.).

  • Obiettivo: Il veicolo vince premio come migliore della categoria
  • Risultato chiave: Abitacolo silenzioso (rumorosità <70 dB)

È possibile che avremo più team che si prenderanno in carico i diversi aspetti del nostro prodotto, la logica è quella dei feature o component team.

No alt text provided for this image

Proviamo ora spingerci ad un livello organizzativo inferiore, in cui, nuovamente, il precedente risultato chiave viene trasformato in obiettivo, questa volta del team che si occupa dei sistema di trasmissione.

  • Obiettivo: Abitacolo silenzioso (rumorosità <70 dB)
  • Risultato chiave: Integrare nuova tecnologia nel cambio

Il terzo elemento fondamentale degli OKR è un livello di aspettativa, aggiornato settimanalmente, su quanto il team di sente sicuro del raggiungimento di uno specifico Key Result. 

Questo intervallo di aspettativa può essere espresso su un intervallo tra 0 e 1 (quello originariamente usato in Google), tra 1 e 5, tra 1 e 10 (meglio utilizzare scale brevi).

L’obiettivo, per essere considerato sufficientemente ambizioso, dovrebbe contenere dei risultati chiave che inizialmente abbiano un livello di aspettativa non superiore al 50%: significa che il team si sta prendendo in carico un risultato che, al momento di iniziare il lavoro, ha un rapporto tra successo e insuccesso di 50/50.

No alt text provided for this image

Attenzione: esattamente per questo motivo gli OKR non devono essere usati, come dicevo poco prima, come sistema di performance management. 

Il fallimento nel raggiungere un obiettivo di team ambizioso non deve in nessun modo influenzare la valutazione della performance del singolo. Se prendersi rischi è penalizzato, perché prendersi rischi e, di conseguenza, perché innovare?

Non tutto quello che conta è misurabile

Per non cadere nella trappola della mera valutazione dell’output e quindi di seguire ciecamente solo i risultati chiave quantitativi, occorre predisporre un formato di aggiornamento che tenga conto del contesto. Questo formato può essere anche usato per un aggiornamento settimanale del team e per condividere la situazione al di fuori del team.

No alt text provided for this image

Questo semplice formato, ripetibile anche sotto forma di una board fisica o virtuale, è composto da quattro aree:

  • Priorità della settimana
  • Preview delle prossime 4 settimane
  • Metriche di “salute”
  • Livelllo di aspettativa sui risultati chiave

Ogni lunedì il team si incontra e condivide un aggiornamento su ciascuna di queste quattro aree:

  • Per priorità della settimana si intendono le attività più importanti o urgenti da svolgere nei successivi cinque giorni lavorativi;
  • La preview delle prossime 2/4 settimane serve per anticipare priorità future o possibili dipendenze o colli di bottiglia;
  • Le metriche di salute sono tutto ciò che non è incluso negli OKR, ma che deve restare entro una soglia accettabile. Le metriche di salute possono essere di natura tecnica (es. uptime di un servizio), organizzativa (es. dipendenze sotto controllo), economica (es. P&L) o personale (es. soddisfazione del team);
  • Il livello di aspettativa sui RC rappresenta un aggiornamento su quanto il team è fiducioso del raggiungimento degli specifici risultati chiave. Mentre le metriche di salute ragionano in termini di soglie minime/massi, i risultati chiave ragionano per target specifici.

Questa board può essere utilizzata solo all’inizio e alla fine della settimana. Al lunedì per fare un briefing di inizio settimana e al venerdì per chiudere con un aggiornamento su tutti i fronti, idealmente per celebrare il raggiungimento di qualche attività prioritaria o il miglioramento del livello di aspettativa su qualche risultato chiave.

Quante volte chi si occupa di strategia si lamenta del livello di dettaglio di chi si occupa di operatività, e quante volte chi si occupa di operatività si lamente della vaghezza degli obiettivi strategici?

Tra gli effetti collaterali dell’utilizzo degli OKR c’è anche quello di innescare un meccanismo che incrementa fisiologicamente la qualità degli obiettivi e del come li descriviamo: il gap tra visione strategica e visione operativa può essere ridotto nel momento in cui dalla operatività ci arrivano i parametri concreti che possiamo utilizzare per valutare il raggiungimento degli obiettivi.

Per integrare le comunicazioni con il resto dell’azienda dobbiamo uscire dal singolo team e relazionarci all’esterno: per farlo possiamo appoggiarci sulla struttura, spesso sconosciuta, delle cadenze in Kanban.

Cadenze in Kanban: ovvero del quando parliamo di cosa, e perchè

Anche qui, benché ci sia maggiore familiarità con gli eventi di Scrum, non significa che una cadenza regolare di incontri con uno scopo specifico non esista in Kanban. Esiste ed è configurata in questo modo.

No alt text provided for this image

La ragione per cui le cadenze non hanno preso piede potrebbe essere causata da questa rappresentazione forse eccessivamente complessa, è importante premettere che: 

  • Queste non sono tutte riunioni obbligatorie
  • È probabile che avvengano già in qualche forma nella vostra azienda
  • Vanno trattate come una linea guida per fare riunioni migliori
  • È rilevante il fatto che siano correlate tra di loro a qualche livello

Questi incontri hanno un ruolo importantissimo: garantiscono una permeabilità tra i diversi livelli aziendali, che, altrimenti, rischierebbero di ricadere, nonostante Kanban, nella trappola del miglioramento locale, dell’isolamento dei silos, delle decisioni top-down e in una gestione di progetto praticamente waterfall.

La nostra azienda potrebbe essere letteralmente tappezzata da lavagne Kanban e potremmo non ricavarne alcun beneficio, in mancanza di una visione di insieme e di meccanismi di feedback integrati.

Fatta la dovuta premessa che Kanban prevede un livello di auto-disciplina superiore rispetto a Scrum, quindi ciascuno di questi incontri, in modalità “pull”:

  • Potrebbe essere fatto solo quando serve e non necessariamente in date prestabilite
  • Alcuni di queste riunioni potrebbero non essere fatte nel vostro contesto

Vale il buon senso applicato: se vi rendete conto che i contenuti di queste cadenze Kanban vengono già affrontati in riunioni che tenete regolarmente, non c’è bisogno di aggiungere altre riunioni (nessuno ha bisogno di ulteriori riunioni…). Diversamente, può essere un’ottima occasione per sviluppare la buona abitudine di fare riunioni più efficaci, con agenda e tematiche prestabilite.

Queste cadenze possono servirci per allineare non solo le tradizionali metriche Kanban, legate all’efficienza del flusso di lavoro, ma gli OKR e, quindi, unire valutazioni di efficacia ed efficienza del lavoro a quelle di raggiungimento di obiettivi strategici.

Un ultimo strumento per evitare la troppo comune trappola del produrre in maniera efficace ed efficiente il prodotto o servizio sbagliato sono i Flight Levels.

Flight Levels: Oltre la Kanban Board di team

Mentre la maggior parte dei framework di scaling agile si focalizzano principalmente su Scrum, si parla molto poco su come fare scaling di Kanban.

Questo perché, tra i tanti motivi, c’è che lo scaling di Scrum può essere presentato in maniera meccanicistica (più team, più gerarchia, più meeting, più organizzazione matriciale, ecc.) mentre lo scaling di Kanban è necessariamente più organico e fluido.

Kanban ci mette alla prova sul come vediamo la nostra azienda, a livello sistemico, e sul come eroghiamo i nostri servizi e prodotti, sul cosa vogliamo ottimizzare globalmente — il che potrebbe essere completamente indipendente da un nuovo modello organizzativo o da dinamiche di scaling puramente meccaniche.

Non esiste, insomma, un “kit di scaling” per Kanban, pronto all’uso, da cui possiamo copia-e-incollare un approccio: l’approccio dobbiamo necessariamente costruirlo in base al contesto – questo sarebbe vero e corretto anche per Scrum, lo è sicuramente e obbligatoriamente per Kanban.

No alt text provided for this image

Klaus Leopold da qualche anno ha reso popolare un modello che si chiama Flight Levels, per descrivere come Kanban potrebbe essere usato, in maniera integrata, su più livelli di una organizzazione: la metafora è quella delle diverse altezze di volo. Da un satellite vediamo interi continenti, da un aereo vediamo una nazione, da una mongolfiera vediamo una città. Fanno tutti parte del “sistema mondo”, ma con un livello di dettaglio via via più raffinato.

Il modello che Leopold propone ha tre livelli:

  • Livello strategico
  • Livello di coordinamento
  • Livello operativo

È un sistema Kanban completo, in cui l’output di un flusso diventa input dell’altro:

  • A livello strategico si decide cosa produrre e con che priorità
  • A livello di coordinamento come produrre e a chi farlo produrre
  • A livello operativo lo si produce

La granularità dei contenuti di questi livello va ad aumentare progressivamente, da programma a progetto, da progetto a prodotto, da prodotto a funzionalità, da funzionalità a singola attività. 

Nell’immagine qui sopra ho sottolineato anche a quale livello potrebbero avere impatto quali cadenze Kanban, tenendo conto che:

  • È un suggerimento indicativo, come dicevo sopra, valutate quali riunioni ricorrenti già avvengono nella vostra organizzazione, e decidete se alcuni di questi incontri avvengono già o magari sono da integrare
  • L’indicazione su chi partecipa è: partendo dal livello strategico, alle varie cadenze sono invitati rappresentanti del livello sottostante ma nessuno del livello sovrastante – quindi, ad esempio, ad una Operation Review saranno coinvolti rappresentanti dei livello operativo e di coordinamento ma non quelli del livello strategico.

Visto così questo sistema a livelli rischia anch’esso di ricadere nella trappola di una sistema top-down con una gestione delle attività di progetto in modalità waterfall: è per scongiurare questa situazione che ho pensato di illustrare come l’utilizzo integrato di OKR e cadenze ci aiutano a rinforzare i “feedback loop”, fondamentali per l’adozione di Kanban.

OKR, cadenze in Kanban e Flight Levels

No alt text provided for this image

Giunti fino a qui abbiamo tre strumenti perfettamente integrabili:

  • Abbiamo gli OKR che sono un framework per fissare e restare allineati su obiettivi e risultati attraverso una intera organizzazione;
  • Abbiamo le cadenze in Kanban, che ci permettono di integrare i feedback da diverse parti dell’azienda;
  • Abbiamo i Flight Levels, che ci permettono di visualizzare il sistema Kanban completo, dall’idea al prodotto finito o al servizio erogato.

Riporto alcuni esempi di come alcune delle cadenze Kanban possono interagire nella pratica sia con il Flight Levels sia con OKR:

  • A livello strategico, la Strategic Review trimestrale può essere il momento in cui si valutano gli OKR trimestrali e si concordano quelli per il trimestre successivo. Questo avrà un ovvio impatto diretto sui successivi Replenishment Meeting, Operations Review e Service Delivery Meeting;
  • A livello di coordinamento, la Risk Review mensile può essere il momento in cui discutiamo gli elementi critici a livello di metriche di salute che non raggiungono la soglia minima che ci eravamo preposti. Come illustrato nello schema più sopra, la Risk Review informa il Delivery Planning Meeting e cambia i contenuti di Operations Review e Service Delivery Meeting.
  • A livello operativo, il Replenishment Meeting settimanale può coincidere con l’aggiornamento di fine settimana della status board, in cui, in base all’andamento della settimana, decidiamo quanto e quale lavoro prendere in carico per la settimana successiva, influenzando direttamente il day-by-day del team.

Di nuovo, la parola chiave è permeabilità: per iniziare dobbiamo metterci nella condizione di creare il più piccolo sistema Kanban, magari di un solo progetto, end-to-end, visto da tre “altezze” diverse, che ci permetta di avere queste tre viste integrate non solo a livello di attività da svolgere, ma anche di obiettivi e risultati da raggiungere.

Inizia da quello che stai facendo adesso

Questo articolo non voleva essere una trattazione esaustiva di Kanban, OKR, Flight Levels e cadenze. Ovviamente ciascuno di questi temi racchiude complicazioni non banali nel passaggio dalla teoria alla pratica.

Quella che ho illustrato è una sorta di “starter kit” per poter uscire da un’ottica di miglioramento locale a livello di team, ed entrare nel reame di un miglioramento globale, o quantomeno esteso, introducendo elementi concreti di allineamento in termini di obiettivi e risultati.

C’è una certa eleganza empirica nel mettere assieme queste pratiche: il cambiamento organizzativo non è infatti un pre-requisito per iniziare da oggi ad applicare Flight Levels, OKR e cadenze. Il cambiamento organizzativo potrebbe essere solo una delle possibilit conseguenze delle evidenze empiriche emerse utilizzando Kanban e OKR in maniera diagnostica.

“Start with what you do now” è un principio cardine di Kanban e il primo passo che puoi fare per iniziare a costruire la tua Kanban è quella che viene chiamata “analisi della domanda”, che si può iniziare a fare rispondendo a queste quattro domande:

  1. Punti di partenza delle attività: ovvero chi sono i committenti, le azioni o gli eventi che fanno iniziare le attività nel nostro team? Iniziamo a pensare al nostro team come ad un team di servizio: chi stiamo servendo e per quale motivo?
  2. Flussi delle attività: per ciascuno dei singoli punti di partenza, individuare quali sono tutti gli step necessari per portare a compimento l’attività. Cosa osserviamo? Ogni flusso ha fasi ben distinte, o ci sono fasi che si ripetono? Su quanti di queste fasi il team è autonomo, su quante ha dipendenze esterne? Emergono colli di bottiglia?
  3. Punti di arrivo delle attività: dove finiscono le nostre attività? Che cosa significa che una attività è “finita”? Il committente iniziale corrisponde con il cliente finale?
  4. Aspettative del cliente: per ciascuno dei flussi di attività individuati, quali sono le cause di soddisfazione o insoddisfazione dei nostri clienti, siano essi finali, intermedi, interni o esterni?

Questo ultimo punto inizia ad aprire la questione di come le attività del team soddisfino i clienti interni ed esterni e di come questa considerazione sul livello di soddisfazione apra poi discussioni sul raggiungimento degli obiettivi strategici, partendo dagli obiettivi di un singolo team: se lavoriamo in agilità i nostri obiettivi non possono essere solo quelli di fare più story point o ridurre il lead time!

Approfondimenti

OKR

https://blog.crisp.se/2019/12/03/jimmyjanlen/make-okrs-and-forecasts-come-alive

https://www.infoq.com/news/2019/10/team-feedback-okr

https://felipecastro.com/en/blog/shared-okrs/

https://felipecastro.com/en/blog/okr-vs-kpis/

http://felipecastro.com/en/okr/okr_and-agile/

https://www.atlassian.com/team-playbook/plays/okrs

https://blog.agendashift.com/2019/09/04/there-will-be-caveats-warming-cautiously-to-okr/

Flight Levels

https://www.leanability.com/en/blog-en/2017/04/flight-levels-the-organizational-improvement-levels/

https://www.leanability.com/en/blog-en/2019/03/once-upon-a-time-there-was-a-flight-level/

https://threadreaderapp.com/thread/1104254694136766465.html

https://www.leanability.com/en/video-blog-en/2018/04/lean-business-agility-e026-medical-device-development-flight-levels-and-scrum/

Cadenze in Kanban

https://djaa.com/kanban-cadences/

https://kanbanize.com/blog/kanban-cadences/

https://getnave.com/blog/kanban-meetings/

Metriche

http://cognitive-edge.com/blog/the-banality-of-measurement/

http://cognitive-edge.com/blog/the-myopia-of-metrics/

http://cognitive-edge.com/blog/a-sense-of-direction-3-2

https://aeon.co/ideas/against-metrics-how-measuring-performance-by-numbers-backfires

https://adexchanger.com/data-driven-thinking/what-goodharts-law-can-teach-you-about-performance-data/

https://www.infoq.com/articles/agile-late-metrics-predictability

https://www.jrothman.com/mpd/2019/09/measure-cycle-time-not-velocity/

http://www.marcusoft.net/2019/01/kanbanstats-simplify-process-stats-get-started.html