Scrum 🇮🇹

Collective Genius Italia

Da ascoltare per trovare ispirazione o aiuto nell'applicazione di Scrum Professionale al lavoro. Facilitato da Fabio Panzavolta, fondatore di Collective Genius Italia (www.collectivegenius.it)

  1. قبل ٣ أيام

    Ep. 54 - Quando l'Esperto Diventa il Problema

    Quando l'Esperto Diventa il Problema | Da Bottleneck a Knowledge Sharing Tre team bloccati. Tre Sprint Planning fermi. Tutti aspettano Tommaso, l'unico che conosce l'architettura legacy del payment gateway. Luca, Scrum Master, deve decidere: schedula Tommaso a rotazione tra i team, o fa qualcosa di completamente diverso? Due anni prima, nella formazione Professional Scrum Master, aveva partecipato all'esercizio "The Cindy Problem" che gli aveva mostrato la differenza tra allocare esperti e diffondere conoscenza. In questo episodio scopri: Come riconoscere quando l'"esperto indispensabile" è in realtà un single point of failure organizzativoLa strategia di pair programming intensivo per diffondere knowledge in 3 SprintPerché accettare velocity inferiore iniziale può portare a una maggiore produttività dopo (e team autonomi per sempre)Come convincere team resistenti e stakeholder scettici sul valore del knowledge sharingIl framework pratico per trasformare dipendenza da persona in cross-functional team veroStoria vera. Luca applica i principi di self-management Scrum: da 1 esperto oberato a 7 persone competenti. Risultato: team autonomi, planning da 4 ore a 1 ora, zero attese. Ideale per: Scrum Master, Engineering Manager, Team Lead che hanno "persone chiave" che bloccano tutto quando non sono disponibili. Perfetto per chi viene da culture command-and-control e vuole capire il vero self-management. Durata: 8 minutiLivello: Pratico, con strategia step-by-step applicabileCorso di riferimento: Professional Scrum Master (PSM) 📚 Vuoi padroneggiare questi principi? Prossime formazioni PSM

    ٨ من الدقائق

  2. ١٣ فبراير

    Ep. 53 - Il Coraggio di Dire "Non Lo So Ancora"

    Il Coraggio di Dire "Non Lo So Ancora" | Forecast Empirico vs Commitment Rigido Hai mai promesso una data di consegna precisa sapendo che era più una speranza che una certezza? Alessandra, Scrum Master in una fintech, si trova davanti al CEO che vuole confermare ai regolatori una deadline di 6 settimane. Lei ha tutti i numeri per calcolare. Ma 8 mesi prima, durante la formazione Professional Scrum Master, ha scoperto qualcosa che le ha cambiato tutto. In questo episodio scopri:→ L'esercizio "Bidding the Job" che rivela la trappola dei calcoli deterministici nello sviluppo software→ Perché dare false certezze ai stakeholder è peggio di dire "non lo so ancora"→ Come passare da commitment rigidi a forecast empirici basati su dati reali→ Il framework pratico per aggiornare le previsioni Sprint dopo Sprint→ Come convincere CEO e stakeholder che la trasparenza batte le promesse Storia vera. Alessandra applica l'empirismo Scrum: trasparenza, ispezione, adattamento. Il risultato? Team che lavora a ritmo sostenibile, zero overtime, e un CEO che preferisce forecast onesti a promesse false. Ideale per: Scrum Master, Product Owner, Agile Coach, Team Lead che vogliono smettere di fare stime waterfall e iniziare a fare forecast professionali. Durata: 7 minuti circaLivello: Pratico, applicabile da subitoCorso di riferimento: Professional Scrum Master (PSM)

    ٧ من الدقائق

  3. ٦ فبراير

    Ep. 52 - Il debito che non si vede

    Andrea è Product Owner in una startup fashion tech. Il competitor lancia una feature killer. L'investitore vuole la stessa feature "subito". Il team propone: shortcut in 3-4 settimane, oppure refactor completo in 7-9 settimane. Per 18 mesi Andrea aveva sempre scelto "veloce ora, sistemiamo dopo". Ma i dati non mentivano: throughput crollato da 4 a 2 feature per Sprint (-50%). Lead time triplicato da 10 a 28 giorni. Il 52% del tempo developer andava in bug fix invece di nuove feature. Durante la formazione Professional Scrum Product Owner ha scoperto che il debito tecnico non è un concetto astratto. È empiricamente misurabile nelle flow metrics. Ha mostrato all'investitore quattro grafici con 6 mesi di trend. Ha presentato forecast empirici: con shortcut, lead time sarebbe arrivato a 40-50 giorni in 6 mesi. Con refactor, throughput sarebbe risalito verso livelli sostenibili. In questo episodio scopri: Come misurare il debito tecnico con flow metrics (lead time, throughput, cycle time)Perché il debito si accumula esponenzialmente, non linearmenteIl trade-off reale: throughput oggi vs throughput domaniCome convincere stakeholder con dati empirici invece di opinioniI risultati: lead time da 28 a 14 giorni, bug fix dal 52% al 28% del tempo Il debito tecnico non è opinione. È dato misurabile. Trova sul nostro sito le date delle prossime formazioni Professional Scrum Product Owner (PSPO) #Scrum #ProductOwner #Agile #TechnicalDebt #FlowMetrics

    ١٦ من الدقائق

  4. ٣٠ يناير

    Ep. 51 - Quando i dati ti danno torto (e ti salvano)

    Chiara, Product Owner di un SaaS italiano, era sicura di aver capito perché i clienti se ne andavano: mancanza di funzionalità avanzate rispetto ai competitor. Aveva già la roadmap pronta. Dashboard complesse, grafici avanzati, report automatici. Il team aveva iniziato a lavorare. Poi ha deciso di validare l'assunzione intervistando 20 clienti. E ha scoperto qualcosa di scomodo: il problema era esattamente l'opposto. Non servivano PIÙ funzioni. Serviva MENO complessità. In questo episodio scopri come tre settimane di validazione hanno evitato tre mesi di sviluppo nella direzione sbagliata, cosa hanno detto davvero i clienti, e perché distinguere opinioni da evidenze è la competenza più importante per chi costruisce prodotti. Una storia vera sulla differenza tra pensare di sapere e validare con dati. I principi applicati in questa storia vengono dalla formazione Professional Product Discovery & Validation (PPDV) di Scrum.org.

    ١٣ من الدقائق

  5. ٢٣ يناير

    Ep. 50 - Dalla Politica ai Dati

    Lunedì pomeriggio, ore 16:45. Chiara, Product Owner in una grande banca italiana, riceve il terzo messaggio "urgente e prioritario" della giornata. La Direzione Commerciale vuole pagamenti istantanei. L'IT dice che è un rischio enorme. La Compliance chiede solo feature per normative AML. Tre stakeholder, tre direzioni diverse, tutte incompatibili. Il problema non è nuovo. È così da anni. Le decisioni vengono prese in base a chi parla per ultimo o chi ha più political capital. Non in base a cosa serve davvero ai clienti. In questo episodio scoprirai come Chiara, dopo la formazione PSPO-AIE (Professional Scrum Product Owner - AI Essentials), ha ribaltato completamente il modo di prioritizzare il backlog. Non con magia. Non con autorità. Ma rendendo espliciti i criteri impliciti che tutti usavano senza saperlo. Imparerai: Perché la maggior parte delle battaglie sulla prioritizzazione non sono battaglie sul valore, ma sull'opacità dei criteri decisionaliCome usare AI tools per visualizzare il consensus implicito tra stakeholder con interessi diversiIl framework concreto che Chiara ha implementato: criteri pesati, workshop, scoring trasparenteCome gestire resistenze tipo "non possiamo ridurre decisioni strategiche a un numero"Il cambio radicale nella qualità della settimana di un Product Owner quando smetti di negoziare e inizi a facilitare decisioni trasparentiStoria vera. Contesto enterprise bancario. Risultati documentati. La formazione PSPO-AIE insegna come amplificare le capacità del Product Owner con l'AI, in particolare nella stance "The Decision Maker". Non teoria astratta, ma applicazione pratica su casi reali. Formazione: PSPO-AIE - Professional Scrum Product Owner AI Essentials Keywords: Product Owner, prioritizzazione backlog, AI decision making, Scrum, PSPO-AIE, stakeholder management, feature prioritization, transparent criteria, Miro AI, enterprise agile, banking digital transformation

    ١٤ من الدقائق

  6. ١٦ يناير

    Ep. 49 - Sei Settimane Per Un Miracolo (Che Non Serve)

    Ep. 49 - Sei Settimane Per Un Miracolo (Che Non Serve) Giulia è Product Owner in una fintech. Il CFO le chiede una feature compliance critica in sei settimane. I dati storici del team dicono 6-7 settimane con 70% probabilità, 7-8 settimane con 85% probabilità. Per mesi aveva promesso deadline basandosi su calcoli predittivi ("16 PBI diviso 5 per Sprint = 6.4 settimane"). Poi slittava. La credibilità crollava. Il team si bruciava. Durante la formazione Professional Scrum Product Owner ha scoperto che quei calcoli non sono forecast empirici. Sono Gantt mascherato da Scrum. Ha imparato a comunicare con gli stakeholder usando dati storici, percentili, e probabilità invece di promesse basate su assunzioni. E a aggiornare il forecast ogni Sprint con evidenze nuove. In questo episodio scopri: - La differenza tra approccio predittivo (calcolo matematico) e approccio empirico (probabilità basata su dati storici) - Come analizzare cycle time e throughput per fare forecast realistici - Perché "16 PBI ÷ velocity = X settimane" è waterfall, non Scrum - Come presentare tre scenari con diverse probabilità agli stakeholder - I risultati: progetti on-time dal 25% al 92%, stakeholder satisfaction da 3.8 a 8.7 Il Product Owner empirico non promette date. Comunica probabilità basate su evidenze. --- Trova le prossime formazioni qua --> Professional Scrum Product Owner (PSPO): Info: www.collectivegenius.it --- Podcast generato con voci AI tramite NotebookLM. Contenuti basati su esperienze reali di partecipanti ai corsi Scrum.org. Host: Collective Genius Trainer: Fabio Panzavolta, Professional Scrum Trainer (PST) #Scrum #ProductOwner #Agile #Empiricism #Forecasting

    ١٤ من الدقائق

  7. ٩ يناير

    Ep. 48 - Silenzio, il timebox è apprendimento non scadenza!

    🧪 EPISODIO SPERIMENTALE Dopo un anno di pausa, torno con un test: un podcast interamente generato da AI che racconta una storia vera della formazione Professional Scrum Master. 📖 LA STORIA Sara, Scrum Master da 6 mesi, riceve una richiesta: "Ci servono solo 2 giorni in più per finire il testing". Possiamo estendere la durata dello Sprint? 🤖 IL FORMATO Questo episodio è generato con NotebookLM da Google, basato su eventi reali della formazione PSM. È un test per capire se questo formato può funzionare per raccontare le esperienze della formazione. 💬 IL TUO FEEDBACK Dimmi se ti piace. Commenta ovunque mi trovi: LinkedIn, email, messaggi. Se funziona, continuo. Se no, esploriamo altro. 🎓 PROSSIME FORMAZIONI PSM Segui Collective Genius su LinkedIn! --- Questa è una produzione sperimentale. La storia è vera. Le voci sono AI (tranne intro e outro, registrate da Fabio) L'esperienza che racconta è autentica.

    ١٨ من الدقائق

  8. ٠٣‏/١٠‏/٢٠٢٤

    Ep. 47 - 5 esempi di prodotti falliti: lezioni sulla validazione del prodotto

    In questo episodio ⁠⁠⁠⁠⁠Fabio Panzavolta⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠,⁠⁠⁠⁠ Professional Scrum Trainer alla Scrum.org e fondatore di ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Collective Genius⁠⁠⁠⁠⁠⁠ ⁠⁠offre spunti di riflessione su come l'approccio di Product Discovery e Validation aiuta ad evitare fallimenti eclatanti attraverso 5 esempi! ⁠⁠Leggi l'articolo sul nostro blog⁠⁠ Visita il profilo di ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Fabio sul sito Scrum.org⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠. Segui Fabio su ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠LinkedIn⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠! Vuoi interagire con il podcast, ⁠⁠⁠⁠⁠⁠scrivici⁠⁠⁠⁠⁠⁠, oppure lascia un messaggio vocale!

    ١٣ من الدقائق
مشاهدة الكل (٥٤)

حول

Da ascoltare per trovare ispirazione o aiuto nell'applicazione di Scrum Professionale al lavoro. Facilitato da Fabio Panzavolta, fondatore di Collective Genius Italia (www.collectivegenius.it)

المعلومات

  • صناع العمل
    Collective Genius Italia
  • سنوات النشاط
    ٢٠٢٢ - ٢٠٢٦
  • الحلقات
    ٥٤
  • التقييم
    ملائم
  • حقوق النشر
    © Collective Genius Italia
  • موقع البرنامج على الويب
    Scrum 🇮🇹