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