IAD 2020 – 13 Novembre

Why all attempts to improve estimation have and will continue to fail!

(and what to do instead)…come si evince dal titolo del suo talk, Vasco Duarte ci ha parlato di quanto sia pericoloso, per i nostri progetti, mettere continuamente mano alle stime attraverso delle simulazioni.

L’errore aumenta enormemente se si passa dall’analisi di progetti piccoli (10 task ad esempio) a progetti più grandi, magari composti da 100 task. Dai dati raccolti da Vasco, non ci sono casi di un progetto con 100 task consegnato per tempo.

L’errore della stima di progetti cresce più velocemente rispetto alla dimensione del progetto. La velocità con cui la stima perfetta decresce è rapida, già con 30 task è vicina allo zero. Se gli errori fossero lineari vedremmo un andamento diverso, lineare appunto. Invece la decrescita è rapida, forse per le tecniche di stima che applichiamo, o magari a causa di altri fattori (competenze del team, scarsa comunicazione con il cliente ecc.).
Dobbiamo comunque fare attenzione ai cosiddetti outlier, dalla statistica un termine che sta ad indicare un insieme di osservazioni, valori anomali e aberranti.

La storia (anche recente) ci ha portato casi di progetti enormi come quello per l’aereo F-35 o l’aeroporto di Brandeburgo, che con il tempo sono cresciuti ulteriormente in termini di budget. Da ciò deduciamo che i progetti sono fragili per dimensione.

Il Manifesto Agile [1] ci viene in aiuto, anzi ce lo dice dall’inizio: lavorare su un qualcosa di piccolo, semplice, che poi man mano si affina, è meglio. La strada era già tracciata, a partire dal fatto quindi che i progetti dovessero diminuire di dimensione,

Nulla è comunque perduto, possiamo sempre rimediare sfruttando i dati a nostra disposizione, ad esempio dagli item che popolano il backlog, per capire che direzione potrebbe prendere il progetto, individuando la landing zone.

Per ulteriori approfondimenti il libro [2] di Vasco spiega come scrivere un backlog affidabile e organizzare i task del progetto affinché venga concluso e il prodotto consegnato in tempo.

Se invece volete capirne di più sulle simulazioni dei progetti spiegate durante il suo interessante talk, vi invito a dare un’occhiata al progetto del simulatore sulla sua pagina personale su GitHub [3].

Ottimo inizio per IAD 2020!

Making Sense of Change

“Come dare senso al cambiamento Agile?” Con questa domanda Jurgen Appelo ha iniziato il secondo speech di IAD 2020.

La storia recente ci fa pensare all’azienda Tesla, un valido esempio di come si possa avere successo abbracciando e anzi provocando un cambiamento.
In quest’epoca del World Wide Web, le app e la tecnologia in generale portano tutte disruption, cambiamento (pensate alla rapidissima ascesa di TikTok). Dobbiamo farci trovare pronti, come (purtroppo) anche in altri casi come virus il Sars-Cov2.
Sempre più ambiti vedranno applicazioni di intelligenza artificiale, i progetti saranno sempre più complessi… insomma avremo a che fare con un ambiente sempre più complesso e incontrollabile, a complessità crescente, sintetizzabile con un acronimo: V.U.C.A. [4].

Questo acronimo sintetizza quattro concetti:

• Volatility (Volatilità): la velocità, il ritmo del cambiamento e le sue dinamiche in un dato contesto, (come ad esempio il mercato economico). Maggiore è la volatilità, più i cambiamenti sono veloci.
• Uncertainty (Incertezza): indica la misura con cui è possibile prevedere con sicurezza il futuro. Più il mondo è incerto, più è difficile da prevedere.
• Complexity (Complessità): l’apporto del cambiamento. Un contesto è tanto più complesso quanto più i fattori da considerare sono numerosi, diversi tra loro e diverse sono le relazioni tra gli elementi. Più il mondo è complesso, più difficile sarà da analizzare.
• Ambiguity (Ambiguità): una situazione è ambigua quando l’informazione è incompleta, contraddittoria o inaccurata per giungere a delle conclusioni.

La pianificazione tradizionale quindi non funziona più. Che fare?
Bisognerebbe creare una sorta di “consapevolezza condivisa” e comprendere quella di altri.
Kark Weick, nel suo libro “Sensemaking In Organizations” [5] ci dice di spingerci sempre oltre i limiti per esplorare nuovi approcci. A seconda dei ruoli che assumiamo, prendiamo decisioni e diamo risposte diverse. Sensemaking vuol dire dare flusso continuo di consapevolezza e di significato in un mondo che cambia continuamente: quando pensiamo di essere arrivati da qualche parte, ecco che le cose sono già cambiate. Non è possibile pretendere la completezza delle informazioni, dovremo ad un certo punto andare avanti da soli.
Un altro suggerimento riguarda la creazione di “mappe plausibili” di un mondo, da raffinare continuamente: una sorta di manifesto dentro il Manifesto. Capiamo quindi quanto possa essere importante fare Backlog refinement, perché analizzando la situazione attuale prendiamo il meglio per migliorarci nello sprint successivo.

“Come applicare il modello Cynefin [6] al sensemaking?”

• Obvious (il dominio semplice, dell’ovvio): sappiamo bene che cosa fare, il problema e le sue cause-effetto sono chiari.
• Complicated (complicato): convolution, ovvero complicato dal complicato. Cause e effetto noti, ma c’è bisogno di un’analisi. Avremo bisogno di esperti per aiutarci. Ad esempio il commercialista per la gestione delle fatture.
• Complex (complesso): un’analisi del problema non basta, bisogna fare approfondimenti. Occorre però coerenza nel modo in cui agiamo, ad esempio nel team che lavora su un problema.
• Chaotic (caotico): Cause ed effetti del problema sono ignoti, agiamo e poi raccogliamo feedback. C’è una crisi in atto, c’è confusione: non sappiamo cosa sta succedendo.

The Next Next Decade of Agile Software Development

J. B. Rainsberger pratica lo sviluppo Agile dal 2000, per il quale ha dato un enorme contributo globalmente riconosciuto con il conferimento del Gordon Pask Award nel 2005.

Per questo IAD 2020 non vuole proporci un nuovo strumento o fare riflessioni specifiche su qualche argomento bensì, come suggerisce il titolo del suo speech, una serie di considerazioni su ciò che è stato dell’Agilità nelle decadi precedenti e quella attuale, per capire ciò che potremmo aspettarci per il futuro.

J.B. o meglio Joe, quando ha iniziato con l’Agilità voleva delle regole specifiche da applicare per scrivere software. Quelle regole c’erano, bisognava soltanto aiutare la gente a capirle. Chi al tempo era fuori dal dominio Agile, accusava chi invece lo aveva accolto. Lui e il team in cui lavorava venivano presi per folli, intenti nel praticare T.D.D. [7] per intenderci.

Negli anni successivi, 2010-2020, il mondo ha pian piano iniziato ad accettare l’Agilità ed apprezzare i vantaggi che porta. Joe ha insegnato Scrum al mondo, con l’intento di trasmettere la semplicità del framework. Ma attenzione, il suo ruolo di coach, come quello di chiunque altro, è di dare indicazioni, mostrare la via e accompagnarci. Il resto del lavoro dobbiamo farlo da soli, con impegno e dedizione costanti.
In generale le persone hanno iniziato ad adottare Scrum, qualcuno è stato soddisfatto, altri no. Joe voleva seguire altre regole, ad esempio quelle dell’eXtreme Programming [8], ma erano più complesse di quelle di Scrum.

“E oggi?” “Che succede?” “Cosa è andato bene?”
Il programmer testing è andato bene, è più riconosciuto, diffuso e praticato rispetto a 10 anni fa. Nota anche una buona diffusione del continuous deployment e lean startup.
Joe però non vede abbastanza diffusa una pratica che lui, e non solo, considera di grande valore nel mondo Agile: l’Evolutionary Design. In breve, il design evolutivo non è solo un pattern software architetturale, ma influenza il modo in cui organizziamo persone e team, pianifichiamo cosa costruire, collaboriamo, integriamo, sviluppiamo e rilasciamo. Per saperne di più rimandiamo alla lettura dell’articolo [9] di Joshua Kerievsky, tra gli speaker di questa conferenza.

Nell’ultima parte del tempo a sua disposizione Joe ha fatto altre interessanti considerazioni su quello che sta notando nei progetti relativamente a stime, comunicazione, team-management, conduzione del progetto.
Di seguito vi propongo due estratti dalle sue slide

The Heart of Agile

A dimostrazione della grande line-up di speaker di IAD 2020, è arrivato il turno di Alistair Cockburn, agilista della prima ora e tra i co-firmatari del Manifesto Agile.

Alistair non ci ha parlato di Agile, ma di un aggiornamento.

Oggigiorno quando si parla di Agile quasi non serve più mostrare il manifesto. E’ applicato ovunque, non solo nelle aziende. Si declina in tutti gli ambiti, situazioni, persone. Attenzione però, a non associare Agile al significato di “fare il doppio del lavoro in metà del tempo”. E’ assolutamente sbagliato, perché il vero scopo dell’Agilità è di accrescere il valore generato dallo lavoro. Questo è il vero significato.

Riprendendo lo speech di Jurgen Appelo, Agile è diffuso anche perché viviamo in un mondo sempre più dominato dal caos e dall’incertezza (V.U.C.A.), e dobbiamo farci trovare sempre pronti ad abbracciare e reagire al cambiamento.

Come scritto all’inizio, Alistair ci propone un aggiornamento Agile, una sorta di semplificazione di quelli che sono i suoi valori.
The Heart of Agile [10] appunto, con quattro parole cardine: Collaborate, Deliver, Reflect, Improve.
Più si collabora e meglio sarà per tutti. Le aziende dovrebbero investire sulla collaborazione perché porterebbe ad un miglioramento della qualità dei processi e quindi del lavoro. Per migliorare la collaborazione, bisogna migliorare la fiducia. Lavorare sulla cultura, ascoltare le persone, è importante.
E’ importante partire da quello che già c’è, dallo stato dell’arte. Riflettere senza dimenticare quindi ciò che di buono abbiamo.

Dell’interessante talk di Alistair, mi porto a casa una bella citazione. Agile non è un framework, lo sappiamo. Alistair ci invita a pensare al suo cuore come ad una bussola utile per decidere in quale direzione mandare la nostra conversazione.

Agile is An Adjective

Agile è un mindset, vero. E’ un insieme di processi e strumenti che ci aiutano nella gestione dei nostri progetti, vero.

Ma prima del Manifesto, prima di tutto… Agile è un aggettivo.

Ripartiamo da questo con Joshua Kerievsky, CEO di Industrial Logic e agilista di fama internazionale, curatore di uno degli ultimi talk di questa prima giornata di IAD 2020.

Cercare di spiegare il significato della parola agile non è semplice. Se si chiedesse a 100 persone molto probabilmente si otterrebbero 100 risposte diverse.

Per aiutarsi, Joshua ci ha presentato un amico, un lama, Si chiama Logic The Lama, la mascotte di Industrial Logic. Logic è appassionato dello sviluppo di prodotti software che siano di valore per i clienti che li usano. Naturalmente, Logic si interessa al feedback dei clienti, ai test A/B, ai feature toggle e ritiene che il mondo sarebbe un posto migliore se solo potessimo porre fine ad una cattiva UX.
Insomma, miglior aiutante non esiste!

Lama non è d’accordo, tanto quanto Joshua, con la definizione dell’agilità certificata di sprint, stime con storypoint e stand-up meeting. Sono l”Happy Meal” dell’Agile. Ma non è essere Agili!
Oggi esistono tante, troppe pratiche, strumenti… infatti molti associano la parola Agile alle pratiche, ma non è così.

Agile è un aggettivo, è l’abilità di muoversi con velocità e grazia (come un ballerino agile ad esempio).
Si può essere agile in tanti modi diversi, l’agilità non riguarda solo il software. E’ un modo di essere.

Il trucco è come farlo.

Agile non è soltanto una di queste parole: facile, grazia, adattabile, con risorse (resourceful), anzi è la combinazione di queste tre parole, ad esempio grazia-veloce-facile oppure veloce-adattabile-con risorse.

Quando parliamo di Agile dobbiamo dimenticare di pensare che sia sinonimo di veloce. Ripensando al nostro ambito, chi è veloce a scrivere software non vuol dire che sia bravo. La velocità è una parola ingannevole: andare veloci è diverso che andare di fretta.

Per tirare le somme, Agile è semplicemente un aggettivo. Ci vogliono dei principi guida, ad esempio Joshua segue quelli del Modern Agile [11] (oltre quelli del Manifesto).

Conclusioni

Questa prima giornata di IAD 2020 in versione International è stata davvero intensa. Peccato non averla vissuta dal vivo, ma grazie all’ottimo lavoro dei volontari (mai vista una board Miro così ricca di post-it!) e degli sponsor che hanno reso possibile l’evento, l’interazione non è mancata.

Tutti i talk sono stati di elevata qualità, personalmente le attese sono state soddisfatte. Dispiace non aver potuto assistere all’ultimo intervento curato da Woody Zuill, l’inventore del mob programming [12]. Niente paura, lo recupererò guardando il video su Vimeo.

Prima di salutarvi e invitarvi a leggere quanto accaduto nella seconda giornata, volevo fare un ultimo ringraziamento a Chiara Montanari per aver realizzato questa fantastica infografica che riassume splendidamente il primo giorno di IAD 2020.

Riferimenti

1. Manifesto per lo Sviluppo Agile di Software
2. Libro “NoEstimates: How to Measure Project Progress Without Estimating”
3. Project duration simulator | GitHub
4. V.U.C.A. | Complexity Education Project
5. Libro “Sensemaking in Organizations”
6. Modello Cynefin | Agile Way
7. Test Driven Development | Agile Way
8. Extreme Programming | Agile Way
9. Evolutionary Design | Industrial Logic
10. The Heart of Agile
11. Modern Agile
12. Mob programming | Agile Alliance