trianglee

Insights Agile Product … Development o Agile … Product Development?

"Technical agility" o "business and process" agility? Non c'è da scegliere!

Linkedin Twitter
Scroll
05/11/2020

Articoli

di Stefano Muro

 

Vi domanderete cosa vuol dire il titolo: perché c’è una ripetizione? In realtà non vi è alcuna ripetizione nel titolo: l’attribuzione dell’aggettivo agile al prodotto o allo sviluppo del prodotto definisce due concetti fondamentali che, sebbene vadano a braccetto tra loro, molto spesso dividono chi applica e diffonde i valori e i principi agili.

 

Definizione di “agile”

 

Innanzitutto, per coloro che sono poco avvezzi al termine “agile” nel contesto dello sviluppo di prodotti (spesso SW ma non solo), potete con ottima approssimazione sostituirlo con “adattivo“: per rispondere all’incertezza, alla volatilità e all’ambiguità del mondo in cui viviamo abbiamo bisogno di essere “adattabili” così da poter sopravvivere o addirittura avere un vantaggio competitivo rispetto agli altri.

Agile Product … Development

 

 

Per essere “adattivi” (o meglio “adattabili”) prima di tutto lo deve essere il nostro prodotto: se per adeguarci ai cambiamenti del mercato e del contesto in cui ci troviamo, dobbiamo ogni volta ricominciare d’accapo, rischiamo di spendere tanto e comunque non riuscire a star dietro alle novità: il nostro prodotto deve essere facilmente modificabile, estensibile, e configurabile (quindi consentire una risposta proattiva al cambiamento), ma anche resiliente (risposta reattiva al cambiamento). Spesso ci si riferisce al mindset, all’approccio e alle pratiche correlate a questo concetto con l’appellativo di “Technical Agility”.

 

Nel SW questa caratteristica del prodotto si ottiene utilizzando appropriate tecniche di design e di codifica (potete vedere il blog di Uncle Bob o di Martin Fowler per farvi un’idea) che portano ad avere un SW modulare, estensibile, testabile e scalabile.

 

Nell’HW (o più genericamente nei sistemi non esclusivamente SW) similmente questa “agilità” si ottiene utilizzando paradigmi architetturali e approcci specifici, di cui, ad esempio, l’Open System Architecture definita dal Dipartimento della Difesa Americano (DoD), è un ottimo esempio.

L’obiettivo, per questi sistemi, è ottenere, facendo leva sulla standardizzazione delle interfacce, prodotti e sistemi che possono facilmente evolvere e modificarsi nel tempo, adattandosi alle condizioni operative.

 

L’agilità quindi inizia da qui, dall’eccellenza tecnica e dal buon design: in un mondo che cambia continuamente se non si è in grado di adattare il proprio prodotto nei tempi necessari, alla luce delle nuove condizioni, non si potrà mai essere competitivi.

Agile … Product Development

 

Avere però un “prodotto agile” ossia facile da adattare sia durante lo sviluppo che durante l’operatività non è sufficiente.

Bisogna avere la capacità di percepire quali sono i cambiamenti nel mercato e nei nostri utenti per sapere come modificare il nostro prodotto e avere un processo che ci consenta di farlo velocemente anche sperimentando nuove soluzioni e testando nuove ipotesi.

 

C’è quindi bisogno di uno sviluppo agile di prodotto in termini di processo end-2-end che sia iterativo e includenda:

  • l’interazione con i clienti,
  • la definizione di ipotesi che potrebbero condurre ad un beneficio per il cliente e per il nostro business,
  • la messa a terra di semplici soluzioni-esperimento che possono validare o smentire le nostre ipotesi e la raccolta di feedback.

 

Molto spesso questo processo “agile” viene messo in piedi solo a metà perché, probabilmente, non ne viene compreso lo scopo fino in fondo. Spesso le aziende creano team cross-funzionali in grado di realizzare ogni due settimane incrementi di prodotto sempre più velocemente con livelli di qualità sempre superiori ma:

 

  1. non raccolgono feedback concreti sull’utilità vera per gli utenti della soluzione realizzata rispetto a quanto fatto dai nostri concorrenti o rispetto semplicemente al nostro prodotto precedente che stiamo andando a sostituire
  2. vengono date per scontante le soluzioni decise a monte, durante una fase iniziale di analisi up-front, senza considerare che ci sono cose che nel frattempo potremmo aver imparato e prima non sapevamo o che ci sono cose che davamo per certe sei mesi fa e potrebbero essere cambiate.

 

In pratica viene messo in piedi un processo non volto a mitigare il rischio di fare la cosa sbagliata (in termini di ritorno dell’investimento), ma volto a mitigare il rischio che si stia realizzando una cosa diversa da quella che si era già deciso di fare, indipendentemente se si stia rivelando corretta o meno.

 

Conclusioni e riflessioni personali

 

Affinché un’azienda possa essere competitiva in mercati fortemente dinamici e competitivi è necessario che sia in grado di realizzare prodotti “agili” ossia facilmente mantenibili/modificabili ma anche che abbia un processo di sviluppo “agile”che individui in maniera esplorativa, tramite esperimenti, quali siano le caratteristiche di prodotto che producano il miglior rapporto Costo/Beneficio.

Purtroppo, per mia esperienza, i due aspetti spesso non vanno di pari passo: alcune aziende approcciano la trasformazione agile “dal basso” adottando pratiche che consentono di avere un “prodotto agile” senza che però questa caratteristica venga sfruttata a pieno dal business. In altri casi la trasformazione parte dal business (pensate alle aziende che adottano pratiche di “Agile Marketing”) ma poi si va a scontrare con un prodotto o un processo di sviluppo che non consente modifiche tempestive in fase di sviluppo nè tanto meno durante l’operatività.