Un metodo con il quale il growth hacking può trovare un valido alleato per tutte quelle attività che vanno in parallelo con il processo di sperimentazione è lo Scrum.
Ideato da Jeff Sutherland (qui il suo libro) e Ken Schwaber, lo Scrum è un framework basato sulla metodologia agile utile per lo sviluppo e la gestione di progetti complessi attraverso la pianificazione delle attività in maniera adattiva.
Lo Scrum consiste in un metodo iterativo e in un approccio di miglioramento incrementale che lo posiziona in linea con i principi descritti dal ciclo di feedback, caro alla metodologia lean startup.
La parola “scrum” deriva dal termine che nel rugby indica la configurazione della mischia e in quanto tale rappresenta perciò una metafora sul team che dovrà lavorare come un’unica entità organizzata in modo che possa procedere unita verso una direzione precisa.
I pilastri su cui si basa questo framework sono essenzialmente 3:
- trasparenza
- ispezione
- adattamento
Per trasparenza si intende che c’è uno scambio pressoché totale della conoscenza e delle informazioni tra i componenti del team, garantendo così una visibilità completa sull’andamento delle attività legate al progetto.
Gli elementi principali del processo devono essere noti ai responsabili del risultato finale.
Il concetto di ispezione invece si basa sulla verifica dell’andamento del progetto e dell’avanzamento desiderato verso l’obiettivo finale dettato dalla visione che caratterizza il progetto.
L’utilità di questo modo di operare sta nella capacità di rilevare il prima possibile eventuali deviazioni dalla visione stessa, evitando così sprechi significativi di risorse.
Tali ispezioni devono essere periodiche ma brevi in modo da non condizionare il lavoro svolto dalle persone del team.
Ovviamente questa fase si rivela estremamente efficace se la persona predisposta a tale compito ha le competenze e conoscenze necessarie per farlo.
Infine, una volta individuate le criticità del processo, bisognerà modificare il progetto in modo da rimuovere questi aspetti negativi: ecco che entra in gioco il concetto di adattamento.
Se i risultati intermedi del lavoro del team non sono soddisfacenti o si sta procedendo verso una direzione diversa rispetto a quella prefissata inizialmente, bisognerà adattare il processo in modo che possa rientrare lungo i binari desiderati.
Ricapitolando in poche parole questi 3 concetti:
- la trasparenza permette di avere una visione globale sulla situazione del progetto;
- l’ispezione consente di capire che cosa si sta facendo in un determinato momento e come quell’attività viene svolta;
- l’adattamento consiste nei correttivi che vengono apportati per ottimizzare e sistemare i punti deboli del progetto stesso.
Lo Scrum team
Per applicare correttamente questo framework, bisogna configurare il team secondo un particolare assetto. Lo Scrum team è infatti composto da:
- Product Owner
- Scrum Master
- Team operativo
Il Product Owner è colui che ha la responsabilità sui risultati generati da tutto il team, detta la propria visione del progetto e conosce a fondo le caratteristiche del proprio team per decretare se la visione può essere realizzata così come è stata descritta o se è necessario adattarla alle competenze di chi si occuperà di renderla realtà.
Per questo motivo il Product Owner è l’unico responsabile del product backlog.
Che cos’è il product backlog?
Si tratta concettualmente di un contenitore all’interno del quale vengono inserite tutte le attività da svolgere affinché si possa realizzare la visione finale del progetto.
Come dicevo, il product owner è il responsabile finale del backlog.
Questo comporta che le attività definite nel backlog siano espresse in modo chiaro, inserite secondo l’ordine più congeniale per lo svolgimento e siano “mono-atomiche”, cioè un’attività non dev’essere composta concettualmente da tante sotto-attività (altrimenti bisognerebbe separarle ulteriormente in più attività distinte), in modo che in fase di ispezione sia facilmente comprensibile “chi sta facendo cosa”.
All’interno dell’organizzazione tutti devono rispettare le decisioni del Product Owner affinché il suo lavoro sia il più efficace e proficuo possibile.
Seguire percorsi diversi da quelli dettati dal product owner potrebbe generare disallineamenti tra i componenti del team e compromettere l’andamento delle singole attività.
In definitiva nessuno può dire al team di lavorare seguendo un flusso diverso da ciò che è contenuto nel backlog.
Se il product owner è il responsabile del backlog, lo Scrum Master lo è invece per quanto riguarda l’operatività.
Il suo compito è innanzitutto quello di far rispettare le regole e i principi di questo framework da parte di tutti i componenti del team.
Il suo ruolo da leader è fondamentale per l’applicazione dello Scrum in azienda in quanto deve guidare il team durante lo svolgimento delle attività e risolvere ogni criticità che si presenti lungo il percorso del progetto.
Dunque si tratta anche di un facilitatore perché aiuta il team a comprendere come operare al meglio affinché la visione dettata dal product owner possa tramutarsi in realtà e gestisce tutti gli eventi che caratterizzano lo Scrum in modo che possano essere efficaci e produttivi.
Prima di entrare nel merito di questi eventi, vediamo insieme quali aspetti contraddistinguono il team operativo.
Il team operativo è composto ovviamente da tutti i membri che si occuperanno della parte esecutiva relativa alle attività definite nel backlog.
Generalmente la sua dimensione ottimale varia fra i 3 e i 9 membri a seconda della grandezza dell’organizzazione e della complessità del progetto in questione.
In particolare un team molto piccolo, composto per esempio solo da 2 persone, non consente di organizzare momenti di allineamento in maniera tale da poter arricchire il confronto attraverso punti di vista diversi, dovuti ai background e alle competenze specifiche dei singoli membri.
Oltre a questo aspetto, c’è da considerare anche il fatto che un apporto minore in termini di persone equivale anche a un bagaglio inferiore di know-how e in generale di forza-lavoro, il che significa maggiore difficoltà nello svolgere le attività in tempi rapidi.
Al contrario, un team composto da 10 o più persone può avere i suoi aspetti critici, sebbene la mole di lavoro che può essere effettuato in parallelo sia nettamente maggiore rispetto al caso precedente.
Infatti gestire e coordinare una squadra composta da tante persone richiede una certa capacità da parte del management, per non pensare ai tempi che possono dilatarsi notevolmente durante gli eventi previsti dallo Scrum.
Per quanto riguarda invece gli elementi caratteristici, il team operativo è strutturato in modo tale che possa organizzare il proprio lavoro in piena autonomia e la sinergia che si crea in questo modo tra i suoi componenti porta un innalzamento generale dei livelli di efficacia ed efficienza interna.
Inoltre il team deve essere cross-funzionale in quanto composto da persone con competenze trasversali, sebbene ovviamente con alcune verticali e aree di focus, utili per il raggiungimento degli obiettivi prefissati.
Lo sprint e i suoi eventi
Un aspetto chiave di Scrum è il concetto di sprint.
Gli sprint rappresentano degli archi temporali, generalmente della durata di 7-14 giorni, durante i quali vengono definite un insieme di attività da completare all’interno dello stesso sprint e si sviluppano in modo ciclico uno dopo l’altro.
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
Prima di spiegare le varie tipologie di eventi previsti durante ogni sprint, è importante questa volta introdurre il concetto di Scrum Board, avendo già discusso individualmente di alcuni suoi elementi interni.
La Scrum Board
- Backlog: dove vengono inserite tutte le attività da svolgere per realizzare la visione completa del progetto;
- To do: le attività da svolgere in un determinato periodo;
- Doing: le attività che si stanno svolgendo attualmente;
- Done: le attività completate.
- Backlog;
- un insieme di liste (o colonne) quante sono le giornate che costituiscono lo sprint (per esempio, Lunedì 5, Martedì 6, e così via);
- Doing;
- Check: una colonna dove vengono inserite le task che erano in corso di svolgimento e che necessitano di una revisione da parte di un altro membro del team o dell’intervento da parte di una persona esterna al team, per cui si decide di mettere la task stessa in attesa;
- Done: le task completate durante lo sprint corrente;
- Archived: un archivio di tutte le attività fatte negli sprint precedenti per mantenere così uno storico dei lavori svolti.
Al di là delle colonne Backlog, Doing e Done che hanno la stessa funzione di quelle considerate nella Kanban Board, ce ne sono altre invece che ritengo possano essere comode per il nostro operato.
L’insieme di liste corrispondenti alle giornate dello sprint, come già spiegato, è utile per avere una panoramica generale sulla distribuzione del proprio carico di lavoro durante lo sprint.
La colonna Check serve a immagazzinare tutte le task in attesa del contributo o della revisione di una o più persone diverse da chi se n’è preso l’incarico.
In Archived vengono appunto archiviate tutte le attività fatte prima dello sprint corrente, quindi spostate dalla colonna Done.
Il flusso operativo di base è il seguente.
- Il product owner etichetta tutte le task contenute nel backlog che ritiene debbano essere svolte per perseguire l’obiettivo dello sprint.
- Il team operativo si auto-organizza e assegna le attività da svolgere durante lo sprint corrente ai singoli componenti, i quali inseriranno le medesime attività nelle colonne relative alle varie giornate dello sprint cercando di equilibrare il carico di lavoro di giornata in giornata.
- Durante il giorno X il membro Y del team svolgerà in maniera sequenziale le Z task assegnate in quel giorno, verificherà quindi le task nella colonna del giorno X, inserirà la task Z-N (con N iniziale equivalente a Z-1) nella colonna Doing e svolgerà l’attività.
- Quando non potrà più apportare modifiche o integrazioni al lavoro Z-N, ciò significherà o che la task è stata completamente svolta, e quindi la sposterà in Done, oppure che richiede l’intervento di una persona esterna, e quindi la sposterà in Check. In quest’ultimo caso, una volta che il contributo esterno può considerarsi concluso, il membro Y verificherà il lavoro della task Z-N e se riterrà che il lavoro sia effettivamente stato completato, la sposterà finalmente in Done, altrimenti la manterrà di nuovo in Check, avvisando dell’intervento la persona predisposta per l’ulteriore contributo. Questo ciclo si concluderà quando la task sarà ritenuta completata e spostata una volta per tutte in Done.
- Se N > –1, si ripete dal passo 3 (decrementando di un’unità il valore di N) altrimenti si potrà ritenere conclusa la giornata lavorativa.
Ora che abbiamo chiaro cosa sia la Scrum board e come è strutturata al suo interno, analizziamo insieme i vari eventi che caratterizzano uno sprint.
Lo Sprint Planning
Lo Sprint Planning è una riunione di pianificazione, organizzata all’inizio dello sprint, a cui partecipa tutto lo Scrum team e che dura all’incirca 2 ore per sprint da 1 o 2 settimane.
Durante questo incontro il product owner definisce lo sprint goal, ovvero l’obiettivo principale da raggiungere: quale risultato si vuole ottenere alla fine di questo sprint?
Inoltre farà una selezione delle attività, raccolte inizialmente nel backlog, da svolgere durante lo sprint corrente proprio per poter perseguire l’obiettivo che ci si è prefissati.
Nel caso dello Scrum originale questo set di attività sarebbe inserito nel cosiddetto sprint backlog, un altro tipo di backlog che questa volta è dedicato esclusivamente allo sprint corrente.
Tutte le attività al suo interno rappresentano ciò che deve essere svolto nel periodo associato.
Andremo ad aggiungere le attività all’interno di tante liste quante sono le giornate che compongono lo sprint.
In questo modo cerchiamo di distribuire equamente il carico di lavoro durante i vari giorni dello sprint e di avere una visione iniziale di tale distribuzione.
Una volta fatta questa selezione, il team, facilitato dallo Scrum master, definisce il piano operativo per svolgere i vari compiti connessi allo sprint.
È importante comprendere questo aspetto: è il team operativo a definire e auto-organizzare il proprio lavoro, nessun altro può farlo al posto suo.
Così facendo si garantirà una certa autonomia e libertà di manovra alle persone incaricate a svolgere le attività, minimizzando eventuali frizioni o prese d’incarico da parte di chi è meno competente su una determinata operazione.
Per quanto riguarda la valutazione delle singole task, non si decreta un tempo necessario per il loro svolgimento perché spesso si sbaglia il giudizio, piuttosto personalmente preferisco dare un voto con una scala di valori da 1 a 5 per giudicare la complessità e l’impegno necessario relativo a un’attività specifica.
In questo modo si può tenere come riferimento durante lo sprint un grafico burndown, sul cui asse verticale è rappresentato il punteggio totale delle task che ci siamo posti di svolgere in quel periodo e su quello orizzontale i giorni del periodo stesso.
Si calcolerà il numero dei punti corrispondenti ai lavori fatti durante un giorno specifico e lo si rappresenterà sul grafico, formando così una linea monotona, inclinata verso il basso, che idealmente dovrebbe arrivare a 0 punti in coincidenza con l’ultimo giorno dello sprint, indicando il fatto di aver svolto tutto quello che ci si era prefissati di fare proprio durante lo sprint planning.
Così facendo, avremo sempre la visione sull’andamento generale e soprattutto sulla velocità del team durante ogni singolo sprint, con l’intento di incrementare questa velocità, e quindi il numero complessivo di punti svolti, da uno sprint all’altro.
Il Daily Scrum
Il Daily Scrum è una riunione della durata di circa 15 minuti che viene tenuta ogni giorno allo stesso orario, generalmente proprio prima di iniziare la giornata lavorativa.
Lo scopo di questo breve evento, ricorrente ogni giorno, sta nel sincronizzare i vari membri del team sullo stato complessivo dei lavori e mettere in evidenza gli eventuali ostacoli che si sono rivelati durante lo svolgimento di determinate task.
Questo evento è anche detto stand‐up meeting in quanto solitamente le persone del team si riuniscono in piedi, per dare anche esplicitamente un senso maggiore di rapidità nell’esecuzione dell’evento stesso, e una alla volta interviene rispondendo sinteticamente a queste tre domande chiave:
- “Che cosa ho fatto ieri per aiutare il team a portare a termine lo sprint?”
- “Ho riscontrato alcune criticità durante le attività?”
- “Che cosa farò oggi per aiutare il team a portare a termine lo sprint?”
In questo modo si riesce a valutare i progressi e l’avanzamento verso gli obiettivi dello sprint e a definire insieme come operare sulle future attività.
In tutto questo, il ruolo dello Scrum master è fondamentale per far rispettare le tempistiche di questo evento, che venga effettivamente svolto e presenziato da tutti quanti.
Inoltre, la sua funzione di facilitatore consiste in questo caso anche nel risolvere tutte le criticità emerse durante la conversazione.
È facile comprendere come il Daily Scrum migliori la comunicazione tra i componenti del team e il livello di conoscenza del progetto da parte di tutti.
Concluso questo breve confronto, le persone del team possono ritrovarsi in altri meeting dedicati a risolvere le criticità specifiche, progettare le modalità di esecuzione di una task e discutere di tutti gli altri dettagli fondamentali.
Per evitare sprechi di tempo, questi meeting devono essere contraddistinti da un’agenda precisa degli argomenti di discussione, una durata prefissata e devono prevedere la presenza delle sole persone strettamente necessarie per lo scopo del meeting, anche una sola persona in più aumenta la complessità di gestione del meeting stesso.
Lo Sprint Review
Lo Sprint Review è il primo dei due eventi che vengono tenuti alla fine dello sprint.
Nello specifico questo evento, della durata di circa 1-2 ore per sprint, serve a mostrare al cliente il lavoro svolto dal proprio team, ispezionare quindi tutte le attività fatte e inserite nella colonna Done della Scrum board e modificare, qualora fosse necessario, il backlog, andando a inserire nuove attività utili per fronteggiare eventuali criticità che si sono presentate o intercettare al meglio le richieste del cliente.
Ovviamente se il progetto non prevede un vero e proprio cliente che ha commissionato il lavoro (come generalmente nel caso di startup digitali), si può organizzare un evento che rappresenti a livello funzionale un mix tra questo evento e quello successivo, lo Sprint Retrospective.
Lo Sprint Retrospective
Lo Sprint Retrospective, anch’esso della durata di 1-2 ore, è l’ultimo evento che viene svolto durante uno sprint e rappresenta un’occasione fondamentale per visionare a posteriori l’andamento di tutto lo sprint.
Si discuterà quindi dei vari pro e contro dello sprint stesso per poter definire un piano di miglioramento da attuare nello sprint successivo.
Durante questo confronto si cercherà di individuare tutte le problematiche che sono emerse durante lo svolgimento delle task, senza però voler fare una “caccia alle streghe” alla ricerca di eventuali responsabili.
La logica di Scrum è basata sul lavoro di gruppo dove tutti sono responsabili dell’andamento del processo e le problematiche devono essere risolte insieme.
Individuare gli eventuali colpevoli davanti a tutti può avere solo effetti negativi: si genererà disagio, frizioni tra le persone e un senso di frustrazione generale nel team.
Piuttosto se ci sono problemi con una persona specifica, meglio parlarne a quattrocchi e trovare insieme le possibili soluzioni.
Se le problematiche continuano a persistere, bisogna capire se sia il caso di valutare l’uscita del professionista in quanto non in linea col progetto.
Lo Sprint Retrospective è anche un’ottima opportunità per dare e accettare feedback costruttivi con l’intento di far crescere l’intero gruppo in termini di sinergia tra le persone e di conoscenze specifiche su una determinata area professionale.
In definitiva l’output che ci si aspetta di generare da questo evento è il cosiddetto “kaizen”, termine che in giapponese significa miglioramento.
Ergo, quale miglioramento dell’intero processo ci aspettiamo di vedere durante lo sprint successivo?
IL LIBRO SUL GROWTH HACKING
Vuoi saperne di più di lean startup, growth hacking e delle varie strategie su tutte le fasi del funnel? Approfondisci con il mio libro “Growth Hacking – Strategie e strumenti per far crescere startup e PMI”!