Che cosa si intende per “Valore Aziendale” (o Business Value) ?

In questi ultimi quattro anni ho letto libri, seguito blog, ascoltato interventi, scambiato opinioni con clienti, partner e persino concorrenti.

Una valanga di concetti come “debito tecnico”, “velocità”, “impegno”, “incremento spendibile” e ovviamente “business value”.

Tutti concordiamo sul fatto che Scrum sia focalizzato sulla creazione di valore per le organizzazioni. Ma poche persone sono state in grado di definire il “valore” come qualcosa che sia realmente significativo nel contesto di un progetto o di un’organizzazione.

In verità questo è un problema sistematico di tutte le teorie di gestione. Incontriamo spesso termini che sembrano molto profondi in apparenza, e poi molto difficili da tradurre in comportamenti e decisioni reali nel mondo reale.

Prendi termini come “spreco” (in Lean), “flusso” (in Kanban), “empirismo”, “qualità”, “leadership”.

Potenzialmente sono solo parole, concetti astratti, giochi linguistici. In Scrum, è importante che un Team fornisca molto di frequente valore.

Il Product Owner – che fa parte dello Scrum Team (non dimentichiamolo) è responsabile di massimizzare il valore (aziendale) che un team di sviluppo offre durante gli Sprint.

Ma cosa significa nel mondo reale questa affermazione ? Cosa potrebbe significare nel tuo ambiente di lavoro ? La tua azienda o la tua organizzazione ?

Proviamo a domandarci:

  • come fai a sapere se il lavoro svolto dal team di sviluppo ha un valore ?
  • tutte le funzionalità consegnate (funzionanti) sono direttamente preziose per l’organizzazione ?
  • cosa significa “valore massimizzante” in termini di comportamento e decisioni ?
  • come fai a sapere quali funzionalità hanno più valore aziendale rispetto ad altre funzionalità ?
  • ci sono diversi tipi di valore ? Sono equivalenti ? Come li confronti ?

È difficile dare una risposta a queste domande.

Infatti, nella guida a Scrum, intelligentemente (o furbescamente ?) non si affronta veramente il tema. Si legge che la definizione di valore dipende dal contesto e dall’organizzazione in cui viene svolto il lavoro.

In effetti, la Guida Scrum non fornisce affatto una definizione di “valore”, ma insiste fortemente sul fatto che un Team dovrebbe fornire valore e che il Product Owner è la persona chiave per decidere cosa ha valore e cosa no.

Ma cosa succede se non esiste una buona definizione di valore ?

Posso facilmente immaginare uno Scrum Team che funzioni perfettamente con i suoi Sprint, che offra funzionalità di alta qualità ad un ritmo costante per il Product Owner, ma in realtà non fornisce nulla di valore all’organizzazione.

Quindi “fare Scrum” (soltanto) non porterà magicamente a un valore maggiore. È ancora molto facile rischiare di lavorare sulle “cose sbagliate nel momento sbagliato”.

Vediamo allora quali potrebbero essere i diversi tipi di valore aziendale.

Abbiamo detto che il lavoro svolto da un Team dovrebbe in qualche modo avvantaggiare l’organizzazione o l’azienda nel suo insieme.

Il valore aziendale è un termine informale che include tutte le forme di valore che determinano la solidità e il benessere dell’azienda nel lungo periodo.

Possiamo provare a dire meglio con altre parole: abbiamo bisogno di avere un modo per determinare se qualcosa nel backlog è “la roba giusta” o “la roba sbagliata”, e quando si stabiliscono le priorità dovremmo essere in grado di dire se è “il momento giusto” o “il momento sbagliato”.

Scrum è orientato allo sviluppo del software, sebbene possa essere facilmente applicato ad altri tipi di lavoro. Penso che possiamo distinguere diversi tipi di valore che possono essere generati per l’azienda / organizzazione dal lavoro svolto da un Team durante uno Sprint.

Partiamo dalla domanda chiave : “Quante entrate o profitti ha questo lavoro?”. Stiamo parlando di “Valore commerciale”, è il più ovvio e consiste in funzionalità o lavoro che si traducono direttamente in profitto, come:

  • una nuova versione di un pacchetto software che i clienti vogliono avere e sono disposti a pagare;
  • una nuova funzionalità che può essere pagata, come i moduli nelle app Web on-demand;
  • cambiamenti che riducono i costi operativi, ad esempio la riduzione dei server richiesti per fare funzionare una applicazione o un servizio, ottenuta migliorando il codice o la distribuzione più economica ai clienti;
  • migliorare il valore soggettivo dell’applicazione in modo che le persone siano disposte a pagare di più (in Lean Six Sigma questo è considerato qualità o valore del cliente, un esempio per tutti il modello di business di Apple).

Cos’è invece il “Valore di mercato” ? In questo caso la domanda che ci poniamo è: “Quanti nuovi clienti saremo in grado di servire?”. Il valore di mercato aumenta il numero potenziale di clienti, attraverso funzionalità che attraggono un nuovo gruppo di clienti; trasposizione di applicazioni ad altre piattaforme, per esempio da iOS ad Android; aggiunta di funzionalità che i concorrenti non hanno (o implementano meglio).

“Quanto tempo o denaro potremo risparmiare ?”. Si tratta del valore dell’efficienza: aumenta l’efficienza organizzativa e quindi riduce i costi operativi, come:

  • la quantità di errori in un processo o aumentare la velocità (automatizzandolo in tutto o in parte);
  • aumentare l’usabilità o la qualità di un’applicazione per ridurre il carico servizio clienti;
  • riduzione della quantità di tempo necessaria per configurare nuovi ambienti cliente o distribuirli;
  • riduzione dei tempi di commercializzazione.

Chiediamoci poi: “fino a che punto diminuirà la probabilità che un cliente se ne vada?”. Il valore per il cliente aumenta la probabilità che i clienti continueranno a utilizzare il tuo prodotto (“fai stare stare meglio il cliente”). Per esempio migliorare l’usabilità in un’applicazione oppure l’aggiunta di una nuova funzionalità che viene comunemente richiesta dagli utenti.

Infine, “Quanto ci farà risparmiare tempo e denaro in futuro ?”. Il valore futuro aumenta le possibilità di raggiungere più facilmente uno dei valori di cui sopra nel futuro (prossimo) investendo in innovazione e apprendimento: per esempio un nuovo framework (personalizzato o open source) che possa essere utilizzato per lo sviluppo futuro. Oppure riduzione del debito tecnico nel codice per rendere le modifiche future nel codice più facili o meno soggette a errori.

Ci sono molti altri tipi di valore che possono essere identificati, ma penso che possano essere tutti ristretti all’insieme che ho appena delineato.

Per concludere quindi, un Product Owner dovrebbe essere in grado di valutare ogni cosa da fare presente nel backlog e dovrebbe essere in grado di tradurla in valore (di business) per l’organizzazione, nel modo più specifico possibile (ma qui è consigliabile un certo pragmatismo).

Il Team deve a sua volta dimostrare che quello che sta facendo è “la cosa (attività) giusta al momento giusto”. In caso contrario, o se le argomentazioni non sono abbastanza forti, il Product Owner dovrebbe evitare di sprecare tempo prezioso, sforzi e denaro per il lavoro che non sposta in avanti l’organizzazione e gli impiegati.