1_2020: Roadmaps, IAM e IAD

1 - 2020 Magazine Bimestrale di AgileForItaly [http://www.agileforitaly.com] disponibile su http://www.agileitalia.agileforitaly.com Magazine Bimestrale AgileForItaly AgileItalia MAGAZINE Roadmaps di Tiziano Interlandi, Dimitri Favre, Andrea Feraco Speciale IAD19 e IAM di Fabio Ghislandi, Alessandro Giardina, Pierpaolo Cimirro, Davide Casari, Andrea Feraco di Vito Semeraro Accorciamo il ponte tra Business Da Open Source a Open SasS e IT Una diversa visione del di Blaise Palopoli project management di Stefano Pistorio Incontrando Doctor Scrum Come favorire l’ agi- (E uncle Bob) lità: la Marina Milita- re Italiana negli anni di Corrado De Sanctis ‘80 Appuntamenti 2020 di Francesco Racanati di Agile For Italy AgileForItaly

#CHISIAMO Tiziano Interlandi, Agile Coach e Software Engineer. Batterista e co-fonico della Secchezza Delle Fauci. Co-fondatore di Agile For Italy. Pierpaolo Cimirro Product Owner. Co- fondatore di Agile For Italy. Davide Casari, Product Owner, Salesforce Specialist, co-fondatore di Vhagin, il gin dell’Agilista. Co-fondatore di Agile For Italy. Vi domanderete il perché di questa cosa. AgileItalia Pensiamo che in Italia sia necessaria una divulgazione massiccia su Agile. Fondatori ed Editori Come paese brilliamo di inventiva e capacità tecnica, ci manca Tiziano Interlandi, Pierpaolo Cimirro e Davide Casari però la struttura manageriale per portare questo paese ad un livello successivo. Sito Agile è un abilitatore. Abilita le persone a creare prodotti https://agileitalia.agileforitaly.com migliori, dominare la complessità ed introdurre una disciplina positiva, fatta di raggiungimento di obbiettivi. Mail Ci sono tanti entusiasti in Italia. Agile in Italia sta esplodendo. [email protected] Vogliamo aggregare e filtrare per tempo questa onda dando a tutti accesso alle informazioni ma anche una corretta e Slack strutturata informativa di qualità. agileforitaly.slack.com (canale aperto) Spesso siamo caustici,ma non confondentela con arroganza. Abbiamo i nostri modi, un po’ da badile e trattore. Ma ci piace Facebook così, genuino. agileforitaly Cerchiamo di aggregare la conoscenza su Agile con tutto ciò LinkedIn che gira intorno: mondi, universi di informazioni, tecniche e AgileForItaly pratiche difficili da sintetizzare e vogliamo far emergere le realtà pratiche che sappiamo essere molte ma ancora da Twitter scoprire. agile_for Questo non sarebbe possibile senza ... AgileItalia AgileForItaly vuoi contribuire? scrivi ad [email protected]

Contents 10. Appuntamenti 2020 di AgileForItaly 12. Una diversa visione del project management, la commistione di frameworks: agile, lean, devops,kanban di Stefano Pistorio 15. Evoluzione del modello Open Source verso il modello Open SaaS di Vito Semeraro 21. Accorciamo il ponte tra Business ed IT di Blaise Palopoli 24. Incontrando Doctor Scrum (e uncle Bob) di Corrado De Sanctis 28. Come favorire l’agilità: la Marina Militare Italiana negli anni ‘80 di Francesco Racanati Speciale Roadmaps 33. L’umore del Gantt di Andrea Feraco 35. Roadmaps: un cammino per farci crescere di Tiziano Interlandi 47. Una Roadmap basata sui bisogni di Dimitri Favre Speciale IAM e IAD 54. Il migiore IAD di sempre di Andrea Feraco 56. Introduzione: la nostra esperienza a IAD 19 di Pierpaolo Cimirro e Davide Casari 58. Tre anni di Italian Agile Movement di Fabio Ghislandi 60. Cinque domande ad Alessandro Giardina con Alessandro Giardina 62. Risorse e Materiali da Italian Agile Movement AgileForItaly thanks to Kaleidico, kellysikkema,olav_ahrens,irongamer, curtimacnewton, 4 janesglas, intothefab, quinoal, thips, randyfath,tessawilson, desalaberry, morvanic, wflwongjjying, wonderingteddybear, toomastartes

La Community delle Communities italiane PODCAST E CANALE YOUTUBE PODCAST Youtube Tiziano, Davide e Pierpaolo Rivedi gli eventi del Meetup e parlano di tematiche delle iniziative di AgileForItaly agili davanti ad una birra. Interviste e racconti dalla trincea. Segui il podcast su Spotify, Apple Podcast, Spreaker. Agile For Italy Lean Beer AgileItalia 5 Agileforitalymilano

In questo numero Editori & Autori Tiziano Interlandi Pierpaolo Cimirro Davide Casari Autori 6 Alessandro Giardina Andrea Feraco Vito Semeraro Fabio Ghislandi Stefano Pistorio Dimitri Favre Blaise Paolopoli Francesco Racanati Corrado De Sanctis Vuoi contribuire anche tu come autore? manda una mail ad [email protected] oppure partecipa alla Call For all’indirizzo https://sessionize.com/call-for-agile-for-italy/ 6

Chi siamo Per rispondere alle crescenti richieste del mercato della business information e dei suoi clienti ed operatori abbiamo progressivamente applicato le nostre competenze ed i nostri servizi fino a diventare «un network di competenze globale» caratterizzato da una molteplicità di esperienze, ampiezza e varietà di offerte, dalla capacità di mettere in campo nuove sinergie. Perchè noi Grazie alla combinazione dell’approccio innovativo e della capacità realizzativa, unito alla conoscenza della tecnologia e alla capacità di innovare i processi di business, affianchiamo i nostri clienti per aiutarli a ridurre i costi e produrre un reale vantaggio competitivo utilizzando metodologie consolidate a supporto delle fasi realizzative, infrastrutture esistenti a livello locale e globale e alleanze tecnologiche. Dove siamo Sintegra è costantemente al fianco dei propri clienti in qualsiasi parte del territorio italiano ed europeo. Gestisce inoltre un proprio laboratorio di sviluppo dove vengono testate tutte le più innovative tecnologie di mercato e vengono prodotte le nuove soluzioni di integrazione software e di project management. Sintegra S7rl Via Falcone, 7 20123 Milano Tel: +39 02-4555-9982 www.sintegra.it

Il Gruppo è costituito da professionisti prima che collaboratori. Il forte legame Amici che da molto tempo ci accompagnano in questa sfida al primato nel che è cresciuto in anni di stima reciproca ci ha plasmati rendendoci empatici. nostro settore non sono soltanto consulenti capaci e motivati ma soprattutto E’ questa la nostra ricetta segreta per regalare ai nostri clienti servizi e campioni del mondo in cui vivono, dell’era tecnologica che cavalcano. consulenza con inusuale serietà e professionalità soprattutto in ambito di informazioni commerciali ed informativa finanziaria. Questi ed altri attori vorremmo riportare all’interno del nostro prezioso bouquet di conoscenza, sul palcoscenico che oggi calpestano interpretando I tanti successi raccolti giorno dopo giorno hanno reso unica la quotidianità l’ambito ruolo di protagonisti della tecnologia dell’informazione. fatta soprattutto non di impegno e lavoro ma di passione e volontà. I nostri I nostri servizi Spieghiamo meglio Il nostro plus Consulenza strategica per lo sviluppo di prodotti Quando un nostro cliente ci chiede Fare la differenza è un modo di dire proprietari nell’ambito delle informazioni riservatezza e rispetto delle normative vigenti lungamente inflazionato e raramente commerciali in materia di privacy e codici deontologici utilizzato per definire il processo che ha noi siamo in grado di isolare, anche portato al reale vantaggio competitivo in cui Fornitura di sistemi in outsourcing completo geograficamente e/o temporaneamente, ci si trova o ci si troverà. per la gestione dell’approvvigionamento delle una completa struttura dedicata; da quel informazioni dalle varie fonti primarie e secondarie momento analisti, sistemisti, programmatori È proprio per questo motivo che non ci e pm saranno «dedicati»; da quel momento interessa lavorare in settori per i quali non Fornitura e personalizzazione di prodotti di e per tutto e solo il tempo richiesto sistemi, possiamo fornire prestazioni di eccellenza elaborazione di primo livello dell’informazione locali, sicurezza e sorveglianza saranno e per questo motivo che i nostri clienti raccolta adeguate. non devono preventivare un periodo di Normalizzazione, deduplicazione, organizzazione formazione al momento del nostro ingaggio, ed estrazione delle informazioni raccolte anche La nostra presenza è, se necessario, e per questo motivo che i nostri clienti da fonti eterogenee discreta ed immateriale. I nostri sistemi di devono pretendere la professionalità che remotizzazione e gli innovativi sistemi di solo chi lavora in questo settore da sempre Adeguamento delle procedure aziendali ed gestione dell’application management (e può dare, e per questo motivo che i nostri integrazione con i sistemi terzi rispetto ai nostri del facility management se richiesto) ci documenti di assessment sono gli unici clienti. permettono di non «pesare» in alcun modo nel campo della cost reduction a poter nell’economia e nella privacy dei nostri clienti. vantare percentuali elevatissime di risparmio Gestione delle più complesse procedure di realmente conseguito dai nostri soddisfatti contrattualizzazione e gestione di gare ed appalti I nostri professionisti riescono a supportare clienti, e per questo motivo che nel nostro nazioni ed internazionali. anche i clienti più esigenti perchè forniscono campo i competitor... non esistono. consulenza anche di tipo strategico e Internazionalizzazione reale o virtuale delle commerciale e possono, dove richiesto, applicazioni legacy gestire un CED, un prodotto, una procedura Gestioni di fonti improprie in completa autonomia e sempre «chiavi in mano».

 Scrum Master, Agile Coach e Product Owner soffrono essenzialemente di una sindrome ossessivo- compulsiva (sconosciuto)  AgileItalia 9

Editoriale di Tiziano Interlandi, Davide Casari, Pierpaolo Cimirro Appuntamenti 2020 sicuramente un anno interessante Il 2020 sarà sicuramente un anno interessante per la sivamente all’universo People, APC un camp (costo numerosità delle iniziative presenti sul suolo italiano. vitto e alloggio) e APD (necessario acquisto biglietto). Sarà l’anno in cui parleremo tanto di Agile People, APC è un camp in chiave open conference, mentre tema ormai predominante delle varie conferenze e APD prevede 6 talk frontali. Di sicuro rilievo è il Coach che speriamo possa trasformarsi da buuzzword a ef- Camp, ormai attivo da diversi anni ed in lingua ingle- fettiva e sentita presenta di chi si occupa di HR. Te- se. I diversi camp hanno la formula del pagamento nendo fermi i due eventi nazionali, ABD e IAD, abbia- del vitto-alloggio, spesso ampliabile anche a familiari. mo molte riconferme (Agile for Innovation, Vimercate) ABD e APD sono eventi a pagamento. e molti Camp. Partiamo dai primi due dedicati esclu- Non dimenticate di frequentare i diversi Meetup sul $ novembre 2020 Milano Varignana Dimaro TBD 4 marzo 28 marzo 28-30 maggio 11-12 settembre $ 1 Febbraio 6-8 marzo 23 maggio Milano Venezia Montegrotto Terme (PD) Vimercate AgileForItalyMilano Agile Reloaded Meetup AgileForItaly Milano Scrum/Agile User’s Vodafone CatchUp VIsione Agile Group Avanscoperta Agile Community Torino Scrum Agile Milano Interlogica Meetup Agile Talks I meetup presentati sono quelli a noi conosciuti, aiutaci segnalandoli a [email protected] 10

vuoi essere autore in questo magazine, registrare un podcast con noi, essere intervistato o parlare ad un Meetup? Call For.... oppure manda una mail a [email protected]

Una diversa visione del project management, la commistione di frameworks: agile, lean, devops,kanban di Stefano Pistorio Riorganizzare e cambiare visione vuol dire abbraccia- patori vedono solo il proprio flusso, quello che permet- re anzitutto una vision “del tutto”, olistica, dall’alto. Nella te di portare il proprio task verso il deploy. Interagiscono gestione dei progetti e quindi delle persone passare da poco con gli altri membri del team e non hanno assoluta- una “non organizzazione” ad una organizzazione vuol dire mente idea della vision del progetto. Nessun sviluppatore scegliere nuove metodologie. Ma quali? può realmente considerarsi responsabile del proprio la- E se volessi unirle, intersecarle è possibile? voro perchè non c’è alcuna organizzazione, nessuno sa su In questo articolo provo a dimostrare che è possibile e quale task sta lavorando l’altro, non c’è un release plan. che alla base di Agile c’è un concetto non scritto che ci Volendo introdurre dei cambiamenti in questa gestione aiuto a non fossilizzarci su regole e metodi come abbia- “non gestita” del progetto, è obbligatorio affidarsi ad un mo fatto per anni almeno nel mondo IT. framework e attenersi totalmente alle sue direttive op- Un caso comune pure possiamo integrare e incrociare tecniche, strumenti, Nell’ambito del project management e senza scomoda- metodologie? re alcun framework, posso tranquillamente dire, almeno Proverò a rispondere a questa domanda. nella mia più che ventennale esperienza, che il modello La Vision waterfall non è l’unico. Esistono altre modalità per gesti- Vediamo ancora come un progetto non gestito può pro- re un progetto in cui l’unico prerequisito è avere un’idea cedere. iniziale, più o meno chiara, della necessità da parte del Nel corso dei rilasci il prodotto inizia a prendere forma e cliente. naturalmente anche le richieste di modifica da parte del Uno scenario è il seguente. Il cliente ha una necessità o cliente così come le richieste di correzione bachi. Quasi un’idea che viene inizialmente discussa assieme ai “tec- nulla è documentato, le richieste sono fatte via mail o al nici” al fine di estrapolare un’analisi, quasi sempre non più nel corridoio antistante l’ufficio, se proprio siamo all’a- scritta. vanguardia abbiamo un timido sistema di ticket tracking, Chi sono i “tecnici”? Sono gli sviluppatori, che in genere quasi fosse la panacea in questo marasma. sono anche i tester gli integratori e coloro che rilasciano Le richieste vengono accolte secondo una modalità “an- il prodotto o servizio. In quest’ambito non sempre esiste siolitica”. In pratica lo sviluppatore porta a termine prima il una figura di project manager quindi gli sviluppatori sono requisito che lo preoccupa di più o che preoccupa di più gestori e non solo di se stessi e del proprio lavoro ma il cliente. Se però è venerdì allora implementerà quello anche del proprio flusso: produzione del software, test, più breve così lunedi non si dovrà ricordare a che punto integrazione e deploy. Un esempio di team auto-gestito era arrivato. Ah! Naturalmente in quest’ultimo caso, pur ma sicuramente non motivato!! essendo venerdì, termino lo sviluppo, faccio qualche test Attenzione a non confondere questa visione come una (se ho tempo) e ...rilascio!! In produzione ovviamente! sorta di system thinking. In questo caso infatti gli svilup- Ma cosa sto sviluppando? Quale contributo sto dando e dove stiamo andando? 12

A queste domande non è possibile rale ma non nel senso di più “distante Abbiamo quindi preso in considerazio- dare risposta perché non esiste una da” ma più dall’alto. Una visione oli- ne due framework Scrum con Kanban vision del progetto. stica che ci fa comprendere il tutto e e Lean. Volendo quindi dare una degna or- dalla quale possiamo partire per crea- Lean ha origine in Giappone presso ganizzazione al nostro progetto cosa re il nostro nuovo modello di progetto la Toyota con il nome di Toyota Pro- possiamo fare? Sicuramente dobbia- e di relazione con le persone. duction System (TPS). Le sue basi mo evitare di infilarci in un’altra rigi- Il Team vengono sviluppate da Taiichi Ohno dità. Il primo step del cambiamento deve e Shigeo Shingo durante gli anni ’50. Di fronte a questo scenario è neces- agire sul team. Occorre cambiare pas- Successivamente, negli anni ’90, gra- sario un cambio di visione e di cultura. sando, come abbiamo detto, ad una zie al libro “The Machine That Changes Quali strumenti ci vengono incontro? vista più sistemica. Scrum ad esempio the World, Lean Thinking and Lean So- Una visione sistemica consente di cambiare le abitudini del lutions” di James Womack and Daniel Siamo in un’ottica di cambiamento. team introducendo un ritmo, una se- Jones, viene formalizzato con il nome Non vogliamo più gestire i progetti in quenzialità delle fasi, dei meeting in di Lean, consentendo alle aziende di questo modo, vogliamo strutturarli. cui confrontarsi, delle priorità nei task. adottarlo in modo strutturale. Ma i progetti non hanno di per sé una In Scrum il development team ha re- Agile è decisamente più giovane: la personalità, non sono persone, non sponsabilità e libertà di decidere come sua origine è databile agli inizi del sono oggetti. Strutturare un progetto organizzare il lavoro e come realizzar- 2001 quando un pool di esperti di svi- vuol quindi dire strutturare le persone lo ma sempre in un’ottica condivisa. luppo software danno vita al famoso e quindi l’azienda. Il team lavora insieme, fisicamente Manifesto, che ne definisce i valori ed Stiamo parlando di cambiare visione. nella stessa stanza e attraverso i daily i principi. L’obiettivo è costruire ciò che interes- meeting realizza una comunicazione E’ possibile però integrare i principi sa agli stakeholder ma per farlo bene continua. Agile e Lean in modo da avere una è necessario che i componenti del L’approccio Scrum prevede inoltre un commistione di tecniche e di proce- team abbiano una visione olistica. continuo miglioramento attraverso re- dura finalizzate a migliorare la condu- A tal proposito ci viene in aiuto la sto- view e retrospective meeting. Scrum zione del nostro progetto? riella dei sei ciechi e dell’elefante, che sfrutta l’impegno del team come Nell’IT abbiamo passati lunghi anni ad qui sintetizzo. agente di cambiamento. adottare la metodologia cosiddetta Sei persone cieche dalla nascita ten- Ma non è sufficiente. waterfall. Fasi ben definite, moltissima tano di capire cosa sia un elefante Il Flusso documentazione, pochi spazi alle mo- ovviamente non avendolo mai cono- Occorre lavorare sul flusso, per esem- difiche in corso d’opera, tempi lunghi sciuto e visto. Ognuno di loro cerca di pio utilizzando il framework Lean. di rilascio tra un deliverable e l’altro, farlo attraverso il tatto concentrandosi I principi Lean si concentrano sul flus- rilasci complessi. Un framework molto chi sulla coda, chi sulla testa, chi sul- so più di ogni altra cosa: i colli di bot- rigido. le zampe, ecc. Siccome ognuno tocca tiglia nel processo devono essere ri- Ma anche la “non gestione” di cui ho una parte diversa il risultato saranno mossi e le attività dispendiose devono già parlato è di per sé un framework. sei interpretazioni diverse che non si essere identificate ed evitate. Potremmo infatti codificarne alcuni integreranno fra di loro. Non si avrà Lean si concentra sul processo, sulla aspetti e notare come sono ricorrenti una visione sistemica del tutto e le visualizzazione del lavoro da fare, l’i- tra un progetto e l’altro. parti di oggetti descritte, anche molto dentificazione degli sprechi e passa Se proprio vogliamo abbandonare bene nel dettaglio, saranno comun- la ownership del flusso al cliente. La questi modelli è auspicabile adottar- que diverse dall’insieme delle parti. produzione infatti è pull: tirata dalle ne di più duttili, dove la diversità è ric- Chi non ha sperimentato queste pro- necessità del cliente. In questo senso chezza e la visione olistica del tutto blematiche in progetti con scarsa or- è molto utile introdurre Kanban negli (leggasi progetto o azienda) è un pre- ganizzazione alzi la mano! stessi Sprint. Kanban ci aiuta ad avere requisito importante. Cambiare vuol dire passare dall’osser- una visualizzazione del lavoro, dello vazione (in senso generale del termi- stato e di chi prenderà in carico cia- ne) del particolare a quella del gene- scun task. Dal particolare al generale passando dall’alto 13

Lean - Agile Il dev team (al massimo di 9 persone se- che mi è sempre piaciuta: patchanka. Iniziamo quindi a confrontare e a trovare i condo le direttive Scrum) è composto da In italiano si pronuncia pacianca. Non se punti di contatto tra Scrum e Lean. persone cross-funzionali, che lavorano ne conosce l’etimo certo ma si può inter- In Lean dobbiamo: fisicamente insieme, che stanno insieme pretare come un genere musicale carat- ● identificare ciò che vale (value) indi- per un lungo periodo al fine di consolidare terizzato da una commistione di stili mu- viduare ciò per cui i clienti sono disposti a la conoscenza reciproca. Insomma un fe- sicali diversi, che rimandano a punk, ska, pagare un prezzo ature team in grado di portare a termine, reggae, rock, funk, rap e molto altro. ● identificare il flusso del valore (va- ad esempio, il task di assemblaggio dell’e- Ho esordito in questo articolo dicendo che lue stream): allineare le attività che creano lefante. Nel team avremo le persone spe- per migliorare ed uscire da disorganizza- valore nella giusta sequenza cializzate nelle gambe, quelle esperte con zione o, da eccessiva organizzazione, è ● far scorrere il flusso del valore la testa, quelle esperte di coda e così via opportuno abbracciare un pensiero siste- (flow): mettere in atto le attività a valore e naturalmente gli esperti di integrazione mico, olistico e più generale. La visione del senza interruzioni e test. tutto, termine sempre più presente anche ● fare in modo che il flusso sia tirato Il team è considerato un tutt’uno e come in altre discipline esoteriche e nella fisica (pull): fare scorrere il flusso in base alle ri- tale, nel suo complesso, ha tutte le skills quantistica. chieste del cliente necessarie a portare a termine il proprio Non pensiamo alle singole parti ma al tut- In Scrum viene creato il Product Backlog lavoro, è un team auto-organizzato e che to... da parte del Product Owner. Il backlog è la ha come focus massimizzare il valore per Un ingegnere fisico, ricercatore, e autore rappresentazione tramite user story delle il cliente e non il numero di linee di codice di numerosi libri e seminari, Vittorio Marchi, necessità del cliente (Value) che vengono prodotte da ciascun membro. tra i suoi illuminanti pensieri parlava pro- eseguite secondo priorità (value stream) Lean – Agile - Devops prio di questo concetto che provo a ripor- definite dal PO, che è la “voce” degli sta- In Scrum il rilascio avviene al termine di tarvi con parole mie. Se io prendo un bic- keholder. Gli item selezionati dal develop- uno Sprint e dopo lo sprint review meeting. chiere d’acqua dal mare, posso dire che ho ment team sono quelli ad alta priorità e E’ possibile integrare tecniche Devops per ottenuto qualcosa di diverso? Ovviamente che hanno tutti i dettagli necessari (flow). massimizzare i rilasci e ottimizzare il valore no, è solo un modo diverso di vedere la Il flusso è pull infatti nel review meeting per gli stakeholder, fermo restando che un stessa cosa. E’ quindi solo un problema di le priorità del backlog possono cambiare task, prima di essere rilasciato, deve sod- visione, osservando più dall’alto il mare e a seguito di richieste del PO o degli sta- disfare i done criteria e i criteri di accetta- il contenuto del bicchiere ci appariranno keholder. zione. Lo sprint review infatti è un modo o come la stessa cosa. In Scrum è inoltre intrinseco identificare ciò un’opportunità per avere il feedback degli La direzione che ho voluto qui delineare che non è importante (waste), si dice infat- stakeholder ma non vieta i rilasci anticipati. è quella della commistione (patchanka) di ti “se non è presente nel product backlog Oltretutto rilasci ed integrazione continui framework: allora non esiste”. Il backlog è realizzato in facilitano la correzione di eventuali com- Scrum, Lean e Devops. Non vedere lo base alle reali necessità del cliente. portamenti che non soddisfano il cliente. Sprint come scolpito nella pietra ma per- Il visual management in Scrum è realizzato Conclusione meabile di miglioramenti continui anche attraverso l’utilizzo di diverse board in cui Nel mondo della musica esiste una parola nella sua stessa definizione. tutti i componenti del team possono aver Ogni cosa evolve in questo nostro univer- accesso. Kanban può essere integrato in so, anche le metodologie di progetto. Scrum portando un ulteriore vantaggio. Bibliografia http://www.mokabyte.it/2015/09/devops-2/ http://www.mokabyte.it/2015/09/loversbeergame-1/ https://www.scrum.org/index.php/resources/blog/scrum-and-devops https://agileweboperations.com/2012/07/12/lean-agile-devops-related/ La quinta disciplina. Peter Sege Stefano Pistorio Stefano Pistorio è project manager presso ePress S.p.A a Milano. E’ Scrum Master certificato e appassionato di «Agilità» guardandola da un punto di vista sistemico e olistico. Applica la metodologia Scrum ai progetti che segue. E’ molto interessato alle dinamiche di gruppo nel team, ha più di vent’anni di esperienza nel settore IT dove ha ricoperto diversi ruoli, dallo sviluppatore al responsabile di progetto. Ritiene che l’evoluzione Agile vada di pari passo con l’evoluzione personale e quindi investe continuamente su se stesso s sulla sua formazione. 14

Vito Semeraro  Dopo una lunga esperienza come web designer sono passato alla gestione di progetti digitali prima in Seat Pagine Gialle e successivamente in Purple Network. L’incontro con Agile mi ha permesso di modificare molto il mio mindset e il modo di lavorare. Ogni giorno contribuisco al miglioramento dei processi in startup e aziende con l’obiettivo di evolvere prodotti e applicativi digitali.  15

EVOLUZIONE DEL MODELLO OPEN SOURCE VERSO IL MODELLO OPEN SAAS di Vito Semeraro In questo articolo scopriremo, partendo del cyberpunk (che professava uno stile più disparate; dalla storia dell’Open Source, come i mo- di vita lo-fi ma al contempo proteso verso -● localizzazione: essendo gestito da una delli di business a pagamento intorno al le possibilità offerte dalla tecnologia) si è community eterogenea supporta pecu- software libero si sono evoluti, per mini- evoluto soprattutto in ambito sistemisti- liarità diverse (es: lingue). mizzare rischi e costi di startup e massi- co e applicativo trovando sostentamento Ogni software libero è comunque tute- mizzare la soddisfazione degli utilizzatori principalmente nelle donazioni, sponso- lato da consorzi (Open Source Initiative) del software e di chi ci lavora. rizzazioni e formazione relativa all’utilizzo. e una miriade di licenze (la GNU-GPL e Queste considerazioni sono frutto dell’e- Le caratteristiche di un progetto sono l’ade- MIT tra le più note, raccolte dalla macro sperienza vissuta da un team che ha evo- renza ad alcuni principi facilmente intuibili: FOSS). Alcune ne proibiscono l’uso per fini luto il progetto Open Source forma.lms ●- accessibilità: tutto il codice è accessibile di lucro ma permettono tutti gli altri utiliz- verso un servizio in SaaS, Forma Cloud. e documentato su repository pubblici; zi. Quindi un software Open Source può Caratteristiche di un progetto Open ●- transparenza: il codice è ispezionabile, essere usato liberamente anche per fini di Source scaricabile e testabile da tutti; lucro, l’importante è che venga rispettato Intorno agli anni novanta, grazie alla diffu- -● perpetuità: il codice si evolve teorica- il principio dell’accessibilità, quindi mante- sione di internet e la possibilità di scam- mente all’infinito grazie al contributo di nendo il codice sempre aperto e disponi- biare velocemente opinioni e soluzioni, le una o più community; bile. barriere imposte dai software a pagamen- ●- interoperabilità: più persone lavorano su Il modello di sviluppo di un progetto Open to iniziarono a vacillare. aspetti diversi del software evolvendolo e Source è molto vicino ai principi Agile e si Questo movimento, vicino alla subcultura senza intaccarne la qualità; basa su: ●- flessibilità: non si hanno vincoli di costi, li- cenze rendendolo flessibile alle esigenze 16

Modello di sviluppo Open Source Collaborazione Sullo stesso repository lavorano più persone che si aiu- tano a vicenda per evolvere verso un obiettivo comune Rilasci ravvicinati più sono ravvicinati i rilasci e maggiore è la qualità del software rilasciato Integrazioni incrementali Permettono di evolvere il software sviluppan- do solo quanto strettamente necessario Partecipazione Le decisioni sulle evoluzioni vengono prese in modo comunitario e sen- za gerarchie, permettendo al team di lavorare in una condizione di auto commitment proficua ed ingaggiante. Questi principi rendono di fatto il software Modelli di business intorno o issue creato dal basso: sfruttano le diverse all’Open Source ●- Formazione sull’utilizzo lato utente o esigenze e skill dei partecipanti al progetto implementazioni custom e permettono agli applicativi di seguire Ci sono vari modi per rendere sostenibile la ●- Consulenza sulle strategie aziendali da i trend di mercato velocemente e senza crescita e la manutenzione di un software implementare per l’utilizzo gerarchie frenanti. Open Source oltre al lavoro di chi lo -● Erogazione di servizi a pagamento supporta. Qui di seguito le maggiori fonti di intorno al prodotto, es: hosting Sono molti gli aspetti che creano valore proventi, divise tra passive (non richiedono nei progetti Open Source, oltre che per effort da parte degli sviluppatori) e attive, i contributori anche per gli utilizzatori; da cui si possono creare entrate costanti. nonostante sia convinzione comune che i progetti Open Source creino vantaggi Passive prevalentemente alla community, in realtà ●- Donazioni da enti società o individui permettono di raggiungere standard di -● Eventi sponsorizzati da aziende qualità pari a quelli dei colossi della new- commerciali economy gratuitamente, senza richiedere Attive finanziamenti o investimenti particolari per ●- Supporto a pagamento fornito per bug chi ci lavora. 17

Da Open Source a Open Core Le entrate attive si configurano come modello Open Core, ov- vero erogare servizi a pagamento intorno a uno o più nuclei di codice Open Source. Servizi come il supporto e il troublesho- oting, lo sviluppo di funzionalità proprietarie sono una valida fonte di entrate per le aziende che lavorano su prodotti Open Source, ma non altrettanto sostenibili dato il segmento infla- zionato e le complessità da gestire. Altro punto a sfavore è la difficoltà di scalare questo genere di business senza richie- dere ingenti risorse umane e di tempo e non garantendo la sostenibilità del business nel lungo periodo. Da Open Core a Open SaaS Un boost al modello Open Core è arrivato dalla maggior ac- cessibilità del cloud storage e delle architetture server ridon- date come Amazon AWS e Google Cloud Platform. L’abbassamento dei costi fissi e la possibilità di scalare le macchine e adottare logiche di “dockerizzazione” hanno dato un impulso notevole ai Servizi in SaaS / PaaS, modello che si basa sulle sottoscrizioni in abbonamento di servizi e applica- tivi web based di vario genere e livello. Le soluzione in SaaS sono molto attraenti per i consumatori soprattutto per alcuni motivi: ●- Sicurezza (girano su infrastrutture altamente performanti con processi di data recovery avanzati) ●- Accessibilità (normalmente sono accessibili da più postazio- ni e più device) ●- Flessibilità (un servizio in SaaS può essere attivato per perio- di di tempo brevi, anche solo 30 giorni) I punti negativi invece sono: -● non si è proprietari del codice (non c’è possibilità di analiz- zarlo se non funzionalmente con le trial, né tantomeno mani- polarlo); ●- si è soggetti a cambi di funzionalità / prezzo (non si ha visi- bilità sulle roadmap di progetto); -● impossibilità di migrare verso altri provider (essendo un co- dice chiuso non è contemplato il porting dell’applicativo su un’infrastruttura proprietaria). Si può definire Open SaaS il modello in cui viene sviluppa- ta un’architettura/infrastruttura che permetta di erogare il software libero in Cloud, mediante abbonamento mensile o annuale. Questo approccio ibrido può portare i benefici di due mondi a sé (quello libero dell’Open Source e quello Enterprise SaaS) da cui poter evolvere costantemente un progetto in modalità Open Source ma fornendo agli utenti SLA ben definiti e rassi- curanti. Ecco una tabella riassuntiva dei vantaggi portati agli utenti dal modello Open SaaS rispetto all’Open Source e al SaaS: Open Source SaaS Open SaaS Codice libero Codice proprietario Codice del core libero Assenza di supporto Supporto incluso Portabilità del codice Il codice vive solo in cloud Supporto incluso secondo KPI definiti Codice aperto Chiusura ai contributi esterni Possibilità di usare l’applicativo sia in Cloud che Necessità di effort lato sistemistico On Demand su infrastruttura chiusa onPremise Codice del core aperto Può essere attivato On Demand o su infrastruttura cliente 18

Ma lato evoluzione del software cosa cambia? Anche qui i benefici di avere un modello Open SaaS sono molteplici: -● poter contare su una community che alimenta, innovandolo a titolo gratuito, il nucleo upstream del codice; -● poter migliorare le performance di un dev team che deve interfacciarsi con la community per la scrittura del codice downstream (quello di produzione del prodotto SaaS); -● poter diminuire drasticamente il technical debt del codice downstream; -● essere competitivi con colossi della new economy anche senza avere le stesse risorse; -● Innescare un circolo virtuoso dove il software in SaaS porta migliorie (bugfixing, evolutive) verso il nucleo upstream del codice e viceversa. Ovviamente una domanda viene spontanea: Conclusioni, il caso forma.lms non è rischioso strutturare un business intorno a un prodotto Open Source che potrebbe essere Negli ultimi 6 anni in forma.lms siamo stati protagonisti di utilizzato da un competitor per la stessa finalità? questa transizione, sperimentando su noi stessi tutti e tre i Un minimo di rischio c’è ma molto basso. Infatti livelli precedentemente descritti. potenziali concorrenti dovrebbero modificare Siamo partiti dal lavorare su un progetto Open Source nato una quantità di configurazioni, processi e sistemi da un fork circa 6 anni fa ed evoluto principalmente per per poter adattare il proprio business al software esigenze aziendali interne di alcune delle quattro società Open Source e alla sua erogazione in SaaS. fondatrici. Inoltre occorrerebbe diverso tempo per ricreare Data una sempre maggiore domanda di formazione a alla base la stessa community, rendendo di distanza da parte delle aziende clienti è andato via via ad fatto il business case non sostenibile. aumentare l’indotto intorno al progetto LMS, testando quindi la modalità Open Core. Vito Semeraro Solo nell’ultimo anno le richieste di erogazione del software  in SaaS si sono decuplicate permettendoci di sviluppare un sistema di deploy in Cloud dell’applicativo. Dopo una lunga esperienza come web designer sono passato alla gestione di progetti digitali prima in Seat Questo non ha minato però la fiducia nelle potenzialità Pagine Gialle e successivamente in Purple Network. dell’Open Governance, anzi le ha rafforzate come lo dimostra questa analisi: forma.lms resta e resterà un progetto L’incontro con Agile mi ha permesso di modificare alimentato dal basso e fieramente Open Source. molto il mio mindset e il modo di lavorare. 19 Ogni giorno contribuisco al miglioramento dei processi in startup e aziende con l’obiettivo di evolvere prodotti e applicativi digitali. 

Vuoi aiutarci a crescere? Cerchiamo Sponsors scrivi a [email protected] 20

Blaise Palopoli  Blaise Palopoli, nato in Francia il 5/9/89. Cresciuto a Roma. Mi laureo in matematica teorica nel 2014. Comincio a lavorare per la Conte.it, società assicurativa ramo danni poco prima di laurearmi. Lavoro nel dipartimento di BI come sviluppatore dwh, curo soprattutto le informazioni per il marketing e la management information. Nel 2017 divento product owner del team di BI. A settembre 19 divento product owner del team di risk selection, il team di delivery delle epiche volte a migliorare la selezione del rischio della compagnia. Ho un grande interesse per il mondo agile e le sue implicazioni su tutta l’infrastruttura societaria.  21

Accorciamo il ponte tra Business e IT di Blaise Palopoli A combattiamo le barriere tra IT e Business chiari i benefici di un’epica rilasciata, diventa molto difficile essere Agile. far raccontare al referente di business i Ciao a tutti, mi chiamo Blaise e sono Quante volte abbiamo visto il nostro team benefici che hanno portato gli sviluppi Product Owner in ambito insurance di sviluppo non realizzare la potenza del fatti. Per esempio: dopo l’integrazione di da poco più due anni. Oggi lavoro lavoro che fanno? Quante volte abbiamo questo nuovo servizio, la soddisfazione dei con un team di delivery di epiche avuto l’impressione di non riuscire a nostri clienti è aumentata di X, portando finalizzate all’ottimizzazione del prezzo coinvolgere le persone del team? Di non numeri e prove (tanto loro avranno già dell’assicurazione. L’argomento che farli sentire a bordo di progetti? Quante dovuto preparare con ogni probabilità vorrei condividere con voi oggi mi è volte il team di sviluppo si sente un mero questi indicatori per il management, quindi molto a cuore: si tratta della distanza tra esecutore di decisioni prese da altri? Non questo non comporta lavoro aggiuntivo). business e IT. solo, mi è capitato di vedere Product -● Prendere dei momenti dedicati per In fondo un Product Owner è esattamente Owner che si sentono dei semplici raccontare come sta andando la società il ponte tra business ed IT, e credo che uno ‘spostatori di post-it’ e di non sentire nella sua interezza: questo crea un senso degli obiettivi di un buon PO sia quello di nessuna responsabilità nella visione del di appartenenza incredibile. accorciare il più possibile questo ponte. prodotto. -● Parlare spesso con gli stakeholder, Quello che vorrei fare con questo articolo Queste problematiche sono complesse per capire le loro idee, i loro problemi è illustrare le problematiche che un e legate a tanti fattori, ma, in maniera ed insieme trovare soluzioni! Questo approccio che separa IT e Business iterativa incrementale, si può cominciare permetterà al PO di diventare parte comporti, i benefici che l’abbattimento di a fare qualcosa per risolverle. Di seguito integrante del processo di definizione di tale barriera possa generare, e qualche qualche spunto che ho applicato e che ha visione del prodotto. piccolo accorgimento per cominciare dato ottimi risultati: a scardinare questa mentalità, ancora ●- Chiedere al referente di business di Si tratta quindi di intensificare i momenti troppo spesso radicata in noi. raccontare al team il valore dell’epica in cui il team respira il business; le cose Se riguardiamo i principi dell’Agile (cosa che si lavorarà nelle prossime iterazioni; poi verranno da sé. che penso dovremmo fare più spesso chiedere di raccontare come è nata Nel nostro caso questi spunti hanno invece di litigare sul fatto che sia meglio l’idea, come è stata sviluppata, fino alla portato tantissimo valore, in termini di Safe, Scrum o XP...) troviamo interazioni definizione dello Use Case che il team è coinvolgimento e reattività del team; ed individui, apertura al cambiamento, portato a lavorare. addirittura ora è lo stesso team che collaborazione. Nelle strutture dove non -● Pretendere che il business partecipi propone miglioramenti (non tecnologici, alle demo: c’è niente di più deprimente e ma per cambiare la vita al cliente) al 22 controproducente di una demo deserta. business. Si crea una sinergia e un -● Fare quello che chiamiamo «retro entusiasmo contagiosi, che ci stupiscono testing». Dopo un periodo di tempo ogni giorno di più. abbastanza lungo, al fine di avere

Il lato umano dell'Agile 6-7-8 marzo 2020 - Montegrotto Terme (PD) Reason Why Viviamo in un’epoca in cui le aziende utilizzano strumenti e competenze tecnologiche da XXI secolo, e pratiche manageriali da XIX secolo. Veniamo attratti e andiamo a collaborare con organizzazioni che espongono visioni futuristiche, e poi ci ritroviamo a convivere con orrori quali avere una leadership inadeguata, zero comunicazione, zero cultura di collaborazione, nessun attitudine ad aiutarsi l’un l’altro. A bad system will beat a good person every time. W. Edwards Deming Parallelamente, sono passati circa vent’anni dalla redazione dell’Agile Manifesto for Software Development e sempre più le tematiche che emergono dalla community si espandono dal mero sviluppo software, abbracciando tutti gli aspetti del knowledge working: design, management, leadership, marketing, contratti, human resources… Proprio su quest’ultima tematica vogliamo creare un community di persone interessate a mettere a terra una serie di principi condivisi, a formulare esperimenti, condividere pratiche, raccontare esperienze con l’obiettivo di migliorare l’ecosistema lavorativo del knowledge working - the Agile Way! Il formato Agile People Camp sarà focalizzato sul concetto di Agile People a 360°. Camp, ovvero una Un-conference, perché l’esperienza degli ultimi anni nell’organizzazione e partecipazione a questo tipo di eventi (Agile Coach Camp, Product Ownership Camp, Socrates) ci convince sempre di più che siano il modo migliore per creare legami forti e duraturi tra le persone, stimolare la creatività, e perché no, rilassarsi e divertirsi tutti insieme. Perché dovrebbe interessarmi? Sei un HR Manager, un C-level, un Coach, o genericamente hai il desiderio e l’influenza per poter innescare cambiamenti nel lato “umano” delle organizzazioni di knowledge workers? Ritieni che le tematiche relative al “lato umano dell’Agile” siano importanti? Allora pensiamo che il tuo contributo sia molto importante per noi. E che il nostro contributo possa essere importante per te. Location Hotel Mioni Royal San Piazzale Stazione, 10 - 35036 - Montegrotto Terme (PD) A g i l e I t a l i a 23

Corrado De Sanctis  Addicted Agile. Coaching teams & organisations (Scrum, Kanban, Lean, SAFe, Spotify), Atlassian, Community organizer  24 24

Incontrando Doctor Scrum di Corrado De Sanctis (e uncle Bob) Qualche giorno fa ho avuto l’opportunità alla fine degli anni ‘80. Framework di incontrare Jeff Sutherland durante un La prima bozza di Scrum, Jeff la fa risali- E’ chiaro che parlare di Scrum con Doctor evento di presentazione di Scrum@Scale re al 1993 (con alcune idee applicate già Scrum e di XP con uncle Bob, è il massi- e al termine abbiamo avuto la possibilità a partire dal 1983). Due anni dopo incon- mo che si possa pretendere e quindi l’oc- di scambiare informalmente 4 chiacchie- tra Ken Schwaber che allora lavorava in casione non si poteva perdere. re. Qualche giorno prima ho avuto analo- modalità waterfall (e si lamentava degli ga opportunità anche con Robert Martin insuccessi) e lo invita a utilizzare questo (uncle Bob per tutti), una autorità di XP e nuovo approccio. Sarà poi Bob che rac- un altro dei firmatari originari del Manife- conterà che un paio di anni dopo (fine anni sto. ‘90) che Ken gli aveva chiesto un paio di Non accade tutti i giorni di avere la possi- team a cui insegnare Scrum seguendo bilità di parlare con personaggi che tanto una bozza di quello che diventerà il corso ha fatto per il movimento Agile e in diversi per la certificazione CSM. mi hanno chiesto di parlarne, ho pensato Quando poi Jeff racconta dell’incontro con quindi di scrivere un articoletto che mette Brian Kernigham ai laboratori Bell diventa insieme un po’ di concetti emersi. Lungi assolutamente esilarante facendoti im- da me l’idea di considerarla una intervi- maginare loro due insieme a Ritchie con sta men che meno la pretesa di esplorare una birra in mano a discutere di sviluppo la personalità di entrambi, tuttavia sono software e team di piccole dimensioni emersi alcuni spunti di riflessione interes- che operavano con tecniche di “guerri- santi e soprattutto alcune conferme. Un glia” contro gli eserciti di sviluppatori wa- articolo che ha anche aspetti personali e terfall controllati da pochi comandanti/ non solo tecnici. manager. Nota: di seguito li chiamerò Jeff e Bob, Segnalo infine che Bob aveva proposto i non certo perché mi sentano così familia- Caraibi per il ritrovo che poi ha portato alla re, ma solo per rendere la lettura più velo- scrittura del Manifesto, ma si dice conten- ce. Spero mi perdoneranno. ;-) to che alla fine siano andati in Utah, altri- Aneddotica menti non avrebbero mai trovato il tempo Va detto che Jeff è una fonte praticamen- di scriverlo essendo sempre in spiaggia. te 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) veni- va suonata la campana che segnalava un difetto. I dettagli del periodo e del luogo non sono stati chiariti ma eravamo intorno 25

La opinione di fondo di Jeff è che Scrum sia un processo per le prestazioni del team. Ma qual’è allora la misura della all’interno del quale applicare le tecniche XP e che la prestazione per un team? La risposta è immediata e non è combinazione dei due porti il massimo beneficio al team che Agile ma Lean: Process Efficiency; e a questo punto viene sviluppa software. Collegato a questo punto segnalo che per fuori il ricercatore. Infatti gli studi di più di 30 anni gli hanno Bob non esiste una vera differenza tra Agile e XP. Attenzione dimostrato che il processo di sviluppo software sia uno però che Agile e Scrum sono due cose diverse e per riportare le dei meno efficienti di tutte le industrie (circa il 1,25% in casi parole di Jeff “i valori di Agile riguardano il modo di PENSARE, fortunati) e che analizzando e applicando alcune semplici Scrum invece indica un modo fi FARE” un’idea che forse non è ottimizzazioni su questa metrica sia possibile arrivare a livelli così lontana da quella di Bob. del 5% con un incremento di 4 volte (il classico 400% degli Ma qual’è secondo il suo creatore la effettiva conoscenza di overperforming team?). E quale sarebbe il miglior modo per Scrum da parte della comunità? Qui Jeff risponde con un dato migliorare l’efficienza? Anche su questo punto la risposta di statistico: nella biblioteca IEEE ci sono 70 documenti originali Jeff è immediata: dare ai Product Owner il potere di decidere. di Scrum che vengono citati da quasi altri 1500 ma guardando Infatti secondo lui la perdita di efficienza è dovuto alla latenza le effettive letture sembra che in pochi leggano i documenti dei processi decisionali che attraversano gli strati organizzativi originali. (mediamente 7 in base alla sua esperienza); ma è evidente che Venendo alle cose più pratiche ci siamo soffermati su alcuni questo significa trasformare la organizzazione da una struttura elementi cardine del framework. gerarchica a una rete che collega team e “nuovi” leader. Per A parte ribadire quando scritto nelle Scrumguide (in particolare questo motivo accanto a Scrum per i singoli team, propone il sui ruoli: lo scrum master si occupa del processo, il product modello @Scale per le organizzazioni. owner del prodotto e il protocollo 3-5-3: 3 ruoli, 5 cerimonie In sintesi la componente “business” assume un ruolo e 3 risultati), la capacità di gestire il backlog è secondo Jeff fondamentale in un framework pensato (erroneamente solo) l’elemento di successo più rilevante: gestire le priorità e per i tecnici. Ed infatti Jeff concorda che la gran parte degli preparare in modo corretto le storie da proporre al team sono sforzi per rendere un azienda agile si devono concentrare nel i veri elementi di maturità, il resto viene come conseguenza business, che deve tendere a un coinvolgimento più profondo, e ha importanza minore: ad esempio lunghi Sprint Planning e nel management, il cui ruolo cambia radicalmente verso sono causati dalla mancanza di questi due elementi. Ma quale quello di “rimuovere gli impedimenti” ai diversi livelli. Per dovrebbe essere la corretta durata di uno Sprint Planning? Jeff ottenere la loro collaborazione la chiave continua a essere sostiene che 4 ore sia il massimo per sprint di 2 settimane, ma la “gestione delle priorità per aumentare la competitività che si possa fare in 1 ora e mezzo. attraverso una maggior velocità per andare sul mercato con i Quindi abbiamo parlato della Velocity che per Doctor Scrum prodotti giusti”. deve essere considerata una misura per il planning e non 26

I personaggi rispetto alla media e anche alla loro età è sempre un In un mondo di manager e esperti Jeff si considera un piacere parlare con loro anche se magari non condividi ricercatore (non a caso tutti lo chiamano Doctor) e in effetti tutto quello che dicono oppure anche se oggi ci sono lo si vede dal fatto che la sua maggior fonte di risorse sono approcci “più moderni” ai problemi che continuano però a i documenti IEEE e BHR. Inoltre da bravo intellettuale non essere gli stessi. ha anche nessun problema a parlare della “bancarotta” In ogni caso sia Scrum che XP hanno cambiato radicalmente della azienda. il mondo dello sviluppo software ed è molto interessante Interessante confrontarlo con la dichiarazione di Bob come (forse) li considerino facce della stessa medaglia (un che ha ammesso che ai tempi non aveva assolutamente po’ come Lean e Agile). creduto nel processo di certificazione di Scrum Master Entrambi, sia Bob che Jeff, c’erano prima del 2001, si sono proposto d Ken Schwaber che invece (anche sotto il ritrovati (con altri) in Utah nel 2001 a scrivere il Manifesto, e profilo economico) ha costituito una delle fondamenta del (anche se Bob ha escluso una “reunion”) ancora oggi sono successo di Scrum. qui a proporre le loro idee. Però forse senza il Manifesto Quello che traspare in Jeff è proprio questa sua voglia di del 2001, che ha creato quel substrato teorico su cui divulgazione: lui ti racconta delle cose e ti dice i perché appoggiare il tutto, oggi avremmo uno scenario diverso. ma non ti vuole assolutamente convincere. Alla domanda Infatti io continuo a pensare che, sebbene sia venuto di come si sentisse per il fatto di aver ispirato così tante dopo, a sintesi di quanto fatto prima, i valori e principi del persone e di essere un guida per una intera generazione Manifesto per lo sviluppo del software, debbano essere di sviluppatori, ha detto che oggi al mondo ci sono considerati le fondamenta su cui appoggiare pratiche e problemi ben più gravi e definitivi quali quelli dell’energia framework e vanno spiegati/capiti/assimilati prima di e dell’ecologia, e si è riferito a Elon Musk e alla sua idea di applicarli attraverso Scrum, XP o quanto altro: ci vuole il un mondo pulito definendolo un “obiettivo degno”. giusto atteggiamento per applicare le pratiche in modo Diverso l’atteggiamento di Bob che è un tecnico e si corretto. presenta come uno sviluppatore, spiegando ai suoi pari (non a caso è “uncle Bob”) perché le diverse pratiche di XP Vi lascio un paio di link interessanti su alcune delle note qui siano efficaci e di come queste siano raggruppate in quello riportate: che lui chiama “il circolo della vita” cioè la persona, il team, https://www.scruminc.com/origins-of-scrum/ l’organizzazione. https://dzone.com/articles/interview-with-uncle-bob Conclusioni Questi signori hanno effettivamente una visione “più alta” 27

Francesco Racanati Scrum Master  Dal 2013 lavoro per aziende che operano nell’ambito digitale, ho avuto modo di lavorare non solo in Italia, ma anche in Brasile, indossando i panni da «business controller», «business operation specialist» e «product owner». Da quasi un anno lavoro come Scrum Master (e alla pari di Neo nel film Matrix) é come se avessi ingoiato quella famosa «pillola rossa» scoprendo «quanto é profonda la tana del bianconiglio». Appunto, l’agilità implica scoprire la parte più profonda delle organizzazioni e aiutarle nel ridurre i rischi imposti dalla complessità...tutto questo lo trovo stupendo, più che un lavoro per me é una missione. Se poi sulla tua strada incontri gente come i ragazzi di Agile Reloaded, allora la missione diventa davvero fighissima!  PREMESSA IMPORTANTE: le riflessioni a seguire non si prestano ad accostamenti politici di alcun tipo, semplicemente si basano su un articolo che racconta una storia e ne denota i parallelismi di tipo meramente manageriale/Agile. Riferimenti [1] Sense & Respond by Jeff Gothelf & Josh Seiden [2] «Quando negli anni ‘80 la marina militare italiana riuscì a fare l’impossibile» https://www.termometropolitico.it/1455616_quando-negli- anni-80-la-marina-militare-italiana-riusci-a-fare-limpossibile.html [3] Illustrazioni a cura di Lorenzo Marsico 28

Come favorire l’agilità: la Marina Militare Italiana negli anni ‘80 di Francesco Racanati Qualche settimana fa mi é capitato di imbattermi nell’articolo: «Quando negli anni ‘80 la marina militare italiana riuscì a fare l’impossibile»; nel leggerlo, più andavo a fondo con la storia descritta in maniera esemplare da Nicolò Zuliani, e più saltavano ai miei occhi temi riguardanti l’importanza del management nei contesti Agili (in via di trasformazione e non). Visto il preambolo, immagino i volti straniti, ma facciamo un passo indietro chiedendoci: Che ruolo deve ricoprire il management nei contesti Agili? Come posso io «manager» non sentirmi «minacciato» e «ridimensionato» da principi come la «self-organization» votata al «miglioramento continuo»? Ebbene si, spesso questi son gli ostacoli maggiori che un’azienda affronta in una transazione Agile e ai quali spesso nessuno sembra badare, generando dei veri e propri «buchi neri organizzativi» che assorbono risorse, tempo e energie, ma senza alcun risultato. 29

«Va bene Francesco», direte voi, «ma la E’ proprio su questo ultimo punto che ordina di recuperarli e portarli in Italia Marina Militare Italiana cosa centra?», un vorrei vi concentraste: cosa é l’approccio - ecco l’intento strategico dichiarato. A attimo...ora ci arriviamo assieme. Nel libro mission command ? E’ un sistema sua volta Andreotti (ex-ministro della Sense & Respond scritto da Jeff Gothelf di leadership militare sviluppato dai difesa), nonostante sia consapevole & Josh Seiden viene descritto molto comandanti militari centinaia (se non della folle richiesta, interpella l’allora chiaramente come il management sia il migliaia) di anni fa, che permette di ridurre i ministro della difesa Ruffini e assieme crocevia fondamentale nel porre in essere rischi imposti dall’incertezza/complessità scelgono Giuseppe Zaberletti (uno che le condizioni che favoriscono l’agilità. che un’azione militare comporta. Come aveva dimostrato già in passato capacità i Prussiani nel 1800, anche la Marina organizzative in casi di crisi) e cominciano Per essere concretamente agili (senza Militare Italiana negli anni ‘80 ha applicato a fare ipotesi sul da farsi - ecco la libertà millantarlo), queste sono le condizioni questi semplici tre principi su cui si basa il d’azione nel rispetto dei protocolli. Non di cui l’agile management dovrebbe mission command: sanno quante saranno le persone da occuparsi: salvare, né dove siano e tantomeno come Non serve pianificare oltre quelle che comunicare (l’inglese e molto più la lingua Integrazione profonda della ricerca & sono le circostanze prevedibili; vietnamita non son ancora così diffuse): Comunicare a tutti i membri del team complessità allo stato puro. Viene quindi sviluppo col business; l’intento strategico necessario a in aiuto il primo principio (non pianificare raggiungere l’obiettivo; oltre le circostanze prevedibili): vengono Proliferazione dell’apprendimento Assicurarsi che tutti abbiano libertà di individuati due sacerdoti vietnamiti del azione nel rispetto dei protocolli. Vaticano e uno studente dell’università riguardante il mercato (la mera delivery di Torniamo così alla nostra storia...nel di Trieste (gli unici in Italia a parlare la 1979 a seguito della caduta di Saigon in lingua vietnamita), l’incrociatore Vittorio features pescate dal product backlog non Vietnam la popolazione cerca di scappare Veneto e Andrea Doria assieme alla nave e l’unica opzione consiste nel prendere logistica Stromboli vengono riadattate basta); dei barconi malandati e gettarsi in mare. per diventare letteralmente «ospedali Mentre l’intero occidente temporeggia galleggianti» - si parte! Diffusione dello spirito imprenditoriale a con dibattiti su cosa sia capitalista e cosa sia comunista, il Presidente tutti i livelli dell’azienda (la prima domanda Pertini chiama il premier Andreotti e gli deve essere «chi compra quello che sviluppiamo?» la seconda «pensi che si possa fare?») Essere consapevoli del fatto che i rischi connessi alla complessità vadano affrontati usando l’approccio mission command 30

Dopo un viaggio estenuante attraversando missione con il ministro della difesa e il - a questi rivolgo la domanda:»in quale caldo mostruoso e mare forza 7, il primo suo collaboratore facendo in modo che università insegnano a far stime temporali principio del non pianificare oltre il la macchina organizzativa si avviasse. su iniziative complesse?» necessario viene nuovamente in aiuto: le Stesso approccio si denota via via che si tre navi militari ormeggiano a Singapore va giù lungo la catena di comando della Serve essere umili a cospetto della per fare «ricognizione informativa» e in storia: immaginatevi un soldato semplice complessità e il vecchio «approccio quattro giorni definiscono cinque possibili chiedere autorizzazione a procedere al industriale», nato dalla produzione di direttrici di fuga, di queste cinque, 2 ministro della difesa nel bel mezzo della massa di beni tangibili e basato su piani vengono identificate come le più plausibili. missione, vi sembra assurdo? Ecco, questo rigidi e micro-management, ha dimostrato é quello succede spesso in moltissime più volte esser fallace anche nei contesti Riportando il tutto all’ambito manageriale: organizzazioni. stessi da cui é stato generato. quante volte, dopo aver definito il cosiddetto value proposition canvas, ci Il resto della storia, che vi invito vivamente «Va bene, Francesco, ma queste son ritroviamo ad avere una lista di ipotesi a leggere, é un misto di grande coraggio, cose troppo teoriche, cosa significa tutto in merito alle reazioni del mercato? impegno, focus, franchezza e rispetto questo nella pratica? In qualità di manager, Verificare rapidamente quelle ipotesi (ops...i valori scrum!) che ha portato alla come misuro la mia capacità di applicare con dei feedback reali, é la vera essenza salvezza 907 persone destinate a morte il mission command?» La risposta é molto della strategia di prodotto. Alla stregua certa. Questa storia è la dimostrazione semplice: Il compito dei «knowledge del Presidente Pertini, il management tangibile di come l’approccio mission workers» é pensare a delle soluzioni ha solo il compito di dare un obiettivo command abbia dato risultati significativi ed esser liberi di prendere decisioni in da raggiungere evitando focus switch e davvero importanti in una situazione in cui un ambiente sicuro. Se nel luogo in cui avendo piena fiducia nei team (intento la complessità era estrema. Pertanto mi lavorate le persone sono fortemente strategico). I team a loro volta, messi chiedo: perché non applicare il mission e ingaggiate con l’azienda, conoscono nelle condizioni di lavorare con una command anche nell’ambito dei prodotti a «menadito» il business, il fatturato certa libertà d’azione, hanno modo di e dei servizi digitali? Perché nei contesti aumenta sulla base delle scoperte che rispondere rapidamente al cambiamento, digitali (e non solo) c’é ancora chi non si fanno, il numero di riunioni é ridotto al pianificando non oltre lo stretto si rende conto della complessità che si minimo necessario e sopratutto nessuno necessario e individuando le «direttrici di interpone puntualmente tra ciò che si ha paura di parlare in tutta franchezza dei fuga» che porteranno al raggiungimento pianifica e ciò che effettivamente si riesce risultati che si raggiungono considerando dell’obiettivo. a produrre? prove tangibili; allora con molta umiltà, Nonostante ciò, esistono ancora manager mi sento di dire che state andando nel Se riflettete un attimo, Pertini non pienamente convinti del fatto che i verso giusto...tuttavia non rilassatevi, il ha mai detto al primo ministro come membri del loro team siano pagati e «miglioramento continuo» e sempre lì raggiungere l’obiettivo. A sua volta il qualificati per «stimare in maniera precisa che ci aspetta al varco implacabile! premier, ha solo condiviso lo scopo della i tempi di ogni singola attività che faranno»  «Nulla di ciò che sappiamo in merito allo sviluppo software andrebbe considerato come vero» (Cit. K. E. McCrea - CTO at Etsy 2011-2015).  31

Speciale Roadmaps Andrea Feraco Tiziano Interlandi Dimitri Favre 32

L’umore del Gantt Andrea Feraco, Agile Manager Agile Manager presso Cerved Group. Ogni giorno lavoro con l’obiettivo di costruire, promuovere e migliorare la mentalità agile per i team che implementano e consegnano i prodotti dell’azienda. AgileItalia

A Alcune settimane fa un mio caro collega e amico mi chiede di facilitare un workshop organizzato da un team che stava per avviare un importante progetto di migrazione tecnologica. In queste occasioni è abbastanza normale che il management di un’azienda voglia avere un’idea dei costi e tempi attesi. In circostanze del genere ci siamo trovati spesso a utilizzare la tecnica dell’affinity estimation, grazie alla quale in poche ore di incontro ci si fa un’idea delle dimensioni di ciò che si sta per affrontare. Ma non voglio parlare di questo. Qualche giorno dopo il suddetto workshop, uno dei partecipanti farlo”, “ma come fanno gli altri manager a capire quali attività mi invia un whatsapp… ci vogliono?!?”, “come fanno a sequenziare attività, come capiscono a chi assegnarle?!?”... Appena l’ho ricevuto, sono letteralmente morto dalle risate. Verso la fine di quel workshop, infatti, alcuni dei partecipanti Pensai che non fosse mestiere per me. Soprattutto vedevo altri chiesero la possibilità di discutere il piano, rivelatosi poi nella manager che si affannavano dietro ai gantt, ci passavano le forma di un gantt, che avevano ipotizzato nei giorni precedenti. serate, fin quando alcuni uscivano orgogliosi dicendo di aver Ho ascoltato con attenzione per diversi minuti la presentazione finito perché il gantt era finalmente pronto, “girava”! Sì, era di questo gantt. Al termine ho semplicemente commentato: il classico esempio di “working software”. E poi si passava il “ecco, vedi quel file sul desktop, prendilo e piano piano tempo “ansiosamente” a controllare, a spostare e riassegnare trascinalo nel cestino!”. task, a chiamare le persone per chiedere perché avevano finito in ritardo, come recuperare, e subentravano subito straordinari Voglio chiarire che ho una grandissima stima verso i colleghi (spesso non pagati) e weekend di lavoro per recuperare i ritardi che hanno lavorato a quel gantt, anzi in realtà quel gantt sul piano. E comunque i progetti finivano in ogni caso in ritardo, aveva un senso importante per alcune ragioni che ne avevano e poi si riciclava continuamente in attività di negoziazione coi richiesto l’elaborazione. D’altra parte il gantt è solo uno clienti sulle change request, e sui cambi di pianificazione, e strumento, e come tutti gli strumenti possono essere utili se sui costi, e sui tempi… bla bla bla, sui rilasci pieni di bug per ci ricordiamo che individui e interazioni hanno più valore di rispettare le deadlines, sul fatidico “effetto demo”... processi e strumenti. Devo andare avanti? Questo breve aneddoto mi ha portato a fare qualche riflessione sul gantt e sul disprezzo che si ha di questo strumento nel mondo dei cosiddetti agilisti. Personalmente ho conosciuto il gantt intorno al 1997, ero Quanti hanno vissuto o stanno ancora vivendo queste allora studente di ingegneria. Diedi anche un esame che situazioni? comprendeva un elaborato sul gantt. Poi per qualche anno ne sentii parlare poco, all’inizio del mio percorso professionale ero E il valore di ciò che si rilascia al cliente dov’è in tutto questo? uno sviluppatore nella parte bassa della gerarchia aziendale Gli obiettivi per soddisfare i bisogni del cliente chi li gestisce? e di conseguenza avevo poca visibilità delle pianificazioni. E la creatività delle persone, come la si supporta? Siamo solo Ebbi la fortuna di fare un po’ di carriera con posizioni via via ruote di un ingranaggio? più vicine a quelle manageriali e iniziai a vedere gente che lavorava con questo “magnifico” strumento. Ammetto che Ecco, tutto questo non è colpa del gantt. Sì, ho scritto giusto. ero terrorizzato, vedevo il nome mio e di altri colleghi sui vari Non è colpa del gantt, ma il gantt è quello strumento che task cui erano assegnate delle durate e delle dipendenze e è diventato l’emblema della cultura direttiva, prescrittiva, temevo che non avrei rispettato quei tempi, peggio ancora utopicamente predittiva, dove le persone e il valore non sono ero spaventato quando mi chiedevano una stima che sapevo al centro, ma solo piani e progetti che diventano il fine e non il poi si sarebbe andata ad incastrare in quel reticolo di righe e mezzo per un obiettivo. relazioni, e se avessi dato una stima sbagliata sarebbe saltata tutta la pianificazione! Per questo ribadisco e torno a dire “vedi quel file sul desktop, prendilo e piano piano trascinalo nel cestino!” Ma il peggio iniziò ad arrivare quando fu chiesto a me di lavorare alle pianificazioni. Nella mia mente passavano pensieri: “non so Amen. 34

Roadmaps: un cammino per farci crescere Tiziano Interlandi, Agile Coach e Software Engineer Divulgatore e Developer. Agile Coach e Software Engineer in Cerved Group. Co-founder di AgileForItaly. Batterista e fonico. A g i l e I t a l i a 35

Abbiamo realizzato la roadmap del cammino che porta da La Verna a Perugia via Assisi in circa due giorni, avevamo qualche contraints (dati da noi stessi): - Non volevamo soggiornare nelle strutture da pellegrini fornite dalle comunità francescana (non per particolari pensieri socio-religio-politici, ma perché volevamo anche stare un po’ per i fatti nostri). - Volevamo vedere un po’ meglio qualche cittadina, ma non era lo scopo principale Quest’anno io e la mia compagna abbiamo deciso di fare il Primo passo: informarsi cammino di San Francesco, un cammino che prevede 250 km Ma cosa è il Cammino di San Francesco? Per fortuna esistono a piedi, un dislivello positivo di 7400 metri e negativo di 8300 diverse risorse e libri. Optiamo per il sito, completo ed ufficiale. metri con uno zaino in spalla di circa 10 kg. Ci sono diversi modi per raggiungere Assisi. Scegliamo il Premetto che non sono cattolico o cristiano, non seguo nessuna cammino da Nord: sette tappe con una variante per Perugia. religione. Mi definisco agnostico. Non seguo nessuna religione Scopro per caso che esistono delle “Credenziali del Pellegrino” ma ho una mia forma di spiritualità. in stile Cammino di Santiago. Ad ogni tappa completata un Ma che c’entra con l’Agile? Diciamo che ho avuto modo e timbro (particolare da non considerare secondario e che tempo di pensare, ed era uno dei motivi che mi ha spinto a fare affronterò dopo). Inoltre sono importanti per essere identificati questi 12 giorni a piedi tra Toscana ed Umbria. come pellegrini e quindi accettati nelle varie strutture con Il dolore alle spalle dovuto alla scelta errata dello zaino ed il sconti. Le strutture in questione, per capirci, sono quelle costante dolore dei piedi dato dalle condizioni diversificate del nelle quali non vogliamo pernottare (gestite dalla comunità terreno ed i 37 gradi perenni mi hanno fatto fare delle analogie francescana). con le Roadmap. Secondo passo: capire la nostra capacità di cammino Lungo il percorso abbiamo conosciuto diversi pellegrini, chi più La mia compagna è da me nominata la “Gazzella di Gaggiano”, organizzato, chi meno e chi assolutamente no. Io facevo parte ingegnere come me ed alpinista. Cammina alla grande ed ha della prima categoria (non è necessariamente la categoria un passo molto veloce. Io sono cresciuto facendo trekking con migliore il “super-organizzatore”). mio zio in montagna e sono un pugile e non uno scalatore, La cosa interessante è che tutte e tre le tipologie di pellegrino sono più vicino ad un mulo piuttosto che ad una gazzella. hanno raggiunto la meta (Assisi) con pochissimo scarto Una cosa ci accomuna: moriamo su di un fianco piuttosto che temporale. non concludere un percorso. Detto questo un cammino di questo tipo è molto diverso dal Mi sono domandato a lungo come mai e queste sono le trekking di montagna. A meno che uno non faccia una serie di mie considerazioni sulle Roadmap e di come sia complesso rifugi uno dietro l’altro (ad esempio il giro del Monte Bianco – realizzarle. 10.000 metri di dislivello e circa 180 Km – solo pernottamento in tenda o rifugio), solitamente si va in giornata, sparata verso Anche qui una premessa: tutti sono capaci di creare una la cima con dislivello importante per poi scendere. E’ come roadmap che non verrà rispettata. Non penso servano particolari comparare i 100 metri con la maratona, due diversi modi con skills. Ma allora cosa ci permette di crearne di attendibili? Quali diverse difficoltà. strumenti abbiamo e quali considerazioni possiamo fare ? Ma Il primo giorno abbiamo capito questa differenza, ma il piano prima di tutto: cosa è una roadmap? era già stato fatto. Una roadmap è un insieme di passi che ci portano progressivamente e incrementalmente ad un obbiettivo che Ma allora saremmo riusciti a fare tappe da 38 Km con 1800 ci siamo preposti. Una roadmap non è fissa, tiene conto delle metri di dislivello? Abbiamo deciso di no in quanto avremmo dipendenze ma cerca in tutti i modi di disaccoppiarsi da esse. vinto la battaglia ma non la guerra. Camminare tutti i giorni con L’adattività e imparare sono più importanti della rigidità. questi ritmi richiede di fare considerazioni diverse rispetto alla I gantt al contrario sono rigidi e calcolano minuziosamente ogni tappa singola. micro attività finendo sempre per non essere veritieri e facendo perdere l’obbiettivo finale. Qui la rigidità è il fondamento. La nostra capacità di cammino al momento di strutturare le tappe era una sicura incognita. Le condizioni meteo non erano chiare in quanto erano previsioni a 3 settimane. Camminare in mezzo ad un bosco durante un temporale non è bellissimo e neanche fare 30 Km senza ombra a 37 gradi. Insomma molte incognite. 36

Terzo passo: come suddividere il cammino? prenotazione La guida diceva molto chiaramente in alcuni casi: meglio - E se si fosse rotto lo zaino suddividere la tappa. Si parla di tappe impegnative da circa - E se si fossero rotte le scarpe 38 km l’una. Ma la domanda vera è: quanti sono 38 Km? No - E se avesse piovuto parecchio sinceramente, riuscite ad immaginarli se non li avete mai fatti? - E se avesse fatto un caldo dell’inferno La presenza di pendenze importanti complicava il tutto, 1 Km in piano non è uguale ad 1 Km con forte pendenza (fatica) o Interessante vedere come sono cambiati durante il cammino, forte discesa (dolori a caviglie e schiena). Abbiamo optato per ovvero la realtà dei fatti: fare mediamente 22 Km a tappa, sperando di averci preso. - Lo zaino pesa troppo, e se mi faccio male veramente alle spalle? Le tappe sono passate da 8 a 10 per andare incontro a questo - Cosa fare in caso di insolazione? “medione”, a cui aggiungiamo un giorno per arrivare alla - Se mi si rompono le scarpe dove posso ricomprarle partenza, un giorno per visitare bene Gubbio ed un giorno a (siamo spesso nel nulla)? Perugia dalla quale avremmo preso il treno di ritorno. Insomma, cercare predittività in questa fase sa più di arroganza Abbiamo optato per arrivare e ritornare in treno, bloccando invece che saggezza. le date di partenza e ritorno. Abbiamo prenotato le strutture divise per tappa. Praticamente abbiamo blindato il tutto. Agile cerca di abbassare costantemente i rischi a differenza di waterfall che li amplifica con il passare del tempo. Quarto passo: quali i rischi? In questo processo di formulazione mentale è inevitabile farsi trascinare dall’eventualità che qualcosa possa andare storto. Per noi è normale farsi delle domande quando dobbiamo arrivare ad un appuntamento in tempo, ad esempio se il treno sarà in ritardo o ci sarà la tangenziale bloccata dal traffico. Allo stesso modo interessante vedere come queste domande non ce le facciamo quando siamo di fronte a formulare un’ipotesi di roadmap con complessità molto più elevate rispetto ad un treno in ritardo. Nel nostro caso ci siamo domandati: - E se uno dei due non fosse riuscito a concludere una tappa - E se arrivati ad un struttura questa non avesse avuto la A g i l e I t a l i a 37

Come è andata veramente? altrettanto spesso andiamo in panico e quindi ci rifugiamo Diciamo una fatica immane ma abbiamo fatto tutto. nella nostra zona di comfort. Non abbiamo mai preso temporali, ma bensì ci sono stati 35 Per noi la zona di comfort nasconde molte insidie: gradi in media a volte su tratti asfaltati. Il numero di vesciche - Micro management è stato quindi importante. Abbiamo dovuto imparare a trattare - Pushing le vesciche nel modo corretto per proseguire. Ci sono stati - Software pieno di errori per rilasciare in tempo momenti in cui pensavamo di svenire dal caldo, pressati da - Sviluppare features non di valore ore di cammino senza ombra. Il vero e serio problema è stata l’acqua: poca sul percorso, siamo stati costretti a portarcene Insomma tutto quello che cerchiamo di combattere molta, aumentando quindi il peso dello zaino. introducendo metodologie agili. Parlando con altri pellegrini abbiamo capito che a parte una Purtroppo (o per fortuna) lo sviluppo prodotto non porta serie di rischi palesemente validi per tutti (ad esempio il meteo), con sé le fatiche fisiche di un cammino quindi spesso siamo ognuno però aveva una diversa paura collegata. Quando scollati rispetto all’effettivo impegno necessario per portare ci domandiamo la presenza o meno di un rischio in realtà ci a termine i nostri obbiettivi. Inoltre camminare da un punto A stiamo chiedendo come risponderemo al rischio stesso. Ad ad un punto B ha una bassa complessità, di fatto le variabili esempio davanti ad un temporale potremmo reagire in modi in gioco sono allenamento, fattori ambientali, logistica. Nello completamente diversi, soprattutto in relazione a quanto sviluppo prodotto siamo nell’ambito del complesso e quindi siamo esperti di temporali estivi e dove si svolgono. molto poco predittivo. Il concetto di usura è stato predominante: anche la più piccola Quando pensiamo ad una roadmap spesso non ci focalizziamo cosa come lo sfregamento dello zaino, se ripetuto per km può sugli obbiettivi che ci prefiggiamo ma cominciamo a sentire il provocare un infortunio tale da interrompere il cammino. Il peso di una data da raggiungere. tempo di effettivo recupero è molto scarso (cammini 10 ore e poi il letto del B&B non ti fa dormire!). In Agile le date esistono!! Le date ci aiutano a focalizzarci sulle cose più importanti. Cosa ha contato veramente? Per me anche saltare 1 metro del cammino sarebbe stato come “barare”, forse per rispetto degli altri pellegrini. Altri, in presenza di piccoli infortuni, hanno saltato delle tappe con bus, senza avere nessun rimorso. Per altri l’importante era vedere i luoghi di culto. Ognuno aveva una sua idea di cammino. Per noi era fare tutto fino a Perugia, vedere qualcosina, ma soprattutto riflettere e staccare la mente. Cosa c’entra con Agile? Se pensate bene a quanto ho scritto prima, spesso ci troviamo a dover ragionare su come arrivare ad un obbiettivo, ed 38

Il concetto di triangolo rovesciato ci aiuta a concentrare la nostra attenzione sul cosa e sul quando. Il quando è un vincolo di business che non può essere tolto. Ma allora perché ci è tanto difficile fare una roadmap ed evitare che diventi gantt? Continuiamo con il parallelo del cammino. L’unico elemento che ci toglie dal contesto totalmente predittivo ad uno complesso è senza dubbio il rischio. In contesti con assenza di rischio riusciamo sempre a concludere quello che avevamo pianificato. Una corretta gestione dei rischi ha diversi vantaggi: - Permette ai team di ragionare a fondo su ciò che si frappone tra loro ed il raggiungimento di un obbiettivo - Permette al/ai Scrum Master/Coach di aggredire questi rischi tramite azione diretta/indiretta - Permette al management di essere proattivo nell’aiutare i team nella risoluzione di questi rischi Ma veramente la presenza dei rischi è ciò che ci permette di passare dal complesso al complicato? Ovvero ricondurre la nostra realtà progettuale a qualcosa che richiede molta competenza ma che diventa più predicibile? Date, date, sempre date!! sia diretta conseguenza del fatto che si lavori bene. Ogni tanto Siamo sempre qui a parlare di date. Come già spiegato le date però ricordiamoci che le aziende sane sono tali perché chi le esistono. Punto. Molti team dovrebbero cominciare ad essere più compone combatte giornalmente affinché questo avvenga, empatici nei confronti di chi deve pensare a come aggredire il tenendo presente non solo il proprio orticello ma cercando di mercato o chi cerca di creare un business plan per la crescita vedere le cose dalla idea alla vendita. aziendale . Si è sempre parlato di scollamento delle persone del business rispetto a chi implementa il prodotto, ma poco del In un’ottica di così grande responsabilità per tutti colori quali contrario. Oggi molti team passano molto tempo a disquisire lavorano in una azienda, è necessario che tutti i coinvolti sulla data di rilascio invece di lavorare su una roadmap che sia partecipino alla realizzazione di una roadmap. il massimo valore erogabile con il budget assegnato. Diciamo anche che molti team non sanno neanche quale sia il budget. ROADMAP: prerequisiti La guida Scrum dice tra le altre cose per la Sprint Review: - Passare in rassegna come il mercato o il potenziale utilizzo 1. La data o le date vengono fissate dal Business, owner del del prodotto possa avere cambiato la cosa di maggior valore da time-to-market implementare prossimamente; 2. Il Product Owner ha la libertà di massimizzare il lavoro - Passare in rassegna la timeline, il budget, le funzionalità svolto dal dev team e non è un proxy potenziali e il mercato per i prossimi previsti rilasci di funzionalità 3. Il Management è proattivo per aiutare i team o di capacità del prodotto. 4. Tutti ascoltano i Coach e gli Scrum Master perché qualcosa di giusto lo dicono sempre e sanno cosa serve per far funzionare In maniera collegiale i partecipanti alla Sprint Review discutono la “macchina”. per creare prodotti migliori, ma soprattutto guadagnare. Grande tabù: le azienda esistono per guadagnare soldi. Rispettare ruoli e competenze è fondamentale. I developers devono essere fieri di esserlo e fare al meglio software, Nei libri su Agile poche volte viene nominato, ma ricordiamoci architetture e codice. Sono artigiani del software. Il marketing che i nostri stipendi o i nostri investimenti sono legati al fatto che conosce il mercato e cerca di essere sempre un passo avanti. Il l’azienda abbia un profitto. segreto è la crossfunzionalità e che ci sia scambio di idee diverse. Spesso si dà troppo per scontato che il guadagno di un’azienda A g i l e I t a l i a 39

La Leadership del Management. Una rappresentazione grafica di cosa si intende per Leadership a livello di Management è l’organigramma rovesciato. Il classico organigramma piramidale spesso viene utilizzato come fine invece che come mezzo. Si dà per scontato che chi sta sopra ne sappia di più di chi sta sotto e che chi sta sotto ha meno potere di chi sta sopra. Questa è una deviazione di quello che l’organigramma dovrebbe rappresentare. Questa deviazione porta sempre alle stesse conclusioni: un’organizzazione gerarchica che non funziona. Gli organigrammi non servono a questo. Per cercare di uscire da questo meccanismo (che va avanti da 100 anni) dovremmo pensare all’organigramma in maniera rovesciata. Se parliamo di Servant Leadership dobbiamo rivedere il concetto di Management, ovvero un Manager che è al servizio degli altri per togliere impedimenti e far progredire l’intera organizzazione. Tutto questo deve avvenire in maniera “ricorsiva” in modo che tutti i livelli possano trarne giovamento. Ogni livello cerca di aiutare gli altri, sia sopra che sotto. Ritornando al concetto di Roadmap e di come possiamo crearla, il Management deve essere al servizio dei team, che sono i veri creatori di valore all’interno delle organizzazioni. Ciò non significa che il management non serva, anzi, ma che dovrebbe passare più tempo ad aiutare piuttosto che cercare di essere allineato (spesso generando effetti più negativi che positivi). Le Roadmap sono create dai team e supportate dal management. Ad oggi si sta rivedendo il concetto di Servant Leadership - Il Product Owner è veramente empowered e tutti integrandolo con quella di Host Leadership. Dedicheremo rispettano a pieno il suo compito. Può fare descoping e passa articoli futuri in quanto il tema è realmente ampio. il proprio tempo a cercare di massimizzare il valore invece di mettere d’accordo i vari attori. I ruoli nelle Roadmaps - Lo Scrum Master/Coach è nella possibilità di aiutare Scrum non ne parla ed in generale dobbiamo fare un mix tra l’intera organizzazione perché conosce strumenti e tecniche metodologie e correnti per capire ruoli e compiti affinché si per far si che tutto funzioni. arrivi agli obbiettivi prefissati. - Il Dev Team è realmente cross-funzionale. - Gli Stakeholder sono proattivi e partecipano alla L’immagine parla chiaro, abbiamo parlato di Servant Leadership costruzione del valore. e di team come owner della roadmap, ma più in dettaglio: Come potete vedere si tratta semplicemente di remare tutti - I team creano le roadmap su indicazione di persone del verso la stessa direzione e di applicare bene i ruoli prescritti da Business che conoscono bene il mercato ed il time-to-market. Scrum/Agile. Stimano e si misurano per capire come raggiungere l’obbiettivo in un’ottica di vero Inspect & Adapt. - Sarebbe cosa buona avere le persone del business all’interno dei team per creare una vera crossfunzionalità ed accorciare la filiera il più possibile. 40

Chi sono gli stakeholders? collegiale e di arrivare alla formulazione di un backlog stimato Se le persone del business entrano nei team, chi sono allora gli in maniera massiva, dei rischi esistenti e di uno o più MVP di stakeholders? prodotto, fino all’MMP. Domanda lecita, oggi troppo spesso si pensa che il Development Gli step che vi presentiamo sono quelli che noi abbiamo Team sia fatto di soli tecnici dimenticando che invece devono trovato utili, ma ne esistono moltissimi. Non vogliamo essere farne parte coloro che sviluppano il prodotto, e ciò significa totalmente esaustivi, vi rimandiamo ai libri in bibliografia per anche scelte di marketing, operations e vendita. tutti gli approfondimenti del caso. Ma così gli stakeholders spariscono? No , ogni team deve capire questa linea di confine e soprattutto se portare all’interno Prerequisiti qualcuno significhi potenziare la cross-funzionalità invece che - La presenza di un facilitatore che conosca bene questi minarla. step Oggi dovremmo spostare il pensiero dalla cross-funzionalità in - La presenza di totale cross-funzionalità rispetto senso stretto (il dev + il tester + il business analist) a value team, al prodotto o progetto che vogliamo affrontare (invitate ovvero team che cercano di tirare il valore. Il concetto di value rappresentanti di tutti i reparti coinvolti) team introduce anche il fatto che potenzialmente chi prima era - Un tempo definito: consigliamo almeno 2 giorni considerato uno stakeholder, oggi è nel dev team. Capire la - Un luogo isolato e che permetta di lavorare bene con linea di confine, come detto prima, dipende da team a team e tavoli e pareti da utilizzare da realtà a realtà. Oggi considerare che “pensare il prodotto” - Lo sponsor di progetto sia fuori da chi lo implementa è un po’ demodè (come vedete - Consigliamo vivamente la presenza fisica rispetto a sono forte anche in francese). Il consiglio quindi è di limitare quella virtuale almeno per queste giornate. Stanca molto stare fortemente il numero di stakeholder, non tanto evitando 8 ore in cuffia o cercando di capire un qualcosa che nasce per di parlarci, ma quanto cercando di portarli nella catena di essere “dal vivo”. Eventuali trasferte in tal senso saranno soldi produzione del valore. spesi bene, soprattutto in relazione al vantaggio che porta operare in questa maniera. Gli Step di creazione di una Roadmap - Preparate la stanza in anticipo per evitare sprechi di tem Ma alla fine come si fa una roadmap?Oggi parleremo di una serie di esercizi che ci permettono di aprire la mente in maniera A g i l e I t a l i a 41

Step di creazione di una Roadmap Step 1 : perché siamo qui? Lo sponsor introduce brevemente le motivazioni di progetto e prodotto. Sembra una banalità, ma spesso non si sa perché si sta implementando una cosa, è molto frustrante e non ci permette di fare le scelte corrette. La presenza di uno sponsor è sicuramente un punto che permette una maggior probabilità di riuscita della nostra iniziativa. Tempo medio 15 min. Step 2: Vision Board Step 3: Rischi Ma per chi facciamo questo prodotto o progetto? Durante tutto l’evento in realtà continueremo ad Quali sono i bisogni che effettivamente dobbiamo alimentare la board dei rischi. Vale però la pena soddisfare? Quali metriche possiamo mettere in soffermarsi su far capire quanto sia importante piedi per vedere l’avanzamento e capire se le nostre questo step e di come evolva nel tempo. affermazioni sono corrette? La Vision Board è un ottimo template che ci aiuta Modalità: a capire meglio tutti questi punti. La vision board chiedere al team di scrivere su post-it eventuali è un artefatto vivo e può cambiare nel tempo, rischi che possono identificare. Clusterizzarli ed rimane però un qualcosa che ci permette sempre di inserirli in todo nella board. ritornare sui razionali iniziali e quindi stare ancorati Chiedere al team per ognuno se sia possibile: all’essenza del prodotto che stiamo facendo - Mitigare il rischio: azioni che possono evolvere. abbassare l’impatto - Accettare il rischio: reputiamo la possibilità Modalità: che avventa, ma riteniamo che sia di basso impatto Il facilitatore pone le domande del template al team. e tale che probabilmente evitarlo costa più che Il team scriverà su post-it diversi il proprio punto subirlo di vista. I post-it vengono applicati sulla board, - Owned: qualcuno ha in carico l’analisi o clusterizzando dove server. A questo punto parte la risoluzione del rischio. discussione e si diverge per poi convergere insieme. - Risolto: rischio azzerato Particolare attenzione alle Expectations: qui devono Potreste non essere in grado di indirizzare tutto, esserci reali “numeri” in modo da capire on maniera è normale. Ricordate che la board dei rischi è un oggettiva se stiamo procedendo correttamente. Le artefatto vivo e come tale evolve. La board dei rischi eventuali barriere emerse possono essere inserite è da considerarsi a tutti gli effetti come un backlog nella tabella dei rischi che vedremo più avanti. di attività che il team deve affrontare. Tempo medio 1h Tempo medio 30 min. 42

Step 4: What is in - What is out? Uno step simile alla board dei rischi è il “cosa è nel perimetro, cosa non lo è”. Spesso ci troviamo di fronte ad iniziative il cui perimetro cresce costantemente. Come rimanere focalizzati su quello che effettivamente ci serve? Modalità: Sempre su post-it clusterizzati chiedete al team cosa secondo loro sia nell’iniziativa e cosa no. Porre sulla board e discuterne. Scoprirete quanto questa fase crei molta consapevolezza e focalizzazione. Anche questo step evolve durante tutte le giornate. Alimentatelo costantemente come i rischi. Tempo medio 30 min. Step 5: Stakeholders Map Questa board offre la fotografia di chi interagisce con noi. Ma Chi sono i nostri stakeholder? Se dovessimo effettivamente cosa possiamo fare? Come vedete ogni quadrante identifica applicare la definizione di Stakeholder avremmo il comportamento. Sicuramente possiamo cercare di spostare “Ciascuno dei soggetti direttamente o indirettamente coinvolti gli afferente al primo quadrante cercando di renderli in un progetto o nell’attività di un’azienda.” In realtà questa promoters. definizione non ci piace. Sembra poco orientata al valore, Come riuscire a farlo dipende dalle singole organizzazioni. quindi a noi piace “Chiunque possa tratte vantaggi diretti Anche questo è un artefatto vivo ed evolve. o indiretti dal nostro operato”, che in questo caso è una iniziativa progettuale o di prodotto. Sicuramente una definizione un po’ troppo ampia, ed è per NOTE questo che questo esercizio ci aiuta a capire come e in che Cerchiamo di non concentrarci sul cliente in questo esercizio, modo sono impattati gli altri dall’iniziativa e come possiamo per lui esistono strumenti che analizzeremo in seguito. trasformare questo “scenario” in modo che l’iniziativa ne tragga il maggior vantaggio possibile e quindi anche gli Tempo medio 45 min. Stakeholder stessi. Costruite una board come in figura e chiedete al team di scrivere il nome, il tipo, l’ufficio dello Stakeholder e di posizionarlo sulla board in relazione all’interesse e potere decisionale. Clusterizzate. Discutete. A g i l e I t a l i a 43

Step 6: Personas Chi sono i nostri clienti, utenti? L’esercizio delle personas è molto importante. Il consiglio è di chiedere alle persone capaci di identificarli ad arrivare già con un premasticato. La costruzione delle Personas richiede analisi di mercato, studi ecc. Cerchiamo di partire da una base già solida per farla evolvere con i contributi della stanza. Partite da uno dei tanti template disponibili e cercate di comprendere a pieno i vostri clienti/ utenti anche con l’utilizzo del template di Empathy Map. Il risultato è una comprensione maggiore dei nostri clienti/utenti in modo da massimizzare il valore nei loro confronti. Modalità Arrivate con un pre masticato e generate ulteriori personas solo se emergono. Fateli raccontare dalla persona che meglio li conosce. Discutetene ed eventualmente correggete ed arricchite. Entrate nel vivo dello studio con l’Empathy Map: quali sono aspirazioni e malesseri delle nostre personas? Cosa sentono? Cosa vedono? Tempo medio 1h. Step 7: Customer Journey E’ importante ricordare che questa attività non genererà un Ora cerchiamo di capire come interagiscono le personas con backlog immutabile, ma un backlog di partenza che potrà le features che abbiamo pensato in fase di Vision. Questi solo evolvere. La parte fondamentale è ragionare insieme sul steps sono i più sostanziosi in termini di tempo, impegno e prodotto e far emergere dipendenze e rischi. concentrazione. Cerchiamo di ragionare sulle nostre features e proviamo Alla fine avremo un backlog stimabile a dividerle e posizionarle temporalmente in orizzontale. massivamente,dipendenze e rischi aggiornati. Poniamoci poi la domanda: come interagiscono le personas con queste features? In questa fase è importantissimo l’apporto del business e del In questa fase possiamo anche inserire delle “personas futuro product owner in modo tale da far capire bene alla particolari”, ovvero i sistemi: in aziende grandi è normale che stanza le necessità e le peculiarità del prodotto. una nuova funzionalità o prodotto usufruisca di qualcosa che già esiste. Questa considerazione però porta con sé il Attenzione a non focalizzarsi troppo su micro attività e problema delle dipendenze: chi gestisce questo sistema? Ha mantenere la focalizzazione sulle personas e su come bisogno di modifiche? Saremo autonomi? utilizzeranno il nostro prodotto. E’ normale parlare anche di tecnologia e soprattutto dei vincoli collegati, ma lasciate Questi passaggi portano anche alla suddivisione delle questi verticali ai normali refinement di team. features in attività più piccole. Passeremo da Features ad Epiche a storie “a grana grossa” fino a storie stimabili (User Tempo medio: 3h Story Mapping). Step 8: Facciamo un Check A questo punto è il caso di tirare le fila e riassumere quanto fatto. La tecnica migliore è far raccontare a qualcuno della stanza quanto abbiamo fatto e ripercorrere tutti gli artefatti prodotti, con particolare attenzione al Customer Journey. Domandatevi: c’è altro? Torna tutto? Raffinate Customer Journey, dipendenze e rischi. Step 9: High Level Architecture E’ buona cosa a questo punto parlare di sistemi. Cercate di disegnare un diagramma di massima dei sistemi coinvolti e delle loro interazioni. Andate pure nel dettaglio, meglio evidenziare un passaggio in più che dimenticarlo. Da questo step ci aspettiamo un’architettura del 44 prodotto di massima e le dipendenze legate.

Step 10: Stima Massiva Ipotizziamo di aver stimato un item della colonna M con 5 Pronti per stimare? In questa fase è impossibile avere una story points, a questo punto potrete costruire qualcosa di stima “secca”. Ricordiamoci che le stime sono sbagliate simile: per definizione, in questa fase lo sono ancora di più. Ma allora perché lo facciamo? Il nostro goal è di ottenere un XS da 1 a 2 range di sprints entro i quali siamo sufficientemente sicuri S da 2 a 3 di concludere le attività. Potremmo dire di aver bisogno dai M da 3 a 5 6 agli 8 Sprints, oppure da 2 a 10. Ovviamente più è ampia L da 5 a 8 questa forchetta e più implicitamente stiamo dicendo di XL da 8 a 13 conoscere ben poco quello che andremo a fare. XXL da 13 a 21 Come stimare quindi così tante attività in poco tempo? ? da 40 a 40 Posizionate (meglio ricopiare) le attività in uscita dalla user Facciamo apposta sbilanciare il ? con 40 sp per porre story mapping e mettele in un backlog. Create colonne immediatamente l’attenzione sulla necessità di raffinare al indicati T-Shirt sizes (XS, S, M, L, XL, XXL e ?). meglio questa attività per ricondurla in una o più attività delle Scegliete chi dovrà stimare all’interno della stanza, altre colonne. indicativamente chi farà parte del Dev Team o loro rappresentanti. Ora come step finale sommiamo tutti i i minimi ed i massimi, ottenendo quindi due valori e utilizziamo la velocity di team A turno ogni partecipante avrà due mosse disponibili: per capire quanti spints ci serviranno. muovere un item dal backlog verso una colonna di size Ad esempio: con una velocity di 30 sp a Sprint ed un minimo oppure prendere un item già con size e muoverlo in un’altra di 150 sp ed un massimo di 300 sp possiamo dire che colonna. siamo confidenti di rilasciare tra il 5 ed il 10 sprint. 5 Sprint di Il gioco termina quando tutte le attività del backlog sono differenza sono troppi? Sicuramente! Ma il business avrà un ultimate. intervallo per agire sul time to market ed iniziative connesse. Ma la domanda più importante che possiamo fare a questo Il gioco avviene in silenzio, ma diamo 2 domande in totale a punto è: cosa possiamo fare in termini di rischi e roadmap partecipante in modo da dipanare i grossi interrogativi. per abbassare questa incertezza? Una volta concluso il gioco si chiede alla stanza se vedono Queste considerazioni non vanno lasciate li a “fermentare”, grandi discrepanze o anomalie e raffinate. abbiamo un artefatto da mantenere ed utilizzare per le considerazioni che faremo in futuro. In questo caso ci viene Tra le colonne abbiamo anche ?, ovvero attività che è incontro il BurnUp Chart. Ci aspettiamo che la minima e la veramente impossibile interpretare. Usatelo con cautela. massima stima convergano nel tempo diminuendo sempre di più l’incertezza. Un comportamento diverso è segnale di A questo punto dobbiamo tradurre queste sizes in story forte pericolo per il progetto e le nostre roadmap. points. La stanza potrebbe essere composta da team già rodati oppure da persone che hanno lavorato poco insieme. Chiedete di stimare con il Planning Poker un’ attività in qualsiasi colonna, vi aiuterà a capire come costruire i vari range. A g i l e I t a l i a 45

Step 11: Team, come e chi A questo punto abbiamo abbastanza elementi per provare a creare un o più team cross-funzionali e fare riflessioni su eventuali framework di scaling da adottare. Domandiamoci sempre: abbiamo tutte le competenze per concludere le attività? Ci sono SME da includere? Conclusioni 12: MVP ed MMP Gli esercizi presentati necessiterebbero di pagine e Partiamo con una considerazione. pagine. Il nostro intendo è stato quello di dare una MVP : Minimum Viable Product, ovvero insieme di feature che panoramica sistemica rimandando a numeri futuri servono a darci feedback dal mercato/utilizzatori in modo da tutti gli approfondimenti del caso. validare o invalidare le nostre tesi. E’ un percorso di comprensione crescente su quello che è più di valore. Possiamo anche pensare l’ Abbiamo inserito alcuni esempi di esercizi ma ce ne MVP come un modo di abbassare i rischi, ovvero il rischio di dare al sono per tutti i gusti. La lista presentata rappresenta pubblico qualcosa che non serva. però un set minimo di passi da fare per arrivare a capire come muoversi all’interno della complessità MMP: Minimum Marketable Product, ovvero insieme minimo di di un progetto/prodotto. feature che vogliamo dare al mercato/utilizzatori mantenendo alto il focus su “meno è meglio”. Su 20 feature pensate quante sono Una cosa molto importante: alla fine di questo quelle veramente importanti per poter uscire sul mercato senza cammino potremmo chiederci se ha senso avere il rischio di dare qualcosa di incompleto dal punto di vista sviluppare un prodotto, ovvero se ci porterà un dell’utilizzatore? guadagno (dove guadagno non è necessariamente economico). Avremo però impiegato poco tempo Possiamo dire che un insieme di MVP danno un MMP, ovvero (e quindi pochi soldi) per capirlo invece di “sbattere validiamo costantemente le nostre tesi fino a costruire un pacchetto contro un muro” dopo mesi di implementazione ed minimo di funzionalità di alto valore da dare ai nostri clienti. aspettative. Riprendiamo il nostro Customer Journey e creiamo diverse Swimlanes secondo gli MVP ipotizzati. Insieme alla stanza spostiamo i vari items sopra e sotto in modo da costruire l’insieme dei nostri MVPs Aggreghiamo gli MVPS in uno o più MMPs. Bibliografia & Riferimenti Agile For Italy Lean Beer Lean Inception - Paulo Caroli - Product Envisionign 1,2 e Inception The Agile Samurai: How Agile Masters - BurnUp e BurnDown Deliver Great Software - Jonathan Rasmusson Gamestorming - Dave Gray, Sunni Brown, James Macanufo Deliver Great Products That Customers Love: The Guide to Product Management for Innovators, Leaders, and Entrepreneurs - Valerio Zanini Liftoff - Diana Larsen, Ainsley Nies 46

Una roadmap basata sui bisogni Dimitri Favre I am a passionate and experienced IT professional with strong executive and technical background. I’m a lean thinker and an agile addicted: I am continuously searching and uncovering better ways of developing IT solutions. I am a #noprojects enthusiast and I wish people live happily ever after without (software) projects. I grew up on a wide front of technologies, covering the most popular development platforms, systems and applications. I developed strong skills in architectural design, with a vision that cover both the whole and the finer details. Speaker and apprentice writer https://leanpub.com/livehap pilyeverafterwithoutprojects Specialties: Agile and Transformation Coaching, Process Improvement, Team Organization, IT System and software architecturestures A g i l e I t a l i a 47

B campo base del team esteso. E infine, esposta dietro a un vetro blindato come la Gioconda al Louvre, c’è lei: la Vision. Non passa inosservata neanche al più distratto dei passanti, con il suo inglese maccheronico a riempire gli spazi bianchi dell’elevator pitch template (perché diciamocelo, certi template in italiano non si possono ascoltare). Donne e uomini del business, sviluppatori, designer, facilitati dall’immancabile coach agile (#agiailcocc) si rinchiudono nel loro accampamento e dopo qualche giorno escono come cardinali dal concistoro: habemus backlog. Il problema del backlog Non ce la possiamo fare. Siamo ancora succubi al concetto dello scope definito. Hai voglia a fare l’aggile, con più g di @agilegigi. Hai voglia a dire che tempo e risorse sono fissi e lo scope è stimato. Lo scope parte sempre con l’idea che quello è e quello si deve fare. Al più ci saranno cose nuove da aggiungere. Finalmente, abbiamo l’agognato budget di progetto. Un piccolo In realtà, il problema non è tanto nello scope fisso, è’ nello tesoretto in attesa di essere speso in attività che migliorino in scope, per come è definito. Lasciando un attimo da parte la modo sensibile il nostro portfolio prodotti. Potrebbe essere un definizione tatutologica della Guida a Scrum (un backlog prodotto nuovo, oppure la tanto agognata evoluzione di un formato da elementi del backlog, e grazie al cazzo tante), prodotto che da un po’ di tempo aveva bisogno di una ventata il backlog quadratico medio di un team Scrum contiene, di aria fresca. essenzialmente, user stories. A seconda della vostra cultura aziendale, potreste chiamarle Epiche, Features, o anche un più In un mondo VUCA (in italiano sarebbe VICA, ma può prestarsi volgare Requisiti. ad ambigui difetti di pronuncia), che evolve nella direzione dell’agilità, le persone hanno bisogno di certezze. E va bene “Cosa c’è in un nome? Ciò che noi chiamiamo con il nome di che rispondere al cambiamento è più che seguire un piano, storia utente, anche se lo chiamassimo con un altro nome, ma alla fine, e ce lo dice il Manifesto per lo sviluppo agile del serberebbe pur sempre lo stesso dolce profumo. Di funzionalità”. software, avere un piano non è esattamente indesiderabile. E Il Bardo Immortale (al secolo, William Shakespeare) vorrà per redigere un piano dobbiamo sapere cosa fare, giusto? perdonare l’abuso che ho fatto della sua celeberrima citazione. Quale che sia il nome che date agli oggetti del backlog, questi Qualcuno la chiama preparation, qualcuno la chiama descrivono funzionalità. In altre parole, descrivono lo spazio requisitazione. Qualunque sia l’etichetta che avete deciso di della soluzione. dargli, a un certo punto un manipolo di avventurieri si riunisce per decidere il da farsi. Sessioni di envisioning, user story Qualcuno dice che in un team agile il product backlog è il piano, mapping, impact mapping come se non ci fosse un domani e e mi sento di condividere questo punto di vista. Ma lo sponsor pareti piene di post-it, a testimoniare il duro lavoro svolto. quadratico medio non capisce questo modo di esprimere un piano. Tutto sommato è comprensibile, considerato che si è Ovviamente non possono mancare canvas di vario genere che abituato a diagrammi temporali, a vedere il tempo che scorre fanno mostra di sé, a metà strada tra la natura morta e l’arte sull’asse delle ascisse, da sinistra verso destra, come in un astratta, sulle pareti di una sala riunioni che è stata adibita a qualunque diagramma di Gantt. 48

La roadmap illimitata di ipotesi. Ipotizziamo che il problema da risolvere sia La migliore sintesi temporale che possiamo fare è una bella quello giusto, e poi assumiamo che la soluzione immaginata roadmap. Cos’è una roadmap? Senza avere l’ambizione di sia quella giusta, ci convinciamo di saperla implementare, e essere formali, possiamo dire che una roadmap rappresenta, magari anche di riuscire a farlo nel rispetto di vincoli di soldi e spesso in modo visuale, in quale release ipotizziamo di rilasciare di tempo. le funzionalità emerse durante la preparation. Ognuna di queste è una assunzione, ovvero una ipotesi non Forse non ve ne siete accorti: ho scritto “in quale release”, validata. Solo che nel momento in cui la scriviamo su un post- non “quando”. In effetti, nel tentativo di rispettare il principio it (e poi su Jira, o su Excel), ci dimentichiamo che era solo indissolubile che, dovendo abbracciare il cambiamento, il piano un’ipotesi. Diventa un fatto. è un esercizio inutile, le roadmap agili tipicamente non hanno una scala temporale. Il tempo si misura in release. Quanto dura Per ricordarci che bisogno e soluzione sono mere assunzioni, una release? Una release dura una release. E ogni release dura potremmo adottare un lessico di questo tipo: il tempo necessario a realizzare la release. Assumiamo che implementando <funzionalità> Soddisferemo il bisogno <bisogno/desiderio> dell’utente Per un certo periodo della mia vita ho anche compreso, e <utente/persona> forse condiviso, il ragionamento che ne sta alla base. L’elenco di funzionalità incluse in ogni release risponde alla domanda: In questo modo, qualunque elemento del backlog ci ricorderà cosa rende ogni release consistente e ragionevolmente di che non abbiamo certezza né del problema, né della soluzione. valore da poter essere considerata per il rilascio in produzione? Un problema spaziale Riconciliare gli obiettivi di business Ogni volta che scriviamo una funzionalità da implementare L’altra dimensione che sparisce completamente dalla vista del una esperienza utente muore mettiamo una pietra tombale team che implementerà le funzionalità del backlog è come, una sullo spazio del problema e entriamo a piedi pari nello spazio volta realizzata e rilasciata in produzione, questa contribuisca della soluzione. al raggiungimento degli obiettivi di business. Alla fin fine, per il team di sviluppo questo problema è già stato affrontato, e Lo spazio del problema è il grande assente dal backlog, e brillantemente risolto, da quel semidio caduto sulla terra che dalle roadmap. Il nome non è neanche dei migliori. Forse lo risponde al nome di Product Owner. si dovrebbe chiamare più correttamente spazio dei bisogni, o addirittura spazio dei desideri. O ancora meglio, lo spazio del Per evitare questa disconnessione, ci sono un paio di strumenti cliente. che un buon team di prodotto dovrebbe sempre utilizzare. La GO (Goal Oriented) product roadmap di Roman Pichler e Nello spazio del cliente si descrivono i suoi bisogni insoddisfatti Impact Mapping di Gojko Adzic. e i suoi desideri non ancora esauditi. Durante le sessioni di envisioning, spesso si fanno workshop mirati a definire quali Attraverso una GO roadmap, ogni release viene associata a siano, questi bisogni e questi sogni, a volte partendo da un obiettivo di business e a metriche ben definite. Il template informazioni più circostanziate, come una ricerca di mercato o suggerisce l’outcome che una sessione dedicata alla scrittura una serie di interviste a utenti veri. di una roadmap dovrebbe avere. L’outcome guida il lavoro, e trovo pregevole che Pichler abbia esplicitato in modo così Indipendentemente dal percorso seguito, a un certo punto chiaro obiettivo di business e le metriche per verificare se sia avremo individuato chi è il nostro utente target e di che cosa stato raggiunto o meno. ha bisogno. Ragionevole pensare che giunti a questo punto, il passo successivo sia quello di entrare nello spazio della soluzione. Infatti è quello che normalmente accade. Si esplora, in modo più o meno esteso, tutto lo spazio del cliente per trovare tutte le soluzioni, che poi gergalmente chiamiamo funzionalità, o storie utente. A differenza del classico documento di specifica dei requisiti, ci si limita a stare a un livello alto, a scrivere poco più di un titolo, magari un piccolo sketch di interfaccia utente. Perché non vogliamo sprecare le nostre energie andando a dettagliare troppo qualcosa che poi magari non si implementerà mai. Tutto giusto, tutto sbagliato. Uno degli insegnamenti dell’approccio Lean Startup è che la prima, grande assunzione che ogni prodotto dovrebbe validare è che si stia risolvendo il problema giusto. Insomma, è un problema dello spazio che osserviamo. In altre parole, è un problema spaziale (ed è anche bello grande). Assunzioni, ovvero ipotesi non validate Lo sviluppo di ogni prodotto è basato su una quantità pressoché A g i l e I t a l i a 49

Impact mapping è una tecnica di facilitazione per supportare che la prima ipotesi da validare è che stiamo risolvendo il la pianificazione strategica. Come si vede nell’immagine problema giusto. seguente, si parte dal perché, o in altre parole dall’obiettivo. Nella mappa, appaiono gli attori del sistema (non solo gli Riutilizzando il formato delle assumption stories, questa ipotesi utenti), ma anziché ragionare in termini di bisogni, si ragiona più potrebbe essere dichiarata come segue: sull’impatto, e cioè sul cambiamento di comportamento che vogliamo generare per ottenere gli obiettivi definiti nel why. Assumiamo che soddisfacendo il bisogno <bisogno/desiderio> Il cosa (what) dell’ultima colonna è, ancora una volta, un insieme dell’utente <utente/persona> di funzionalità. Letta da destra verso sinistra, la mappa ci dice raggiungeremo <obiettivo di business> entro <data> che la funzionalità (what) genererà il cambiamento (how) della persona (who) per raggiungere l’obiettivo (why). In aggiunta, e Questa potrebbe essere la base di partenza della costruzione in modo simile a quanto definito nella GO product roadmap, di un nuovo tipo di roadmap, che anziché concentrarsi su cosa all’obiettivo vengono associati degli elementi di misura per verrà realizzato, si focalizza su quali problemi verranno risolti. poterne determinare il raggiungimento. A ogni percorso della mappa, inoltre, viene indicato in modo quantitativo il contributo Una roadmap needs-driven che quel percorso porta al raggiungimento dell’obiettivo. Una roadmap needs-driven è un piano allo sviluppo di prodotto che lavora sullo spazio del cliente. Facciamo un Ancora una volta, una volta completato il lavoro, avremo storie esempio, Ipotizziamo che lo sviluppo riguardi un app bancaria che nasconderanno le ipotesi fatte durante la costruzione su dispositivo mobile e che il nostro obiettivo di business sia di della roadmap o della mappa di impatto, e in assenza di una aumentare il numero di utenti su dispositivi mobili del 10% in evidente incertezza, diventeranno fatti. tre mesi. Per ricordarci che soluzione e obiettivo di business sono Una user story potrebbe essere scritta così: collegati in via del tutto ipotetica, potremmo adottare un In qualità di cliente mobile della banca lessico di questo tipo: Voglio poter fare un bonifico Assumiamo che implementando <funzionalità> Al fine di trasferire i soldi su un altro conto corrente bancario Raggiungeremo <obiettivo di business> entro <data> L’ipotesi sottostante è che il bisogno dell’utente sia quello di Assumptions stories poter trasferire soldi su un altro conto corrente bancario, e Mettendo insieme i due template, otteniamo quella che io che rendere disponibile un bonifico in app sia la soluzione da chiamo una assumption story. Contiene sostanzialmente implementare. Aggiungiamo una seconda storia: tutti gli elementi di base di una user story (per chi, valore e In qualità di cliente mobile della banca funzionalità) e li collega agli obiettivi di business, in q u e s t o Voglio poter pagare un acquisto online con PayPal modo: Al fine di effettuare transazioni online senza comunicare il numero di carta di credito Assumiamo che implementando <funzionalità> Soddisfaremo il bisogno <bisogno/desiderio> dell’utente Cosa differenzia le due storie? Quale dovremo fare per prima? <utente/persona> Quale produce maggior valore? A questo livello, non abbiamo E raggiungeremo <obiettivo di business> entro <data> più nessuna informazione su questo punto. E quale delle due garantisce più facilmente il raggiungimento dell’obiettivo di Troppa attenzione alle funzionalità business? A questo punto dovrebbe essere chiaro come il Indipendentemente dal template adottato e dalla specifica tanto usato formato delle user stories sia insufficiente a fornire tecnica di facilitazione e descrizione del backlog, le nostre queste risposte. roadmap sono ancora troppo piene di funzionalità. Ricordiamoci 50

Seguendo i template precedentemente indicati potremmo Il quarto vantaggio è che il soddisfacimento di un bisogno si scrivere: collega in modo più naturale e diretto agli obiettivi di business (la Assumiamo che soddisfacendo il bisogno di trasferire soldi a funzionalità lo fa in modo indiretto, e per farlo deve passare dal un altro conto corrente bisogno). Quando si ragiona su questo aspetto, diventa molto Raggiungeremo un aumento del 10% di utenti del servizio facile (o rendere meno prioritari) elementi del backlog che non bancario su dispositivi mobili in tre mesi hanno nessuna attinenza con l’obiettivo di business. Senza dimenticare, tuttavia, che la prima assunzione da verificare o In realtà, realisticamente, la sola presenza di questa funzionalità confutare è che si stia risolvendo il problema giusto. Ma questa potrebbe non garantire il risultato desiderato, e quindi la nostra è un’altra storia. formulazione più verosimilmente sarà: Assumiamo che soddisfacendo il bisogno di trasferire soldi a L’ultimo, piccolissimo, vantaggio è che nel nostro backlog un altro conto corrente non avremo più etichette diverse a seconda della dimensione: Raggiungeremo un aumento del 2% di utenti del servizio avremo solo bisogni da soddisfare (e da raffinare). bancario su dispositivi mobili in tre mesi Conclusioni Avere un piano è una necessità organizzativa alla quale nessun La seconda storia potrebbe essere riscritta così: team di prodotto, neanche un team agile, può sottrarsi. Va bene Assumiamo che soddisfacendo il bisogno di effettuare abbracciare il cambiamento, ma se il mondo non cambia, che pagamenti online senza esporre la carta di credito facciamo, abbracciamo gli alberi? Raggiungeremo un aumento del 7% di utenti del servizio bancario su dispositivi mobili in tre mesi Il backlog è una forma di piano, ma una roadmap comunica in modo più efficace. Possiamo costruire la roadmap scrivendo In sostanza, una roadmap basata sui bisogni indicherà, per funzionalità come se non ci fosse un domani, perché tanto ogni release, non tanto la funzionalità da implementare, ma il prima o poi lo dovremo fare. Oppure, possiamo provare a bisogno che si intende soddisfare e come questo è collegato concentrarci un po’ di più sui bisogni del nostro utente e all’obiettivo di business della release. costruire un piano che definisca, release per release, quali bisogni andremo a soddisfare e quali desideri esaudire. Il primo vantaggio di questo tipo di approccio è che, anche senza entrare nel merito di come verrà risolto il problema, Non dobbiamo mai dimenticare che siamo sempre nel mondo abbiamo a disposizione tutti gli elementi necessari a definire le delle ipotesi. Un modo per farlo è l’adozione di un formato priorità del backlog e di conseguenza della roadmap. come quello delle assumption stories, che mette in chiaro che tutto ciò che scriviamo deve essere validato o confutato. Il secondo vantaggio è la flessibilità. Data l’esistenza di vincoli Perché alla fine scrivere software è un esperimento. temporali ed economici, focalizzarsi sui bisogni rende più flessibile lo scope, e abilita il defer commitment. Decidere la Se siete come il Tenente Colonnello Hannibal Smith e vi soluzione in fase di preparation è quanto meno prematuro. piacciono i piani ben riusciti, non potete non fare una roadmap. Il livello di conoscenza è bassissimo, e non siamo ancora Magari, la prossima che farete sarà più focalizzata sui bisogni neanche sicuri che stiamo risolvendo il problema giusto. e sugli obiettivi di business, e un po’ meno sulle funzionalità. Il terzo vantaggio è quello di abilitare l’empowerment e la self- organization del team. Fintanto che nella roadmap è presente il bisogno, e non la funzionalità da implementare, il team è aperto a più di un’opzione, tra le quali, in accordo con il product team, potrà selezionare quella più rispettosa dei vincoli di tempo e di soldi. A g i l e I t a l i a 51