Misurare l’Operosità vs Misurare i Risultati
Galen Low è affiancato da Fred Fowler—uno Scrum master certificato di Livello 3 che ha pubblicato diversi libri sulla metodologia Scrum—per insegnarci come smettere di misurare l’operosità e iniziare a misurare i risultati.
Punti salienti dell’intervista
- Fred ha iniziato come programmatore nel 1980. [3:00]
- Abbiamo questa tendenza a misurare l’operosità perché è semplice da misurare. Tutto ciò che serve è un orologio per misurare quanto siano impegnate le persone. Tutto quello che ti serve per capire se le persone stanno rispettando una serie di scadenze è un calendario. È la base della retribuzione. [9:00]
Il tempo di una persona è prezioso per lei, ma ciò che è prezioso per un datore di lavoro è quello che viene fatto con quel tempo.
Fred Fowler
- All’interno di Scrum, devi sempre creare qualcosa che sia fatto, finito, completo e pronto per il cliente alla fine di ogni sprint. [12:41]
- Si misura il valore in base a quanto il cliente è disposto a pagare. [13:25]
- Scrum sottolinea che bisogna prendere decisioni basate su ciò che si misura, non su ipotesi, non su opinioni, ma su ciò che si misura. E la cosa più importante da misurare è il valore. [14:16]
- Nella struttura di Scrum, la misurazione del valore è responsabilità di una sola persona. Scrum suddivide le responsabilità in tre ruoli: il product owner, gli sviluppatori e lo scrum master. [15:05]
- Il product owner è colui che è responsabile del valore. Non si può massimizzare qualcosa se non la si può misurare, perché se non si può misurare quello che si sta cercando di massimizzare, non si ha idea se quello che si fa lo sta migliorando o peggiorando. [15:24]
- Esistono quattro modi per aumentare il valore. Il metodo più comune è aumentare le entrate. Un altro modo è ridurre i costi di qualcosa. Il terzo modo è ridurre i rischi e il quarto modo è aumentare le opportunità. [15:49]
Non puoi misurare il valore di qualcosa che non esiste.
Fred Fowler
- Il product owner non è un ruolo tecnico. Il product owner è un ruolo business. Gli sviluppatori sono i tecnici. Scrum è una negoziazione tra persone che hanno responsabilità in queste due aree diverse. [22:07]
- Ci sono due aspetti della retribuzione: 1) far entrare le persone in azienda; 2) come compensare il valore che le persone producono. [28:21]
- Una delle grandi qualità della struttura Scrum è che allinea correttamente gli incentivi di tutti e mette le decisioni nelle mani di chi è in grado di prenderle e di risponderne. [30:41]
- Il product owner è fondamentalmente un investitore. [31:01]
- Permettendo agli sviluppatori di avere l’autorità di prendere tutte le decisioni in autonomia, non hanno nessuno a cui dare la colpa se non loro stessi. [31:30]
Scrum dice che i team di sviluppo devono essere autonomi e cross-funzionali. Cross-funzionale significa che devono essere in grado di creare il prodotto in autonomia.
Fred Fowler
- Il team di sviluppo dovrebbe essere in grado di organizzarsi e gestirsi da solo. [33:10]
- Un product owner deve essere capace di assumersi la responsabilità di investire centinaia di migliaia, se non milioni di dollari, nel tentativo di creare prodotti di valore. Gli sviluppatori devono essere in grado di creare il prodotto lavorando come una squadra per essere responsabili di ciò, ed è per questo che devono avere l’autorità necessaria. [34:09]
Il compito dello Scrum master è fare in modo che tutti lavorino insieme come una squadra e comprendano le proprie responsabilità.
Fred Fowler
- Un buon modo per aiutare gli sviluppatori è introdurre uno schema di retribuzione che li premi per il valore reale che creano. [35:03]
È molto importante che il prodotto su cui lavora un product owner abbia un valore misurabile. Se stai lavorando su qualcosa ma non puoi misurare il suo valore, non è un prodotto.
Fred Fowler
- Si misura il prodotto vendendolo. Si misura il prodotto facendo sì che qualcuno sia disposto a pagare per esso. Perciò, se non puoi vendere qualcosa e non puoi far sì che qualcuno sia disposto a pagarlo, non hai un prodotto. [39:18]
Scrum riguarda proprio il tentativo di creare prodotti senza seguire una ricetta predefinita.
Fred Fowler
- Fred ha citato un libro chiamato Agile Product Management with Scrum di Roman Pichler. [40:40]
- Devi essere in grado di avere persone qualificate che prendano decisioni di cui sono responsabili, sia dal punto di vista aziendale sia da quello dello sviluppo del prodotto. E gli sviluppatori devono essere capaci di creare l’oggetto e autogestirsi. [41:52]
Non importa quale framework tu stia utilizzando, assicurati di concentrarti sulla misurazione del valore invece che sull’attività, misura i risultati invece che le produzioni.
Fred Fowler
- Fred gestisce un gruppo meetup dal 2015, tutto incentrato su Scrum. Lo chiamano il meetup Advanced Scrum Case Studies. Una volta ogni due settimane si incontrano online e Fred pubblica un caso in anticipo, che solitamente offre o pone qualche problema in termini di gestione di progetto o gestione Scrum. [43:08]
- Fred ha raccolto note su circa 60 casi diversi dal loro meetup di case study e li ha documentati tutti in un volume intitolato Advanced Scrum Case Studies. [44:03]
Conosci il nostro ospite
Fred è una delle sole 50 persone negli Stati Uniti a detenere la prestigiosa certificazione Professional Scrum Master Livello III e sviluppa software nella Silicon Valley da più di 35 anni.
Nel 2013 ha lasciato il suo incarico di VP e CIO in una delle prime 150 aziende della Silicon Valley per dedicare il suo tempo all’insegnamento dello Scrum.
Ha fatto risparmiare milioni di dollari alle aziende lavorando con start-up e compagnie Fortune 500 tra cui Oracle, Apple, Uber e Walgreens.
Fred è stato eletto sindaco durante l’attacco terroristico dell’11 settembre aiutando la comunità a superare le conseguenze e ricopre il ruolo di presidente per diverse organizzazioni non profit.
È autore di due libri innovativi che spiegano alle aziende perché l’applicazione corretta dello Scrum può portare a risultati trasformativi.
Non ha importanza se le persone offshore siano occupate o meno. Questo non è importante. Ciò che conta è quello che effettivamente consegnano, il valore di ciò che consegnano. È questo che dovresti misurare.
Fred Fowler
Risorse da questo episodio:
- Unisciti alla Community dei Digital Project Manager
- Iscriviti alla newsletter per ricevere i nostri ultimi articoli e podcast
- Segui Fred su LinkedIn
- Visita il sito web di Fred
Articoli e podcast correlati:
Leggi la Trascrizione:
Stiamo testando la trascrizione dei nostri podcast tramite un programma software. Perdonateci eventuali errori di battitura, poiché il bot non è sempre preciso al 100%.
Galen Low: Quiz a sorpresa: sei a metà del tuo progetto e tutte le tue metriche sembrano ottime. Il tuo fornitore ha lavorato il numero di ore concordato e la velocità e l'utilizzo del tuo team sono esattamente come pianificato.
Ma nonostante il tuo progetto sia in salute, il prodotto continua a non centrare l'obiettivo nei focus group e nei test con gli utenti. La tecnologia sulla quale il tuo sponsor esecutivo insisteva sta rapidamente diventando obsoleta, rendendo difficile apportare modifiche. E il morale del tuo team è basso: quando chiedi soluzioni, si limitano a scrollare le spalle dicendo di aver fatto ciò che gli era stato richiesto entro il tempo assegnato.
Quindi, come può il tuo progetto essere "in salute" anche se il risultato non produce il valore previsto?
Se hai notato che le metriche del tuo progetto misurano più l'operosità che il valore reale, continua ad ascoltare. Esamineremo le strategie pratiche su come i team di progetto possono misurare il valore, esplorando idee per spostare l'incentivo dalle ore lavorate al valore creato.
Ciao a tutti, grazie per essere qui. Mi chiamo Galen Low e sono con il Digital Project Manager. Siamo una comunità di professionisti digitali con la missione di aiutarci a vicenda a sviluppare competenze, acquisire fiducia e connetterci, così da poter amplificare il valore della gestione progetti nel mondo digitale. Se vuoi scoprire di più, vai su thedigitalprojectmanager.com.
Bene, oggi parliamo della differenza tra misurare la salute e il progresso di un progetto rispetto a misurare il successo del progetto stesso. È sufficiente monitorare la velocità del team e il controllo dei costi? Oppure è nostra responsabilità, come leader di progetto, misurare anche gli esiti e l'impatto?
Con me oggi c'è Fred Fowler—scrum master certificato di Livello 3, autore di vari libri sulla metodologia Scrum, organizzatore del gruppo meetup Silicon Valley Professional Scrum con circa 2.000 membri, guida una community simile a Shanghai, Cina, e ha organizzato la prima conferenza Silicon Valley Scrummit. Insomma, uno che di Scrum ne sa davvero.
Benvenuto Fred!
Fred Fowler: Ciao! Grazie per avermi invitato.
Galen Low: È un piacere averti qui.
Fred Fowler: Mi presento come un tipo "scrummy". Anche se qualcuno dice che sono "scrumcious".
Galen Low: Beh, meglio che se dicessi Fred "scrum-of-the-earth"!
Fred Fowler: Ci sono tanti modi per giocare con la parola scrum. Potresti dire scrumbag, e così via. Ma dai, vai pure avanti.
Galen Low: Fantastico! Hai un background molto interessante, e credo che darà ai nostri ascoltatori un bel contesto su come vedi le metriche di progetto. Se ho capito bene, hai iniziato come programmatore, poi sei passato alla politica diventando sindaco, poi CIO, per arrivare a utilizzare la rara certificazione Scrum Master Livello 3 per aiutare gli altri.
Vorrei che ci raccontassi di più del tuo percorso e di come le tue esperienze hanno influenzato il tuo modo di vedere le cose oggi.
Fred Fowler: Direi che la mia carriera è stata come una pallina da flipper.
Ho iniziato programmatore nel 1980. Sai, tempi antichi, lavorando su una macchina così grande e pesante che servivano attrezzature speciali per spostarla ed era meno potente di un normale telefono oggi. Ma gestivamo una divisione di una società di semiconduttori e lì ho imparato le mie abilità.
Poi mi sono spostato, perché era la Silicon Valley degli albori—volatilità a volontà. Nei primi otto anni di carriera ho lavorato per cinque aziende diverse: incredibile, una volatilità continua. Arrivato alla fine ho capito che mi serviva sicurezza, così ho lavorato in proprio.
Sono diventato consulente e per i successivi 10 anni ho lavorato per 60 aziende diverse, sempre applicando la tecnologia per risolvere problemi di business, che poi è il fulcro della questione. Poi mi hanno fatto un'offerta che non potevo rifiutare: sono finito a dirigere le loro operazioni IT, diventato CIO, e ho applicato molte tecniche che poi ho scoperto essere metodi scrum, anche se allora non lo sapevo. Dare potere alle persone per risolvere i problemi, giustificare il lavoro in base al ritorno degli investimenti.
Sai, in quei tempi ho gestito tanti progetti che hanno formato la mia visione su come organizzare le iniziative. Cose di cui vado orgoglioso. L’azienda aveva speso parecchio per costruire un sito e-commerce affidandosi a una grande società informatica. Avevano speso un quarto di milione di dollari per una soluzione piuttosto scadente.
Sono intervenuto, ho visto la possibilità di migliorare e ho organizzato un progetto suddividendo il lavoro tra Stati Uniti e Cina (lì il front-end, qui il back-end, entrambi interfacciati). Risultato: con $14.000, in sei mesi il sito faceva il 40% del business, sostituendo il vecchio sistema da $250.000.
Galen Low: Ecco, squadre snelle, dati in contratto, e via di corsa.
Fred Fowler: Esatto. E la cosa chiave era capire COSA era importante misurare.
Quando si parla di team offshore, tutti vogliono strumenti per sapere cosa fanno, misurare quanto lavorano, essere certi che siano sempre occupati.
Ma indovina? Non importa! Non fa alcuna differenza se chi lavora offshore è impegnato o no. L’importante è COSA consegnano, il valore di ciò che producono. Dimentica di cronometrare le persone. Sai... se hai un team di 200 persone che lavorano 8-10 ore al giorno per due anni, rispetto a un team di 10 persone per un anno… chi produrrà più valore?
La storia di healthcare.gov: 200 persone per due anni = disastro; 10 persone hanno riscritto da capo in un anno e creato valore vero.
Galen Low: Entriamo nel punto: perché misuriamo l’operosità? Vengo da agenzie e consulenze dove tutto sono ore fatturabili, utilizzo risorse, bug risolti, task completati.
Perché tendiamo a misurare l'operosità?
Fred Fowler: Semplice: è facile da misurare! Basta un orologio per vedere chi è impegnato, un calendario per le scadenze. E, come dici tu, è legato alla retribuzione. Le ore fatturabili: il grande inganno! Il tempo è prezioso per chi lo offre, ma quello che conta per te è COSA viene fatto con quel tempo.
Molto meglio trovare un modo per misurare i RISULTATI di quel tempo.
Quando parlo alle aziende, dico sempre: bisogna capire il valore di ciò che vuoi ottenere, scomporlo in elementi misurabili e valutare i progressi in base al valore creato. Anche nel "lean" si parla di prodotto minimo realizzabile: basta mettere qualcosa nelle mani del cliente per capire il valore reale, e quindi giudicare se la spesa è giustificata.
Se sviluppi un’app che costa mezzo milione, è un buon investimento? Se vendi 3 milioni di copie a due dollari l’una, sì. Se ne vendi 25.000 a $2, hai creato solo 50.000 dollari di valore. Stesso sforzo, valore diverso: conta il valore del risultato.
Galen Low: Il ragionamento del MVP (minimo prodotto realizzabile) spesso non viene capito. A volte misuriamo l’operosità perché ci manca la fiducia: vedendoli al lavoro, almeno sappiamo che "fanno qualcosa". Ma non stiamo misurando valore.
C’è chi dice che le ore fatturabili siano un male necessario. Tu come la pensi: è una pratica necessaria o dobbiamo andare oltre?
Fred Fowler: In qualche modo è un male necessario. Ma bisogna comunque confrontare sempre il costo con il valore dei risultati prodotti. Lo Scrum ti impone che a fine sprint hai qualcosa di finito, pronto da consegnare.
Perché? Perché solo allora ha valore, quando è pronto e può essere consegnato al cliente. E infatti, il valore si misura da quanto un cliente è disposto a pagare. Ogni due settimane produci qualcosa che puoi misurare e confrontare con l'investimento fatto.
Devi suddividere il lavoro in pezzi dal valore misurabile. Lo Scrum insiste: devi prendere decisioni su cose che puoi misurare. La più importante? Il valore.
Galen Low: Puoi spiegare come si misura il valore? Se misuriamo solo l’operosità, quali sono le metriche giuste per un team scrum?
Chi valuta quanto vale davvero ciò che si produce sprint dopo sprint? Come si tiene traccia di questo?
Fred Fowler: In Scrum solo una persona ha la responsabilità di misurare il valore: il Product Owner. Scrum divide i ruoli in tre: Product Owner, Developers e Scrum Master. Compito del Product Owner è massimizzare il valore del lavoro del team. E non puoi massimizzare ciò che non sai misurare.
Ci sono quattro approcci per aumentare il valore: La più ovvia è il fatturato: vendi 3 milioni di app a 2 dollari = valore misurato. Un altro modo: riduzione dei costi; se tagli 50 centesimi su un milione di prodotti, hai risparmiato mezzo milione. Il terzo è ridurre il rischio: nel mio caso da CIO, avevamo un data center connesso tramite fibra. Ogni anno un escavatore rompeva il cavo, e andavamo giù per un giorno: perdita da un milione di dollari l’anno. Investire 50.000 dollari per spostare il data center e ridurre il rischio è un affare. Il quarto modo è aumentare le opportunità: se vincere un’asta su sei diventa due su sei con una miglioria, puoi calcolare il valore aggiunto.
Galen Low: Il Product Owner misura e aggrega tutto questo valore, come lo trasmette al team?
Fred Fowler: Il Product Owner misura le quattro leve del valore e decide su cosa il team deve lavorare. Ma non puoi misurare il valore di qualcosa che ancora non esiste. Il Product Owner fa un'ipotesi su cosa sarà di valore e indirizza il team che poi crea tale valore. Dopo, si misura se il risultato risponde alle attese. Solo così puoi verificare il ritorno dell’investimento.
Il team dovrebbe preoccuparsi di questo, perché nessuno paga $50.000 di sprint per avere $25.000 di valore. Product Owner e team sono tutti nella stessa barca.
Galen Low: È una frase importante: 80 ore di lavoro non equivalgono a 80 ore di valore.
Fred Fowler: Esatto! Quando i developer lo capiscono, si rendono conto che sono parte integrante del processo di creazione del valore.
Il Product Owner si occupa di business: indica cosa è desiderabile. I developer dicono cosa è possibile. Insieme, negoziano su ciò che è pratico. Scrum è negoziazione tra responsabilità diverse, verso la creazione del massimo valore praticabile.
Galen Low: Partnership: molti la vedono come servitù, ma in realtà il vero Scrum è collaborazione e negoziazione.
Fred Fowler: Esattamente. Anche i developer possono influenzare i costi con soluzioni astute, per es. "Accedi con Google" invece che creare da zero un sistema di login.
Non bisogna solo eseguire, ma proporre soluzioni efficaci. Più il team è coinvolto, migliore sarà il valore prodotto.
Galen Low: Sono colpevole di aver misurato velocità e operosità più che valore. Che tipo di conversazione avviene nei team Scrum su questi temi? Il Product Owner comunica il valore ottenuto?
Fred Fowler: Tutto ruota attorno alla retribuzione. Se si paga tutti a ore, l'incentivo è fare le cose complicate. Questo danneggia tanti progetti: aziende che spendono milioni in attività senza valore concreto.
La soluzione, secondo me, sta in due aspetti retributivi: uno è la base, il salario di mercato che ti fa entrare nel team. L’altro è il premio sul valore: se il team crea $100.000 di valore, magari il 20% viene distribuito al team. Lascia che siano loro a dividerlo: nessuno meglio del team sa chi ha contribuito di più.
Galen Low: È simile a un modello di profit sharing.
Fred Fowler: Esatto. Ha senso perché allinea tutti gli incentivi verso la creazione di valore.
Il Product Owner è come un investitore: decide come investire il tempo del team e risponde dei risultati. Il team ha totale autonomia su come realizzare. Così, ognuno è davvero responsabile delle proprie decisioni.
Galen Low: L’industria non ha favorito l’accountability: spesso ci si limita a fare ciò che viene detto dal capo.
Fred Fowler: Questo è controproducente. Chi decide non apprende dagli errori, e se il team non è cross-funzionale, si scarica la colpa sugli altri. Il team deve poter consegnare da solo e organizzarsi autonomamente.
Un vecchio detto dice: "Nulla è impossibile se non devi farlo tu stesso".
Galen Low: È un equilibrio tra empowerment, accountability e CAPACITÀ.
Fred Fowler: Esatto. Chi ha il potere deve anche essere capace. Product Owner capaci di investire risorse, developer capaci di costruire e collaborare. Il ruolo più difficile è quello dello Scrum Master, che deve insegnare al team a gestirsi e spingerli verso un modello in cui sono ricompensati per il valore davvero creato.
Galen Low: Mi piace: misurare e premiare il valore.
Fred Fowler: Esattamente. E un ultimo punto: se non puoi misurare il valore di ciò su cui lavori, non è un prodotto. Non puoi prendere decisioni razionali.
Ad esempio, in un'azienda con una web app finanziaria, c'erano tre Product Owner (front-end, API, back-end), ma nessuno poteva misurare il vero valore. Serviva un unico Product Owner sul valore dell'intera filiera, per eliminare conflitti e ottimizzare lo sviluppo.
Galen Low: È incredibile come a volte la politica freni il valore.
Fred Fowler: Sì, spesso è così. Se non si può misurare il valore delle decisioni, si procede a caso. Solo la visione completa della catena del valore consente di fare scelte sensate.
Galen Low: Approccio prodotto: tagli verticali, non orizzontali. Alcuni pensano di non poter adottare Scrum perchè non producono incrementi, ma basta cambiare mentalità, orientandosi all'intero prodotto. Molto interessante!
Fred Fowler: L’ho confermato anche con Jeff Sutherland, uno dei creatori di Scrum. Un prodotto è qualcosa che si può produrre e il cui valore è misurabile oggettivamente, senza opinioni. Il valore si prova vendendo o facendo pagare l'utente. Se non riesci a venderlo, non è un prodotto, ma una parte di qualcos'altro che costituisce il vero prodotto.
Galen Low: Un’ultima domanda: quanto queste pratiche funzionano oltre Scrum? Cosa consigli a chi usa altri metodi?
Fred Fowler: Altri metodologie? Certo che sì.
Scrum si basa su principi più profondi. Anche Agile si basa su fondamenta comuni. La differenza col modello a cascata (Waterfall) PMI è che quest’ultimo si basa sulla pianificazione a priori, che però perde efficacia perché tutto cambia in corso d’opera.
Roman Pichler (autore di Agile Product Management with Scrum) racconta di aver rinnovato un prodotto medico con approccio Waterfall: consegnò puntuale, sotto budget, ma il prodotto era già obsoleto.
Non bisogna seguire ricette fisse. Bisogna avere persone qualificate e responsabili che prendano decisioni—sia lato business sia lato sviluppo—più la capacità di fornire incrementi misurabili. Non importa la metodologia, l’importante è misurare valore, non solo attività. Se misuri i risultati e impari da essi, sei sulla strada giusta.
Galen Low: Questo è il succo. Bellissimo!
Fred, parlavi del tuo gruppo Meetup e dei libri che hai scritto. Dove trovano info chi ci ascolta?
Fred Fowler: Gestisco dal 2015 un gruppo meetup chiamato Advanced Scrum Case Studies.
Ogni due settimane ci ritroviamo online e propongo un caso di studio, di solito una sfida legata a Scrum: offshore team, misura del valore, ecc. Se ti interessa, cerca Silicon Valley Professional Scrum su Meetup per trovare l’Advanced Scrum Case Studies meetup. Siete i benvenuti. Da qui sono nati molti casi interessanti, raccolti in un volume intitolato Advanced Scrum Case Studies, disponibile su Amazon o sul mio sito: www.siliconvalleyscrum.com. Ci sono 15 casi e sto lavorando al Volume 2.
Galen Low: Non sapevo che il libro nascesse dalle discussioni del meetup—molto bello!
Fred, grazie di essere stato con noi. Ho apprezzato storie e idee, specialmente sul tema retribuzione—magari ci torneremo! Spero che i nostri ascoltatori abbiano colto tanti spunti di valore.
Fred Fowler: Grazie a voi, è stato un piacere.
Galen Low: E voi cosa ne pensate?
È davvero possibile orientare un team di progetto verso la creazione di valore invece che su ore lavorate o storie utente completate? O siamo troppo dipendenti dal modello “denaro per ore lavorate”?
Raccontaci la tua esperienza nei commenti: quali sono state le metriche giuste per i tuoi progetti? E quali cambiamenti o risultati hai osservato grazie ai dati sul tuo progetto?
Se vuoi migliorare come project leader strategico, unisciti alla nostra community!
Vai su thedigitalprojectmanager.com/membership per accedere a una community di supporto dove condividiamo conoscenza, risolviamo sfide complesse e insieme costruiamo il futuro della nostra disciplina.
Da template robusti e sessioni di formazione mensili che ti fanno risparmiare tempo ed energie, al supporto tra pari tramite Slack, eventi live e mastermind group: essere nostro membro vuol dire avere più di mille persone accanto a te mentre navighi la carriera nel project management digitale.
E se ti è piaciuto l’episodio, iscriviti e resta aggiornato su thedigitalprojectmanager.com.
Alla prossima, grazie per l’ascolto.