Bene e benvenuti su Geekbar! Nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori e devo dire ultimo episodio che registro in vacanza dovete sapere che come probabilmente già saprete se avete ascoltato le puntate precedenti è morto tutto, è morto il computer che usavo per registrare quindi sono un po' in una situazione di fortuna perché è ancora in vacanza, ma dalla prossima settimana ritorniamo belli, precisi, con il nostro setup di sempre detto questo, io come sempre vi ricordo rapidamente i nostri contatti info@gitbar.it e la mail classica @brainrepo e il nostro handle twitter o x ormai non so più come chiamarlo e devo dirvi una cosa in tutta sincerità io non lo so perché da quando ha cambiato colore ha cambiato logo non mi viene più il tap compulsivo nel telefono io non lo so una quasi depulsione strana non razionale completamente irrazionale fuori dal controllo ma io boh infatti devo trovare una soluzione a questo e quindi vi ricordo il nostro canale ufficiale e insomma quello che utilizziamo per tutto che è Telegram ci trovate su Gitbar, sul gruppo di Gitbar appunto e nulla veniteci a trovare scrivendo semplicemente Gitbar nel vostro client, Telegram preferito vi chiedo solo un attimo perché probabilmente state sentendo la mia figlia che urla urla prima mi sono dimenticato di chiudere la porta.Questo è il bello della diretta in realtà il podcast è registrato ma facciamo finta di niente.Benvenuti su Gitbar il podcast dedicato al mondo dei full stack developer i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Oggi ho un ospite, in realtà lo dico praticamente a tutta la età, però oggi ho un ospite che ci farà vedere un argomento super interessante.Intanto abbiamo una cosa che ci accomuna, perché siamo entrambi italiani e viviamo in Francia.lui vive nella parte figa, dovete sapere che i francesi ci tengono molto, c'è Parigi e poi c'è la campagna, per loro lui vive nella città e io vivo nella campagna, perché tutto ciò che non è Parigi è campagna.Detto a questa fesseria, in realtà la persona che abbiamo con noi è un grandissimo professionista, è founder di Collective Genius, è un professional scrum trainer che lavora tra la Francia e l'Italia.Abbiamo con noi Fabio Panzavolda.Ciao Fabio! Ciao Mauro, ciao a tutti, piacere di essere qua e grazie per avermi invitato.Grazie, grazie a te per aver accettato il nostro invito, anche perché oggi andiamo a parlare di una cosa che tu tratti tutti i giorni, ma che negli ultimi periodi, voi state sentendo un po' dopo l'episodio, però negli ultimi periodi su Hacker News se ne è parlato molto di Scrum, con il famoso post, i vari thread su Reddit "Scrum sucks" e vai giù a dirne di ogni.Iniziamo proprio così, a freddo, Allora, non è da oggi che ci sono i detrattori di Scrum.Tu pensi cosa alimenti questa repulsione da professionista proprio del topic? Bella domanda.L'incompetenza.Se tu usi un martello per tagliarti le unghie probabilmente ti farai male, le unghie non saranno tagliate.Insomma, quindi Scrum è uno strumento che deve essere capito, compreso, usato in modo professionale e se non è fatto così fa più male che bene, proprio come il martello se lo usi per tagliarti le unghie.Quindi, globalmente, penso che i detrattori di Scrum siano persone che hanno sofferto a causa di Scrum.E quindi, ricapisco, io ho iniziato, sono laureato in scienza dell'informazione, il mio sogno era quello di...giocavo molto ai videogiochi, no? Quindi il mio sogno era quello di sviluppare videogiochi, non mi piacevano talmente tanto.Quindi ho fatto scienza dell'informazione, poi mi sono racconto che...È un hook condiviso, io credo che tutti abbiamo iniziato così.Esatto, sì penso, quelli che hanno fatto informatica, molti.E quindi dopo cosa ho fatto? Io ho cominciato come sviluppatore software e ho smesso proprio perché non ho mai sopportato persone che mi dicessero come fare le cose.e il bello che io ho trovato in Scrum è il fatto che libera le persone proprio, cioè ti lascia usare la tua intelligenza, ti lascia usare la tua esperienza per creare software, fra le altre cose, non solo software ma in particolare software.E quindi niente, io penso che i detrattori siano persone che abbiano sofferto perché hanno magari avuto persone sono stati consigliati male, ho avuto manager o persone che non avevano capito bene Scrum, non c'è nulla di peggio di applicare Scrum in modo autoritario o col comando e controllo, non c'è nulla di peggio.Niente, questo è quello che posso dire.Sì, sono d'accordo con te.In In realtà secondo me il vero problema è che Scrum è un framework che di per sé è nato per dire tu adottalo e customizzalo a seconda del tuo use case, non farcelo entrare a forza forzando come dicevi tu i processi o imponendoli.Il problema è che questo, diciamo, avere un piano chiaro di utilizzo di Scrum all'interno di un contesto presuppone che tu abbia conoscenza del contesto e conoscenza di Scrum, cosa che probabilmente non è così comune, perché sì si ha magari conoscenza di alcuni tool framework, ma spesso non si ha profondamente metabolizzato quelli che sono i principi e i valori di Scrum, che in realtà secondo me hanno probabilmente molta più importanza delle cerimonie stesse e dei tool spiccioli.Per cui volevo fermarmi con te un attimo a rivedere quelli che sono i principi fondanti di questa metodologia.Sì, certo, sono d'accordo con te.Allora, in realtà Scrum è molto più qualcosa che riguarda il comportamento delle persone in determinate circostanze.Quindi i fondamenti di Scrum sono due, il Lean Thinking, che viene dell'epoca di Toyota, quindi dagli anni '80.Perché tutto ciò che si fa quando si fa Scrum è rivolto alla creazione di valore e a farne il meno possibile, che sembra un paradosso, ma si vuole cercare di farne il meno possibile, ma poco che si fa deve essere fatto bene e risolvere veramente un problema di un utilizzatore reale.E il secondo principio fondamentale è l'inthinking e l'empirismo.Quindi il fatto che si approcciano le cose facendo.Nel senso che, a priori, quando si usa Scrum, si fa per cercare di risolvere dei problemi complessi, quindi qualcosa che si sta esplorando, si fa dell'esplorazione, L'esplorazione non si può pianificare e quindi il principio fondamentale di Scrum è quello che si fanno emergere le funzionalità o le cose che dobbiamo fare grazie all'esperienza che si fa.Quindi tu parlai di valori prima, per lavorare in questo modo è fondamentale la fiducia fra le persone che lavorano insieme e gli utilizzatori, fiducia e la collaborazione.Io vedo spesso Scrum applicato in silos e molto spesso è uno dei problemi per i quali la gente soffre.Quindi due principi fondamentali, l'inthinking e l'empirismo.Chiaro.Partendo da questi due principi, a livello proprio operativo, cosa rende Scrum più effettivo e dove lo rende più effettivo nella gestione dei progetti rispetto a un approccio waterfall? Scrum non è un metodo di gestione di progetti.Scrum è un framework che è utile per risolvere problemi complessi.Quindi Scrum non è un processo, Scrum è un framework.Quindi dove lo rende più utile? Lo rende più utile in ambienti di lavoro altamente incerti e ambienti di lavoro in cui c'è molto cambiamento, cambiamenti continui, queste cose qui.Quindi, globalmente, se voi siete, state sviluppando un prodotto o siete in un contesto lavorativo che induce un sacco di cambiamenti rapidi e con cose che emergono nel tempo, In questi contesti Scrum vi aiuta un sacco se lo applicate in modo professionale.Proviamo a immaginare il team di Gitbar.Sto provando a immaginare un contesto, realtà Gitbar non si presta molto a questo tipo di ragionamento.Allora, arriviamo in una piccola startup.Come dicevi tu, contesto altamente incerto perché si fa pivot due giorni su tre, fondamentalmente, come ormai sappiamo.Adesso sto esagerando, però il pivoting è un'attività abbastanza comune.Abbiamo un piccolo team.Cosa porta, tu hai detto, Scrum è un framework, non ragione in termini di processi.Allora, qual è la parte di framework e la parte di processi in questo piccolo team? Aiutaci proprio a capire cosa va sotto il cappello più generale della Gile e cosa va dritto dritto su Scrum.Il cappello generale della agile è il manifesto agile, quindi persone e interazioni piuttosto che processi e strumenti, process and tools, collaborazione col cliente piuttosto che contrattualizzazione, quindi questo è l'agile manifesto e questi sono i principi agile.Un altro dei principi agile è quello di, che ne ho parlato prima, è ottimizzare il lavoro non fatto, quindi questo è proprio uno dei principi agile.Si vuole massimizzare, ottimizzare il lavoro non fatto.Poi c'è Scrum.Scrum è uno strumento, parlavo prima del martello, Scrum è uno strumento che ha...il martello è utile se devi piantare un chiodo.Scrum è utile se tu devi risolvere un problema per il quale non hai nemmeno la soluzione.Faccio un esempio, spero di non perdermi, se mi perdo me lo dici perché a volte va parto in sì sì tranquillo per strade strane faccio un esempio io ho aiutato adesso non so se mi ascolteranno ma ho aiutato dei ragazzi una startup proprio di Bolzano che fa droni e questi ragazzi quando hanno inventato questo drone l'hanno inventato perché passeggiavano in montagna avevamo visto che c'era un elicottero che portava dei tronchi d'albero adesso non so se è proprio è così la storia, più o meno è così la storia, portare dei tronchi d'albero, hanno detto, ma perché invece di usare un elicottero che usa benzina non usiamo un drone cargo che porta l'albero, il pezzo di albero, eccetera.E questi ragazzi hanno quindi inizialmente pensato che il drone cargo poteva fare sto lavoro qui.Ma in realtà questo è un buon esempio perché il drone cargo non è per adesso qualcosa di super utilizzato, Quindi questi ragazzi non sanno neanche chi sono i loro potenziali clienti.E quindi devono fare degli esperimenti.E è proprio questo il senso di Scrum.Nel senso che molte persone, se noi pensiamo al software, purtroppo hanno l'abitudine di dire, vabbè, dobbiamo fare un software, quindi pianifichiamo.Pianifichiamo tutte le feature dei prossimi...Ma anche del prossimo mese, dei prossimi due mesi.Pianifichiamo tutto.Perché si vuole cercare di controllare le cose.ma in realtà Scrum è qualcosa che ti permette di far emergere le cose.Quindi facciamo emergere un prodotto, per esempio questi ragazzi pensavano di usare il drone per sostituire l'elicottero, si sono accorti che in realtà l'elicottero non lo puoi sostituire, perché adesso hanno dei percorsi pianificati, super ottimizzati per tutto, e adesso usano il drone come una gru.Cioè invece di usare delle gru, chiamano il loro drone, perché la gru ha un raggio limitato dalla lunghezza del suo braccio, invece il drone ha un raggio limitato dalla sua batteria.Quindi questa cosa qui loro non l'avevano pianificata, è venuta fuori.Così, con l'esperimentazione.Quindi la stessa cosa è per il processo.Quando dico che Scrum non è un processo, Scrum in realtà dà ai ragazzi che lavorano nello Scrum Team l'opportunità di creare un processo che evolverà col tempo.Ma cos'è un processo? Il processo è mettersi d'accordo su come si fanno le cose, a che momento, quali strumenti usiamo, ma non è qualcosa che può essere predefinito se risolviamo un problema complesso.Il processo è qualcosa che emergerà insieme al prodotto e che si adatterà nel tempo sempre e continuamente, no? Perché in un contesto di complessità le cose evolvono, Quindi non possiamo avere un processo fisso, il processo deve evolvere.Quindi Scrum fa emergere il processo e potete vedere Scrum come l'impalcatura che a volte si vedono nei palasti, no? Ci sono delle impalcature perché bisogna riverniciare la facciata del palasto, eccetera, eccetera.Quindi Scrum è semplicemente un'impalcatura con delle regole, dei principi e dei valori, ma a un certo punto l'impalcatura la smontate, perché avete capito come potete lavorare in modo empirico.Ok, quindi queste cose qui che sono spesso poco comprese, in ogni caso nella mia esperienza con i miei clienti, sono quelle che fanno la potenza di Scrum.Quindi il processo è qualcosa che emerge nel tempo ed è un miglioramento continuo, esattamente come il prodotto.E Scrum è un framework, quindi un insieme di principi, valori e regole che ci permettono di capire che l'asset principale di uno Scrum Team e l'adattamento al cambiamento.Non so se...Sì, sì, è chiaro.Io che sono uno che si focalizza spesso sui tool, mi chiedo a questo punto, ti ripete che io nel team utilizziamo Scrum, noi nel team utilizziamo Scrum, e mi chiedo come alla fine parte dei tool che mette a disposizione scrum, in qualche modo si sposino nel realizzare questo processo, mi viene in mente, no? Che ne so, il product backlog.Quando io parlo di product backlog penso, ok, il backlog essendo uno strumento adattivo rispetto a un progetto predefinito, uno strumento in continua evoluzione, ci porta in quello che mi hai appena detto.Però allo stesso tempo mi chiedo come per esempio si sposano un altro argomento controverso che sono le stime, che io ho sempre vissuto come una parte di Scrum, nel...sai, un progetto adattivo molto mutevole sembra cozzare con il concetto di stima, no? Quindi mi chiedo come lo strumento per esempio delle stime si sposa nella cornice che hai appena disegnato? Si, bella domanda.Allora il product backlog è un artefatto, non è un tool.Si, correggimi io, devi farlo.Quindi il product backlog è un artefatto, un artefatto in Scrum è qualcosa che rende l'informazione trasparente, quindi quando io prendo un product backlog devo devo capire qual è la strategia del produttore per il prodotto e devo anche capire come lui sta ottimizzando il lavoro non fatto.Quindi, artefatto, prova e clock, rende trasparente l'informazione in modo tale che può essere ispezionata e adattata.Quindi, questo è l'empirismo.L'empirismo è trasparenza, ispezione e adattamento.Le stime, in realtà, in Scrum, non sono...Allora, per quelli che non lo sapessero, Però, quando parliamo di Scrum, il punto di riferimento di Scrum è lo Scrum Guide, che potete scaricare su scrumguides.org.E relativamente alle stime, non c'è scritto niente nello Scrum Guide.C'è scritto che si possono stimare come volete.Quindi, quello che io faccio con i team che aiuto, è dire, già, prima di tutto, ragazzi, fate delle stime come siete abituati a farle.Facciamo così, così, così."Ok, vi sta bene come le fate?" "Sì, ci sta bene." "Allora usate quello che funziona, usatelo." Ma le stime sono attività che vengono ad aggiungersi a Scrum, no? Perché il framework Scrum è qualcosa di minimalistico.Infatti, quando leggete lo Scrum Guide, vedete che nello Scrum Guide c'è scritto che non si può togliere niente da Scrum, perché se togliete qualcosa da Scrum, Scrum non funziona più.però potete aggiungere.E quindi le stime è qualcosa che potete aggiungere alla vostra pratica di Scrum.E quindi fa parte di questo miglioramento continuo del processo.Quindi tante volte, per esempio, io arrivo in team che stimano in ore.Poi a un certo punto abbiamo le nostre discussioni e dico "Ma scusate, cosa vi serve stimare?" Non accercano una! No, sì, poi a cosa serve? nell'ottica sempre del lean thinking, io penso al lean thinking, ma quanto tempo perdiamo a stimare in ore? E a chi serve la stima in ore in realtà? Serve all'utilizzatore finale sapere quante...No! Quindi è tempo perso, tempo che non mettiamo a creare valore, e tempo che impieghiamo solamente per soddisfare il manager ABC.E quindi dico, va bene, allora, ci possiamo incontrare col manager vedere come possiamo fare differentemente per soddisfare lui e passare più tempo a creare valore invece che fare dei calcoli matematici.E quindi molto spesso inizio io le cose così e poi il team prova la soluzione da solo.Quindi ce ne sono che fanno poker planning, ce ne sono che si mettono solo a contare le user story che finiscono alla fine dello sprint.Insomma, ma non c'è un metodo predefinito in Scrum? Assolutamente no.Allora mi viene da chiederti quali sono quegli elementi minimalistici che sono condizioni sine qua non perché stiamo davvero adattando utilizzando Scrum? Sì, è l'impalcatura.L'impalcatura in Scrum è costituita da semplicemente i tre artefatti, quindi product backlog, sprint backlog, incremento, incremento è una nuova versione del prodotto, i 5 eventi di Scrum, che sono lo Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, e le 3 accountabilities, le 3 responsabilità in Scrum, che sono Product Owner, Developers e Scrum Master.Questi sono i blocchi fondamentali di Scrum.Quando avete finito questo qui, avete l'imparcatura.Ma avere solo questa imparcatura qui non è sufficiente, perché se voi avete solo questa imparcatura qui e poi fate del command and control, Non serve a nulla.Quindi questa impalcatura funzionerà in modo ottimale se voi avete capito i valori di coraggio, rispetto, apertura, qual è l'altro? Focus, quindi concentrazione, focus, e coraggio, rispetto, focus, apertura, e impegno, engagement, impegno.Ok? Questi sono i cinque valori.Quindi i cinque valori ci permettono di avere fiducia e di lavorare insieme per risolvere questo famoso problema complesso.Quindi questi elementi fondamentali sono scritti nello scan guide.Chiaro, chiaro.In realtà io avrei tipo un gozziliardo di domande da farti e voglio iniziare da uno degli elementi che tu hai citato come fondamentali, un elemento che io mi ripeto costantemente, vivo, che è il product backlog.Allora la prima domanda è, essendo uno strumento vivo e anche, passami la metafora, un bambino che va educato, perché spesso il product backlog, come si suol dire, se ne scivola e diventa qualcosa di mostruoso.Dalla tua esperienza esistono delle best practice per gestirlo? Allora no perché anche qui vado un po' nel dettaglio ma in un ambiente complesso le best practice non esistono perché se tu hai una best practice vuol dire che quello che devi fare non è complesso no? Devo, torno al mio esempio del il cavolo su qualcosa, devo mettere un quadro nel muro, best practice, prendo un chiodo, un martello, non me lo pianto le dita se possibile, best practice.Ma nel lavoro che facciamo noi, sviluppo software, insomma, le cose sono talmente complesse che la gestione del product backlog dipende dal prodotto che hai, dipende dal mercato sul quale vuoi andare, dipende da tantissime variabili.Quindi best practice non ne ho.Le avessi sarei un charlatano.Quello che ti posso dire però sono quali sono i principi che si possono usare, che io trasmetto ai product owner ai quali faccio coaching, che sono avere un product backlog che riflette la strategia del prodotto, quindi un ordinamento che sia coerente con il product goal.Allora, sì, una cosa che non abbiamo detto in Scrum, funzionava molto a obiettivi, no? C'è un obiettivo che si chiama il product goal, che è un obiettivo a medio termine.E quindi, quando abbiamo questo obiettivo qui, e poi l'ordinamento del product backlog deve avere una coerenza con questo obiettivo.Quindi, coerenza dell'ordinamento del product backlog con l'obiettivo.Le cose che sono in alto nel product backlog sono cose, sono esperimenti, funzionalità, che vogliamo fare perché sono quelle più attese dai nostri utilizzatori.Quindi risolviamo un problema più velocemente o aggiungiamo una funzionalità che fa risparmiare tempo, eccetera.Altro principio è quello di avere gli item che sono più in alto nel prototype log il più piccolo possibile.Funzionalità atomiche, ma veramente piccole piccole, perché il principio di Scrum è che siccome noi stiamo costruendo un prodotto complesso, vogliamo fare dei passettini piccoli, no? Perché se ci sbagliamo possiamo tornare indietro, possiamo cambiare strada.E in ogni caso l'esperimento meno dura è meglio è.Perché abbiamo il feedback prima possibile e sappiamo se stiamo trovando la soluzione giusto o meno.Quindi gli item in alto del front end backlog il più piccolo possibile.Idealmente un paio di giorni, un giorno, un paio di giorni al massimo.E poi dopo quelli sotto, quello che vi pare.La cosa più importante è avere un product owner che ha capito che non si dice sì a tutto, o che non si cerca di soddisfare la persona che grida più forte.Quindi abbiamo veramente bisogno di un product owner che ha capito che la sua accountability è quella di massimizzare il il valore del prodotto.Quindi, quello che io noto spesso in azienda è che purtroppo il product owner è un tecnico e non ha questa libertà nella gestione del suo product backlog.Quindi, ancora prima di andare nei dettagli di come io scompongo il product backlog, lo ordino, eccetera, bisognerebbe lavorare per dare più libertà, più autonomia al product owner in modo tale che possa veramente fare scelte che vadano nell'inthinking, no? Quindi ottimizzare il lavoro non fatto.Poi, ovviamente, dopo, se vogliamo andare nel dettaglio, perché io ho capito che è interessante, è anche opportuno andare più nel dettaglio, la scomposizione del product backlog si può fare secondo, per esempio, il workflow che si sta implementando.Quindi, che ne so, stiamo facendo un'applicazione di banking, stagliuzziamo il nostro product backlog in modo tale che, non so se nel workflow c'è prima di tutto mi loggo nell'applicazione, poi accedo al mio conto corrente, poi che ne so, faccio queste cose qui, lo stagliuzzamento del product backlog si fa per workflow.Un'altra tecnica è quello di fare lo stagliuzzamento del product backlog per crude, quindi le funzionalità di, cos'è, read, update, c non mi ricordo mai, create, quindi update, delete, esatto, quindi facciamo, abbiamo, che ne so, una funzionalità da fare, facciamo prima il create, poi una volta che l'abbiamo finito facciamo il read, poi abbiamo finito facciamo l'update, quindi avere proprio questa coerenza nelle cose che si fanno e una volta perché abbiamo fatto il create, vogliamo ottenere feedback.Questa è una cosa molto importante, perché molto spesso, purtroppo, gli Scrum Team creano degli stock di funzionalità che sono troppo grandi, no? E quando dico stock di funzionalità, vuol dire che voi fate tutto in un colpo, che ne so, 20 funzionalità, magari.Avere uno stock di funzionalità così va contro uno dei principi dell'in, no? perché nel lean lo stock è qualcosa che potenzialmente è inutilizzato, rimane lì, è waste, è spreco.E noi non vogliamo questo spreco.Quindi un team, uno scrum team performante, è uno scrum team che non tiene stock, fa una funzionalità il più rapidamente possibile, va sul mercato con la funzionalità per ottenere feedback.Quindi questo è il principio generale.Poi dopo altre strategie sono per tipo coerenza business.Ci occupiamo di tutta la parte del nostro applicativo che è relativa al marketing.Perché abbiamo questa coerenza col marketing, abbiamo un obiettivo marketing, quindi facciamo l'aggiornamento di tutta la parte marketing.Insomma, quindi queste sono delle strategie che possiamo usare per ordinare e andare avanti nel lavoro col product backing.Domanda invece sugli sprint che sono un altro elemento importante che hai citato prima.Gli sprint sono quel lasso di tempo in cui noi abbiamo tra il… lasciamolo dire con la zappa poi ti prego correggimi… è il momento in cui parte il ticchettio del full focus al momento in cui diciamo ok siamo pronti adesso dateci feedback.Perfetto, sì.Quando si pianifica lo sprint mi è capitato nella mia esperienza di vedere sprint più o meno omogenei all'interno dei contesti.Molte delle critiche che vengono mosse è che la durata dello sprint, che è utilissima per esempio per ragionare in termini di stima, perché è un punto di riferimento quando stimi la dimensione dello sprint, molti dicono che si ha necessità di uno sprint adattivo o comunque di lasti di tempo non così rigidi.Questa è una delle critiche che si muove verso un approccio a sprint rigido.Cosa mi puoi dire di questo? Ti posso dire che se tu decidi di correre una maratona che fa 42 chilometri 195 metri e poi Poi dici, vabbè, cambiamo le regole, facciamo una maratona di 20 km.Perché sono stanco.E non va bene.Quindi, allora, perché vogliamo una durata fissa dello sprint? Perché lo sprint è il cuore pulsante di Scrum.Lo sprint è quella cosa che ci permette di avere una frequenza di ispezione e adattamento regolare, costante.Proprio il cuore, no? Cioè, dà delle pulsazioni.Quindi noi vogliamo diventare sempre migliori in quello che facciamo e abbiamo bisogno di riferimenti.Quindi il fatto di avere, al di là del fatto che la durata dello sprint, ad ogni sprint retrospective il team può decidere di cambiarlo, no? Quindi io quello che osservo in generale è che dopo due o tre sprint troviamo la durata che va bene.E quindi abbiamo questo cuore pulsante E la problematica che in realtà tu esponi è il sintomo di un'incomprensione di Scrum.In generale ci metto due giorni a spiegare queste cose.Confido nella tua dote di sintesi che sono sicuro hai.Anche perché io le ascolterei molto volentieri due giorni di spiegazione.Non voglio rubarti tutta questa tempo.Io sono una passione infinita, quindi per me è un piacere.Dunque, allora, l'incomprensione qual è? L'incomprensione è quella che quando cominciamo uno sprint, noi pensiamo di, almeno non so se è così, ma è quello che vedo più spesso, magari non è così nel vostro caso, o comunque fra le persone che ci ascoltano, però quando iniziamo uno sprint, l'unica cosa fissa, immutabile, che non cambia durante lo sprint è lo sprint goal.Abbiamo detto prima, abbiamo parlato di product goal, abbiamo un altro livello di goal in Scrum, che è lo sprint goal, che è l'obiettivo che ci diamo per lo sprint.È l'unica cosa fissa, tutto il resto è variabile.Quindi, in pratica, cosa succede? Succede che se voi dite "No, no, No, per lo sprint abbiamo queste 5 feature che sono fisse e che dobbiamo finire per la fine dello sprint, altrimenti non siamo stati bravi.Questa è un'incomprensione di Scrum che induce parecchi problemi di debito tecnico, di qualità, perché se arriviamo verso la fine dello sprint e ci manca una use story da fare, magari lo facciamo in fretta per far vedere che funziona, ma creiamo debito tecnico.Però viene detto che ne facciamo 5 e ne abbiamo fatti 5.In realtà, quello che dovete capire, potete fare delle ricerche su internet, è la differenza che c'è fra output e outcome.Allora, l'output è la quantità di cose che facciamo, l'outcome è il risultato.Quindi se io vado in pizzeria e il pizzaiolo mi dice "Io sono capace di fare 30 pizze all'ora", poi quando vai a vedere le pizze sono come quelle che faccio io, nel senso che non sono mai tonde, ci vanno un po' qui in mezzo, eccetera."Ah, cavoli, vabbè, fai 30 pizze, però ne possiamo mangiare due di queste 30, non è che..." Se invece l'obiettivo è fare la pizza che permette al cliente di fargli sognare Napoli, se sono in Francia, per esempio, capite bene che se questo è l'obiettivo, a me non me ne frega niente di fare 52 pizze o una.Dal momento in cui riesco a farne una, buona, come volevo, Sono contento, ho raggiunto il mio obiettivo.Ma dal momento che sono riuscito a farne una, probabilmente nel prossimo sprint avrò capito come ottimizzare, che ne so, il posizionamento dei miei strumenti sul piano di lavoro, mi compro una macchina che mi fa la pasta della pizza invece di doverla fare io a mano.E quindi probabilmente al secondo sprint sarò capace di fare 3-4 pizza così, che fanno sognare.Al terzo sprint ne saprò fare 5-6.Poi a un certo punto arriveremo a un plateau, ci fermeremo.tranne fare degli investimenti.Quindi quello che purtroppo disfunziona in queste team è avere il coraggio, perché spesso sia il manager dietro che non ti permettono di fare queste cose qui, ma avere il coraggio di dire, ok, aspettate, concentriamoci sulla qualità e sull'obiettivo.Poco importa quante feature faremo alla fine.L'importante è che il feedback che ho alla fine dal mio cliente sia un feedback che mi dice, ok, questo va bene, questo cambia, eccetera.E poi concentriamoci a diventare sempre migliori.quindi che cosa ci serve al prossimo sprint per invece di fare una feature farne due e quindi capite che se noi abbiamo questo modo di ragionare non ce ne frega più niente di fare delle stime, non serve più a niente, tempo perso, tempo perso che non dedichiamo a creare valore per qualcun altro, cioè per i nostri utilizzatori.Certo mi viene a questo punto una domanda, come si sposa e se si sposa Scrum in un contesto con delle deadline due date rigide invece? Allora qui c'è un problema, il problema è se tu hai una, perché non mi dice niente la deadline rigida, ok faccio quello che mi pare per la deadline rigida avrai qualcosa ma molto spesso spesso il problema è che hai la deadline rigida con l'efficio fisse e con anche risorse limitate, il budget fisso, quindi sono praticamente mission impossible.Quindi quello che io faccio con i miei clienti in questo caso, in questa configurazione qui, è lavorare perché il problema risale alla la contrattualizzazione col cliente.Qui c'è ancora il manifesto, collaborazione col cliente piuttosto che contratto.E purtroppo nei contratti si mettono la lista di feature.Bisognerebbe fare un esperimento, se potete fatelo, vedrete che vi cambierà la vita, invece di contrattualizzare le feature, contrattualizzate i goal, gli obiettivi.Così vi liberate, fra l'altro ho fatto dei video, credo, un episodio anche io del podcast che parla di queste cose qui, Così vi liberate da questo blocco dovuto al fatto che ho data fissa e feature fisse, perché qui Scrum non vi aiuta, no? Però se voi avete un obiettivo fisso e una data fissa, il vantaggio di avere Scrum è che se voi fate questi cicli di ispezione e datamento continui che si chiamano sprint, ad ogni sprint potete far vedere quello che avete realizzato ai vostri...a quelli per cui lavorate.E il produttore è costretto a fare dell'ottimizzazione del lavoro non fatto.E quindi probabilmente farete qualcosa di più leggero, più light, perché, per esempio, una funzionalità, voi la potete fare con una super interfaccia web mega fica, ma potete fare la stessa funzionalità con un'interfaccia web che è un po' meno fica.Funziona, sarà un po' meno carina, però funziona.Quindi la deadline si può rispettare, l'obiettivo si può rispettare a condizione appunto di non fare la fissazione sul numero e la quantità di funzionalità.In questo caso dobbiamo comunque lavorare anche col team di product design e di prodotto vero e proprio, quindi c'è un collegamento e un confronto continuo, no? ed è appunto una parte che dicevi importante di rivalutazione continua, proprio basata su questo.Volevo chiederti in realtà, proprio perché pensavo al concetto di feature, no? E allora io ho collegato con il concetto basic di storia e di libica, che è un po' il modo in cui noi ci disegniamo quello che poi andremo a fare, cioè non disegniamo perché può ricordare magari mockup o studi di design, ma proprio proviamo a rappresentare in parole quello che proviamo a fare.Quanto delle cosiddette elementi basici di una storia è citato e diciamo è seriamente raccomandato in Scrum? Mi viene in mente un un elemento importante è che mi ha cambiato la vita quando avevo l'azienda e adesso che sono un single contributor.Per esempio io da quando ho ragionato in termini di definition of ready e definition of done, la mia vita è letteralmente cambiata.E quanto appunto questi elementi fanno parte proprio del mindset che si deve avere quando si adotta questo framework.Sì, sì, allora, trasparenza è la parola chiave, no? Perché abbiamo detto che Scrum ci aiuta a lavorare in modo empirico, quindi trasparenza, ispezione, adattamento.La trasparenza è fornita appunto da uno stato dell'incremento, quindi noi arriviamo alla fine dello sprint e abbiamo la nostra nuova versione del prodotto che ha uno stato coerente, stabile, e sfruttabile, potenzialmente rilasciabile in produzione.Quindi la definition of DOM è un pilastro di Scrum.Se...Vabbè, è un pilastro di Scrum.Insomma, ho avuto la fortuna di andare, non sapevo se dirlo o meno, ma ho avuto la fortuna di andare da...A meno, fortuna per me perché sono appassionato e sono stato qui.Di andare da Scrum.org negli Stati Uniti e sono andato dove c'erano gli uffici Ken Schrober, eccetera.E c'è la foto di Ken Schrober che indica "donno" e sorride, con un grande sorriso.Perché lui dice che tutto il punto di Scrum è quello di riuscire a realizzare un incremento funzionante, potenzialmente rilasciabile in produzione, alla fine dello sprint.Se non siete capaci oggi di fare questa cosa qui, Insomma, pensateci.Quindi, DON è assolutamente fondamentale per eliminare l'ambiguità e rendere il tutto trasparente, no? Sappiamo che arriviamo alla fine dello sprint, sappiamo che il nostro incremento è trasparente perché abbiamo fatto tutta una serie di test.Quindi la definition of DON non è altro che tutta una serie di test, che è fatta sul prodotto in generale.Quindi può essere fatta anche sulla documentazione, può essere fatta sulla...Io per esempio in un team avevamo la dimensione dei caratteri, la polisse, come si dice, il tipo di carattere, se traducete il vostro user documentation in più lingue, avere la traduzione che fosse corretta, eccetera.La definition of non sono test, no? Quindi questo è assolutamente fondamentale in Scrum.Per la definition of ready invece c'è una piccola riserva, c'è una parolina proprio nello Scrum BI, non c'è tanto, e la definition of non è un commitment, quindi è qualcosa di proprio forte, no? Che devono rispettare i developers.Invece la definition of ready è proprio qualcosa di piccolo perché potenzialmente è pericolosa la definition of ready perché nella pratica ci si è resi conto che la definition of ready era usata come un contratto che si faceva tra il product owner e i developers, quindi se avevano comportamenti del tipo product owner che dice ai developers "No, mi avevate detto che era ready, quindi io non ne parlo più di questa cosa qui.Non dovreste avere più domande.Quindi la definition of rating è un po' più delicata come cosa.Non deve essere un contratto, non deve essere qualcosa che limita la collaborazione perché sarebbe anti-agile.Io non l'ho mai usata la definition of rating nella pratica.Come però, perché a questo punto la domanda mi viene conseguente, come però si genera quella specie di stimolo il product owner, perché non tutti i product owners sono ninja product owners che ti fanno le storie ben fatte, con gli asset iscritti, riascritti bene.Sai, talvolta ci sono anche dei PO che poco ci manca, che scrivono un titolo e quello basta.E ne abbiamo visti tanti, probabilmente facendo coaching ne avrai visto tantissimi anche tu.Ecco, allora se la definition of ready, come dici tu, è pericolosa, esistono degli altri strumenti per stimolare il PO a metterci cura nella scrittura delle storie, anche perché alla fine sono delle immagini verbali che servono proprio a rappresentare quello che sarà il nostro prodotto, quindi sono uno dei tassellini importantissimi per il backlog? Sì, il vantaggio competitivo o se vuoi la ragione di esistere un prodotto non lo Scrum Team non è quella di scrivere user story.Magari sto scioccando qualcuno ma la ragione di esistere di un prodotto se pensiamo proprio a Scrum fatto in modo professionale e compreso la ragione di esistere un product owner è quella di capire il mercato, di capire il business, di capire come sono messi i concorrenti per poter stargli davanti.Questa è la ragione di esistere di un product owner.Ora, effettivamente purtroppo in molte aziende il product owner, ed è positivo che ci sia perché che è un primo step e poi si evolve, il produttorne scrive user story.Però, se leggete lo Scrum Guide, sempre mi riferisco allo Scrum Guide, nello Scrum Guide c'è scritto che chiunque può scrivere user story, non è il produttorne.Il product owner è l'owner del prodotto e del product backlog.Quindi il product owner deve essere d'accordo per far entrare il nuovo item nel product backlog.Ma chiunque può scrivere user story.Quindi io non ho...Allora, io ho fatto errori, come tutti, all'inizio, che mi hanno insegnato molto.Quindi l'errore che facevo all'inizio era costringere il produttore a usare un certo formalismo per scrivere le sue user story.Ma non funzionava, perché, come dicevi tu, dopo "ah, ma ho troppo da fare", eccetera.Quindi dopo non facevi le cose fatte per bene.Quindi, in realtà, potete usare quello che volete, come formalismo.Dovete proprio avere questo gusto di lavorare insieme, per crescere insieme e magari dire, "Oh, produttore, se vuoi le user story le scrivo io, perché mi sa che le scrivo meglio di te".E la user story non è una specifica.La user story è come un segnalibro.Nel senso che se voi scrivete solo un titolo e capite tutti cosa bisogna fare, poi il principio dell'inthinking è quello di dire, "Ok, ragazzi, questa user story che dobbiamo fare per domani, mettiamoci tutto attorno a un tavolo e cerchiamo di capire bene cosa dobbiamo fare.E quindi, praticamente, tutto quello che è concezione, sviluppo, test, eccetera, si fa tutto insieme attorno a un tavolo.Questo è il principio della collaborazione, no? Quindi sì, non ho strategie particolari, l'unica cosa è che chiunque può scrivere user story, il product owner deve essere d'accordo per metterlo nel product backlog, perché deve aver senso con la sua strategia.E il formalismo, come si scrive, bisogna che venga fuori dal team.Quindi usare le retrospective per dire, "Oh, produttore, qua non capiamo una mazza, quando ci fai le proprie user stories, non è che ci possiamo mettere d'accordo per capirle meglio".Però è super fondamentale parlarsi, quindi la user story non deve tagliare il dialogo, non deve essere uno strumento che limita la collaborazione e il dialogo, altrimenti è un problema.Quindi possiamo dire che in realtà la user story in un mondo ideale è il risultato di un, o comunque nasce anche in un contesto dove c'è un backlog grooming di team che si lavora tutti insieme, è chiaro.Sì sì, certo, può essere un developer che dice "oh ragazzi, siamo dimenticati questo criterio di accettazione, aggiungiamolo", un altro che dice "oh ma qua cambiamo sta parola perché...oppure abbiamo l'opportunità di tagliarla in due, tagliamole in due", è un lavoro di team.E devo dire che in realtà da sviluppatore una cosa che ho trovato molto interessante proprio di queste sessioni dove ci c'è, di questo confronto al di là delle sessioni informalizzate, di questo confronto e che in realtà si andava a creare.Tu hai detto giustamente l'owner del backlog, la responsabilità del backlog sta un po' sulle spalle del product owner, però la responsabilità della storia in un contesto dove questo confronto funziona ed è una cosa bella che ho vissuto è una responsabilità condivisa.E avendo tanti occhi sopra la storia in realtà si riescono a vedere tanti di quegli edge case, la storia di per sé si evolve e diventa molto più precisa, talvolta diventa anche un'epica se ci sono tanti occhi sopra, però diventa talmente talmente dettagliata e talmente precisa che poi alla fine è implicitamente ready.Perché se tutti hanno dato uno sguardo, qualcuno ha trovato qualcosa, sai, 5 per 2, 10 occhi alla fine hanno visto praticamente più o meno quello che c'era da vedere.Poi ci si può sempre aprire a eventuali cose ma comunque si spotta molto di più.Abbiamo parlato di backlog grooming, abbiamo parlato di momenti in cui il team si confronta.Una delle critiche che spesso si fa a Scrum è le sue cerimonie.Le sue cerimonie che vuol dire allocare del tempo nel calendario, vuol dire come diceva qualche manager della mia vita passata, vuol dire che lo sviluppatore non sta programmando ma sta chiacchierando, ascoltando passivamente.Quindi, quello che voglio dirti è, se le cerimonie le si vive in modo effettivo, penso per esempio a una retrospettiva, sono molto utili, ma quali sono gli elementi per fare in modo che ci sia un coinvolgimento generale in questo tipo di cerimonia? Parlo della retrospettiva perché è spesso quella cerimonia dove le persone entrano in modalità standby e tu nelle cam li vedi con led rosso in fronte che guardano Miro.No ma allora, ogni evento in Scrum è proprio al servizio dell'empirismo, no? proprio trasparenza, ispezione e adattamento.Quindi, per me, la cosa fondamentale è che tutti abbiano capito questa cosa in termini di mindset.E quindi quando vedo gente che viene nella retrospettiva, ma insomma viene così in modo turista, effettivamente capisco che io, come Scrum Master, devo fare un lavoro migliore per far capire l'utilità di questa cosa qui.E ci vuole tempo, no? Ci sono persone che ci mettono più tempo di altre.Quindi non ho anche qui la ricetta magica, purtroppo.L'unica cosa che posso dire è che le persone devono capire che il loro contributo è importante per il successo del team.E quindi molto spesso io faccio workshop sui valori.Perché avere gente che viene in modo turista nella retrospective vuol dire, per esempio, non rispettare i colleghi, perché magari c'è qualcosa che non dici o che non fai che avrà pregiudizio già nel prossimo sprint per tutto il team.Quindi è proprio riuscire a creare un team, un collettivo, no, un team proprio, questo gruppo di persone che prova gusto a sfidarsi a diventare migliori.Quindi è proprio un mindset, no? Che non viene dal giorno in due secondi, no? Ci vuole tempo.Perché possa avvenire questa cosa qui? Ci vuole qualcosa che gli americani chiamano psychological safety.Te lo stavo per chiedere, guarda.Era pronta, infatti.Ecco, io sono il primo a non esprimermi in un gruppo di persone se sento che non sono al sicuro.Io sono uno alla base introverso e timido, cioè ce l'ho tutte proprio.E quindi io mi sto zitto se non mi sento… cioè se sento che la mia opinione non è interessante o non interessa a nessuno, o che dico una cosa e poi non mi si ascolta nemmeno, poi smetto di dare la mia opinione.Quindi molto spesso il problema non è la persona che non si esprime.Il problema è il fatto che manca psychological safety e manca quindi una struttura magari di facilitazione che può stimolare questa espressione, insomma il fatto che uno partecipi.E ti dico, non ho regole magiche, io per sei mesi ho lavorato in un team dove c'era una persona che faceva di tutto per mettermi i bastoni fra le ruote e poi non so cosa sia successo, andavamo a correre tutti i mezzogiorni insieme, alla pausa pranzo, e dopo sei mesi questo ha avuto uno sblocco generale e è diventato uno dei più grandi fan di Scrum, ma non ho capito come mai si è sbloccato.Quindi tutto questo per dire che quando c'è il fattore umano, non ci possono essere regole magiche, l'unica cosa è proprio creare un ambiente di lavoro dove la gente può esprimere per esempio con dei cursori, se voi lo fate a distanza potete usare dei cursori che indichino il livello di attenzione che uno ha, perché magari ha un problema col figlio a scuola e quindi ha la testa altrove.Quindi si possono fare questi check-in quando si entra in retrospettiva e poi uno si può anche autorizzare a dire "Oh, se non stai bene, sei stanco, eccetera, perché siamo tutti umani, magari lasciaci un posto, dici qualcosa e poi fai quello che devi fare.Insomma, sono questi tipi di delicatezze che bisognerebbe avere con le persone perché siamo tutti umani e abbiamo i giorni buoni e i giorni meno buoni.È iper fondamentale, per quello che quando a me mi dicono "ah, le formazioni", sì, perché leggere lo Scam Guide che fa 13 pagine va bene, ma cambiare il nostro modo di pensare dopo non so quanti anni di studi facciamo all'università, quanti anni nel lavoro, che abbiamo un modo di ragionare che è completamente sbagliato.È come se noi, se vogliamo risolvere problemi complessi, è come se noi torniamo a scuola guida dopo 30 anni che guidiamo la macchina con la mano sul cambio.Quando andiamo a scuola guida dopo 30 anni che guidiamo con la mano sul cambio, il tipo non ci fa passare l'esame perché ci vogliono le due mani sul volante.Solo che abbiamo talmente l'abitudine di mettere la mano sul cambio che è così.così, la mano sul cambio.Quindi cambiare questo modo di ragionare, di pensare, estremamente richiede molta energia, molto impegno e una voglia di ricominciare in qualche modo un viaggio nuovo, insomma, capito? Da membro del team poi, una cosa che in realtà io sono sempre stato almeno in questi contesti negli ultimi anni un single contributor, quindi vivevo la cosa come membro di un team, come uno sviluppatore, non avevo alcuna responsabilità di tipo manageriale.E mi son reso conto che in realtà il livello di partecipazione, spesso in un team nuovo, aumenta nel momento in cui il tuo contributo, per esempio sulle cose che non sono andate bene, si è trasformato a fine retrospettiva in un action item che è preso in carica.Adesso, non tutte le cose che ci piacciono o non ci piacciono specialmente possono diventare un action item, anche perché c'è il tratto soggettivo, c'è la storia che noi abbiamo, magari abbiamo vissuto in sette team diversi, con contesti differenti, in ambienti, in prodotti diversi, però ecco, il vedere che quello che dici è rilevante ti aiuta, almeno a me in quel contesto mi aiutava a essere più aperto.C'è da dire però che in realtà quando si entra in un team spesso all'arrivo, alla retrospettiva, almeno nelle prime iterazioni, ti viene da dire "e mo che che dico? Fin dove mi spingo? Quanto questo contesto è diverso da quelli dove ho vissuto per cui magari criticare il modo in cui si scrive la documentazione? Quanto sono pichi? Quanto posso esserlo? Ecco, secondo te ha senso, prima della retrospettiva, in qualche modo chiarire questi elementi e dire "si può essere pichi ma non rompere i coglioni", ma per dire, adesso sto banalizzando e sto scherzando, però in realtà la domanda è che il single contributor si pone? Sì, è iper fondamentale comunicare a tutti che ogni idea vale la pena di essere ascoltata.Molto spesso se fai quello che dici tu è un'ottima cosa, nel senso che scrivi l'idea, la metti nero su bianco e la rendi visibile, trasparente, perché è psicologicamente importante.Poi questo fa parte dei valori, nel senso che il rispetto, l'apertura, poi abbiamo il focus, il commitment, questi cinque valori sono fondamentali per per costruire delle relazioni che ti permettono di creare conflitti costruttivi.Se voi leggete il libro di Patrick Lencioni, che si chiama "The five dysfunctions of a team", una roba del genere, in questo libro, che è piccolino, si legge bene, questo libro è la storia di una dirigente che riprende un'azienda, va a capo di un'azienda e si trova con un team di dirigenti che in realtà non è un team, sono delle persone.In questo libro spiega come potete darvi più chance di riuscire in un team se siete capaci di avere fiducia l'uno nell'altro, perché se siete capaci di aver fiducia sarete anche capace di fissarvi dei goal e sarete anche capaci di avere questi conflitti costruttivi che che vi permettono di raggiungere i goal, oppure se non li avete raggiunti, di migliorarli per raggiungerli.Quindi è assolutamente necessario che uno Scrum Team lavori su questi valori.Io faccio due workshop quando arrivo da un cliente.I primi due workshop sono sui valori, il primo, e il secondo è sulla definition of done.Perché è super importante dire che cos'è per te il rispetto, Mauro, che cos'è il rispetto, cosa vuol dire rispetto per me e Fabio, per esempio, perché abbiamo due storie diverse, sicuramente non abbiamo le stesse definizioni.E poi fare quello che io chiamo, come si dice in italiano, la team, non le regole del team, la carta del team, i principi fondatori del team.Quindi ci sarà cosa vuol dire rispetto per Fabio, che cosa vuol dire rispetto per Mauro, ma quindi che cosa vuol dire rispetto per tutto il team.Cosa vuol dire rispettarsi, no? E quindi quando tu dicevi che il manager ti dice "Oh ragazzi, e mi è successo un miliardo di volte, adesso quando volete, se ci vedono che parliamo, quando volete tornare a lavorare, prego, accomodatevi", allora io li guardo e dico "Guarda che stiamo lavorando, eh, e tutto quello che stiamo facendo qui ci farà risparmiare tempo dopo, no?" Quindi è iperimportante avere queste regole di team capire che cosa vuol dire avere rispetto per tutto il team.Sì, non so se ho divagato un po', ma sono assolutamente cose fondamentali da fare quando si lavora in contesti di complessità.No, è chiarissimo e mi trovi d'accordo tipo al 400%, al 500%.Però, ecco, raccontando la storia di quel manager mi stai portando all'ultima domanda perché ho appena guardato l'orologio e il tempo, mamma mia, vola inesorabile.Però questa domanda te la voglio fare perché credo che sia quella un po' più rompiscatole della nostra chiacchierata.Tu sei oltre che un trainer per Scrum Master, sei anche uno Scrum Master, come è ovvio che sia.E una delle difficoltà, immagino, da osservatore più grande dello Scrum Master è quello di spesso far percepire il proprio valore.Perché? Perché l'effetto di un lavoro di questo tipo si vede nel medio e lungo termine, quindi in realtà è come piantare dei semi, però nel contempo devi lavorarti la fiducia da una parte del team, dall'altra del management.Ecco, dalla tua esperienza, ormai sono tanti anni che fai questo lavoro, quali sono gli elementi che se hai un contesto verso gli sviluppatori che nel contesto verso il management ti aiutano a dare un'occhiata, a far dare un'occhiata, a far vedere in proiezione quello che stai generando per non farti dire "beh adesso lavoriamo oppure si adottiamo Scrum ma non abbiamo bisogno di Fabio perché c'è la guide e e ce la caviamo.Sono belle domande.Allora, il metodo di valutazione che dovreste usare per sapere se state facendo un buon lavoro da Scrum Master o meno, sono questi i metodi di valutazione, più o meno, in ordine sparso.Per prima cosa, lo Scrum Team è capace di creare alla fine di ogni sprint un incremento che si addonna e potenzialmente rilasciabile in produzione ma veramente nel senso che io voglio alla fine della sprint review poter ripartire con il prodotto che è stato fatto anche se solo il bottone che tu fa hello world, schiacci su bottone mi scrive hello world ma è potenzialmente rilasciabile no? Quindi questo è il primo obiettivo dovete essere capaci come Scrum Master di aiutare il team a costantemente e systematicamente alla fine di ogni sprint avere un incremento a donna.E questo che abbiate tre sviluppatori o 300 deve essere la stessa cosa.È un po' più difficile con 300.Il secondo metro di valutazione per sapere se uno Scrum Master lavora bene è che le persone sono più felici.Le persone che vengono al lavoro sono più felici.e magari hanno anche più voglia di venire in presenza che di rimanere a distanza.Adesso questa è una cosa nuova che non ho ancora completamente checcato e testato, ma è un po' la sensazione che ho.Anche se io ho fatto tre anni di lavoro a distanza già nel 2015, contavamo i giorni perché alla fine di ogni due sprint ci vedevamo fisicamente, alla fine di ogni due sprint, ogni sei settimane.Quindi le persone sono più felici.Vedete che la gente, quindi i membri della Scrum Team, prendono iniziative senza chiedere permesso a nessuno.Perché questo è segno di ownership.Quindi io, una volta sono arrivato al lavoro con questo team, eravamo in un luogo fisico, arrivo e i ragazzi si sono comprati un timbrino con la data e ogni volta che c'era un nuovo post-it mettevano la data, con il timbro.Ho detto "ma che cacchio fa?" "Eh, così vediamo quando creiamo il post-it e poi ci mettiamo la data quando lo finiamo.E così sappiamo quanto è stato il cycle time per lo sviluppo della..." Sta cosa qui l'hanno inventata...Nessuno ha chiesto niente, ma loro avevano talmente preso questo gusto a capire le loro statistiche, a cercare di diventare sempre migliori, che l'hanno fatto.Questo è un segno che di voi c'è veramente poco bisogno adesso, capiti il miglioramento continuo.Mi fermo qui, io direi che sono queste le tre cose principali, se riuscite a fare questa cosa qui, si sa che state facendo un ottimo lavoro da Scarnazzo.E io dico che con questa frase possiamo andare nel momento tipico e topico del nostro podcast, che è il momento Paese di Balucca.Ah no, aspetta, aspetta, dobbiamo ringraziare i donatori che questa settimana ci hanno supportato per fare in modo appunto che questo podcast potesse raggiungere le vostre orecchie e allora in ordine sparso ringraziamo Roberto Cossu che ci ha invitato una birra, Edoardo Cremaschi che ci ha invitato cinque birre, Davide Cetuloni che ci ha invitato due birre scrivendo anche grazie a Mauro e a tutto lo staff Davide Iabacu, poi abbiamo anche Alessandro Mele che ci offre una birra artigianale sarda, spero una Marduk, grazie per il vostro lavoro Andrea, poi c'è anche il Cavaliere Vesugo che ha finito di ascoltare le 167 puntate di Gitbar quindi si è messo al passo, in realtà ha fatto tipo un binge listening enorme perché sono qualcosa tipo 100-200 ore, una roba del genere, quindi sono davvero tantissime.E' Elis Pelizzari che ci invita a tre birre.Spero di non aver dimenticato nessuno e con questo ci spostiamo nel momento del Paese di Balocchi, in un momento in cui sia i nostri guest che i nostri host e condividono con noi un libro, un talk, un video, una birra, qualunque cosa abbia catturato la loro attenzione e abbiano piacere a condividere con la nostra community.Quindi io a questo punto chiedo a Fabio "Fabio, hai qualcosa da condividere con noi?" Ti conduco nel paese dei barocchi.Ah, il paese dei barocchi.Tante cose.Allora, io penso che, dipende dall'obiettivo che avete, ma un consiglio, se volete capire bene Scrum e se lavorate come Scrum Master, vi consiglio, se non l'avete già fatto, di leggere il libro di Gunther Verheyen che si chiama Scrum e Pocket Guide.Scrum e Pocket Guide è anche disponibile in italiano, nella seconda versione, ma vi consiglio di prendere la terza edizione in inglese.Scrum e Pocket Guide è veramente un piccolo librino che si legge bene, poi per esempio volete leggere solo lo Spring Planning, andate a leggere solo lo Spring Planning, ma è assolutamente fondamentale da mettere a fianco dello Scrum Guide.Poi, una seconda cosa, perché ha avuto un impatto enorme su di me, dovete sapere che ho lavorato 8 anni come project manager, program manager e che sono una persona molto command e control, mi piace controllare la gente.Quindi ho dovuto fare un lavoro pesante, però, quello che vi dicevo, so cosa vuol dire, perché mi sono fatto, insomma, ho cercato di evolvere, no? E non ho ancora finito.Quindi vi consiglio un altro libro, che è quello di Lisa Atkins, che si chiama "Coaching Agile Teams".Lisa Atkins, anche lei era una project manager che è diventata agile coach ed ha un sacco di ottime idee per qualcuno che è command and control e per evolvere verso più della facilitazione, della servant leadership.quindi questo è un secondo libro che ha avuto un impatto abbastanza forte per me e magari vi aiuterà.Purtroppo sono tutti e due in inglese e in italiano c'è un po' un deserto del Sahara, in termini letterari, su Scrum.Beh, aspettiamo il tuo libro allora.No, non so scrivere, non so assolutamente scrivere, quindi mi piacerebbe un sacco.Se qualcuno sa scrivere io non so facciamo qualcosa insieme molto volentieri ma io non so scrivere.Anch'io ho un libro in realtà, io ho anche io due balocchi, il primo è un libro, l'ho letto tanti anni fa in realtà quando ancora avevo la mia azienda e mi occupavo parzialmente di sviluppo software, ma mi ha cambiato completamente il modo di vedere ciò che mi circondava, che è dell'instartup, è tipo un bestseller, però mi ha aiutato tanto a inquadrare un sacco di elementi, quindi ve lo suggerisco.E un'altra cosa interessante in realtà è un podcast, voi ascoltate il podcast, quindi Siete ormai abituati a questo a questo media che è il podcast che Fabio ha pubblicato e che è anche visibile su Scrum.org.Il podcast si chiama Scrum Italian Podcast, Scrum Guide, ed è super interessante e ve lo metto nelle note dell'episodio.Grazie, non volevo parlare di pubblicità, quindi non l'ho menzionato.No, ma siccome io l'ho ascoltato a questo punto e mi è piaciuto tra l'altro, guarda ricordati che condividiamo solo cose che ci sono piaciute e delle quali ci prendiamo anche la responsabilità.L'obiettivo è quello di creare valore sempre per me, quindi cerco di aiutare le persone che non vogliono avere informazione per tante ragioni non possono a prepararsi magari ascoltando cose che sono...Sì, poi per uno che è un auditivo come me è stato veramente veramente utile, tra l'altro devo dire che lo sta utilizzando anche mia moglie per perfezionare un pochino, quindi sì molto figo.Detto questo ho visto l'orologio, promesso ti lascio andare però non ti lascio andare prima di salutarti e di di ringraziarti di esserci venuta a trovare, vi ricordo che il contenuto di questo episodio andrà a finire anche su una card collezionabile che potrete trovare durante il Code Motion Event, quindi ci vediamo là.Fabio, grazie di cuore per essere venuto, mi ha fatto super piacere e poi una cosa ti devo dire, quando qualcuno viene su GitHub, immagina di tornare agli anni '70, ok? E di trovarti la sera davanti a una stazione ferroviaria.Nella stazione ferroviaria sotto nei sotterrani vedi tante persone che ridono, bevono, chiacchierano.È esattamente il circolo del dopolavoro ferroviario.Ecco, Gitbar è un po' il circolo del dopolavoro ingegneristico e di sviluppo software.E cosa succede in questi circoli? Che una volta che entri per farti entrare e ti fanno la tessera.Quindi tu ufficialmente fai parte della famiglia di Gitbar perché sei formalmente tesserato e questo vuol dire che quando ti fa piacere condividere qualcosa con la nostra community o ci sono delle novità o hai qualcosa che ti va, pingami perché c'è sempre una birra fresca, ahimè virtuale, però c'è sempre una birra fresca per te, grazie di cuore.Ok, grazie, grazie a voi, grazie a voi, mi è piaciuto un sacco, grazie, ciao! Ciao Fabio, alla prossima ragazzi ci sentiamo la prossima settimana ciao ciao gitbar il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e con brain repo parliamo di linguaggi e tecniche di sviluppo web di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei full stack dev [Musica] [Musica]
