Iterativo e incrementale? Agile

Questo articolo fa parte di una serie di mie riflessioni sull’Agile project management, cominciata qui.

Lo sviluppo di un prodotto in rilasci incrementali, frutto di iterazioni successive, non solo aumenta la qualità esplicita del prodotto (grazie al vincolo di rilasciabilità alla fine del ciclo), ma insegna anche a tutti coloro che sono coinvolti nel progetto cosa è realmente necessario per supportare una business vision.

Anche in questo caso ricorro alle buone pratiche di Henrik Kniberg e ad un suo esempio che è diventato virale e che trovate qui, nella sua forma originale.

Primo esempio – non come questo …
La riga superiore mostra un malinteso comune sullo sviluppo di un prodotto in modo iterativo e incrementale (a.k.a Agile).

Immaginate di andare da un cliente che ha ordinato una macchina e dirgli: “Ecco la nostra prima iterazione, un pneumatico anteriore. Cosa ne pensi?” Il cliente verosimilmente ci risponderà “Perché diavolo mi stai mostrando un pneumatico? Ho ordinato una macchina! Cosa dovrei fare con questo?”. Se proseguite in questo modo, ad ogni iterazione il prodotto si avvicina a quello che è stato ordinato, ma il cliente sarà ancora arrabbiato perché non può effettivamente utilizzare quanto gli viene presentato. E ‘ancora solo una macchina parziale. Inoltre, quando il prodotto sarà completato, il vostro cliente potrebbe dirvi: “Grazie! Finalmente! Perché non mi avete consegnato subito questo, saltando tutte le altre consegne inutili?”. Infine, in questo esempio, il cliente appare felice del prodotto finale, perché è quello che ha ordinato. In realtà, questo non è generalmente vero. Un sacco di tempo è passato senza alcun test utente effettivo, ed è più probabile che il prodotto abbia difetti di progettazione basati su presupposti errati rispetto a ciò di cui il cliente ha bisogno. Vi ricorda qualcosa?

In ogni caso, la prima riga rappresenta un “agile imbastardito”. Tecnicamente potrebbe sembrare una consegna incrementale e iterativa, ma l’assenza di un ciclo di retroazione effettiva rende molto rischioso – e sicuramente non agile.

Secondo esempio – Ti piace questa? Ora guardate la seconda riga. Qui abbiamo un approccio molto diverso. Si comincia con lo stesso contesto – il cliente ha ordinato una macchina. Ma questa volta non ci limitiamo a costruire una macchina. Invece ci concentriamo sulla necessità di fondo che il cliente vuole soddisfare. Scopriamo che il suo bisogno di fondo è “Ho bisogno di andare da A a B in modo più veloce”, e l’auto è solo una possibile soluzione a questo. Ricordate, l’automobile è solo una metafora, commisurate l’esempio su qualsiasi tipo di situazione di progetto.

Nell’approccio Agile, il team offre al cliente la cosa più piccola con la quale può pensare di ottenere un test dal cliente ed un feedback. Alcuni potrebbero definirlo un MVP (Minimum Viable Product). E’ improbabile che il cliente che contento di questo. Questo non è neanche lontanamente la macchina ha ordinato. Ma va bene! Ecco il punto – non stiamo cercando di rendere il cliente felice a questo punto. Il nostro obiettivo principale, a questo punto è solo quello di imparare. Idealmente, il team lo spiega chiaramente al cliente in anticipo, in modo da non generare troppa delusione. Tuttavia, in contrasto con la ruota anteriore nel primo scenario, lo skateboard è in realtà un prodotto utilizzabile, che aiuta il cliente ad andare da A a B in modo più veloce. Non eccezionale, ma un pochino meglio di niente. Quindi diciamo al cliente “non preoccuparti, il progetto non è finito, questo era solo la prima di molte iterazioni. Abbiamo ancora l’obiettivo di costruire una macchina, ma nel frattempo per cortesia prova questo e dacci un feedback “. Pensare in grande, ma consegnare in piccoli incrementi funzionalmente vitali.

Potremmo imparare alcune cose davvero sorprendenti. Supponiamo che il cliente dice che odia lo skateboard; chiediamo perché, e lui dice “Odio il colore”. Siamo sorpresi “uh …. il colore? È tutto?”. E il cliente dice: “Sì, lo preferisco blu! Oltre a questo, va bene! “. Avremo appena risparmiato un sacco di denaro, non costruendo la macchina! Non è probabile, ma chi lo sa?

La domanda chiave è: “Qual è il modo più economico e più veloce con cui possiamo iniziare ad imparare?” Possiamo consegnare qualcosa anche prima di uno skateboard? Che ne dite di un biglietto dell’autobus?

Può questo aiutare a risolvere il problema del cliente? Forse, forse no, ma potremo sicuramente imparare qualcosa consegnando questo nelle mani di utenti reali. Non è necessario testare il prodotto su tutti gli utenti, e non c’è bisogno di costruire un prodotto per testare qualcosa. Il test di un prototipo, anche un singolo utente vi insegnerà più di niente.

Torniamo all’esempio skateboard.

Dopo aver giocato un po’ intorno all’ufficio, il cliente dice “OK, divertente, e mi fa raggiungere la macchina del caffè più velocemente. Ma è instabile. Cado troppo facilmente “. Così nella prossima iterazione cerchiamo di risolvere il problema, o almeno di saperne di più.

Un monopattino! Il cliente può ora girare in ufficio senza cadere!

Contento? Non proprio, ha ancora voglia di quella macchina. Ma nel frattempo sta utilizzando questo prodotto, e ci dà feedback. La sua più grande lamentela è che è difficile percorrere distanze più lunghe, ad esempio tra due edifici, a causa delle ruote piccole e della mancanza di freni. Così, la prossima versione del prodotto si trasforma in qualcosa di simile a una bicicletta.

Ora il cliente può girare velocemente ed in sicurezza per tutto il campus! Abbiamo imparato altre cose lungo la strada: il cliente ama la sensazione di aria fresca sul viso. Il cliente è in un campus, e le sue necessità di trasporto sono per lo più girare tra gli edifici.

La bicicletta può rivelarsi un prodotto migliore della macchina inizialmente prevista. Infatti, durante la prova di questo prodotto possiamo imparare che i percorsi sarebbero comunque troppo stretti per una macchina. Abbiamo appena risparmiato a molti clienti tempo e denaro, e gli abbiamo dato un prodotto migliore in meno tempo!

Ora si può pensare “ma non avremmo già scoperto queste cose tramite un’analisi up-front del contesto e delle esigenze del cliente?” Buon punto. Ma nella maggior parte degli scenari di sviluppo di prodotti reali , non importa quanta analisi up-front fai, resti ancora sorpreso quando metti la prima versione reale nelle mani di un utente reale, e molti delle tue ipotesi risultano essere fuori strada.

Quindi sì, fate un po di up-front analisi, scoprire quanto più è possibile prima di iniziare lo sviluppo. Ma non spendete troppo tempo su di esso e non vi fidate troppo – iniziate la prototipazione e rilasciate: è in quel momento che succede il vero apprendimento.

Comunque, tornando alla storia, forse il cliente vuole di più. A volte ha bisogno di recarsi in un’altra città, e la corsa in bicicletta è troppo lenta e faticosa. Così nella prossima iterazione aggiungiamo un motore.

Questo modello è particolarmente adatto per il software, dal momento che il software è, beh, Soft. Si può “trasformare” il prodotto, lungo la strada, al contrario dell’hardware dove si deve essenzialmente ricostruire ogni volta.

E ora? Anche in questo caso, forse il cliente è felice con la moto. Potremmo finire il progetto prima del previsto. La maggior parte dei prodotti sono pieni di complessità e di caratteristiche che nessuno usa. L’approccio iterativo è davvero un modo di fornire meno, o trovare il modo più semplice ed economico per risolvere il problema del cliente (lean thinking).

Oppure, ancora, il cliente potrebbe scegliere di continuare, con o senza modifiche ai requisiti. infatti si può finire con la stessa identica macchina originariamente prevista. Tuttavia è molto più probabile che guadagniamo intuizioni vitali lungo la strada e finiamo con qualcosa di leggermente diverso. Come questo.

Il cliente è felice! Perché? Perché abbiamo imparato lungo la strada che egli apprezza l’aria fresca in faccia, così abbiamo finito con una decappottabile: una macchina dopo tutto – ma una macchina migliore di quanto originariamente previsto!

Quindi facciamo un passo indietro.

Nello sviluppo del prodotto, una delle prime cose che dovreste fare (dopo aver descritto quale problema si sta cercando di risolvere per chi) è quello di individuare il vostro skateboard-equivalente: la più piccola cosa che si può mettere nelle mani degli utenti reali, e ottenere un feedback reale.

Questo vi darà un ciclo di retroazione necessario, e darà a entrambi (voi ed il cliente) il controllo sul progetto – si può imparare e fare i cambiamenti, invece di seguire il piano e sperare per il meglio.

Sul blog di Henrik il post prosegue con alcune esperienze reali …

Prosegue qui

disclaimer