Scalare Agile: encore

Dopo aver scritto l’articolo del mese scorso [1], una serie di coincidenze ha fatto sì che l’attenzione verso il “più grande” si sia spostata, al contrario, verso il “più piccolo”. È vero, i team di sviluppo che adottano Scrum diventano sempre di più, le aziende di una certa dimensione che iniziano ad avere al loro interno vari gruppi che sviluppano in Scrum e vanno, diciamo così, coordinati — lo so, è una forzata semplificazione — aumentano anche in Italia…

Eppure, il mondo dello sviluppo — specie per quello che attiene a soluzioni consumer come le app disponibili sui vari market/store digitali — vede ancora una buona fetta di produttori che sono piccolissimi gruppi di sviluppo, a volte di sole due o tre persone, quando non addirittura dei singoli individui.

E allora la domanda è stata: “Va bene scalare agile verso il più grande… Ma ha senso applicare principi e pratiche agili, e in particolare Scrum, a singoli sviluppatori?”. La risposta è più articolata di quello che sembri. Se è chiaro che le quattro proposizioni principali del Manifesto Agile [2] si applicano a chiunque voglia sviluppare con un certo approccio, indipendentemente dal fatto che si lavori in grandi organizzazioni o in microaziende, quando si passa ai 12 principi [2] e si va più nel pratico, il concetto di team inizia a ricorrere molto spesso. E allora, con metafora olimpica, Agile è solo per gli “sport di squadra” e non per le “discipline individuali”? Sì. Ma anche no…

Scrum è uno “sport di squadra”

Se si guarda alla metodologia agile più diffusa e strutturata, ossia Scrum, già a partire dal nome il richiamo alla squadra è fortissimo: scrum è il termine inglese che indica la mischia ordinata nel rugby, che magari al profano può apparire come una ruvida accozzaglia di energumeni, ma che in realtà è un atto sportivo che richiede forza fisica, notevoli doti tecniche, sincero affiatamento, comunicazione continua, grandi capacità di collaborazione. In pratica tutto quello che serve a un team di sviluppo (compresa, a volte, la forza fisica…).

Ma così come non ci sono solo sport di squadra ma anche discipline individuali, il panorama dello sviluppo vede ancora realtà di dimensione “micro” in cui a realizzare il prodotto sono una, due o tre persone. Ha senso per questo tipo di gruppi di lavoro, e a maggior ragione per chi lavora da solo, mettere in atto una metodologia strutturata come Scrum o perlomeno tentare di adattarla alla peculiare situazione?

Vediamo di seguito come e quanto certe pratiche tipicamente Scrum possano essere adattate al lavoro dei singoli. Senza dimenticare che Scrum nasce per i team, ci renderemo conto che alcune cerimonie e alcuni strumenti della metodologia possono funzionare anche negli “sport individuali”.
Ma deve essere chiaro che non si tratta di Scrum così come viene definito nella guida ufficiale [3], quanto di un tentativo di buon senso in cui si prendono a prestito principi e pratiche.

Scrum for individuals

A dire il vero, non è difficile trovare in rete svariati articoli dedicati al tentativo di applicare Scrum alla vita in generale, e questo è un approccio che a volte rischia di sfociare quasi al limite di certe pratiche new age… In certi casi si tratta proprio di quello che gli americani chiamano “life hack”, ossia dei “trucchi” o delle pratiche per migliorare e semplificare la vita delle persone in cui una sorta di “scrum personale” aiuta a organizzare le attività quotidiane [4] [5] [6].

In altri casi [7] si affronta il tema da un punto di vista più “tecnico” tentando di vedere quali principi possano essere effettivamente applicati da parte di chi lavora da solo [8]. Anche noi tenteremo di percorrere questo secondo binario, prendendo in esame la teoria, i valori, i ruoli, gli eventi e gli “artefatti” di Scrum così come esposti nella Scrum Guide [3] e cercando di capire se e come possono essere applicati — eventualmente con opportune modifiche — allo sviluppatore che lavora da solo.

Ne vale la pena?

In questo tentativo, non va dimenticata una regola di basilare buon senso: gli sforzi necessari a “tenere in vita” determinate pratiche devono avere degli effetti positivi sulla produttività e sui tempi di lavoro del programmatore singolo freelance o del “microteam” di due o tre persone. Altrimenti quella che, nelle parole di uno degli inventori, sarebbe una “arte per fare il doppio del lavoro nella metà del tempo”, diventa invece solo un ulteriore inutile carico di compiti da svolgere a discapito del benessere e della produttività.

Va poi considerato un ultimo e non trascurabile aspetto: un conto è l’adattamento di Scrum o di qualasiasi metodologia agile da parte del singolo che già le conosce — perché ha lavorato in un team più grande in cui erano pratica comune, perché le ha studiate per le più svariate ragioni etc. — e un conto è un singolo programmatore che deve imparare ex novo tutti i principi e le pratiche connesse a un framework come Scrum che, con le parole dei principali proponenti del metodo, è sì “semplice da comprendere”, ma è anche “molto difficile da padroneggiare”.

La discussione che segue presuppone in ogni caso una conoscenza, anche non approfondita, dei diversi elementi che costituiscono Scrum.

La teoria di Scrum

Alla base della teoria di Scrum ci sono la trasparenza e una mentalità basata sul principio dello inspect & adapt. Tutto il processo è iterativo e incrementale e le decisioni si basano su ciò che si conosce in quel momento. Si aggiunge mattoncino su mattoncino non tanto in base a un’idea immutabile stabilita a priori e una volta per tutte, ma tenendo in considerazione la costante evoluzione del progetto e ciò che, magari in modo imprevisto, può emergere durante il suo svolgimento.

Per questo è così importante la trasparenza intesa come visibilità dei risultati e del processo a tutti coloro che sono coinvolti e come adozione di un “linguaggio” comune, condiviso e chiaro a tutti, con il quale ci si capisce tra i diversi attori in campo, in particolare per quanto riguarda la definzione di ciò che è considerato “completato”.

Il concetto di ispezione può essere riassunto nella necessità di guardare spesso a tutte le informazioni che si hanno a disposizione e che alcuni appositi “strumenti” aiutano a tenere bene in vista: dalla velocità con cui si sta procedento, alle funzionalità del software che si stanno effettivamente completando, ai problemi e agli intoppi di tipo tecnico o di altra natura che possono presentarsi nel corso del processo. L’atto dello inspect è fondamentale, ma non deve essere così “ossessivo” da andare a intralciare il processo di sviluppo: ci sono quindi anche dei momenti formali in cui lo si compie.

L’adattamento è l’azione con la quale si “ricalibra” ciò che si sta facendo in base a quanto si è potuto acquisire nella fase di ispezione: se ci sono degli sforamenti in un senso o nell’altro, o se emergono delle novità, occorre mettere in campo delle sensate misure di adattamento. In certi casi, ci si potrebbe rendere conto di essere stati troppo “ambiziosi” nell’ipotizzare che cosa e a che livello poteva essere fatto, e in queste occasioni l’adattamento dovrà anche prendere atto di queste “mancanze” dovute ad esempio a lacune tecniche, o a un ritmo di sviluppo ipotizzato troppo alto e così via.

Adottabilità per lo sviluppatore singolo

Come tutti i principi assennati, questi concetti di buon senso ben si applicano non solo a un team che adotti Scrum strutturato per lo sviluppo del software, ma ad ogni attività “creativa” in senso lato, che sia svolta in gruppo o da soli. Se, in teoria, ognuno dovrebbe essere trasparente con sé stesso — e qui si entra più nel campo della psicologia che in quello delle metodologie di sviluppo — l’approccio empirico inspect & adapt è qualcosa che possiamo riscontrare in molte attività artigianali svolte da singoli.

I valori di Scrum

La nuova versione della Scrum Guide [3] pubblicata lo scorso anno ha aggiunto un paragrafo esplicitamente dedicato ai valori di Scrum. Impegno, coraggio, concentrazione, apertura, rispetto contribuiscono a creare fiducia tra i membri del team, favoriscono la pratica e crescono a mano a mano che il gruppo procede nel suo lavoro.

Adottabilità per lo sviluppatore singolo

Anche qui, in linea teorica, non si può che dire “ben vengano questi valori nel lavoro quotidiano dello sviluppatore individuale”. Ma a uno sguardo più attento si vede già meglio che oltre a trattarsi di valori giusti in sé e per sé, essi iniziano ad avere una chiara connotazione di squadra perché puntano a creare fiducia reciproca tra i vari membri del team. Si potrebbe dire che, a prescindere dal fatto che si tratti di valori condivisibili, che ciascun singolo sviluppatore può decidere di adottare e fare suoi, è proprio nel lavoro di squadra — fosse anche solo un paio di colleghi — che l’importanza di questi valori assume una portata “pratica”.

Il team e i ruoli in Scrum

Product Owner e team di sviluppo con relativo Scrum Master costituiscono gli Scrum Team. Questi vanno considerati come unità che si auto-organizzano anche grazie alle loro compentenze cross-funzionali.

Il PO ha la responsabilità esclusiva di gestione del Product Backlog (vedi oltre) e si deve impegnare per portare al massimo il valore prodotto e del lavoro degli sviluppatori.

Lo Scrum Master è un leader a servizio dello Scrum Team e ha anche il compito di far sì che tutti aderiscano ai valori, alle pratiche e alle regole di Scrum.

Il team di sviluppo è in genere costituito da massimo 9 persone, anche se spesso i gruppi di sviluppatori sono leggermente più piccoli. In ogni caso, citando dalla Scrum Guide [3]: “Avere meno di tre persone nel Team di Sviluppo diminuisce l’interazione e comporta un minore guadagno in termini di produttività”.

Con queste premesse ultrasemplificate, ci fermiamo subito qui.

Adottabilità per lo sviluppatore singolo

Per quanto riguarda la complessità degli aspetti “di squadra”, è banalmente ovvio che non è possibile adottare Scrum per singoli sviluppatori né per microteam di due persone. E ciò viene dichiarato esplicitamente dalla guida quando tratta la dimensione dei team. Uno dei punti di forza di Scrum sta proprio nel riuscire a gestire in maniera proficua un team e le sue interazioni.

Ciò che potrebbe risultare interessante per lo sviluppatore singolo o la coppia di sviluppatori è capire se e quando nella loro attività cambiano il loro ruolo. Ci saranno momenti in cui sono effettivamente solo sviluppatori, altri in cui potrebbero essere degli Scrum Master, altri ancora in cui il ruolo da svolgere è quello del Product Owner.

Questa affermazione potrebbe essere approfondita, e però presuppone una buona conoscenza del framework metodologico Scrum: potrebbe essere il caso di di chi abbia lavorato in contesti strutturati adottandone le pratiche, e poi abbia scelto di diventare un battitore libero. Ma sono casi particolari e già ci stiamo allontanando dalla maggior parte dei casi reali relativi a chi lavora da solo come freelance.

Nel complesso, tutta la parte relativa allo Scrum Team, ai suoi ruoli e ai suoi compiti è qualcosa di poca pertinenza per chi lavora come singolo.

Gli eventi e le “cerimonie”

Fedele al mdello dello sviluppo iterativo e incrementale Scrum basa la scansione delle sue attività sul concetto di Sprint. Uno sprint è un “lotto temporale” di lavoro in cui si realizza un incremento di prodotto funzionante e rilasciabile che deve rispondere al criterio di done cioè di “effettivamente completato”.

Uno sprint deve essere relativamente breve e non dura mai più di un mese, anche se in genere si fanno sprint di 2-4 settimane.

All’interno dello sprint si possono individuare alcuni eventi formali ben definiti. Semplificando al massimo, gli eventi sono i seguenti:

• Sprint Planning: a inizio sprint, serve a definire quale sarà l’obiettivo di quello sprint, che cosa potrà effettivamente essere realizzato e consegnato in quello sprint, come mettere in pratica questo incremento. Nella implementazione regolare di Scrum, questo evento si può avvalere di pratiche utili a definirne meglio gli esiti (story points, planning poker etc.). Le cose da fare vengono scelte a partire da una lista di funzionalità e necessità che di chiama Product Backlog e che viene gestita dal Product Owner.
• Daily Scrum: è una “riunione” che si svolge ogni giorno alla stessa ora e nello stesso posto. La caratteristica primaria è che è molto breve (max 15 minuti) e si fa in piedi (per evitare di dilungarsi inutilmente). Lo scopo consiste nell’allineare e sincronizzare tutti i membri del team che a turno dicono che cosa hanno fatto nel giorno precedente, che cosa faranno nella giornata che comincia e quali ostacoli hanno incontrato, singolarmente o come team di sviluppo, per procedere verso l’obiettivo dello sprint.
• Sprint Review: è un incontro che si tiene alla fine dello sprint e che vede partecipare PO, Scrum Master, team di sviluppo insieme ai principali stakeholder. Nel corso della Sprint Review, viene presentato l’incremento realizzato in quello sprint, il PO dice ciò che è stato fatto e non fatto e aggiorna di conseguenza il Product Backlog, e, in uno spirito informale e collaborativo, si discute su ciò che è andato bene e meno bene, nell’ottica di migliorare il valore di ciò che verrà realizzato nello sprint successivo.
• Sprint Retrospective: al termine dello Sprint, dopo la Sprint Review, si tiene la retrospettiva sullo sprint. Si tratta di un incontro breve (due o tre ore), in cui lo Scrum Team, facilitato dallo Scrum Master, esamina come sono andate le cose nell’ultimo sprint riguardo a persone, relazioni, processi e strumenti, individua quali miglioramenti si possono apportare al processo e stabilisce delle azioni concrete da intraprendere per realizzare tale miglioramento. Anche se è importante identificare intoppi e problemi, la Sprint Review deve essere un’occasione propositiva per il miglioramento e non un momento in cui ci si scontra sulle “colpe” da attribuire a qualcuno per ciò che non è andato bene.

Adottabilità per lo sviluppatore singolo

Per quanto riguarda gli eventi e le “cerimonie” di Scrum, molti sono gli elementi adattabili allo sviluppatore singolo, chiaramente con delle adeguate modifiche.

Anzitutto, il concetto di Sprint si presta sicuramente ad essere adottato anche dallo sviluppatore individuale: avere un preciso orizzonte temporale in cui un determinato set di funzionalità deve essere realizzato rappresenta un argine alla dispersione e al senso di inconcludenza che può mettere in difficoltà il programmatore freelance.

Invece, avere uno Sprint — magari non troppo lungo, e le 2 settimane potrebbero essere una misura di riferimento da cui partire — all’interno del quale deve essere fatto un determinato lavoro, può aiutare sicuramente a migliorare la produttività del singolo.

Quanto ai singoli eventi dello Sprint, alcuni hanno più senso nell’adozione dal parte del singolo e altri ne hanno meno, ma tutti forniscono alcuni spunti da considerare. Li vediamo di seguito

• Sprint Planning: è utile definire cosa e come si farà in quello Sprint. Ma per il singolo ci sono due fattori di adattamento da tenere presenti. Anzitutto, bisogna svolgere un po’ anche il compito di Product Owner per creare e mantenere il Product Backlog con la lista delle funzionalità e la loro priorità. In secondo luogo, è difficile da soli riuscire a dare una precisa valutazione dell’effort necessario a portare a termine un determinato obiettivo. Quindi, nella scelta delle cose da fare per quel determinato Sprint è bene “tenersi larghi”: non esagerare con quello che si prende in carico, individuare con oculatezza le priorità, e valutare bene senza sottovalutarlo, il reale impegno che quella feature potrà richiedere. In questo, effettivamente, fanno sentire tutta la loro importanza un PO distinto, un Product Backlog tenuto bene, una valutazione fatta con il Planning Poker [9] o tecniche simili e il confronto continuo che solo un gruppo ben assortito può garantire.
• Daily Scrum: allora, fare una riunione con sé stessi tutte le mattine alla stessa ora per informarsi su quello che è stato fatto ieri, quello che si farà oggi e sui problemi che ci sono stati può sembrare quantomeno strano. Di certo, il “daily standup meeting” come è inteso da Scrum non è assolutamente proponibile per il singolo. Però potrebbe avere senso dedicare 5 minuti ogni mattina a scrivere un sintetico “diario” che riporti data, un brevissimo riassunto di ciò che è stato fatto, di ciò che ci si propone di fare e dei problemi incontrati nel giorno precedente: solo poche e semplicissime note, nulla che impieghi più di 5 minuti. Questo non serve a sincronizzarsi con sé stessi, ma a creare uno “storico” che potrà risultare molto utile successivamente, in fase di retrospettiva.
• Sprint Review: questo evento ha senso se si sta sviluppando “on demand” per qualcuno a cui mostrare i risultati del lavoro dello sprint, ma risulta più difficile da realizzare nel caso in cui si realizzi un progetto “a investimento”, come nel classico caso dell’applicazione o del gioco realizzato in proprio, di cui comunque esistono (pochi) casi di enorme successo, che sono nati davvero dalla mente e dal codice di sviluppatori singoli o microteam. Di sicuro, oltre che a sé stessi, si può mostrare il risultato ad amici, colleghi etc. Ad ogni modo, non ci avviciniamo al valore e all’importanza di una Sprint Review formale inscritta in un processo Scrum reale.
• Sprint Retrospective: anche qui… strano o perlomeno difficile confrontarsi con sé stessi, magari scegliendo uno dei tanti formati esistenti per le retrospettive, e svolgendo al tempo stesso il ruolo di facilitatore esterno… Però, al termine di ogni Sprint, il famoso “diario” di cui si parlava a proposito del Daily Scrum, può essere riletto e su di esso possono essere fatte delle riflessioni: si è sovrastimato il lavoro che si pensava di fare? Si sono incontrati più problemi di quello che si pensava? E di che natura? Limiti tecnici, mancanza di competenze o “banali” interruzioni continue sul lavoro? E cosa si può fare per migliorare in tal senso? Magari si potrebbe scoprire semplicemente che concentrare le telefonate di lavoro in un determinato arco di tempo ci consente di avere un “flusso” di lavoro più proficuo, oppure che dedicare un certo numero di ore ogni mese all’aggiornamento degli e sugli ambienti di sviluppo potrebbe facilitare il lavoro e così via. Non sarà una retrospettiva in senso classico, ma questi momenti di riflessione potrebbero aiutare sicuramente ad aggiungere piccoli contributi al miglioramento continuo che anche un singolo sviluppatore deve perseguire.

Gli “artefatti” e gli altri strumenti

Scrum prevede l’uitlizzo di alcuni “artefatti” vale a dire di alcuni strumenti di visualizzazione del lavoro e del valore prodotti. Il termine inglese artifacts andrebbe più correttamente corretto come “manufatti”, ma il concetto è che si tratta in ogni caso di “oggetti” prodotti allo scopo di migliorare la trasparenza su quello che sta accadendo nel processo e, conseguentemente, di favorire l’ispezione e l’adattamento.

A livello ufficiale, gli strumenti previsti da Scrum sono

• Product Backlog: la lista costantemetne aggiornata, raffinata e ordinata delle funzionalità del prodotto che andranno realizzate;
• Sprint Backlog: gli elementi prelevati per quel determinato sprint dal Product Backlog;
• Increment: la somma di tutti gli elementi del Product Backlog completati durante uno Sprint e durante tutti gli Sprint precedenti.

In realtà, ci sono poi tutta una serie di strumenti quale il burn down chart o le Kanban board che non fanno parte dell’ufficialità di Scrum ma che sono comunemente usati all’interno dei gruppi che adottano Scrum.

Visto lo scopo dell’articolo, non ci dilunghiamo su questi aspetti di cui peraltro si è parlato a più riprese su queste pagine [10]. Ribadiamo invece che questi strumenti devono servire al team per avere sempre chiara la velocità a cui si sta procedendo, le cose fatte e quelle che restano da fare, gli eventuali discostamenti da quello che si era inizialmente stimato, chi sta lavorando su cosa per evitare di avere nel gruppo persone sovraccariche e altre troppo scariche e così via. Ancora una volta si torna alla teoria: la trasparenza che consente di visualizzare il processo per applicare l’inspect & adapt.

Adottabilità per lo sviluppatore singolo

Per quanto riguarda gli strumenti in grado di garantire visibilità sul processo, occorre fare due considerazioni.

La prima è che alcuni di essi (Burn Down Chart ad esempio) presumono una serie di “premesse” per essere realizzati: tanto per dire, uno Sprint Planning fatto con tecniche che consentano il calcolo dei punti delle storie che si andranno a sviluppare nel corso dello Sprint. E abbiamo visto che questo è già un grosso limite per chi lavora da solo o in coppia.

L’altra considerazione è che, in definitiva, qualsiasi strumento sensato che consenta una visualizzazione dello stato del processo può andare bene. E in questo senso, per il programmatore singolo, potrebbe bastare la più semplice delle Kanban Board (figura 4), con le tre colonne per il “ToDo”, “Doing” e “Done” e magari una “corsia” preferenziale per le emergenze. Usata come “monitor” per tenere presente quello che succede durante uno Sprint, si tratta di uno strumento di facile utilizzo che non aggiunge praticamente carico di lavoro alle attività che si stanno svolgendo, ma che consente di avere immediatamente uno sguardo su quello che sta succedendo.

Si possono usare Kanban board fisiche con Post-it o si può ricorrere ad applicazioni come Trello [11] che oltretutto consentono di condividere le proprie Kanban: non si sa mai… magari si decide di scappare dall’isola disabitata e dedicarsi a uno sport di squadra…

Conclusioni

No, non è Scrum. Diciamolo subito e onestamente: Scrum è qualcosa di altamente strutturato e di estremamente rigoroso, pur nella sua sostanziale semplicità. E questi aspetti di strutturazione e rigore sono pensati per gruppi di lavoro e non per singoli.

Ciò nonostante, come abbiamo visto, alcuni principi e alcune pratiche di Scrum possono essere sperimentate, magari con adattamenti e variazioni, anche dal singolo sviluppatore freelance. Certo… non è Scrum, ma il tutto finisce per avvicinarsi di più a una versione riveduta e corretta di Getting Things Done (GTD) [12].

Ma, al di là dei nomi e delle metodologie, quel che conta è che un certo approccio che consenta di migliorare la produttività e il valore prodotto può, pur con tutte le limitazioni del caso, essere scalato anche verso il basso.