Il mindset Agile si basa molto sulla collaborazione: collaborazione fra cliente e fornitore, fra Leader e Operators, fra membri dello stesso team.

Nel 1999 Kent Beck pubblicò il suo famoso libro “Extreme Programming Explained” nel quale parlava (e si parla tutt’oggi) di tecniche di sviluppo e organizzazione di persone per generare software di qualità superiore in modo più produttivo.

Due di queste tecniche sono il pair programming e la scrittura di test (sia automatici sia di accettazione) prima della scrittura del codice (test first).

Con l’ottima facilitazione di Stefano Marello abbiamo provato ad “unire ed estremizzare” questi due principi in una sessione di Mob o Ensemble Programming.

In cosa consiste? Quali sono le regole e i ruoli?

“Ensemble Programming” significa qualcosa del tipo “Programmazione d’insieme” e la tecnica consiste nel far lavorare un intero team sulla stessa cosa, nello stesso tempo, nello stesso posto, sullo stesso computer (da cui anche “Software Teaming”).

Sono previsti due ruoli:

• Un Navigator che colloquia con l’intero team per trovare la migliore soluzione possibile al problema.
• Un Driver che è colui/colei che è fisicamente alla tastiera e traduce le richieste del Navigator in codice implementando TDD (Test-Driven-Development).

Durante la sessione i volontari che hanno partecipato attivamente, a turno hanno assunto entrambi i ruoli, e ogni 10 minuti (tempo arbitrariamente deciso) la persona che faceva da Navigator diventava Driver, mentre il Driver tornava ad essere un membro del team.

Sembra uno spreco di tempo avere un intero team concentrato su un unico problema? In realtà l’obiettivo pratico delle sessioni di ensemble programming è concludere il task descritto nella storia fornita dal Product Owner riducendo il tempo di rilascio e realizzando codice molto più robusto.

Ma entriamo nel dettaglio della serata.

Una quindicina di esperti e non si sono alternati nello sviluppo del Kata proposto da Stefano: è stato un… Kata-Christmas! Non è propriamente in tema carnascialesco ma è stato molto efficace.

Lo scopo era scrivere un software che seguisse le istruzioni di Babbo Natale per governare una griglia di 100×100 luci e creasse la sequenza di combinazioni vincente per aggiudicarsi la gara di giochi di luci più belli.

Stefano ha lasciato parola e tastiera agli ospiti che si sono cimentati in discussioni tecniche e filosofiche, come capita fra i migliori programmatori, per poi generare del codice seguendo le regole del TDD.

Fra una classe ed un metodo, fra uno unit test ed un commit siamo riusciti ad accendere qualche lampadina in tutti i sensi, sia quelle di Babbo Natale sia nelle nostre teste.

La parte più interessante dell’esperimento è stato vedere come l’intelligenza collettiva sfruttata tramite l’espressione di idee e di opinioni di gruppo senza alcun tipo di ostacolo o paura abbia generato un sano confronto che effettivamente si è tradotto in una soluzione da implementare.

Vi lascio con alcune delle domande che ci siamo posti pensando ai nostri ambienti di lavoro:

1. Quanto è applicabile nei nostri contesti lavorativi?
2. La pratica è davvero percepita come un modo per trovare la miglior soluzione facendo contemporaneamente un check sulla qualità del codice? Oppure è vista come qualcosa che blocca un intero team su un unico problema quando potremmo lavorare in parallelo su diversi task?
3. Come possiamo misurare l’impatto che possiamo avere in termini di:
   1. minor numero di bug
   2. facilità di refactoring
   3. riduzione del tempo di implementazione
   4. condivisione di conoscenze

Probabilmente le risposte sono demandate ai Manager e alla loro capacità di comprensione e di lungimiranza.

Io da parte mia mi sono divertito e ho trovato l’argomento molto interessante.

Ma soprattutto si saranno divertiti coloro i quali hanno continuato a chiacchierare al di fuori del meeting davanti ad un buon cocktail.

Se sei interessato al dojo dai un’occhiata alle slide proiettate durante la serata e non esitare a contattarci!

Coding_Dojo_Intro.pdf

Alla prossima!

Nicola

More Posts

Follow Me:

L'articolo Coding Dojo: sperimentiamo il Mob Programming proviene da Agile Community Torino.

Ecco come è iniziata la giornata dello scorso 30 settembre per i volontari e per tutti coloro che si sono svegliati presto per essere presenti al TAC23.

Alle 07:30 in venti eravamo pronti sul posto e già operativi per spostare i tavoli degli sponsor e del coffee break, appendere i cartelli per le indicazioni e preparare il check-in iniziato alle 08:15 in punto: si è aperta così una giornata molto speciale.

Pian piano i primi ospiti hanno cominciato a popolare il cortile antistante la sede, poi è stato il turno della pasticceria (adesso si comincia a ragionare ) con vassoi di dolci, pizze e bevande in quantità.

Il tema per questa edizione “Agile everywhere? Innovazione ad alta efficacia” è stato scelto pensando alle mille sfaccettature dell’agilità e a come è stato applicato in svariati contesti, anche quelli che esulano dal software. Siamo stati molto soddisfatti delle proposte di intervento pervenute (il programma completo è ancora disponibile sul sito).

Andrea Provaglio, amico della Community, ci ha fatto l’onore di essere il nostro Keynoter e ci ha parlato di come Lean e Agile possono essere proficuamente applicati nella produzione industriale.

L’affluenza è continuata durante tutta la giornata, arrivando a più di 170 partecipanti (su 260 richieste) che hanno sfruttato i lunghi coffee break per salutare vecchi amici, conoscerne di nuovi ed avvicinarsi ai banchetti dei nostri sponsor per chiedere informazioni o lasciare il proprio curriculum.

Rifocillati per bene ognuno si è diretto verso il talk di proprio interesse o il workshop al quale si era iscritto.

La mattinata è stata ricca di temi molto variegati: si è parlato di prodotti aerospaziali, di Agile nella didattica, e di come se ne possa applicare il mindset anche per HR. Non è mancato un intervento sulla diatriba fra efficacia ed efficienza e su un tema attualmente molto caldo: Agility and Generative AI: amici o nemici? Si possono affiancare per ottenere risultati migliori? Se non lo avete scoperto nel talk potete sempre guardare i video girati da due ragazzi bravissimi, che ci hanno accompagnato per tutta la giornata.

E poi tutti a pranzo!! (non so chi ha avuto il coraggio di andare fuori a mangiare dopo un così ricco coffee break, però…).

Quali tematiche, invece, sono state affrontate nel pomeriggio? Beh, siamo passati dall’aerospazio alla produzione di autovetture e a come sta cambiando lo scenario anche in questi contesti.

E non ce la mettiamo una spruzzatina di Kanban? O esiste solo Scrum? Assolutamente no! Un doppio appuntamento per non farci mancare proprio nulla.

Ci siamo avviati verso la conclusione di questa giornata parlando di agilità nelle scuole, di OKR e di come Agile possa essere un valido aiuto anche in contesti normativi.

I quattro workshop hanno fatto da splendida cornice con giochi molto coinvolgenti.

Per i saluti finali ci siamo raccolti nella sala del keynote con la raccolta di feedback, foto conclusive, saluti e ringraziamenti ai nostri magnifici sponsor, senza i quali l’evento non avrebbe avuto luogo, agli speaker, che hanno saputo trasmettere valore coi loro interventi, ai volontari, che ci hanno dato un grosso aiuto per la gestione step-by-step, al pubblico che è intervenuto, al Centro di Biotecnologie Molecolari che ci ha ospitato ed infine agli organizzatori che indefessamente hanno lavorato e ancora continuano a farlo per rendere questa giornata una giornata molto speciale.

Se non c’è due senza tre…Chissà.

Numeri, feedback e statistiche sono disponibili leggendo il report dell’evento.

CIAOOOOO!!!!!!

Nicola

More Posts

Follow Me:

L'articolo Una giornata molto speciale proviene da Agile Community Torino.

Quello che però succede spesso è che quando mi avvicino ai banchi di frutta e verdura e noto che la qualità della merce non è in linea con le mie aspettative mi ritrovo a pensare: “Se fossi andato al mercato di quartiere avrei avuto molte bancarelle con la stessa merce, a prezzi diversi e di qualità diversa. Qui, invece, ho solo due scelte: accettare quello che mi viene offerto o rinunciare all’acquisto”.

Questo è quello che succede quando ci si siede ad un tavolo di negoziazione e non si hanno alternative all’accordo proposto.

“Adesso BATNA!” è anche il titolo di uno dei capitoli del libro “Extreme Contracts” scritto da Jacopo Romei, il nostro amico e relatore del talk che ci ha coinvolti nel meetup da lui organizzato nelle sale del Talent Garden di Torino.

BATNA è un acronimo e significa “Best Alternative To a Negotiated Agreement” (migliore alternativa ad un accordo negoziato).

Il concetto alla base è semplice: nel momento in cui ci sediamo ad un tavolo negoziale ognuno di noi ha un bouquet di scelte, bouquet che può essere più o meno limitato ma ce l’ha, fosse soltanto il fatto di scegliere se rimanere o abbandonare la trattativa.

Come al supermercato se non abbiamo alternative all’accordo proposto dalla controparte non abbiamo possibilità di negoziare: accettiamo oppure rifiutiamo.

Se, però, abbiamo diverse scelte su cui puntare ecco che siamo più forti, possiamo mettere in campo le nostre ragioni e iniziare una negoziazione.

Il suggerimento di Jacopo, dunque, è quello di non fermarsi, di crearsi una propria BATNA e possibilmente di rinnovarla e rafforzarla, perché nel momento in cui iniziamo una contrattazione non sappiamo quanto forte è la nostra BATNA e quanto lo sia quella della controparte.

Diventa, allora, fondamentale anche tener conto di aspetti che possono sembrare esterni al contesto, perché l’innesto di un terzo attore, fino a quel momento ignorato, potrebbe cambiare le nostre prospettive ed ampliare all’improvviso le scelte a disposizione.

Jacopo ci ha spiegato con esempi di vita vissuta quanto è importante poter scegliere, avere “potere contrattuale”, ed è stato tutto molto chiaro e semplice (Specification by Example).

Nel sul libro Jacopo pone tre domande alle quali bisognerebbe dare risposta per essere pronti a poter prendere una decisione:

1. Quali sono le mie priorità? Non mi sarà chiaro come procurarmi ciò che mi serve se non mi sarà chiaro cosa io desideri
2. Qual è la mia BATNA? Non confondere questa domanda con quella simile “Ho una BATNA?” Tutti abbiamo una BATNA ma conoscerla ci dice quanto è potente e qual è il nostro potere contrattuale
3. Qual è la loro BATNA? Chiunque sia seduto dall’altro lato del tavolo avrà una sua BATNA; buona, cattiva, chiara o confusa non importa: per noi sarà importante estrarre e ottenere ogni possibile informazione per preparare la nostra negoziazione al meglio.

A questo punto è chiaro che avere una BATNA ricca e variegata è fondamentale.

Ma come si fa ad ottenerla?

La risposta al prossimo meetup di Jacopo Romei del 28 giugno 2023 o leggendo il suo libro.

Ciao ciao. E buona BATNA a tutti.

Nicola

More Posts

Follow Me:

L'articolo Adesso BATNA!! Risk Management per il Knowledge Worker proviene da Agile Community Torino.

Noi dell’ACT abbiamo fatto un esperimento simulando uno Scrum Sprint Planning.

Ci siamo inventati un’esigenza che in questo momento storico può essere reale: la creazione di una piattaforma di prenotazione on-line dei prodotti da asporto su un sito già esistente di un ristorante per dare la possibilità all’utente finale di prenotare il pranzo o la cena.

L’idea iniziale è stata quella di:

• poter caricare sul sito in maniera dinamica tutte le pietanze con relativi ingredienti, possibili allergeni, costi e quantità disponibili
• selezionare dal menu piatti e quantità
• selezionare l’orario del delivery
• selezionare la modalità di delivery (da ritirare in loco o consegna a domicilio)
• selezionare il tipo di pagamento (contanti, bancomat, ecc..)
• dare conferma dell’avvenuta prenotazione
• dare la possibilità di modificare l’ordine fino a qualche ora prima del delivery

Insomma una serie di possibilità utili al consumatore.

Ovviamente non è possibile avere tutto subito, immediatamente, e avere anche la pretesa di aver implementato tutte le funzionalità che sicuramente saranno ritenute utili.

Quindi? Come fare? Come procedere?

Siamo partiti dall’inizio, dalla vision del servizio e ci siamo chiesti quali potevano essere le User Story necessarie alla sua realizzazione; così su una board Miro abbiamo creato uno Story Mapping e tutte le storie con relative personas e flusso di lavoro.

Ci siamo chiesti, poi, se il progetto poteva avere senso e come poter validare le nostre ipotesi con il minimo sforzo; così ci siamo dati come obiettivo del primo Sprint quello di fornire le funzionalità necessarie per vedere se il prodotto poteva funzionare.

Ottimo inizio: avevamo creato un primo Product Backlog e lo Sprint Goal del primo Sprint.

Quindi, escludendo il superfluo, rimanevano solo le funzionalità per il MVP.

Ma cos’è l’MVP? Ovvero cos’è Il Minimum Viable Product? Minimo prodotto vitale, sostenibile, necessario, ma per chi? Ma per le personas individuate precedentemente.

Ecco, allora, che poteva avere inizio la scrematura.

Sono state selezionate le storie che nella visione del Product Owner potevano dare valore sin dal primo Sprint e grazie alle quali si poteva raggiungere il Goal:

Su queste storie si è aperto il nostro meetup che ha visto protagonisti il PO, lo Scrum Master e cinque Sviluppatori, tutti selezionati volontariamente tra i partecipanti.

La discussione sul significato delle User Story, sulla loro fattibilità nell’arco di uno Sprint e sul raggiungimento dello Sprint Goal hanno animato la serata.

I sette volontari sono stati bravissimi e hanno simulato alla perfezione lo Sprint Planning.

Qui di seguito lo Sprint Backlog.

Supponendo che il team riesca a completare tutti i task selezionati, con questo “minimo set di User Story” potevamo essere in grado di fornire al cliente una prima versione funzionante del prodotto, certo con diverse limitazioni, ma pur sempre funzionante.

In questo modo abbiamo 2 vantaggi:

1. avere un feedback dal cliente a breve giro
2. testare direttamente sul campo se il prodotto può incontrare il favore del pubblico

I feedback ricevuti indicherebbero che l’obiettivo del Meetup sia stato raggiunto.

Un particolare grazie va a tutti coloro che hanno contribuito attivamente alla realizzazione dell’evento:

• Alma Maria Del Campo Vara che ha creato lo User Story Map
• Daniel Palmisano che ha contribuito alla selezione delle User Story per il primo Sprint
• Alessandro Dellafiore che ha moderato il meetup
• Giancarlo Degani nel ruolo di Product Owner
• Paolo Pustorino nel ruolo di Scrum Master
• Antinea, Rossana, Annalisa, Annita e Giacomo nel ruolo di Sviluppatore

Nicola

More Posts

Follow Me:

L'articolo Sprint Planning Simulation proviene da Agile Community Torino.

Certo non è come essere fisicamente vicini, ma i segnalini che si muovono su e giù per la board, l’aggiornamento in tempo reale di sensazioni, feedback e domande è utile e, se vogliamo, anche divertente.

E’ un pensiero maturato durante i nostri meetup e durante i talk di IAM On Air.

Anche ieri sera, 18 giugno 2020, mentre il nostro amico Michele Roncaglione Tet parlava della sua esperienza da imprenditore, l’esperimento della board Miro ha funzionato.

Essa è diventata un pot-pourri di domande, spunti interessanti, copertine di libri consigliati.

Michele ha evidenziato più volte come le relazioni fra persone sono la cosa fondamentale per lui e per il suo lavoro, e di come questo pensiero lo ha condotto attraverso storie sì di insuccessi, ma anche e soprattutto di soddisfazioni che hanno coinvolto tutto il suo team.

E’ stato anche interessante scoprire come alcuni suoi clienti apparentemente “allergici” ad Agile abbiano cambiato idea una volta toccato con mano gli effettivi benefici che si possono ottenere da un corretto utilizzo delle pratiche che la nostra Community sta portando avanti; e il momento più intrigante è stato quando gli stessi clienti dopo aver chiesto di fare un passo indietro e di tornare al contratto “a corpo” si siano trovati spiazzati e delusi da quelle che fino a pochi mesi prima erano le loro prassi. 

Il meetup si è concluso con una stuzzicante dibattito sul Gantt come strumento e come eventualmente esso possa essere utilizzato con profitto nelle pratiche Agile: la discussione si è animata con contributi sia di chi lo “odia” sia di chi non lo demonizza; in fondo è uno strumento come gli altri e la sua utilità/inutilità dipende sempre dall’uso che se ne fa.

Al prossimo incontro.

Nicola

More Posts

Follow Me:

L'articolo La Mirabile Impresa proviene da Agile Community Torino.

Molto (troppo) spesso si pensa che sia sufficiente mettere insieme un gruppo di persone, dire loro che devono seguire poche semplici regolette prese dal manifesto Agile o da qualche altro manuale e… taaac! Il gioco è fatto: si può dire di essere Agile!!!

Niente di più falso.

Non basta concentrarsi sulla produzione, bisogna rivedere il processo di analisi, di collaborazione con i clienti, di scrittura dei contratti.

Ma se alla base di tutto questo non mettiamo le persone giuste, non riusciremo mai ad ottenere i risultati desiderati.

E come fare ad inserire le persone giuste negli ingranaggi di un’azienda?

È necessario che anche il processo di selezione sia rivisto ed abbia come obiettivo sia  l’accertamento delle capacità professionali dei candidati sia la loro propensione al lavoro di gruppo e al modo con cui si relazionano coi colleghi.

Come, però, è possibile sondare questi aspetti dei candidati?

Al solito quando si tratta di persone non esiste una risposta unica o un metodo preconfezionato che possa andare bene sempre e comunque.

Durante il nostro meetup del 23 luglio 2020, Paolo Pustorino ci ha descritto come SparkFabrik ha pensato di organizzare il processo di selezione dei suoi collaboratori.

Paolo è a capo dell’ufficio HR (Human Relations) e si occupa direttamente di selezione del personale; la sua esposizione chiara e dettagliata, così come le risposte alle domande dei partecipanti hanno reso l’evento davvero interessante.

Ecco la registrazione:

[This post contains video, click to play]

Buona visione!

Nicola

More Posts

Follow Me:

L'articolo Reclutamento e agilità: un’esperienza proviene da Agile Community Torino.

Lo scorso 7 maggio 2020 si è tenuto il secondo meetup quasi completamente virtuale.

Virtuale è stato il nostro incontro via Zoom, virtuale è stata la nostra board, un progetto Mural condiviso sul quale abbiamo tracciato le linee guida della serata e dove tutti hanno potuto inserire domande, commenti e quant’altro si è pensato utile per la serata.

Virtuale è stato anche il banchetto allestito per Synesthesia, lo sponsor della serata che, grazie ad un giochino, ha premiato il più veloce risolutore tra i partecipanti. Qual è stato il premio? Un buono Amazon, che in questo momento crediamo sia particolarmente gradito.
Ma quindi perché QUASI completamente virtuale?
Ma è ovvio: perché NOI eravamo reali, le NOSTRE domande erano reali, come anche le NOSTRE risposte: reali!
La differenza la fanno le persone: vicine o lontane purché in contatto.
Esattamente come è accaduto durante il precedente meetup “PO cafè virtuale” del 17 aprile, il cui successo ha fatto scattare l’idea di replicare con la figura dello Scrum Master.

Il format è stato molto simile: 3 iterazioni con domande e risposte fra gli speaker e i partecipanti; ciò che ha differenziato le due sessioni è stata la sperimentazione dell’uso di un progetto Mural, ma a noi agilisti, si sa, piace sperimentare per imparare e migliorare.
Fino ad ora dai meetup della Community abbiamo sempre portato a casa qualcosa: un consiglio, un’idea, una battuta divertente, una critica costruttiva, un libro o un link ad un articolo interessante. Questa immagine che riporta i risultati del sondaggio di gradimento alla fine del meetup testimonia che abbiamo fatto centro anche questa volta.

Finché ci sarà gente che crede nella Community e nello scambio interpersonale non c’è virus che tenga. Ci arricchiremo sempre un po’ di più. Sempre di qualcosa di REALE.

W LA COMMUNITY e tutti coloro che la sostengono (anche economicamente, perché come tutte le Community, anche la nostra si basa su piccole donazioni)!!!

Nicola

More Posts

Follow Me:

L'articolo Scrum Master caffè virtuale proviene da Agile Community Torino.

Un altro successo della Community!!

Di cosa sto parlando? Ma naturalmente del Mini #Play14 che si è tenuto sabato 9 marzo presso i locali di Cascina Roccafranca a Torino!!

La partecipazione è stata numerosa e il coinvolgimento totale, grazie anche ai due moderatori (oserei dire trascinatori) Antonio Fazio e Francesco Pratolongo.

Ci siamo divertiti un sacco, abbiamo giocato, pensato e imparato.

Quali erano i giochi? Non è importante. L’importante è il come.

Tornare bambini fa piacere a tutti e vedere persone adulte che giocano come se fossero dei “mocciosetti” fa sorridere.

Quando l’atmosfera è giocosa non si pensa alle sfide o a primeggiare: questo rende liberi di agire e anche di sbagliare senza remore, liberando così il pensiero laterale.

È stato dimostrato, infatti, che in alcune attività ludiche i bambini superano gli adulti in prestazioni, proprio perché per loro non si tratta di una sfida, ma di un momento di divertimento e di aggregazione. Nulla di più.

Ma allo stesso tempo sappiamo che per i più piccoli il gioco è un momento fondamentale di crescita e di apprendimento.

Ed è proprio questo aspetto che viene sfruttato nel #Play14: il gioco diventa momento per imparare a liberarsi, a stare con gli altri, a ricaricarsi di energia positiva.

Risultato? Eccolo!!!

Nicola

More Posts

Follow Me:

L'articolo Mini #Play14 sbarca a Torino proviene da Agile Community Torino.

E anche allo IAD 2018 non sono rimasto deluso.

Qualcuno potrebbe pensare che sia sempre la solita solfa, che sia la stessa minestra riscaldata, che è meglio rimanere comodamente a casa e aspettare la pubblicazione dei video, tanto è lo stesso.

Tutto sbagliato!

Non è per niente lo stesso. Essere lì, avere la possibilità di fare domande, di guardare in faccia il relatore, di respirare quell’aria è un’altra cosa.

Ci sono sempre aspetti che non avrei mai immaginato, spunti nuovi su argomenti dei quali non avevo mai sentito parlare, o solo per sentito dire.

I workshop ti danno la possibilità di interagire direttamente con altre persone, di conoscere gente nuova, di socializzare.

E non è finita qui.

Il dopo-talk, la cena tutti insieme, sono momenti di aggregazione bellissimi, impagabili.

E anche fra uno scherzo e l’altro, fra una battuta ed una frase seria, c’è sempre da imparare: un suggerimento, un libro interessante, l’esperienza di vita vissuta, fanno di questi eventi degli incontri formativi che non puoi vivere stando sulla poltrona di casa, che non trovi fra le pantofole ed il cuscino.

Può essere stancante, soprattutto se fai lunghi viaggi, se magari per essere a Brescia ci si è dovuti spostare dalla Calabria, o dalla Sicilia o dalla Sardegna ma, secondo me, ne vale la pena.

È vero che non si può fare la trottola in giro per l’Italia e seguire tutti gli eventi che vengono proposti nelle varie regioni e che bisogna anche fermarsi un attimo, per approfondire gli argomenti che più ci hanno interessato, e, soprattutto, metterli in pratica per crescere insieme al proprio team di lavoro.

Ma quando è possibile, allora sì, dai … finalmente ecco l’apertura della prenotazione del biglietto … su, organizza il viaggio, prenota il treno o l’aereo … “Hai già chiamato l’albergo?” “No, questa volta mi sono organizzato con degli amici per una casa”. “Perfetto, quando ci vediamo?” “Ti aspetto alle 09.00 all’apertura delle registrazioni”.

E quindi mi chiedo e ti chiedo: perché non proviamo ad organizzare noi un evento? Abbiamo un’idea? Un argomento da proporre? È faticoso sì, ma bello, coinvolgente, aggregante. E alla fine potrai dire: “Stavolta c’ero anch’io!”

Nicola

More Posts

Follow Me:

L'articolo IAD 2018 – Brescia proviene da Agile Community Torino.

L’esperienza è sempre positiva anche perché, oltre allo zoccolo duro che non può mancare ad ogni appuntamento, si aggiungono sempre persone nuove con le più disparate conoscenze, che molto spesso si trovano lì per sbaglio o per caso, o solo per curiosità, ma che alla fine difficilmente vanno via deluse, almeno così dicono.

I volontari che propongono argomenti interessanti e desiderano divulgare la loro esperienza per fortuna non mancano, e questa volta i temi trattati erano davvero stimolanti, seppur difficili da seguire.

La scaletta di questo meetup prevedeva i seguenti punti:

• Preventivare il rischio: quando il rischio d’impresa diventa un’opportunità – Wolfgang Cecchin
• Antifragilità – Jacopo Romei
• Gaming: Penny Game – Andrea Pinnola

Stuzzicanti vero? Beh, vi assicuro che dal vivo lo è stato di più.

Ma, visto che c’erano parecchie persone nuove, abbiamo iniziato con un giochino per rompere il ghiaccio. Ecco, qui sotto raffigurato, lo strumento di “tortura”.

Dopodiché siamo entrati nel vivo della serata.

Nella prima parte della serata abbiamo parlato di rischio d’impresa legato ai contratti.

Sì, perché ci sono diverse modalità per stipulare un contratto fra un committente ed un fornitore, vecchie e nuove, più rischiose o più sicure, e non sempre una tipologia va bene per un determinato prodotto o per quel tipo di impresa o addirittura per quel determinato committente.

Grazie ad una serie di slide ed esempi, Wolfgang ha mostrato come, fin dai tempi di Colombo e dei navigatori dell’epoca, si potevano stipulare i contratti in forme diverse in base alle quali i rischi e i vantaggi potevano essere bilanciati in modo differente tra le parti.

Stava ad ognuno dei due contraenti riuscire a convincere l’altro su come procedere nella trattativa, cercando di condurla a proprio favore.

E tutto questo è davvero agile. Non sì può pensare di avere contratti rigidi dove tutto è predeterminato (funzionalità, tempo, spesa) e allo stesso tempo lavorare in agilità. L’agile ribalta le vecchie regole del waterfall e lo schema seguente lo mostra perfettamente:

fermo restando la qualità, il tempo e i costi, quello che varia sono le funzionalità.

Solo così il team può muoversi in maniera snella (lean) e agile al cambiare dei requisiti che il cliente e il mercato impongono.

Nel secondo intervento abbiamo affrontato l’argomento clou: cos’è l’Antifragilità?

Cos’è fragile e cosa non lo è, ma soprattutto cos’è antifragile.

Riprendendo alcuni concetti di Nassim Taleb sull’argomento, Jacopo ha spiegato con la semplicità e l’efficacia che lo contraddistinguono, quali sono le differenze fra i vari tipi di sistemi: un sistema che si rompe alle sollecitazioni è un sistema fragile, uno che invece resiste è un sistema robusto; ma un sistema che reagisce alle sollecitazioni e si rafforza è un sistema “antifragile”.

In natura abbiamo molti esempi di questo.

Il nostro sistema immunitario ad esempio: noi oggi siamo forti e più o meno resistenti alle malattie perché ci siamo ammalati da piccoli (chi di voi genitore non ricorda il primo anno di asilo nido o scuola materna del proprio figlio? Quanti giorni il vostro bambino ha passato in casa malato e quanti all’asilo?).

Altro esempio, un osso non si fratturerà mai due volte nello stesso punto (è il principio che molti fanatici delle arti marziali usano per rafforzare le loro ossa: si procurano una serie di microfratture alla tibia in modo da creare il callo osseo in più punti).

Nell’ultima parte della serata abbiamo giocato al “Penny Game”.

È stato divertente vedere attraverso un gioco come piccoli ma continui rilasci di poche feature siano molto più efficaci di un unico grande rilascio alla fine del progetto.

L’abbiamo fatto con l’ausilio di alcune monetine (penny, appunto) che i componenti del gruppo si scambiavano rispettando alcune regole dettateci da Andrea.

Insomma il bilancio finale è stato, come sempre, una serata all’insegna dello scambio di idee, della diffusione delle conoscenze, ma soprattutto nello spirito di un gruppo di persone piacevoli ed unite dalla passione per l’Agile.

Nicola

More Posts

Follow Me:

L'articolo Contratti e Antifragilità proviene da Agile Community Torino.