Imparare dalle delivery

Premessa

L’apprendimento è un aspetto fondamentale della nostra vita, è continuo e spesso inconsapevole.

Imparare, anche dai nostri errori, ci consente infatti di prendere decisioni senza le quali non saremmo le persone che siamo.

Impariamo fin dal nostro primo giorno di vita e quando dopo diventiamo genitori diciamo ai nostri figli che “sbagliando si impara”.

Questo insegnamento dovrebbe diventare una specie di mantra, che deve riecheggiare costantemente nella nostra mente, accompagnandoci in qualsiasi azione compiamo.

Continuous Learning ed MVP

Qualche tempo fa ho riletto uno dei libri alla base della mia formazione professionale: “User Story Mapping”, e fra le sue pagine ho ritrovato, da un lato, alcune delle definizioni che l’autore Jeff Patton ed il suo amico Eric Ries (“The Lean Startup”) danno di “MVP” (Minimum Viable Product):

Il minimo prodotto fattibile è il più piccolo

rilascio del prodotto che raggiunge con successo ilrisultato desiderato

insieme a

Il minimo prodotto fattibile è ANCHE la più piccola

cosa che potresti creare o fare

per provare o confutare un presupposto

dall’altro lato, un concetto su cui si insiste spesso in questo libro: il “Continuous Learning”, cioè ”imparare” sempre e da ogni situazione.

Ma come si collegano “Continuous Learning” ed “MVP”?

Se analizziamo meglio la seconda definizione di MVP, possiamo rileggerla/interpretarla come un piccolo esperimento da cui imparare qualcosa, confermando o confutando quanto presupposto in un primo momento.

In pratica l’MVP può essere inteso, quindi, come un piccolo esperimento da portare all’attenzione del nostro cliente/utilizzatore.

Ma piccolo quanto? Grande quanto?

Sufficientemente grande da farci apprendere qualcosa, ma nello stesso tempo sufficientemente piccolo da rappresentare un rischio gestibile e sostenibile in caso di fallimento.

Il principio è che l’arte di massimizzare la quantità di lavoro non svolto è essenziale.

Filosofia DevOps ed MVP

Questo modo di vedere l’MVP è perfettamente in linea anche con l’approccio DevOps detto a tre vie, dove ogni via è un passo che si compie verso l’applicazione dei relativi principi filosofici che sono alla base di DevOps:

Prima via – Flow: pensare per sistemi, con lo scopo di migliorare le operazioni tra l’idea e la consegna

Seconda via – Feedback: amplificare il ciclo di feedback, ovvero far sì che i dati guidino le nostre decisioni

Terza via – Learning: abbracciare una cultura di sperimentazione continua e apprendimento, per rendere tali valori parte della nostra quotidianità

Tuttavia, nella maggior parte dei casi che mi trovo ad affrontare quotidianamente l’MVP è inteso solo come un qualcosa da rilasciare, un “pacchetto” di funzionalità giudicate più di valore in quel momento.

Il concetto può essere ritenuto corretto, ma non è sufficiente. Infatti, se non guardiamo anche i feedback che ci tornano dai clienti/utilizzatori allora non avremo imparato niente. E se non impariamo, se non comprendiamo gli eventuali errori

commessi, non saremo in grado di crescere e migliorare, non sapremo se stiamo risolvendo il problema giusto nel modo giusto.

I feedback ci danno la misura dei successi e dei fallimenti e le basi su cui creare le ipotesi dei prossimi esperimenti.

Ma abbiamo più livelli di feedback? Se sì quanti sono?

Chris Argyris, un teorico della “Learning Organization”, dice che esistono due livelli di feedback che chiama loop learning:

Il primo, quello più interno (Single-loop), si focalizza sulla risoluzione dei problemi riscontrati durante lo svolgimento del proprio lavoro; il secondo (Double-loop), quello più esterno, si focalizza, invece, su cosa fare per evitare che gli errori si verifichino.

Mentre col primo loop si lavora su quello che è possibile migliorare all’interno di un sistema già esistente, col secondo si prova a sfidare il sistema cercando il modo di cambiarlo.

Quello che i due loop hanno in comune è che si basano sui risultati ottenuti dopo un rilascio.

C’è, dunque, un legame molto stretto fra apprendimento e rilascio.

Non ci può essere “Continuous Learning” senza “Continuous Delivery”: soltanto rilasciando continuamente possiamo validare i nostri esperimenti misurando i risultati e continuando ad imparare da questi ultimi.

Concludo con una frase del mio amico Jacopo Romei: “La definizione che preferisco di Agile è la misura della frequenza con cui ci procuriamo i feedback end-to-end sulle decisioni prese”.

Impariamo ad imparare dalle delivery e dai relativi feedback.

Autore: Nicola Lobusto – Agile Coach