Agile per team e progetti

Abbiamo tenuto qualche tempo fa un techlab particolare: un talk show sull’agile nei progetti e nei team. All’evento hanno partecipato Fabrizio Venere, Daniele Maccioni e Massimiliano Atzori, che hanno parlato della loro esperienza di appassionati e di professionisti che usano l’agile nel lavoro di tutti i giorni. Massimiliano e Fabrizio sono due ex programmatori e ora project manager, mentre Daniele è un programmatore che da poco ha iniziato anche un’avventura come Scrum master nei team con i quali lavora.
Lasciamo la parola a loro, riportando i punti salienti dei loro interventi.

Massimiliano: Oggi parliamo di qualcosa di diverso rispetto agli argomenti prettamente tecnici dei TechLabs di Develer: parliamo di tecniche e di strumenti per lavorare bene come gruppo. Questo è un argomento che normalmente passa in secondo piano, perché nel nostro lavoro è frequente dare più importanza alle tecnologie, alle librerie e ai linguaggi. Secondo noi, invece, è un tema che risulta fondamentale quando si vuole arrivare in fondo a un progetto, software o di qualunque altro genere.

In questa conversazione non vi parleremo dell’agile in generale e nemmeno di un metodo particolare. Vi parleremo delle nostre esperienze. Questo perché siamo nell’ambito di attività fatte da persone, quindi non ci sembra sensato proporre “una guida per come fare bene agile”, ma ci pare più costruttivo partire dal nostro quotidiano per aiutare chi vuole provare l’agile nel proprio lavoro.

Massimiliano: Daniele: prima ancora di parlare di agile e di manifesto agile, ci dici quali sono i problemi che hai incontrato, prima come sviluppatore e poi anche come Scrum master, quando hai lavorato in team di sviluppo software?

Daniele: Immagino che non dirò niente di originale. Per esempio, problema tipico: siamo un team di programmatori, ho eccellenze tecniche, il team dovrebbe essere perfettamente in grado di risolvere il problema che gli viene dato e, nonostante questo, ci sentiamo impantanati, le feature non arrivano, il cliente non è soddisfatto, come mai? Non sappiamo esattamente bene il perché. Questa è una prima tipologia di problemi. Oppure prendiamo il prodotto: ci lavoriamo, rilasciamo feature, ma ogni volta che lo presentiamo al cliente o all’utente finale, sembra che quello che abbiamo fatto non abbia valore, sembra che il nostro impegno sia stato speso nella direzione sbagliata, e non riusciamo a capire come risolvere questo problema. Oppure ancora: il prodotto non è abbastanza stabile , ci sono un sacco di bug, però al tempo stesso sforiamo le scadenze e le feature non arrivano. 
Tutti questi problemi sono problemi di processo, ma anche di stabilità e di valore del prodotto. 

Massimiliano: Quindi dici che si lavora tanto, però sembra che non si arrivi mai a un qualcosa che funzioni o che ci soddisfi?

Daniele: Certo. Oppure ci sono impedimenti di vario tipo che frustrano il team, quindi vorremmo fare di più ma ci sono X problemi che ci bloccano oppure ci sentiamo non allineati con quello che vorrebbe il business. 

Massimiliano: Secondo te, tra tutti i problemi che mi hai citato, qual è quello sentito come più importante da affrontare?

Daniele: Nella mia esperienza, mi verrebbe da dire che quando ci si trova nella situazione in cui un progetto non sta andando nella direzione giusta e il prodotto non soddisfa abbastanza, questo non è causato da motivi strettamente tecnici. Quindi: problemi organizzativi, problemi di focus, problemi di priorità, problemi di valore. Questo genere di problematiche sono quelle più importanti. Raramente il team non riesce a conseguire obiettivi perché inciampa davvero in un problema tecnico o non sa come fare qualcosa. Di solito, le persone questi problemi li risolvono, se non ci sono impedimenti accessori di tipo, appunto, organizzativo o gestionale.

Fabrizio: Se il PM non fa danni, insomma! 🙂
Provo a dare anche un altro modo di vedere la cosa perché io, che a differenza di uno Scrum master ho più a che fare con il cliente, mi rendo conto di come il provare a mettere in campo i metodi agili è sicuramente una sfida molto interessante.
Negli ultimi anni, il livello di maturità sta cambiando nel nostro settore, quello industriale. Era impensabile provare semplicemente a proporre una metodologia di questo tipo negli anni scorsi. Ultimamente, invece, noto un’apertura da parte delle aziende. 

Massimiliano: C’è comunque da dire una cosa a questo punto: negli ultimi anni il software è diventato sempre più complesso. Mi ricordo anch’io, avendo iniziato a sviluppare nei primi anni 2000, che c’era lo sviluppatore che faceva il “one man band”: parlava col cliente, si disegnava il software e se lo scriveva.
Forse adesso, nelle aziende si è arrivati ad avere una complessità per cui non ti basta più il singolo sviluppatore che prova a fare tutto.

Fabrizio: Sono d’accordo. Ad oggi purtroppo sono costretto ad evidenziare che ancora molte aziende ci danno il famoso “faldone del capitolato tecnico”. Dicono che lì c’è scritto il progetto e che “ci vediamo tra sei mesi a progetto ultimato”. Questo è impensabile, lo era nei primi anni duemila e ora è una cosa ingestibile.
Un altro punto secondo me fondamentale è quello relativo alla comunicazione.
In passato era evidente la mancanza di comunicazione da parte del business, quindi da parte di chi il prodotto lo pensa e che recepisce gli input dal mercato, verso il team di sviluppo. Oggi sarebbe impensabile: bisogna sedersi tutti quanti allo stesso tavolo e parlare. La comunicazione è uno dei principi fondamentali anche dell’approccio agile. Le persone devono essere al centro del progetto, è inutile lasciare il team di sviluppo isolato dal prendere quelle decisioni, che sono poi fondamentali e che si ripercuotono nello svolgimento del progetto.

Massimiliano: Abbiamo visto quindi una serie di situazioni che si incontrano da sempre nello sviluppo software, cioè problemi organizzativi, problemi di priorità, di comunicazione..
Daniele, come si arriva a elaborare il manifesto vero e proprio, e da lì ai metodi agili?

Daniele: La prima cosa da dire che è che il famoso faldone del capitolato tecnico, che qui chiamerò per comodità il “Grande Piano (™)”, non funziona. Il Software non si sviluppa così e ci sono tanti tanti problemi che si innescano – alcuni li abbiamo accennati. È un approccio che non soddisfa quasi nessuno: non soddisfa il cliente, non soddisfa l’utente finale, non soddisfa i programmatori, non soddisfa il management. Già ben prima del manifesto agile, che è del 2001, c’erano problemi concreti e reali di insoddisfazione e di frustrazione, che avevano portato a tutta una serie di prassi e tecniche. Già c’era Scrum, c’era Extreme Programming, Lean programming di vario genere, e a un certo punto questi programmatori, soprattutto programmatori, come Kent Beck, Jeff Sutherland per Scrum, Robert Martin e altri, decidono di riunirsi nello Utah e di dire: va bene facciamo il punto della situazione, parliamo tra di noi, creiamo il sistema che li dominerà tutti. Mettiamo insieme tutto quello che c’è di meglio e creeremo il manuale di come si sviluppa software davvero. 🙂 Sto scherzando ovviamente, però l’intenzione un po’ era questa.
Hanno fatto quello che era il meglio possibile: una sintesi di tutti i sistemi e di tutti i processi disponibili e hanno messo a fattor comune quelle che erano le idee buone. La domanda era: perché funziona questo processo? Perché Scrum ci piace? Che cosa ci piace di Extreme Programming e perché funziona? Quello che è emerso è appunto il Manifesto Agile, quindi quattro valori e dodici principi, abbastanza generici, per tracciare una direzione

Massimiliano: Quindi possiamo dire che tutti i metodi organizzativi del lavoro che in qualche modo sono conformi ai principi e valori del manifesto agile sono metodi agili. Tra questi anche Scrum, che è uno dei metodi che si possono usare per organizzare un progetto software e che, come diceva Daniele, in realtà nasce prima del manifesto. Visto che risulta conforme a quello che viene fuori dalla scrittura del manifesto, è un metodo agile ante litteram.

Fabrizio: Ricordiamoci che questi metodi non sono validi sempre in assoluto. Si può fare il tentativo di provare a seguire quelli che sono gli aspetti e le “regole” dell’approccio agile, ma non è detto di poter applicare sempre questi concetti nel lavoro di tutti i giorni, anche perché dall’altra parte, come dicevamo prima, c’è un committente, che ha i suoi processi, le sue regole e i suoi tempi, che talvolta tendono a scontrarsi con gli approcci agili che vorremmo utilizzare 

Daniele: Sono d’accordo, anche perché i valori e principi di per sé sono molto generici. Dire: il software funzionante ha più valore della documentazione è abbastanza generico. Non è che la documentazione non ha valore; sì, ha valore, però il software funzionante ha più valore. Poi cosa questo significa nel tuo contesto o nel tuo team, il manifesto non te lo può dire. Se uno riesce ad applicare più o meno tutti questi principi e questi valori – per esempio, lavoro per iterazioni abbastanza brevi, al termine di ogni iterazione rilasciamo un prodotto che ha un incremento di valore, questo prodotto è immediatamente nelle mani dell’utente o del cliente che mi può dare feedback, fare le retrospettive, il team che si auto organizza – si raggiunge piano piano l’ottimale. Che cosa è l’ottimale? È un processo di sviluppo razionale, che là dove ci sono vincoli che mi impediscono di attuare un principio o un altro, va bene, raggiungerò qualcosa un po’ meno ottimale, però se riesco ad applicare 6 principi su 12 è comunque meglio che zero su 12.

Massimiliano: Ma quindi un team che usa una struttura rigida, magari con una road map e Gannt, può lavorare in modo agile?

Fabrizio: Personalmente, penso che l’approccio agile in team di prodotto sia sempre vincente, e anche in quel caso il team può autoorganizzarsi. Sì, è chiaro che è il business che definisce le scadenze e le road map di prodotto, però proprio in funzione di queste indicazioni, il team di sviluppo può autoorganizzarsi in modo tale da centrare gli obiettivi. Senza entrare nel dettaglio, però possono essere applicati almeno alcuni dei principi dell’agile. Uno su tutti, per esempio, quello della comunicazione intesa, come: cerchiamo di fare modo che il team di lavoro nella sua totalità sia allineato su quelli che sono gli obiettivi, su cosa deve essere fatto e sulla possibilità di fornire – tramite ad esempio iterazioni – un pezzettino del prodotto ogni settimana o ogni due settimane, in modo da poter dare qualcosa al marketing per testare quel prodotto lì. 

Daniele: Io partirei da un’osservazione parlando di road map e di gantt rispetto appunto al team agile. Avere il “Grande Piano (™)” semplicemente non funziona e questo è un punto fondamentale. Non è cattiveria. È che per far sì che il “Grande Piano (™)” funzioni, si devono allineare pianeti in un modo perfetto e questa è la cosa meno probabile che ci sia.
Che cos’è un piano? Un piano è quando io scelgo il quando, il come, il cosa, in pratica tutto; quindi nel piano c’è scritto: faremo questa cosa, entro questo tempo, con queste risorse, con queste persone e con questo investimento.
Perché questa cosa abbia successo e funzioni davvero, vuol dire che tu devi avere avuto informazione totale su tutti gli imprevisti, su tutto quello che volevi, su tutto quello che voleva il cliente, su quello che l’utente finale è interessato a comprare o a usare, non ci sono imprevisti, e poi hai fatto osservazioni assolutamente intelligenti su questo e quindi, date le informazioni totali, hai anche elaborato la risposta migliore. Questa qui è la cosa meno probabile che accada. Magari può accadere, ma è veramente la cosa meno probabile. Stai investendo, anzi scommettendo, sul cavallo che non è vincente, magari vince ogni tanto, ma perde 99 partite su 100. E questo al di là di dire se è o non è compatibile con agile. Tendenzialmente no, perché non è un modo razionale di gestire il tuo lavoro.  
Possiamo anche farlo questo piano bellissimo con tutte le scadenze, però poi cominceranno a saltare. E quando cominciano a saltare, che succede? Prendi decisioni difficili, lo metti da parte oppure lo continui a seguire ciecamente facendo finta di nulla? Sei entrato in un vespaio. 

Fabrizio: Qui c’è il primo disaccordo, a quanto vedo

Daniele: Se funziona il “Grande Piano (™)”, funziona, nessuno si accorge di niente. Ma se poi non funziona?

Fabrizio: Io penso che la domanda fosse rivolta per dire: ok, c’è un grande piano in modo che tu sai quale dovrà essere il prodotto finale; verosimilmente ti autoorganizzi, in modo tale da poter portare a compimento il tuo lavoro per poter realizzare quel prodotto.

Daniele: Ok, su questo, sono assolutamente d’accordo. Ma non lo definirei un piano. Questo è: ho degli obiettivi 

Fabrizio: Sì, esatto.

Daniele: Degli obiettivi sì, li voglio avere degli obiettivi e che siano concreti.

Fabrizio: Però torniamo nel discorso di prima, quello del capitolato tecnico dove c’è scritto tutto.

Daniele: Certo questo qui, il “Grande Piano (™)” del capitolato tecnico, con le scadenze e tutto definito, questa cosa è anti agile nel senso che non funziona, non può funzionare, non è una metodologia che ci aiuta.

Massimiliano: Certo, prendere per esempio Scrum e utilizzarlo in maniera molto rigida, in un contesto rigido, non è l’ideale, ma se l’alternativa è non fare niente e lasciare che le cose avvengano da sole, forse meglio Scrum utilizzato in maniera rigida che il caos. 
Altra domanda. Quando si parla di agile, si sente dire spesso che la documentazione è assente perché si sviluppa in maniera iterativa e che non si danno tempi perché si sviluppa mano a mano e non ci dovrebbero essere dei tempi legati all’attività – anche se poi in realtà si cerca di rimetterli dentro utilizzando Scrum, con gli story point o magari con gli sprint. Questa visione dell’agile come occasione in cui si rinuncia a fare delle stime e si rinuncia anche a documentare quello che succede nel codice forse non è esattamente l’agile come ne abbiamo parlato con il manifesto?

Fabrizio: Siamo sempre lì, dipende da che taglio di agile si vuol provare a dare al progetto. Quello che dici è corretto, e mi ci sono scontrato anche io all’inizio. 
Innanzitutto la documentazione assolutamente assente: mi verrebbe da dire no. Nel senso che, se per documentazione si intende il famoso capitolato tecnico di prima, allora sì alzo le mani; ma in realtà io sono il primo a scrivere documentazione, anche solo banalmente per descrivere le storie e le epiche di un progetto, perché spiego cosa sto andando a fare, sia dando un taglio molto alto, ma anche entrando nel livello di user story con taglio più dettagliato. Poi è il team di sviluppo che magari suddivide quelle attività in task. Magari è solo un concetto differente di documentazione.
Per quanto riguarda i tempi – qui magari mi attrarrò le brutte parole di Daniele – con l’inclinazione mia di PM è chiaro che ho bisogno di alcune stime, ecco perché in quel caso i tempi rientrano nel concetto di story point. Dal mio punto di vista, uno sviluppatore, quando prende in carico un task, deve avere una minima idea di quanto quell’attività potrà durare. E in questo modo, raccogliendo tutte le informazioni di tutto il team, si riesce ad avere una stima del prossimo deliverable, cosa conterrà e in quanto tempo verrà sviluppato. Questo penso sia fondamentale anche per il cliente, perché ora noi internamente possiamo fare agile quanto ci pare, però poi dobbiamo rendere conto e lui ha necessità di sapere quando verrà sviluppata quella feature lì.

Massimiliano:  Ma il concetto di stima è vincolante, tipo un contratto firmato, o lo si usa come veicolo per approfondire nel dettaglio le cose che è necessario mettere in road map? Che tipo di problemi riusciamo a prevedere e che tipo di sviluppo riusciamo adesso a intravedere?

Daniele: Chiaramente un contratto firmato, è questa la risposta che aspettavi! :O)
La carta da giocare è sempre: il team si auto organizza. Quindi, per esempio, per quanto riguarda la documentazione tecnica, me lo dirà il team che fare, se la documentazione tecnica serve o non serve e quanto serve. 

Massimiliano: Facciamo infatti una precisazione. Nel manifesto non c’è scritto “working software and no documentation”; c’è scritto: diamo più importanza e più valore al software che funziona rispetto alla documentazione, ma questo non vuol dire non scriverla affatto. 

Daniele: Tradotto: se alla fine dello sprint, mi fai vedere quanti bei documenti hai scritto su google docs, questa cosa non mi fa contento; se invece mi fai vedere una feature, è meglio.
Anche lì, dipende: se stiamo parlando di cose che producono un codice particolarmente complicato, e la documentazione tecnica assume un valore enorme, se il team la scrive va bene. E la stessa cosa per le stime: anche qui c’è un altro membro del team, che è il business, che arriva e chiede: io ho bisogno di queste cose. Di quanto ne ho bisogno? Non lo posso sapere a prescindere. Magari è una cosa fondamentale ed è una scadenza con davvero tanto in gioco, o magari no.
Siamo in un team e dobbiamo venirci incontro su queste esigenze, però non è che un’esigenza può nascondere la realtà. Ci sarà appunto una negoziazione, un punto d’incontro, dove questa conversazione può avvenire. Io ho bisogno di stime, mi sapete dare delle stime, guardando il lavoro pregresso, come è andata? E il team mi dirà: su questa cosa sono più sicuro, su questa cosa sono meno sicuro. Ci deve essere una conversazione che permetta di fare delle scelte razionali.

Fabrizio: Un ruolo fondamentale è quello del product owner perché lui fa da collante tra il business e il team di sviluppo. È lui che conosce le priorità, quindi conosce ciò che c’è lato business, ma sa anche come performa il team, quali sono le eventuali limitazioni che il team di sviluppo ha. È la persona che riesce a individuare il giusto trade off tra quello che il cliente vuole e quello che il team di sviluppo riesce a performare, dando delle priorità che poi sono quelle fondamentali che permettono al team di sviluppo di lavorare .

Daniele: Sì, infatti, il manifesto agile dice: cerca di tenere il business più vicino possibile a te e al team. Quanto più possibile è meglio: se è possibile al 50 per cento, ci prendiamo il 50 per cento, se invece abbiamo appunto un product owner che sta nel nostro team e ci fornisce queste informazioni, ottimo.

Massimiliano: Ecco, abbiamo parlato di stime, che sono uno strumento per comunicare, e del product owner, che ha un ruolo fondamentale nel cercare di favorire la comprensione tra il business e chi realizza il software. È evidente che molto dell’agile ruota attorno alla comunicazione e alla necessità di avere un feedback continuo su quello che sta succedendo.
Fabrizio, tu come fai quando lavori in team a fare in modo che la comunicazione avvenga in maniera continua e possa raccogliere il maggior numero di feedback?

Fabrizio: Io reputo la comunicazione, al netto dell’approccio agile, fondamentale a prescindere. Far sedere allo stesso tavolo tutti gli stakeholder, cioè il business, il marketing, il team di sviluppo, il product owner, lo scrum master, e intavolare una discussione bidirezionale è sicuramente importantissimo.
Per avvalorare questo approccio, io sono un fan delle cerimonie in ambito agile. Il mio calendario è pieno di cerimonie, che sono lo strumento che il manifesto ci mette a disposizione. Internamente, è essenziale lo stand up, quando tutto il team di sviluppo si incontra per discutere cosa è stato fatto ieri, cosa farà oggi, se ci sono dei blocking point.  Mentre è fondamentale coinvolgere anche il cliente nelle review settimanali e nei planning. Questo perché la review – ciò che è stato fatto – gli viene mostrata in tema di deliverable, quindi incremento nel corso della settimana o delle due settimane precedenti. Mentre nel planning – la pianificazione di quello che verrà fatto nelle settimane successive – si cerca di trovare giusto trade off tra quelli che sono i desideri del committente, spesso fantasiosi o di grande ispirazione, e quello che poi è la capacità reale del team. E poi di cerimonie ce ne sono tante altre. Quella che io adoro è sicuramente la retrospettiva, non ne faccio mai quante vorrei in realtà. La retrospettiva è un momento basilare nella gestione del progetto e del team, inteso come appunto gruppo di persone che sono lì, che lavorano insieme per arrivare al raggiungimento dell’obiettivo.
Sappiamo più o meno come è strutturata una retrospettiva: si cerca di capire quali sono i punti che stanno andando bene nel progetto, dai rapporti interpersonali agli approcci tecnici o alle metodologie usate nel processo quotidiano, e questi argomenti si cerca di mantenerli sempre ad uno standard mondo molto elevato. E poi si parla anche delle cose che vanno meno bene: mancanze tecniche del team di sviluppo, mancanza di comunicazione – magari anche da parte mia o da parte del cliente che non ci dà informazioni su quello che è il master plan o quelli che sono gli obiettivi a breve, a medio e lungo termine – o anche problemi nel rapporto interpersonale. 
Reputo la retrospettiva una delle cerimonie fondamentali, proprio per tenere sempre elevatissimo il livello di raggiungimento degli obiettivi del team di sviluppo.

Massimiliano: Daniele, i team come reagiscono quando inizi a chiedere loro di utilizzare retrospettive o altri momenti di comunicazione?

Daniele: Nella mia esperienza, di solito molto bene. Anche perché, come dicevo prima, le disfunzioni del processo di sviluppo frustrano tutti.
Nessuno vuole vedere il cliente che ti dice: vabbè, avete lavorato due settimane, ma queste cose sono sbagliate, non le volevo, non hanno valore per me. Nessuno vuole questo: non lo vuole il business, ma non lo vuole nemmeno lo sviluppatore, che anzi vorrebbe vedere facce soddisfatte, utenti che usano il suo prodotto che ha partorito con tanto dolore, e quindi vedere che sono arrivati da qualche parte questo sforzo e questa energia. Quando cominci a introdurre elementi dell’agilità, che sia con un sistema più organico e più strutturato come Scrum, che sia Kanban o si tratti semplicemente di principi e valori del manifesto, di solito si vedono abbastanza in fretta i risultati positivi, di solito la razionalità del processo emerge.

Massimiliano: Quindi non c’è da aver paura? Insomma, facciamolo!

Daniele: Dalla mia esperienza ti direi no. Non quando vai al team e dici: ok, allora io mi occupo adesso di parlarti di persona e di comunicarti quelle che sono le priorità dello sviluppo, quelle che sono le esigenze del business, quelle che sono le aspettative del cliente. Lo sviluppatore è contento, anzi è quando questo non avviene che c’è confusione, che c’è di frustrazione, perché non si capisce dove stiamo andando e cosa stiamo facendo.
La retrospettiva è fondamentale. Prendiamoci un’ora ogni sprint, ogni due sprint, quando ce n’è bisogno, per fare introspezione, per migliorarci, per capire cosa non va, per parlarne: il team di solito è contento. Oppure usiamo lo stand up meeting: tutti elementi questi molto concreti, che danno un miglioramento tangibile e immediato.

Massimiliano:  Altra domanda: come si convince il cliente che agile è meglio rispetto a un processo rigido come Waterfall?

Fabrizio: Bella domanda, anche perché mi verrebbe da dire che non è possibile convincere immediatamente. Non posso, se non magari con esperienze pregresse, dimostrare la bontà dell’agile rispetto a Waterfall. Vi porto una mia esperienza: mi è capitato di lavorare con un’azienda che aveva sempre lavorato in maniera waterfall e abbiamo deciso con loro di provare a utilizzare un approccio differente. È una azienda di refrigeratori industriali, quindi parliamo di elettronica, meccanica e software, che arrivava da un settore molto verticale su un approccio di questo tipo e che ci ha commissionato un prodotto alla fine del progetto Come abbiamo fatto? È stato un discorso abbastanza progressivo e lungo, e qui c’è da anche da ringraziare l’azienda cliente, perché si è dimostrata immediatamente aperta al cambiamento. Quello che siamo riusciti a dimostrare loro è stato il vantaggio di avere avanzamenti piccoli e la possibilità di ottenere ogni due settimane un piccolo incremento del prodotto. Perché poi queste cose hanno permesso loro di iniziare prima del previsto tutta una serie di meccanismi e processi previsti per il termine del progetto, quali i test, i field test, i test end to end, e hanno potuto iniziare a provare subito parti del prodotto. Di conseguenza, il loro marketing si è messo immediatamente in moto per far vedere le porzioni del prodotto ultimate alle sedi all’estero, quindi i feedback sono stati immediati. In questo modo si capisce da sé: piuttosto che avere un faldone di riscontri sul prodotto alla fine, dopo magari sei mesi, quando qualsiasi intervento sarebbe stato più oneroso, la possibilità di averne immediatamente ogni due settimane permetteva chiaramente a noi di fixare i bug che c’erano e anche di recepire quelle modifiche che magari provenivano dal campo direttamente dai field test fatti dal cliente stesso.
Per cui, come si convince? È implicito, il cliente vede i benefici andando avanti col progetto stesso.

Massimiliano:  È possibile utilizzare agile all’interno di progetti in cui il tipo di industria o il tipo di lavoro sono, per definizione, molto rigidi, come per esempio quello medicale o aerospaziale?
Daniele che ne pensi?

Daniele: Io non ho esperienza proprio diretta su industria aerospaziale, ma spero di riuscire comunque a rispondere a questa domanda. In questa situazione presentata ci sono più vincoli: esiste un processo di certificazione, i tempi devono essere certi, ci sono delle leggi che devono essere rispettate anche sul modo in cui si scrive il software, quindi abbiamo vincoli che si aggiungono ai vincoli.
In questo caso, si può nuovamente andare di best effort: questi vincoli che non possono essere allentati in nessun modo, vanno tenuti in considerazione, va bene. Però per tutto il resto che sta intorno, nuovamente l’approccio agile è secondo me l’approccio più razionale e quindi dobbiamo cercare di applicare certi principi: comunicare le priorità, comunicare le specifiche nel modo migliore possibile, se il tuo cliente è in una condizione in cui non è minimamente interessato ad avere un prodotto incrementale, va bene, allora le demo interne falle comunque; magari il cliente non è interessato, non viene perché magari è un’industria particolare con particolari vincoli, ok, il prodotto non ha valore fino alla fine, va bene, però noi che lo sviluppiamo comunque diamoci delle scadenze, facciamo delle demo, facciamo delle dimostrazioni interne, cioè segniamo comunque il progresso.

Fabrizio: Sono d’accordo con quello che dice Daniele, ma soprattutto non è sempre possibile applicare l’agile. Credo di dirlo con  ragionevole certezza. Ma poi tra il non applicarlo affatto e applicarlo totalmente, quindi tra il bianco e nero, ci sono infinite tonalità di grigio per cui comunque si mettono in pratica determinate attività che verosimilmente possono portare del valore. I vincoli rimangono fissi, però se facciamo delle cerimonie o delle demo bisettimanali, qui credo che non si vada a intaccare nessun tipo di vincolo.

Massimiliano: Sì, sono assolutamente d’accordo, anche io punterei molto su cosa adottare di agile e perché, all’interno di un contesto. Alla fine quello che è importante non è tanto quanto uno è agile da 0 a 100, ma usare una serie di strumenti e di tecniche che possono migliorare la realtà delle persone che devono lavorare; cerchiamo di introdurre qualcosa, vediamo se funziona e andiamo avanti.
Altra domanda: agile prevede, e in che modo, approccio di metodi di risk management sulla gestione dei progetti?

Massimiliano: Rispondo io perché mi ricordo un bellissimo talk del 2019 di Emiliano Soldi all’Agile Day su questo tema, cioè “Scrum come framework di risk management”. La risposta secondo Emiliano – e sono d’accordo – è sì, dipende da cosa si intende per framework di risk management. Se si intende un piano e torniamo lì, al grande piano che cerca di prevedere tutti i possibili esiti, ecco se si intende in questo senso il risk management, no, sicuramente agile in questo non aiuta. Se invece il risk management si intende come un percorso che ti porta via via a tirare fuori quelli che possono essere le fonti maggiori di rischio e non spendere troppo tempo e troppo lavoro su quegli aspetti più critici che vengono fuori man mano che vai avanti in uno sviluppo, e quindi invece su quali aspetti soffermarsi e su quali aspetti concreti andare a fare un’analisi dei rischi, ecco su un piano di risk management inteso in questo senso, l’Agile può dire qualcosa. Però il mio consiglio è di guardare il video di Emiliano Soldi all’ “Agile Day, 2019”.

Massimiliano:  Parliamo di agile e software che funziona. Molto spesso c’è questa polemica tra chi utilizza metodi agili e chi li vede un po’ come tecniche che vanno bene per organizzare meglio il lavoro, per comunicare più efficacemente, però poi alla fine devo scrivere software e in questo non mi aiutano. Dato che un punto del manifesto è il “working software”, in che modo agile aiuta a far venire fuori del software che funziona meglio?

Daniele: È il risultato dei vari principi e dei vari valori che vengono applicati che fa la differenza. Vediamo se riesco a risponderti. Un primo punto è: assicurati che il tuo lavoro stia andando nella direzione giusta: quindi parlo con il cliente, con l’utente finale, quindi mi assicuro che ci sia valore in questa direzione. Ok, primo punto fatto. Magari questo valore potrebbe essere una feature anche a discapito di qualche bug in un primo momento, non lo so, parliamone col management, parliamone con il cliente, questo è comunque un compromesso accettabile se è negoziato e se è consapevole. Quindi stiamo andando nella direzione giusta. Do il il potere tecnico al team che si autorganizza – altro principio –  e quindi prendo le persone che hanno la più alta probabilità di essere informate sui fatti tecnici e le decisioni tecniche le fanno loro, quindi riduco le probabilità che si introducano problemi tecnici, perché decisioni di non tecnici vanno a sabotare il lavoro dei tecnici per esempio. Quindi altro punto fatto. Sei tu il tecnico, mi fido, mi fido del mio team: se il mio team dice che bisogna fare le cose in un certo modo, sicuramente ne sanno più loro di me, e anche se la decisione non è quella giusta al cento per cento perché siamo esseri umani, loro sono quelli che sapranno decidere meglio come gestire questo problema.

Massimiliano: Ma mi fido nel senso più religioso del termine fede che funzioni o agile mi dà degli elementi un po’ più concreti per dire sì, il team sta lavorando, sta facendo il meglio che può?

Daniele: Nel senso proprio di fiducia o se vuoi anche in un certo senso di delega. Per le questioni tecniche, io delego a quelli che sono gli esperti all’interno del mio team: il team ha certi esperti e certe potenzialità tecniche al suo interno e delego a queste potenzialità tecniche, a queste persone, le decisioni che più sono vicine a loro. In una negoziazione ovviamente, c’è sempre un punto di dialogo aperto. Non sto isolando i tecnici, non è che non mi interessa cosa fanno. Magari si possono dare anche input, si possono prendere input dall’esterno, ma il team degli sviluppatori dovrebbe guidare la barca per quello che riguarda le decisioni tecniche, i rischi tecnici e le problematiche tecniche. 

Fabrizio: Quasi una condivisione delle responsabilità.

Daniele: Esatto. Se siamo un team di persone dove c’è il business, dove ci sono i tecnici, dove c’è il management, guidiamo insieme la barca e siamo tutti corresponsabili. Questo però va in combinazione con i principi dell’agile: quindi io mi sono assicurato che stiamo andando nella direzione giusta, che sto estraendo valore, mi sono assicurato che le decisioni tecniche le guida il team tecnico, sto andando nella direzione in cui è più probabile che emergano software, scelte, feature di qualità. Il team mi dice che il debito tecnico sta salendo, avremo bisogno di spendere e investire più tempo per ridurlo; ecco se il team ha la possibilità di dirlo, se c’è una conversazione che avviene dove questo bisogno può essere espresso e dove possono essere prese scelte razionali al riguardo, è più probabile che il debito tecnico venga tenuto sotto controllo. 
Altro principio agile: cerca di fare iterazioni brevi. Anche questo va in combinazione con tutto il resto. Quindi tutto quello che ho appena detto lo aggiorno non ogni sei mesi, ma ogni settimana; ci riconfrontiamo ogni settimana perché anche il valore che un prodotto ha può cambiare, cose ritenute importanti un mese fa potrebbero non esserlo più oggi, per questioni esterne. Se ho del software funzionante, che ho rilasciato, che posso mettere alla prova, posso cambiare il percorso di questo software, non ogni sei mesi, ma ogni settimana, ogni due settimane. 
Anche qui: gli sprint sarebbe meglio che fossero abbastanza brevi, una settimana sarebbe forse l’ottimale, sarebbe perché mi permette di reagire al cambiamento.
Sono tanti tasselli, che quando si incastrano danno un valore maggiore della somma delle parti.

Massimiliano: E quindi di conseguenza producono un software che sembra funzionare meglio, ma in realtà poi funziona meglio per tutto un insieme di fattori però che vanno un po’ a lavorare insieme.

Daniele: Hai costruito un processo che probabilisticamente tende a produrre software di migliore qualità e questo si rifà anche alla domanda di prima del risk management. Ragionando in termini di probabilità, sto allocando gli investimenti cercando tutte le volte di investirli nelle cose a più basso rischio. Il rischio c’è sempre, ma sto lo sto limitando quanto possibile.

Massimiliano: Sono mai capitati clienti che hanno chiesto un’offerta con tempi e costi ben definiti e non hanno voluto sentire parlare di metodi agili? Quelli che vogliono sapere quanto costa fare questo contratto, questo faldone di 100 pagine entro, non lo so, il mese prossimo, anzi è quasi sempre entro la settimana prossima… 

Fabrizio: Entro ieri magari!

Massimiliano: Ecco è capitato? Sì, rispondo io, è capitato. Che cosa facciamo in questi casi Fabrizio? Qual è metodo migliore di lavorare contrattualmente con questi clienti?

Fabrizio: Innanzitutto si fa opera di persuasione verso il cliente, nel senso che si fa capire che non siamo in grado ad oggi di poter stimare un lavoro della durata di – anche banalmente – un mese. Quello che è il miglior approccio commerciale in questo caso, o comunque quello che meglio si sposa con quelli che sono gli approcci di tipo agile, sono i contratti “time and material”. Il cliente, piuttosto che spendere una certa somma di danaro senza però essere poi certo che il progetto sarà ultimato alla fine del budget, acquista invece un monte ore, quindi un budget inteso proprio come una certa quantità di ore di lavoro, e all’interno di questo costo fisso ci sono feature variabili, quindi è proprio in relazione a quelle che sono le sue priorità, che il cliente indica quelle che saranno lavorate per prime. Per quanto riguarda il tempo che il cliente ha acquistato e che noi internamente allochiamo nello sviluppo del prodotto, all’inizio vengono sviluppate, costruite e realizzate tutte quelle funzionalità che hanno una priorità più alta per il cliente stesso, e via via con il passare del tempo si cerca sempre di andare a realizzare le feature a priorità sempre minore. Questo vuol dire che, verosimilmente, a una certa percentuale del monte ore, il prodotto avrà già esaurito le feature prioritarie, per cui spesso il monte ore restante viene utilizzato per enhancement, o anche per bugfixing, o eventuali revamping che ci sono del prodotto stesso. 
Quindi sicuramente “time and material” è quello che si sposa meglio. Tutto sta a convincere il cliente a utilizzare lo stesso budget con costo fisso e features variabili. Però, come dicevo prima, come fai a convincere un cliente? Non devo convincerlo, il cliente si convince da solo in base a quelli che sono i deliverable che vengono prodotti dal team.

Massimiliano: Daniele cosa consiglieresti a chi vuole iniziare a utilizzare agile senza per forza dover adottare una metodologia specifica, ma volesse capire cosa utilizzare velocemente all’interno del suo lavoro nel team? 

Daniele: Il manifesto agile sono davvero quattro valori e dodici principi, è alla portata di chiunque. Il primo passo probabilmente dovrebbe essere un po’ un esame di coscienza di quanto ci si crede davvero, perché sono valori e principi abbastanza leggeri da leggere, ma in realtà sono molto densi, ci sono implicazioni abbastanza importanti dietro ognuna di quelle righe scritte. Ma quanto ci crediamo davvero? Quanto ci crediamo davvero che è importante parlare con il cliente? Quanto ci crediamo davvero che è meglio lavorare per interazioni brevi, avere lo sviluppo di un prodotto funzionale, ecc?
Se uno ci crede davvero, fa la prima retrospettiva. Cominciamo con una bella retrospettiva di cosa non va e cosa va, e soprattutto capiamo se ci sono elementi nella nostra abitudine di lavoro corrente che possiamo rivedere alla luce di quelli che sono i principi del manifesto.
Se cerchiamo un approccio più “agile” all’agile, vanno bene una retrospettiva e poi un po’ di lavoro di introspezione, di aggiustamenti. Chiaro che la cosa più importante è nella comunicazione, quindi uno si deve creare gli spazi dove questa comunicazione deve avvenire: se non fate un daily, fatelo; se non fate una retrospettiva, fatela; se non avete riunioni, planning di qualche tipo, dove l’input del cliente e del business può arrivare, pianificateli; se non fate demo interne, cominciate a farle; se i vostri sprint non hanno obiettivi, se le vostre iterazioni, qualunque esse siano, non hanno degli obiettivi concreti alla fine, definite obiettivi concreti e verificateli insieme. 
Come faccio a sapere che il mio obiettivo è concreto abbastanza? Riesco a fare una demo con un software funzionante di codice mergiato sul master – giusto perché ci sono tanti programmatori che ci seguono – mergiato davvero, con tutti i requisiti che noi riteniamo essere necessari per essere un deliverable che davvero funzioni e secondo quelle che sono le aspettative? Questa è una cosa che il team dovrebbe essere totalmente in grado di fare.
Con questi elementi qui: la comunicazione, i deliverable, le retrospettive, stai già facendo tanto rispetto al caos.

Massimiliano: Fabrizio visto che sei cintura nera di retrospettive, rispondi: cosa ne pensi quando accade che tra la feature che viene consegnata e poi la retrospettiva che si fa magari su quella feature, passano dei mesi? è sempre utile fare la retrospettiva oppure la retrospettiva va fatta al momento giusto?

Fabrizio: Bravo, quando ho parlato di retrospettiva, ho detto che non ne faccio quante in realtà ne vorrei o comunque non “azzecco” mai il momento giusto. Non esiste un gruppo di lavoro che non ha problemi, siano essi problemi interpersonali o problemi di lavoro quotidiano, o tecnici o di comunicazione con il cliente. Quindi la retrospettiva andrebbe pianificata con regolarità. Ogni quanto? Dipende, come un po’ tutto nel mondo agile: in un team di lavoro medio, direi probabilmente anche alla fine di ogni sprint, però magari potrebbe essere troppo oneroso. Direi una volta al mese, perché così si accumulano un po’ di informazioni e dati, per poter poi mettere in pratica quelli che sarebbero gli elementi costruttivi e migliorativi.

Massimiliano: Bene, purtroppo siamo veramente alla fine. Prima di salutarci, volevo dirvi che se siete interessati al mondo dell’agile e magari volete fare networking con altri appassionati che in Toscana – zona di Firenze e Pisa – si interessano di agile, trovate su meetup un gruppo che si chiama Agile Lean Tuscany, ne faccio parte anch’io.
In epoca pre-covid, una volta al mese ci ritrovavamo tutti insieme allo Student Hotel a Firenze. Speriamo di ritornare all’incontro in presenza, e quindi per sapere quando ripartiremo, iscrivetevi al gruppo. Speriamo di vederci al più presto!