Ottobre 26, 2020 - di Giulia Tumminelli
Qualche settimana fa sul nostro blog è uscito un articolo sulla metodologia Agile Scrum: cosa è e a cosa serve. Qui, ci siamo soffermati sulla teoria, le best practices e l’approccio in generale. Adesso, è arrivato il momento di fare uno step successivo e dedicare la nostra attenzione su un esempio pratico.
Lo sapete già da tempo, a noi eroi di prodotto ci piace “to get real”, come direbbero gli americani!
Oggi, quello che vi propongo, è un esempio pratico tratto da un caso fittizio in cui abbiamo applicato la metodologia Agile Scrum: AppFit, l’app che ti fa rimanere in forma dovunque tu sia senza bisogno di attrezzi.
Partendo dall’inizio, vi racconterò passo dopo passo come utilizzare la metodologia Agile Scrum a livello pratico, dal concepimento dell’idea alla sua effettiva realizzazione e continuo miglioramento.
Di seguito, un’anticipazione su ciò che troverete nell’articolo:
Se vuoi scaricare il post che stai leggendo in PDF e accedere ad oltre 100 pagine su Agile, Team Cross-funzionale, Scrum/Kanban, Backlog, etc. ti presento Agile Starter Kit, una cartella condivisa su Google Drive pensata per gli eroi come te che stanno iniziando il proprio viaggio nel Digital Product Management.
Scarica Gratis Agile Starter KitSe hai già accesso alla cartella troverai direttamente lì il post in PDF.
Il termine Lean UX è stato coniato da Jeff Gothelf e Josh Seiden. Questa pratica si basa sul principio di collaborazione estrema fra tutti gli esponenti di un team, pur con diverse expertise, per portare alla luce un nuovo prodotto molto più velocemente.
La metodologia Lean UX, declinazione di Agile Scrum, si basa sulle seguenti fondamenta:
Josh e Jeff si soffermano più volte su questo concetto: “We work to build a shared understanding of the customers, we prioritise learning over delivery to build evidence for our decisions.”
E’ proprio su questo principio: “Prioritizzare l’apprendimento piuttosto che il rilascio delle funzionalità” che si basa la scoperta e la pivotizzazione del nostro esempio pratico: AppFit.
Mi spiego meglio: quando si ha che fare con un prodotto digitale, in questo caso un’app, bisogna testare che le proprie assunzioni, fatte durante il concepimento dell’idea, siano veritiere.
Utilizzando la tecnica Lean UX, dove l’intero team contribuisce alla creazione di mini prototipi dell’app e alla divulgazione di essi al pubblico, capiremo quali delle nostre idee sono buone e quali invece vanno scartate.
Vediamo nello specifico, come applicare la tecnica Lean UX nel processo di validazione delle features di AppFit, partendo dall’organizzazione del team.
Prima di tutto…di chi abbiamo bisogno?
Sicuramente di un team che abbia le seguenti caratteristiche:
Una volta formato il team, ci dobbiamo assicurare che TUTTI siano coinvolti dal primo istante e che abbiano uno “shared understanding” dei goal che vogliamo raggiungere.
Questo ci farà risparmiare un sacco di tempo e soldi. Perché?
Perché il coinvolgimento di tutti gli stakeholder fin da subito, permette di creare una sorta di “intelligenza collettiva” che, a turno, farà emergere la creazione e il continuo miglioramento del prodotto digitale molto più velocemente e in maniera sostenibile.
D’altronde, il mercato di riferimento di cui ci stiamo occupando, in questo caso fitness apps, procede a velocità supersoniche. Siete d’accordo?
Veniamo alla parte più difficile del processo: “intendere il lavoro come problemi da risolvere”.
Per validare l’idea di una fitness app che potesse essere utilizzata ovunque e senza attrezzi, bisogna dare risposte alle seguenti domande:
Come si fa quindi a dare risposta a queste domande?
Da dove si comincia?
Partendo dal Problem framing, ovvero dal considerare il lavoro che andremo a svolgere sul prodotto come un problema da risolvere per il nostro target.
I nostri consumer dell’app, non vogliono “features”, vogliono che l’app li faccia avvicinare il più possibile ai loro obiettivi. In questo caso di benessere fisico ovunque si trovino, senza il pensiero di doversi procurare attrezzature costose o pesanti da trasportare.
(Fonte: https://blog.pixielabs.io/)
Quali sono i benefici d’intendere il lavoro svolto e quindi la realizzazione di un prodotto digitale come problemi da risolvere?
Una volta individuato il problema (creare un’app che faciliti l’allenamento ovunque e senza sforzi) e organizzato il team, cominciamo a mettere uno dopo l’altro i “building blocks” della nostra app tramite la tecnica della Lean UX Canvas.
Consideratela come una tela da riempire con i vostri best guesses su:
Del problem framing, ce ne siamo già occupati, adesso occupiamoci dei “big 4”.
Cosa sono i big 4? Sono le assunzioni che andremo a fare su:
Facciamo questo esercizio insieme. Di solito in Lean UX, si fa con l’aiuto e la collaborazione di tutto il team.
Sediamoci a tavolo con i membri del nostro team e proviamo a costruire la nostra prima tela sui business outcomes, ovvero i cambiamenti misurabili che vorremmo vedere nel mondo e nel comportamento dei nostri clienti.
In questo caso, il business outcomes (o obiettivi di business) potrebbero essere quelli di mettere sul mercato un’app rivoluzionaria nel mondo del fitness che cambi l’esperienza di workout, permettendo a milioni di users di allenarsi quando e dove vogliono.
Anche qui, faremo lo stesso esercizio con l’aiuto del nostro team e lo ripeteremo per le altre due “tele”.
Il nostro intento, lo ripeto, è quello di permettere alle persone impegnate lavorativamente, magari 10/12 ore al giorno, di ritagliarsi uno spazio e allenarsi dove gli viene più comodo.
Qui, stiamo puntando a un target medio-alto e possibilmente nella fascia d’età 30-60, dove il tempo è limitato e quello libero deve essere dedicato al relax e al divertimento.
Un’ipotesi, potrebbe essere quella di ottimizzare il tempo disponibile per allenarsi. Quindi, magari puntare ad avere un tipo di allenamento personalizzato, a portata di fingertips.
Facciamo un’altra ipotesi. Se stiamo parlando di persone che lavorano e che hanno poco tempo a disposizione, sicuramente vorranno degli allenamenti veloci e time-boxed di 15-20 minuti massimo. Quindi, un’idea potrebbe essere quella di avere una feature che includa dei set di allenamenti localizzati che hanno una durata massima di 20 minuti con diversi livelli di difficoltà in base alla predisposizione dello user.
Sì, lo so che esistono milioni di app di questo tipo, ma qui il punto è la logica che stiamo utilizzando per creare il nostro prodotto digitale e non le feature!
Ok, finalmente abbiamo messo insieme le nostre quattro assunzioni, i “building blocks”, su business outcomes, users, user outcomes e features. Ora guardiamo al problema più grosso da risolvere: il “problem statement”.
Questi statements sono creati dal team quando si comincia a indirizzare la visione strategica di business.
Sono da considerarsi come delle linee guida che danno al team un focus molto chiaro per creare gli Sprint goals, ovvero gli obiettivi che di volta in volta si stabiliranno nelle iterazioni.
Partiamo dal seguente template, tratto dal libro Lean UX, per completare la nostra tela numero 1 all’interno della Lean UX Canvas.
Lo stato attuale del [dominio] si è focalizzato principalmente su [questi segmenti di clienti, pain points ecc] Quello in cui gli attuali prodotti falliscono è indirizzare [questo gap] Il nostro prodotto indirizzerà questo gap con [questa visione/strategia] Il nostro focus iniziale sarà [questo segmento di mercato] Sapremo se stiamo raggiungendo la nostra visione quando vediamo [questi comportamenti da parte degli users] |
Adesso proviamo a declinare il template, aggiungendo le nostre ipotesi in modo da comporre il nostro statement.
Lo stato attuale del [mercato delle fitness] si è focalizzato principalmente su [users che hanno poco tempo a disposizione per allenarsi quotidianamente] Quello in cui gli attuali prodotti falliscono è indirizzare [il problema del tempo, non considerando set di allenamenti personalizzati e brevi] Il nostro prodotto indirizzerà questo gap con [delle features centrate su allenamenti di brevissima durate e accessibili dovunque gli users si trovino] Il nostro focus iniziale sarà [il pool di lavoratori altamenti specializzati, con poco tempo a disposizione e un budget medio-alto per il tempo libero e il relax] Sapremo se stiamo raggiungendo la nostra visione quando vediamo [che il target di riferimento trascorra sull’app almeno 15 minuti al giorno] |
Ecco qui il nostro problem statement! Adesso, strutturiamo un po’ meglio le nostre “Personas”.
Le “PROTO-Personas” sono una versione più immediata delle “Personas”. Questo perché il concetto è che debbano essere riviste ciclicamente con la collaborazione dell’intero team.
Sono il nostro best guess in merito a “chi” userà il nostro prodotto e “perché”. Ovviamente, questo cambierà nel tempo, man mano che raccoglieremo dati sui nostri esperimenti e man mano che i nostri users ci daranno feedback sull’utilizzo dell’app.
Vediamo allora un piccolo identikit/avatar della nostra Proto-persona:
Avendo creato le nostre assunzioni più importanti e la nostra Proto-Persona, possiamo focalizzarci sul ciclo Agile Scrum. Come utilizzare la metodologia per trarne il meglio?
Partiamo da una considerazione importante: User stories, discovery e tech tasks devono necessariamente stare nello stesso backlog. Perché?
Perché bisogna creare quello “shared understanding” di cui parlavamo all’inizio di questo articolo. Tutto il team deve essere in grado di dare il suo contributo sulle attività di discovery. Si risparmia tempo e si ha un spirito molto più oggettivo nel giudicare cosa è bene fare e cosa no.
Un’attività molto interessante è il mobbing-UX, dove l’intero team partecipa a sessioni di Design Thinking e fa emergere le idee migliori.
Da queste attività nascerà il nostro primo MVP (Minimum Viable Product) che non deve essere per forza un set di funzionalità ben consolidato a livello di sviluppo software, ma un prototipo, se così vogliamo chiamarlo, che ci farà capire qual è la minima quantità di lavoro in grado di permetterci d’imparare la cosa più importante: le ipotesi più rischiose.
Il risultato potrebbe essere, un wireframe, un prototipo su InVision, oppure su carta. Il punto è di non sprecare troppo tempo a implementare le nostre assunzioni di tutto punto, se prima non sono state testate e sottoposte al nostro target.
Vediamo insieme un esempio di Product Backlog:
All’interno del backlog troviamo user stories, bugs, tech e discovery tasks. Ognuno dei Product Backlog items ha una priorità e degli story points assegnati.
Il che significa, che i vari items sono stati stimati tramite la tecnica del Planning Poker nelle sessioni di backlog refinement di cui abbiamo parlato qui.
Il backlog refinement, chiamato anche “grooming” in alcuni casi, è la prima cerimonia Agile che dà inizio al ciclo/iterazione.
In questo evento, vengono rifinite tutte le user stories che è necessario prioritizzare per il prossimo Sprint Planning.
La stesura degli Acceptance Criteria per le user Stories e la loro prioritizzazione viene fatta dal Product Owner con il supporto del team. Questa attività rappresenterà la prima parte del meeting.
La seconda parte della cerimonia sarà dedicata alla stima dell’effort delle user stories in story points. Questa stima darà le basi per lo Sprint Planning, evento in cui si dovrà decidere quante “storie” fare durante la Sprint che sta per iniziare e capire quanto effort effettivamente ci vorrà per ognuna di esse.
Torniamo al nostro adorato esempio pratico e immaginiamo, come riportato nella tabella, che i backlog items siano stati rifiniti con l’aggiunta di story points e grado di priorità durante la cerimonia di backlog refinement, cosa ci aspetta next?
Adesso ci attende lo Sprint Planning, in cui faremo un’attività di calibratura. In base alla capacità del team e alla loro velocity (quanti story points sono stati bruciati negli Sprint successivi) calibreremo la Sprint che sta per iniziare.
Supponiamo che nelle quattro Sprint precedenti il nostro team abbia fatto in media 60 story points, in base alla tabella seguente:
55+65+70+50=240/4=60 -> media di 60 story points per Sprint
Adesso che abbiamo una media (chiamata anche “average velocity”), torniamo alla tabella in cui abbiamo stimato i nostri backlog items e facciamo una somma degli story points:
8+13+13+40=74
Ahi Ahi! Mi sa che una storia non entrerà nello Sprint, dato che eccediamo l’average velocity. Quindi, eliminiamo una storia da 13 story points, magari la storia con ID #100 che ha una priorità 4, quindi bassina, e rifacciamo la somma.
8+13+40=61
Ecco il nostro numero vincente: 61, che eccede di pochissimo la nostra average velocity, ma ci permetterà di avere un’ottima calibrazione dell’effort nella Sprint che sta per iniziare.
Adesso non resta che stabilire uno Sprint Goal. Guardando il nostro backlog, quale potrebbe essere?
“Creare la prima versione di welcome experience (login+home screens) di AppFit”.
Questo goal potrebbe essere il nostro MVP e ci farà capire quanto le nostre assunzioni sul prodotto fossero veritiere o meno.
Una volta, finito lo Sprint Planning e stabilito lo Sprint Goal, si aprono le danze e la Sprint inizia.
Da qui fino alla fine della Sprint, ogni giorno, il team si riunirà per sincronizzarsi e capire quanto si sta avvicinando/allontanando dallo Sprint Goal con il Daily Scrum di cui abbiamo parlato più nello specifico qui.
Nel caso della nostra AppFit, il team avendo stabilito il goal di “Creare la prima versione di welcome experience (login+home screens) di AppFit”, ogni giorno, guardando la board fisica o virtuale, capirà se si stanno facendo passi in avanti verso di esso o se ci sono degli impedimenti, dei roadblocks che non permettono di raggiungerlo.
In base a come va il daily, si avvieranno delle operazioni di mitigazione, spesso con l’aiuto dello Scrum Master, che dovrebbero portare, alla fine dell’iterazione, ad avere un incremento di prodotto da mostrare agli stakeholder del progetto.
Eccoci arrivati alla fine della Sprint! A questo punto gli stakeholders del progetto saranno curiosi di vedere che diavoleria avranno combinato gli sviluppatori!
E’ qui che avviene la Sprint Review o Sprint Demo, dove i bellissimi login e home screen della nostra app saranno mostrati agli stakeholders.
Immedesimiamoci nella situazione e immaginiamo come questo meeting possa svolgersi… lo Scrum Master presenterà il team al nostro gruppo di stakeholders e uno dei programmatori farà uno “show and tell” di queste fantastiche screen.
Uno degli stakeholders farà una piccola osservazione sulla password… “Magari bisogna introdurre dei criteri più stringenti per creare la propria password sull’app: introduzione di numeri, capital letters e special characters”.
Il Product Owner prende nota e informa gli stakeholders che questa funzionalità sarà inserita nel backlog, stimata e prioritizzata nelle Sprint a venire. Ovviamente, terrà tutti aggiornati sull’andamento di queste richieste.
Ecco, un esempio molto semplificato di come una Sprint Review potrebbe andare! Il feedback fornito dagli stakeholders è prezioso e verrà utilizzato per stabilire cosa fare nel prossimo Sprint.
Come ultimissimo meeting della nostra iterazione, ci aspetta la Sprint Retrospective, di cui abbiamo parlato approfonditamente qui nel nostro blog di Product Heroes.
Come andrebbe la retrospective del primo Sprint per AppFit?
Noi l’abbiamo immaginata così!
La parte all’estrema destra della nostra board è molto importante. Indica le azioni che saranno implementate nella prossima Sprint per garantire una cultura di Continuous Improvement.
Attenzione però a non riempire la colonna di destra con 10 azioni a Sprint che di certo non avrete il tempo d’implementare.
Il mio consiglio è di fare una lista e prioritizzarne sempre al massimo due, così non avrete scuse per portarle a termine.
Siamo giunti alla fine di questo lungo viaggio pratico sulla metodologia Agile Scrum!
Un’ultima considerazione generale deve essere fatta prima di chiudere questo capitolo.
Agile è una metodologia fondamentale nell’armamentario di un product manager, ma in quanto metodologia deve essere considerata come uno strumento che può facilitare la crescita e lo sviluppo sano di un prodotto digitale.
Agile non deve essere un approccio da seguire a occhi chiusi, ma deve essere declinato alle esigenze del prodotto in questione e al mercato di riferimento.
Quindi, rimboccatevi le maniche ed esercitatevi a mettere in campo il vostro intuito e il vostro giudizio sempre. Solo così potrete trarre tutti i benefici di questa meravigliosa metodologia, come la chiamo io, “muta-forma”.
Ad Maiora Semper!
Le slide sono disponibili per studenti ed ex studenti del Master in Product Management