Novembre 21, 2022 - di Redazione
Obiettivi Waterfall? Perché puntare al binomio OKR – Agile
L’articolo che segue è un deep dive di quello che abbiamo letto, ascoltato e approfondito sullo status quo che parecchie aziende vivono oggi. Si tratta, spesso, di grandi corporate che, imbrigliate nella legacy Waterfall, faticano a sfruttare le opportunità che gli OKR e l’Agile possono offrire se abbracciati “veramente”.
Molte aziende, infatti, non riescono a coniugare gli OKR con la metodologia Agile, oppure ritengono che gli OKR non siano necessari, avendo già adottato la filosofia Agile.
Una difficoltà che nasce proprio dall’aver frainteso la natura stessa degli OKR e dell’Agile. Se usati insieme, OKR e Agile, possono essere una combinazione super potente. I team diventano promotori stessi del cambiamento e nello stesso tempo contribuiscono positivamente agli obiettivi di business.
Per questo approfondimento ci siamo focalizzati sul contributo di Felipe Castro che, sul suo blog, ha scritto un articolo dal titolo OKR and Agile: Stop Waterfall, del quale riportiamo i tratti salienti.
Prima di entrare nel vivo, però, vi invitiamo a dare un’occhiata ai nostri articoli dedicati su Cosa sono gli OKR e perché sono importanti e sulla metodologia Agile e Lean.
Questo è quello di cui parleremo:
- La fabbrica di feature vs empowered team
- Stack tradizionale vs stack Delivery Agile
- Essere Full-Stack Agile: cosa significa
- I vantaggi nell’utilizzare gli OKR
La fabbrica di feature vs empowered team
Innanzitutto, è importante ricordare che l’Agile è stato creato per lo sviluppo del software in alternativa allo svilluppo Waterfall, e che è focalizzato sulla parte di deliverable (story e feature) e non sulla parte di creazione del valore (degli outcome di business).
In effetti non c’è una sola cerimonia in Agile dedicata alla misurazione dei risultati.
Anche il settimo principio dell’Agile Manifesto è fuorviante, quando dice:
“Working software is the primary measure of progress.”
Non tutto il working software genera del valore. Alcuni progetti falliscono e non tutte le feature vengono adottate.
Molte aziende si trovano quindi in uno stato che noi definiamo “di fabbrica delle funzionalità“.
Abbiamo dedicato un articolo intero a descrivere bene cosa significhi per noi essere una fabbrica di feature, dove i team non sono focalizzati sul rilasciare valore ma, come dice John Cutler, “Developers are just sitting in the factory, cranking out features, and sending them down the line”.
E dove le conseguenze di questo approccio si traducono in:
“The teams are just there to flesh out the details, code, and test. They have little understanding of the bigger context, and even less belief that these are in fact the right solutions.
[They have] little regard for whether or not the features actually solve the underlying business problems. They measure progress by output and not outcome”. — Marty Cagan
I team sono concentrati sui dettagli e il testing, e hanno una scarsa comprensione del contesto generale e una ancora più scarsa convinzione che le soluzioni alle quali stanno lavorando siano giuste ed efficaci. Misurano i progressi in base agli output e non agli outcome.
Dopo più di vent’anni dalla pubblicazione del manifesto, molte aziende abbracciano l’Agile per la sola delivery dello sviluppo del software, e in poche abbracciano la vera business Agility.
Stack tradizionale vs stack Delivery Agile
Se proviamo a pensare a una azienda, come a uno stack formato da cinque layer, questi sono: cultura, strategia, tattica, operation e obiettivi.
Gli obiettivi, rispecchiano la natura stessa dell’azienda, e sono trasversali a tutto.
Lo stack organizzativo, di un’azienda di stampo tradizionale, ha un setup di questo tipo:
- Cultura: di matrice top-down dove vige il comando e il controllo;
- Strategia: che viene pianificata annualmente → statica;
- Tattica: che punta su grandi scomesse e cicli di feedback molto lunghi;
- Operation: dove l’approccio waterfall è parte sia dello sviluppo che lato project management;
- Obiettivi: che seguono una logica Waterfall.
Spesso invece, quando le aziende adottano l’Agile, lo applicano alla sola delivery (Delivery Agile), e questo va ad “impattare” solamente il layer operation, rispetto alla struttura tradizionale, che diventa:
- Operation:
dove l’approccio waterfall è parte sia dello sviluppo che lato project management
dove lo sviluppo segue il metodo Agile e fa esperimenti; - Obiettivi: che seguono una logica Waterfall, a eccezione delle operation.
Non possiamo quindi dire che, in uno scenario di questo tipo, sia presente una vera cultura della sperimentazione, perché le legacy Waterfall (che è presente ovunque, tranne che sul layer Operation), entra in conflitto con la parte Agile.
Gli obiettivi Waterfall
In un contesto come quello descritto fino a ora, è facile che si usi un processo top-down per definire gli obiettivi, e che gli obiettivi abbiano una durata annuale.
Obiettivi Waterfall = pianificazione statica
Gli obiettivi annuali del top management si riversano a cascata su tutta l’organizzazione, e creano una tale immobilità, da essere in contrapposizione con l’essere Agile.
Credere in un approccio così statico, significa dare per scontato che il piano che si sta seguendo sarà cristallino, molto probabilmente infallibile, e che le condizioni del mercato non varieranno (e se varieranno, saranno gestibili durante la review di metà anno).
Gli obiettivi Waterfall sono basati su progetti
A complicare le cose, c’è il fatto che gli obiettivi waterfall, spesso sono mossi da progetti che vengono decisi dal management:
“The work of every workman is fully planned out by the management at least one day in advance.” – Frederick Taylor
Esattamente come è stato per il Tailorismo, l’approccio Agile in questo caso, esiste solo nella misura in cui bisogna deliverare progetti, ed è l’esecutivo a pianificare tutto.
Sposando questo tipo di approccio, dove l’Agile segue una pianificazione statica Waterfall, le aziende si espongono a rischi ben più alti e riducono la capacità di sapersi e potersi adattare al cambiamento.
Dalla pianificazione statica a quella dinamica
La pianificazione dinamica, al contrario di quella statica, è in grado di abbracciare il cambiamento. Lavora con brevi cicli iterativi e tiene conto di una possibile variazione delle condizioni del mercato. Ci permette d’imparare a ogni iterazione e di saper valutare meglio il problema, adattando continuamente il piano.
“The only way it’s all going to go according to plan is if you don’t learn anything”
Kent Beck
Se la necessità dei team è quella di lavorare testando le ipotesi con cicli iterativi, come si possono avere obiettivi statici definiti attraverso processi Waterfall? Significa che si sta usando Agile solo per la delivery, mentre si sta usando Waterfall per ogni altra cosa.
Essere Full-Stack Agile: cosa significa
Per raggiungere la business agility, le aziende dovrebbero essere Full-Stack Agile e ripensare tutti i layer dello stack come segue:
- Cultura:
di matrice top-down dove vige il comando e il controlloche si basa sulla creazione di un’autonomia allineata e condivisa → Da mercenari a missionari; - Strategia:
che viene pianificata annualmente → staticache è iterativa e si concentra sul validare le ipotesi; - Tattica:
che punta su grandi scomesse e cicli di feedback molto lunghidove eseguono esperimenti safe-to-fail con cicli di feedback brevi; - Operation: che usano il metodo Agile;
- Obiettivi:
che seguono una logica Waterfallche utilizzano gli OKR.
Ma quali sono i passi concreti da compiere perché si agisca in modo capillare, sui sistemi e sui processi?
La risposta è: provare a usare gli OKR.
I vantaggi nell’utilizzare gli OKR
Su Product Heroes abbiamo parlato degli OKR in una decina di articoli, quindi vorremmo evitare di soffermarci su concetti già affrontati, ma ci focalizziamo sulla principale differenza rispetto ad altri metodi:
- Sono stabiliti e valutati con frequenza in genere trimestrale;
- Invece che essere distribuiti a cascata, sono bidirezionali.
Questo significa che sono i team che creano i loro OKR in linea con gli obiettivi aziendali, e che poi li discutono con i rispettivi manager.
Questo approccio offre a i team un ambiente molto più motivante. Si sentono tutti responsabili degli obiettivi che hanno stabilito (obiettivi che in genere monitorano una volta alla settimana).
Se usati correttamente, gli OKR possono aiutare le aziende a diventare Full-Stack Agile.
Creare dei team value-driven
La chiave per diventare Full-Stack Agile è concentrarsi sul valore, dove la vera sfida sono le attività pianificate dal management e il flusso della delivery, ovvero la fabbrica di funzionalità.
Questa “ossessione” per la delivery è radicata. Inizia con l’uso del “working software come misura del progresso” (settimo principio agile) e continua ancora oggi con Scrum e “l’arte di fare il doppio del lavoro in metà tempo”, come recita il titolo del libro di Jeff Sutherland.
Ma se nella Kanban Board aggiungessimo una colonna, come dice John Cutler? Ovvero quella legata agli outcome e a quello che abbiamo imparato?
Nonostante il Manifesto sia fuorviante, uno dei suoi autori, Martin Fowler, ha scritto a proposito degli outcome:
“The key to [defeating] waterfall is to realize that agilists value Outcomes over Features. The feature list is a valuable tool, but it’s a means not an end. What really matters is the overall outcome, which I think of as value to the customers | La chiave per [sconfiggere] waterfall è capire che gli agilisti danno più valore agli outcome che alle feature. L’elenco delle feature è uno strumento prezioso, ma è un mezzo, non un fine. Ciò che conta davvero è il risultato complessivo, che io considero un valore per i customer“.
Cosa spinge effettivamente i team a lavorare? Lo ha descritto benissimo Henrik Kniberg, un Agile & Lean coach.
- La prima opzione (barrata) rappresenta la fabbrica di funzionalità. Il presupposto è che il team non è in grado di decidere cosa costruire. Lavorano su qualcosa perché qualcuno ha detto loro di farlo (“Sam”). Segue il principio Taylorista della separazione tra pianificazione e realizzazione. È demotivante e non promuove l’innovazione.
- Il secondo approccio (barrato) è l’estremo opposto, in cui i team lavorano su qualcosa solo perché “ne hanno voglia”.
- La terza opzione, è il team orientato alla creazione del valore e che ragiona su come può avere un impatto. Ha lo scopo chiaro e una visione completa del lavoro e della strategia.
Usare gli OKR nel modo giusto
Come qualsiasi altro strumento, gli OKR possono essere usati “male” e diventare una to-do-list. Ma se volete concentrarvi sul valore, gli obiettivi dovranno riflettere questa scelta e avere dei Key Results (KR) basati sul valore generato per i vostri customer e per la vostra azienda.
Quando si utilizza Agile con i KR basati sulle attività, si crea attrito. I team hanno già delle roadmap da seguire, quindi perché avrebbero bisogno degli OKR?
“Using Value-based OKRs can be transformative. It can be the missing link between Agile and Lean. In can bridge the gap between product and engineering. | L’uso di OKR basati sul valore può essere rivoluzionario. Può essere l’anello mancante tra Agile e Lean. Può colmare il divario tra prodotto e engineering”.
Felipe Castro
Prendere decisioni basate sui dati e non sulle opinioni
Nello stack Delivery Agile, non sono i dati a guidare l’Agile, ma piuttosto l’HiPPO (Highest Paid Person’s Opinion), ovvero l’opinione della persona più pagata. Come ci consiglia Felipe, il concetto è brillantemente illustrato nel libro How Google Works.
Il modello (di matrice Waterfall), si basa sul fatto che le gli stakeholder dicono ai team ciò che deve essere fatto. Invece di raccogliere dati e misurare ciò che funziona, si chiede agli HiPPO cosa costruire, perché loro sanno cosa è di valore per l’utente finale.
Sperimentare: adottare uno sviluppo guidato dalle ipotesi
Il fatto è che i team non hanno bisogno di qualcuno che sia la voce del customer. Possono intervistare e misurare i comportamenti degli utenti in autonomia.
Gli OKR possono sostituire l’HIPPO con esperimenti che consentono al team d’imparare e iterare, e di adottare uno sviluppo guidato dalle ipotesi, come descritto da Barry O’Reilly:
We believe this capability.
Will result in this outcome.
We will have confidence to proceed when we see a measurable signal.
In questo modello, non si tratta più di presentare dei deliverable, ma di discutere le metriche e le ipotesi più importanti per migliorarle costantemente.
Promuovere l’autonomia dei team
La mentalità di comando e controllo persiste nelle aziende con uno stack Delivery Agile. I team lavorano su qualcosa “perché l’ha detto Sam” e si fermeranno “quando Sam sarà d’accordo”.
Ma quanti si possono davvero permettere di lavorare così?
La verità è che tutti hanno bisogno del pieno contributo del proprio team. Quindi, i team devono comprendere i problemi di business e avere voce in capitolo su cosa costruire. Come ha scritto Marty Cagan, “If you’re just using your engineers to code, you’re only getting about half their value.”.
Per rendere i team autonomi, è necessario dare loro la libertà di decidere come raggiungere gli outcome desiderati per costruire prodotti migliori.
Lo scopo del team deve quindi cambiare:
- Lo scopo della Feature Factory DIVENTA –> Lo scopo di un team orientato al valore
- La delivery di quello che vogliono gli stakeholder DIVENTA –> Raggiungere gli obiettivi di valore concordati con gli OKR.
Conclusioni
Sia che si lavori in una startup, o che si lavori in una grossa corporate, il binomio OKR Agile è un ingrediente che può aiutare i team a dare il massimo e a raggiungere obiettivi davvero sfidanti.
Laddove l’approccio Waterfall è fortemente permeato nei processi e negli “ingranaggi”, la strada è un po’ più tortuosa, ma percorribile, se si è disposti a ribaltare tutto.
A guidare sarà sempre e solo un unico obiettivo, ovvero il raggiungimento del miglior prodotto possibile, nel minor tempo possibile, grazie alla partecipazione responsabile di tutti i team nel processo di creazione del valore.
E voi in quale stack vi trovate? La vostra azienda ha già adottato gli OKR e avete degli spunti da condividere? Raccontatecelo nei commenti.
Se l’articolo ti è piaciuto e vuoi rimanere aggiornato sui prossimi contenuti, iscriviti alla nostra Newsletter 📩
