di Corrado De Sanctis

Qualche mese fa ho avuto l’opportunità di incontrare Jeff Sutherland durante un evento di presentazione di Scrum@Scale e al termine abbiamo avuto la possibilità di scambiare informalmente 4 chiacchiere. Qualche giorno prima ho avuto analoga opportunità anche con Robert Martin (uncle Bob per tutti), una autorità di XP e un altro dei firmatari originari del Manifesto.

Non accade tutti i giorni di avere la possibilità di parlare con personaggi che tanto ha fatto per il movimento Agile e in diversi mi hanno chiesto di parlarne, ho pensato quindi di scrivere un articoletto che mette insieme un po’ di concetti emersi. Lungi da me l’idea di considerarla una intervista men che meno la pretesa di esplorare la personalità di entrambi, tuttavia sono emersi alcuni spunti di riflessione interessanti e soprattutto alcune conferme. Un articolo che ha anche aspetti personali e non solo tecnici.

Nota: di seguito li chiamerò Jeff e Bob, non certo perché mi sentano così familiare, ma solo per rendere la lettura più veloce. Spero mi perdoneranno. 😉

Aneddotica

Va detto che Jeff è una fonte praticamente inesauribile di aneddoti su Scrum. 

Sicuramente un punto importante è quello relativo alla nascita del termine: infatti ha confermato esplicitamente che l’idea gli è venuta vedendo gli operai raccogliersi nello spiazzo apposito nel momento in cui in un impianto Honda (che applicava ciò che venne in seguito definito Lean) veniva suonata la campana che segnalava un difetto. I dettagli del periodo e del luogo non sono stati chiariti ma eravamo intorno alla fine degli anni ‘80.

La prima bozza di Scrum, Jeff la fa risalire al 1993 (con alcune idee applicate già a partire dal 1983). Due anni dopo incontra Ken Schwaber che allora lavorava in modalità waterfall (e si lamentava degli insuccessi) e lo invita a utilizzare questo nuovo approccio. Sarà poi Bob che racconterà che un paio di anni dopo (fine anni ‘90) che Ken gli aveva chiesto un paio di team a cui insegnare Scrum seguendo una bozza di quello che diventerà il corso per la certificazione CSM.

Quando poi Jeff racconta dell’incontro con Brian Kernigham ai laboratori Bell diventa assolutamente esilarante facendoti immaginare loro due insieme a Ritchie con una birra in mano a discutere di sviluppo software e team di piccole dimensioni che operavano con tecniche di “guerriglia” contro gli eserciti di sviluppatori waterfall controllati da pochi comandanti/manager.

Segnalo infine che Bob aveva proposto i Caraibi per il ritrovo che poi ha portato alla scrittura del Manifesto, ma si dice contento che alla fine siano andati in Utah, altrimenti non avrebbero mai trovato il tempo di scriverlo essendo sempre in spiaggia.

Framework

E’ chiaro che parlare di Scrum con Doctor Scrum e di XP con uncle Bob, è il massimo che si possa pretendere e quindi l’occasione non si poteva perdere.

La opinione di fondo di Jeff è che Scrum sia un processo all’interno del quale applicare le tecniche XP e che la combinazione dei due porti il massimo beneficio al team che sviluppa software. Collegato a questo punto segnalo che per Bob non esiste una vera differenza tra Agile e XP. Attenzione però che Agile e Scrum sono due cose diverse e per riportare le parole di Jeff “i valori di Agile riguardano il modo di PENSARE, Scrum invece indica un modo di FARE” un’idea che forse non è così lontana da quella di Bob.

Ma qual’è secondo il suo creatore la effettiva conoscenza di Scrum da parte della comunità? Qui Jeff risponde con un dato statistico: nella biblioteca IEEE ci sono 70 documenti originali di Scrum che vengono citati da quasi altri 1500 ma guardando le effettive letture sembra che in pochi leggano i documenti originali. 

Venendo alle cose più pratiche ci siamo soffermati su alcuni elementi cardine del framework.

A parte ribadire quando scritto nelle Scrumguide (in particolare sui ruoli: lo scrum master si occupa del processo, il product owner del prodotto e il protocollo 3-5-3: 3 ruoli, 5 cerimonie e 3 risultati), la capacità di gestire il backlog è secondo Jeff l’elemento di successo più rilevante: gestire le priorità e preparare in modo corretto le storie da proporre al team sono i veri elementi di maturità, il resto viene come conseguenza e ha importanza minore: ad esempio lunghi Sprint Planning sono causati dalla mancanza di questi due elementi. Ma quale dovrebbe essere la corretta durata di uno Sprint Planning? Jeff sostiene che 4 ore sia il massimo per sprint di 2 settimane, ma che si possa fare in 1 ora e mezzo.

Quindi abbiamo parlato della Velocity che per Doctor Scrum deve essere considerata una misura per il planning e non per le prestazioni del team. Ma qual’è allora la misura della prestazione per un team? La risposta è immediata e non è Agile ma Lean: Process Efficiency; e a questo punto viene fuori il ricercatore. Infatti gli studi di più di 30 anni gli hanno dimostrato che il processo di sviluppo software sia uno dei meno efficienti di tutte le industrie (circa il 1,25% in casi fortunati) e che analizzando e applicando alcune semplici ottimizzazioni su questa metrica sia possibile arrivare a livelli del 5% con un incremento di 4 volte (il classico 400% degli overperforming team?). E quale sarebbe il miglior modo per migliorare l’efficienza? Anche su questo punto la risposta di Jeff è immediata: dare ai Product Owner il potere di decidere. Infatti secondo lui la perdita di efficienza è dovuto alla latenza dei processi decisionali che attraversano gli strati organizzativi (mediamente 7 in base alla sua esperienza); ma è evidente che questo significa trasformare la organizzazione da una struttura gerarchica a una rete che collega team e “nuovi” leader. Per questo motivo accanto a Scrum per i singoli team, propone il modello @Scale per le organizzazioni.

In sintesi la componente “business” assume un ruolo fondamentale in un framework pensato (erroneamente solo) per i tecnici. Ed infatti Jeff concorda che la gran parte degli sforzi per rendere un azienda agile si devono concentrare nel business, che deve tendere a un coinvolgimento più profondo, e nel management, il cui ruolo cambia radicalmente verso quello di “rimuovere gli impedimenti” ai diversi livelli. Per ottenere la loro collaborazione la chiave continua a essere la “gestione delle priorità per aumentare la competitività attraverso una maggior velocità per andare sul mercato con i prodotti giusti”.

I personaggi

In un mondo di manager e esperti Jeff si considera un ricercatore (non a caso tutti lo chiamano Doctor) e in effetti lo si vede dal fatto che la sua maggior fonte di risorse sono i documenti IEEE e BHR. Inoltre da bravo intellettuale non ha anche nessun problema a parlare della “bancarotta” della azienda.

Interessante confrontarlo con la dichiarazione di Bob che ha ammesso che ai tempi non aveva assolutamente creduto nel processo di certificazione di Scrum Master proposto d Ken Schwaber che invece (anche sotto il profilo economico) ha costituito una delle fondamenta del successo di Scrum.

Quello che traspare in Jeff è proprio questa sua voglia di divulgazione: lui ti racconta delle cose e ti dice i perché ma non ti vuole assolutamente convincere. Alla domanda di come si sentisse per il fatto di aver ispirato così tante persone e di essere un guida per una intera generazione di sviluppatori, ha detto che oggi al mondo ci sono problemi ben più gravi e definitivi quali quelli dell’energia e dell’ecologia, e si è riferito a Elon Musk e alla sua idea di un mondo pulito definendolo un “obiettivo degno”. 

Diverso l’atteggiamento di Bob che è un tecnico e si presenta come uno sviluppatore, spiegando ai suoi pari (non a caso è “uncle Bob”) perché le diverse pratiche di XP siano efficaci e di come queste siano raggruppate in quello che lui chiama “il circolo della vita” cioè la persona, il team, l’organizzazione.

Conclusioni

Questi signori hanno effettivamente una visione “più alta” rispetto alla media e anche alla loro età è sempre un piacere parlare con loro anche se magari non condividi tutto quello che dicono oppure anche se oggi ci sono approcci “più moderni” ai problemi che continuano però a essere gli stessi.

In ogni caso sia Scrum che XP hanno cambiato radicalmente il mondo dello sviluppo software ed è molto interessante come (forse) li considerino facce della stessa medaglia (un po’ come Lean e Agile).

Entrambi, sia Bob che Jeff, c’erano prima del 2001, si sono ritrovati (con altri) in Utah nel 2001 a scrivere il Manifesto, e (anche se Bob ha escluso una “reunion”) ancora oggi sono qui a proporre le loro idee. Però forse senza il Manifesto del 2001, che ha creato quel substrato teorico su cui appoggiare il tutto, oggi avremmo uno scenario diverso. Infatti io continuo a pensare che, sebbene sia venuto dopo, a sintesi di quanto fatto prima, i valori e principi del Manifesto per lo sviluppo del software, debbano essere considerati le fondamenta su cui appoggiare pratiche e framework e vanno spiegati/capiti/assimilati prima di applicarli attraverso Scrum, XP o quanto altro: ci vuole il giusto atteggiamento per applicare le pratiche in modo corretto.