Archivi categoria: Scrum

LeSS (Large-Scale Scrum): 15 domande a Craig Larman

Questa settimana ho partecipato ad un Meetup con Craig Larman, uno dei pionieri nell’applicazione di Scrum in contesti allargati.
Larman era a Milano dal 4 al 6 Luglio per il suo corso di Certified LeSS Practitioner.
Durante l’incontro i partecipanti hanno avuto l’occasione di approfondire dubbi e questioni direttamente con l’autore di “Scaling Lean & Agile Development“.
Questa è una sintesi delle domande emerse nel corso della serata.

Cosa significa essere agili?

Significa essere flessibili, adattarsi al cambiamento.
Non a caso quando queste pratiche sono nate erano due le parole in lizza per descrivere il framework: agile e adaptive ed entrambe sottolineano questo concetto.
Diciamo infatti “essere agili” piuttosto che “fare Agile”.
Essere agili significa mettere da parte l’arroganza di conoscere e abbracciare l’umiltà dell’imparare.

Quali sono gli elementi caratteristici di LeSS?

LeSS prevede 3 ruoli: il Product Owner, responsabile di massimizzare il valore prodotto; da 2 a 8 team che hanno il compito di realizzare l’incremento di prodotto potenzialmente rilasciabile e gli Scrum Master ad agevolare il processo (di norma 1 Scrum Master ogni 3 team).
In LeSS esiste un unico Product Backlog per il prodotto.
Per quanto riguarda gli Sprint Backlog invece ogni Team ha il proprio che viene stabilito nel corso dello Sprint Planning.
LeSS prevede gli stessi eventi di Scrum, ma li declina diversamente per la presenza di più team.

Quanti sono i framework LeSS?

Large-Scale Scrum prevede 2 framework: LeSS e LeSS Huge
Il primo si applica a situazioni in cui è presente un Product Owner, 1 product backlog e da 2 a 8 team di sviluppo che lavorano sul medesimo prodotto.
LeSS Huge si applica in contesti ancora più ampi, dove un singolo Product Owner avrebbe difficoltà ad avere una visione complessiva dell’intero prodotto.

Ci sono delle pre-condizioni per adottare LeSS?

LeSS non è un framework che si presta ad essere adottato bottom-up; deve essere introdotto dall’alto, al senior level.
Necessita la presenza di un management evoluto perché richiede un profondo cambiamento del sistema. Stiamo parlando di eliminare tutti i component team, così come i progetti e i programmi.

Può essere utilizzato in realtà multi-site?

LeSS è stato implementato in molte realtà con persone che lavorano su diverse sedi.
Ma c’è un vincolo: all’interno di un singolo team le persone devono essere co-locate, non disperse. I diversi team possono invece essere sparsi su più sedi geografiche.

Come posso convincere il management ad adottare LeSS?

Non puoi convincerli. Non funziona la dinamica di convinzione.
Sono loro che devono arrivare a sentire davvero l’urgenza del cambiamento, perché le dinamiche di resistenza al cambiamento sono molto forti nelle organizzazioni.
L’idea di fondo è che le persone debbano arrivare a fare propria un’idea (own), invece che accoglierla da altri (rent).
Nel momento in cui la convinzione è una dinamica interna solo allora si crea davvero la possibilità per un cambio radicale.
Molte aziende hanno troppi soldi” dice Larman, quindi si possono permettere tante modalità disfunzionali e non hanno questo senso di urgenza. Mettono in atto solo “fake changes”.

Non c’è proprio nulla che posso fare per agevolare questo cambiamento?

Ciò che si può fare è cominciare a creare interesse e curiosità intorno a questo argomento.
Le possibilità sono tante: far circolare dei libri che trattano di LeSS presso persone chiave in azienda, inviare video, trovare degli sponsor interni all’organizzazione, crearsi degli alleati in questo percorso, promuovere eventi e incontri con esperti esterni all’azienda.

Come avviene lo Sprint Planning?

Lo sprint planning è diviso in due parti.

Nella prima parte sono presenti il PO ed i rappresentanti dei diversi team (è bene che ruotino da un planning all’altro).
Questa prima parte dura massimo 2 ore per uno sprint di 2 settimane, ma spesso si conclude in meno di un’ora.
In questa fase il PO presenta le user stories in ordine di priorità, viene definito lo Sprint Goal ed i rappresentanti dei team selezionano le attività sulle quali lavoreranno.

Nella seconda parte sono di fatto i team ad organizzarsi e più tavoli di discussione possono essere portati avanti in parallelo. In questo momento ogni team elabora il proprio piano per produrre l’incremento di prodotto. Il PO può chiarire eventuali dubbi in questo momento.

Come vengono assegnate le user stories ai vari team?

Le user stories non vengono “assegnate”.
In Scrum trattiamo le persone come adulti.
Sono i team ad auto-organizzarsi e a scegliere le storie da realizzare per poter produrre un incremento.

Che cosa si intende per integrazione continua?

Non parlo tanto di continuous integration ma di integrate continuously.
L’integrazione continua non è una questione di strumenti e tool, riguarda il comportamento e la forma mentis degli sviluppatori.

Si basa su 3 pratiche:

  • effettuare check in e check out del codice con cicli il più corti possibile (stiamo parlando di qualche minuto!);
  • evitare l’utilizzo di branches (tutti i team lavorano sul master);
  • utilizzare un sistema di continuous integration sempre attivo e dove i test girano continuamente.

Come è opportuno procedere quando non si hanno le idee chiare su quale architettura adottare?

In questi casi è bene utilizzare un processo di Agile Modeling in cui i diversi team si trovano assieme ed elaborano idee al fine di individuare la migliore soluzione al problema.
Vengono fatti sketches dell’architettura. Si tratta di prendere decisioni partecipate.

In fase di implementazione tuttavia solo uno dei team parte ad abbozzare la soluzione condivisa (è una questione di focus). Può così verificare se si tratta di un’idea valida o se è necessario apportare delle correzioni piuttosto che riconsiderare il tutto.

Le emerging architecture non funzionano bene in contesti large scale.

Ma in pratica per iniziare ad adottare LeSS come è bene partire?

All’inizio è bene evitare di avere un gruppo troppo piccolo (ad esempio 2 soli team) o troppo numeroso. Nel primo caso il test non è rappresentativo, nel secondo il livello di difficoltà è eccessivo.

Partite con questo set:

  • 50 persone circa
  • 1 solo prodotto
  • 1 unica sede
  • per un periodo di 6 mesi

E’ fondamentale costruire un’esperienza di successo, perché il codice funzionante è molto più convincente di qualsiasi power point. In questo modo (e solo in questo) si guadagna credibilità all’interno dell’organizzazione.

Come sono organizzati i team in relazione ai prodotti?

Da questo punto di vista LeSS è perfettamente in linea con Scrum.
Scrum è un modello product-centric.
I team devono essere disaccoppiati dal codice ma in relazione stabile con i prodotti.
Più team lavorano sempre su un determinato prodotto.
Quando l’organizzazione non è strutturata in questo modo non sto adottando un framework Agile, sto semplicemente tentando di migliorare l’efficienza nella gestione dei progetti.

Qual è il ruolo del Product Owner in LeSS?

Il ruolo del Product Owner in LeSS non cambia rispetto a Scrum e ai contesti non scalati.
Il PO è colui che gestisce il prodotto soddisfando i bisogni degli utenti finali, colui che comunica al team gli obiettivi e la vision di alto livello.
Il PO non è un Business Analyst; è un imprenditore, un innovatore, un pensatore a livello sistemico, di fatto un “mini CEO”.
In LeSS è previsto che un Product Owner possa gestire sino a 8 team (con il supporto di alcuni Scrum Master), per un totale di oltre 50 sviluppatori. Questo significa necessariamente adottare un modello di product ownership “diffusa”, dove i membri del team hanno un’elevata conoscenza del dominio e grande maturità professionale.

Quanto è grande un prodotto in LeSS?

La grandezza del prodotto dipende da diversi fattori: il numero di prodotti che un’azienda gestisce e la loro ampiezza.
Per intenderci Microsoft Word è un prodotto, un prodotto ancora più grande è MS Office.
Ad ogni prodotto corrisponde un product backlog e diversi team lavorano continuativamente sul medesimo prodotto.
Più l’azienda segmenta il prodotto e maggiore è la possibilità che diminuisca il valore delle singole user stories lavorate. Sta ottimizzando “localmente”, ma non a livello sistemico.
Per produrre maggior valore è bene avere prodotti di ampio respiro, più grandi e non più piccoli.

Lift-off di progetto: uno strumento potente per creare comprensione comune

Che cos’è e a cosa serve il lift-off di progetto

Il lift-off è una pratica che ha 3 obiettivi principali:

  • dare forma al progetto e definirne chiaramente lo scopo (purpose)
  • creare allineamento tra le persone interessate dal progetto (alignment)
  • chiarire il contesto più ampio in cui il progetto si inserisce ed eventuali vincoli (context)

Generalmente il lift-off è un workshop che viene effettuato all’inizio di un progetto o anche in fase di avanzamento qualora uno dei tre elementi indicati sopra (obiettivi, allineamento e contesto) venga a mancare in corso d’opera.
Ad esempio potreste accorgervi di alcune perplessità durante i grooming del team…

Perché lift-off?

Il termine inglese lift-off indica il decollo.
Di fatto rappresenta una metafora dell’avvio di progetto.
E’ il momento in cui tanti aspetti devono essere coordinati a livello di sistema per garantire la riuscita dell’operazione.
Si sale tutti in aereo diretti nella medesima direzione.
Rispetto al più noto “kick-off” di progetto, il termine lift-off sottolinea il concetto che l’inizio del progetto è una fase collegiale, non individuale e che è fondamentale creare sintonia tra tutti i partecipanti.

Quanto dura?

Non esiste una regola fissa.
Il lift-off dura quanto serve e dipende dall’entità del progetto, dal grado di conoscenza del team e dai rischi.
Diciamo che la durata minima corrisponde a mezza giornata (è il tempo necessario per attraversare tutti gli step del workshop) ma in alcuni casi il meeting può essere esteso anche a una settimana.

Chi partecipa al lift-off di progetto

Ovviamente la composizione dei partecipanti può variare a seconda del tipo di progetto e quando viene fatto, ma in generale è utile mettere insieme tutti coloro che sono essenziali per il suo successo.
E’ particolarmente utile avere una composizione d’aula variegata: il business owner, il team, product managers, business analyst, in generale la comunità di progetto e – se possibile – i clienti stessi.
Avere nel lift-off solo le persone appartenenti al proprio team non vi consentirà di sfruttare a pieno la potenza di questo strumento.

Cosa preparare prima del meeting

Una serie di materiali fungeranno da supporto e da information radiator nel corso dell’incontro. Per questo motivo è opportuno che siano preparati prima dell’inizio. Possono essere lavagne o fogli di grandi dimensioni in cui andremo a raccogliere i post-it prodotti dai partecipanti.

Questi “contenitori” che vengono predisposti dal facilitatore verranno svelati mano a mano che il lift-off procede e riguardano i 3 aspetti principali sui quali verte l’incontro:
– il perché del progetto
– il cosa del progetto
– il contesto in cui il progetto si inserisce

Ovviamente devono poi essere disponibili tutti gli strumenti necessari per il lavoro: penne, post-it e generi di conforto vari per le pause.
La scelta della logistica è un aspetto importante di questo processo.

Come iniziare

E’ opportuno che l’incontro sia condotto da un facilitatore, possibilmente esterno al progetto.
All’inizio il facilitatore illustrerà ai partecipanti che cos’è la pratica del lift-off e quali benefici offre.
Ribadirà inoltre alcune regole (ad. esempio evitare l’uso di cellulari e laptop, scrivere sui post-it dubbie e domande, ecc.).
Non c’è un modo che va bene o no. E’ però importante che i partecipanti capiscano che il valore di questo meeting sta nel mettere a fattor comune i diversi punti di vista e farli dialogare; i post-it non sono altro che “gettoni di discussione”.

Come si svolge l’incontro

Non esistono delle regole fisse in questo senso e possono essere vari gli strumenti utilizzati nel lift-off.
Io vi racconto un format articolato in 4 fasi, che mi sembra particolarmente efficace.

1. Individuare lo SCOPO

Ai partecipanti viene posta una prima domanda:
qual è lo scopo del progetto?

In questa fase si lavora sul “perché” e sulla vision del progetto.
Ognuno  ha qualche minuto a disposizione per scrivere le proprie risposte sui post-it.
Una volta terminata questa fase individuale i post-it vengono posizionati dove possono essere visibili a tutti.
Chi attacca il proprio post-it è invitato a spiegarlo agli altri e mano a mano le risposte vengono raggruppate per cluster.

2. Creare un ELEVATOR PITCH

Qui il facilitatore spiega che cos’è un elevator pitch, fornisce qualche esempio e invita ad utilizzare il formato standard, ovvero:

PER – [indicare il cliente]
CHE – [presentare i bisogni/le caratteristiche distintive]
il PROGETTO [nome del progetto in questione]
E’ – [definire la categoria di prodotto/servizio]
CHE – [indicare le caratteristiche distintive della soluzione proposta]

La condivisione dell’elevator pitch ha lo scopo di creare allineamento tra i partecipanti.
In questa fase ci si sta concentrando più specificamente sulla mission del progetto, sul cosa si sta andando a costruire.
Se vengono individuate diverse tipologie di clienti con bisogni differenti è opportuno seguire il format del pitch per ognuno di essi.

Al termine di questa fase il facilitatore può ripercorrere tutto ciò che è stato esplicitato per i vari clienti e prendere l’occasione di sottolineare cosa è stato scoperto di nuovo mettendo a fattor comune i diversi punti di vista.

3. Definire i VICINI DI CASA

Chi sono tutti i possibili stakeholder del progetto in questione?
Qual è il sistema complessivo in cui il progetto si inserisce?
E’ importante anche in questo caso arrivare a condividere la visione d’insieme.
Ai partecipanti viene chiesto di individuare tutte le parti coinvolte direttamente o indirettamente dal progetto al fine di esplicitarne dipendenze esterne, vincoli, confini, necessità in termini di risorse, ecc.

Una volta definiti i “vicini di casa” sarà molto più facile provare a formulare degli use cases.

4. Scoprire cosa non ci fa dormire la notte…

E’ questa la fase in cui – se non dovessero essere già emerse nella terza parte dell’incontro – vengono esplicitate le principali problematiche, i rischi e in generale tutto ciò che può andare storto.
Anche in questo caso ci avvaliamo dei post-it e delle idee individuali condivise poi con il gruppo.
E’ una fase molto importante per rendere esplicite le aspettative degli attori coinvolti che dovranno essere gestite durante il progetto.

Conclusione

Al termine dell’incontro è sempre buona norma chiedere un feedback ai partecipanti sull’utilità del meeting (in termini di ritorno per il tempo investito) e su come poterlo migliorare in futuro (chiedete cosa ha senso mantenere, aggiungere o togliere).

Se siete interessati ad approfondire l’argomento questo è il libro che fa per voi: “Liftoff: Launching Agile Teams & Projects” di Diana Larsen

Ho ereditato un product backlog… e adesso?

Sarà capitato anche a voi.
Non sempre si ha la possibilità di partire con un progetto da 0, avendo davanti una tabula rasa.
Spesso nella nostra professione si subentra al lavoro di qualcun altro ereditando gioie e dolori di progetti già esistenti.
Se avete sperimentato questa situazione sapete di cosa parlo.
Mi è capitato già due volte di ereditare un backlog creato da altri e siccome sono certa di avere fatto errori entrambe le volte e che avrei potuto fare di meglio, penso sia giunto il momento di tirare le somme. Magari il post consentirà a voi di risparmiare tempo prezioso.

Diciamolo francamente: ereditare un product backlog realizzato da altri con user stories annesse e connesse è un po’ come per i programmatori dover mettere le mani sul codice altrui.
Difficilmente sarete entusiasti di ciò che troverete.
Non perché il vostro predecessore abbia fatto necessariamente un cattivo lavoro, semplicemente il vostro modo di formulare le user stories, di suddividere i temi o di organizzare il tutto secondo epiche è semplicemente “vostro”, ovvero personale.
E’ un po’ come riempire una lavastoviglie: ognuno lo fa a modo proprio!

Che fare in questi casi? Come procedere?
Vi condivido alcune idee, che – col senno di poi – si sono rivelate utili.

Delimitare i progetti

Partiamo da un livello “macro”. Prima di tutto è opportuno suddividere le storie in base ai progetti a cui appartengono.
Magari sarete fortunati e avrete un unico grande progetto su cui lavorare, il più delle volte tuttavia erediterete di tutto un po’.
Partite dalle basi e verificate che ogni progetto abbia un ambito chiaro e ben definito, in caso contrario dovete poter arrivare a delinearne i confini. Quindi cercate di associare ogni item a un progetto di riferimento.
Se qualcosa non torna è un indizio da seguire. Ha senso mantenere quella storia? E’ ancora valida o può essere considerata superata?

Individuare le epiche

Che siano presenti esplicitamente nel backlog o meno, lo step di individuare le epiche e formularle in maniera comprensibile a voi e al team vi aiuterà molto a chiarire le idee.
Se, ad esempio, state iniziando a lavorare su un dominio nuovo il lavoro sulle epiche sarà il primo passo per organizzare le nuove conoscenze.
Potreste non avere le idee chiare sui dettagli, ma a livello più alto vi sarete fatti una visione a 360 gradi del progetto.
Createle ex-novo o modificatele secondo le vostre necessità, ma non saltate questo passaggio. Sarà più utile di quanto pensiate anche nella comunicazione con i vari attori.
Ricordate che anche a questo livello potete effettuare dei tagli.

Distinguere le user stories da storie tecniche… o altre amenità

Su questo punto ci sarebbe da scrivere un romanzo intero!
Chiariamo qualche presupposto: un titolo non è una user story, una soluzione tecnica non è una user story, la lista della spesa sulle modifiche al layout non sono storie, un componente applicativo non è il soggetto di una user story… non vado oltre.
Ciò che intendo dire è che il vostro backlog dovrà contenere per la maggior parte delle vere user stories, pensate e formulate secondo i canoni. Controllate che sia effettivamente così.
Poi ovviamente saranno presenti anche altre cose, non ultime tutta una serie di attività tecniche. Ma è opportuno che queste siano ben distinte dalle altre, anche per verificarne il peso complessivo e poter creare il giusto mix funzionale-tecnico ad ogni sprint.
Anche le storie tecniche devono avere un perché: migliorare le performance, risolvere un bug, rendere più facili gli sviluppi futuri, garantire la stabilità della piattaforma. Se il team non è in grado di individuarne il valore da solo educateli gentilmente a questa pratica. E’ utile per tutti.

Scartare le storie che sono già soluzioni

Almeno alcuni di questi esemplari li troverete sicuramente nel backlog in eredità (sono pronta a scommettere!).
Evitatele come la peste.
Apparentemente vi hanno già risolto un problema indicando la soluzione da adottare, in realtà nascondono spesso scarsa chiarezza sui bisogni ai quali rispondono.
Se trovate user stories che sono già la soluzione al problema procedete al contrario. Risalite la corrente e andate a verificare le necessità dalle quali hanno avuto origine. Cercate chi può darvi queste risposte e se non trovate nessuno o non è possibile risalire al reale bisogno buttatele nel cestino.

Associare le user stories alle epiche

Adesso che avete definito le epiche dei vostri progetti e avete distinto gli aspetti tecnici da quelli funzionali non vi resta che associare ogni user story alla relativa epica.
Questo passaggio potrebbe portarvi anche a riformulare le epiche secondo un nuovo schema. Poco male, purché veicoli una maggiore comprensione.
Nel caso in cui qualche storia rimanga “orfana” provate a chiedervi se avete dimenticato qualche parte del progetto non censito dalle epiche o se – piuttosto – sia la storia a dover essere riconsiderata (in molti casi si rivelerà materiale di cui potete fare a meno).

Individuare le user stories di maggior valore

Siam sempre lì.
Il nostro lavoro è la celebrazione dal principio di Pareto.
Ricordate l’idea dell’80/20 applicato al backlog? E’ proprio ciò di cui sto parlando.
Per ogni epica che avete definito dovreste riuscire ad individuare le user stories fondamentali. Di certo non avranno tutte il medesimo valore.
Ordinatele secondo questo criterio e abbiate ben chiare quali sono quelle chiave. Le altre potrebbero rivelarsi superflue strada facendo.

Chiedere, chiedere, chiedere

Fate una marea di domande ai vostri stakeholder e interlocutori. Avete tutto il diritto di non capire ciò che è stato sintetizzato da altri quindi vincete il timore di passare per stupidi e – piuttosto – siatelo. Finché non capite cosa vi stanno chiedendo di portare a termine e perché, non sarete in grado di fare il bene il vostro lavoro. Quindi mettete da parte ogni remora e fatevi sotto!

Fare declutter

Alla fine di tutto questo lavoro avrete comunque la sensazione che ci sia del superfluo e di sicuro… avete ragione! Ogni occasione è buona per fare pulizia nel backlog, ma l’occasione della “prima volta” non vi ricapiterà più quindi non fatevela sfuggire.
Non temete di essere troppo radicali, buttate!
Mal che vada se si tratta di cose fondamentali le richieste torneranno ad emergere. Ma nella maggior parte dei casi ciò che pensate non sia importante non sarà più sollecitato da nessuno.
Vi consiglio solo di fare questa operazione nel momento in cui vi sentite relativamente confidenti sul dominio. Avete scelto di fare dei tagli, ma lo avete fatto consapevolmente.

Puntare all’essenziale

Questo punto è un rinforzo del paragrafo precedente. Anche se temete di eliminare qualcosa che “prima o poi viene buona”, resistete alla tentazione del “non si sa mai”.
State per iniziare un lungo viaggio. Viaggiate leggeri.
Portate con voi l’essenziale perché inevitabilmente il materiale crescerà lungo la strada del progetto.
Se invece siete così abili da avere ridotto il vostro backlog a non più di una trentina di item, vi prego contattatemi. Voglio intervistarvi e imparare i vostri trucchi!
Se al contrario vi sentite troppo timorosi per effettuare tagli sfidate voi stessi: cosa succederebbe se di tutte le storie contenute nel backlog ne cancellassimo un quarto, un terzo, la metà?

Tenere sotto controllo la dimensione

Quanti item contiene il backlog che avete davanti?
30? 50? 100? Oltre?
Questo numero può darvi delle indicazioni importanti.
Se il backlog contiene più di un centinaio di storie è difficilmente gestibile e già 100 sono un numero oneroso.
Provate a verificare se qualcosa può essere cancellato o, nel caso, accorpato. Inutile avere dettagli minuziosi su attività che verranno portate a termine tra mesi. Concentratevi su ciò che dovrà essere lavorato nell’arco dei prossimi 2-3 mesi; il resto può essere sintetizzato in epiche o temi.
Un grande backlog fa rallentare, defocalizza il team e offusca i progressi. Al contrario un backlog troppo minuto è l’indizio che o non avete lavorato bene sul futuro più prossimo o è ora di andare a fare quattro chiacchiere con i vostri stakeholder.

Verificare gli obiettivi

Provate a guardare il vostro backlog dal punto di vista degli obiettivi, non  delle epiche.
Quello che vedete è un’immagine coerente ed equilibrata?
E’ allineata con la fase del ciclo di vita del prodotto?
Questa è la “prova del 9” del product backlog.
Ci possono essere delle fasi in cui si punta maggiormente alla monetizzazione o alla riduzione dei costi, ma ci sono tanti altri criteri oltre al soldo che definiscono un buon prodotto e un’azienda vincente (market share, usabilità, scalabilità, branding, innovazione tecnologica, ecc.).
Se la quasi totalità delle vostre user story punta alla generazione di ricavi e dimentica tutto il resto è la spia che il backlog debba essere attentamente riconsiderato.