IAD 2021 – Conferenza di Sabato 13 Novembre

Keynote “L’illusione dell’ortogonalità (la sfiga non esiste)”

Alberto Brandolini, CEO di Avanscoperta, ha curato il keynote di questo IAD 2021 parlandoci di ortogonalità, o meglio dell’illusione dell’ortogonalità.

Cosa abbiamo scoperto in questi 20 anni di vita del Manifesto per lo Sviluppo Agile di Software?

Focalizzarsi su un singolo aspetto –  il processo, il Test-Driven Development (TDD), l’avere un codice pulito, o Clean Code – non porta da nessuna parte. I veri cambiamenti avvengono quando scopriamo le reali interazioni tra le parti, quando lasciamo la specializzazione e cominciamo a vedere il vero quadro d’insieme.

TDD

Per chi lavora praticando il TDD sa bene che porta diversi vantaggi quali un design dell’applicazione migliore e del codice affidabile perché sviluppato appunto “guidato dai test” – e aperto alle evoluzioni. Il TDD non è una pratica strettamente ingegneristica, secondo Alberto ha impatti anche a livello di ansia, pianificazione e reattività di business.

Per rendere più coinvolgente e divertente il suo ragionamento, Alberto ha utilizzato un personaggio immaginario, Sam. Un uomo di una certa età e con una certa esperienza, un po’ scettico e soprattutto sospettoso.

Che cosa dice Sam?

“Se lavori applicando il TDD ci metti il doppio del tempo per fare qualunque feature.” e ancora “Non sempre funziona”.
Prendiamo il seguente scenario di un team composto da persone che non lavorano in TDD oppure dove è un solo membro a praticarlo. Che cosa succede? Si hanno porzioni di codice completamente testate e altre no, quindi non appena si esegue un commit sul branch la pipeline inevitabilmente si rompe.

Sam, reticente al TDD, inizia a praticarlo per poi dire al collega “Io cucino, il tempo laverà i piatti” ovvvero “Ti accontento, però ricorda che sei la persona che vuole la cucina pulita ogni volta, ora quindi la devi mantenere pulita“.

Certi contesti lavorativi, dove si possono trovare persone come Sam che non colgono il reale valore di alcune pratiche, non sono contesti vincenti.

Quale ingrediente manca? Per Alberto è una questione di assenza di confini, chiari e condivisi, ad esempio delle best practice condivise da tutti.

Contesto

Sam continua ad essere scettico perché, nonostante lavorare in TDD abbia migliorato il codice e la qualità del prodotto, i bug rimangono.
È una questione di contesto, è fondamentale lavorare avendo piena consapevolezza dei confini all’interno del quale potersi muovere.

Riprendendo l’approccio Domain-Driven Design (DDD) e le sue definizioni fondamentali (dalla pagina Wikipedia), il contesto è importante:

• Dominio: un contesto di conoscenza, influenza, o attività. L’area in cui l’utente lavora con il software è il dominio dello stesso.
• Modello: un sistema di astrazione che descrive specifici aspetti del dominio e che può essere usato per risolvere problematiche relative alla definizione del dominio.
• Ubiquitous Language: un set di termini creato attorno al modello di dominio utilizzato dal team per indirizzare e contestualizzare i problemi da risolvere durante l’implementazione.
• Contesto: l’ambiente in cui un determinato termine assume un determinato significato.

Esiste anche il concetto di Bounded Context, ovvero ambiti applicativi indipendenti gli uni dagli altri ed ognuno con il proprio Ubiquitous Language. Dotarsi quindi di Bounded Context aiuta a capire come risolvere un problema specifico per certe persone e con un certo obiettivo. Quindi con confini ben precisi.

Sam ha un’altra obiezione: “Ok, ho svolto degli esercizi in TDD ma la realtà è tutta un’altra storia”.
Se fatto bene, anche un progetto reale è simile agli esercizi, è tutta una questione di avere definito dei confini ben precisi.

Stime e dipendenze tra team

Bisogna tener conto anche delle stime quando lavoriamo ad un progetto. È difficile, ma non impossibile, stimare il lavoro. Stimare zone ad alta incertezza (codice legacy pericoloso o attività altrui) ha margini di errore decisamente più alti. Le dipendenze contano, anche quando vorremmo che fosse solo un problema di processo. Magari c’è un problema di architettura che limita le relazioni tra le persone in azienda.

Idealmente ogni team dovrebbe rispondere a pochi progetti, ma la realtà è ben diversa: i team hanno dipendenze tra loro che portano inevitabilmente a problemi. Prendiamo per esempio un’azienda con diversi team che lavorano su uno stesso progetto, può capitare che magari un team rimanga fermo fintanto che l’altro team non avrà completato un lavoro. Peggio ancora quando un team, magari con skill specifiche, è fermo in attesa del completamento di una precisa fase del progetto.

Architettura

Alberto ha utilizzato una metafora tanto simpatica quanto calzante, ovvero quella del “mammut nel guardaroba” per parlarci di tutti quei casi in cui un’azienda progetta una applicazione software partendo da dati centralizzati in un unico database, il mammut appunto. Adottare questo approccio porterebbe quasi certamente ad avere una centralizzazione di concetti, inoltre le forti dipendenze architetturali e di team si tradurrebbero in problemi di coordinamento e stress…insomma, un freno lato business.

Intanto il caro e vecchio Sam fa un’altra obiezione: “Stiamo passando a un’architettura a microservizi, non c’è problema. Tutto si risolverà.”.

Event-Driven Design

Perché non basarsi su un’architettura Event-Driven, ovvero guidata dagli eventi? Questo tipo di architettura può aiutare le organizzazioni a realizzare un sistema flessibile che consenta loro di trasformarsi prendendo anche decisioni in tempo reale. Disporre di informazioni in tempo reale significa poter sfruttare tutti i dati disponibili che riflettono lo stato attuale del sistema per prendere qualsiasi decisione aziendale, sia manuale sia automatizzata.

Conclusioni

Come riportato nel titolo del suo keynote, la sfortuna nei progetti non esiste. Sono le aziende stesse a “fare sì che vada male”. Ciò che dobbiamo fare è ripartire dalle basi, dalle piccole attività ma fatte bene (Pair Programming, TDD, ecc…) lavorando in contesti ben definiti dove tutti abbiano ben chiaro l’obiettivo finale.

UX for Developers

Antonio Dell’Ava, sviluppatore frontend per Flowing, ha proposto una “narrazione” del mondo User Experience (UX) per gli sviluppatori con l’obiettivo di fornire nozioni di base e spunti per migliorare la collaborazione e la consapevolezza all’interno di un team Agile: il modello Design Thinking.

Design Thinking

Di seguito ripercorriamo le cinque fasi di questa metodologia Agile e “user-centered”:

• Emphatize: si raccolgono quante più informazioni reali possibili – attraverso interviste, questionari ecc. – sull’utente mettendo da parte giudizi e aspettative. Questa prima fase richiede cura dei dettagli per definire le cosiddette “personas” che saranno poi il fulcro della sessione intera, da cui partiranno e si svilupperanno idee e soluzioni.
  Per realizzare un’intervista che sia di valore Antonio ci lascia alcuni suggerimenti:
  • Imparare a fare le domande giuste alle persone giuste.
  • Arrivare all’intervista con una lista di domande già pronta.
  • Presentarsi, magari spiegando l’obiettivo dell’intervista.
  • Raccogliere dati che siano più eterogenei possibili, sia sul prodotto che sulle abitudini dell’intervistato.
• Define: utile per individuare la definizione del problema dell’utente. È necessario definire le difficoltà e gli ostacoli che incontrano gli utenti e circoscrivere il problema che il team è chiamato a risolvere. Si formalizzano dei modelli utilizzando User Personas o Jobs-To-Be-Done per identificare le caratteristiche chiave degli utenti basandosi sul contesto (fattori esterni, bisogni, valori e obiettivi che influenzano l’esperienza della persona), stato emozionale (sentimenti ed emozioni nelle varie fasi), azioni (cosa vuole fare concretamente la persona), fattori chiave (touchpoint e nuove opportunità).
• Ideate: a questo punto si iniziano a progettare le soluzioni. Qui è necessaria la creatività e la capacità di ideazione dei partecipanti. È necessario e utile riunire il team, anche più volte, al fine di raccogliere e confrontare il maggior numero di idee possibile. Si possono usare diverse tecniche di ideazione come brainstorming e mind-mapping.
• Prototype: in questa fase si passa alla trasformazione delle idee in prodotti tangibili. Si tratta fondamentalmente di una versione ridotta del prodotto che incorpora le potenziali soluzioni identificate nelle fasi precedenti. Qui emergono e si evidenziano eventuali problemi e difetti e a questo punto le soluzioni progettate possono essere confermate, migliorate, ridisegnate o rifiutate.
• Test: si testano le soluzioni sugli utenti, che non significa essere arrivati alla fine del processo. I feedback relativi al test possono far emergere elementi per cui sarà necessario ridefinire l’analisi del problema originale o elaborare nuove idee.

What leaders can learn from the Montessori Method

Simone Casciaroli, Engineering Manager per Babylon Health, a IAD 2021 ha affrontato la tematica della leadership da un punto di vista personalmente molto originale.

Tutti abbiamo sentito parlare almeno una volta del Metodo Montessori, l’approccio educativo per bambini sviluppato da Maria Montessori nei primi del Novecento. È un metodo che si sposa bene con il mondo del coaching, perché è legato a concetti ancora attuali.

Molti leader lottano per creare team autonomi e abbandonare i comportamenti di controllo. Simone ha spiegato i principi del Metodo Montessori per vedere che cosa si può utilizzare per promuovere l’autonomia pur essendo di supporto:

• Preparare l’ambiente affinché sia accogliente e metta a proprio agio le persone, come avviene in molti asili dove si utilizzano tutti gli oggetti a misura di bambino: le sedie, i bicchieri…tutto a misure e altezza giuste. Dobbiamo quindi pensare a processi e strumenti ad-hoc e semplici da usare. In definitiva è importante settare l’ambiente affinché l’azione X sia la più semplice possibile da svolgere.
• Indipendenza: se un team si propone per fare un’attività in autonomia quale preparare le slide per una demo, è giusto lasciarlo lavorare e non intervenire. Sicuramente commetterà degli errori ma con il tempo imparerà anche grazie ai feedback ricevuti, proprio come un bimbo che vuole pulirsi le mani o vuole mangiare da solo.
• Libertà all’interno di confini. Riprendendo uno dei punti del keynote di Alberto Brandolini, è importante definire dei confini e divulgarli a tutto il team e all’organizzazione. Confini che vanno pensati in base anche al rischio dell’azione.
• Rispetto. Come un bimbo cresce con i suoi tempi, anche nel lavoro è giusto pensare che ogni persona dia il massimo e cresca in base alle proprie capacità.

Miglioramento dei team: come rendere efficace una Retrospettiva

Massimo Terzo, dalla sua esperienza di Agile Coach, ci ha parlato di come rendere efficace una retrospettiva riferendosi al modello dei “5 step” descritto nel libro “Agile Retrospectives: Making Good Teams Great” di Ester Derby e Diana Larsen.

Che cosa si intende per retrospettiva e a cosa serve?

Prima di iniziare Massimo ha dato una sua definizione del termine retrospettiva. Il termine è un po’ fuorviante perché significa “guardare indietro” nell’iterazione appena conclusa per capire cosa ha funzionato e cosa no. A ben pensarci il reale valore di una retrospettiva è per l’immediato futuro, alle prossime iterazioni di progetto. Questa cerimonia serve a tutto il team per migliorare.

Cosa NON è una retrospettiva?

La retrospettiva non è un “post-mortem” anzi deve essere un momento in cui il team si ritrova per fare emergere cosa non ha funzionato e trovare delle soluzioni al fine di migliorare il lavoro futuro del team. Dovrebbe essere visto come un laboratorio dove poter sperimentare e dagli esperimenti raccogliere i dati – i feedback – per trovare ulteriori spunti di miglioramento.

Cos’è una retrospettiva efficace?

Agile vuol dire adattabilità, qualcosa che comporta un’evoluzione. L’adattabilità si declina in:

• Adattabilità di prodotto, da realizzare in maniera incrementale, con demo e review del prodotto in base ai feedback. Il feedback ci fa evolvere, in termini di prodotto.
• Adattabilità di team, dei processi, di come si lavora. La retrospettiva è un elemento chiave.

Secondo l’esperienza di Massimo la retrospettiva spesso non viene fatta dai team, e quelle volte in cui si svolge viene vista come un “waste of time”, una perdita di tempo.

Come fare per rendere efficace una retrospettiva?

Massimo ha ripreso ognuno dei cinque step del modello:

• Set the stage – In questa prima fase va definito l’obiettivo, spiegare a cosa serve fare la retrospettiva. E’ importante chiedere al team su cosa voler concentrare l’attenzione e quali sono gli obiettivi, prestando attenzione che ciascun membro dia la sua opinione facilitando il tutto anche con rappresentazioni grafiche.
• Gather data – Si raccolgono i dati per capire a che punto del progetto si trova il team, una sorta di istantanea della situazione. Bisognerebbe cercare di usare tutti i dati a disposizione – ad esempio le metriche o gli eventi del calendario accaduti durante lo sprint – e integrarli con le sensazioni e il morale del team. Potrebbe essere di aiuto utilizzare dei post-it colorati (ad esempio il verde per scrivere eventi positivi, il rosso per eventi negativi). In questa fase esistono diverse tecniche descritte nel libro quali “Timeline” o “Mad, Sad, Glad”.
• Get insight – I dati raccolti vanno analizzati per focalizzarsi su ciò che è emerso e identificare eventuali trend, relazioni e connessioni. Tramite l’attività di “Dot-voting” il team potrebbe prioritizzare i dati assegnando ad ognuno dei pallini (tipicamente tre a testa per ogni membro). In questa fase si deve capire perché siano successe delle cose e perché ci si trovi in una certa situazione. Dalla metodologia Lean viene in aiuto il diagramma di Ishikawa, conosciuto anche come “Fishbone Diagram”.
• Decide actions – Il team deve decidere quali azioni, chiare e realizzabili, intraprendere in base alle analisi svolte sui dati. Potrebbe essere utile ricorrere al “Dot-voting” per prioritizzare le azioni e sceglierne una, massimo due da mettere in pratica nell’iterazione successiva. Massimo ricorda che tutto il team è responsabile delle azioni, e che le azioni sono esperimenti. Dopotutto operiamo in un ambiente complesso, sempre più dominato dall’incertezza, perciò sperimentale è fondamentale.
• Close the retrospective – In quest’ultima fase si riassumono i risultati e si tiene traccia degli insegnamenti (ad esempio con poster o scrivendo in una wiki interna). Ultima ma non meno importante, si dovrebbe fare una retrospettiva della retrospettiva, per capire cosa migliorare per le volte successive.

Nell’ultima parte di questo interessante talk Massimo ci ha regalato alcuni consigli:

• Non usare un tono accusatorio con le persone durante la retrospettiva.
• Preparare un ambiente che sia il più possibile sicuro e stimolante.
• Evitare condizionamenti esterni come ad esempio figure manageriali che potrebbero mettere in soggezione qualche membro del team.
• Fare attenzione al Groupthink, o pensiero di gruppo, condizione che potrebbe manifestarsi quando si ha a che fare con un gruppo coeso, che lavora insieme da tempo, e che quindi è affiatato. Piuttosto sarebbe utile creare dei sottogruppi per stimolare la creatività e la conversazione.
• Evitare che si concluda una retrospettiva senza azioni, c’è sempre qualcosa su cui migliorare.
• Cambiare sempre modello e attività, questo perché bisognerebbe fare evolvere la retrospettiva con il team.
• Fidarsi del team.

Leading by coaching. New leadership patterns to drive changes

Federica de Benedittis, Soft Skill Specialist per aziende profit e non profit, ci ha portato la sua esperienza in materia appunto di soft skill, conosciute anche competenze trasversali, sempre più importanti per le aziende odierne che operano in un mondo in continua evoluzione.

V.U.C.A.

Negli ultimi anni abbiamo sentiamo parlare di contesto V.U.C.A. per descrivere un ambiente complesso e incontrollabile, a complessità crescente. L’acronimo sta per “Volatility Uncertainly Complexity Ambiguity”, quattro aspetti che caratterizzano il nostro mondo. Per ulteriori approfondimenti vi rimando al mio articolo sul talk tenuto da Jurgen Appelo durante IAD 2020.

Pensiamo a eventi di massa quali la rapida urbanizazzione, il cambiamento demografico, la globalizzazione, la sempre più rapida innovazione tecnologica. Sono tutti fenomeni che contraddistinguono questo contesto.
Le organizzazioni hanno bisogno di affrontare un rapido cambiamento in modo creativo per sopravvivere. Nuove competenze e capacità sono fondamentali per guidare i team e guidare l’organizzazione al successo. Per queste ragioni stanno nascendo nuovi modelli di leadership. I leader efficaci sono coloro che si avvicinano allo staff con uno stile di coaching che permette loro di ispirare e motivare profondamente le persone nell’ambiente di lavoro.

Come può un leader gestire la complessità e aiutare l’azienda?

Federica ci ha parlato di due soft skill molto importanti che ogni leader dovrebbe avere: decision making e problem solving.

Il decision making fa leva sulla capacità di scelta della persona, ovvero sul processo mentale che porta a individuare la migliore strategia di azione possibile tra le diverse alternative.

Con problem solving si intende la capacità di risoluzione dei problemi. A prima vista può sembrare una caratteristica comune a chiunque, ma come ci troveremmo nel caso in cui da una nostra scelta dovesse dipendere il successo o l’insuccesso di un business dell’azienda per la quale lavoriamo? Ecco dunque spiegata l’importanza della “capacità di problem solving”.

Decision making e problem solving sono importanti ma da sole non bastano. Un buon leader dovrebbe saper indirizzare le persone nel prendere le decisioni giuste.

Servirebbe una “spintarella”.

La teoria dei nudge

In base alla teoria dei nudge, spiegata e difesa nel 2008  dall’economista Richard H. Thaler – il quale nel 2017 vinse il Premio Nobel per il suo contributo all’economia comportamentale – e il professore di Legge della Harvard Law School Cass R. Sunstein, è possibile alterare il comportamento delle persone in modo prevedibile e indirizzarle verso la scelta desiderata sfruttando distorsioni sistematiche (più note con i termini routine o abitudini) che influiscono sulle nostre decisioni e impediscono una valutazione imparziale delle opzioni disponibili.

Questa teoria trova applicazioni in diversi ambiti quali economia e psicologia comportamentale, ed è ampiamente sfruttata anche nel marketing e nella politica.

Federica ci ha riportato un esempio di “nudging” che rende abbastanza bene l’idea: negli anni Novanta in Olanda decisero di applicare un adesivo a forma di mosca sugli orinatoi maschili dell’Amsterdam’s Schiphol Airport. Questa mossa economica e poco impegnativa garantì che gli utilizzatori prendessero la mira come cecchini, con notevoli risparmi sulle pulizie.

Behavioral coaching

Ultimo ingrediente, ma non meno importante, per un leader è la capacità di saper aiutare le persone ad aumentare la loro efficacia e la felicità sul lavoro.

Federica ci ha parlato quindi di behavioral coaching, o coaching comportamentale, che può essere definito come la scienza e l’arte di facilitare le prestazioni, l’apprendimento e lo sviluppo dell’individuo o del team, che a sua volta assiste la crescita dell’organizzazione.

Conclusioni

Che posso dire di di IAD 2021?

Per il secondo anno consecutivo abbiamo vissuto le due mezze giornate da remoto. Nonostante tutto ho notato una bella e vivace partecipazione da parte di tutti i presenti, accomunati da un unico grande interesse: l’Agilità.

Ricorderò volentieri questa edizione degli Italian Agile Days anche per essere stato il mio “battesimo di fuoco” come moderatore di una delle stanze, esperienza che quasi certamente replicherò.

Con la speranza di potervi raccontare il prossimo IAD vissuto in presenza, vi saluto e vi ringrazio per aver dedicato del tempo leggendo questo mio articolo.