Nella comunità globale di coaching e formazione Agile ci chiediamo se dobbiamo concentrarci sui risultati o sull'efficienza dei team. Allo stesso tempo, ci poniamo anche la domanda sulla differenza tra l'Agilità di Business e la Agilità di team
Sia l'Agilità di Business che quella di team si riferiscono all'approccio di adattamento rapido, continuo e ciclico, e all'innovazione imprenditoriale diretta a guadagnare e mantenere un vantaggio competitivo. La differenza principale è che sono su diversi livelli.
Oggi, la leadership è interessata ad un team Agile solo se può rendere l'azienda nel suo complesso più Agile così da aiutarla a raggiungere gli obiettivi di business. Quindi l'Agilità di Business richiede un focus sia sui risultati che sull'efficienza.
Il membro medio del team è scettico sull'interesse del management per l'Agilità di Business e forse ancora più scettico sugli investitori a livello di consiglio di amministrazione. Tuttavia, il senior management e gli investitori hanno una chiara comprensione dell'Agilità di Business, ma comprensibilmente dalla loro prospettiva. Questo spesso si traduce in queste o simili domande:
Quindi le cinque componenti dell'Agilità di Business sono:
L'Agilità di Business si misura ad un livello macro. Per esempio, OpenView Ventures Partners fa parte di un gruppo che vuole investire 525 milioni di dollari in aziende Agili nel 2021. Hanno dati concreti sul valore effettivo di ogni azienda in cui investono e quel numero viene aggiornato ogni mese. Ricevono aggiornamenti quotidiani sulle aziende quotate in borsa nei loro portafogli. Sanno che queste valutazioni sono guidate dall'Agilità di Business.
Nel 2018, Takao Sakai ha pubblicato il suo libro su "The Secret Behind the Success of Toyota" e mi ha inviato una nota dicendo che i formatori Scrum stavano insegnando Scrum in modo sbagliato. Lo avevamo già sentito nel 2016 dai vertici di KDDI in Toyota che ci hanno contattato per creare una joint venture chiamata ScrumInc Japan per insegnare il "vero" Scrum, lo Scrum dei nonni Takeuchi e Nonaka.
Avevamo già capito con i giapponesi che la Guida Scrum non era sufficiente per formare gli Scrum Master alla Toyota. All'epoca, KDDI era al 20% di proprietà di Toyota e aveva contratti di formazione Scrum per Toyota R&D e Toyota IT. Abbiamo deciso con loro che le basi Lean erano essenziali per le prestazioni di Scrum, i modelli iper-produttivi erano obbligatori per i team ad alte prestazioni, ed era essenziale scalare senza perdere le prestazioni a livello di team.
Takao Sakai ha portato un'ulteriore prospettiva per migliorare radicalmente la formazione Scrum facendo notare che solo il 5% del successo di Toyota era basato sulla produzione snella (oggi tutti devono avere una produzione snella), e il 95% del successo era basato sugli ingegneri capo di Toyota dall'altra parte dell'autostrada a Toyota City lontano dagli stabilimenti di assemblaggio. Sakai ha detto che i Chief Engineers erano l'equivalente dei Product Owner in Scrum e che hanno consegnato la maggior parte dei profitti di Toyota progettando prodotti ad alto valore e basso costo. L'alto valore era importante, ma una grande quota di mercato era raggiungibile solo con prodotti a basso costo.
La principale critica di Sakai alla formazione Scrum è che non stavamo concentrando il 95% della nostra formazione sul Product Owner che fornisce un valore superiore e crea un backlog per consegnare il massimo valore a basso costo. Quindi un modo migliore di dire "consegnare il doppio del lavoro in metà tempo" sarebbe "consegnare il doppio del valore a metà del costo".
Dal 2006 a OpenView Venture Partners abbiamo implementato Scrum ovunque nel gruppo di venture e, per quanto possibile, in tutte le aziende in cui abbiamo investito. I venture capitalist sono molto aggressivi e hanno una bassa tolleranza per gli impedimenti. Abbiamo imparato rapidamente che gli impedimenti sono come le zanzare. Ne colpisci una e ne tornano 25, a meno che tu non faccia un'analisi delle cause alla radice. Un documento pubblicato è disponibile su questo argomento nella IEEE Digital Library - Take No Prisoners.
Da una prospettiva di business, abbiamo scoperto che l'efficienza del team (consegnare rapidamente a basso costo) era essenziale e facilmente raggiungibile, ma consegnare un valore più alto al giusto segmento di mercato richiedeva l'80% dei nostri sforzi concentrati principalmente sulla funzione di Product Owner. I nostri investitori avevano già capito cosa diceva Sakai nel 2006.
Non si tratta di efficienza contro risultati, ma di entrambi. La nostra formazione deve concentrarsi maggiormente sulla funzione di Product Owner. I Product Owner di successo devono creare un backlog che generi un valore più alto e che fornisca quel valore ad un costo inferiore. Il costo inferiore deriva da due fattori (1) il design del prodotto e (2) l'impatto del Product Owner sulla performance del team.
I dati della ricerca mostrano che i Product Owner possono facilmente raddoppiare le performance del team con un backlog migliore e consegnare il prodotto alla metà del costo. Abbiamo anche scoperto che i grandi Product Owner ottengono un flusso di entrate dai loro prodotti e gli viene consegnata un'alta quota di mercato. I team devono permettere questo attraverso un'alta efficienza e una qualità eccezionale, entrambe direttamente influenzate dal backlog del Product Owner, dai test di accettazione e dall'input collaborativo sulla Definition of Done. Una corretta implementazione genererà un'alta Efficienza di Processo, la metrica lean fondamentale che guida Toyota.
Per questo motivo, nella Guida Scrum@Scale, chiariamo che la missione è di fornire il doppio del valore a metà del costo. Sia l'efficienza che i risultati sono essenziali per le aziende di successo.
Tradotto e adattato da Scrum Inc.: https://www.scruminc.com/business-agility-intersection-outcomes-efficiency/
Scritto da Jeff Sutherland | 22 settembre 2021 | Blog
Vuoi conoscere Scrum? Scegli uno dei componenti del Framework dalla lista e scopri come funziona il framework Agile più diffuso al mondo.