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. 20 feb

    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

    8 min

  2. 13 feb

    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)

    7 min

  3. 6 feb

    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

    16 min

  4. 30 gen

    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.

    13 min

  5. 23 gen

    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

    14 min

  6. 16 gen

    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

    14 min

  7. 9 gen

    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.

    18 min

  8. 03/10/2024

    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!

    13 min
Elenco completo (54)

Valutazioni e recensioni

4,3
su 5
3 valutazioni

Descrizione

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)

Informazioni

  • Creatore
    Collective Genius Italia
  • Anni di attivitĆ 
    2022 - 2026
  • Puntate
    54
  • Classificazione
    Contenuti adatti a tutti
  • Copyright
    Ā© Collective Genius Italia
  • Sito web del podcast
    Scrum šŸ‡®šŸ‡¹