Scrum: it’s all about the loop
Per capire cos’è lo Scrum, cosa significa Agile, e qual è la loro applicazione e utilità, a me piace l’idea di conoscerne la storia, quali sono i principi su cui si basano e qual è il loro significato.
Nicola Battoia profilo
Junior Product Owner
Questo articolo nasce dalla sensazione che ci sia una diffusa confusione su cosa significa essere Agile e usare il metodo Scrum.
Questi termini sono ormai mainstream, vengono usati per fare bella figura nel sito aziendale o nella presentazione di un progetto; ma nella pratica di tutti i giorni non hanno un reale impatto.
Per contribuire a portare più chiarezza, voglio raccontare la storia, o almeno un parte, di come si sono formati questi approcci.
Questa storia inizia in Giappone, ancora una volta nella famosa fabbrica da cui uscì la macchina che ha cambiato il mondo.
Quella macchina era una Toyota, e cambiò il mondo perché lo obbligò a studiare il sistema di produzione Toyota (Toyota Production System).
Siamo negli anni ‘70, e l’approccio della Toyota ha dato il via a una rivoluzione, conosciuta nel mondo come Lean.
Per questa storia voglio focalizzarmi sui principi alla base dell’approccio Lean.
Spesso per spiegare questo tema si usa la metafora della casa Lean, e se usata con la giusta sintesi è una figura utile per una prima essenziale comprensione.
Quindi, questa casa, che se disegnata ricorda più un tempio, ed è forse l’immagine più appropriata per quello che rappresenta, si basa su tre pilastri.
Il primo pilastro è il rispetto delle persone, che deve essere pari al rispetto che si porta a un artigiano e al suo lavoro unico.
E’ un pilastro interessante, implica un’azione, quella di portare rispetto, ma implica anche che ci si aspetta di ricevere il frutto di un lavoro superbo.
Il secondo pilastro è il flusso, che porta dal produttore al cliente, le cui attività vengono realizzate solo se sono richieste e solo quando vengono richieste.
Questo concetto si riassume in “pull” e “just in time”.
Terzo pilastro del tempio lean è il miglioramento continuo, il motore di tutto, che nasce dal riconoscere che qualsiasi attività non è mai perfetta, e può sempre essere migliorata.
Questi tre pilastri hanno un solo scopo, cioè creare valore per il cliente.
Anzi, l’obiettivo è più alto: creare nient’altro che valore per il cliente.
Significa quindi analizzare le attività, comprendere quali creano un valore aggiunto, e fare solamente quelle, eliminando tutto il resto, perché sarebbe solo uno spreco.
In questo tempio, devoto solo al valore, il management e la leadership hanno la funzione di supportare e liberare la strada alle persone che costituiscono il cuore dell’organizzazione.
Questa costruzione riconosce in modo chiaro dove viene creato il valore, e tutte le attenzioni devono essere messe lì.
Quindi, abbiamo detto: rispetto per le persone, flusso tirato dalla richiesta, e miglioramento continuo.
Tutto ciò per creare nient’altro che valore. In poche parole questo è il cuore del sistema Lean, ed anche del metodo Scrum. Vediamo come.
Lean, automobili, anni ‘70.
Ok, adesso facciamo un salto avanti a metà anni ‘90.
Lo scenario in cui entriamo è quello dello sviluppo software, che allora era il regno della confusione.
I progetti erano sempre in ritardo, sempre oltre il budget, e per di più la qualità era bassa e i risultati non soddisfavano i clienti.
Era l’inizio di qualcosa di nuovo, era il caos.
In questo scenario, Jeff Sutherland si occupava di sviluppo software e cercava, insieme alla sua squadra, un nuovo metodo per affrontare i progetti.
Avevano capito che il vecchio Waterfall project management serviva solo a produrre delle bellissime, quanto inutili, pianificazioni.
Nella loro ricerca si imbattono in un articolo del 1986, “The new new product development”, scritto da due professori giapponesi sul metodo di alcune aziende, tra le più produttive al mondo, per gestire lo sviluppo di nuovi prodotti.
L’articolo paragona lo sviluppo di un progetto a come la palla avanza, passando di mano in mano, tra i giocatori in una mischia di rugby, Scrum in inglese.
La sfida era quella di riuscire a metterlo in pratica.
L’approccio descritto ha delle caratteristiche base, tra queste c’è la creazione di un squadra interdisciplinare, a cui viene data piena indipendenza su come organizzare il proprio lavoro.
Lo sviluppo non avviene in modo lineare tra fasi successive, ma viene portato avanti attraverso delle fasi in sovrapposizione tra loro.
Questo significa che il lavoro avanza più rapidamente, ed è flessibile per rispondere ai cambiamenti in modo rapido.
Un’altra caratteristica fondamentale è che le persone siano responsabili per il progetto dall’inizio alla fine.
In questo modo si sentono parte di una strategia, di qualcosa di completo, e sono motivate ad impegnarsi per migliorare il risultato complessivo.
Lo scopo è di eliminare la separazione netta tra responsabilità, che crea attriti tra le persone e le porta ad impegnarsi solo fin dove è di loro competenza.
Si elimina così il rischio dell’effetto “scarica barile”, tra uffici e persone, perché il risultato che viene valutato è quello complessivo e tutta la squadra ne è responsabile.
La squadra così creata si comporta come una start-up all’interno dell’organizzazione, dalla quale riceve degli input sul lavoro da fare.
Gli input saranno le richieste di potenziali clienti e la strategia aziendale, che dà un significato e una direzione al lavoro da fare.
Ispirato da questi concetti Sutherland li usa per il suo progetto, conoscendone gli obiettivi dice al suo CEO:
“Non mi chiedere una pianificazione adesso, tra un mese ti porterò una prova, una parte del software funzionante, che tu potrai testare e dirmi se stiamo andando bene o no.”
L’essenza di questo approccio è creare un ciclo di promesse e dimostrazioni, che in inglese suona come promise-proof cycle.
Significa che il team fa una promessa su ciò che realizzerà, e il confronto viene fatto sulle prove che mostrerà in iterazioni successive.
Alla base c’è la fiducia e il rispetto per le persone che realizzano il lavoro, e una valutazione basata sui fatti concreti e non sulle pianificazioni.
Questi cicli di promesse e dimostrazioni sono i famosi Sprint del metodo Scrum, normalmente durano tra le 2 e le 4 settimane, e sono la forma di avanzare il lavoro in modo iterativo.
Intorno a questi cicli di lavoro sono stati definiti degli strumenti e dei ruoli, che hanno via via delineato il metodo Scrum.
Per questo Ken Schwaber e Jeff Sutherland hanno scritto la guida Scrum, in cui queste figure vengono descritte nel dettaglio.
Certamente sono degli strumenti molto utili, ma perdono di significato se non si comprende qual è l’obiettivo da raggiungere.
L’aspetto da guardare è come si decide il flusso di lavoro.
Dicevamo che il metodo Scrum si ispira profondamente alla Toyota, e qui si vede molto bene.
Alla base del sistema Toyota c’è il famoso ciclo di Deming, Plan-Do-Check-Act, fatto di 4 fasi ripetute ciclicamente: Pianifica-Fai-Controlla-Agisci.
Il ciclo di Deming è un metodo usato per processi di miglioramento continuo, e declinato per lo Scrum diventa quanto segue:
sulla base delle richieste ricevute, il team costruisce una lista di attività da realizzare per soddisfare il cliente.
In questa lista stabilisce delle priorità e pianifica cosa fare solo per il successivo Sprint, in base alla disponibilità del team.
Durante lo Sprint viene sviluppata un parte del prodotto che possa essere mostrata al cliente.
Al termine di ogni Sprint c’è un confronto su quanto realizzato, e il cliente dirà se è soddisfatto e in quale direzione proseguire.
Davanti a qualcosa di realizzato è più facile comprendere le reali necessità del cliente, e entrambe le parti si rendono conto del lavoro ancora da fare.
Sulla base di queste discussioni, il team ridefinisce la lista delle cose da fare e inizia un altro sprint.
Procedendo con questi cicli iterativi si hanno molti vantaggi.
In sintesi:
viene sviluppato solo ciò che ha valore per il cliente;
ci si rende conto velocemente se il progetto sarà profittevole o no;
c’è un costante miglioramento e adattamento ai cambiamenti;
le perdite in caso di fallimento sono ridotte al minimo.
Fino a qui ho cercato di trasmettere la storia e i principi fondanti del metodo Scrum.
Adesso vorrei aggiungere un ragionamento sul perché questo approccio funziona, e perché è efficace nel mondo attuale.
L’assimilazione di questo approccio crea un’intelligenza di tipo adattivo, cioè del tipo che apprende costantemente dalle interazioni con il sistema in cui si trova, e si adatta di conseguenza.
Oggi più che mai, questa è una caratteristica essenziale per la sopravvivenza.
Qualsiasi azienda si trova a lavorare all’interno di sistemi complessi, che cambiano costantemente e non sono prevedibili, perché vengono influenzati da troppi fattori.
Il modo per sopravvivere in queste realtà è essere flessibili, apprendere velocemente e rispondere in modo agile ai cambiamenti.
Avere un approccio Scrum consente di sopravvivere soprattutto nelle situazioni complesse e incerte, ed anche di crisi.
Un concetto intrinseco nello Scrum è quello di sviluppare qualsiasi cosa partendo dal Minimo prodotto Fattibile (minimum viable product), cioè quel prodotto che contiene le funzionalità basiche, essenziali, e niente più.
Deve essere il prodotto che lanci sul mercato con un po’ di paura, perché sai che non è completo.
Lanciare questo prodotto come test sul mercato genererà molte lamentele da parte della clientela, e quelle lamentele sono il miglior feedback in cui il team di sviluppo può sperare.
Sulla base dei commenti ricevuti dai reali utilizzatori si potrà implementare ciò che i clienti realmente vogliono, concentrarsi su quelle caratteristiche e dimenticare il resto.
I vantaggi sono di riuscire a soddisfare realmente le persone, risparmiare i costi di attività non necessarie, e accorciare il tempo di risposta al mercato.
Qui voglio sottolineare la forte eredità dell’approccio Lean:
devozione alla creazione di valore ed eliminazione degli sprechi.
L’altra caratteristica che consente di navigare in acque burrascose è l’utilizzo di squadre interdisciplinari.
Una mentalità tradizionale potrebbe contestare che il fatto di avere sovrapposizioni di ruoli all’interno dell’azienda è un’inefficienza, un costo evitabile.
Certo, è vero che si paga un costo in questo senso, perché sarebbe conveniente centralizzare le competenze il più possibile.
Pagando però questo prezzo in partenza, si ha il grosso beneficio della capacità di rispondere ai cambiamenti in modo efficace e tempestivo.
Una squadra interdisciplinare, di per sé completa e indipendente, può rispondere alle nuove richieste del mercato e soddisfarlo.
Inoltre il fatto che ci siano dei ruoli in sovrapposizione all’interno dell’azienda genera diversi punti di vista, e dal confronto di questi si crea un’elevata ricchezza.
Questa ricchezza è in termini di valore e tipo di risposta che si offre al cliente, e sarà tale da compensare i costi di alcune sovrapposizioni.
Riprendendo la nostra storia, l’ultimo passaggio da raccontare è il collegamento tra Scrum e Agile, e cosa vuol dire Agile.
Dopo gli anni ‘90, il mondo dello sviluppo software era migliorato solo in parte, la maggior parte dei progetti aveva ancora risultati insoddisfacenti.
Sentendo fortemente questo problema, diciassette specialisti dello sviluppo software si riuniscono con lo scopo di superare una volta per tutte i vecchi approcci fallimentari.
Tra di loro c’erano gli ideatori di diversi metodi, tra cui Ken Schwaber, il co-inventore del metodo Scrum insieme a Jeff Sutherland.
Nella discussione capirono che non potevano arrivare a un accordo su un unico metodo, quindi fecero qualcosa di più bello e importante:
scrissero un manifesto con dentro i valori e principi che condividevano, l’Agile Manifesto.
I quattro valori fondanti del Manifesto sono un perfetto riassunto di quanto detto finora, e stabiliscono delle priorità.
Sono i seguenti e sono ordinati per importanza di realizzazione. Il primo valore è:
individui e interazioni prima di processi e strumenti.
Si riconosce che la ragione di un successo sono sempre le persone e l’interazione tra queste.
Quindi se c’è un processo o uno strumento che ostacola il lavoro delle persone, va cambiato.
Il secondo valore è:
software funzionante prima di documentazione estensiva.
La priorità assoluta è il prodotto funzionante, che deve essere realizzato e funzionante il prima possibile.
Questo significa che la documentazione viene realizzata in parallelo e solo su ciò che è già stato realizzato.
Terzo punto:
collaborazione con il cliente prima delle negoziazioni contrattuali
Qui è importante ricordare che quando si parla di cliente non si tratta solamente del cliente finale ed esterno, ma anche dei clienti interni all’azienda, cioè chi beneficia e utilizza il lavoro fatto da un certo team.
Questo valore serve a riconoscere l’importanza di avere delle conversazioni significative con il cliente, che permettano di raggiungere risultati migliori.
Fare questo sforzo di collaborazione, a differenza di ricorrere costantemente ai contratti, porta grandi benefici.
Per farlo in modo produttivo è importante avere un prodotto funzionante il prima possibile, in modo che si possano avere delle discussioni costruttive su qualcosa di tangibile.
Così facendo si porterà il cliente a collaborare, in risposta ai cambiamenti, in modo ciclico. Questo effetto è riconosciuto nel quarto principio:
rispondere al cambiamento prima di seguire il piano.
Una frase che mi ha dato la giusta chiave di lettura per questo valore è:
“Il piano è costruito nel momento in cui sai di meno su cosa succederà, e tutti i rischi sono davanti a te.”
Quindi pianificare resta importante per prepararsi, però una volta iniziato lo sviluppo è fondamentale rispondere al cambiamento, piuttosto che seguire il piano prestabilito.
Profilo Linkedin di Nicola Battoia
A questo punto ti auguro buon lavoro e ti aspetto nei prossimi articoli
Gli Ebook di impresaefficace.it
Se vuoi capire come fare un budget di vendita
qui puoi trovare come usare il margine di contribuzione
e infine qui impari a fare il rendiconto finanziario
e infine 10 piccoli indiani per capire il bilancio