Le 3 rivoluzioni
Seduti intorno al fuoco che ci unisce in questa conferenza – un fuoco alimentato da curiosità, passione e bisogno di continuo miglioramento – Agile sensei e storyteller Claudio Perrone ci trasporterà magicamente in un mondo caratterizzato da osservazioni, teorie, e sperimentazioni che hanno sostenuto almeno tre rivoluzioni in campo software tuttora in corso: Agile, Lean Software e Lean Startup. Claudio illustrerà alcuni modelli e strumenti che sta utilizzando o sviluppando in questo periodo per aumentare drammaticamente le possibilità di successo di startup, gruppi di sviluppo e transizioni a livello enterprise. La storia ha inizio negli Stati Uniti nel 2001, quando un incontro casuale con un pioniere Agile frantuma tutte le certezze e le illusioni di conoscenza che Claudio aveva sino a quel momento…
In cerca del cigno giusto
1° fatto. La consulenza è disfunzionale: una vera impresa lean
considera la consulenza una forma di spreco.
2° fatto. La consulenza scala solo linearmente e vogliamo tutti essere
ricchi sfondati.
3° fatto. I contratti, i preventivi e i vari rituali sono una forma di
spreco: nessuna start-up è stata tirata su con le scartoffie.
4° fatto. I “venture capital” stanno al denaro come noi possiamo stare
al know-how.
Unendo queste quattro proposizioni e sperimentando sul campo per una
ventina di mesi, vi voglio raccontare come ho cambiato il business
model della mia azienda supportando in modo davvero lean le start-up,
con un occhio al Cigno Nero di Taleb.
Perché non facciamo più quello che ci piace
Ilaria Mauric
Alessandro Violini
Una volta era: faccio la cosa che mi piace nel modo più facile. Oggi è: faccio al meglio la cosa più semplice e veloce per consegnare valore al cliente (e questo ci piace di più!)
—-
La nostra sessione è stata proposta e presentata il 31 maggio 2012 all’Agile UX Camp (Firenze) e vogliamo riproporla all’Agile Day per mostrare alcune integrazioni e raccontare le evoluzioni avvenute da maggio a novembre 2012.
È rivolta agli ux designer e a chi lavora in team con loro.
Orchestra: proposta per una board Kanban eretica
Sviluppare software significa passare dallo 0% di conoscenza al 100% dell’informazione. In un team agile la board accompagna l’intero percorso.
Ma se lo sviluppo software è un processo di trasformazione dell’informazione, perché ci limitiamo a spostare dei post-it? Perché le board non tentano almeno di rappresentare questo arricchimento di informazione?
E cosa accadrebbe se ci si provasse?
Siamo proprio certi che rappresentare un flusso di informazione dal backlog alla produzione sia una buona metafora dello sviluppo? E se il modello di board più adeguato fosse completamente differente?
Lo speech propone un prototipo di board alternativo e certamente non ortodosso e suggerisce alcune pratiche che potrebbero essere efficaci nella gestione del WIP e del lavoro quotidiano di team.
Nella sua semplicità, una board dovrebbe dovrebbe realizzare un obiettivo molto ambizioso: rappresentare in modo ortogonale Progetti, Task, Persone, Tempo, Stato di avanzamento e WIP. La board dovrebbe visualizzare le regole del team, rinforzandone i principi e amplificando gli effetti delle violazioni.
Quella banale superficie bianca, insomma, rende visibile e governabile un processo intangibile.
Per questo non è secondario che sia basata su una metafora potente. Perfino eretica, dovesse servire.
Sviluppo agile in un contesto bancario: come far convivere team, sistemi e metodi di lavoro diversi
Vogliamo raccontarvi una esperienza di successo riguardante il rifacimento di un prodotto in un contesto bancario. Le sfide sono state tante, su vari aspetti. Tecnico, perché dovevamo far convivere il sistema vecchio con quello nuovo fino a completo spegnimento; di metodo, perché dovevamo coordinarci con altri dipartimenti che nulla sapevano di ‘metodi agili’; di pratiche, perché abbiamo rivisto e ottimizzato quali pratiche usare nel tempo per essere sempre piu efficaci. La presentazione è di fatto un experience report, ma ci vogliamo focalizzare sugli aspetti piu innovativi che per noi sono stati importanti e originali.
Lo Scrum Master come sviluppatore di team
Il ruolo di Scrum Master è descritto come servant leader e team coach, dedito al miglioramento costante del team. Ma… cosa significa esattamente? Cosa serve ad uno Scrum Master per esercitare un tale ruolo? E come può imparare tali competenze?
In questo workshop presenterò delle tecniche da applicare nel lavoro quotidiano dello Scrum Master per favorire lo sviluppo e l’auto-organizzazione del team. I partecipanti verranno invitati a discutere le applicazioni dei metodi presentati ai loro casi concreti e verranno presentati alcuni case studies.
Il workshop è anche rilevante per i Product Owner che vogliono trovare nuovi metodi per interagire con i loro team – anche loro sono dei servant leader! – e, in generale, è utile per ogni persona che per professione lavora in team.
Formato: workshop
The Beating Heart of Agile
Cos’è che permette a un team o a un’organizzazione Agile di funzionare come un orologio, di produrre risultati e di generare successo? Quello che chiamiamo Agile è solo un insieme di pratiche e strumenti utili, o c’è dell’altro che ancora non vediamo? Certo, abbiamo valori e principi nel manifesto Agile, ma sono quelli a fare veramente la differenza tra un team che funziona e uno che non funziona?
E la domanda più importante: potrebbe essere che la capacità effettiva di teamwork e le competenze socio-relazionali, adattate su misura all’ambiente culturale del mondo Agile, siano la vera (e per la maggior parte inutiluzzata) fonte di vantaggio competitivo?
In questa sessione, che si basa sull’esperienza dello speaker come coach Agile, toccheremo temi quali:
* modelli mentali efficaci e non
* il ruolo della creatività
* intelligenza collettiva
* apprendimento organizzativo
* sistemi sociali auto-organizzanti
Inoltre, vedremo come tutti i temi sopra citati siano necessari (e possano essere coltivati) per creare una cultura e un ecosistema in cui sia l’organizzazione che le singole persone possare raccogliere i benefici di un approccio Agile, i quali comprendono qualità, feedback rapido, miglioramento costante, apprendimento, teamwork e, naturalmente, profitto.
Agile Experience Design and Development
Timothy Carniato
Mauro Servienti
Design e sviluppo sono da sempre due discipline che si basano su fondamenta e punti di vista molto diversi. Per questo motivo è sempre stato difficile creare il mix giusto, mix che quando è riuscito ha decretato il reale successo del prodotto o del servizio realizzato.
Oggi, più che negli anni passati, il mercato, le tecnologie, gli utenti, i contesti di utilizzo, i clienti ed i contenuti sono arrivati ad assumere decine di forme dando vita a migliaia di combinazioni possibili.
Per questo motivo è vitale, e non opzionale, trovare il modo in cui Design e Development possano non solo convivere ma crescere insieme ed uno esaltare l’altro con l’obiettivo comune di realizzare prodotti e servizi dall’esperienza unica.
Breaking the ice with agile: cinque strade per rompere il ghiaccio e introdurre i metodi agili in una azienda
La nostra esperienza ha mostrato che esistono alcune pratiche “rompighiaccio” che, con un costo di introduzione relativamente basso, permettono di far prendere coscienza alle persone di alcune problematiche e dinamiche tipiche dei progetti software e che ne minano il successo.
La presa di coscienza di queste problematiche e dinamiche è il primo passo per comprendere e abbracciare valori e principi dei metodi agili.
Le pratiche di cui vorremmo parlare e che definiamo “ice breakers” per quel che riguarda le metodologie agili sono:
- adozione della lavagna per rappresentare il flow del lavoro
- standup meeting
- retrospective
- build automatica (e automazione in genere)
- acceptance testing
A cascata poi queste pratiche se ne portano dietro altre più difficili da adottare fin da subito, ma più facili da far adottare quando le persone prendono coscienza dei problemi che gli impediscono di lavorare in modo efficace (pair, tecnica del pomodoro, user stories, TDD, CI, simple design, daily journal, etc) e abbracciano i principi dell’agile.
Per ogni pratica “ice breakers”, a partire dalla nostra esperienza, illustreremo il motivo per cui secondo noi sono tali, le dinamiche secondo noi migliori per proporne l’introduzione, anti-pattern e resistenze al cambiamento che abbiamo incontrato e come le abbiamo affrontate.
Da programmatore a CEO
Questa è la storia di due programmatori che dopo aver trascorso alcuni anni come dipendenti e come freelance hanno deciso di fondare una società che si occupa di software.
Durante la sessione racconterò quali sono stati i passi e le scelte che abbiamo fatto, come è nata l’idea di fondare una software house che realizza progetti su commessa e quali principi ci hanno ispirato. Parlerò dei problemi tecnici, economici e burocratici che abbiamo avuto e di come abbiamo cercato di superarli. Racconterò dei nostri successi, dei progetti falliti, delle piccole rivincite e di quello che sono riuscito ad imparare sul business del software. Una serie di best practice, worst practice e tips per il neo imprenditore.
Continuous Delivery in un baleno
Altri speaker:
Collaborerà Francesco Degrassi.
Hai sentito parlare di Continuous Integration e Continuous Delivery, due temi che da un po’ di anni scaldano l’ambiente del software, ma non hai mai provato a metterle veramente in pratica, magari perché ritieni che nella tua piccola azienda, o nel tuo lavoro da libero professionista, il loro contributo potrebbe essere minimo rispetto al tempo che dovresti perderci per imparare ad usarle.
Hai anche provato a dare un’occhiata alle soluzioni hosted che ti proponevano il tutto come un servizio, per capire che in realtà imponevano un workflow forse migliore ma decisamente diverso dal tuo, che non vuoi o non puoi permetterti di cambiare tutto d’un tratto, fermando il tuo lavoro.
Ti propongo quindi di imparare, in soli 10 minuti, ad effettuare il setup di un’infrastuttura elementare di build & delivery: git o mercurial come VCS, Jenkins come server di continuous integration, e Puppet come strumento di configuration management.
Potrai vedere da subito quant’è facile essere immediatemente operativi, automatizzare procedure solitamente lente e noiose, massimizzare il tempo dedicato allo sviluppo effettivo, e raffinare l’infrastruttura man mano a seconda del tempo a disposizione e delle necessità, effettuando quindi una migrazione progressiva dal “tutto manuale” al “tutto automatico.”
Formato: Lightning talk
Non è solo un problema di metodologia
La “cultura aziendale” è composta da un’insieme di regole non scritte, e di comportamenti, che influenzano le azioni delle persone di un’organizzazione. Queste regole possono diventare il principale freno per l’adozione di una metodologia agile, o la scusa per adottarne solo alcune pratiche e non i principi.
Se Scrum o Xp non fanno per voi, allora supponiamo di adottare una metodologia Non Agile.
Possiamo sperare di migliorare la competitività aziendale senza modificare gli aspetti culturali?
Formato:Lightning talk (durata 10′)
The Rhythm of the Board
Gaetano Mazzanti
Questo breve talk illustra un utilizzo creativo di tecniche audio e visuali per rappresentare l’evoluzione di una Kanban board, in particolare il flusso di elementi in entrata e uscita e la loro “età”.
Questo tipo di informazioni non sono in genere ricavabili tramite strumenti e grafici standard quali Control Charts e CFD.
Il talk mostrerà come ovviare a questa lacuna combinando audio, barre mobili e grafici a bolle. It’s fun 
Un sistemista agile e snello
BioDec ha intrapreso nel corso del 2012 un’iniziativa per migliorare il proprio modo di lavorare. L’attività dell’azienda consta per tre quarti in system management, o guerrilla IT, e per il resto in sviluppo software {bio,}informatico. L’idea era di valutare se le metodologie Agili, e in particolare quanto si applicava allo sviluppo del software fosse usabile, e nel caso con quali varianti, nell’ambito dell’IT.
La sessione vuole mostrare il percorso svolto fino ad’ora da BioDec, da dove siamo partiti, cosa abbiamo fatto e cosa non abbiamo fatto, a che punto siamo (e dove vorremmo arrivare).
“La collaborazione col cliente più che la negoziazione dei contratti” – si, ma i contratti in Agile?
Collaborando con diverse società interessate a trasformare il loro processo di sviluppo e di realizzazione di prodotti da una modalità tradizionale ad una basata sulle metodologie Lean Agile mi è capitato spesso di dover rispondere in modo concreto alla domanda seguente: “come vanno gestiti i contratti in un contesto Lean Agile?”
Scopo di questa sessione è quello di trattare questo importante e delicato tema, descrivendo le dieci principali forme di contratti Lean Agile sotto vari punti di vista e dettagliando punti di forza e di debollezza di ciascuno di essi.
Training and Coaching Agile Minds
In questi ultimi anni ho formato l’idea che le metodologie Agili non sono solo un nuovo modo di sviluppare software ma rappresentino una delle molteplici risposte al modo in cui la nostra società sta cambiando.
Zygmunt Bauman ha chiamato “modernità liquida” la nostra società che ci impone di adeguarsi alle attitudini ai cambiamenti sociali in maniera sempre più frenetica creando continua incertezza.
Una continuazione caotica di modernità dove più facilmente si può passare da una posizione sociale ad un altra in modo fluido.
Creare un ponte tra culture diverse, affrontare incognite e prendere decisioni in un contesto di incertezza, non solo fail fast ma fail better, essere in grado di rivalutare le proprie aspettative, imparare ad imparare, imparare a dare e ricevere feedback, imparare quando infrangere le regole, evolvere ed innovare continuamente.
Questi sono alcuni dei tratti che stanno diventando importanti non solo per far parte di team di sviluppo software, ma anche per affrontare la società moderna.
Abbiamo formato ed è evoluto il nostro programma di formazione su questi principi cercano di formare non Sviluppatori Agili migliori ma Persone migliori.
Agile Software Development in the Computer Science Handbook
Il Computer Science Handbook è un compendio importante del cosiddetto Body of Knowledge dell’Informatica. A causa del grande successo delle prime due edizioni, una terza edizione sarà pubblicata che prevede una nuova parte sull’ingegneria del software. L’obiettivo del compendio è di riassumere i principi, lo stato dell’arte, e i temi di ricerca attuali e futuri in ogni area. Mi è stato chiesto di scrivere il capitolo per lo sviluppo Agile per la nuova edizione. Parlerò di qualche tendenza ed iniziativa attuale ed anche dei nuovi temi di ricerca nell’ambito agile che ho incontrato mentre scrivevo il capitolo.
Extreme Project Evaluation
“How can you plan a project if you only have a week? [..] You don’t have enough time to write a complete set of stories [..] You don’t have time to write prototypes so you can estimate the stories from experience”. La risposta a questa domanda è come Beck conclude il capitolo “Planning Strategy” del “libro bianco”, in cui spiega come XP gestisce il rischio nei progetti per i quali non si ha il tempo di pianificare e valutare le complessità tecniche.
In questa sessione provo a raccogliere la mia esperienza nella valutazione di fattibilità di progetti XP: tutto quello che passa da quando un cliente arriva con un’idea a quando si ha il via per iniziare il progetto. Che potrebbe anche non partire mai.
Condivido con il pubblico sia una strategia di massima (esplorazione, commitment, report), sia le pratiche e gli strumenti che negli ultimi anni ho trovato più utili: mappe mentali, modelli del dominio, piano di rilascio, bozze architetturali e spikes.
Kanban Pizza Game
Il Kanban Pizza Game è una attività che permette di conoscere e sperimentare Kanban.
Simulando il ritmo frenetico degli ordini di una pizzeria userete Kanban per aumentare la produttività e dare più scelta ai clienti; risolvere problemi di code e colli di bottiglia e facilitare le interazioni tra le persone. Tutto questo permetterà di ottimizzare il sistema complessivamente.
Identificherete le assunzioni necessarie all’introduzione di Kanban ed imparerete ad usare le sue tre pratiche base (visualizzare il processo, limitare il WIP, ottimizzare il flusso). Infine capirete come Kanban, ed il suo approccio evolutivo al cambiamento, si applicano allo sviluppo di software.
Il Kanban Pizza Game é stato inventato un anno fa, ma è già stato usato con grande successo in conferenze ed aziende. Il gioco è molto divertente e offre una simulazione complessa che include variazioni del flusso ed un livello di difficoltà progressivo.
Potete trovare altre informazioni qui:
http://www.agile42.com/en/blog/2011/09/23/kanban-pizza-game/
Formato: Workshop
Event Based Modeling
Da quando sono entrato nel trip di Domain-Driven Design e poi di Event Sourcing / CQRS …non modello più come una volta! È possibile affrontare la modellazione di sistemi complessi in maniera alternativa/complementare alle user stories e ricavare informazioni fondamentali per la struttura del sistema, focalizzandosi principalmente sul comportamento anziché sulla struttura dati.
Formato: workshop
English
Italiano