Settembre 28, 2020 - di Marco Imperato
Agile Scrum: la metodologia, cosa è, e a cosa serve
In questo post ti guiderò attraverso la metodologia più diffusa e usata di Agile, ovvero Agile Scrum. Ne abbiamo già parlato abbondantemente su Product Heroes affrontando il Mindset, i Principi, esplorando alternative possibili e avventurandoci nei vari rituali.
Adesso però, sentiamo il bisogno di unire tutto ciò di cui abbiamo parlato in una guida unica che possa essere di riferimento per chi si sta approcciando a questa metodologia per la prima volta.
Alcuni argomenti li abbiamo già affrontati su Product Heroes quindi alcuni paragrafi saranno delle brevi descrizioni che poi rimandando ai rispettivi post specifici di approfondimento.
Questo post è stato scritto a quattro mani, insieme a Giulia Tumminelli, Product Owner e cintura nera di Agile, ed è il primo di una serie di due post che verranno pubblicati sulla Metodologia Agile Scrum.
Oggi vedrai il processo completo dal punto di vista teorico, mentre nel post successivo affronteremo un esempio concreto e pratico a beneficio di chi sta partendo da zero e vuole implementare Scrum per la prima volta.
Per non perderti il prossimo post ti consiglio di iscriverti alla Newsletter.
Ecco cosa troverai
- Definizione di Agile
- Le Metodologie Agile
- Mindset vs Metodologia Agile
- La Metodologia Agile Scrum: Overview
- Agile Scrum: i concetti base
- Agile Scrum: Focus sui Rituali
- Organizzazione in Agile Scrum
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.
Definizione di Agile
A differenza di quanto si crede Agile non è una metodologia.
Agile è un insieme di principi e valori contenuti nel Manifesto Agile creato per la prima volta nel 2001.
Ci si rese conto che il modo in cui si sviluppava Software fino a quel momento era inadatto alle esigenze che stavano cambiando con i tempi, così un gruppo di sviluppatori ed esperti del settore si riunirono per capire come e cosa si poteva migliorare.
Nasce così il Manifesto Agile che contiene i quattro valori e i dodici principi fondamentali di Agile. Se ti interessa approfondire puoi farlo da questo articolo che abbiamo scritto per raccontare come è nato Agile e perchè importante.
Sintetizzando al massimo: fino a quel momento tutta l’attenzione nel processo tradizionale di sviluppo software, chiamato Waterfall, era stata posta su documentazione, processi e specifiche tecniche, adesso la lente si spostava sulle persone e sulle interazione tra di esse, sui team e sul loro spirito di adattamento e risposta al cambiamento.
Le Metodologie Agile
Questi principi e valori piacquero così tanto che si decise di organizzare il lavoro sulla base di essi.
Agile però non bastava. Era ancora troppo astratto.
Così nacquero delle metodologie organizzative (anche chiamati framework). Alcune individuavano nel tempo, l’elemento più importante e attorno al quale fa ruotare l’intera metodologia, come Scrum, altre invece ritenevano lo scope fosse l’elemento più importante, come Kanban.
Se ci pensi, già avere la consapevolezza che non ci si poteva focalizzare su entrambi contemporaneamente vista la capacità (sempre) limitata di un team, fu una grande rivoluzione.
In questo post parleremo solo della metodologia Agile Scrum, se vuoi un assaggio di Kanban e vuoi approfondire le differenze principali tra Scrum e Kanban puoi leggere questo post che abbiamo scritto in passato sulle metodologie agile Scrum e Kanban.
Il Mindset Agile vince sempre sulla Metodologia
Prima di addentrarci nel mondo di Agile Scrum, è doverosa una precisazione: anche se impari a memoria i 5 rituali, i 4 valori, i 12 principi e le migliaia di pagine che troverai in rete sulla metodologia, ma non pensi in modo Agile non riuscirai mai a sfruttare il grande cambiamento che Agile ha portato.
Dal mio punto di vista il Mindset è la cosa più importante, tutto il resto lo impari.
Qui di seguito ti riassumo quali sono i punti chiave:
- Accettare l’incertezza e tutto ciò che ne deriva
- Il fallimento è la via più sicura per imparare
- Se non lo misuri non lo sai
- Fiducia nelle persone e nella loro capacità di avere impatto
- Own your Outcome: assumersi la responsabilità a tutti i livelli
So che in questo momento potranno sembrarti parole buttate a caso, mentre tu vuoi solo sapere come si “Pesano le storie”, ma credimi che senza un Mindset Agile starai solo imparando una nuova metodologia di Project Management.
Puoi approfondire questa parte su un post che abbiamo dedicato per intero al Mindset Agile.
Metodologia Agile Scrum: una visione d’insieme
Prima di addentrarci nei dettagli del Framework è necessario avere una visione d’insieme, a partire dal significato della parola Scrum.
Il significato di Scrum
Nel rugby, la parola “Scrum“ è un termine usato per spiegare il goal del team di ottenere il possesso della palla in quanto unità molto coesa. In maniera simile, in Agile Scrum, il team di sviluppo lavora insieme per raggiungere uno o più obiettivi alla fine dello Sprint/iterazione.
Ma Agile Scrum non è solo questo, è molto di più.
Cosa è Agile Scrum
Agile Scrum è a tutti gli effetti un sistema di regole, procedure e rituali ben definiti su come applicare la metodologia Agile, dove, come ho detto qualche riga prima, il tempo è l’elemento più importante.
A scandire il tempo in Agile Scrum ci pensano gli Sprint, dei piccoli time-frame in cui il team di sviluppo lavora per il rilascio di una o più funzionalità.
Per semplificare ancora: invece di sviluppare un progetto in “un’unica tirata” che dura 12 settimane, il progetto viene suddiviso in 6 piccoli “pezzi di tempo” che durano 2 settimane, questo pezzo di tempo viene chiamato Sprint.
La cosa interessante è che ogni Sprint ha un obiettivo di per sé e già da subito il rilascio derivante dal lavoro svolto in una sprint deve dare valore all’utente che usa il tuo prodotto. Non si tratta quindi soltanto di suddividere un lavoro grande in pezzi più piccoli, ma di un nuovo sostanziale approccio allo sviluppo software che mette l’utente finale al centro e cerca di “stargli il più vicino possibile” senza impiegare mesi prima di arrivare a dare qualcosa di valore all’utente stesso.
Overview delle fasi e dei tempi in Agile Scrum
Prima di andare nei dettagli dei rituali e dei ruoli provo a darti una visione d’insieme. Se trovi qualche parola che non conosci o non comprendi non ti preoccupare, man mano che andrai avanti ti sarà tutto più chiaro.
Lo Sprint inizia con lo Sprint Planning dove il Product Owner prioritizza il Product Backlog ed insieme al team crea lo Sprint Goal, ovvero l’obiettivo da raggiungere per la Sprint in partenza. Da questo momento in poi inizia il ciclo di sviluppo che è raffigurato qui sotto di cui parleremo più approfonditamente man mano.
In Agile Scrum una delle parti fondamentali risiede nel feedback da parte degli stakeholder che partecipano alla Sprint Review, un meeting che avviene alla fine di ogni sprint.
Immagina la preparazione ad un concerto di un’orchestra sinfonica:
Dopo giorni di pratica ed esercizi, arriva il momento cruciale in cui l’orchestra si confronta col pubblico e capisce se tutta la preparazione, le lunghe ore passate a provare, soddisferanno la voglia del pubblico di svagarsi e di partecipare ad un evento unico.
Ecco, la Sprint Review è un meeting di confronto con la realtà, a volte piacevole, a volte spietata, perché non sai mai se tutto ciò che è stato fatto soddisferà le esigenze del pubblico.
Durante questo meeting, le nuove funzionalità di prodotto saranno mostrate ai clienti o ai vari stakeholders del progetto che avranno l’opportunità di dire la loro e di capire insieme su cosa si potrebbe lavorare next.
È qui che il Backlog viene messo in discussione. Nel caso in cui l’incremento di prodotto mostrato abbia necessità di miglioramenti, le user story relative agli improvement saranno organizzate di conseguenza e prioritizzate per il prossimo Sprint.
È un’occasione imperdibile per pivotare le idee più rischiose e metterle lì fuori con il meno sforzo possibile, dato che le iterazioni sono di breve durata!
Il succo sta proprio in questo in Agile Scrum, utilizzare le iterazioni come esperimenti a basso rischio per mettere un nuovo prodotto o una nuova funzionalità sul mercato e capirne la percezione del pubblico.
Se le cose vanno male, pazienza! Avrai sprecato solo due settimane, invece di mesi di analisi, progettazione, e rilascio, e avrai imparato delle lezioni importanti da inglobare nel prossimo esperimento.
Questo è l’elemento che fa la differenza: Agile Scrum prevede sin da subito la possibilità di sbagliarsi. Il miglioramento non è raggiunto tramite un unico grande rilascio, ma attraverso vari cicli di iterazione (le sprint). Quando stai innovando non sai cosa funzionerà, quindi tanto vale non impiegare mesi per scoprirlo!
Agile Scrum: i concetti base
Prima ancora di avventurarci nelle singole fasi di Agile Scrum ci sono alcuni concetti fondamentali che è meglio conoscere.
Lo sprint in Agile Scrum
Anche chiamato “iterazione” è un lasso di tempo che può variare da uno a quattro settimane dove il team si adopera per creare un “incremento”, un prodotto/funzionalità, anche non finito, che crea valore e che può essere ispezionato alla fine, ricevendo feedback positivi/negativi dagli stakeholders interessati.
Nello Sprint si usa il concetto di time-box, dove all’inizio del progetto si decide quanto l’iterazione debba essere lunga (da una a quattro settimane, non di più). Una volta decisa la durata, non deve essere cambiata, perché può essere controproducente per la produttività del team, che mano a mano troverà il suo cosiddetto “heartbit”.
Il Product Backlog
Il backlog è la lista di user stories o task che non è ancora stata introdotta nello Sprint e risiede in uno spazio apposito. Considerala come una wishlist di funzionalità che potrebbero essere implementate e che saranno prioritizzate dal product owner durante lo Sprint Planning.
Se ancora non hai dimestichezza con il Product Backlog abbiamo scritto un post dedicato: Product Backlog, significato, esempio e template.
User Story
Come avrai letto nell’approfondimento, Il Product Backlog è composto principalmente da User Story.
La User Story è la funzionalità o l’incremento di prodotto che si vuole portare in sviluppo scritta dal punto di vista dell’utente.
Ogni User Story incorpora al suo interno CHI beneficerà di quella funzionalità, COSA si richiede e PERCHÈ è importante per l’utente
Se ancora non hai dimestichezza con le User Story puoi leggere il post scritto da Giuseppe: Cosa sono le User Story e come si scrivono
La Velocity in Agile Scrum
Come avrai capito Agile Scrum ruota tutto intorno al tempo e quando si ha il tempo come riferimento chi ha il maggior vantaggio?
Di solito chi va più veloce.
Man mano che passano le sprint il team di lavoro acquisirà il proprio ritmo, “heartbit” o velocità.
La Velocity è la somma degli story point completati a fine sprint. Questa servirà da metro di paragone per pianificare gli Sprint successivi.
Facendo un passo indietro infatti ogni User Story prima di essere portata in sviluppo deve essere analizzata e ne deve essere valutato il peso in termini di impegno del team.
Es: una User Story che pesa poco impegna solo alcuni membri del team (anche uno solo) per poco tempo, una Storia che pesa molto impegna tanti membri del team per tanto tempo.
Solo dopo aver dato un valore ad una User Story usando appunto gli Story Points, questa può essere aggiunta allo Sprint Backlog.
Agile Scrum: I rituali
Come avrai capito finora Agile Scrum è una metodologia fatta di tempi, ritmo e rituali. Ogni rituale ha un obiettivo specifico.
Daily Scrum: allineamento giornaliero
Sprint Planning: preparazione della Sprint
Estimation: stimare il peso di ogni user story
Sprint Review: demo e review del lavoro svolto
Sprint Retrospective: migliorare il modo in cui si lavora insieme.
1. Il Daily Scrum
In breve, il daily scrum è un meeting giornaliero dove il team si riunisce e raccoglie le proprie impressioni su come sta andando lo Sprint e quanto ci si sta avvicinando o allontanando dallo Sprint goal. Ogni membro deve rispondere a tre domande ben precise:
- Cosa ho fatto ieri?
- Cosa ho fatto oggi?
- Ci sono impedimenti che stanno bloccando il mio percorso nel raggiungere lo Sprint Goal?
Anche in questo caso abbiamo già scritto un post dedicato al Daily Scrum e ai consigli principali per farlo al meglio.
2. Sprint Planning
Lo Sprint Planning è forse uno dei meeting più importanti nelle cerimonie Agile ed è il momento in cui business (product owner) e technical team si riuniscono per decidere cosa faranno nella prossima iterazione/sprint.
Di solito dura circa 4 ore ed avviene il giorno prima dell’avvio della sprint.
L’obiettivo dello Sprint Planning è proprio quello di pianificare la Sprint definendo l’Outcome (L’obiettivo di sprint) e passando dalle user story alle singole task per ciascun componente del team.
Anche in questo caso abbiamo scritto un articolo dedicato. Puoi approfondire da qui: Sprint Planning, la guida completa.
3. Estimation in Agile Scrum
Ne abbiamo parlato sopra a proposito degli Story Point.
La cosiddetta stima dell’effort è un concetto fondamentale, specie nel Backlog Refinement e in Sprint Planning dove il team di sviluppo si riunisce per dare un valore numerico alle user stories.
Questo aspetto non è assolutamente da sottovalutare, perché dalla stima delle user story possono scaturire tantissime discussioni interessanti per capire effettivamente il grado di rischio, complessità, fattibilità di ciascun task.
L’estimation a differenza degli altri rituali non ha una sua precisa collocazione, può essere fatto in qualsiasi momento, ma considera che il Team dovrebbe dedicare al meno il 10% del suo tempo alla stima del lavoro necessario per sviluppare una User Story.
Se vuoi approfondire abbiamo scritto un post dedicato: Estimation in Agile Scrum.
4. Sprint Review
È qui che finalmente si raccolgono i frutti di quel che è stato fatto.
L’incremento, ovvero la somma delle funzionalità che si sono sviluppate durante lo sprint vengono finalmente mostrate al cliente e ai più importanti stakeholders del progetto. Qui si riceve il feedback che porterà a decidere quale corso il prodotto deve prendere e quali user story saranno prioritizzate nel prossimo sprint.
La Sprint Review non è solo una Demo, ma è l’elemento di raccordo con la Sprint precedente: un incontro fondamentale su cui costruire la cultura, creare prodotti migliori e rinforzare la fiducia del team.
Queste sono alcune delle attività:
- Definire cosa è stato completato e cosa no, commentando il lavoro.
- Demo individuali
- Rivedere impatto delle feature su Metriche Chiave
- Verifica User Story e aggiunta nuove per completare
- Backlog Grooming
Approfondiremo sicuramente la Sprint Review in un post dedicato, ma quello che possiamo darti come consiglio principale è di evitare che la Sprint Review, vista la presenza degli stakeholder principali, diventi un meeting di negoziazione e definizione del dettaglio della prossima sprint!
5. Sprint Retrospective
La retrospective viene spesso sottovalutata, invece dovrebbe essere la top priority per il team. È un momento di ispezione per tutti, per i processi, per le persone e per il modo in cui si lavora. Qui si ispeziona quel che è stato fatto chiedendosi:
- Cosa è andato bene?
- Cosa potrebbe andare meglio?
- Quali sono gli improvement / miglioramenti che si possono implementare nel prossimo Sprint?
Se vuoi approfondire la Retrospective puoi farlo da questo post: La restrospective nella metodologia Agile Scrum.
Organizzazione in Agile Scrum
Uno dei cambiamenti decisivi che ha introdotto Agile Scrum è la responsabilità di Team. Non si tratta più di lavorare in compartimenti stagni o in classici team funzionali.
L?immagine di sotto è una semplice, ma utile, rappresentazione di come i diversi attori coinvolti ci sia aspetta che lavorino insieme (Abbiamo usato la Matrice Raci).
Il Team Cross-funzionale
Il team cross- funzionale è un team che prevede la stretta collaborazione tra figure appartenenti a diverse funzioni.
Le skills/conoscenze individuali devono essere trasferite al team tramite peer programming (sviluppo di una funzionalità a due mani) o mob programming (sviluppo a più mani).
Questo porterà il team nel lungo periodo ad essere molto più efficiente, dato che ogni membro del team avrà come bagaglio la conoscenza del prodotto e del software utilizzato e potrà essere intercambiabile.
Tipicamente un team cross funzionale è composto da Product Manager, Design, Sviluppo, Data Analyst.
Se vuoi approfondire abbiamo chiesto ad alcuni Product Leader come sono organizzati all’interno del proprio team e abbiamo sintetizzato le risposte nel post: Come organizzare il team di Prodotto.
Il Product Owner
In questo caso siamo di parte, ma oggettivamente il Product Owner è una delle figure fondamentali del team.
È colui/colei che guida il team nella giusta direzione, che prioritizza le user storiy e come un direttore d’orchestra si interfaccia con gli stakeholders e col team per far in modo che tutto funzioni alla perfezione.
Non sempre il ruolo di product Owner coincide con quello di product manager. Anche in questo caso esistono diverse configurazioni. Abbiamo chiesto un’opinione in merito ad alcuni product manager delle più note aziende tech italiane ed europee. Se vuoi approfondire ti consiglio di leggere il post di seguito: Product Manager e Product Owner, qual è la differenza
Lo Scrum Master
In alcuni casi viene anche chiamato Agile Coach. Lo Scrum Master è colui/colei che si adopera per far si che il team raggiunga la massima produttività ed efficienza. È il facilitatore di tutte le cerimonie Agile tramite tecniche di negoziazione e mediazione.
È anche la voce del team di sviluppo. Chi promuove la metodologia Scrum e fa sì che i suoi principi/valori vengano applicati in maniera corretta tramite un durissimo lavoro di coaching e mentoring.
Lo scrum master si occupa anche delle metriche di avanzamento per fare venire a galla i problemi, ma anche i successi del team.
In sostanza è un trascinatore, un servant leader che permette al team di dare il meglio e di realizzare la visione di prodotto del product owner con un forte focus sulla qualità.
Alla fine quel che conta veramente non è ottenere un prodotto di qualità e che soddisfi le esigenze del pubblico? Ecco, lo Scrum Master è quello che rende questo possibile, non con una bacchetta magica ma con duro lavoro!
Alla fine di questo post ci aspettiamo che tu sia abbastanza confuso: eccitato per tutte le parole nuove che avrai imparato, ma completamente nel pallone per come effettivamente debba funzionare la macchina.
Sappiamo come ti senti. Questo è il motivo per cui a breve pubblicheremo un esempio completo di come potrebbe funzionare l’organizzazione in Agile Scrum partendo da zero. Iscriviti alla Newsletter per non perdertelo e scrivi nei commenti eventuali dubbi, idee, richieste di chiarimenti.
