Guarda il video del meetup

[This post contains video, click to play]

Un esperimento in diretta: AI e sviluppo software in tempo reale

In questo meetup dell’Agile Community Torino, abbiamo esplorato un tema che sta rivoluzionando il modo di progettare e costruire prodotti digitali: l’intelligenza artificiale generativa applicata allo sviluppo software.
Abbiamo ospitato Tech Reloaded, rappresentata dai due speaker Stefano Marello e Stefano Leli, che ci hanno guidato in un viaggio tra teoria e pratica, mostrando come l’AI possa diventare un alleato potente, ma non privo di rischi.

La serata si è aperta con un’introduzione di Daniel Palmisano, che ha presentato l’esperimento live: mentre Leli raccontava il processo, Marello sviluppava in tempo reale una nuova funzionalità per Raid Atlas, un prodotto nato proprio per testare il potenziale del Vibe Coding.

Cos’è il Vibe Coding?

Il termine Vibe Coding è un approccio allo sviluppo software che consiste nel descrivere ciò che si desidera in linguaggio naturale e lasciare che l’intelligenza artificiale generi il codice necessario.
Per essere veramente efficace, abbiamo visto come il Vibe Coding richieda:

• Agenti AI specializzati (product manager, architetti, sviluppatori, tester)
• Automazione avanzata (IDE potenziati, agenti su linea di comando, server MCP)
• Supervisione umana costante

L’obiettivo? Costruire un flusso end-to-end che parte dalla raccolta dei bisogni utente e arriva fino alla messa in produzione, mantenendo sempre il man-in-the-loop: l’essere umano come guida e validatore.

Il caso Raid Atlas

Raid Atlas è una piattaforma pensata per motociclisti, che permette di creare, vendere e acquistare itinerari di viaggio. Leli ci ha raccontato che alla base del progetto ci sono state quattro fasi fondamentali:

1. Ideazione e pianificazione (con interviste agli utenti tramite agenti AI e creazione di roadmap e PRD)
2. Design e prototipazione (mockup su Miro e conversione in componenti React tramite Figma Make)
3. Setup degli ambienti (con regole, boilerplate e CI/CD su Vercel)
4. Sviluppo (creazione task tecnici, sviluppo e test automatici).

Contemporaneamente, Marello ha implementato in diretta una nuova funzionalità: i commenti sui viaggi.  Un’idea nata spontaneamente dal pubblico, è stata implementata in tempo reale con il supporto dell’AI, in appena trenta minuti (“un pomodoro”).

Pregi e limiti dell’AI nello sviluppo

Pregi:

• Accelerazione drastica dei tempi
• Supporto su tecnologie non conosciute
• Crescita professionale per junior e senior
• Collaborazione cross-funzionale facilitata

Limiti:

• Allucinazioni e inventiva non controllata
• Memoria corta e perdita di contesto
• Tendenza a “barare” nei test
• Rischio di mettere in produzione codice non validato

Un codice etico per il Vibe Coder

I relatori hanno proposto quattro principi guida per chi lavora con l’AI nello sviluppo:

1. Responsabilità: il codice in produzione è sempre responsabilità umana
2. Comprensione : non si mette in produzione ciò che non si comprende
3. Qualità: non ci sono più scuse per codice scadente
4. Guida: l’AI è un amplificatore, non un sostituto

Domande e riflessioni

Il meetup si è concluso con un vivace scambio di domande, tra cui:

• Come integrare il TDD con l’AI?
• Quali strumenti usare per requisiti, test e sviluppo?
• Come si addestrano gli agenti AI?
• Qual è il ruolo del designer in questo processo?

La risposta più potente è arrivata dalla conversazione: “Il man-in-the-loop oggi è la garanzia che l’AI non sostituisce l’essere umano, ma lo affianca. E questo è ciò che rende il processo sostenibile e professionale.”

L'articolo Vibe Coding: AI generativa e sviluppo prodotto, tra accelerazione e supervisione proviene da Agile Community Torino.

Partendo dallo Scrum Expansion Pack, una proposta aperta disponibile su scrumexpansion.org, abbiamo discusso insieme di come il framework si stia adattando alle nuove sfide che team e organizzazioni incontrano ogni giorno.

Una board, tante prospettive

Come spesso accade nei nostri incontri, la conversazione è stata arricchita dal contributo di tutti i partecipanti. Su una board Miro condivisa abbiamo raccolto spunti, osservazioni ed esperienze dirette. Ci siamo soffermati in particolare su alcuni aspetti che abbiamo trovato interessanti:

• Focus sul prodotto e product goals, discovery, team auto organizzati e professionalità

• Agenti AI come tool utili al lavoro ma anche come product developer facenti parte del team

• Nuove accountabilities come supporter stakeholder

• Validation del valore da realizzare: usability, desirability, viability

• People are not resources!

Il risultato è stato un mosaico di punti di vista che ha reso evidente come Scrum non sia mai statico, ma una pratica viva che evolve insieme alle comunità che la utilizzano.

Cosa ci portiamo a casa

La serata ci ha lasciato alcune riflessioni importanti:

• Scrum come base solida, ma non intoccabile: i principi restano, le pratiche si adattano.

• Sperimentare è fondamentale: solo provando sul campo nuove idee possiamo capire se generano reale valore.

• Il confronto comunitario arricchisce: ascoltare esperienze diverse ci aiuta a vedere opportunità che da soli non coglieremmo.

E adesso?

L’invito per tutti è continuare a sperimentare, leggere e contribuire allo Expansion Pack, e portare poi in community le esperienze vissute.

La conversazione è aperta: probabilmente faremo un follow-up di questo meetup per arricchire ed evolvere la conversazione. Stay tuned!

L'articolo Scrum Reloaded: una conversazione sull’evoluzione di Scrum proviene da Agile Community Torino.

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!

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

Nel nostro ultimo meetup di 2024, il 10 dicembre da Talent Garden Torino, abbiamo chiuso in bellezza con il nostro buon Stefano Marello che ha portato ai partecipanti un mix and match di due approcci chiave che sono le User Stories e il framework Jobs to Be Done (JTBD). 

Il primo passo per comprendere questi approcci è analizzare la triade fondamentale:

Utente + Bisogno + Outcome

Ricordiamoci che ogni prodotto servizio che creiamo (o aiutiamo a creare) ha la responsabilità di soddisfare un bisogno specifico. Ma qui entra una discussione importante: quanto è cruciale mettere in evidenza (e perciò approfondire) l’utente? Quanto questo elemento, che abbiamo già stabilito essere cruciale, può variare a seconda della complessità del contesto e degli attori coinvolti? 

Già nel 2010, alcune aziende come Intercom hanno sollevato dubbi sull’utilizzo delle User Stories e sul fatto che mettere l’utente di riferimento al centro del requisito non portasse vantaggi concreti.

Sebbene le Personas siano strumenti utili per rappresentare gli utenti, esse creano profili immaginari piuttosto che reali. Ed è qui il punto che vogliamo focalizzare perché questo ci porta a interrogarci sul legame tra le personas e gli utenti reali.

Non sempre le sfumature delle Personas influenzano direttamente i bisogni fondamentali degli utenti. 

L’esempio che abbiamo utilizzato all’inizio era la necessità di proteggere un account. Il bisogno di base rimane costante, ma le modalità di soddisfacimento possono variare. Ma il bisogno è sempre quello, indipendentemente a quale Personas ci rivolgiamo.

Proviamo ora a guardare da un’altra prospettiva, evidenziando un secondo framework: Jobs to Be Done (JTBD), sviluppato da Clayton Christensen e approfondito da Alan Klement. Il JTBD si concentra sul contesto (sul contesto!) in cui si trova l’utente e sulle motivazioni che lo spingono ad utilizzare un prodotto o un servizio per soddisfare un bisogno specifico. In questo modo, il focus si sposta dalla persona all’attività da svolgere.

Quindi, perché non mettere tutti gli ingredienti in pentola per avere una visione molto più pratica dell’utente?

Ed è qui che nascono le Job Stories: una forma alternativa delle User Stories che incorporano elementi chiave del JTBD.  La struttura tipica di una Job Story è: “Quando [situazione], voglio [motivazione], così posso [risultato]”. Questo approccio consente di esplorare le esigenze degli utenti in modo più profondo e contestualizzato.

Quando Utilizzare User Stories o Job Stories

La scelta tra User Stories e Job Stories dipende dal contesto del progetto:

• User Stories: Utili quando gli utenti hanno bisogni distinti e variabili. Queste storie iniziano con “Come utente…” per mettere in risalto chi sta compiendo l’azione.
• Job Stories: Preferibili quando i bisogni degli utenti non differiscono significativamente. Qui, il focus è sul compito da svolgere piuttosto che sull’identità dell’utente.

E quindi, che approccio mi conviene utilizzare?

Immagina di mescolare User Stories e Job Stories all’interno dello stesso backlog di prodotto. Questo ti permette di avere una visione più completa delle esigenze dei tuoi utenti.

È come avere il meglio di entrambi i mondi.

La cosa bella è che sia le User Stories che le Job Stories sono progettate per migliorare la comunicazione tra i team di sviluppo e gli utenti. Così, puoi essere sicuro che i prodotti finali rispondano davvero ai bisogni di chi li utilizza.

Si crea la possibilità di innovare in modo significativo e rispondere alle esigenze dei clienti in modo efficace. In sintesi, non sottovalutare il potere di queste tecniche, soprattutto quando messe insieme. Lascia che ti sorprendano!

Per visualizzare la presentazione completa, clicca qui.

L'articolo Quando l’User Story incontra il Job to be Done proviene da Agile Community Torino.

Oltre la definizione tradizionale di leadership

Il 3 ottobre 2024, al Talent Garden Fondazione Agnelli di Torino,  Alma del Campo Vara ci ha aiutato a riflettere su cosa sia davvero la leadership. Abbiamo iniziato sfidando l’idea che un leader sia necessariamente un individuo con potere politico o decisionale. Il dibattito ha toccato le varie forme di leadership che esistono in un’organizzazione, mostrando come un leader possa emergere in qualunque ruolo, non s olo da chi è in cima alla gerarchia. Questa parte ha messo in luce come la leadership possa essere vissuta da chiunque sappia influenzare positivamente il proprio contesto, dimostrando empatia, visione e capacità di ascolto.

Leader e follower: una relazione simbiotica

Uno dei concetti centrali del workshop è stata la relazione tra leader e follower. Alma ci ha chiesto se “un leader senza follower, è davvero un leader?” stimolando riflessioni interessanti. La discussione ha evidenziato l’importanza di saper creare un ambiente di fiducia e motivazione, un terreno fertile dove la collaborazione può crescere. Un leader non è tale se non riesce a ispirare chi lo circonda. Abbiamo esplorato le dinamiche tra leader e follower, mettendo in risalto l’importanza del coraggio e dell’orientamento al risultato.

Un leader di contesto

Infine, il workshop ha offerto strumenti di riflessione su quali stili di leadership siano più efficaci in contesti diversi. Ogni gruppo ha potuto esplorare una situazione diversa e approfondire quale approccio sarebbe stato migliore per il raggiungimento del risultato atteso.
Siamo stati invitati a riflettere sulle nostre esperienze di leadership, condividendo successi e difficoltà e creando un ambiente di apprendimento collettivo.

Abbiamo capito che la leadership non è solo una questione di potere e posizione, ma di responsabilità e influenza. Si tratta di creare un percorso di crescita personale e di lavorare costantemente sulle proprie abilità per ispirare e motivare chi ci circonda.

L'articolo Leadership autentica: sviluppo, relazioni e impatto proviene da Agile Community Torino.

Quante volte abbiamo avuto esperienze negative nei team di lavoro e abbiamo faticato a migliorare la situazione?

Da oggi possiamo aggiungere uno strumento in più al nostro cassetto degli attrezzi grazie a CoLabo, il gioco in scatola “serious play” con il quale si possono organizzare workshop che facilitano la comunicazione e promuovono l’ascolto.

Abbiamo giocosamente affrontato problemi reali e molto comuni scoprendo alcune soluzioni vincenti per costruire un ambiente di lavoro sereno e collaborativo.

Si va in trasferta

Per la prima volta, la community ha organizzato un appuntamento “fuori sede” grazie alla preziosa collaborazione di Scrum Agile Milano e Talent Garden, che ha gentilmente messo a disposizione gli spazi di TAG Isola per il workshop.

L’evento si è tenuto il 7 marzo e ad accoglierci abbiamo trovato i creatori di CoLabo: Valerio Acerbis, Matteo Tortelli, Giulia Re e Alessandro Colla, tutti colleghi della Web Agency Evoluzione.

I ragazzi hanno preso le redini del workshop introducendo le meccaniche e l’obiettivo alla base del loro gioco: un’esperienza ludica che favorisca la comunicazione e la collaborazione all’interno di un gruppo di lavoro.

Inizia il gioco

Ci siamo divisi in tavoli da 4-5 giocatori e, dopo una breve introduzione, siamo subito entrati nel vivo e abbiamo iniziato a giocare.

Lo svolgimento è tanto semplice quanto efficace: CoLabo è un gioco collaborativo, ad ogni gruppo è chiesto di portare a termine i Progetti che verranno pescati durante la partita entro un certo numero massimo di round, chiamati Sprint.

Ogni Progetto completato, in base al grado di difficoltà, porterà una diversa quantità di punti al gruppo e l’obiettivo finale del team è raggiungere 20 punti prima della fine degli Sprint.

Come si completano i progetti?

Il gioco prevede due risorse fondamentali: l’Energia e l’Empatia. Ogni gruppo dovrà essere in grado di raccogliere e impiegare le risorse a disposizione collaborando e seguendo una strategia comune.

La strategia viene discussa e affinata al termine di ogni Sprint, dopo che tutti i giocatori hanno giocato il proprio turno, il momento della Retrospettiva.

Durante la Retrospettiva, il team può scambiarsi risorse e progetti per aiutarsi a vicenda e raccogliere più punti possibile.

Terminata la Retrospettiva, ricomincia un nuovo giro e quindi un nuovo Sprint.

Per aggiungere un po’ di pepe alle dinamiche di gioco, CoLabo prevede anche l’incursione di Problemi, atti a mettere i bastoni fra le ruote al team (es. l’impossibilità di parlare durante la Retrospettiva), ma anche delle carte “Comportamento Virtuoso” che i giocatori possono ottenere quando aiutano i compagni, le quali permettono di risolvere i Problemi pescati.

Il gioco si fa serio

CoLabo è divertentissimo, ma il valore che abbiamo tratto da questa esperienza va ben oltre il gioco in sé. Ogni carta da gioco, oltre alla sua funzione primaria, include anche degli esempi, delle situazioni, delle dinamiche che possiamo trovare nel lavoro quotidiano e qualche spunto di riflessione su come poter affrontare una situazione simile. 

Inoltre, le carte spesso includono dei mini giochi di ruolo che ricalcano un po’ le dinamiche raccontate, queste attività sono state importantissime per creare gruppo e anche momenti veramente esilaranti!

Chiusura e raccolta feedback

Dopo un’ora abbondante di divertimento, abbiamo concluso il workshop con una retrospettiva finale.

CoLabo è ancora in fase beta e i feedback raccolti sono stati tantissimi. È stato molto coinvolgente confrontarsi con i creatori sugli aspetti meglio riusciti e quelli da affinare per evolvere il gioco e renderlo ancora migliore.

La serata si è conclusa con un aperitivo in compagnia e un augurio a rivederci presto per altri fantastici appuntamenti!

L'articolo CoLabo: coltiva un ambiente aziendale positivo proviene da Agile Community Torino.

Roberto, infatti, ci ha accolti calorosamente e ci ha mostrato quanto sia importante affrontare il momento di crescita di un’azienda nel migliore dei modi, quanto le persone siano importanti e quanto i giusti strumenti possano facilitarci la vita. Ma procediamo per ordine.

Welcome

La sala, allestita appositamente, prevedeva la presenza di tre team, ognuno dei quali aveva a disposizione il proprio tavolo, dei pennarelli, dei post it, una parete, dei fogli A4 e… Un tavolo condiviso, sul quale erano riversi un paio di kg di Lego^®!

Dopo una breve presentazione, Roberto ci ha condiviso la sua esperienza di transizione organizzativa di un’azienda metalmeccanica ceduta dalla famiglia ad un fondo d’investimento, delle difficoltà che ha dovuto affrontare e di come, grazie ad alcune pratiche di facilitazione ed alcuni strumenti, sia riuscito ad identificare i punti critici e ad agire su di essi.

Arrivati a questo punto ricordo che ho pensato:

E ora come lo trasforma in un workshop?

La creazione della nostra azienda

La risposta è arrivata immediatamente: ogni tavolo ha creato la propria azienda.

Per prima cosa abbiamo utilizzato lo strumento di facilitazione 1-2-4-All attraverso il quale abbiamo deciso quale prodotto avremmo realizzato: le idee sono state fantastiche e divertenti.

Quindi, partendo dal prodotto che si voleva realizzare ed utilizzando un modello di ragionamento induttivo, ognuno ha scritto 5 step che, secondo lui, sarebbero stati necessari per arrivare a quel risultato.

Gli step sono stati condivisi, spiegati e, tutti insieme, ordinati in un flusso, che è stato poi suddiviso in «reparti».

In pochi minuti avevamo creato un prodotto, un flusso che ci avrebbe portato a realizzarlo e suddiviso i vari step nei reparti di competenza!

Wow!

La costruzione dell’azienda

Come ogni azienda che si rispetti, avevamo bisogno di persone ed uffici, quindi perché non costruirli insieme??

Ah! Ecco a cosa servivano i Lego^®!!

Ognuno ha preso in carico un reparto e ha costruito, secondo il proprio pensiero, un modellino. Mettendo insieme i modellini, le aziende hanno preso forma!

EventStorming

Non sempre le tempeste sono una brutta cosa: l’EventStorming ad esempio, ci ha permesso di «fotografare» i processi che avremmo voluto realizzare all’interno dell’azienda!

E così, a suon di Eventi, Policy e Comandi, è stato definito cosa sarebbe successo in ogni reparto, quali conseguenze avrebbe avuto e che «comandi» sarebbero usciti, con destinazione ad altre persone del reparto o a persone di altri reparti.

Questo ha permesso di visualizzare la complessità del flusso che stavamo modellando, ma anche le interazioni che ci sarebbero state tra i vari reparti!

Task e Kanban board

Infine abbiamo dato vita all’azienda, creando i task ed utilizzando la Kanban Board per visualizzarne lo stato di avanzamento!

Figo!!

Download

SLIDE – Sbloccare la crescita si può

L'articolo Sbloccare la crescita, si può! proviene da Agile Community Torino.

Ecco qui le bellissime slide proiettate durante la serata: Marco D’Andrea – È la luce quella in fondo al tunnel

In qualità di Agile coach, Marco ci ha raccontato il suo impegno nella trasformazione della cultura del lavoro e nell’ottimizzazione delle prestazioni del team.
Marco ha approfondito le complessità della filosofia Lean, facendo luce su come questa si interseca, e a volte si scontra, con la metodologia Agile.

Ha condiviso aneddoti del suo primo viaggio, illustrando il delicato equilibrio necessario per implementare efficacemente i principi Scrum in un ambiente produttivo già avviato. Dall’adattamento al cambiamento alla promozione di una cultura del miglioramento continuo, le esperienze di Marco hanno portato i presenti a conoscenza di una storia vera, fatta di successi e sconfitte e sicuramente tanta passione.

La presentazione di Marco ha fatto da scintilla per un dibattito spontaneo in cui molti dei partecipanti hanno discusso dei loro primi approcci alla metodologia Agile in ambiti diversi, scambiando esperienza, consigli e aneddoti a volte buffi e sorprendenti.

L'articolo È la luce quella in fondo al tunnel? proviene da Agile Community Torino.

A poco più di un mese dall’evento finalmente puoi vedere video e slide di tutti gli interventi del 30 settembre!
Rilasciati in modalità iterativa, ora li trovi tutti sul sito, nelle sezioni “programma” e “sessioni”:

https://agilemovement.it/venture/2023/torino/#schedule

Buona consultazione e stay #TAC23!

L'articolo #TAC23 Tutti i video e le slide degli speaker 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!!!!!!

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