Metodologia Agile Scrum – Un esempio pratico

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:

1. Tecnica Lean UX e Organizzazione del team
2. Il lavoro inteso come problemi da risolvere nella metodologia Agile Scrum
3. Lean UX Canvas e i grandi 4
4. Problem statement 
5. La Proto-persona nella metodologia Agile Scrum
6. Ciclo “Agile Scrum”
7. La strategia per un Agile Scrum di successo: esercita il giudizio!
   

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.

Se hai già accesso alla cartella troverai direttamente lì il post in PDF.

Tecnica Lean UX e Organizzazione del team

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:

• UX: User Experience
• Design Thinking: sessioni di design che coinvolgono l’intero team
• Agile Scrum (di cui abbiamo parlato abbondantemente qui)
• Lean Startup (metodologia basata sui principi del “Crea-Misura-Impara” e la pratica del Minimum Viable Product)

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:

• Cross-functional: deve contenere al suo interno persone con diverse competenze ma che lavorano in maniera indipendente perché al suo interno hanno tutto quello di cui hanno bisogno.
• Small, dedicated, co-located (può anche essere remote): il team deve essere dedicato al progetto full-time, le mezze misure non vanno mai bene!
• Self sufficient and empowered: questo gruppo di persone deve avere il potere di prendere delle decisioni da sé.
• Problem-focused: l’obiettivo che abbiamo è quello di risolvere un problema, un need in crescita, perciò il focus principale è sviscerare il problema.
• Heterogeneous, all’interno del nostro team è consigliabile avere expertise molto eterogenee:
  • Product Owner/Product Manager (proveniente dall’area business),
  • Scrum Master/Agile Coach (capace di facilitare workshop session altamente collaborative),
  • Business Analyst (capace di analizzare i flussi e individuarne le criticità),
  • Programmatori che abbiano anche competenze UX,
  • Product Designers con competenze in UX, UI, Market research.

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?

Il lavoro inteso come problemi da risolvere nella metodologia Agile Scrum

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:

• Chi è il nostro cliente e quindi il nostro target di riferimento?
• Quale problema vogliamo risolvere con AppFit?
• Quali sono le features o i set di features che avvicineranno i nostri clienti ai loro obiettivi?

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?

1. Si incoraggia la creatività, l’esplorazione di nuovi orizzonti e la product discovery.
2. Le priorità del team si concentrano attorno al problem solving e non alla creazione di features.
3. Forza il team a pensare agli outcomes che vogliamo raggiungere (ovvero come si sentiranno i nostri users utilizzando l’app?)

Lean UX Canvas e i grandi 4

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:

1. Il problema di business da risolvere
2. Gli outcomes che volete raggiungere
3. Gli users
4. Gli outcomes degli users e i benefici che vogliono ottenere
5. Le soluzioni
6. Le ipotesi
7. Qual è la cosa più importante che dobbiamo imparare per prima? Il concetto di Minimum Viable Product.
8. Qual è il minimo sforzo che dobbiamo fare per imparare la cosa più importante?

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:

• Business outcomes 

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.

• Users o Personas: per chi stiamo risolvendo un problema?

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.

• User outcomes: quali sono gli obiettivi di questi user?

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.

• Features: i cambiamenti di prodotto che aiuteranno i clienti ad avvicinarsi ai loro goal.

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!

Problem statement 

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.

Adesso proviamo a declinare il template, aggiungendo le nostre ipotesi in modo da comporre il nostro statement.

Ecco qui il nostro problem statement! Adesso, strutturiamo un po’ meglio le nostre “Personas”.

La Proto-personas nella metodologia Agile Scrum

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:

Inizio del Ciclo “Agile Scrum”

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.

La strategia per un Agile Scrum di successo: Esercita il giudizio!

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!