Ottimo talk, dal mio punto di vista uno dei più interessanti e costruttivi. Tante informazioni da spendere fin da subito nel quotidiano!
Talk molto interessante ed intenso.
Come dice Emanuele da utilizzare come bignami per approfondimenti.
Se il tuo scopo era questo, well done!
Avevo una "pila" di obiettivi bella alta per questo workshop, qualche messaggio è andato a segno, mentre qualche altro ha avuto qualche difficoltà in più. In particolare, pur essendomi portato tutta una cartoleria da casa, avevo ipotizzato di poter stare al centro, vedendo due o tre gruppi di lavoro. Lavorando nel corridoio avevamo sì a disposizione una lunga superficie liscia, ma i gruppi hanno lavorato più isolati ed io ho perso un po' di visione d'insieme.
Riassumo un po' dei takeaways:
- se vogliamo modellare non c'è constraint che tenga: rotolo di carta e rotolo di scotch e possiamo farlo dovunque.
- i dev "godono" ad speculare su dominii immaginari. L'esperto di domino era presente e tutti i team inventavano cose che non c'erano nel dominio. Le domande all'esperto erano il piano B, o C.
- imporre un ordine dall'inizio può essere una strategia perdente. La prima esplorazione è caotica: prima raccogliamo i dati e poi capiamo che forma hanno. Lo spazio a volte impone dei vincoli, ma a volte siamo noi ad imporli.
- Eventi e Comandi ci permettono di evidenziare dove sono i nodi di comportamento del sistema. I "dati" non sono necessariamente una parte chiave.
- Questo approccio di modellazione va al bacio con DDD, ma è estremamente utile anche come modellazione a se stante. Non di rado si intraprende lo sviluppo di sistemi complessi senza avere chiaro il quadro generale.
- Realizzare un modello complesso può essere decisamente economico. Non lo si fa perché ci vuole troppo tempo. È falso. E capire come funziona esattamente un business si ripaga in tempi estremamente brevi. Quante pagine insensate ci siamo risparmiati?
- Modellare gli aggregati partendo dai dati non è necessariamente una strategia vincente, anzi.
- Ci sono più modelli all'interno del sistema, e più linguaggi. Se rendiamo evidente la possibilità di queste ambiguità la possiamo dominare.
La presentazione è stata molto in linea con le premesse. Sono state esposte idee interessanti (un pochino eretiche ...) ma stimolanti e nella linea del miglioramento continuo. Idee da sviluppare ulteriormente da parte di ciascuno. Molto piacevoli e vive le slides di presentazione.
Forse troppo 'tecnico', qualche parola più ad alto livello avrebbe giovato.
Molto interessante e stimolante come al solito! Non facile però seguire quando il discorso si sposta su Lean Startup.
Case study interessante per chi vuole approcciare alle metodologie agili in contesti "non da manuale"
Grazie Alessio, Giancarlo, Aldo, Antonio e Fabio
Per Giancarlo: sì, i talk erano registrati e la prima track dovrebbe essere pubblicata molto a breve.
Per Antonio: L'intenzione era di partire da "una storia", e legare il più possibile i contenuti all'esperienza reale facendo più esempi concreti (ne avrei voluti fare di più). Avvicinandosi un po' più al limite di un experience report.
Oltre all'aver nominato troppe volte l'azienda e questo punto sopra ci sono altri elementi che ti hanno dato la sensazione di "marchetta"?
Ci tengo anche a sapere il feedback di altri partecipanti su questo punto perché vorrei davvero eliminare questa sensazione.
Per Fabio e Stefano (e i prossimi feedback): visto che avete nominato entrambi la "piattezza", ci tengo a sapere se pensate impatti molto sul riuscire a mantenere l'attenzione del pubblico o comunque non avete avuto tante distrazioni e potrei mantenere lo stile aggiustandolo solo un po'. Prima della presentazione pensavo proprio di aggiungere qualche attività per far partecipare il pubblico.
Il game molto bello, e' la seconda volta che lo vedo, riproporlo in azienda e' un po difficile (2 ore e forse piu)...e' un peccato tralasciare di spiegar per bene teoria e principi per mancanza di tempo o spazio.
Il gioco è stato super ganzo. Siccome immagino che le critiche siano più utili dei complimenti, provo a commentare solo su quel che ho apprezzato meno. Ma non fraintendetemi! Ho trovato il gioco molto bello!
Mi sono molto divertito, ma credo anche perché avevo già sperimentato il Dot Game un paio di anni fa con Alberto Brandolini.
Ho l'impressione che potrebbe non essere stato così efficace quanto quello o quanto altri giochi, per lo meno per chi fosse completamente a digiuno di Kanban.
Voglio dire: il gioco ha offerto moltissii spunti interessanti per chi già conosceva Kanban, ma di per sé non mi pare che offrisse troppi spunti per i novizi perché capissero o introducessero autonomamente i principi di Kanban.
Di fatto, per esempio, era limitato solo il wip del forno (e il limite è stato tolto nell'ultima fase del gioco). Nel Dot Game, una delle condizioni del gioco, ad un certo punto, era proprio "Ripetete il gioco con questo nuovo constraint: limitate il wip e vediamo come cambiano le metriche"). Qui, mi sembra, è mancato lo sperimentare i cambiamenti di metriche in funzione di cambiamenti di constraint.
Suggerirei per la prossima volta di pensare ad una figura dedicata a prendere le misure: era abbastanza evidente che molti team tirassero fuori dati poco affidabili; avrei trovato molto efficace avere, oltre al solo lead time, altre misure altrettanto importanti: uno su tutti "da quando abbiamo abbassato il wip limit, quanto sono diminuiti gli sprechi?"
Rispetto ad altri giochi che ho fatto o visto mi sembra anche che la complessità della produzione in sé (fare la pizza) fosse così alta da condurre a un'azione un po' troppo frenetica, tutto a spese dell'attenzione verso il processo. "Fare la pizza" era così faticoso che davvero mancava il tempo per pensare ad azioni come "individua il collo di bottiglia", "proviamo a untrodurre un controllo di qualità".
In altri giochi la produzione è così banale che tutta l'attenzione del team può essere dedicata al miglioramento del processo, il che mi sembra didatticamente più efficace.
L'impressione, infine, è stata che il gioco spingesse più ad una competizione tra team piuttosto che a una tensione verso il miglioramento del proprio processo.
Io, ripeto, mi sono divertito da morire. Ma forse anche perché mi sono trovato in squadra con diverse persone già esperte di Kanban.