Podcasts about Agile

Aimé Flemm: Renting The Change vs Owning It — Why LeSS Transformations Get Reversed 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.   "They rented the change instead of owning it." - Aimé Flemm   A year ago Aimé helped his Dutch employer adopt LeSS. The teams are happy. They're performing well. And now, he's watching it all get pulled apart. The company was acquired by a German parent that's "actually really German" — traditional, command-and-control. The parent wants to "align" all its companies and is pushing to revert the LeSS structure back to component teams. Why? Because higher management never went to the trainings. They never went through the change themselves. They signed off on it, but they didn't internalize it. And now the loud-but-few voices of the status quo are reaching upward, and management is panicking. That's what Aimé means by "renting the change" — you got the lease, you never bought the building, and the moment pressure rises, you walk away. His experiment for the next sprint, sharpened in this conversation: stop trying to defend the structure. Start a conversation with management to co-create success metrics for the merger itself. Decouple the structure from the definition of success. As long as the merger succeeds, the structure can stay fluid. Speak their language. And remember: coaching is the cherry on top — about 5% of the real gains. The big improvements live in the structural changes.   Self-reflection Question: When you sold your last change to upper management, did they buy it — or are they renting? And what's your plan for the moment when they want to give back the keys?   [The Scrum Master Toolbox Podcast Recommends]

5 Hidden Costs of Sprint Planning And the Agile Approach That Actually WorksHidden cost 1 — Meeting time multiplied by shallow decisionsHidden cost 2 - Inflated estimates driven by groupthinkHidden cost 3 — Hidden work and untracked dependenciesHidden cost 4 — The false economy of large batch planningHidden cost 5 — Overcommitment as a culture problem- [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/

Aimé Flemm: Culture Follows Structure — Why Some Teams Self-Destruct By Design 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.   "Culture follows structure. The destructive tendencies of a team are the consequence of how the organization is actually structured." - Aimé Flemm   Aimé doesn't blame teams when they go toxic. He looks at the org chart. At his first gig, the UX-only team grew bitter — making screens nobody used, blocked from talking to customers, drowning in dependencies. The team's behavior wasn't a coaching problem. It was a structural one. At his current company, building backend software for EV charging stations, he watched the opposite happen: leadership flipped seven component teams (backend, billing, etc.) into seven end-to-end feature teams with one Product Owner. Two-week sprints. Switching costs collapsed — they could decide on Wednesday to change direction, refine on Thursday, and have all seven teams pivot together by the next sprint. The org became truly adaptive. Aimé's question to every Scrum Master listening: is your organization fit for purpose? If the work is predictable and specialism-heavy, component teams can work. If you need adaptability, the structure has to match. Don't coach behavior that the structure forces.   In this segment, we talk about Larman's Laws of Organizational Behavior, the Star Model by Jay Galbraith, and Org Topologies.   Self-reflection Question: Look at the team you're coaching. Which of their "destructive habits" might actually be a rational response to the structure you've put them in? Featured Book of the Week: Large-Scale Scrum: More with LeSS by Bas Vodde and Craig Larman This week, Aimé recommends two books that complement each other. First — and his "holy bible" — is Large-Scale Scrum: More with LeSS by Bas Vodde and Craig Larman. "I remember reading this for the first time. It took me two weeks, the whole book. And I was just constantly texting people — 'this is it! It all makes sense now. I finally know what to do.'" For the how of organizational change — workshop ideas, possible structures, change tactics, and the people side — LeSS is the book. The companion book Aimé pairs with it is 10x Organization by Alexey Krevitsky, Roland Flemm, and Craig Larman — strong on the what and the why, with a 2x2 visual map that helps you explain to management where you are today, where the market needs you to be, and what should change. (You can also listen to our episode with Bas Vodde and our BONUS episode with Roland Flemm for a deeper view.)   [The Scrum Master Toolbox Podcast Recommends]

Why do accountability systems fail even when roles and responsibilities seem clear? In this episode, we sit down with Robert Snyder, Founder and President of Innovation Elegance, LLC, to explore why most organizations unintentionally separate authority from accountability, creating confusion, project delays, and trust issues. Robert introduces his Five Verbs framework—draft, review, revise, approve, and distribute—and explains how it creates clearer ownership, stronger collaboration, and better decision-making. Together, we discuss why documentation is a leadership tool rather than administrative overhead, how teams can detect and address untrustworthiness earlier, and why discipline and empathy must work together to build high-performing cultures. We leave with a practical perspective on creating trust through clear expectations, transparent decisions, and systems that help people succeed together. Key Takeaways: Keep authority and accountability connected to strengthen trust and execution.Use simple, repeatable processes to create clarity across teams.Document decisions that matter and avoid relying on memory alone.Encourage healthy task conflict while preventing personality conflict.Build empathy through consistent habits, questions, and team rhythms. Resources Mentioned The Inspire Your Team to Greatness assessment (the Courage Assessment) - In less than 10 minutes, find out where you're empowering and inadvertently kills productivity, and get a custom report that will tell you step by step what you need to have your team get more done. Get it here: https://courageofaleader.com/inspireyourteam/ You don't need to have all the answers to lead well. Get your copy of the Clarity Kit for just $17 to learn the five practices to bring more clarity, confidence and courage into your leadership - https://courageofaleader.com/the-clarity-kit/ About the Guest: Robert Snyder is the founder and president of Innovation Elegance, LLC. His thirty-year career spans roles such as developer, project management, change management, sales enablement, and the performing arts. His career path includes corporate roles, consulting roles, startups, PMP, and Agile certifications. He's performed in numerous vocal, dance, and theater ensembles. Robert earned his BS in Electrical Engineering from the University of Illinois and his MBA in Strategy from the Kellogg School of Management at Northwestern University. Robert is publishing a series of books on innovation methodology. Innovation Elegance: Transcending Agile with Ruthlessness and Grace - https://a.co/d/0e8MCIao Innovation Portfolio: Five Verbs Shape Your Team's Legacy - https://a.co/d/0h1K85BO Elegant Leadership: Distinguishing the Good, the Bad, and the False (targeting 2027) About the Host: Amy L. Riley is an internationally renowned speaker, author and consultant. She has over 2 decades of experience developing leaders at all levels. Her clients include Cisco Systems, Deloitte and Barclays. As a trusted leadership coach and consultant, Amy has worked with hundreds of leaders one-on-one, and thousands more as part of a group, to fully step into their leadership, create amazing teams and achieve extraordinary results. Amy's most popular keynote speeches are: The Courage of a Leader: The Power of a Leadership LegacyThe Courage of a Leader: Create a Competitive Advantage with Sustainable, Results-Producing Cross-System CollaborationThe Courage of a Leader: Accelerate Trust with Your Team, Customers and CommunityThe Courage of a Leader: How to Build a Happy and Successful Hybrid TeamHer new book is a #1 international best-seller and is entitled, The Courage of a Leader: How to Inspire, Engage and Get Extraordinary Results - https://a.co/d/06hsUz64 http://www.courageofaleader.com https://www.linkedin.com/in/amyshoopriley Thanks for listening! Thanks so much for listening to our podcast! If you enjoyed this episode and think that others could benefit from listening, please share it using the social media buttons on this page. Do you have some feedback or questions about this episode? Leave a comment in the section below! Subscribe to the podcast If you would like to get automatic updates of new podcast episodes, you can subscribe to the, podcast on Apple Podcasts or Stitcher. You can also subscribe in your favorite podcast app. Leave us an Apple Podcasts review Ratings and reviews from our listeners are extremely valuable to us and greatly appreciated. They help our podcast rank higher on Apple Podcasts, which exposes our show to more awesome listeners like you. If you have a minute, please leave an honest review on Apple Podcasts. Mentioned in this episode:The Inspire Your Team to Greatness Assessment (The Courage Assessment)https://courageofaleader.com/inspireyourteam/

Agile is Dead. Welcome to the Era of “Agent-Driven” DevelopmentAgile was invented for humans — biological entities that need coffee, sleep, and two weeks to understand a complex requirement. But we are no longer just building software with humans. We are building it with agents. Agents that don't sleep, don't need standups, and can iterate in seconds, not days.Welcome to Agent-Driven Development (ADD). The era of the 2-week sprint is over. The era of the Continuous Loop is here.- [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/

Founder and CEO of Auriga Space, Winnie Lai, joins me to talk about their electromagnetic launch infrastructure and the path she sees for Auriga across space and defense markets. And yes, we talk about whether this kind of alternative launch architecture is a good fit for Earth, or a better fit for pretty much every other rock in the solar system. This episode of Main Engine Cut Off is brought to you by 32 executive producers—Steve, Ryan, Matt from Built, Russell, Joel, David, Kris, Joakim, Fred, Pat, Matt, Theo and Violet, Natasha Tsakos, Donald, Warren, Miles O'Brien, Will and Lars from Agile, Frank, Jan, Tim Dodd (the Everyday Astronaut!), Josh from Impulse, Stealth Julian, Lee, Joonas, The Astrogators at SEE, and four anonymous—and hundreds of supporters. Topics Auriga - Electromagnetic Launch for Space and Defense Auriga Space raises $6M to shoot rockets off an electromagnetic launch track | TechCrunch The Show Like the show? Support the show on Patreon or Substack! Email your thoughts, comments, and questions to anthony@mainenginecutoff.com Follow @WeHaveMECO Follow @meco@spacey.space on Mastodon Listen to MECO Headlines Listen to Off-Nominal Join the Off-Nominal Discord Subscribe on Apple Podcasts, Overcast, Pocket Casts, Spotify, Google Play, Stitcher, TuneIn or elsewhere Subscribe to the Main Engine Cut Off Newsletter Artwork photo by SpaceX Work with me and my design and development agency: Pine Works

Fifteen years ago, the future of work seemed inevitable: bureaucracy was crumbling, adaptive organizations were the next default, and a whole movement of practitioners was going to get us there. That future never arrived. Agile transformation offices are being eliminated, the pendulum has swung hard back to command-and-control, and the companies we held up as proof are still the exceptions, not the rule. This week, Rodney and Sam take an honest look at the failure of the ways of working movement, including their own part in it. They dig into the mismatches that doomed so much of this work and get practical about what still works—because while the movement may have stalled, the moves still matter. -------------------------------- Ready to change your organization? ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Let's talk.⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Get our newsletter: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Sign up here⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠.⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Follow us: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠LinkedIn⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Instagram⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ -------------------------------- Mentioned references: Bradlees Twilight and Sunshine Zone Buurtzorg Morning Star: BNW Ep. 54 with Doug Kirkpatrick Haier "Bayer under Bill": BNW Ep. 68 with Bill Anderson Mary Parker Follett org debt: FOHR Miniseries action meeting: BNW Ep. 80 strategy stack: AWWTR EP. 2 op rhythm: BNW Ep. 118 00:00 Intro + Check-in: Your first music purchase with your own money? 05:18 The failure of the new ways of working movement 07:54 What we mean by "failure" 11:08 ZIRP, COVID, and the swing back to command-and-control 15:27 What people will buy isn't actually what they need 17:30 Selling Sunshine Zone products for Twilight Zone work 20:12 Bottoms-up to a fault 25:01 Nobody has capacity to learn anymore 28:11 Tennis vs. golf: the new consulting posture 35:23 Is local change worth it? 38:42 Failure of the movement, not the moves 40:34 Change #1 - Go deeper 42:49 Change #2 - Orient to the outcome 44:47 Change #3 - Branching roadmaps and scenario planning 46:15 Change #4 - Build organizations that benefit from change 49:15 The End Sound engineering and design by Taylor Marvin of ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Coupe Studios⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠.

Aimé Flemm: Why Solo Scrum Masters Get Fired — The Coalition Of The Willing 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.   "It doesn't make sense to try and change a system of 2,000 people on your own." - Aimé Flemm   Three months into his first gig out of consultancy, Aimé got the call: you're fired. He was at a Dutch pension fund — 2,000 people, deeply ingrained legacy structure — serving as Scrum Master to three component teams, including a UX-only team that couldn't ship anything end-to-end. Full of ambition and fresh ideas from a meetup, he pushed to restructure the teams to be cross-functional. His manager said "yeah, go for it." But Aimé was the only one pushing. He was, in his words, "poking and fighting the system way too much that they had built." So they didn't extend the contract. The lesson he carries from that firing reshaped how he approaches every change initiative since: do not try to do it alone. Find the coalition of the willing first — other Scrum Masters, other change agents, the volunteers — and build a network before you start pushing structural change. Use Scrum Master Syncs, communities of practice, even pizza budgets. Let the change spread like an oil spill. It takes time. It doesn't happen overnight. But you'll still have a job at the end of it.   In this episode, we refer to the coalition of the willing and change management tactics for Scrum Masters working in resistant systems.   Self-reflection Question: Where in your current organization are you trying to change the system alone — and who could become your first ally if you stopped pushing and started recruiting?   [The Scrum Master Toolbox Podcast Recommends]

to follow Noble: https://www.linkedin.com/in/noblegibbens

Simplicity in Agile: The Art of Maximizing Work Not DoneSimplicity is preached in Agile, yet somehow, we are tangled up in complex system processes and frameworks. And if you've worked with Agile at scale, you've probably seen it: what started as a powerful mechanism for flexibility and speed now seems more like a convoluted system of frameworks, metrics, and reports, ironically complicating the very agility it sought to enhance..This paradox isn't just a minor hiccup. It's a core problem in the way Agile is scaled today. The idea of simplifying work gets lost under layers of practices and processes that complicate the very thing Agile is meant to improve: Agility.- [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/

Reaching 1,000 podcast episodes is one of those milestones that feels impossible when you're recording episode one. Yet here we are — one thousand conversations, one thousand opportunities to learn, one thousand chances to help someone become a little better than they were yesterday. When Rob started Building Better Developers nearly a decade ago, the goal wasn't to build a massive content platform or chase download numbers. It was simpler than that: help developers grow, build better careers, work more effectively, and never stop learning. The Power of Small Improvements One theme we've returned to again and again is that meaningful growth rarely comes from a single breakthrough. It comes from consistency — a better habit, a better conversation, a better question, a better decision. The same philosophy that helps developers improve their craft is what got us to 1,000 episodes. Not because we had a master plan. Not because we knew exactly where this would go. But because week after week, episode after episode, we showed up and shared what we were learning. The same way great software gets built: one iteration at a time. More Than Just a Podcast Over the years, Building Better Developers has grown into articles, videos, interviews, challenges, and a community of people who genuinely care about getting better at what they do. We've covered software architecture and Agile practices, leadership and career growth, AI, entrepreneurship, burnout, communication, and team dynamics. Languages have evolved. Frameworks have come and gone. Entire development ecosystems have appeared almost overnight. But one thing has stayed constant: the need for developers willing to learn. Tools change. Technology changes. The ability to think, adapt, communicate, and grow never goes out of style. Thank You for Being Part of the Journey Whether this is your first episode or you've somehow been here for all 1,000 — thank you. For listening, for sharing episodes with coworkers and friends, for the emails and feedback, and for challenging us to think differently. Building Better Developers has always been a conversation, not a broadcast. Every message and discussion has helped shape what we cover and where we go. This milestone belongs as much to our listeners as it does to us. The Next 1,000 If there's one thing a thousand episodes has taught us, it's that there is always more to learn. AI is reshaping how we build software. Teams are adapting. Developers are finding new ways to create value. The future will look different from the past decade — but our mission stays the same. Keep learning. Keep growing. Keep helping developers build better careers and better lives. Here's to the next milestone. And as always — keep building better. Stay Connected: Join the Developreneur Community

Can AI make you a great leader? Josh says no, Bob agrees, and they spend this one drawing the line between the tactical work AI can absorb and the human work it can't. They get into Meta's 50-to-1 manager experiment, the unscripted moments that reveal who you really are as a leader, and why great leadership only ever gets learned in the trenches: no books, no videos, no easy button. 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!

OpenChoreo is an opinionated, “batteries included”, AI-native Kubernetes platform stack for Platform Engineers that combines GitOps, Observability, AI Agents, and Workflows into a custom K8s distribution “super pack” that is managed via Backstage, CLI, API, or MCP. Now a CNCF project.Check out the video podcast version here: 

Dix ans après le texte coup-de-poing de Mike Beedle, Coach AF rouvre le dossier dans Un Café avec Frédéric : « SAFe n'est pas Agile, SAFe n'est même pas Scrum ». Une rétrospective franche, 2016→2026, sur la mise à l'échelle de l'agilité d'affaire (scaling agile) et la question qui dérange — Mike avait-il raison?

————— COACHING —————Vous êtes leader tech ou product face à des défis majeurs ?

Jira Turned Agile Into a Micromanagement ToolThere was a time when Agile felt liberating. Teams owned their work, conversations mattered more than documentation, and progress was measured by outcomes, not activity. Then somewhere along the way, tools stepped in to “support” the process. What followed in many organizations was not support but substitution. Jira did not break Agile by design. It became the easiest place for organizations to quietly reintroduce control, visibility, and ultimately micromanagement under the label of transparency.- [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/

Dave West sits down with Mik Kersten, author of Project to Product and the upcoming Output to Outcome, to explore why AI amplification is exposing the real bottlenecks in how organizations work. Mik shares data from over 3,600 value streams showing that development teams account for just 8% of end-to-end delivery time which means making those teams faster with AI doesn't move the needle if the constraints are upstream and downstream.The conversation digs into why most organizations are measuring the wrong things (hint: token consumption is not a productivity metric), why overlay agile structures have largely failed, and why the answer isn't fewer teams it's more empowered ones. Mik introduces the core models from his new book: the outcome loop, the outcome tree, and seven organizational shifts that together make up a new operating model designed for the age of AI.Key Takeaways:The bottleneck has moved from software delivery to planning, governance, and innovation and most organizations haven't caught upMaking development teams faster with AI delivers little value if the surrounding system isn't designed around outcomesAgile as an overlay structure doesn't work it has to become the primary operating model and the actual org chartEmpowered, autonomous teams are not optional in an AI-driven world the speed of feedback loops makes half-measures unsustainableLeadership roles need to be redefined and incentive structures realigned to match the way teams are actually workingThe theory of constraints still applies in the age of AI the constraint just keeps moving, and finding it is now the critical management skillLinkshttp://outputtooutcome.org/

In this episode of All Hands on Tech, Tanya Dent, Continual Improvement Practice Lead at Nova Scotia Power, joins the conversation to explore what it really takes to build effective, resilient tech teams in fast-moving environments.With a career path that began in law before transitioning into IT, Tanya brings a practical and grounded perspective to topics like continual improvement, Agile, leadership and change readiness. The discussion dives into why some teams still feel stuck despite adopting frameworks like Scrum or Agile, how organizations can avoid change fatigue and where common bottlenecks tend to emerge in modern tech environments.The episode also explores the mindset shifts that help teams work smarter, not just faster, and what individuals can do to stay adaptable as AI and new technologies continue reshaping the workplace. Produced by Unbound Media

Royce Sin spent a decade at HSBC automating things nobody asked him to automate. He didn't ask for permission. He just did it, showed people the results, and let the time savings speak for itself. That instinct, to question why things are done a certain way and then actually do something about it, is what eventually led him into the AI space.In this episode, Peter and Dave sit down with Royce Sin to talk about what it actually takes for AI to stick inside an organization. Spoiler: it's not about the tools.We get into the tension between flexibility and reliability, why most people are being set up to fail with AI, and what it means to think like a manager when you're not one. Royce also shares his MIND framework, a practical way to think about AI adoption that he developed through hands-on work across enterprise and startup environments.There's also a good conversation about the trades, no-UI as an ideal, and why the most dangerous move in transformation is knocking down fences you don't fully understand.This week's takeaways:Think of AI as a new type of employee. Set it up for success the same way you'd set up your staff. Design roles and processes to match what it's actually good at.Not every rule is a hard rule. Before treating a constraint as a blocker, understand what's behind it. Some fences are load-bearing. Some aren't. Know the difference before you act.Don't just bring in AI. Know what outcome you're after. If you can't tell whether it's working, you don't have a tool problem, you have a clarity problem.Have a thought on any of this? Reach us at feedback@definitelymaybeagile.com

In this episode of What's Next, Aki Anastasiou speaks to Siliziwe Mafika – Director of Finance & Performance Leader at Deloitte Consulting about the realities facing African CFOs in one of the world's most complex operating environments. From currency volatility and regulatory shifts to supply chain pressure and fragmented markets, Mafika explains why resilience, rapid scenario planning and decision velocity have become essential capabilities for modern finance leaders. The conversation explores how finance functions must move beyond traditional monthly reporting cycles toward real-time insight, connected data infrastructure and AI-enabled decision-making. Mafika also unpacks the shift in talent required for the future — where finance, data science and engineering converge — and why the next generation of CFOs must translate technology into tangible business action to stay competitive.

I often talk about SpaceX being an extreme outlier in the industry and how many organizations have tried to replicate their approach, but very few (if any) have been successful. Matt Gjertsen of Built  joins me to share a take on what exactly it is internally that drives their results, how to apply it in other organizations, and to share some perspective on his time at SpaceX leading Training and Development, and from elsewhere in the industry. This episode of Main Engine Cut Off is brought to you by 32 executive producers—Steve, Ryan, Matt from Built, Russell, Joel, David, Kris, Joakim, Fred, Pat, Matt, Theo and Violet, Natasha Tsakos, Donald, Warren, Miles O'Brien, Will and Lars from Agile, Frank, Jan, Tim Dodd (the Everyday Astronaut!), Josh from Impulse, Stealth Julian, Lee, Joonas, The Astrogators at SEE, and four anonymous—and hundreds of supporters. Topics Built Leaders Minimum Viable Manager – Built Leaders Why Steve Jobs drowned the first iPod prototype | Cult of Mac The Show Like the show? Support the show on Patreon or Substack! Email your thoughts, comments, and questions to anthony@mainenginecutoff.com Follow @WeHaveMECO Follow @meco@spacey.space on Mastodon Listen to MECO Headlines Listen to Off-Nominal Join the Off-Nominal Discord Subscribe on Apple Podcasts, Overcast, Pocket Casts, Spotify, Google Play, Stitcher, TuneIn or elsewhere Subscribe to the Main Engine Cut Off Newsletter Artwork photo by SpaceX Work with me and my design and development agency: Pine Works

BONUS: Why a Former Chess Champion Thinks Your Leadership Is Stuck in the Opening Game John Whitt spent 30 years managing billion-dollar construction portfolios in corporate America — sleeping five or six nights a week in hotel beds, traveling the country, winning at someone else's game. Then he walked away. In this episode, he breaks down what chess taught him about business phases, why generosity outperforms hustle in the long run, and how the "pause factor" keeps leaders from burning out while scaling their impact. From Corporate Construction to Coaching — The Move That Changed Everything "I spent 5, sometimes 6 nights a week, sleeping in a hotel bed, traveling around the country, and it really wasn't good for my sanity, it wasn't good for my family. And then the company decided to move from Southern California to Dallas, and so that was like the — I'm not going to Dallas move, and it's time to start something else."   John's corporate career was successful by every external measure — managing $500 million construction portfolios at companies like CB Richard Ellis. But the lifestyle was hollowing him out. He'd been thinking about leaving for a while when the relocation to Dallas forced his hand. Through behavioral assessment work, he discovered coaching was where his strengths naturally pointed — it had been his primary leadership style all along. In 2010, he invested in a Focal Point coaching franchise, which gave him the tools and training without having to reinvent the wheel. Combined with 30 years of corporate relationships, it was enough to launch. His reflection on the transition is simple: "The cool thing about coaching is that we're just helping people." The Chess Game of Business — Opening, Middle, and End "The way the chess game is played at the higher levels has influenced my way of thinking essentially for the rest of my life. The opening is where you're getting started — startup business, takes a lot of hustle, a lot of energy. But then the transition happens to the middle game, where you have to think a lot more strategically, and tactically with the right move in the right order, because the wrong order will not get you the results you're looking for."   John played in the United States Chess Championships in 1976, and the framework stuck. He maps business growth to three chess phases: the opening (startup hustle, high energy, you do everything), the middle game (strategic delegation, building systems, hiring people with an ownership mindset), and the end game (transitioning assets and resources to serve the life you actually want). The danger zone is the opening-to-middle transition. Founders and leaders get trapped being the go-to person for everything — solving everyone else's problems during business hours and doing their own work after hours and on weekends. The middle game demands a different skill: learning to operate on the business instead of always in it. And it can't happen overnight — you have to prioritize what to change, in what order, or it gets jumbled up. Accomplishing Goals Through Others — The Magic of Discretionary Effort "The magic is accomplishing goals through other people, because when you do that, you're going to do big things. As an individual, you can only do so much. There's only so many hours in a day."   John keeps coming back to one idea: if you're doing it all yourself, your impact is capped at 24 hours. The real unlock is getting other people to give their discretionary effort — that extra gear where someone stays 20 minutes longer because they care, or thinks about the project at home because they're genuinely excited. Discretionary effort isn't something you can demand. It comes from inspiration. John frames it through WIIFM — "What's In It For Me?" — everybody's favorite radio station. Leaders who skip that question get compliance. Leaders who answer it get mountains moved.   The flip side is equally important: many leaders have never been on a high-performing team, so they don't know what they're missing. They accept compliance as normal. Others are smart and capable but lack the relationship skills to inspire. John's point is clear: leadership through inspiration is a learnable skill, not an innate trait. Generosity as Strategy — Time, Talent, and Treasure "Generosity always — I mean, this is unequivocal — always gives you better long-term results. If you plan to be generous, if you say this is who I am and I will do the work that's necessary to be generous, then you will always get better long-term results."   John's 4-Facet LifeShine Generosity Process puts generosity at the center of leadership — an unusual move in a world that defaults to performance metrics and execution frameworks. His argument is that generosity isn't soft. It's strategic. The framework starts with unique identity (who are you?), then moves through three dimensions: time, talent, and treasure. Most people think generosity means writing a check. John says time and talent are far more powerful. A leader who invests the time to communicate vision and inspire the team is being generous — and that generosity compounds into better team performance, stronger relationships, and less burnout over time.   The risk, though, is over-giving. Agile coaches and scrum masters who tie their identity to the work are especially vulnerable — they give so generously at work that they burn out when results don't match expectations. That's where the plan matters: define the life you want, build the business or career to serve that life, and stay disciplined about boundaries. The Pause Factor — How Leaders Protect Their Thinking "You gotta learn to say pause. That's a great idea, I understand what you're saying, we need to spend a little more time on that — so let me schedule some time later. Because right now, if I spend all that time, it's not going to get my best thinking, it's not going to get my best response."   People bring problems to leaders constantly — personal problems, business problems, urgent and not-urgent mixed together. The instinct is to solve immediately. John teaches leaders the "pause factor": acknowledge the importance of what someone brings you, then schedule dedicated time to address it properly. This isn't avoidance — it's quality control for your own thinking. When you're distracted and rushed, you give worse answers. When you pause, you also create space to ask: is this mine to solve, or does it belong to someone on my team?   John extends this to how teams bring problems: train people to come with clarity — here's the problem, here's the challenge, here's some potential solutions. That way the leader can triage effectively in a short time instead of getting pulled into an unstructured conversation that eats an hour. About John Whitt John Whitt is a leadership strategist with 30+ years of business transformation experience, from managing $500 million construction portfolios at companies like CB Richard Ellis to coaching small business owners. He's the author of Checkmate!: Winning Tactics for Translating Ideas Into Money and creator of the Whole Life Leadership experience.   You can link with John Whitt on LinkedIn.  

Hoje o papo é sobre IA no RH e na gestão de pessoas! Neste episódio, conversamos sobre como a inteligência artificial e os agentes de IA estão chegando às áreas de pessoas, e os impactos disso na gestão, nos processos seletivos, na cultura corporativa, no desenvolvimento de lideranças e até no desenho das organizações. Vem ver quem participou desse papo: Paulo Silveira, o host que quer saber se é top-down, ou bottom-up Vinny Neves, cohost, dev e professor na Alura Valéria Marretto, diretora de pessoas do Itaú Daniel Linhares, diretor de gente na Localiza Raphael Bozza, VP de pessoas no iFood Tavane Gurdos, CEO da Alura Business  Links:  CEO da CloudFlare fala sobre builders, sellers, e mensuradores Case de transformação do Itaú para Agile e Squads Texto original de Jeff Bezos sobre decisões one-way-door e two-way-doors (PDF) Jack Dorsey: From Hierarchy to Intelligence Paulo Silveira Comenta: Da Hierarquia à Inteligência, de Jack Dorsey – Hipsters Ponto Tech #514 CEO da Bolt comenta demissão em massa, incluindo o time de RH Grit, TED Talk de Angela Lee Duckworth Livro Grit: The Power of Passion and Perseverance, de Angela Lee Duckworth O Paradoxo de Stockdale Conheça o Alun Business Vá para o Vale do Silício com Paulo Silveira, Marcell Almeida, Fabrício Carraro e Marcus Mendes na “Imersão IA Sob Controle e Alura no Vale do Silício“! Vagas limitadas, corra para reservar a sua. TechGuide.sh, um mapeamento das principais tecnologias demandadas pelo mercado para diferentes carreiras, com nossas sugestões e opiniões. #7DaysOfCode: Coloque em prática os seus conhecimentos de programação em desafios diários e gratuitos. Acesse https://7daysofcode.io/ Produção e conteúdo: Alura Cursos de Tecnologia – https://www.alura.com.br Edição e sonorização: Rede Gigahertz de Podcasts

The smartest leadership tool you've got isn't in any AI model. It's your gut.Bob and Josh dig into why intuition still wins the hard calls, the ones data alone can't make for you. Bob owns up to the hires he botched by ignoring his gut. Josh shares the story of the client who told him he was being paid for his pattern recognition and how that changed everything.Reading a room. Trusting yourself before anyone else does. The 60-second habit that sharpens your instincts. And why even perfect data shouldn't get the final word.If you've been outsourcing your judgment to a chatbot, this one's for you.Your Gut Is a Great Leadership ToolStay 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!

Jennifer St Pierre is Senior Vice President of Developer Experience and Transformation at Dell Technologies, where she leads the strategy for how Dell's Infrastructure Solutions Group builds, operates, and evolves software.In this session from DX Annual, Jen argues that the biggest challenge in adopting agentic AI is not the technology itself, but the people transition behind it. Drawing on lessons from earlier shifts like Agile, DevOps, and cloud adoption, she explains why organizations that treat AI as a simple tooling rollout may get compliance, but not commitment.Jen outlines five leadership imperatives for navigating the transition: building a shared understanding of why change is happening, defining a clear future state, clarifying how roles will evolve, creating psychological safety for experimentation, and aligning metrics and organizational structures with new ways of working. Throughout the talk, she emphasizes that while AI may generate code, humans remain responsible for direction, judgment, and meaning.Where to find Jennifer St Pierre: • LinkedIn: https://www.linkedin.com/in/jennifer-st-pierre-4935a81In this episode, we cover:(00:00) Intro(00:13) Why every major technology shift is ultimately a people transition(05:00) AI-generated code and the evolving role of software engineers(07:43) The importance of developing a shared understanding(12:00) Defining a clear future state and how engineering roles will evolve(19:12) How psychological safety enables experimentation and honest feedback(22:41) Why metrics and organizational structure must evolve for the age of AI(25:40) Why leaders must drive AI transformation intentionallyReferenced:• Measuring developer productivity with the DX Core 4• Understand team effectiveness 

AI can generate an answer in seconds. The harder question is whether it is the right answer to the right question, and what you actually do with it.In this episode, Kate Megaw, Anu Smalley, and Ryan Smith dig into what “human in the loop” really means, and why so many AI transformations are failing. Forbes puts enterprise generative AI failure near 95%, and RAND says more than 80% of AI projects miss. The pattern echoes the early Agile years: chasing a shiny tool without knowing what problem it solves.AI sees the data. Humans see the story behind it. The human brings context, ethics, and judgment, and stays the ethical guardian who catches the hallucination and the answer that is right for the wrong reasons.In this episode, we discuss:The human algorithm - turning AI outputs into real outcomes through context, ethics, and judgmentWhy AI sees the data but only humans see the story behind itAnu's five workflow principles for human-led AI, including protecting the retro and naming a human decision owner for every recommendationWhy so many AI transformations fail, and how it mirrors the early Agile yearsAI-enabled vs. AI-native organizations, and why native winsUsing AI as a tool versus trusting it to run the businessChoosing the right tool for the job instead of defaulting to one model for everythingThe ethical guardian role - catching not just what AI gets wrong, but what it gets right for the wrong reasonsKnowing when to trust AI, when to challenge it, and when to override it Just because AI can do something does not mean it should. That is where humans come in. We are not using AI to replace thinking. We are creating more space for higher quality thinking for the human in the loop.Referenced in this episode: the documentary How I Became an Apocalyptimist (Daniel Rohrer), the Conan O'Brien podcast on how tools change but the task doesn't, the New York Times feature on Box adding AI roles, and the AI-native shift discussed at the Miro Canvas conference.

Maria Skvortsova: The Yes-Man Product Owner and the Scrum Master Who Became a Proxy for the Proxy In this episode, we refer to User Story Mapping and the MoSCoW prioritization method. The Great Product Owner: Structure Over Gut Feeling — When a Well-Shaped Backlog Speaks for Itself 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 indicator of a good product owner is a well-shaped backlog — with priorities, with values, with efforts. You definitely know that you pull from the top, and it is the most valuable thing you should work on." — Maria Skvortsova   For Maria, the best product owners she's worked with share one trait: they bring structure. Not rigidity — structure. They use techniques like user story mapping to make priorities visual for everyone. They use value-effort matrices instead of gut feelings. They apply methods like MoSCoW to give the backlog a clear, unambiguous order. The result? A developer never has to ask "what should I work on next?" — the answer is always at the top of the backlog. Maria, drawing on her decade as a C++ developer, knows firsthand how frustrating it is to chase down a BA or PO just to figure out what to build next. A well-ordered backlog doesn't just help the team move faster — it also makes it easier for the product owner to communicate with the business, because every decision has data behind it, not just intuition.   Self-reflection Question: Could a new team member look at your product backlog right now and immediately know what to work on next — and why that item is the most valuable? The Bad Product Owner: The Yes-Man Who Sank the Ship — When Saying Yes to Everything Means Delivering Nothing 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.   "He was always saying yes. And this led to the scope that grew and grew, until we realized we were not capable of delivering what we committed to." — Maria Skvortsova   Maria returns to her SAP migration experience for this anti-pattern. The team had a team lead acting as product owner — someone technical who saw everything as important. Every new requirement got a "yes." The scope ballooned while the iron triangle held firm: fixed cost, fixed time, no room to breathe. The team reached a breaking point where they had to admit, to each other and to the client, that delivery was impossible. Maria stepped in as what Vasco called "a proxy for the proxy" — she helped the team lead build a user story map on Miro, then facilitated a workshop with the business. Her question was disarmingly simple: "If we don't deliver this by go-live, will your product still function? If yes, it goes to release two." That reframing — not "no" but "yes, later" — gave the client clarity without triggering defensiveness. The team lead learned that business stakeholders aren't the enemy; they just need someone to help them make honest trade-offs. And saying "not now" is infinitely more useful than saying "yes" to everything and delivering nothing on time.   Self-reflection Question: When was the last time you or your product owner said "not now" to a stakeholder — and did it feel like a failure or a strategic decision?   [The Scrum Master Toolbox Podcast Recommends]

Maria Skvortsova: If Your People Feel Safe, You Succeed — Measuring What Matters as a Scrum Master 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.   "If your people feel safe and comfortable in the environment you built, then you succeed. If not, that's something you should change in your ways of working." — Maria Skvortsova   For Maria, success as a Scrum Master has nothing to do with green reports or velocity charts. She's seen green dashboards masking miserable teams and sky-high velocity hiding terrible quality. Instead, her definition of success centers on one thing: can a developer honestly tell the product owner that a story isn't ready — and not be punished for it? That's psychological safety in action. Maria measures this through healthy conflict — the team's ability to disagree constructively, to challenge each other without fear. She uses the Vacation, Shopper, Prisoner, Explorer retrospective as a gauge: are people showing up as engaged shoppers and explorers, or as reluctant prisoners? She also emphasizes a practice that many Scrum Masters overlook — having regular one-on-ones with every team member. Not just for task alignment, but to understand their cultural background and personal context. Maria works with people from many different cultures and has learned that what feels like disengagement in one culture might be deep respect in another. Her tip: before assuming you understand someone's behavior, invest in learning where they come from. The cultural awareness you build through those conversations will make you a better Scrum Master than any framework ever could.   Self-reflection Question: How do you know whether the people on your team feel safe enough to say "no" or "this isn't ready"? When was the last time you checked? Featured Retrospective Format for the Week: Stinky Fish Maria's favorite retrospective format is the Stinky Fish. The metaphor is simple and vivid: a stinky fish represents the things a team is trying to hide, the elephants in the room that everyone avoids. The longer you hide the fish, the worse it stinks. The exercise asks team members to put their "stinky fish" on the table and admit that something smells. Maria doesn't use this format every sprint — she saves it for when she senses there's something the team is avoiding. She also structures all her retrospectives using the Derby-Larsen model: opening, objective data (burn-downs, defect counts), subjective data, insights, decisions, and closing with a ROTI (Return on Time Invested) vote. For large teams, she uses breakout rooms in pairs — because when you're in a pair, it's impossible not to talk. She also uses Mentimeter for interactive slides, letting people grab their phones, relax, and contribute without the pressure of speaking up in front of 17 people.   [The Scrum Master Toolbox Podcast Recommends]

Today, we're joined by Jeff Lawson - co-founder of Twilio and now founder of Inertia, a fusion energy company commercialising the Lawrence Livermore fusion breakthrough (the first experiment to produce more energy from fusion than it consumed.)Cameron McLain talks to Jeff about why he thinks the barriers to fusion are manufacturing problems, not physics problems, what a 10-15 year timeline to grid energy actually looks like, and why he thinks SaaS is heading for a structural reckoning.He speaks about:Why the Lawrence Livermore breakthrough proved the physics works.Why the two commercial barriers are cost problems, not technical problems. For almost 100 years, fusion was '3 decades away' because nobody knew if it could work. But now it can work, the question is commercialisation.Why fusion and solar will win together. In 50 years, Jeff expects the grid to run on two sources: solar-plus-battery and fusion. How to make Agile work in hardware (and why the Gantt chart is a lie!)Why SaaS has an innovator's dilemma in the AI age.Why infrastructure companies win when the world is building.Why storytelling runs through everything: fundraising, hiring, selling.Building a purpose driven company? Read more about Giant Ventures at www.Giant.vc.Music credits: Bubble King written and produced by Cameron McLain and Stevan Cablayan aka Vector_XING.Please note: The content of this podcast is for informational and entertainment purposes only. It should not be considered financial, legal, or investment advice. Always consult a licensed professional before making any investment decisions.

Listen and subscribe to Money Making Conversations on iHeartRadio, Apple Podcasts, Spotify, www.moneymakingconversations.com/subscribe/ or wherever you listen to podcasts. New Money Making Conversations episodes drop daily. I want to alert you, so you don’t miss out on expert analysis and insider perspectives from my guests who provide tips that can help you uplift the community, improve your financial planning, motivation, or advice on how to be a successful entrepreneur. Keep winning! Two-time Emmy and Three-time NAACP Image Award-winning, television Executive Producer Rushion McDonald interviewed Bamidele Farinre. Founder of No Ceiling Consulting, a biomedical scientist, STEM expert, agile project manager, and advocate for professional development, mentorship, and removing internal and systemic limitations (“ceilings”). They discuss her STEM background, the evolving role of AI in science, the meaning of “no ceilings,” navigating personal and professional barriers, mentorship, setbacks, agile leadership, and how individuals—especially people of color—can create opportunity even in the face of bias and structural limitations.

Listen and subscribe to Money Making Conversations on iHeartRadio, Apple Podcasts, Spotify, www.moneymakingconversations.com/subscribe/ or wherever you listen to podcasts. New Money Making Conversations episodes drop daily. I want to alert you, so you don’t miss out on expert analysis and insider perspectives from my guests who provide tips that can help you uplift the community, improve your financial planning, motivation, or advice on how to be a successful entrepreneur. Keep winning! Two-time Emmy and Three-time NAACP Image Award-winning, television Executive Producer Rushion McDonald interviewed Bamidele Farinre. Founder of No Ceiling Consulting, a biomedical scientist, STEM expert, agile project manager, and advocate for professional development, mentorship, and removing internal and systemic limitations (“ceilings”). They discuss her STEM background, the evolving role of AI in science, the meaning of “no ceilings,” navigating personal and professional barriers, mentorship, setbacks, agile leadership, and how individuals—especially people of color—can create opportunity even in the face of bias and structural limitations.

Maria Skvortsova: Breaking the Factory Mindset — When a 17-Person Scrum Team Treats Development Like an Assembly Line 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.   "They wait for the story to be pushed to them, then they hand it to QAs and say 'it's not my business anymore.' We have not a Scrum team, but a factory." — Maria Skvortsova   Maria's current challenge is one that many Scrum Masters will recognize: a large distributed team — 17 people, cameras always off, only four months together — that operates like a factory instead of a collaborative unit. In refinement sessions, only the Tech Lead, BAs, and QA speak. Everyone else stays silent. When the sprint starts, developers wait for the Tech Lead to assign stories, work on them in isolation, then toss them over the wall to QA with a "not my problem" attitude. Maria and Vasco explored this challenge through a coaching conversation, identifying information loss as the core issue. Every handoff between developer and tester destroys knowledge and slows the process. Maria had already introduced desk testing — pairing a developer with a QA before deployment to walk through the code on the developer's machine. It worked well in previous teams, but this team keeps forgetting, and in a recent retrospective they even proposed creating a "handover to QA" subtask — the exact opposite of what Maria is trying to build. The experiment that emerged: find a few early adopters willing to try a deeper collaboration model where developers participate in testing and testers participate in design — starting small, measuring what changes, and letting results speak louder than process mandates.   Self-reflection Question: Where are the biggest information loss points in your team's development process, and what experiment could you run this sprint to reduce them?   [The Scrum Master Toolbox Podcast Recommends]

What Cinco de Mayo Can Teach Us About Agile - Mike CohnToday seems like a good day to celebrate Cinco de Agile.Cinco de Mayo commemorates the Battle of Puebla, when a smaller, less-equipped Mexican force defeated a larger French army.There's an agile lesson in that.The side with the bigger plan, more resources, and more confidence doesn't always win.Sometimes the winner is the side that can adapt faster.That's one of the biggest differences between agile and waterfall.Waterfall assumes that if we plan thoroughly enough up front, we can control the outcome.Agile assumes that once real work begins, we'll learn things we couldn't have known at the start.When customers change their minds, markets shift, or the team learns something new, fast feedback beats slow certainty.A team that delivers something small, gets feedback, and adjusts can outperform a team that spends months moving confidently in the wrong direction.That's the real lesson.It's not that small always beats big.It's not even that agile always beats waterfall.It's this:In changing conditions, adaptability is your biggest competitive advantage.So if your current plan feels a little too certain, it may be worth asking one uncomfortable question:What are we doing to learn faster?Because in product development, learning speed often determines who wins.Happy Cinco de Agile.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/

Maria Skvortsova: The Team That Gave Up — When Green Reports Mask a Sinking Ship 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.   "They said, 'Yeah, we know, but no one will listen to us.' And they just gave up — waiting for the ship to sink so they could swim away." — Maria Skvortsova   Maria walked into a 20-person migration team where the PowerPoint reports glowed green but the reality on the ground was covered in red flags. Developers were building features against requirements that had already changed — nobody had told them. The scope was impossibly large, and when Maria asked the team why they hadn't raised a red flag, the answer shook her: "No one will listen to us." The team had given up. They were waiting for the project to fail so they could leave. Maria's first instinct was to observe — spend weeks understanding the dynamics, the communication patterns, the culture. But she learned the hard way that when a team is already drowning, there's no time for a slow ramp-up. She needed to act immediately. Her breakthrough came from a simple technique: replacing some daily standups with an async RAG (Red-Amber-Green) status system in Jira. Team members just chose a color for each story — no explanation needed. It gave them psychological safety to signal problems without speaking up in a 20-person meeting. From there, Maria broke the team into smaller cross-functional groups — one QA, one developer, one consultant — so they could actually discuss features instead of hiding behind silence.   In this episode, we refer to Zombie Scrum Survival Guide by Christiaan Verwijs, Johannes Schartau, and Barry Overeem. Also check out the episode with Barry and Christiaan, authors of the book, on the podcast.   Self-reflection Question: When you join a new team and sense that something is deeply wrong, how long do you wait before acting — and is that waiting period serving the team or just your own comfort? Featured Book of the Week: Zombie Scrum Survival Guide by Christiaan Verwijs, Johannes Schartau, and Barry Overeem Maria chose Zombie Scrum Survival Guide because, as she puts it, "Most Scrum Masters learn by the happy path. We all know how it should be. But we rarely think about how it should not be." The book focuses on detecting anti-patterns early — before they become entrenched behaviors that are much harder to break. Maria finds it especially valuable because it provides concrete experiments you can try with your team to shake off the zombie symptoms. Her advice: start here, because understanding what bad looks like is just as important as knowing the ideal.   [The Scrum Master Toolbox Podcast Recommends]

This conversation was recorded at GOTO Copenhagen 2025.https://gotocph.comMartin Fowler - Pioneer of Various Topics around Object-Oriented Technology & Agile MethodsKent Beck - Software Engineer & Creator of Extreme ProgrammingRESOURCESMartinhttps://x.com/martinfowlerhttps://www.martinfowler.comhttps://toot.thoughtworks.com/@mfowlerhttps://www.linkedin.com/in/martin-fowler-comKenthttps://bsky.app/profile/kentbeck.bsky.socialhttps://www.kentbeck.comhttps://github.com/KentBeckhttps://twitter.com/KentBeckhttps://www.linkedin.com/in/kentbeckhttps://tidyfirst.substack.com/aboutDESCRIPTIONMartin Fowler and Kent Beck — two of the authors of the Agile Manifesto and perhaps the most influential duo in software engineering history — reunite for an unscripted conversation spanning thirty years of friendship, craft, and the relentless pace of change. They discuss how AI ("the Genie") has become a genuine part of both their workflows: Kent uses it as an endlessly patient tutor for exploration between features, while Martin distinguishes between AI as a tool for talking to computers versus the irreplaceable human skill of talking to the people who need software built. Both are optimistic about the future, though Kent's optimism takes characteristically sharp form: he expects the industry to keep making the same mistakes, which means he'll still be employed teaching the same lessons 20 years from now.The conversation also revisits the Agile Manifesto at nearly 25 years old, with both reflecting on what Extreme Programming got right — feedback loops, testability, evolutionary design — and what the broader adoption missed or diluted. Martin is candid that progress in software has been slower than he'd like, though he points to a "forest" of practitioners who have genuinely advanced the craft. On the question of a Manifesto reunion, both gently redirect: it belongs to the next generation now. Their closing advice to a junior developer in the audience is perhaps the most memorable exchange in the whole session — use the gaps between features to learn, and never forget that understanding the domain and the people in it is ultimately what separates good programmers from great ones.Read the full abstract here:https://gotocph.com/2025/sessions/3780RECOMMENDED BOOKSMartin Fowler • Refactoring • https://amzn.to/3EVcHXQMartin Fowler & Pramod Sadalage • NoSQL Distilled • https://amzn.to/3ChIpu7Martin Fowler • Patterns of Enterprise Application Architecture • https://amzn.to/3lp4sIqMartin Fowler • Domain-Specific Languages • https://amzn.to/3nzOIFkMartin Fowler • UML Distilled • https://amzn.to/3kahjyAKent Beck • Tidy First? • https://amzn.to/4gscjjKKent Beck & Cynthia Andres • Extreme Programming Explained • https://amzn.to/3sBASDGKent Beck • Test Driven Development • https://amzn.to/3U4AXLsKent Beck, Fowler, John, William, Don & Gamma • Refactoring • https://amzn.to/3SFBYbNKent Beck • Implementation Patterns • https://amzn.to/3sBlCGLBlueskyInstagramLinkedInFacebookCHANNEL MEMBERSHIP BONUSJoin this channel to get early access to videos & other perks:https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/joinLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Maria Skvortsova: When Agile Labels Hide Waterfall Reality — A Scrum Master's Wake-Up Call in SAP Migration 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.   "I realized that even if I like Scrum and Agile, and I think they are really good ways of thinking, some areas cannot adapt them because they are completely different from the mindset and ways of working." — Maria Skvortsova   Maria came to Agile with the fire of a true believer. After a decade as a C++ developer, she'd found something that matched how she thought and felt about building software — something that went beyond controlling budgets and roadmaps. When a boutique SAP consulting company hired her as an Agile coach to transform their entire organization, she was all in. She built what she describes as a "really good" training for senior management, designed to sell them on Agile ways of working. But when she stepped out of the PMO role and into a real SAP migration project as delivery manager, the ground shifted beneath her. The iron triangle — fixed cost, fixed scope, fixed time — ruled everything. Teams ran "sprints" that were really just boxed iterations with no feedback loops, no value delivery, just a march toward a go-live date. Maria realized she was putting Agile labels on a fundamentally waterfall process. The hardest part wasn't the discovery — it was accepting that she needed to redirect her energy to environments where Agile could genuinely take root, rather than forcing it where the mindset simply didn't exist. Her advice: recognize when labels don't match reality as quickly as possible, and have the courage to choose environments that align with how you want to work.   Self-reflection Question: Are you putting Agile labels on processes that are fundamentally waterfall? How quickly would you recognize the mismatch — and what would you do about it?   [The Scrum Master Toolbox Podcast Recommends]

The current moment feels like 'the end'. If you're truly Agile, the opportunities are everywhere. Tech feels like mayhem right now, but that creates MORE opportunity to envision the future, and place a bet on an experiment that could change everything. Isn't that what we're supposed to be good at?

Every leader gets it wrong eventually. The question is what you do next.Josh and Bob dig into one of the hardest things any leader faces: admitting a mistake out loud. Not waffling, not deflecting, not the classic move of saying the wrong thing louder and hoping it becomes true. Actually owning it.They get into why doubling down is so tempting and so corrosive, how your team almost always knows you're wrong before you do, and why vulnerability ends up being a far stronger position than false certainty. Josh tells the story of bombing an Amazon interview over their "you're right a lot" principle, and how it took him years to understand what that line was actually saying. Bob makes the case that being wrong with your team is no different than being wrong with your spouse or your kids, and that bad news never ages well.If you've ever sat in an all-hands watching everyone trade that look because the person on stage just said something nobody in the room believes, this episode is for you. The world isn't binary. It's mostly gray, and learning to lead in that gray is the whole job. 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!

Blue Origin's New Glenn blew up on LC-36 last night during a static fire test, Starship flew its 12th flight, and NASA had a series of updates on its Moon Base program, including LTV awards, launch and landing contracts, and a somewhat unexplained branding exercise. This episode of Main Engine Cut Off is brought to you by 32 executive producers—Lee, Steve, Josh from Impulse, Kris, David, Miles O'Brien, Tim Dodd (the Everyday Astronaut!), Jan, Donald, Frank, Better Every Day Studios, Stealth Julian, The Astrogators at SEE, Ryan, Matt, Warren, Will and Lars from Agile, Pat, Fred, Joonas, Theo and Violet, Russell, Joel, Natasha Tsakos, Joakim, and four anonymous—and hundreds of supporters. Topics Here's why the failure of Blue Origin's New Glenn rocket is so catastrophic - Ars Technica NASA takes steps toward building Moon Base, including discussing a "perimeter" - Ars Technica NASA selects four companies for initial moon base awards - SpaceNews The Show Like the show? Support the show on Patreon or Substack! Email your thoughts, comments, and questions to anthony@mainenginecutoff.com Follow @WeHaveMECO Follow @meco@spacey.space on Mastodon Listen to MECO Headlines Listen to Off-Nominal Join the Off-Nominal Discord Subscribe on Apple Podcasts, Overcast, Pocket Casts, Spotify, Google Play, Stitcher, TuneIn or elsewhere Subscribe to the Main Engine Cut Off Newsletter Artwork photo by NASA/Bill Ingalls Work with me and my design and development agency: Pine Works

Njegos Ilic: The "Painting by Numbers" Scrum Master vs. The Quiet Leader Who Made the Team Self-Sufficient In this episode, we refer to the concepts of Scrum Master as facilitator and team empowerment. The Bad Scrum Master: The "Painting by Numbers" Approach That Leaves Product Owners Working Alone 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.   "You basically feel totally alone because you are trying to deliver value as a team, but if nobody asks anything and nobody challenges anything, you end up defining everything yourself." - Njegos Ilic   Njegos describes the worst Scrum Master anti-pattern he's witnessed: the "painting by numbers" Scrum Master who runs every ceremony by the book — dailies, refinements, plannings, retros, reviews — but without understanding the purpose behind any of them. The meetings become a reporting cycle: "What did you do yesterday?" with no interaction, no challenging, no real engagement. From the product owner's perspective, this is devastating. Njegos describes feeling completely alone — trying to deliver value as a team while nobody engages, nobody asks questions, nobody pushes back on assumptions. The downstream effect is predictable: gaps that could have been caught early with a single conversation only surface during development or after deployment. Worse, the lack of engagement creates doubt and overthinking — the product owner starts over-defining requirements because there's no feedback loop, which reinforces the very passivity that caused the problem.   Self-reflection Question: Are the ceremonies on your team creating genuine engagement and learning — or have they become a reporting cycle that nobody actually needs? The Great Scrum Master: The Quiet, Impactful Leader Who Made the Team Self-Sufficient 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 best Scrum Masters I worked with were invisible — they knew always when to speak, they sensed the pulse of the team, and they weren't afraid to jump in when needed." - Njegos Ilic   The best Scrum Masters Njegos has worked with share a common trait: they were almost invisible. They didn't dominate meetings or insert themselves where they weren't needed. But they were always present — sensing the team's pulse, knowing when to step in, unafraid to say "we're out of time, let's take this offline." They were knowledgeable about the product, which earned them genuine respect from developers. And perhaps most powerfully, they delegated facilitation itself. Njegos shares an example where a Scrum Master introduced a round-robin system: when new developers joined the team, everyone took turns facilitating meetings — planning, retros, dailies. This wasn't just delegation for efficiency; it was empowerment by design. Team members who facilitated a retrospective suddenly understood how hard it is to lead one. That empathy changed how they participated when someone else was facilitating. The Scrum Master remained the guide, but the team grew its own capacity to self-organize.   Self-reflection Question: If your Scrum Master disappeared tomorrow, would your team know how to facilitate its own ceremonies — and if not, what does that say about how the role is being used?   [The Scrum Master Toolbox Podcast Recommends]

Njegos Ilic: Why Measuring Your Product Bets Is the Key to Product Owner Success 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.   "If you cannot measure what you build, you will just be depending on who is screaming the loudest and using your gut feeling — which is not a good thing long term." - Njegos Ilic   Njegos defines product owner success through three pillars: the ability to measure product bets, deep knowledge of the industry and product, and the humility to admit mistakes and be challenged. The measurement piece is central — without it, he argues, you're flying blind, making decisions based on opinions rather than evidence, reacting to whoever screams loudest rather than what the data shows. But Njegos is honest that not every environment makes measurement easy. Some companies lack the tooling, the culture, or the historical infrastructure to set up proper analytics. In those situations, he turns to user interviews as the next best thing — getting direct feedback from users, even though he acknowledges that opinions are still limited without data to fact-check them against. His most powerful suggestion: invite the whole team to user interviews, not just the product trio. When developers hear directly from users, they connect to real-world problems, and conversations during refinements become richer and more grounded.   In this episode, we refer to The Mom Test by Rob Fitzpatrick and Shift: From Product to People by Michael Dougherty and Pete Oliver-Kruger.   Self-reflection Question: How do you currently measure whether the features you shipped actually delivered the value you expected — and if you can't measure it, what's your fallback? Featured Retrospective Format for the Week: Start With a Relaxing Exercise Njegos doesn't advocate for a specific retrospective template — and that's the point. From his product owner perspective, he values retrospectives that begin with a relaxing, informal exercise to set the tone. Not everything needs to feel like business as usual. This casual opening allows people to connect as humans first, which opens them up to think differently about what they learned during the sprint. Njegos is candid about the reality: some teams love icebreakers, while others find them childish and just want to get to the point. His advice is to sense the pulse of the team and adapt. The format matters less than whether it creates an environment where people can be honest about what went well, what didn't, and what to improve. A Scrum Master who reads the team's vibe and adjusts accordingly — that's what makes the difference.   [The Scrum Master Toolbox Podcast Recommends]

AI Breaks the Agile Sweet Spot For Team SizeHow big should your Agile taem be? Does Agentic AI change everything? Lets listen and explore how team sizes may EXPLODE! 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/

Njegos Ilic: How a Miro Board Experiment Changed the Way His Team Understood the Big Picture 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.   "Every feature is a product bet. I would call this a process bet — just try to see what works best for you." - Njegos Ilic   Njegos shares a change story from his time working with a tech lead who had previously been a Scrum Master — a partnership that made all the difference. Together, they introduced a simple but powerful change: visualizing the team's work on a Miro board instead of relying on a standard ticket board with cards and status columns. They mapped out concepts, connected ticket numbers to a visual representation of how different pieces of work fit together, and used this board during dailies and refinements to track progress in context. The change wasn't imposed top-down — Njegos and his tech lead simply said, "Give us one sprint to try this. If it doesn't work, we drop it." The result was immediate: dailies became more engaging, the team could see how their individual work connected to the bigger picture, and Njegos found it much easier to track progress as a visual thinker. His advice for Scrum Masters and product owners who want to introduce something similar is refreshingly simple — frame it as a "process bet," just like you'd frame a product bet. Try it, measure what happens, and if it doesn't work, drop it and try something else. The willingness to experiment with your own process is a prerequisite for experimenting with the product itself.   Self-reflection Question: What "process bet" has your team been avoiding — and what would it take to just try it for one sprint?   [The Scrum Master Toolbox Podcast Recommends]

Retrospectives are supposed to help teams improve, but for many teams they slowly become rushed, repetitive, or skipped altogether. In this episode, Brian Milner and Cort Sharp unpack why retrospectives lose their value and what Scrum Masters and leaders can do to make them useful again.   Overview When a team stops engaging in retrospectives, it is usually a symptom of something deeper. Sometimes the format has become stale. Sometimes the team no longer feels safe being honest. And sometimes the biggest issue is that retrospectives create plenty of discussion but very little meaningful change. In this conversation, Brian and Cort explore the most common reasons retrospectives begin to fail and how teams can rebuild trust in the process. They discuss the importance of psychological safety, why teams should focus on fewer actions instead of trying to fix everything at once, and how Scrum Masters can better tailor retrospectives to the personalities and working styles of their teams. They also share practical ideas for making retrospectives more engaging, more actionable, and more valuable over time.   References and resources mentioned in the show: Cort Sharp Amy Edmonson, Psychological Safety #139: The Retrospective Reset with Cort Sharp #141: Cooking Up a Killer Retrospective with Brian Milner The Empirical Retrospective Approach by Mike Cohn 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 a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast 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. Cort Sharp is the Scrum Master of the producing team and the Agile Mentors Community Manager. In addition to his love for Agile, Cort is also a serious swimmer and has been coaching swimmers for five years.

AI can help product owners move faster, but faster is not always better. In this episode, Lance Dacy and Brian Milner explore where AI genuinely improves product work and where teams still need strong judgment, clear priorities, and real customer understanding.   Overview   As development teams adopt AI tools at a rapid pace, product owners are under pressure to keep up. Brian and Lance discuss how AI is already changing backlog refinement, product discovery, stakeholder communication, and day-to-day product work. They also explore why many teams are still using AI too narrowly and missing larger opportunities to improve decision-making and collaboration.   The conversation stays grounded in practical application rather than hype. Lance shares where AI can save product owners meaningful time, where human judgment still matters most, and why teams need to be careful about treating AI-generated output as automatically correct. If your team is trying to understand how AI fits into modern product leadership, this episode offers a realistic starting point.   References and resources mentioned in the show:   Lance Dacy #117: How AI and Automation Are Redefining Success for Developers with Lance Dacy #164: Why Innovation Efforts Fall Flat with Tendayi Viki AI Doesn't Eliminate Agile Teams — It Increases the Need for Great Ones by Mike Cohn 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 a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast 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. Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant's heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.

Many leaders assume Agile breaks down in highly regulated environments. John Holmes has spent years proving the opposite inside aerospace, defense, and space programs where the cost of failure is extremely high.   Overview   In this episode, Brian Milner talks with Scrum Inc. Fellow John Holmes about what it actually takes to apply Scrum in complex defense and aerospace organizations. From military programs to space systems, John explains why Agile is often less about moving faster and more about creating visibility, improving communication, and reducing the risk of major surprises late in delivery.   John also shares practical lessons from coaching teams inside highly disciplined environments where command-and-control leadership has traditionally dominated. The conversation explores how Agile can strengthen discipline rather than weaken it, why trust and training matter more than process compliance, and how small operational changes can create meaningful improvements in delivery, alignment, and team effectiveness.   References and resources mentioned in the show:   John Holmes #107: Transforming Organizational Mindsets with Bernie Maloney #108: Adaptive Organizations with Ken Rickard There Is No End State When Transitioning to Agile by Mike Cohn 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 a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast 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. John Holmes is a Scrum Inc. Fellow who has spent decades helping aerospace, defense, and government organizations apply Agile and Scrum in some of the world's most complex environments. From launching Scrum for Space at Lockheed Martin to training thousands of leaders and teams since 2005, John brings a practical, field-tested perspective on what it really takes to make Agile work where the stakes are high.

A lot of organizations say they've “gone Agile,” but still struggle with missed deadlines, unclear priorities, and teams that feel busy without delivering better outcomes. In this episode, Scott Dunn joins Brian Milner to unpack why Agile ROI is so often misunderstood and what leaders should actually be measuring instead.    Overview What does a successful Agile transformation actually look like? Too often, organizations adopt Scrum or Agile practices because everyone else is doing it, without first defining the business outcomes they hope to achieve. The result is predictable: teams follow the motions of Agile while leadership struggles to see measurable value. In this conversation, Brian Milner and Scott Dunn explore why ROI conversations around Agile frequently go off track and how leaders can reconnect Agile practices to meaningful business goals like faster delivery, improved customer satisfaction, stronger collaboration, and better adaptability. They discuss the hidden cost of operationalizing Agile too early, why coaching and leadership alignment still matter, and how the rise of AI makes strong Agile fundamentals more important, not less.   References and resources mentioned in the show: Scott Dunn #104: Mastering Product Ownership with Mike Cohn #132: Can Nice Guys Finish First? with Scott Dunn Do the Proven Benefits of Agile Training Justify the Costs? by Mike Cohn 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 a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast 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. Scott Dunn is a Certified Enterprise Coach and Scrum Trainer with over 20 years of experience coaching and training companies like NASA, EMC/Dell Technologies, Yahoo!, Technicolor, and eBay to transition to an agile approach using Scrum.

Former NASA Administrator Jim Bridenstine has joined Quantum Space as CEO. We talk about what the company is working on, the Ranger spacecraft, how they fit into the industry, where he sees their market going, and what it's like to be a former NASA Administrator running a company in the industry. This episode of Main Engine Cut Off is brought to you by 32 executive producers—Fred, Frank, Better Every Day Studios, Tim Dodd (the Everyday Astronaut!), David, Steve, Kris, Stealth Julian, Will and Lars from Agile, The Astrogators at SEE, Pat, Warren, Josh from Impulse, Miles O'Brien, Russell, Matt, Natasha Tsakos, Joakim, Lee, Theo and Violet, Joonas, Joel, Jan, Donald, Ryan, and four anonymous—and hundreds of supporters. Topics Quantum Space hires Bridenstine as CEO - SpaceNews Quantum Space to build spacecraft in Tulsa - SpaceNews Quantum Space acquires Phase Four propulsion assets - SpaceNews Quantum Space raises $40 million - SpaceNews The Show Like the show? Support the show on Patreon or Substack! Email your thoughts, comments, and questions to anthony@mainenginecutoff.com Follow @WeHaveMECO Follow @meco@spacey.space on Mastodon Listen to MECO Headlines Listen to Off-Nominal Join the Off-Nominal Discord Subscribe on Apple Podcasts, Overcast, Pocket Casts, Spotify, Google Play, Stitcher, TuneIn or elsewhere Subscribe to the Main Engine Cut Off Newsletter Artwork photo by NASA/Bill Ingalls Work with me and my design and development agency: Pine Works

Njegos Ilic: Why the Product Trio Breaks the Hand-Off Mentality That Kills Team Engagement 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.   "I can't change people, but I can definitely involve them." - Njegos Ilic   Njegos describes a pattern he's encountered multiple times as a product owner: teams where engagement is almost nonexistent. He walks into a refinement session, presents ideas, asks for feedback — and gets crickets. Nobody pushes back, nobody asks questions, nobody challenges the assumptions. The result is a product owner working in isolation, defining everything alone, only to discover gaps during development that could have been caught early with a single conversation. Njegos is honest about the limits of what any one person can do — you can't change people's personalities, and expecting a Scrum Master to do so is unrealistic. But what you can do is involve people. His approach when joining a new team: don't come in announcing how things will work. Instead, learn how the team already works, meet them where they are, and then find ways to fit new concepts into their existing rhythm. For the non-negotiable things — the red lines — he's precise, open, and always provides an alternative rather than just pushing his way.   In this segment, we talk about Discovery and Delivery and the Product Trio concept.   Self-reflection Question: When you join a team meeting and get silence instead of feedback, do you assume agreement — or do you treat it as a signal that something deeper needs to change? Featured Book of the Week: Inspired by Marty Cagan Njegos recommends Inspired by Marty Cagan as the book that most shaped his approach to product ownership. He highlights the entire SVPG series — including Empowered and Transformed (available as the Product is Hard SVPG Box Set) — but points to the Product Trio concept as especially powerful. As Njegos puts it, the Product Trio — bringing together a product manager, a tech lead, and a designer — removes the hand-off mentality where each discipline works in isolation. Instead of the product owner defining everything alone and handing it to the team, the trio shapes problems together during discovery, so that by the time work reaches the team, there's shared understanding of why they're building something, not just what to build.   [The Scrum Master Toolbox Podcast Recommends]

Njegos Ilic: Why Saying Yes to Every Stakeholder Request Is the Fastest Way to Fail as a Product Owner 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 game is rigged because they are strong personalities, they want to get things done, but you don't have a magic stick — it's really hard to deliver results if you cannot say no." - Njegos Ilic   Njegos shares a failure from early in his career as a product owner in startup environments, where he found himself saying yes to every stakeholder request. Working with strong-willed founders who expected things done their way, Njegos fell into the trap of trying to please everyone — building everything that was asked without pushing back. The result was predictable: scattered priorities, no room to pivot, and a product backlog driven by the loudest voice in the room rather than real user needs. But Njegos frames this failure with a perspective that product owners at any stage can learn from. He compares the learning process to watching children learn to walk — stumbling and falling is not a sign of weakness, it's a necessary step in the process of growing. His advice to product owners currently stuck in this pattern: don't try to avoid failures too hard, because you might prevent yourself from learning the most important lessons. Instead, treat failure as a feedback loop — something happened, you can measure it, and you can change your approach. The key is doing the actual work of reflection: What did I do? What should have been different? What wasn't possible to change, and why?   Self-reflection Question: When was the last time you said yes to a stakeholder request even though your gut told you it wasn't the right call — and what would it take for you to say no next time?   [The Scrum Master Toolbox Podcast Recommends]