Superare l’ottimizzazione 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.

Obiettivi e risultati chiave

Con queste premesse, possiamo dire che:

• 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 che spiega quanto detto potrebbe essere il seguente. L’obiettivo a livello strategico è rinforzare la presenza su un settore automobilistico debole; il risultato chiave sta nel fatto che il nostro veicolo vince premio come migliore della categoria.

A scopo esemplificativo, ho riportato solamente un risultato chiave associato all’obiettivo: è ovvio che al raggiungimento di un obiettivo, soprattutto di alto livello, concorreranno più risultati chiave. Restando nell’esempio che abbiamo fatto, altri risultati chiave potrebbero coinvolgere marketing e vendite, oltre alla produzione.

Calare il risultato chiave a un livello inferiore

Proviamo a calare il questo primo risultato chiave a un livello organizzativo inferiore, trasformandolo in un obiettivo per il team che coordina lo sviluppo del prodotto e quindi supervisiona il lavoro di più team, per esempio un team per gli interni, un team per il sistema di trasmissione, e così via. Quello che, al livello strategico, era stato il risultato chiave diventa qui invece l’obiettivo da raggiungere.

• 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.

Ulteriore approfondimento

Proviamo ora spingerci ad un livello organizzativo ancora 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.

Livello di aspettativa

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, per quanto sia 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 a 50.

Attenzione… è esattamente per questo motivo che gli OKR non devono essere usati, come dicevo poco prima, quale sistema di performance management. Il fallimento nel raggiungere un obiettivo di team ambizioso non deve in nessun modo influenzare la valutazione della prestazione del singolo. Se prendersi rischi è penalizzato, perché mai, allora, prendersi dei 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.

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.

I contenuti della board

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 (p.e.: uptime di un servizio), organizzativa (p.e.: dipendenze sotto controllo), economica (p.e.: P&L, Profit and Loss) o personale (p.e.: soddisfazione del team).

Il livello di aspettativa sui risultati chiave 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/massime, 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.

Colmare il gap tra i vari livelli

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 lamenta 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: 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 eccome ed è configurata in come rappresentato in figura 6.

La ragione per cui le cadenze non hanno preso piede potrebbe essere dovuta proprio a questa rappresentazione, forse eccessivamente complessa. Per cominciare, è 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, ma potremmo comunque non ricavarne alcun beneficio, in mancanza di una visione di insieme e di meccanismi di feedback integrati.

Considerazioni sulle cadenze

Fatta la dovuta premessa che Kanban prevede un livello di autodisciplina superiore rispetto a Scrum, vediamo di fare un paio di considerazioni valide per questi incontri, in modalità pull.

• un determinato incontro potrebbe essere fatto solo quando serve e non necessariamente in date prestabilite;
• nel vostro contesto, alcune di queste riunioni potrebbero non essere svolte affatto;

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 anche gli OKR; si riesce pertanto a unire valutazioni di efficacia ed efficienza del lavoro a quelle di raggiungimento di obiettivi strategici.

Ma non finisce qui. C’è un ultimo strumento per evitare la troppo comune trappola per cui si finisce a 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. Uno dei vari motivi di questa “reticenza” è probabilmente che lo scaling di Scrum può essere presentato in maniera “meccanicistica” — più team, più gerarchia, più meeting, più organizzazione matriciale, e cos’ via — 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 già pronto all’uso, da cui possiamo copia-e-incollare un approccio: l’approccio dobbiamo necessariamente costruirlo in base al contesto. Questo sarebbe comunque vero e corretto anche per Scrum, ma lo è sicuramente e obbligatoriamente per Kanban.

Flight Levels

Klaus Leopold, da qualche anno, ha reso popolare un modello che si chiama Flight Levels, per descrivere in che modo potrebbe essere usato Kanban, in maniera integrata, su più livelli di una organizzazione: la metafora è quella delle diverse altezze di volo degli aeromobili.

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 si stabilisce come produrre e a chi farlo produrre;
• a livello operativo lo si produce

La granularità dei contenuti di questi livelli va ad aumentare progressivamente: da programma a progetto, da progetto a prodotto, da prodotto a funzionalità, da funzionalità a singola attività. In figura 7 ho sottolineato anche a quale livello potrebbero avere impatto le diverse cadenze Kanban, tenendo conto delle due considerazioni seguenti.

Anzitutto, questo è 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.

In secondo luogo, l’indicazione su chi partecipa ai meeting segue questo principio: partendo dal livello strategico, alle varie cadenze sono invitati rappresentanti del livello sottostante ma nessuno del livello sovrastante. Quindi, ad esempio, a 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 un meccanismo 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 aiuti a rinforzare i feedback loop, fondamentali per l’adozione di Kanban.

Integrare OKR, cadenze Kanban e Flight Levels

Giunti fino a qui abbiamo tre strumenti perfettamente integrabili:

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

Riporto di seguito alcuni esempi di come alcune delle cadenze Kanban possono interagire nella pratica sia con i 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 di figura 7, 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.

Comincia 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 possibili conseguenze delle evidenze empiriche emerse utilizzando Kanban e OKR in maniera diagnostica.

Analisi della domanda

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

• Punti di partenza delle attività: ossia chi sono i committenti, le azioni o gli eventi che fanno iniziare le attività nel nostro team? Iniziamo a pensare al nostro team come a un team di servizio: chi stiamo servendo e per quale motivo?
• 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 quante di queste fasi il team è autonomo, su quante ha dipendenze esterne? Emergono colli di bottiglia?
• 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?
• 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?

Quest’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!