Scrum 🇮🇹

Quando l'Esperto Diventa il Problema | Da Bottleneck a Knowledge SharingTre 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

Il Coraggio di Dire "Non Lo So Ancora" | Forecast Empirico vs Commitment RigidoHai 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 promesseStoria 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)

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 tempoIl 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

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.

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 EssentialsKeywords: Product Owner, prioritizzazione backlog, AI decision making, Scrum, PSPO-AIE, stakeholder management, feature prioritization, transparent criteria, Miro AI, enterprise agile, banking digital transformation

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.7Il 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 GeniusTrainer: Fabio Panzavolta, Professional Scrum Trainer (PST)#Scrum #ProductOwner #Agile #Empiricism #Forecasting

🧪 EPISODIO SPERIMENTALEDopo 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 STORIASara, 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 FORMATOQuesto 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 FEEDBACKDimmi se ti piace. Commenta ovunque mi trovi: LinkedIn, email, messaggi. Se funziona, continuo. Se no, esploriamo altro.🎓 PROSSIME FORMAZIONI PSMSegui 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.

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!

In questo episodio ⁠⁠⁠⁠Fabio Panzavolta⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠,⁠⁠⁠ Professional Scrum Trainer alla Scrum.org e fondatore di ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Collective Genius⁠⁠⁠⁠⁠⁠ ⁠offre spunti di riflessione su come Scrum aiuta a collegare l’Output creato dallo Scrum Team con gli Outcomes sperati per gli utenti del prodotto e, infine, l’impatto sull’azienda. ⁠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!

In questo episodio ⁠⁠⁠Fabio Panzavolta⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠,⁠⁠ Professional Scrum Trainer alla Scrum.org e fondatore di ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Collective Genius⁠⁠⁠⁠⁠⁠ esplora la tematica dello Scrum Master come agente di cambiamento che stimola ed aiuta tutti, in azienda, a migliorarsi continuamente. Leggi l'articolo sul nostro blog Facendolo, gli ostacoli che si presenteranno nel percorso di creazione del prodotto, saranno rimossi. Questa rimozione porterà più business agility: prodotti di migliore qualità, clienti e dipendenti più contenti, più rapidità per andare dall’idea alla produzione. Visita il profilo di ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Fabio sul sito Scrum.org⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠. Segui Fabio su ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠LinkedIn⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠! Vuoi interagire con il podcast, ⁠⁠⁠⁠scrivici⁠⁠⁠⁠, oppure lascia un messaggio vocale!