IAD 2020 – 14 Novembre

Come per il giorno precedente, la conferenza IAD 2020 è iniziata con un’introduzione a cura di Fabio Ghislandi, presidente dell’Italian Agile Movement.

Parola poi a Simon Powers per primo talk della giornata.

Playing with the system

Tutti condividiamo il desiderio di crescere, di apprendere, è qualcosa più grande di noi. Ed è ciò che Simon riscontra nella sua attività di Agile Coach per conto di AdventuresWithAgile, ogni volta che ha a che fare con persone che vogliono rendere il proprio posto di lavoro migliore.

Seguendo gli spunti del libro di Sam Kaner “Facilitator’s Guide to Participatory Decision-Making” [1] Simon ci fa notare che le aziende non possiedono la bacchetta magica, non possono dal nulla migliorarsi bensì devono farlo poco alla volta. E lo si fa instaurando innanzitutto una buona connessione con le persone, soprattutto da parte di figure quali coach o leader.
Scrum, Lean… sono tutti framework validi ma che di per sé non danno contenuti, il coaching è il canale.

Simon ha poi spiegato le fasi di un arco di conversazione senza contenuti, i quali non devono arrivare dal coach ma dal team. Di seguito le fasi.

• Creare innanzitutto un ambiente confortevole, dove ogni persona si possa sentire a suo agio e libera di esprimersi: nessuno punterà il dito su ciò che si vorrà dire.
• Esplorare gli obiettivi, ovvero iniziare a parlare di ciò che si vuole raggiungere. Può essere una trappola, magari può generare alte aspettative.
• Sensemaking: diamo un senso alle idee, lasciamo esprimere le persone, restringiamo il campo per capire ciò che è veramente fattibile.
• Ci impegniamo affinché facciamo quello che ci siamo prefissati.

Nella seconda parte del tempo a sua disposizione Simon ha spiegato il playbook che viene adottato da lui e gli altri coach di AdventuresWithAgile, che ripropongo nell’immagine seguente.

Be Agile Remotely

Molood Ceccarelli è una Agile coach e grande sostenitrice del remote working.

Lavorare da remoto ha tanti vantaggi, ce ne stiamo accorgendo solamente in questo drammatico 2020. Sicuramente ci sono vantaggi economici (non dobbiamo più raggiungere il posto di lavoro, non dobbiamo più mangiare fuori ecc.). I lavoratori sono più motivati (dormiamo di più, abbiamo più tempo libero, lo stress è ridotto ecc.) e ciò va a vantaggio di produttività ed efficienza.

Ma una cosa è fondamentale per Molood: la trasparenza dell’informazione. Deve essere ben definita e bisogna fare tutti uno sforzo organizzativo affinché sia accessibile da chiunque ne abbia bisogno.

Se ci pensiamo, nell’arco di una giornata di lavoro da remoto abbiamo molti momenti di comunicazione: un Daily Scrum, una chat con un collega, un planning, uno Sprint Review, una presentazione.
Vien da sé fare una riflessione su come gestire questi momenti che sono differenti per natura: parliamo di comunicazione sincrona ed asincrona.

“Quale modalità scegliamo per il lavoro da remoto?”
Molood consiglia la comunicazione sincrona per tutti quei momenti di decision making, per risolvere conflitti, per celebrazioni, momenti di socializzazione e ovviamente attività di coaching.
Se dobbiamo condividere delle informazioni, presentare dei dati o una demo, raccogliere opinioni su un particolare tema… sono tutti momenti per il quale non è necessario “digerire” subito l’informazione o avere subito un feedback. Si può fare in un secondo momento, quindi stiamo parlando di comunicazione asincrona.
Per la sua esperienza Molood suggerisce di adottare una comunicazione più asincrona possibile per lo scambio di informazioni.

Altre considerazioni utili per lavorare al meglio da remoto sono:

• Ridurre al minimo il numero di strumenti utilizzati. Dopotutto la semplicità è “l’arte di massimizzare il numero di strumenti non utilizzati”.
• Semplificazione dei processi.
• Creare accordi espliciti.
• Non replicare in casa l’ambiente e le dinamiche dell’ufficio.

Per chi volesse approfondire, Molood vi aspetta all’evento (ovviamente da remoto) Remote Forever Summit [2].

Per questo IAD 2020 un talk su questo tema non poteva mancare. Grazie Molood per i consigli che ci hai regalato.

The Zombie Scrum Survival Guide

Quando compaiono gli zombie si sa, l’unica cosa che possiamo fare è sopravvivere.

Partendo dalle esperienze sul campo come Scrum coach e Agile coach, Barry Overeem e Johannes Schartau hanno presentato il loro libro “The Zombie Scrum Survival Guide” [3] in uscita il 23 Novembre.

Per combattere gli zombie è innanzitutto opportuno conoscerli, capire quali possano essere i sintomi. Ad esempio vedere gli sviluppatori sempre con indosso le cuffie, come per dire “lasciatemi lavorare, non disturbatemi, non parlatemi”. Oppure notare una scarsa partecipazione di alcuni membri del team a cerimonie quali Stand-up meeting o retrospettive sullo sprint appena concluso. Sono tutti atteggiamenti che potrebbero far pensare che quelle persone non gradiscono Scrum, oppure non credono nel framework e nel valore che apporta.

Riprendiamo per un attimo la definizione di Scrum [4]:

Scrum è un framework di processo utilizzato dai primi anni novanta per gestire lo sviluppo di prodotti complessi. Non è un processo o una tecnica per costruire prodotti ma piuttosto è un framework all’interno del quale è possibile utilizzare vari processi e tecniche. Scrum rende chiara l’efficacia relativa del proprio product management e delle proprie pratiche di sviluppo così da poterle migliorare.

Facendo attenzione alla definizione, si parla di Scrum come strumento usato per gestire problemi complessi. Complesso, non complicato. Sono due termini diversi, soprattutto in ambito di gestione di progetti, come ben spiega il modello Cynefin [7].

Scrum è un ottimo strumento, ma occorre organizzazione.

Ciò che causa lo Zombie Scrum è la mancanza di efficienza, e si dovrebbe il più possibile evitare di lavorare a compartimenti stagni. Bisogna inoltre comprendere bene il framework, capire cosa vuol dire Scrum, non bisogna adottarlo solo perché ce lo dice qualcuno o perché “Lo fanno tutti, e perché non noi?”. Utilizzare uno strumento senza conoscerlo bene può fare solo che danni. E non basta nemmeno prendere certificazioni per dire “Ok, sono pronto per fare Scrum”, oppure adottare soluzioni semplici e veloci, ad esempio fare nostre alcune best practice della community.

Per avere successo con Scrum e Agile è importante innanzitutto di capire bene ciò che vogliono gli stakeholder. Bilanciarsi su ciò che sono i loro bisogni e l’organizzazione. Capire bene chi è il cliente, deve essere chiaro a tutti.

Creare trasparenza: la Customer Distance Metric, come la chiamano Barry e Johannes. Come misurare la distanza tra team e stakeholder? Ad esempio lavorando sul backlog, prendendo un item e analizzandolo procedendo a ritroso per risalire alla fonte, al bisogno che lo ha generato. Ciò aiuterebbe a capire se ha davvero senso mantenere una certa distanza dal cliente.

Ship it fast: è più lo sconosciuto che il conosciuto, vale nella vita come per un progetto software. Rilasciando più rapidamente avremo modo di ottenere feedback più frequenti che valideranno o meno le nostre assunzioni e quindi potremo apporre le giuste correzioni.
E in tutto ciò, il team apprende e si migliora continuamente.

Ultimo ma non per importanza, viene suggerito l’approccio Double-loop learning [5] che viene utilizzato quando è necessario modificare il modello mentale da cui dipende una decisione. A differenza dei Single-loop, questo modello include un cambiamento nella comprensione, da “semplice e statica” a “più ampia e dinamica”.

Grazie Barry e Johannes per aver portato a IAD 2020 i vostri consigli su come sconfiggere gli zombie Scrum.

Three Powerful Tools

Siamo arrivati all’ultimo talk di questi IAD 2020. Chiusura con il botto dato che a curare l’intervento è stato Andy Hunt, un altro dei co-firmatari dell’Agile Manifesto [6], il quale ci ha parlato di tre strumenti utili.

Diamo però un minimo di contesto.

Oggi tutto può diventare Agile in un’organizzazione, dalla contabilità al reparto HR (Risorse Umane)… ma non è la cosa giusta da fare. Non esiste infatti uno strumento giusto, la cosa giusta… bisogna sempre considerare anche il contesto: persone, organizzazione, tecnologia, tempistica.
Riprendendo ancora una volta il modello Cynefin [7]: quotidianamente, in ambito Agile, si fa consulenza a ciò che è chiaro e ovvio (dominio del Semplice), ma spesso abbiamo a che fare con qualcosa che è complesso (dominio del Complesso).

Parlando di sviluppo software, la chiave è scriverlo. Ma non è semplice. Ed eccoci arrivare ai tre strumenti suggeriti da Andy:

• Feedback
• Simplicity
• Learning

Molti nostri sforzi spesso si concentrano per capire come rilasciare, deliverare software rapidamente, ma non è l’obiettivo primario. E’ bene ricordare inoltre che la velocità deve viaggiare in parallelo con la qualità, per quello serve avere feedback. E lo si ottiene facendo test.
Con l’espressione “experiment to get feedback” si può sintetizzare il tutto: faccio l’ esperimento, ottengo i feedback, apporto piccoli aggiustamenti, identifico i feedback. Se i feedback sono negativi o si trovano errori nessun dramma, dagli errori si cresce ci ricorda Andy. A patto che gli errori siano piccoli e correggibili. Il processo che ci permette di avere in caso errori piccoli e gestibili è la programmazione pragmatica, di cui Andy è grande esponente. Se non lo avete ancora fatto, leggete il suo libro [8], considerato da molti un must-to-read per qualunque programmatore.

L’abbiamo sentita spesso durante questi IAD 2020, la semplicità è l’arte di massimizzare la quantità del lavoro non ancora svolto. Potrebbe essere considerata come uno strumento, ma non è semplice ottenerlo. Richiede molto lavoro, competenza ed esperienza.
Riprendendo la legge di Brook:

Aggiungere forza lavoro ad un progetto software in ritardo, lo farà ritardare ancora di più.

Ma aumentare la forza lavoro aumenta anche la complessità del team in termini di dimensioni, competenze. La complessità mina la comprensione in generale.
Diikstra giusto qualche annetto fa assunse che si deve tenere tutto il meno intricato possibile, e tale assunzione oggi più che mai è valida.

E’ importante quindi per uno sviluppatore (dopotutto Andy lo è) gestire la complessità, e oggi come oggi ha tutti gli strumenti necessari per lavorare in maniera il più possibile semplice.

Conclusioni

Che dire di questa seconda giornata di IAD 2020? Un altro bel filotto di talk interessanti e ispirazionali, tra cui una bellissima intervista a Jutta Eckstein che ha cercato di guardare oltre l’orizzonte Agile per mostrare un percorso verso l’agilità a livello aziendale. A proposito, date un’occhiata al suo approccio BOSSA Nova [9].

Nonostante sia stata la prima volta da remoto di questa due giorni dedicata all’Agilità, posso dire di essere stato davvero bene. Ottima gestione dei tempi e degli spazi virtuali, conduzione simpatica ed efficace da parte dei moderatori, insomma… tutto perfetto.

A proposito di spazi virtuali, vi lascio con un’immagine della board Miro al termine dell’ultimo talk. Non credo servano altre parole, l’immagine è parlante già di suo:

Riferimenti

1. Libro “Facilitator’s Guide to Participatory Decision-Making” | Amazon
2. Remove Forever Summit
3. The Zombie Scrum Survival Guide | Scrum.org
4. The 2020 Scrum Guide
5. Double-loop learning | Wikipedia
6. Manifesto per lo sviluppo Agile di software
7. Modello Cynefin | Agile Way
8. Pragmatic Programmer, The: From Journeyman to Master | Amazon
9. BOSSA Nova