Fallisci presto, impara in fretta: sii Lean!

Build, measure, learn

Il Lean è una cultura orientata a comprendere le esigenze del cliente, ridurre gli sprechi e ottimizzare i processi, una filosofia che potremmo riassumere nel motto “massimo risultato con il minimo sforzo”.

E’ una teoria di organizzazione aziendale che integra al suo interno varie metodologie gestionali.
Obiettivo del Lean è produrre di più con un minor consumo di risorse.
Il termine “lean production” – produzione snella – è stato coniato in riferimento al sistema Toyota, l’azienda automobilistica giapponese caratterizzata da processi industriali ad altissima efficienza rispetto ai principali produttori mondiali di automobili.

Tra i concetti chiave del Lean c’è l’idea del miglioramento continuo (“Kaizen”) perseguito mediante l’applicazione di un processo ciclico in 3 fasi: sperimentazione, misurazione dei risultati e apprendimento (build, measure, learn).

Nel famoso libro di Eric Ries “Lean Start-up” viene più volte ribadito che l’acquisizione di conoscenza è cruciale per il successo di un’iniziativa imprenditoriale:

“Questo è il modo giusto di pensare alla produttività in una start up: non in termini di quanta roba stiamo producendo, ma di quanto apprendimento validato stiamo incamerando per i nostri sforzi.
Ogni bit di conoscenza che raggiungiamo ci suggerisce nuovi esperimenti da fare che muovono le nostre metriche più vicine ai nostri obiettivi.”

Un processo Lean prevede i seguenti step:

  1. Identificare cio’ che vale per gli utenti 
(per cosa sono disposti a pagare un prezzo?)
  2. Identificare il flusso del valore
    definire la sequenza ottimale delle attività per creare valore
  3. Far scorrere il flusso del valore
    eseguire le attività di valore senza inutili interruzioni
  4. “Pull” e non “push”

    fare scorrere il flusso del valore in base alla domanda, non all’offerta
  5. Puntare alla perfezione come punto di riferimento in un contesto di miglioramento continuo

Se applichiamo i principi Lean al mondo del software e in generale della progettazione ritroviamo gli step ciclici di build, measure, learn.

Dobbiamo identificare un problema o un’opportunità di sviluppo e verificare che abbia davvero valore per gli utenti (per questo è necessario acquisire conoscenza dei loro bisogni e e necessità).
Modifichiamo il nostro punto di vista e proviamo a ridefinire il problema dal punto di vista degli utenti. Mettiamoci “nei loro panni”.
Solo a questo punto – quando siamo stati in grado di avere empatia nei confronti di coloro per cui stiamo progettando – siamo in grado di fare brainstorming in maniera proficua e portare soluzioni creative.

Una volta definite la nostra idea ne verifichiamo le assunzioni (cosa stiamo dando per scontato senza averne alcuna prova?) conducendo degli esperimenti.
Possiamo creare un prototipo – il più “lean” possibile – per mettere alla prova l’idea in poco tempo e con il minimo delle risorse per testare la soluzione sul campo e raccogliere feedback quanto prima.

Il confronto reale con i propri utenti ci permette di validare l’idea iniziale raffinandola ulteriormente, di aggiustare il tiro o – in alternativa – di non proseguire oltre.
Anche una soluzione che si rivela totalmente sbagliata è un insegnamento di successo: ci evita lo spreco di realizzare un prodotto/servizio che non ha valore per l’utente finale e ci offre l’opportunità di investire meglio le nostre risorse.

A conti fatti se non puoi fallire, non puoi imparare.

Build, measure, learn

L’importanza di fare Sprint Demo

Perché fare demo del lavoro svolto nello sprint?
Si possono saltare? Meglio di no.
E’ importante tenerle con continuità per più motivi.

Descriviamo una situazione tipica…
Il vostro team fa Scrum, comincia ad avere una discreta conoscenza della metodologia ed è abbastanza rigoroso nell’esecuzione delle cerimonie.

Quindi si fa il planning, le review e le retrospective, ma – chissà perché – c’è una certa ritrosia nel fare demo aperte a tutti.
E magari vi ritrovate al penultimo giorno dell’iterazione con qualcuno che chiede: “ma dobbiamo proprio farla la demo?”.
Sì, assolutamente sì!
Non a caso la Sprint Review si chiama anche Sprint Demo…

Non è una questione di controllo (“vediamo cosa avete fatto in tutto questo tempo!”), di principio (“dobbiamo farla perché in Scrum si fa”) o di forma (“facciamo la demo così lo Scrum Master è contento”)…
Dal mio punto di vista è proprio un tema di sostanza.
Perché una review con una vera e propria demo estesa a tutti i potenziali interessati è, rispetto ad altre cerimonie, la migliore occasione che il team ha per interagire realmente con gli stakeholder e con tutti coloro che hanno una visione parziale del progetto.

Durante la demo viene illustrato l’incremento di prodotto realizzato nel corso dello sprint.
La finalità non è dimostrare agli altri quanto è stato bravo il team o esporlo al pubblico biasimo se non ha portato a termine tutto quello che era stato programmato.
Oltre all’accettazione formale delle storie da parte del Produt Owner, ci confrontiamo con il resto dell’azienda per ottenere dei feedback e far emergere aspettative che sino a quel momento non hanno avuto voce.

La finalità della demo è triplice: verificare cosa va bene, capire cosa eventualmente non va bene e capitalizzare idee.
Non accoglieremo necessariamente tutto quanto emerge dalla platea, ma avremo raccolto un piccolo patrimonio di osservazioni che potranno rivelarsi preziose nel seguito del progetto.
In alcuni casi la demo consente di portare alla luce effetti collaterali che non avevamo preso in considerazione o di cui non avevamo valutato a pieno la portata.

Mi è capitato proprio di recente.
Il team porta a termine un’iterazione e completa una user story con un elevato valore di business nell’arco delle canoniche due settimane.
Il manangement è interessato a rilasciare la funzionalità il prima possibile.
Nel corso della demo emerge che gli sviluppatori hanno trovato una soluzione semplice ed efficace per l’implementazione, ma questa scelta produce conseguenze inattese sulle altre properties. Qualcosa si è perso nella comunicazione tra il Product Owner ed il team. Nulla di grave. Può succedere e c’è sempre un modo per porvi rimedio.
Si decide di rimandare il rilascio di un’iterazione, il tempo utile per realizzare un piccolo incremento di prodotto e garantire la massima flessibilità a tutti gli altri gruppi di sviluppo.

Senza la demo questo problema non sarebbe emerso.
Avremmo rischiato di scoprirne le conseguenze solo in produzione. Avere tutti gli interlocutori seduti al medesimo tavolo ci ha consentito di intercettare per tempo la criticità e trovare la risposta più adeguata.

Inspect and adapt in ogni fase.

La comunicazione, la trasparenza e l’esporre il lavoro svolto sono passi fondamentali quando si intende perseguire un miglioramento continuo.