In Principio era Scrum

La verità è che la storia che vi racconto, ho scoperto essere quella di tanti altri;

In principio era Scrum… l’Agile venne molto dopo è una mezza citazione dall’eccezionale libro di Covatta “Parola di Giobbe”, che per esteso recita:

“In principio era il Verbo… il complemento oggetto venne molto dopo.” “Dio prese del fango, ci sputò su e nacque Adamo. E Adamo, asciugandosi il viso, disse: ‘Cominciamo bene!”

Citazione decisamente inusuale, ma vedo parecchie analogie.

Tornando a noi, questa cosa dell’Agile era difficile da capire, Perché?

Beh, Agile non è una cosa, non un elenco di cose da fare, una ricetta, un qualcosa che si possa installare ed eseguire, quindi significa che è una cosa impalpabile e tecnicamente, non esiste. La cosa che esiste, invece, è lo strumento, Jira, ed è da lì che ho iniziato a modellare la mia consapevolezza di cosa fosse Scrum, o Agile? Era più o meno la stessa cosa.

Si inizia a studiare la guida aurea quindi, testa bassa su quelle 12 pagine e cerchiamo di capire di cosa si tratta; quindi via con mappe mentali, appunti, acronimi, sigle, INVEST, SMART, 3C e tutto il resto: Abbiamo studiato abbastanza, siamo pronti per partire, si ma quanto tempo ci vuole per finire una storia? Qualcuno dice che story point = giornate di lavoro, ma sì certo, ovvio!? Iniziamo a fare stime temporali, mappiamo tutto, inseriamo nelle storie il CDA, la DOR, la DOD, la stima in SP e che siano scritte dal punto di vista dell’utente con stima Fibonacci. Facciamo incontro per stimare tutto il Backlog?

Beh, niente male, si parte e il 90% del beneficio di Scrum lo si ottiene semplicemente incontrandosi tutte le mattine e avendo un team dedicato. Le cose iniziano a girare, ma in questo Sprint non abbiamo abbastanza tempo: lo allunghiamo che è meglio; Sta andando tutto bene, a che serve la Retrospettiva? Ma si saltiamola a questo giro, casomai la facciamo nel prossimo sprint così prendiamo 2 piccioni con una fava.

Passa qualche mese e la sensazione di stare facendo dei mini-waterfall inizia a diventare realtà, qualcosa non torna, sembra quasi di aver cambiato tutto per non cambiare niente (cit.)

Dall’Olimpo, 2 coach vengono calati nella nostra piccola realtà di periferia, di cantinari dell’Agile, ed ecco che si scopre che dietro a quel continuo affannarsi nel cercare di rispettare delle regole, arriva la cosa più importante che fino a quel momento era passata in sordina, forse eclissata dall’enfasi di fare qualcosa di nuovo e rivoluzionario:

Il Perché.

Il perché, come dice il buon Sinek, è l’unica cosa che ti farà trovare pace e darà un senso a tutto il resto; Cynefin, Complessità, TPS, Fibonacci, Ammiragli, Staffette, il Signore degli Anelli e tantissime altri #tag, mi hanno dato la consapevolezza che mi serviva per capire che in effetti, lo strumento o il framework ti fanno ragionare al contrario, la cosa veramente importante è quanto sei capace di cambiare punto di vista e quanto sei capace di surfare sulle onde dell’entusiasmo e della passione.

Una volta che ti sei messo d’accordo con te stesso, ti rendi conto di tante cose che hai sempre pensato, ma che non hanno mai trovato un riscontro concreto nella tua vita lavorativa.

Quello che si legge nell’Agile Manifesto, inclusi i principi, sono delle semplici regole di buon senso; il buon senso!

Mi pare ovvio che un team che abbia focus su una cosa per volta sia più efficace; così come che se massimizzi il lavoro non svolto, allora sei più efficace.

Il colmo è sulla conversazione faccia a faccia: chi direbbe che sia meglio mandare una mail piuttosto che parlare “a voce”?

Beh allora che è tutta questa potenza dell’Agile?

Sono convinto che sia proprio questa, l’Agile ti sbatte in faccia quanto tu stia cercando di risolvere cose giuste nel modo sbagliato, perché hai sempre fatto così, abbiamo sempre fatto così e hanno sempre fatto così.

Aver etichettato come “Agile” il buon senso ci ha dato modo di renderlo vero, di poterne parlare e poterlo addirittura vendere alle organizzazioni;

La mia storia è simile a quella dell’umanità dal 1900 ad oggi (sempre esagerato):

ho iniziato come tecnico PC, all’alba dei primi floppy da 1,44″, e sono sempre stato abituato a cose fatte di altre cose, che a loro volta erano fatte di cose. Quindi mettendo insieme cose, se ne ottenevano altre… si parla quindi di cose, fisiche, che vedi e monti. Da lì poi sono passato dopo qualche anno allo sviluppo software; parliamo degli anni di nascita di Scrum, di Doom e della programmazione ad Oggetti.

Beh la vita dello sviluppatore è un inferno, ma non per lo sviluppo in se, quanto per il cliente. Un inferno puro, fatto di specifiche iperminuziose, bugs, change request, debito tecnico, refactoring, pipeline e Milestone…una quantità incredibile, di tempo sprecato. Inoltre non si trattava più di “Cose” che potevo smontare, ma di Software, qualcosa che non esisteva ma che risolveva ugualmente problemi a centinaia di persone contemporaneamente: bastava un “Run” e tutti ricevono il fix….ansia.

Guarito dalla parentesi “Sviluppatore” e dopo aver ripreso uno pseudo normale ritmo del sonno, ormai conscio che non tutto fosse semplificabile e con in tasca una bella lezione su cosa sia complicato e cosa sia complesso, mi sono dedicato ai sistemi IT, probabilmente nel vano tentativo di sfuggire alla complessità, in fondo si trattava di cose… (e invece no!). Da lì la mia carriera è proseguita verso il IT Management, per poi finire a fare il Coach Agile.

Perché sono finito a fare il Coach? Avete presente quella sensazione di quando scoprite un qualcosa di nuovo che risponde a quel prurito insistente e ricorrente che si manifesta come un’allergia, quando vi viene chiesta una data di consegna? Ecco, la cura è talmente efficace, che salvare il prossimo è diventata la mia missione.

Ho perso davvero troppo tempo nel fare quei Gannt che per quanto belli graficamente, colorati, pieni di lineette, nomi e percentuali, già l’indomani sarebbero diventati carta straccia, e pensare che anche io come tutti, aggiungevo il fantomatico “cuscinetto” del xx% a seconda del rischio, ma vi sembra una roba sensata?

Per me l’Agile è stata una risposta; attraverso la consapevolezza e lo studio del geniale Cynefin, mi si sono aperte le porte di un mondo frattale, intricato e pieno di spunti interessanti che oggi mettiamo sotto il nome di Agile, ma che semplicemente, è l’unico modo di fare.

Nella mia personale Agile “Adoption”, ho fatto tanti errori tecnici e quasi tutti questi errori tecnici sarebbero stati evitati se fossi stato in grado di rispondere alla semplice domanda: “Ma questa cosa che sto facendo, è Agile?” Beh, non è stato così semplice rispondere e spesso non lo è nemmeno adesso, a più di 10 anni di distanza dalla mia “prima volta“. Di sicuro, se potessi tornare indietro, partirei from Why, e poi successivamente ragionerei sul Cosa e sul Come; la mia strada è stata esattamente l’opposto ma mi ha permesso di capire le cose fino in fondo… sanguinando copiosamente e rischiando l’esaurimento, certo, ma comunque in maniera esperienziale che qualcuno dice sia l’unico modo per imparare davvero qualcosa.

Vi do qualche consiglio che secondo me può salvarvi la vita, poi vedete voi:

Prima di tutto fate formazione, studiate, entrate in community, condividete, parlate con coach, lanciatevi e contaminate con la vostra enfasi.

Se sei il capo, fai prima. Se hai il “potere” di organizzare la tua BU come meglio credi, fallo. Essendo il capo sarà tutto incredibilmente più facile; Agile funziona, non è che bisogna dimostrarlo, se non funziona dipende da te o dalla tua organizzazione. Questa è una certezza senza se e senza ma.

L’adozione Agile a panino resta il sistema migliore, il top management deve spingere dall’altro, i team spingono naturalmente dal basso (non sono stupidi) e il middle management dei latifondisti, tende a non voler mollare un metro del proprio orto; A furia di spingere dal basso e dall’alto, a costo di un po’ di ketchup riversato, si riuscirà a cambiare le cose.

È meglio chiedere “scusa” che “per favore”. Chiedere di poter fare qualcosa, spesso ti fa perdere più tempo del fare quella stessa cosa e provare se funziona. Parti, se qualcuno verrà a dirti che quella cosa è fuori procedura, scusati e mostra i risultati che hai ottenuto nonostante non fosse in procedura, anche se non ce ne sono stati, inventati qualcosa tipo che: bisogna provare per capire se le cose funzionano.

Non aver paura di non servire più, un buon leader fa in modo di far funzionare tutto anche se lui non c’è, altrimenti torniamo di nuovo al 1908 e riprendiamo a costruirci i nostri “orticelli” per renderci indispensabili.

Se sarai bravo nel non servire più e quindi a delegare e soprattutto a rinunciare al “potere” che ti è stato conferito, potrai dedicarti a cose di valore sia per te che per l’organizzazione.

Non partire da una metodologia o framework specifico, come dice Alistair, la metodologia si adatta al prodotto, non viceversa. Comincia inserendo piccole cose nel quotidiano e vedi se al team servono oppure no.

Metti in conto che ci vuole tempo, non è una cosa veloce, come dicevo, se sei il capo e ci credi fai prima, ma comunque un cambio di prospettiva è qualcosa di davvero difficile da metabolizzare.

Sta attento a come crei i team, per essere agili ci vuole una certa predisposizione al “nel domani non v’è certezza” (cit.), non tutti ci riescono; e presta particolare attenzione alle soft skills, le hard skills sono prerogativa delle macchine e siamo bravi a misurarle e valutarle… ma le softskill?

Ti sentirai solo, additato come figlio dei fiori perché gli agilisti sono quelli “senza date”, tieni duro, non mollare, pensa positivo e se hai bisogno di una spalla, scrivimi che ti faccio forza.

Comunque lo rifarei, la prima volta si è sempre un po’ impacciati (…) ma già la seconda prima volta va molto meglio e oggi, dopo una decina di anni e qualche decina di prime volte, sto continuando a scoprire modi nuovi di creare valore. Sviluppandolo e aiutando gli altri a fare lo stesso. (cit.)

Grazie per il tuo tempo!

trovate questo articolo anche su Agile Italia di Gennaio 2024!