Podcasts about Agile

The Future of Scrum: What Will Agile Look Like in 2030?Agile methodologies, particularly Scrum, have dominated the software development and product management landscape for decades. However, as technology advances and workplace dynamics shift, Agile is evolving rapidly. By 2030, Scrum will be unrecognizable from its early iterations. Here's how it will transform...How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

In this episode, Josh and Bob challenge the growing obsession with artificial intelligence and mechanical leadership “frameworks” by reminding us what matters: leading humans like a human. They unpack what authentic high-performance leadership looks like and how showing genuine care for people is still the most powerful management tool you have. Instead of passing leadership responsibilities on to checklists or algorithms, the hosts lay out a bold reminder — real leadership comes from connection, courage, and empathy. Stay Connected and Informed with Our NewslettersJosh Anderson's "Leadership Lighthouse"Dive deeper into the world of Agile leadership and management with Josh Anderson's "Leadership Lighthouse." This bi-weekly newsletter offers insights, tips, and personal stories to help you navigate the complexities of leadership in today's fast-paced tech environment. Whether you're a new manager or a seasoned leader, you'll find valuable guidance and practical advice to enhance your leadership skills. Subscribe to "Leadership Lighthouse" for the latest articles and exclusive content right to your inbox.Subscribe hereBob Galen's "Agile Moose"Bob Galen's "Agile Moose" is a must-read for anyone interested in Agile practices, team dynamics, and personal growth within the tech industry. The newsletter features in-depth analysis, case studies, and actionable tips to help you excel in your Agile journey. Bob brings his extensive experience and thoughtful perspectives directly to you, covering everything from foundational Agile concepts to advanced techniques. Join a community of Agile enthusiasts and practitioners by subscribing to "Agile Moose."Subscribe hereDo More Than Listen:We publish video versions of every episode and post them on our YouTube page.Help Us Spread The Word: Love our content? Help us out by sharing on social media, rating our podcast/episodes on iTunes, or by giving to our Patreon campaign. Every time you give, in any way, you empower our mission of helping as many agilists as possible. Thanks for sharing!

Tom Marotta of The Spaceport Company joins me to talk about the executive order this week focused on commercial space regulatory reform, what problems it seeks to solve, his experience on both sides of those issues, and how we should understand the positioning of the order.This episode of Main Engine Cut Off is brought to you by 34 executive producers—Frank, David, Jan, Josh from Impulse, Steve, Ryan, Joakim (Jo-Kim), Lee, Creative Taxi, Theo and Violet, Fred, Pat, Donald, Better Every Day Studios, Stealth Julian, Bob, The Astrogators at SEE, Russell, Joel, Tim Dodd (the Everyday Astronaut!), Matt, Natasha Tsakos (pronounced Tszakos), Kris, Warren, Heiko, Will and Lars from Agile, Joonas, and four anonymous—and hundreds of supporters.TopicsTom Marotta | LinkedInThe Spaceport CompanyPrevious appearance: T+259: Tom Marotta, The Spaceport Company - Main Engine Cut OffEnabling Competition in the Commercial Space Industry – The White HouseTrump Issues Executive Order on Commercial Space – SpacePolicyOnline.comThe ShowLike the show? Support the show on Patreon or Substack!Email your thoughts, comments, and questions to anthony@mainenginecutoff.comFollow @WeHaveMECOFollow @meco@spacey.space on MastodonListen to MECO HeadlinesListen to Off-NominalJoin the Off-Nominal DiscordSubscribe on Apple Podcasts, Overcast, Pocket Casts, Spotify, Google Play, Stitcher, TuneIn or elsewhereSubscribe to the Main Engine Cut Off NewsletterArtwork photo by NASAWork with me and my design and development agency: Pine Works

Somya Mehra: When Technical Expertise Becomes Product Owner Micro-Management Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Clear Communicator and Dependency Master Somya worked with an exceptional Product Owner on a project with multiple team dependencies. This PO excelled at clear, direct communication with both stakeholders and the team. They were proactive in stakeholder communication and maintained strong focus on what was needed and why. Their backlog management was exemplary, creating proper epics with comprehensive information including dependencies, enabling the team to easily know who to contact. This approach led to a much more motivated team. The Bad Product Owner: The Technical Micro-Manager Somya encountered a technically strong Product Owner whose knowledge became a liability. While technical strength can be beneficial, this PO used their expertise to control the team, telling developers exactly what solutions to implement. Initially, developers accepted this direction, but it escalated to every feature and task. The developers became uncomfortable voicing their perspectives, creating an unhealthy dynamic where the PO's technical knowledge stifled team autonomy and creativity. Self-reflection Question: How do you help Product Owners leverage their technical knowledge without falling into micro-management patterns? [The Scrum Master Toolbox Podcast Recommends]

“Agile isn't about following the rules. It's about delivering real value together.” In this episode, host Rebecca Kalogeris speaks with Jenny Martin, seasoned facilitator, coach, and creator of the OOPSI framework. While Agile has transformed software development over the past two decades, many organizations struggle to scale it effectively or to see the benefits they were promised. Jenny explains why so many teams fall into the trap of focusing on ceremonies and tools instead of the principles that actually drive results, like collaboration, value delivery, and rapid feedback. She introduces OOPSI—short for Outcomes, Outputs, Process, Scenarios, Inputs—a lightweight, non-prescriptive framework that helps teams break down complex problems, align on value, and accelerate delivery. Jenny shares how OOPSI can resolve common Agile pitfalls like “water-scrum-fall,” where work still flows through waterfall-style handoffs despite sprint-based development. If your teams don't understand user stories, are unclear on priorities, or struggle to collaborate across functions, this conversation offers a practical path to restoring focus, alignment, and energy in Agile. For show notes and more resources, visit: pragmaticinstitute.com/resources/podcasts Pragmatic Institute is the global leader in Product, Data, and Design training and certification programs for working professionals. Learn more at pragmaticinstitute.com.

Somya Mehra: Why Collaboration Should Be Your Team's Primary Goal Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Unlike technical roles where success is tangible, Scrum Master success can be harder to measure, especially for those transitioning from tech roles. Somya defines successful Scrum Master performance through team behaviors: when teams trust and respect each other, and when collaboration becomes their goal. She emphasizes the importance of observing behaviors and discussing them with team members early enough to foster the right behaviors within the team. Featured Retrospective Format for the Week: The 2 Pillars Retrospective Somya recommends the 2 Pillars retrospective format, which she intentionally varies to keep teams engaged and curious. Her core structure focuses on two essential questions: "What went well?" and "How can we improve?" She notices that using the same retrospective format repeatedly leads to team boredom, so she adds variety while maintaining these fundamental pillars. In specific cases, she includes a gratitude section to ensure team members feel appreciated. Self-reflection Question: How do you measure your success as a Scrum Master when the results aren't as tangible as in technical roles? [The Scrum Master Toolbox Podcast Recommends]

In this episode of Building Better Developers with AI, Rob Broadhead and Michael Meloche revisit their earlier discussion on defining ‘done' in Agile – how to stay on Track and Avoid Scope Creep. They explain why “done” must mean more than “I finished coding,” and they show how a shared Definition of Done (DoD) keeps teams aligned and projects on schedule. What Does “Done” Really Mean? In Agile, “Done” extends beyond writing code. It often includes: Passing unit and integration tests Receiving QA approval Deploying to staging or production Updating documentation Securing acceptance sign-off Without a clear, documented DoD, each team member may interpret “done” differently. As a result, projects risk rework, delays, and frustration. “If we ask, ‘Is it done?' we should get a clear yes or no—no ‘sort of' or ‘almost.'” – Rob Broadhead Why Ambiguity Leads to Trouble Michael points out a common problem: a developer finishes their code, marks the ticket as done, and passes it to QA—only for testers to find gaps in the requirements. A login screen ticket might say “Allow users to log in with username and password.” But does that mean: Username is case-insensitive? Special characters are allowed? Do error messages display on failure? If these details aren't defined, both the developer and tester may interpret “done” differently, leading to frustration on all sides. The Link Between “Done” and Scope Creep Rob and Michael agree: unclear definitions open the door to scope creep. Without a firm DoD, features get stuck in an endless loop of revisions: Developers feel QA keeps moving the goalposts. QA feels developers aren't meeting the requirements. Clients think the delivered feature isn't what they expected. Over time, this erodes trust and pushes delivery dates further into the future. Lessons from the Field Michael contrasts two scenarios from his career that highlight the power of a strong Definition of Done. Before an acquisition, his team worked with a crystal-clear DoD. Every ticket had precise requirements, clear acceptance criteria, and well-defined testing steps. As a result, tasks finished on time, testing followed a predictable pattern, and rework was rare. The team knew exactly when work met the agreed standards, and stakeholders trusted that “done” truly meant done. After the acquisition, the situation changed dramatically. Tickets became vague and massive in scope, often resembling open-ended “make it work” directives. Multiple teams modified the same code simultaneously, resulting in merge conflicts, inconsistent results, and unpredictable delivery schedules. Without a clear DoD, developers, testers, and stakeholders all had different ideas of what completion looked like, and work frequently circled back for revisions. The difference between the two environments came down to one factor: a clear and enforceable Definition of done. In the first scenario, it acted as a shared contract for quality and completion. In the second, the lack of it created confusion, wasted effort, and missed deadlines. Building a Strong Definition of Done The hosts outline key components every DoD should include: Code complete and reviewed – Ensures quality and shared understanding. Automated tests passing – Reduces regressions. Documentation updated – Prevents future confusion. Deployment verified – Proves it works in the target environment. Acceptance criteria signed off – Confirms alignment with the original requirements. Pro Tip: Keep your tests fresh—don't just update them to pass without meeting the real requirement. Who Owns the DoD? One person doesn't own the DoD—it's a team responsibility. Product owners, Scrum Masters, and developers should collaborate to create and update it, reviewing it regularly to adapt to evolving project needs. Making “Done” Part of the Process Once defined, your DoD should be visible and integrated into your workflow: Add it to user stories during sprint planning. Track it in tools like Jira, Trello, or GitHub. Use workflow stages that match your DoD steps—coding, testing, review, deployment, and sign-off. Michael emphasizes that personal accountability matters just as much as team accountability. Great developers hold themselves to the DoD without needing reminders. Your Challenge: Define “Done” This Week If your team doesn't have a documented Definition of Done—or if it's been more than three months since you reviewed it—set aside time this week to: Write down your current DoD. Identify where ambiguity still exists. Get agreement from the entire team. Update your workflow so that every ticket must meet the DoD before it is closed. This single step can prevent months of wasted effort and ensure your work delivers exactly what's intended. The Bigger Picture A well-defined DoD is more than a checklist—it's your guardrail against wasted effort and shifting goals. It ensures the final product matches what the client truly needs, not just what was coded. Your Definition of Done is your “why” for each task—it keeps your work focused, aligned, and valuable. Stay Connected: Join the Developreneur Community We invite you to join our community and share your coding journey with us. Whether you're a seasoned developer or just starting, there's always room to learn and grow together. Contact us at info@develpreneur.com with your questions, feedback, or suggestions for future episodes. Together, let's continue exploring the exciting world of software development. Additional Resources Getting It Right: How Effective Requirements Gathering Leads to Successful Software Projects The Importance of Properly Defining Requirements Changing Requirements – Welcome Them For Competitive Advantage Creating Use Cases and Gathering Requirements The Developer Journey Videos – With Bonus Content Building Better Developers With AI Podcast Videos – With Bonus Content

At 9:23 p.m. on April 14, 1953, the crew aboard a U.S. Navy patrol plane conducting a classified ELINT (Electronic Intelligence) operation during Korean War had an unsettling encounter with the unexplained. Moving silently through the air at nine thousand feet, the aircraft initially noticed a light in the distance that appeared to be signaling to them using Morse Code. Over the hour that followed, the crew found themselves in the middle of a strange series of engagements that could only be interpreted as an aggressive display toward their aircraft by objects of unknown origin.  This week on The Micah Hanks Program, we explore this little-known Cold War-era incident involving a U.S. Navy spy plane's classified mission that led to an aggressive encounter with unidentified aerial phenomena, as well as its implications to the history of the subject and similar military encounters then and now.  Have you had a UFO/UAP sighting? Please consider reporting your sighting to the UAP Sightings Reporting System, a public resource for information about sightings of aerial phenomena. The story doesn't end here... become an X Subscriber and get access to even more weekly content and monthly specials. Want to advertise/sponsor The Micah Hanks Program? We have partnered with the AdvertiseCast to handle our advertising/sponsorship requests. If you would like to advertise with The Micah Hanks Program, all you have to do is click the link below to get started: AdvertiseCast: Advertise with The Micah Hanks Program Show Notes Below are links to stories and other content featured in this episode: ANNOUNCEMENT: Physics of Exotic Propulsion with Dr. Matthew Szydagis - Society for UAP Studies  NEWS: Google Search Ranking Volatility Shakes Up This Weekend  OpenAI will not disclose GPT-5's energy use. It could be higher than past models  1953 UAP REPORTS: UFO Reports and Documents from 1953 - Project 1947  UFO HISTORY: The UFO Encyclopedia - By Jerome Clark, et al  PROJECT BLUE BOOK: US, Project Blue Book - UFO Investigations, 1947-1969 BECOME AN X SUBSCRIBER AND GET EVEN MORE GREAT PODCASTS AND MONTHLY SPECIALS FROM MICAH HANKS. Sign up today and get access to the entire back catalog of The Micah Hanks Program, as well as “classic” episodes, weekly “additional editions” of the subscriber-only X Podcast, the monthly Enigmas specials, and much more. Like us on Facebook Follow @MicahHanks on X. Keep up with Micah and his work at micahhanks.com.

Somya Mehra: From Top-Down to Collaborative—Reimagining Organizational Restructuring Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. During a business unit split and reorganization focused on creating smaller teams, Somya and her fellow Scrum Masters were invited to create the new structure process. After hearing feedback that teams felt excluded from previous changes, they decided to include teams in the reorganization process to give them a sense of control. They started by asking top management for constraints, then applied them to see what was possible. They facilitated workshops with Product Owners to divide the product portfolio and determine team assignments, ensuring people felt involved in the change process. Self-reflection Question: When leading organizational change, how do you balance the need for structure with giving teams meaningful input into decisions that affect them? [The Scrum Master Toolbox Podcast Recommends]

In this episode of the Agilists: Aspire and Achieve podcast, host Emily Lint chats with Alena Keck about the realities of leading international teams across the U.S., Europe, and beyond.   About the Featured Guest: Alena Keck is an experienced Transformation Leader who has led complex, enterprise-wide change initiatives across Europe and the U.S.—from building an omnichannel Digital Solution Center at Mercedes-Benz Financial Services USA, driving engineering transformation at Aptiv, and aligning digital strategy and ways of working at Porsche, to heading the Lean-Agile Center of Excellence at Vodafone/VOIS. Her passion: driving purposeful transformation that delivers sustainable value—with people always at the core. Follow her on linked in at https://www.linkedin.com/in/alena-keck/   The Women in Agile community champions inclusion and diversity of thought, regardless of gender, and this podcast is a platform to share new voices and stories with the Agile community and the business world, because we believe that everyone is better off when more, diverse ideas are shared. Podcast Library: www.womeninagile.org/podcast Women in Agile Org Website: www.womeninagile.org Connect with us on social media! LinkedIn: www.linkedin.com/company/womeninagile/ Instagram: www.instagram.com/womeninagile/ Twitter: www.twitter.com/womeninagileorg   Please take a moment to rate and review the Women in Agile podcast on your favorite podcasting platform. This is the best way to help us amplify the voices and wisdom of the talent women and allies in our community! Be sure to take a screenshot of your rating and review and post it on social media with the hashtag #womeninagile to help spread the word and continue to elevate Women in Agile. About our Host: Emily Lint is a budding industry leader in the realm of business agility. Energetic and empathetic she leverages her knowledge of psychology, business, technology, and mindfulness to create a cocktail for success for her clients and peers. Her agile journey officially started in 2018 with a big move from Montana to New Mexico going from traditional ITSM and project management methodologies to becoming an agile to project management translator for a big government research laboratory. From then on she was hooked on this new way of working. The constant innovation, change, and retrospection cured her ever present craving to enable organizations to be better, do better, and provide an environment where her co-workers could thrive. Since then she has started her own company and in partnership with ICON Agility Services serves, coaches, and trains clients of all industries in agile practices, methodologies, and most importantly, mindset. Please check out her website (www.lintagility.com) to learn more. You can also follow Emily on LinkedIn (https://www.linkedin.com/in/emilylint/).

Somya Mehra: How Upper Management Can Destroy a High-Performing Team in Minutes Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. While working as a business analyst at a startup building an exam evaluation product for universities, Somya witnessed a well-functioning team with good collaboration and timely delivery. However, upper management began challenging the team lead and Scrum Master, accusing the team of padding story points. When leadership confronted the team, the tech lead threw the entire team under the bus, breaking all trust. The CEO's declaration that he could detect padding in estimates shattered the relationship between developers and leadership, leading team members to want to leave. Featured Book of the Week: Agile Retrospectives by Larsen and Derby Somya recommends "Agile Retrospectives" by Larsen and Derby because doing Scrum right means doing retrospectives right. As someone who wanted to excel as a retro facilitator, she found this book invaluable due to its excellent reviews and practical examples. The book provides several examples of how to facilitate retrospectives effectively, making it her go-to recommendation for Scrum Masters wanting to improve their retrospective facilitation skills. Self-reflection Question: How do you maintain trust between your team and leadership when management questions the team's estimates or performance? [The Scrum Master Toolbox Podcast Recommends]

In this episode of Grow a Small Business, host Troy Trewin interviews Robyn Djelassi, founder of Impact People Solutions. After a 25-year corporate HR career and a top role at Vinomofo, Robyn launched Impact People Solutions in 2022 to give growing Australian businesses access to top-tier people leadership without the full-time cost. Their flagship service, CPO Connect, embeds a fractional Chief People Officer into your business. Bootstrapped from day one, Robyn has grown the business from a solo consultancy into a cash-positive team of eight. This is a story of building a business on clarity, commerciality, and treating adults like adults. Why would you wait any longer to start living the lifestyle you signed up for? Balance your health, wealth, relationships and business growth. And focus your time and energy and make the most of this year. Let's get into it by clicking here. Troy delves into our guest's startup journey, their perception of success, industry reconsideration, and the pivotal stress point during business expansion. They discuss the joys of small business growth, vital entrepreneurial habits, and strategies for team building, encompassing wins, blunders, and invaluable advice. And a snapshot of the final five Grow A Small Business Questions: What do you think is the hardest thing in growing a small business? According to Robyn, the hardest thing in growing a small business is time. Finding enough of it to get everything done, especially when you're wearing multiple hats as a founder. What's your favorite business book that has helped you the most? Robyn's favourite business book is Who Moved My Cheese by Spencer Johnson. Despite being an oldie, she finds it incredibly relevant and continues to refer to it even today. Are there any great podcasts or online learning resources you'd recommend to help grow a small business? One of Robyn's go-to podcasts for professional development is How I Work by Amantha Imber. She appreciates Amantha's insights on productivity and building habits that stick. What tool or resource would you recommend to grow a small business? Robyn recommends using Microsoft To Do List as a simple yet powerful tool to manage daily tasks. Despite using more advanced tools like HubSpot, she finds this one still does the best job of helping her stay on track and productive. What advice would you give yourself on day one of starting out in business? If she could go back to day one of starting her business, Robyn would tell herself: “Be patient.” Success doesn't happen overnight, and learning to breathe and enjoy the journey is key. Book a 20-minute Growth Chat with Troy Trewin to see if you qualify for our upcoming course. Don't miss out on this opportunity to take your small business to new heights! Enjoyed the podcast? Please leave a review on iTunes or your preferred platform. Your feedback helps more small business owners discover our podcast and embark on their business growth journey.     Quotable quotes from our special Grow A Small Business podcast guest: Good people help good people. Kindness in business always comes back around – Robyn Djelassi You don't need funding to succeed. You need grit, trust, and a hell of a work ethic! – Robyn Djelassi Success is doing the work you love with people you respect, not just chasing numbers. – Robyn Djelassi      

In this episode of Building Better Developers with AI, Rob Broadhead and Michael Meloche revisit one of the most persistent challenges in software projects: scope creep. Using AI prompts, we revisit a past episode on “Mastering Scope Creep: Navigating the Hidden Challenges in Software Development.” In that discussion, we explored what scope creep is, why it happens, and how to prevent it from stalling projects, draining teams, and eroding trust. Today, we're building on that conversation with fresh insights and practical strategies. Listen to the full episode for more real-world stories and practical strategies to keep your projects on track. What Is Scope Creep? Scope creep occurs when requirements change after development begins—often without proper planning or agreement. Rob describes it as “moving the goalposts” for what “done” means. This differs from: Iteration – Evolving requirements after review and delivery. Agile flexibility – Adjusting before a sprint starts, not mid-execution. Uncontrolled changes shift the destination while you're already driving toward it. Scope Creep vs. Feature Creep Michael introduces feature creep—adding extra features—as a related but distinct problem. Feature creep bloats the product, while midstream requirement changes alter agreed-upon work. Both can waste time and resources, but shifting requirements often cause rework and missed deadlines. Why It Happens The hosts highlight common causes: Poorly defined requirements Lack of regular checkpoints Stakeholder indecision or shifting priorities Underestimating the impact of “small” changes Without a process to control evolving requirements, teams risk chasing ever-changing goals. The Impact of Unmanaged Scope Creep Burnout from Endless Adjustments When requirements keep shifting, tasks drag on for weeks instead of days, creating “death march” projects that drain morale. If the definition of done changes mid-task, close the ticket and open a new one. Damaged Trust in Estimates Developers see moving targets, clients see missed deadlines, and both lose faith in estimates and planning. Growing Technical Debt Repeated changes often necessitate quick fixes, making the system more challenging to maintain. Stories from the Trenches Rob recalls a four-week integration project that stretched to nine months due to unclear ownership of data mappings. Michael shares a modular app that was copied into six separate projects instead of being built for reuse. One small change multiplied into six updates—an expensive lesson in poor change control. How to Prevent Scope Creep Expansion Define “Done” Clearly – Every task needs explicit completion criteria. Set Regular Checkpoints – Confirm that requirements remain relevant throughout the project. Separate New Work – Treat changes as new tickets with new estimates. Clarify Ownership – Assign responsibility for every requirement and integration. Challenge “Quick” Changes – Always Assess the Real Impact. Key Takeaways Unmanaged scope creep—or any uncontrolled change—can sink a project. By defining requirements early, revisiting them often, and isolating new work from current work, teams can adapt without losing control. Managing changes well is the difference between a project that adapts and one that never ends. Your Scope Creep Challenge Think about the last project you worked on. Did requirements change midstream? Were there regular checkpoints to confirm priorities? How did those changes impact the timeline, quality, or team morale? This week, choose one active project and: Review its requirements with the team. Confirm whether they are still valid. If anything has changed, document it as a new item rather than altering the current work in progress. By doing this, you'll practice catching and managing evolving requirements before they cause unnecessary rework. Stay Connected: Join the Developreneur Community We invite you to join our community and share your coding journey with us. Whether you're a seasoned developer or just starting, there's always room to learn and grow together. Contact us at info@develpreneur.com with your questions, feedback, or suggestions for future episodes. Together, let's continue exploring the exciting world of software development. Additional Resources Sprint Planning – Setting The Scope A Positive Look At Scope Creep The Importance of Properly Defining Requirements Getting It Right: How Effective Requirements Gathering Leads to Successful Software Projects The Developer Journey Videos – With Bonus Content Building Better Developers With AI Podcast Videos – With Bonus Content

Bret and Nirmal are joined by Michael Irwin to discuss Docker's comprehensive AI toolkit, covering everything from local model deployment to cloud-based container orchestration across multiple interconnected tools and services.

Somya Mehra: Learning to Spot Team Performance Warning Signs Early Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. At the start of Somya's Scrum Master journey, she joined a well-organized and balanced team. However, after two senior developers left the company, the team faced unexpected challenges. Despite hiring new people, velocity didn't improve. Somya discovered that a remaining senior developer had been stepping back and wasn't contributing actively to the team. Through conversations and giving specific tickets to the senior developer, Somya learned valuable lessons about early intervention and communication. Self-reflection Question: How quickly do you address performance concerns with team members, and what signals do you watch for to identify when someone might be disengaging? [The Scrum Master Toolbox Podcast Recommends]

Sarah Elk, Senior Partner at Bain & Company and global leader of its operating model work, brings a clear, pragmatic lens to why so many large-scale change efforts fail to stick. Drawing on decades of advising multinational organizations, she diagnoses the structural and behavioral traps that cause transformations to stall, and shares the disciplines that make change durable.   Elk emphasizes that transformation is not a one-off program but an enduring capability that must be “led from the top and embedded in the culture.” She cautions against outsourcing responsibility to a program office: “If the CEO is not leading it and the leadership team isn't engaged in the change, you might get something done, but it will erode quickly.”   Key Insights from the Conversation: Clarity on Non-Negotiables Many failed transformations lack a shared definition of the “non-negotiables” in the new operating model. Without them, execution becomes fragmented. “You have to be crystal clear on what's standard and what's flexible.”   Outcomes Over Activity Successful change efforts anchor to measurable business results, not just activity metrics or generic benchmarks. “It's not about hitting 80 percent of a checklist. It's about whether you've moved the needle on the outcomes you care about.”   Leadership Alignment Is a Continuous Process Alignment isn't built in a single offsite; it requires ongoing dialogue, joint problem-solving, and confronting decisions that challenge entrenched interests. “You need the leadership team acting as one—every week, every month—not just at the kickoff.”   Manage Change Fatigue Overloading the organization erodes momentum. Sequencing initiatives and celebrating visible early wins tied to strategy helps sustain energy. “People get tired. You have to show progress and give them space to breathe.”   Governance, Incentives, and Talent Must Evolve Together Elk warns that without parallel changes to systems and structures, “behavior will revert to what it was before.”   The discussion reframes transformation from a high-profile event into a muscle organizations must build and maintain. For executives seeking change that endures beyond the initial push, Elk offers a blueprint grounded in operational rigor, leadership accountability, and cultural realism.   Get Sarah's book here: https://shorturl.at/Tyotz Doing Agile Right: Transformation Without Chaos   Here are some free gifts for you: Overall Approach Used in Well-Managed Strategy Studies free download: www.firmsconsulting.com/OverallApproach   McKinsey & BCG winning resume free download: www.firmsconsulting.com/resumepdf   Enjoying this episode? Get access to sample advanced training episodes here: www.firmsconsulting.com/promo

What does great leadership look like?In this episode, Josh and Bob unpack their personal, hard-earned list of what truly defines a great leader — beyond the metrics, beyond the titles, and way beyond the fluff. From building resilient, high-performing teams to owning mistakes, speaking truth to power, and knowing when to be patient (and when to push), this is a no-BS breakdown of how to measure leadership that matters.This isn't theory. It's lived experience — the stuff you feel when you're around a real leader… and the gaps you notice when one's missing.Whether you're trying to grow into a leadership role, assess your own growth, or just want to build something better — this episode gives you the unfiltered playbook. Stay Connected and Informed with Our NewslettersJosh Anderson's "Leadership Lighthouse"Dive deeper into the world of Agile leadership and management with Josh Anderson's "Leadership Lighthouse." This bi-weekly newsletter offers insights, tips, and personal stories to help you navigate the complexities of leadership in today's fast-paced tech environment. Whether you're a new manager or a seasoned leader, you'll find valuable guidance and practical advice to enhance your leadership skills. Subscribe to "Leadership Lighthouse" for the latest articles and exclusive content right to your inbox.Subscribe hereBob Galen's "Agile Moose"Bob Galen's "Agile Moose" is a must-read for anyone interested in Agile practices, team dynamics, and personal growth within the tech industry. The newsletter features in-depth analysis, case studies, and actionable tips to help you excel in your Agile journey. Bob brings his extensive experience and thoughtful perspectives directly to you, covering everything from foundational Agile concepts to advanced techniques. Join a community of Agile enthusiasts and practitioners by subscribing to "Agile Moose."Subscribe hereDo More Than Listen:We publish video versions of every episode and post them on our YouTube page.Help Us Spread The Word: Love our content? Help us out by sharing on social media, rating our podcast/episodes on iTunes, or by giving to our Patreon campaign. Every time you give, in any way, you empower our mission of helping as many agilists as possible. Thanks for sharing!

Ever felt the post go live blues?  Ever noticed momentum waning after a deployment?  In this episode we explore ways to improve YOUR growth and success while keeping ServiceNow an engine of innovation in your enterprise.MENTIONED IN THIS EPISODE:The Power of User Councils for your ServiceNow PlatformABOUT USCory and Robert are vendor agnostic freelance ServiceNow architects.Cory is the founder of TekVoyant.Robert is just some guy.Sponsor Us!

Florian Georgescu: How Decision Journals Can Transform Product Owner Behavior Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Humble Learner Florian describes a Product Owner who started from scratch with business knowledge but no PO experience. This exemplary PO demonstrated transparency and engagement in their communication style, showed humility in recognizing knowledge gaps, and actively built strong relationships with the team. They used practical tools like a Product Canvas shared with the team, implemented "Story Time Tuesdays" for informal refinement sessions, and introduced feature learning cards to assess impact and learn from completed work. This PO's success came from embracing the learning journey openly and creating collaborative environments where both they and the team could grow together. The Bad Product Owner: The Command-and-Control Controller Florian encountered a Product Owner who transitioned from 20 years in project management, bringing a command-and-control style that frustrated the development team. Despite having good business and technical knowledge, this PO made technical decisions for the team without allowing input, particularly challenging since they were in a different location. Florian addressed this through a "decision journal" experiment over three sprints, documenting every product decision and analyzing their impact during retrospectives. This approach served as a powerful mirror, clearly showing that technical decisions made without team input produced poor results, ultimately helping both the PO and team recognize the importance of collaborative decision-making. Self-reflection Question: How does your Product Owner balance their expertise with the team's input, and what tools could help improve this collaboration? [The Scrum Master Toolbox Podcast Recommends]

Michael Moreno, VP of Strategy at Lunar Outpost, joins me to talk about what they've been up to at the company, the NASA Lunar Terrain Vehicle Services contract, the idea of services as a business on the Moon, and more.This episode of Main Engine Cut Off is brought to you by 35 executive producers—Lee, Russell, Fred, The Astrogators at SEE, David, Matt, Theo and Violet, Warren, Josh from Impulse, Frank, Pat from KC, Steve, Pat, Creative Taxi, Jan, Stealth Julian, Better Every Day Studios, Kris, Heiko, Donald, Natasha Tsakos (pronounced Tszakos), Joel, Joakim (Jo-Kim), Will and Lars from Agile, Harrison, Joonas, Ryan, Tim Dodd (the Everyday Astronaut!), Bob, and four anonymous—and hundreds of supporters.TopicsHome | Lunar OutpostLunar Voyage 1 Update Lunar Outpost Becomes First Company to Receive Payment for Space ResourcesNASA selects three companies to advance Artemis lunar rover designs - SpaceNewsLunar Dawn Team Awarded NASA Lunar Terrain Vehicle ContractLunar Outpost Signs with SpaceX for Starship Moon MissionThe ShowLike the show? Support the show on Patreon or Substack!Email your thoughts, comments, and questions to anthony@mainenginecutoff.comFollow @WeHaveMECOFollow @meco@spacey.space on MastodonListen to MECO HeadlinesListen to Off-NominalJoin the Off-Nominal DiscordSubscribe on Apple Podcasts, Overcast, Pocket Casts, Spotify, Google Play, Stitcher, TuneIn or elsewhereSubscribe to the Main Engine Cut Off NewsletterArtwork photo by NASAWork with me and my design and development agency: Pine Works

Florian Georgescu: When Teams Embody Agility Without Having To Thinking About It Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Florian defines success for Scrum Masters as achieving teams that embody agility naturally, without conscious effort. He identifies key behaviors that indicate true team maturity: team members openly discuss their needs and how to fulfill them, they embrace constructive conflict as productive and necessary, and developers can communicate with business stakeholders in accessible language rather than technical jargon. This level of success represents the ultimate goal for Scrum Masters – creating self-organizing teams that have internalized agile principles so deeply that they become second nature, enabling authentic collaboration and effective business communication. Featured Retrospective Format for the Week: Naikan Retrospective The Naikan Retrospective, based on a Japanese self-reflection practice, proved invaluable when Florian's team faced a catastrophic release failure during a Champions League game at a sports betting company. This format addresses three key questions: "What have I done successfully for my team?", "What did I get back from my team?", and "How did I support my team in these hard moments?" Despite initial concerns about team acceptance, this retrospective format provided structured relief during high-tension situations, allowed team members to express missing support needs, and created lasting positive impact. The human-centered approach helped the team process failure constructively and build stronger relationships through structured self-reflection. self-reflection Question: What behaviors in your team indicate they're truly embodying agility, and how might you recognize when they no longer need your guidance? [The Scrum Master Toolbox Podcast Recommends]

In this episode of the Scrum.org Community Podcast, Dave West is joined by Darrell Fernandes to tackle questions from a recent webinar on the Agile Product Operating Model and incentives. Together, they explore how incentive models can either support or derail agility.They dig into real-world challenges like misaligned rewards, hero culture, and scaling with private equity influence—offering practical guidance on creating transparent, flexible, and outcome-focused incentives.Referenced webinar - APOM: Aligning Incentives with Value

Florian Georgescu: From Resistance to Effective Change Leadership in Agile Adoption Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Florian shares his transformation from resisting organizational standardization to becoming a champion of strategic alignment. Initially fearing that standardization would stifle innovation and turn agile practices into rigid frameworks, he discovered the bigger picture when he became scrum master chapter lead for 12 scrum masters across multiple locations and cultures. The breakthrough came from implementing a three-level standardization approach: level 1 for non-negotiables, level 2 for encouraged patterns, and level 3 for team-specific innovations. Using the 80/20 principle, they focused on the 20% of standards that would create 80% of alignment. The scrum master chapter became a learning hub where teams could share their level 3 innovations, creating a balance between consistency and creativity that enabled effective cross-tribe collaboration. Self-reflection Question: How might you balance the need for organizational alignment with preserving team autonomy and innovation in your current context? [The Scrum Master Toolbox Podcast Recommends]

#310: In this episode, Darin and Viktor sit down with Tim Beattie, co-founder and CEO of Stellafai, to chat about the myths and realities of DevOps and Agile in today's workplaces. They dive into how DevOps and Agile should be seen more as philosophies rather than just titles on a business card. Tim shares his take on why roles like DevOps Engineer can actually create more silos and how the real goal should be about breaking down those barriers. They also talk about the crucial role of leadership in fostering a safe environment where teams can speak up and innovate. With references to aerospace and software industries, they show how adaptive practices are super important for staying relevant.   Tim's contact information: LinkedIn: https://www.linkedin.com/in/tdbeattie/ X: https://x.com/timbeattie   YouTube channel: https://youtube.com/devopsparadox   Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/   Slack: https://www.devopsparadox.com/slack/   Connect with us at: https://www.devopsparadox.com/contact/

Join Brian and Mike Cohn as they unpack the five essential pillars that take Agile from “just the motions” to meaningful, measurable impact. Plus, get a behind-the-scenes look at their revamped course built for real team transformation. Overview In this episode of the Agile Mentors Podcast, Brian is joined by longtime collaborator and Agile thought leader Mike Cohn for a deep dive into what really makes Agile stick. They explore the five foundational pillars—mindset, practices, roles, teamwork, and support beyond the team—and share stories of what happens when teams get them wrong (like obsessing over story point math or demoing a copyright update in a sprint review). Along the way, they introduce the newly available Working on a Scrum Team public course and explain why it’s designed for entire teams, not just isolated roles. Whether you're new to Agile or knee-deep in transformation, this episode will help you rethink how to build an Agile approach that actually works. References and resources mentioned in the show: Mike Cohn #80: From Struggling to Success: Reviving Agile Teams with Mike Cohn Scrum Team Roles and Responsibilities Working on a Scrum Team Course Mountain Goat Software Certified Scrum and Agile Training Schedule Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection. Auto-generated Transcript: Brian Milner (00:00) Welcome in, Agile Mentors. We're back for another episode of the Agile Mentors podcast. Thanks for joining us. I'm with you, as always, Brian Milner. And today, I have the one and only Mike Cohn back with us. Welcome in, Mike. Mike (00:12) Thanks, Brian. Good to be here. Brian Milner (00:14) Always happy to have Mike on the show and really appreciate Mike making time to come on. Wanted to have Mike on because there's some things Mike's been talking about recently that are really interesting and people have been asking a little bit about this and I thought maybe it'd be just a good opportunity to talk through some of the stuff that Mike's been writing about. I know you spent, Mike, a lot of time helping teams to not just do Agile but to really get solid results from it. to see impact from it. And I know the topic you've been talking about recently is sort of these five pillars of supporting real agile improvements, the mindset, practices, roles, teamwork, and support beyond the team. So I thought maybe we could just dig in and drive through those and maybe learn a little bit about those as we go. Obviously also to talk a little bit about the exciting new course that's being launched here, the working on a Scrum team course, because I know that was originally just for private classes, right? And now it's being open to the public. Mike (01:23) Yeah, we've done working on a Scrum team as a private class for probably 20 plus years. It's been kind of our main offering to private clients. But we're hearing from a lot of people that they have one team and they can't really get a private class approved with the budget and such. So what we're doing is going ahead and making that course available as a public course. So two people from your company, five people from another company all in the same class the way we've done our certified courses for decades. And so we're going to start offering this as a public course. And the exciting thing there is that it's really meant to be a team-based class, where things like Scrum Master training, great class, but it's really meant for the Scrum Master, right? And working on a Scrum team is really designed, and you and I helped you and I design this course together, but it's designed to be something that is a whole team training, right? So good for anybody on a team. Brian Milner (02:16) Yeah, yeah, it's been really great teaching those in the private classes and I'm excited to think about the public being able to come in and take that now. Let's talk a little bit about these pillars and, I think people are gonna be really intrigued by the concept here. The first one is mindset, I think, and just wanna start there and say, what does it actually mean to... think Agile and what is the found, why is that kind of the foundation for successful transformations? Mike (02:43) Remember the kind of the early days of agile and there was a lot of conversation about could you be agile without understanding the principles, right? If you just did the practices, were you agile? Other people were saying, no, you have to start with the principles, right? And so do you start with principles? Do you start with practices? And I remember these early debates and they often devolved into a discussion of the karate kid movie, right? Remember that one, right? And, you know, can you just wax on? Brian Milner (03:12) Ha Mike (03:12) for long enough, just do the practices. And then all of a sudden, your karate instructor or your agile coach is, OK, you're agile. And it's like, wait, all I know how to do is wax a car, right? And so there were these discussions about practices versus principles. And I was kind of always on the side where you better understand the principles to do this. Just knowing the practices, waxing on all day, is kind of just going through the motions. And so you have to understand the principles. And the idea that I wanted was that if a team truly understood all of the principles underneath Agile, I don't just mean just the manifesto, but all the principles that are there from Lean, from Kanban, from everything, that if you really understood those, you'd kind of invent the practices, right? You do those and you go eventually to go, hey, we should probably meet every day. Or hey, if we tested first, that might be a really good thing. Brian Milner (03:57) Yeah. Mike (04:05) So you'd invent the practices if you really had that type of agile mindset. And so for me, when we're working with organizations to get them truly agile, and I don't mean like more agile than less agile, but agile in a way that's going to stick, you got to change mindsets, right? You've got to do more than just the wax on. So people have to get the mindset. Brian Milner (04:27) Yeah, I love that. I know that I've experienced some things in the course of working with people that's it's sort of like you, if you're not on the same page with the principles, then you start to talk through the practices and you run up against a problem. And really what you find out the core of it was, well, we weren't aligned on really the principle behind this. So why would I want the practices then, right? ⁓ Mike (04:49) Yeah. Well, that's where you also end up then with a lot of team debates about things, right? Because you're arguing about the practice. if you'll say you and I are arguing about the benefit of some practice, if we agree on the principle, we might just have different views on it. But deep down, we'll probably agree on some practice, or we might find an alternative one. But if you don't agree on the principles, you end up with a lot more of these kind of annoying. mean, team debates are great. I mean, I love. Brian Milner (04:54) Yeah. Mike (05:12) you know, having a team debate, arguing stuff like that, but not about pointless things, right? And not without some sort of foundation. They just kind of get in the way. It's just frustrating for everybody. Brian Milner (05:21) Yeah. Well, I'm kind of curious, what kind of signs or signals do you think teams should look out for to kind of clue in and let them know that what might actually be going on here is more of a mindset issue? Mike (05:36) think sometimes it's when you hear the appeal to authority, right? Somebody says, you know, well, we got to do it this way because the scrum guide says, right? Or the one that annoys me is we have to do it this way because Mike Cohn says, ⁓ you know, that was like, no, I, somewhere else also said, think, right? Don't just, you know, don't just, you know, blindly do story points or something. Cause I say they're a good thing. I want you to think too. Brian Milner (05:50) You You Mike (06:01) And so I think that kind of appeal to authority when teams are debating things. It's where we also see teams who think they're agile because they do a set of practices. We use a particular agile tool, so we must be agile. We do daily meetings. We must be agile. And those are not the things that make you agile. Those are artifacts of being agile. If you're agile, you're going to meet a lot. You're not going meet a lot, but you're going to talk a lot. Um, and so those are the artifacts of behaving in an agile way. And so I want to understand why we're doing those things. So I look for those kind of appeals to authority. Um, you know, emphasis on that type of stuff in an argument talking about how this is the right way saying there's only one right way to do something. Brian Milner (06:49) Yeah, yeah, that's great. How does working on the Scrum team deal with this? How does that address it? Mike (06:55) Well, one of the things we do, it was actually one of my favorite exercises. We do this exercise at the start of the class where we ask people to kind of map out how the organization talks about certain adsel principles and then how does the organization behave. And so for example, if a company says, people are our greatest asset, and then they treat people like dirt, we've got this kind of problem between what we say and what we do. And so I like to kind of map this out. And so we do this with the principles in the Agile Manifesto. And once we map those out and we start to see things that we say we value, but we don't behave that way, really helps us understand if we've really embraced that mindset. Or are we just doing things because an Agile coach told us to, or a boss told us to, or we did it that way in our prior company. Those are all bad reasons to do something. Brian Milner (07:48) Y eah. So this is great. So I agree. The mindset's really foundational. And there is this symbiotic relationship between mindset and practices, which came first and which comes first, as we talked about. I know a lot of teams get stuck doing Agile, though, in really only name only. So when we talk about practices, what makes the difference between going through the motions? Mike (08:00) Mm-hmm. Brian Milner (08:11) and actually doing things that work. Mike (08:13) Well, practices is kind of our second pillar, right? You have to have the mindset, right? But you also have to have the practices that come from having that mindset. so, again, I try to think of that team on a desert island, right? And they're isolated from the world. They've never talked to anybody, but they have an agile mindset. What practices are they going to invent, right? And I think those are kind of the core practices. We see a lot of problems with as an example, teams that misunderstand sprint planning. And I know when I first started teaching about sprint planning, I'd have a slide up there to have a picture of a sprint backlog. And the sprint backlog listed tasks like code this, design this, test this. And then there were estimates next to code this. It's going to take four hours testing. It's going to take three. And so we were able see all these numbers and think the point of a sprint planning was these numbers. And Even in the early days of this, I was always saying, no, it's not about those numbers. It's about deciding what product backlog items you can pick. if taking a, I don't even want to call it an estimate, but taking a wild guess about, it probably can take four hours to code. If that helps you decide how many backlog items you can commit to, great, put those numbers up there. But it was never about the numbers. And it's one of the most common problems that I see with teams in sprint planning is they get obsessed with How many hours did we bring in? How many points did we bring in? And I remember one team I worked with where we did sprint planning. Having those estimates were helpful for them on their sprint back. They were helping. And we finished the meeting. And we're using Google Sheets in a meeting to do this. We've got a row with the estimates in there. And as we start to wind down the meeting, I deleted that column that they'd spent so much time talking about. They're all kind of pissed off at me. Why'd you delete that? We spent all this time talking about it. I said, because we got the benefit, right? You got the benefit of those numbers. The benefit isn't a week from now remembering that you said five hours, because it's going to take what it takes. The benefit was the discussion that it led to of can we take more or are we already full? So I see teams get obsessed with that. This is one example, but that's one of the problems with sprint planning as a practice. Brian Milner (10:25) Yeah. Yeah. I think you're absolutely right. And that's one of the things I know I've talked about with people going through the course is sort of understanding the purpose behind the things. Just going back to, know, harkening back to what you said about, don't just do it because someone told you, you know, understand why the purpose behind it. And, know, otherwise we, I'm sure we've all had that experience before where someone just tells you to do something and says, you know, why? Cause I told you so, you know, that, that doesn't, that's not very convincing. Mike (10:52) Thanks, Mom. Brian Milner (10:53) Right, right, thanks mom. Yeah, not very convincing, but it's much more convincing when they can tell you, well, no, you do this because this is what we're trying to do. And I think you're right, that makes all the difference there. ⁓ Mike (11:05) It just, don't know anybody that responds well to being told what to do, right? My instant reaction is no, right? mean, you it could be, you know, a really, you it could be a really good thing. Eat more vegetables, you spend more time outside. No, right? Don't tell me what to do. So. Brian Milner (11:09) Right. Right. Yeah. It's almost like our default response is no until you convince me. Are there other common practices? We talked about sprint planning. Are there other kind of practices you see teams struggle with? Mike (11:28) Yeah, yeah, for a lot of people. think a huge one is product backlog refinement. I don't know what a better word would be than refinement. refinement is about making the backlog better. It's not about making it perfect. And I see teams that get stuck on backlog refinement and feel like they have to resolve every open issue, that everything has to be tiny and answered and buttoned up before we can start a sprint. And that's not the case. For me, the goal in refinement is to make sure things are small enough and sufficiently well understood. I don't want to bring in a backlog that's bigger than my velocity. If our velocity is 25, I don't want bring in a 50-point story. how about the problems of a 50-point story anyway? But I don't want to bring in some massive epic like that into a sprint. And so refinement is about making it small, making sure it's sufficiently well understood. Sufficiently well understood, not perfectly. And so Brian Milner (12:18) Yeah. Mike (12:28) The problem is these teams, and I know you've seen this, but teams who get in there, want to resolve every open issue. It's like, no, we can resolve that during the sprint. If we think about the goal and planning to make sure we know what to bring into the sprint, not too much, not too little, we're fine just enough that you're at that point. Is the button blue or red? Who cares? If it's a log in story, we're going to lock people out after some number of failed attempts. Who cares how many? Figure that out during the sprint. If it's five or three or eight, who cares? Figure that out later. So I think refinements won. Another big one would be reviews, ⁓ where sometimes teams demo too much in a sprint review. And they feel like they have to justify their existence, show everything you did during the sprint. And the most egregious example of that was this was a handful of years ago. But I literally remember a team showing Brian Milner (12:58) Yeah. Yeah. Mike (13:18) how they had updated the copyright notice on the footer of the web page, know, copyright, you know, whatever year our company, right? And it's like, my God, you didn't need to show that to stakeholders, right? We all either know there's a copyright notice on the bottom of the web page or we've seen one before. I don't need you to bring it up and scroll down to it. Now only took 15 seconds of the meeting, but that was 15 seconds of people's lives. They were never going to get back. you know, show stuff that you need feedback on, right? If you'd... Brian Milner (13:41) Right. Mike (13:45) You fixed a bug and you fixed it only way it could be fixed. Mention it perhaps, but you don't need to show it, right? Brian Milner (13:51) Yeah, yeah, know teams I've been on often it's just it's suffice it to have a list sometimes and just say here's a list of things if you want to know more about these come talk to us but we're move on to the stuff you care about. Mike (14:02) Yeah, I always have like a will show, will not show list. you know, I often, if I'm writing the meetup present, that'll put that up on Zoom or, you know, show it on a screen if we're in person. And often somebody wants to see something that's on the will not show list. Or they just want me to describe what bug was that again? What was that? You know, and I'll explain it really quickly. But if nobody wants to see it, don't bother showing it. So. Brian Milner (14:26) Yeah, I know we talk about these scrum practices quite a bit in the working on the scrum team class, but if someone signed up to take this class, what can they expect to hear or what can they expect to learn about these practices in the course? Mike (14:39) Well, I think one of the things that you and I did together in creating the newest version of the course was to look at what do you actually need to practice doing, and it's feasible to practice doing in a classroom setting, versus what should you just kind of talk through. And not everything needs to be practiced to get the hang of it, right? Everybody in the world has taken something big and split it up into smaller things before, right? I need to make. spaghetti dinner tonight. What do need to buy? Right? OK. Well, that's that's that's test decomposition by noodles, by sauce, by tomatoes. Let's make it from scratch. Right. By some garlic. Right. So everybody in the world has done decomposition. We've broken a big thing into small things. And I remember, you know, iterating over I'm still on sprint planning, I guess. But I remember iterating over exercises in sprint planning and in courses over the decades by now. And I would have one where you're planning a party for your kid, break it down into tasks. It's like, nobody learns anything from this. And so that's one where I'd rather say, OK, this problem occurs in sprint planning. How could you solve it? Other things like, let's say, splitting user stories or splitting job stories, that's a skill worth practicing together, getting feedback on. And so those type of things we try to practice in the course. other things we just talk about. mean, I'm curious on your thoughts on that. What do you think about some things being worth practicing, some things worth being better talked about? Brian Milner (16:01) Yeah, I agree. I agree fully. it's, it's, you know, there's some things, it's kind of like what you said before, there's some things that's not worth spending the time on, and it's better to just have a discussion and move on. Mike (16:13) Yeah. Yeah. I guess that's one of the things we always talked about. We always talked about return on investment of the exercise. What's the return on the exercise? And if you're going to have a one hour exercise, cool. One hour exercise. But it better have a pretty healthy return because that's a lot of time in class. And so what's the return on exercise? Is this worth a practice? Is it worth just a discussion? And if we can discuss two hard problems and give people advice on two common problems, they're probably going to face. Brian Milner (16:21) Yeah. Mike (16:41) Might be better than spending 20 minutes practicing something that they've probably done before. Brian Milner (16:45) Yeah, I completely agree. Let's move to the third pillar then, because I know this is a big one, just thinking and talking about the roles. And just as far as communication issues are concerned, even outside of Scrum, I know that's part of the big problem with teams and organizations just not being clearly defined about who does what and who's responsible for each thing. So those misunderstandings are really common failure points. ⁓ Mike (17:09) Mm-hmm. Brian Milner (17:10) How do you see teams getting that wrong and how's that derailing a Scrum team? Mike (17:15) Well, think we see it all the time on Scrum teams between Scrum Master and Product Owner and even the development team, right? Who does what? I was responding to some comments on LinkedIn this morning on some post I'd made last week and somebody had some comments. And it had to do with whether the Scrum Master or Product Owner does something. And it was interesting because in the comments on that post, I... I don't remember which one it was, but I shared a certain perspective. I feel pretty strongly that I have it right. I mean, I this is how we do it. But there were other people saying the opposite, right? And so, you know, these are people that are probably fairly experienced with Scrum, if they're following me on LinkedIn and feel comfortable commenting on a post, probably feel comfortable with it. And so there's a lot of confusion about what role does what thing. And I don't think this is something where the Scrum guy is going to have the answers for you. I think it's, I mean, you can look at the Scrum guy, oh, this. Here's my starting point answer, but we always want to play to people's strengths, right? And if you've got a scrum master who's got a lot of skill in one area, maybe they shift a little work from the PO to themselves, right? With the PO's permission, right? And the opposite, right? Between maybe PO and team. So it's fine to have default starting positions on who does what, but you always want to play to people's strengths. So I think PO scrum master, I think we see it with project managers and scrum masters, roll confusion on those type of roles as well. Brian Milner (18:38) Yeah, completely agree. A lot of those roles that are not named Scrum team roles and how they interact with the team, that's often a source of confusion as well. What are maybe some signs or symptoms that teams might be having confusion or problems in this area that maybe they don't even recognize or realize they're having an issue with roles? Mike (18:59) Any sort of conflicts, right? You know, you and I arguing over which one of us should do something. The other one would be kind of the opposite, which would be like a dropped ball. I was watching some YouTube video. I love baseball. I was watching some YouTube video the other day of like missed catches or something like that. And some team hit a baseball way up in the air and it was landing near three players, right? Three players are all looking at it. Brian Milner (19:12) You Mike (19:23) One guy waves the other two off, he's going to catch the ball and he must have been blinded by the sun because he's like six feet from the ball when it lands on the ground, right? And, you know, if we have a responsibility to catch the ball, run this meeting, right, right the backlog, the kids dropped, right? And so I think either arguing over who does something, two of us trying to do the same thing or neither of us doing it. I don't mean trying to get out of the work, right? All three players have been happy to catch the ball, but I think you've got it. You think I've got it, right? Those type of things are pretty good signs. think getting clarity around these roles can really optimize how a team works. And I think a really key thing here is that it changes over time. So I'll go back to my example of maybe the Scrubmaster has some skills that can help the product owner early on. Because maybe the product owner is new to the company. The product owner doesn't know the product as well. So they might rely on the Scrubmaster for guidance on things. Well, a year from now, we might shift responsibilities a little bit because now the PO is the expert on all things related to the product. So it's not like we want to establish clarity on roles one time and leave it forever. It's going to change. We get a new tester on the team, things might change. Product owner moves. It's going to change again. So we need to realize these responsibilities are dynamic. Brian Milner (20:39) Yeah, that's a great point. Your point about baseball just made me think about how, when you watch any youth sport in the world, when you go watch your kids play a sport, what's the one thing you always hear people scream from the sideline? Talk to each other. Call the ball. Well, that too. That too. Ump your blind. Those kinds of things. Well, let's talk a little bit about Mike (20:52) I thought you were going say, put my kid in. Brian Milner (21:00) I know this course addresses the roles and how would you say this course really helps address that issue of role confusion? Mike (21:07) think a big part of it is that we designed it to be for everybody on the team, right? Suppose you send a scrum master to a class, and it's a great class. Scrum master is going to back to the certain set of impressions about their role. Product owner goes to an equally good class about the product. They might have different impressions. Even if they took the course from the same instructor, they're hearing it a little differently. They're hearing it through their filters, right? And so when they're in a course together, there's more opportunities to clarify their understanding about those things, especially in the classes designed as we did with this one to bring out some of those differences. So I think the course helps with that. we've also designed it to mention the rules we haven't talked about, like managers and things like that. Brian Milner (21:53) Yeah, yeah, I think those are so important. And there's a lot of great discussions that come out when we have those topics. ⁓ Let's talk about the fourth pillar then, teamwork, because this, I think, builds really well on what we just talked about. And the idea that there's actually, Scrum is a team sport. ⁓ So beyond just normal human personality conflict type issues, what do you see that gets in the way of teams actually Mike (21:58) Mm-hmm. Mm-hmm. Brian Milner (22:18) working as a team. Mike (22:19) think ego is probably one, right? I can do everything better, just leave me alone. There's an old book that says basically, beware of a lone developer in a room, right? You know, it was referring to the developer who wants to close their door and say, I'll it done in a month, trust me, right? And one of the companies I worked with, and this one's going back like 15 years ago, but it was a really good story. Brian Milner (22:36) Yeah. Mike (22:43) is they would literally grab one unit of work. Each person on the team would grab a unit of work and take anywhere from three to 12 months to do the thing. So they were big things, but the person would do everything on it. They'd coded, tested everything. And the organization was putting out very little because of this. When they moved to Scrum in the first year, by their estimate, they said they delivered 540 % more work. over five times the amount of new features delivered. And that was through the collaboration, through the short iterations, those type of things. But it was about getting people to collaborate more. So I think there's huge opportunities to do that. One of the problems I see is when we don't overlap work. If we think about that organization I just described, you grab your thing, you're done in six months. I grab mine, I'm done in seven months. If we'd work together on those things, what's not make us any faster? No faster. But you and I could have worked on your one thing and been done in three months. OK, we're delivering value in three months, right? And so one of the things I look for a lot is how much teams are overlapping work, right? And if we're not overlapping work, there's huge opportunities to improve at that. I'll a little example of this. One of my favorite restaurants is, I don't know, barely call it a restaurant. It's a fast food deli. It's called Jimmy John's. Have you been to Jimmy John's, Yeah. Yeah, there's one near my house where I can go there and the wine will be out the door. Right. And you know, normally you see a wine out the door and it's like, crap, I'm going somewhere else. Right. These guys are so fast. They're so fast. When I get to the front, I place my order. I play this little game of can I fill up my cup? You know, I get an iced tea and they give me an empty cup and can I go fill up ice and put the tea in before they hand me my sandwich? And it's about 50-50. Right. It doesn't take long to fill up your iced tea. But the way they do that is the overlap work. As soon as I order my Italian club sandwich, somebody's already got the bread open, somebody's got a slab of meat they're ready to drop on there, somebody else has their hands over the vegetables and they're dropping the vegetables on there, and then a fourth person wraps it up. And so like four or five people touch my sandwich. Hopefully their hands are clean, but four or five people touch my sandwich as opposed to like most delis where I go and it's like you watch one person plod along making the sandwich, right? Overlap work is huge. Brian Milner (25:07) Yeah. Yeah, this episode sponsored by, no, just kidding. Use code Mike Cohn when you go to, no, just kidding. Yeah, I agree. And yeah, yeah, I'm familiar with Jimmy John's. Probably too familiar. ⁓ Yes, yeah, no, that's, I think that's part of their shtick is that they're, you know, they're known for being fast. So yeah. Mike (25:10) You Is yours just as fast? Yeah. Yeah. They call it Freaky Fast. They actually have a competition. I've seen YouTube videos of this where they get like the best teams at various restaurants race, right? And so they have like the Jimmy John sandwich making Olympics or something, but it's a skill. Brian Milner (25:36) wow, wow, yeah. You should pair that up with the hot dog eating challenge in some way and see if we could have a team sport going there. ⁓ Mike (25:48) Well, that's a good point because think about the hot dog eating. That's one guy, right? That's Joey Chesnett shoving hot dogs down. The Jimmy Johns is a team. They get the best crew at a restaurant and it's a team, right? How fast can the team go? Not how fast can one guy make a sandwich, right? Brian Milner (25:51) Yeah. Yeah, yeah. That's awesome. So what are some tips? What are some ways that you can really unite a team, especially those new teams? Because that's the fascination point for me is, how do you take this group of humans that really don't know each other and haven't worked together in the past and unite them together and have them gel as a team? How do you do that? Mike (26:21) I'll give you a couple. One, I think having really crisp sprint goals helps. So we all know exactly what we're trying to get done in the sprint. We don't lose sight of that because sometimes in the middle of a sprint, you lose sight of it. And you get myopic and you just focus on a list of tasks. And I'm going to say that it's probably similar to the team doing sprint planning and just getting them assessed with the numbers. It's not about the numbers. It's not about the tasks. It's about the backlog items that lead to some goal. So crisp sprint goals help. That's a hard phrase. Crisp Sprinkles helps. The other one I'd say is having a shared vision about where you're headed over a little bit longer term. Probably the biggest change to the Scrum Guide ever that I've liked is the inclusion of a product goal. And that was something I'd been talking about forever. mean, literally since I started doing Scrum was that sprinkles are great, but they're pretty short, right? You want to have something bigger. Brian Milner (26:52) It is. Mike (27:14) And so I like having product goals that are a few months out there. And one of the things I like doing for product goals is have teams do something like write a press release that describes their goal or create a vision in some way, write a review that you want to see come out on the App Store, Play Store, and a magazine. And one of my clients made software and they were reviewed by a major magazine and they were given an editor's choice runner up award. And they actually estimated that being runners up for that was probably worth about $10 million. First place, first time was worth about $10 million a year to them. And so they decided to get serious about this and they wrote a review. Their scrum master, she was actually combo scrum master product owner, Erin. She had the team write a review and she said, let's go earn this review. And I literally remember the email I got from her three months later. It was because it was Halloween night. I just like, you know, brought in the candy from outdoors. We're done trick or treating. And I checked my email. I a three word email from her from Erin. said we did it. And the magazine had let her know, hey, we're reviewing you. be out on, you know, like Tuesday's edition. And the review had quotes in there that were from their vision review, right? The things that they had wanted to achieve. Brian Milner (28:22) Ha ha. Mike (28:35) And that team had just really jelled around that and just became so much more productive and collaborated so much better because of that shared vision. Brian Milner (28:43) Yeah, that's amazing. getting back to the course then, I know in the course we're trying to kind of some of those collaboration muscles. What are some of the ways that the course helps to build that? Mike (28:56) think one of the key things that we're doing, and I'm excited about this, is that we're, you know, we of course use Zoom breakout rooms, right? You you go talk about this, we'll see you in eight minutes or something like that. And for this course, we're doing something where a group of three or more, when they register, can have a private breakout room. And this to me is exciting because people get the benefit of having a private breakout room. They can have sensitive discussions if they want. They can talk very specifically about. you know, what do we do about our jerk product owner? mean, whatever it is, right? You know, they can talk about their specific issues, yet have the context of a broader class. Because I think in one of the benefits of any public class is hearing how other teams are doing things. And sometimes that's because you get a good advice, you know, how did you solve that problem? We have that problem. Other times, it's just feeling that you're not alone in the world. they've got that problem too, right? And they don't have any solution for me, but I know I'm not alone in the world with this. And so I like these private breakout rooms for three or more. I think it's a novel thing we're doing with this class. And it's with the intent of combining the best of both worlds of private and public training for this. I'd the other thing is probably consistency, having everybody on the team hear the same message, having those discussions with an experienced instructor like you or me in the room to provide guidance when they have questions. know, go back to the role clarity, right? You know, they can talk about it and they're there. Then they're back in the main room with you or me and we can kind of answer questions. So I think that consistency will be huge as well. Brian Milner (30:25) Yeah, yeah, I love that idea of the private private breakout rooms that that's that's gonna be huge for a lot of people I know. ⁓ Mike (30:31) I'm excited to try it with this. This will be the first classes we do that for. I'm excited about it. Brian Milner (30:36) Yeah, yeah. Well, let's bring it home then and talk about the fifth pillar because the fifth pillar is really interesting as well. It talks about support beyond the team and teams can only do so much. Every team struggles when they're not supported well. And there's lots of studies that show leadership support is one of the biggest hurdles or obstacles to the adoption. Mike (30:46) Mm-hmm. Brian Milner (30:59) What does that support look like from outside the team and how can a team influence that? Mike (31:06) Yeah, if you're trying to be agile and your HR group has quarterly reviews of personnel that are all based on individual performance and has nothing to do about teamwork in there, it's going to be hard to focus on collaboration. So we have to kind of fix these issues. I think what we have to do here is to have team members educate those outside the organization. And we have information that we share about, you here's how to talk to a boss that's maybe mandating deadlines, things like that. And so we try to coach people through having some of those challenging conversations. And one of things I want teams to do is kind of become an example of what good agile looks like. And if you have a team that's excelling with agile and they're doing it from a kind of principles first, that mindset first approach. You're going to see other groups look at that and let's say the marketing group. They're going to look at that go, hey, that's an interesting way to work. I wonder how we could do that, right? And it's going look different for a marketing group than a tech team. the mindset is going to be the same. Principles will still be the same. And so when we get teams to do really well with this, other parts of the organization start to get interested. And then they stop being as much in our way. Brian Milner (32:20) Yeah. I know one of the most important aspects here and that we talk about is, is that you don't need to, to wait, right? If you're the team level, you don't have to just sit around and wait for the organization to make changes. you, you have opportunities to make changes as well. So how does that happen? How's the team change, you know, bring about those changes that, improve the agile process, the results. Mike (32:42) I think that's by being the example so that people see it. I think it's by having those conversations. You know, one of the things that we'll get is, you know, it's so common is the product owner that wants to change their mind all the time. I was reading something, I guess this is in our Agile mentors community, I think is where it was, but it was about the, you know, the product owner who said his favorite thing about Agile is that he can reprioritize every week. ⁓ And it's like, you can, you know. Brian Milner (33:05) Hmm. Yeah Mike (33:10) I'm not sure it's good. And I think about that, a team gets momentum, right? And you're working on a certain feature. Next sprint, it would be nice to work in that same area of this system, right? Your head's there. Just kind of keep going a little bit. And I've often described this as like, let's say you're working on three backlog items that are in a certain area of this system. Let's make it concrete. Let's say it's the spell checker in Microsoft Office, right? And you do three backlog items related to the spell checker this sprint. Next sprint, maybe your top priority is not more spell checker stuff, but maybe items, I don't know, 25, 26, and 27 on the backlog are still in the spell checker. You know what? It might be better to do those. There are probably two or three sprints away. Let's bring them into this sprint. Just get them done while my head's into spell checking. And so getting product owners or stakeholders to stop doing that, one of the ways that I like to talk about doing that is using an example of ordering a meal at a restaurant. I can order, let's say, the chicken entree. And then as the waiter is taking the orders around the table, I change from chicken, no, bring me the fish. Not a big deal. The waiter is going to cross off chicken and write down fish. If the waiter goes away, brings me back my salad, and I change my mind then, I say, hey, bring me the fish. Might not be a big deal. It's going to be a big deal if I've already taken three bites of the chicken. right? Or if he brings me the chicken. So yeah, we can change our mind, but there's a cost, right? And we want to educate stakeholders about that cost. They don't overdo it. Brian Milner (34:31) Yeah. Yeah. Well, speaking of the leaders and the organization, managers, leaders, do you think this course is appropriate for managers and leaders to attend as well? you feel like they might need to in order to really have this be an impact? Mike (34:55) Yeah, that's a good question. Is it appropriate? Yeah, I think it's appropriate. When we do this privately, we've had plenty of leaders and managers attend. I think it's great. I don't think that's required because they're not on the Scrum team. You said the name of the course is working on a Scrum team. And so they're not on the Scrum team. They benefit by knowing more how their Scrum team works. But I think what we found is that having just a key subset of people who hear the same message work through the training together, and then go back to the organization. That's enough to bring the passion, conviction, and skills that we want. So we don't truly need leaders. They're great. I would never talk a leader out of going, but I wouldn't. If I were a team and I could take the class this month or with my leader next month, I would just get the class done, right? And educate the leader afterwards. Brian Milner (35:41) Yeah. Yeah, yeah, I think that's a good plan. All right, well then we've made our way through the five pillars and for people who have come this far with us and are at this point, if they're listening and they're recognizing some of these problems we've been talking about, what would you recommend to them as next steps here? Mike (35:49) if Well, take a look at our website. If you go to mountaingoatsoftware.com. And then I think there's a courses link on the top. You can go up there and find the link to this course. It's an exciting one that we're doing. I've literally been teaching this, I think the first time I taught a class called Working on a Scrum Team was 2003 or 2004. it's a time tested course. You and I kind of redesigned it a couple of months ago to make it appropriate for public. or little better just in general and more appropriate for public. But it's a time-tested course that's now designed to be available for public settings instead of, you know, have to have 25 people or something. Brian Milner (36:36) Yeah, yeah, that's really exciting. I can't wait to see kind of how people are in, you know, react and interact in the course to some of these concepts and ideas. And we'll, we'll of course link to all these things that we've talked about in our show notes and make it easy for everyone to find the course listing and, and, you know, where the dates and everything that we're going to offer them. So make sure to check that out. Mike, thanks so much for coming on. This has been really enlightening and I appreciate you making time for it. Mike (37:01) Of course, thanks for having me, Brian. Always a pleasure.

In this episode of the Risk Management Show, we explore the transformative role of AI in supply chain success and mastering agile sourcing. Boris Agranovich, founder and CEO of the Global Risk Community, is joined by Sam Jenks, Chief Revenue Officer at Kodiak Hub, an innovative supplier relationship management platform. Together, they discuss strategies for navigating geopolitical risks, tariffs, and disruptions while leveraging AI and big data to enhance procurement precision and sustainability. We also examine the shift from traditional supplier strategies to agile sourcing techniques, the importance of understanding vendor tiers, and the integration of technology in risk management. Sam shares insights on reshoring, nearshoring, and the future of AI-driven systems in procurement, emphasizing the critical need for businesses to adapt and innovate in today's volatile landscape. If you want to be our guest or suggest a guest, send your email to info@globalriskconsult.com with the subject line: “Guest Proposal – Risk Management Show.”

Florian Georgescu: When Knowledge Hoarding Destroys Team Dynamics Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Florian describes a payment system development team where an experienced tech lead unknowingly created a dangerous dependency. This senior developer, while well-intentioned, became the single point of knowledge and decision-making for the entire team. Other developers began copying his behavior, creating a culture where team members were afraid to ask questions for fear of appearing incompetent. When this key developer left, the team fell apart - planning sessions became confusing, technical discussions stalled, and two junior developers quit citing lack of learning opportunities. The story demonstrates how knowledge hoarding, even when unintentional, can destroy team resilience and create toxic dynamics that stifle growth and collaboration. In this segment, we refer to the Monday episode with Florian as context for the story he shares on this episode. Self-reflection Question: How might knowledge hoarding be happening in your team, and what steps could you take to encourage more distributed learning and decision-making? Featured Book of the Week: The Responsibility Process by Christopher Avery Florian The Responsibility Process by Christopher Avery particularly valuable for understanding the stages people go through when taking responsibility. The book's framework helped him process his own burnout experience and provides crucial insights for helping teams accept responsibility for their outcomes. Florian emphasizes how the responsibility process is essential for understanding what you can influence when you want to take ownership, making it a powerful tool for both personal growth and team development. In this segment, we refer to the Responsibility Process, by Christopher Avery, who was a previous guest on our Audiobook project: Tips From the Trenches, Scrum Master Edition.  [The Scrum Master Toolbox Podcast Recommends]

In this episode, we dive into what it takes to make an agile supply chain. Our guest, Vic Chynoweth, CEO of Tempo breaks down how companies can better prepare themselves for the unexpected and move forward as an organization when it comes to supply chain disruptions. For more information, subscribe to ⁠Check Call the newsletter⁠ or the podcast. ⁠Follow the Check Call Podcast⁠ ⁠Other FreightWaves Shows⁠ Learn more about your ad choices. Visit megaphone.fm/adchoices

10 Human-Centered Leadership Principles1. Ask for forgiveness, not permissionInnovation rarely starts with approval.Build what you believe in — and deal with the politics later.You will be remembered for the rules you break.2. Build teams first, then productsGood products are built by healthy teams.Invest in trust, care, and clarity — and the product will follow.3. People and interactions over processes and toolsStolen from Agile, and still true.Tools are only as good as the humans using them.Build relationships before systems.4. Find a way — or build oneConstraints don't stop creativity.They shape it.Be scrappy. Be resourceful. Be relentless.5. Never build what is askedDig deeper.Understand the real need.Then build what actually matters.6. Less talking, more buildingEndless alignment leads nowhere.Create momentum by making things.Then talk about what's real.7. Live off the landUse what you have, don't wait for ideal conditions.Work with the terrain, not against it.It takes knowledge, humility, and creativity.But that's how great work gets done.8. Everyone is a designerDesign is not a job title — it's a mindset.Everyone on the team shapes the experience.So give them the tools, the trust, and the invitation to contribute.9. Good management is as little management as possible.The best leadership is invisible.Create clarity, then get out of the way. People want clarity not transparency.Support, don't control.Unblock, don't bottleneck.10. We all have wings, but some of us don't know whyThere's magic in everyone.Part of leadership is reminding people they can fly —even if they've forgotten how..How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

#5amMesterScrum show 1261 Get to the Next Level New Tuesday Topics   I'm going to be changing the Tuesday programming from 2 for Tuesday or 10x to more of a Get To the Next Level in your Agile or Scrum Career. Soon I will also announce a new spin off as well that relates to general Career Growth and Business Growth on a separate channel. Related to the idea of Get to the Next Level. I hope you will find this helpful on your career journey in Agile or Scrum.

Discover the key to mastering business adaptability for PMP success! In this transformative journey, you'll uncover practical advice for evaluating and addressing external business environment changes—a crucial skill for the PMP exam. Learn how Agile and Hybrid methodologies empower project managers to pivot with confidence, ensuring alignment with dynamic market conditions. This episode dives deep into strategic approaches for navigating challenges like disruptive competitors, regulatory shifts, and technological advancements. By cultivating the right mindset for success, you'll bridge knowledge gaps and gain the tools to adjust project scope and objectives proactively. With real-world examples, mindset mantras, and expert tips, this video equips you to conquer the PMP exam while enhancing your project management expertise. Ready to elevate your career? Smash the like button, subscribe for more practical advice, and explore our resources for webinars, live training, and more on PMP exam preparation. Let's turn challenges into milestones on your path to PMP success!

In this episode, we dive into what it takes to make an agile supply chain. Our guest, Vic Chynoweth, CEO of Tempo breaks down how companies can better prepare themselves for the unexpected and move forward as an organization when it comes to supply chain disruptions. For more information, subscribe to Check Call the newsletter or the podcast. Follow the Check Call Podcast Other FreightWaves Shows Learn more about your ad choices. Visit megaphone.fm/adchoices

Florian Georgescu: From Burnout to Balance: A Scrum Master's Reality Check Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Florian shares his experience of trying to single-handedly transform an entire IT service company, leading to what he calls the "superman scrum master syndrome." His story highlights the dangers of trying to be everywhere for everyone and create perfect change from the beginning.  Working with a coach, Florian recognized the warning signs of burnout - exhaustion, frustration, and the unhealthy need to control everything. His journey teaches us that sustainable change takes time, and it's perfectly acceptable for things not to be perfect from the start. The key insight is learning to pace yourself and accept that meaningful transformation is a gradual process, not a solo mission. Self-reflection Question: When have you found yourself trying to be the "superman" in your role, and what signs helped you recognize it was unsustainable? [The Scrum Master Toolbox Podcast Recommends]

https://youtu.be/avv30Z0wD9Q Josh Tarbutton, Entrepreneurial Chairman and Chief Innovation Officer of Bravo Team Engineering Design and Fabrication, is on a mission to restore the dignity of engineers and unleash their creative potential through intentional culture and agile structure. We explore Josh's journey from soldier and professor to engineering leader, and his Engagement Success Framework, which includes: Scoping/Visioning, Customer Communication, Resourcing, and Solution. Josh explains how this structured process allows Bravo Team to align deeply with client goals, unlock team creativity, and deliver complex, high-impact innovations with confidence. We also discuss how “grooming” a project helps avoid costly misalignments, how AI and Agile methods are transforming the engineering workflow, and why design for sustainability and accessibility will define the next frontier of innovation. --- Unleash the Power of Engineers with Josh Tarbutton Good day, dear listeners, Steve Preda here with the Management Blueprint Podcast. And my guest today is Josh Tarbutton, former professor, soldier, and currently the Entrepreneurial Chairman and Chief Innovation Officer of Bravo Team Engineering Design and Fabrication. Josh, welcome to the show. Steve, glad to be here, thank you. Well, I'm excited to have this conversation because your kind of firm has not been represented on the show for the last 300 episodes. So, we're definitely gonna have some new insights and the new perspectives. We've never had an engineering consulting firm, I believe. And you also have a very inspiring “Why” of why you're doing this. So let's start with this. And would you share your personal “Why” and how you are manifesting it in Bravo Team? Yes. So why Bravo Team or why do this? So I think there's the truth that if you want to create new things, you got to imagine them and put yourself in a position to create.Share on X And I think as engineers, we have that unique opportunity and in many of our careers to be the tip of the spear for creativity in our organizations. And, for me personally, seeing how soldiers are trained in the army, seeing how engineers are matriculated in academia and seeing the career paths that they end up with, I really feel like there's a little bit of a mismatch in the market between what the engineer is really capable of and what they're actually able to produce in an organization. And I would say that to the extent that there's a blockage between the creative capacity of the engineer and the value that they could deliver, I feel like I kind of want to help that. And so what is that? Well, part of it has to do with like just the dignity of the engineer and how we understand the value contribution. And so part of my “Why” is I actually believe that if we actually have intentional conversations and we change some of the ways that we do things that we can get, we can allow people to be much more creative and we can have bigger budgets because we're reducing waste in other areas and really make a dramatic impact into the way that we do design work. Okay, so that is fascinating. And you mentioned the dignity of engineering. So, what is happening with the dignity of engineering? Why it needs to be restored? So fundamentally, dignity is, I think, mostly just about respect. And I think, sometimes, when two people are having a conversation, our assumptions that we bring into the conversation can really take away from what the other person is saying. And I think that happens a lot in engineering, where the engineer is doing their best to try to communicate what needs to be communicated. And yet, there's a little bit that's lost in translation. So, then the engineer comes across as being a resistive or adding some restriction or creating problems or trying to slow things down. When in reality, I'd say almost all the time, these individuals are trying to help and reduce risk and increase the customer experienc...

Breaking Down The Spotify Engineering Culture ModelThe Spotify Engineering Culture Model is one of the most widely referenced frameworks for scaling Agile and creating autonomous, innovative teams. Originally popularized by Henrik Kniberg and Anders Ivarsson in their internal videos (now public), the model describes how Spotify organizes and empowers teams to deliver software at scale while maintaining a strong culture of innovation, speed, and flexibility.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

Despite all the easily available books and courses on How To Do Agile, we can't seem to keep the Agile Principles straight. Easily half of them are abused in just about every corporate environment. Is it any wonder our reputation is on the rocks?

In this powerful episode, Josh and Bob go all-in on the responsibility of leadership—especially when it's uncomfortable. Prompted by listener feedback questioning whether it's “worth it” to speak truth to power, they deliver a no-nonsense masterclass on the cost and courage of real leadership.This conversation is blunt, passionate, and grounded in decades of lived experience. From promotions earned by speaking uncomfortable truths to the burden of responsibility great leaders carry, this is not a theoretical chat—it's a challenge. If you're hiding, coasting, or waiting for it to get easier, this episode is your wake-up call. Stay Connected and Informed with Our NewslettersJosh Anderson's "Leadership Lighthouse"Dive deeper into the world of Agile leadership and management with Josh Anderson's "Leadership Lighthouse." This bi-weekly newsletter offers insights, tips, and personal stories to help you navigate the complexities of leadership in today's fast-paced tech environment. Whether you're a new manager or a seasoned leader, you'll find valuable guidance and practical advice to enhance your leadership skills. Subscribe to "Leadership Lighthouse" for the latest articles and exclusive content right to your inbox.Subscribe hereBob Galen's "Agile Moose"Bob Galen's "Agile Moose" is a must-read for anyone interested in Agile practices, team dynamics, and personal growth within the tech industry. The newsletter features in-depth analysis, case studies, and actionable tips to help you excel in your Agile journey. Bob brings his extensive experience and thoughtful perspectives directly to you, covering everything from foundational Agile concepts to advanced techniques. Join a community of Agile enthusiasts and practitioners by subscribing to "Agile Moose."Subscribe hereDo More Than Listen:We publish video versions of every episode and post them on our YouTube page.Help Us Spread The Word: Love our content? Help us out by sharing on social media, rating our podcast/episodes on iTunes, or by giving to our Patreon campaign. Every time you give, in any way, you empower our mission of helping as many agilists as possible. Thanks for sharing!

Anamaria Ungureanu: Building Self-Awareness in Overly-Technical Product Owners Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Master Storyteller Anamaria highlights a Product Owner who excelled at storytelling and vision communication, making every team member feel aligned with project goals. This exceptional PO consistently explained the "why" behind requirements and painted compelling pictures of how the team's current work would create future value. Their storytelling ability kept the team engaged and motivated, demonstrating how great Product Owners apply agile mindset principles to create shared understanding and purpose. The Bad Product Owner: The Monologue Specialist Anamaria describes a technically-skilled Product Owner who transitioned from a tech lead role but fell into the anti-pattern of excessive monologuing during sprint planning sessions. This PO, despite good intentions, overwhelmed the team with lengthy technical details, causing developers to withdraw from interactions and leaving them confused about project purposes. Through one-on-one coaching focused on building self-awareness and establishing working agreements, Anamaria helped this PO learn to communicate more effectively and engage collaboratively with the team. Self-reflection Question: How do you help Product Owners transition from technical expertise to effective team communication, and what signs indicate when detailed explanations become counterproductive monologues? [The Scrum Master Toolbox Podcast Recommends]

In this episode of the Health Systems CXO podcast, Brian Contos discusses the current challenges facing health systems, including financial pressures and policy changes. He emphasizes the need for health systems to rethink their growth strategies, focusing on operational scale through AI and site of service optimization. Welcome to the Health System CXO Podcast, sponsored by The Health Management Academy, featuring content designed for Health System Nurse Executives, Health Equity Officers and Strategy Executives provided by our company SME's - Anne Herleth, Jasmaine McClain, Ph.D. and Jackie Kimmell. Subscribe today and receive the latest insights from the country's leading Health System CXO experts regularly, helping you remain current and guide your health system strategy with thought leadership and success.The Health System CXO Podcast activates health system leaders towards outcomes and scalable solutions you can implement now.About The Health Management Academy:Since 1998, The Health Management Academy has cultivated the premier community of healthcare's most influential changemakers from the top U.S. health systems and innovative industry partners. We power more than 2,000 health system senior executives and 200 industry organizations through exceptional peer groups, original market insights, world-class leadership development programs and novel member alliances. Our industry-leading programs and solutions enable members to facilitate meaningful relationships, navigate strategic transformation and address critical industry issues. To learn more, visit hmacademy.com and follow The Health Management Academy on ...

In this episode of Agile&Me, guest expert Jason Wambold shares valuable insights on variable compensation models in outpatient physical therapy, exploring how these flexible pay structures can boost therapist satisfaction, support recruitment and retention, and benefit clinic owners. Tune in to learn practical strategies and real-world examples that highlight the advantages of offering compensation choices for therapists and fostering a supportive, thriving work environment.To learn more about us, visit our website at https://www.allianceptp.com/

Anamaria Ungureanu: Tracking Scrum Team Behavioral Evolution Over Time Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Anamaria defines Scrum Master success by focusing on team behavioral trends and performance evolution over time. She monitors how teams increase trust with stakeholders, demonstrate commitment, and apply agile behaviors consistently. Her approach emphasizes seeking regular feedback from stakeholders and conducting honest self-assessments to ensure the Scrum Master role is truly maximizing team performance. Success isn't measured by a single moment but by sustained positive change in team dynamics and delivery capabilities. Featured Retrospective Format for the Week: Stop/Start/Continue with Enhanced Focus Anamaria recommends the classic Stop/Start/Continue format but emphasizes the importance of varying the questions and bringing both quantitative and qualitative data to drive meaningful conversations. She suggests picking specific themes for each retrospective (like testing) and ensuring that discussions lead to concrete, actionable outcomes rather than just surface-level feedback. Self-reflection Question: How do you currently measure your effectiveness as a Scrum Master, and what trends in your teams indicate genuine progress versus superficial compliance? [The Scrum Master Toolbox Podcast Recommends]

Can We Do 100% Scrum And SAFe Simultaneously? - NOPE...This question emerged during a recent Scrum.org Professional Scrum Master Advanced training in Germany

Join us as host Patty G sits down with Keith Primeaux from Agile Brewing. From software development to flavor profiles, Keith is a master of many trades. Hear the story of how he and his team have created one of the most unique breweries in town. Check out Agile here: http://www.agile.beer/Sponsors: PB&J Productions, Coretechs, Falaya, and Lake Men's Health CenterThe Patty-G Show website: ⁠https://thepattygshow.com/⁠#explorebatonrouge #batonrouge #batonrougepodcast #thepattygshow #onlylouisiana #visitbatonrrouge #louisianatravel #podcast #localpodcast #entrepreneur #entrepreneurship #vodcast #batonrougebusiness #batonrougeentrepreneur

Anamaria Ungureanu: Practical Strategies for Organizational Tool Rollouts Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Anamaria shares her approach to successfully implementing JIRA across an organization by focusing on practical value rather than forcing adoption. Her strategy involved identifying early believers within teams, conducting open discussions to gather feedback, and demonstrating concrete benefits like improved dependency management. Rather than trying to convince resisters, she concentrated on working with willing teams to showcase the tool's value, providing real-time support during implementation, and ensuring team members felt supported throughout the transition. Her method emphasizes being present to answer questions immediately and building momentum through successful early adopters. Self-reflection Question: When leading organizational change, how do you balance addressing resistance with amplifying the voices of those ready to embrace new approaches? [The Scrum Master Toolbox Podcast Recommends]

Anamaria Ungureanu: The Tech Lead Who Nearly Destroyed the Team Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Anamaria describes a seven-member software team that initially seemed engaged but began self-destructing when a senior tech lead refused to embrace transparency and knowledge sharing principles.  The situation escalated when this key team member's four-day absence completely blocked the team's ability to deliver, creating a dangerous single point of failure. Through careful retrospective facilitation and strategic motivation techniques, including offering the specialist new learning opportunities while gradually transferring their legacy knowledge to teammates, Anamaria helped the team overcome knowledge silos and establish sustainable collaboration patterns. Featured Book of the Week: Never Split the Difference by Chris Voss Anamaria recommends “Never Split the Difference” by Chris Voss, a negotiation masterpiece because it taught her essential communication strategies for establishing trust and navigating tense situations. She emphasizes that negotiation is a critical Scrum Master skill, and Voss's techniques help build rapport with stakeholders while managing difficult conversations that arise during team transformations and organizational change initiatives. Self-reflection Question: What knowledge silos exist in your teams, and how might you motivate specialists to share their expertise while providing them with new growth opportunities? [The Scrum Master Toolbox Podcast Recommends]

Get featured on the show by leaving us a Voice Mail: https://bit.ly/MIPVM 

Anamaria Ungureanu: Goal Clarity—The Missing Piece in Agile Team Performance Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Anamaria shares her experience working with a platform implementation team that appeared engaged but was actually struggling in silence. Despite initial assumptions that everything was fine, the team's quiet demeanor masked their lack of understanding about project goals and deliverables.  Through strategic intervention including goal clarification with the Product Owner, confidence level assessments, and story mapping sessions, Anamaria helped transform a disengaged team into one capable of successful delivery. Her approach emphasized the importance of fostering constructive conflict, asking open questions during sprint planning about demo expectations, and facilitating better PO-team interactions to create transparency and shared understanding. In this episode, we refer to User Story Mapping and the concept of Gemba, or Gemba Walk Self-reflection Question: How might your teams be silently struggling, and what signs should you watch for to identify when apparent engagement actually masks confusion or disengagement? [The Scrum Master Toolbox Podcast Recommends]

You Don't Need Agile... YES You Do Need Agile!When Agile was introduced many years ago, it gave software delivery an option to do things differently. From there, many offshoots have come from Agile that come from Agile that provide even more options for Software Delivery.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

Anh Vu: The Hidden Cost of Decision-Making Delays in Product Development Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Strategic Connector Anh describes an exceptional Product Owner who went far beyond managing the backlog to become a strategic connector between customer needs, business requirements, technical constraints, and overall strategy. What made this PO remarkable was their background - they came from a developer background rather than business, yet quickly mastered the Product Owner role through dedicated learning. Despite being new to the PO role, they rapidly developed the ability to connect backlog items directly to customer pain points, often using techniques like user story mapping. This PO brought both clarity and purpose to the team, significantly boosting team motivation by helping developers understand how their work directly impacted customers and business outcomes. The Bad Product Owner: The Proxy Problem The worst Product Owner situation Anh encountered involved a Proxy PO who lacked the authority to make decisions independently. This created significant challenges for both the team and the PO, as every new problem or decision required seeking permission from external stakeholders. This pattern lengthened feedback cycles and demotivated both the PO and the development team, who couldn't move forward efficiently when blocked by decisions. Anh's approach to addressing this involved coaching the PO on engaging with external stakeholders, setting up regular touchpoints (2-3 times per week) to shorten feedback cycles, and focusing on improving the decision-making process to unblock the team. He also emphasized creating a strong network of connections for the PO to navigate the organization effectively and always having a Plan B when certain decisions couldn't be made quickly. Self-reflection Question: Does your Product Owner have true decision-making authority, or are they frequently forced to seek permission from others, and how is this affecting your team's velocity and motivation? [The Scrum Master Toolbox Podcast Recommends]