Simplicity Agile Coaching
Il principio che doveva essere più enfatizzato
Sto scrivendo questo breve post con un computer portatile che pesa meno di un tablet ed ha una sola porta con la quale si fa tutto, dall’alimentazione alla connettività. Certo a molti la cosa non è piaciuta, ma è sempre stato così quando si sono semplificate delle cose. Di tutte le idee che sono scaturite da Apple dopo la sua morte sono certo che questa sarebbe stata fra le preferite da Steve Jobs in quanto fra le più Zen — pratica, prima che religione, da lui perseguita quasi da sempre. In fondo il Rasoio di Occam, la legge per cui la soluzione più giusta è la più semplice, ovvero quella che prevede meno passaggi, è la versione occidentale dello stesso metodo e il primo iMac è stato proprio questo. In un periodo in cui i computer erano delle “torri” per consentire un numero maggiore possibile di porte e periferiche una diversa dall’altra, lettori ottici, masterizzatori ottici, drive per floppy da 3,5 e 5,25, Iomega Zip, eccetera, eccetera, e proprio in ragione delle “cose in più” che venivano ospitate o almeno erano rese disponibili che veniva “pesato” un prodotto, egli produsse un computer di tanti colori ma un solo modello e un solo tipo di espansione possibile, quella che passava per la porta USB (allora agli esordi). Tante tecnologie venivano spazzate in un colpo solo e i più pensavano che ad essere spazzato via sarebbe stato l’iMac. Ovviamente avvenne il contrario e le periferiche su porte parallele, seriali, SCSI e così via finirono per contribuire all’inquinamento elettronico, assieme ai dati che non si era riusciti a salvare per tempo. Una cosa analoga fece Bill Gates quando dimostrò, a dispetto degli analisti che giudicarono la cosa uno harakiri, che il principio più leggero, il software, avrebbe dettato la legge su quello più pesante, l’hardware, rappresentato da Big Blue IBM. Meno famoso ma ancor più influente fu il momento in cui, con la versione Snow Leopard di Mac OS X, sempre Steve Jobs fece lavorare tutto il suo personale per rinnovare il sistema operativo con una versione (allora ancora a pagamento) che non offriva nulla di visibilmente nuovo, ma che veniva proposto come l’update più importante in quanto era stato alleggerito di un’infinità di codice inutile operando intensamente per alleggerire il maggior numero di processi possibili. Si era rispettivamente nel 1998, 1990 e 2009. Al centro di questo ventennio venne scritto quello che passò alla storia come il Manifesto Agile dello sviluppo del software che oggi viene adottato per consentire alle organizzazioni di far fronte alla disruption dei mercati tradizionali, la perdita dei riferimenti tradizionali e la debacle di gran parte della pianificazione industriale (una situazione tutt’altro che inedita nella storia ma della quale sembrava avessimo perso memoria).
Come ho avuto a scrivere giusto qualche giorno fa, con le miriadi di modellizzazioni successive, la burocrazia che doveva uscire dalla porta con Agile è rientrata dalla finestra di SCRUM e i suoi fratelli portando con sé infiniti ruoli, pratiche e procedure che fanno perdere di vista creatività, autonomia e focalizzazione.
Che cosa caratterizza momenti come i tre sopra espressi? Se ci pensate bene è il fatto che la fase della domanda — o delle domande— ha avuto un budget superiore a quella delle soluzioni. E la forte focalizzazione su un solo fattore che producesse un effetto domino sul sistema.
Questo dovrebbe essere il focus su cui il vero ruolo critico del team agile (che può essere rivestito anche da un altro membro invece che una persona specializzata in questo), ovvero il Coach Agile, tiene concentrata l’attenzione dello squad in azione. In molti mi hanno chiesto che cosa volesse dire la regola del manifesto che a proposito di semplicità recita “massimizzare la quantità di lavoro non svolto”. La cosa è molto semplice anche se paradossale per il modo di pensare degli uffici dove chi più fa è più produttivo. Se tu occupi una quota significativa della tua attività a buttar via quello che non è essenziale, riduci i costi, migliori la qualità e lavori meglio: in una parola “semplifichi”.
Ho confrontato le leggi del Manifesto con quelle della Semplicità espresse da Maeda e, seppure nella loro diversità, sembrano fatte apposta per essere integrate e dovrebbero essere la bussola di ogni Coach e Team Leader.
In particolare la legge definita “Unica”, ovvero quella che recita “Semplicità significa sottrarre l’ovvio e aggiungere il significativo” e soprattutto se la abbiniamo a due metodi: quello di prendere le distanze il più possibile dalla mole di stereotipi operativi e normativi tradizionali e quello di aver fiducia nel fatto che si otterrà di più usando meno in una cultura di apertura.
Sei un Coach Agile? Prova a dimenticare tutta quella pletora di criteri pensanti e farraginosi e tieniti leggero solo con quest’ultimo paragrafo, prova a scoprire cosa succede e poi parliamone!
I principi sottostanti al Manifesto Agile
Seguiamo questi principi:
1. La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua.2. Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo. I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente.
3. Consegnamo frequentemente software funzionante, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi brevi.
4. Committenti e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto.
5. Fondiamo i progetti su individui motivati. Diamo loro l’ambiente e il supporto di cui hanno bisogno e confidiamo nella loro capacità di portare il lavoro a termine.
6. Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team ed all’interno del team.
7. Il software funzionante è il principale metro di misura di progresso.
8. I processi agili promuovono uno sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante.
9. La continua attenzione all’eccellenza tecnica e alla buona progettazione esaltano l’agilità.
10. La semplicità — l’arte di massimizzare la quantità di lavoro non svolto — è essenziale.
11. Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano.
12. A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.
(Manifesto per lo sviluppo agile del software — 2001)
1. RIDUCI Il modo più semplice per conseguire la semplicità è attraverso una riduzione ragionata
2. ORGANIZZA L’organizzazione fa sì che un sistema composto da molti elementi appaia costituito da pochi
3. TEMPO I risparmi di tempo somigliano alla semplicità.
4. IMPARA La conoscenza rende tutto più semplice.
5. DIFFERENZE La semplicità e la complessità sono necessarie l’una all’altra.
6. CONTESTO Ciò che sta alla periferia della semplicità non è assolutamente periferico.
7. EMOZIONE Meglio emozioni in più piuttosto che in meno.
8. FIDUCIA Noi crediamo nella semplicità.
9. FALLIMENTO Ci sono cose che non è possibile semplificare.
10. L’UNICA Semplicità significa sottrarre l’ovvio e aggiungere il significativo.
TRE CHIAVI
I. LONTANO Più sembra meno: basta semplicemente spostarlo lontano, molto lontano.
II. APERTO L’apertura semplifica la complessità.
III. ENERGIA Usa di meno, ottieni di più.
(John Maeda, Le leggi della semplicità — 2006)
