Podcasts about Agile

Casey Dreier of The Planetary Society joins me to talk about the NASA FY2026 budget, the early days of the Administrator Isaacman era, and how we feel going into Artemis II.This episode of Main Engine Cut Off is brought to you by 33 executive producers—Matt, Fred, Will and Lars from Agile, Kris, Lee, Jan, Frank, Miles O'Brien, Josh from Impulse, Theo and Violet, Ryan, Joakim, Stealth Julian, Heiko, Tim Dodd (the Everyday Astronaut!), Better Every Day Studios, Joel, Steve, Joonas, The Astrogators at SEE, Pat, Warren, Natasha Tsakos, Russell, David, Donald, and four anonymous—and hundreds of supporters.TopicsCasey Dreier | The Planetary SocietyThe Planetary SocietyYou just saved NASA's budget | The Planetary Society2025 Impact Report | The Planetary SocietyThe ShowLike the show? Support the show on Patreon or Substack!Email your thoughts, comments, and questions to anthony@mainenginecutoff.comFollow @WeHaveMECOFollow @meco@spacey.space on MastodonListen to MECO HeadlinesListen to Off-NominalJoin the Off-Nominal DiscordSubscribe on Apple Podcasts, Overcast, Pocket Casts, Spotify, Google Play, Stitcher, TuneIn or elsewhereSubscribe to the Main Engine Cut Off NewsletterArtwork photo by Blue OriginWork with me and my design and development agency: Pine Works

Cristina Cranga: When Teams Stop Testing Reality and Fall Into Decision Hallucinations 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.   "Over time, what I notice is that teams stop testing reality. They optimize execution around constraints that might no longer exist." - Cristina Cranga   Cristina introduces a powerful concept she calls "decision hallucinations"—the perception of constraints and boundaries that aren't actually real or present. In her experience working with teams in complex matrix environments, she noticed a troubling pattern: team members would say things like "we can't change this because it's already decided" or "the priority comes from the top level" without ever verifying these assumptions.  The impact on team behavior was significant—teams stopped asking questions, stopped having conversations with stakeholders, and began operating within perceived limitations rather than actual ones. Cristina emphasizes that as Agile practitioners, our work isn't just about ceremonies and metrics—it's about supporting and facilitating decision processes.  When she encouraged teams to ask better questions like "Is this an assumption-based decision or an explicit shared choice?", something beautiful happened: options reappeared, conversations changed, and teams realized they were constrained by perception rather than reality. She uses the famous duck vs. rabbit optical illusion from psychology to illustrate how our brains can only see one reality at a time, making the case that we must constantly test our view of reality through continuous conversations with stakeholders.   In this episode, we refer to the work of Esko Kilpi on conversations and the duck vs rabbit image from psychology.   Self-reflection Question: When was the last time you challenged an assumption your team operates under, and what did you discover when you tested that reality?   [The Scrum Master Toolbox Podcast Recommends]

Matt Ezyk has decades of experience building, scaling and leading digital commerce technology and strategy at some of the most innovative companies in the world. Matt serves as Senior Director of Engineering, Ecommerce at Hanna Andersson which is a leading direct-to-consumer premium children's apparel and lifestyle brand. Prior to joining Hanna Andersson, he led digital at Pet Supermarket with oversight of product and engineering. Additionally he served as Director of Functional Architecture and Director of PMO at RafterOne (f/k/a PixelMedia) with operational oversight of teams working with iconic brands like Skechers and LL Bean. Matt also served in progressive leadership roles at Accenture, Merkle (f/k/a LiveArea) and several startups working with hundreds of global brands like Uniqlo, Disney, Revlon, Tapestry and many more. Matt brings to retailers and DTC brands a deep expertise in developing and implementing diverse end-to-end commerce strategies. In This Conversation We Discuss: [00:00] Intro[00:24] Sponsor: Taboola[01:41] Connecting tech decisions to business growth[04:36] Comparing agency and brand-side perspectives[07:24] Sponsor: Next Insurance[08:37] Delivering progress customers can feel[09:58] Choosing platforms based on business maturity[13:03] Callouts[13:13] Auditing tech to recover lost conversions[15:31] Reducing redundancy to improve performance[17:47] Evaluating third-party tools for value[19:36] Sponsor: Electric Eye[20:44] Improving conversion with UX and engineering[22:25] Augmenting team expertise with AI tools[27:46] Balancing speed with long-term scalabilityResources:Subscribe to Honest Ecommerce on YoutubeKids clothes from playtime to bedtime hannaandersson.com/Follow Matt Ezyk linkedin.com/in/mezykReach your best audience at the lowest cost! discover.taboola.com/honest/Easy, affordable coverage that grows with your business nextinsurance.com/honest/Schedule an intro call with one of our experts electriceye.io/connectIf you're enjoying the show, we'd love it if you left Honest Ecommerce a review on Apple Podcasts. It makes a huge impact on the success of the podcast, and we love reading every one of your reviews!

Mohini Kissoon: The One Question That Transforms Messengers Into Product Owners The Great Product Owner: The Calm Navigator Who Shields the Team Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "He said "no" often, but he did it with such clarity that people respected it. It's not just no—it's giving the reason why." - Mohini Kissoon   Mohini has had the privilege of working with many great Product Owners, but one stood out for his calm demeanor and ability to navigate complex situations. Whatever stakeholders threw at him, he remained professional and calm—and critically, he never transferred that pressure onto the team. He had built strong relationships with stakeholders and was the go-to person who commanded respect across the organization.  When stakeholders demanded features that didn't align with team goals, he would acknowledge the request, explain the trade-offs, and offer to revisit it once the current direction was validated. He said no often, but with such clarity and reasoning that people respected his decisions.  This Product Owner also shielded the team from ad hoc requests, handling stakeholder bypass attempts so developers could maintain focus. He would only bring truly urgent items—like compliance issues—directly to the team.  With his helicopter view, he understood how incoming work would impact different stakeholders and parts of the business. Most importantly, he was a good listener who gave the team space to grow and experiment while challenging them constructively.   Self-reflection Question: When you work with your Product Owner, do they shield the team from chaos or pass it through unfiltered—and how might you help them develop that protective capability? The Bad Product Owner: The Messenger Who Couldn't Say No 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.   "When the team would ask 'why are we building this?' the answer would be 'because sales asked for it.' There was no triaging, no challenging stakeholders—just saying yes." - Mohini Kissoon   Mohini shares a story about a Product Owner who appeared to be doing everything right on paper: attending ceremonies, responding to questions, being present for the team, and working closely with stakeholders. But the team was constantly frustrated with scope creep, and the root cause was that this Product Owner was operating as a messenger, not a decision maker. She would bring requests from stakeholders directly into the backlog with no prioritization based on value and no pushback.  Major new work would appear at sprint planning that hadn't been discussed during backlog refinement. The team was committing to 100 story points but only completing 40, with items constantly carrying over.  When Mohini was brought in to help, she asked one simple question that changed everything: "What is the vision for your product?" The Product Owner couldn't answer—because nobody had ever asked her before.  Mohini ran a product vision workshop with her and key stakeholders, created a one-page strategy identifying target users, core problems, and success metrics, and established a working agreement that backlog items must align with identified goals. She also introduced prioritization sessions involving stakeholders. The transformation came when the Product Owner finally felt equipped to say no with informed reasoning.   Self-reflection Question: Does your Product Owner have a clear product vision they can articulate, and if not, what workshop or conversation could you facilitate to help them discover it?   [The Scrum Master Toolbox Podcast Recommends]

Mohini Kissoon: The Language Test That Reveals True Team Ownership 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.   "When I see my team taking ownership of their work, taking ownership of the Scrum events, asking questions, challenging each other constructively without waiting for me—that's when I know I've done my job." - Mohini Kissoon   Mohini defines success for Scrum Masters through three distinct lenses. First, she looks for teams that take ownership—of their work, of the Scrum events, of asking questions and challenging each other constructively without waiting for her to intervene. When she can observe from the sidelines while the team self-manages, she knows she has shaped the right conditions for them to thrive.  Second, success means having metrics that demonstrate improvement over time: team happiness, flow, and how individuals have grown in their roles. These metrics aren't just for the team—they're for sharing with leadership to show the positive impact created.  Third, and perhaps most importantly, success is about creating psychological safety where team members feel comfortable disagreeing, engaging in healthy conflict, and being creative without taking things personally.  One powerful indicator Mohini uses is the language of the team: do they say "their sprint goal" or "our sprint goal"? This subtle shift from passive to possessive language reveals the true level of ownership the team has developed. It's an easy thing to observe but often missed by Scrum Masters.   Self-reflection Question: Listen carefully in your next sprint planning or daily scrum—does your team use "we" and "our" language, or do they speak about the work as something external to them? Featured Retrospective Format for the Week: Timeline Retrospective Mohini finds herself returning to the Timeline retrospective more than any other format, especially when a team has been going through something complex—a difficult sprint, a major release, or a quarterly review with a working group. The format helps people pause and reflect on what has happened before jumping into "what do we change next?" In a physical room, she draws a line on the whiteboard and invites people to add sticky notes for key moments that stood out during the period. In virtual settings, she uses a digital whiteboard. The moments can be good, bad, confusing, or stressful—anything significant. The exercise starts silently, giving everyone space to think without being influenced. Then the team walks through the timeline chronologically, sharing stories behind their notes.  What makes this format powerful is that it creates shared understanding before asking for solutions. Team members often realize that others experienced the same event differently. However, Mohini warns that the timeline can feel overwhelming when you see all the stickies on the board. The key is to build a bridge before jumping to actions: have the team identify patterns, vote on items to discuss further, and only then derive concrete actions from the prioritized items.   [The Scrum Master Toolbox Podcast Recommends]

Agile in 2026 Looks Nothing Like ScrumThat delay cost us 42,000 failed checkout attempts and a week of executive explanations. Nothing was broken in the code. The failure was procedural. The fix was ready. The sprint boundary said no.That was the moment we stopped pretending Scrum was helping us ship.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/

Mohini Kissoon: Beyond the AI Fear—Discovering What Makes Scrum Masters Truly Irreplaceable 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 real challenge isn't whether AI will replace Scrum Masters. It's whether we understand what parts of our work are actually irreplaceable—and whether we're spending our time on those things." - Mohini Kissoon   Mohini is wrestling with a challenge that's coming up repeatedly in conversations with Agile coaches and Scrum Masters: the anxiety around AI and what it means for their role. She hears questions like "Will AI replace Scrum Masters?" but believes we're asking the wrong question. The real challenge is understanding which parts of our work are truly irreplaceable and demonstrating value in those areas.  People might think that AI can generate sprint reports and analyze team metrics—so why do we need Scrum Masters? But what's missing is the human touch: reading the room, sensing unspoken tension, building trust through presence, and asking questions that shift perspectives. Mohini and Vasco explore how the Scrum Master role may have accidentally become defined by process and structure rather than impact on teams.  The solution lies in showing value through concrete metrics—demonstrating improvement in team happiness, flow, cycle time, and lead time. Scrum Masters need to use storytelling and create history that shows the before and after. They should leverage champions from teams they've worked with to share testimonials. We are like diplomats: we work through influence and need allies both inside and outside the team to support our work.   Self-reflection Question: If AI could handle all the administrative and mechanical aspects of your Scrum Master role tomorrow, what would you spend your time doing—and are you already investing enough time in those irreplaceable human elements?   [The Scrum Master Toolbox Podcast Recommends]

Mohini Kissoon: When Politeness Becomes the Enemy of Team Growth—Escaping the Conflict Avoidance Trap 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.   "Conflict isn't the enemy. It's when we're avoiding conflict that it becomes an issue for teams." - Mohini Kissoon   Mohini shares a story about the worst self-destructive pattern she has witnessed: teams that are overly polite to avoid addressing conflicts. She worked with a team that prided themselves on being collaborative and drama-free, but beneath that politeness was a hesitancy to have difficult conversations. It started small—in sprint planning, the Product Owner would propose unrealistic scope, and people would just nod and accept. Someone might say "that's quite ambitious," but no one would actually push back. In retrospectives, feedback was always wrapped in layers of positive framing. When a developer consistently delivered work that didn't meet the Definition of Done, no one called it out directly—they just quietly fixed it or worked around it. After three months, side conversations started emerging where people would pull Mohini aside to share concerns they would never voice in the room. The team was skipping the storming phase of the Tuckman model, and this avoidance eventually led to missed deadlines and frustrated stakeholders. The key learning: healthy conflict brings the energy teams need to innovate and grow.   In this segment, we talk about the Tuckman model and why the storming phase is essential for team development.   Self-reflection Question: Is your team's harmony genuine collaboration, or is it a facade hiding unspoken frustrations that will eventually surface at the worst possible moment? Featured Book of the Week: Turn the Ship Around by David Marquet Mohini discovered Turn the Ship Around by David Marquet at a time when she was working with multiple teams and feeling exhausted from being the person everyone looked to for answers. She thought that's what servant leadership meant, but she was actually creating dependency rather than capability. The book tells the story of how Marquet took command of the worst-performing submarine in the US Navy and transformed it into the best by fundamentally changing how leadership worked. "Instead of the traditional leader-follower model, he built a leader-to-leader structure where everyone was expected to think, decide, and own their work," Mohini explains.  The key insight was that we don't just empower teams—we need to build an environment where they can grow and don't need permission to excel. This shifted Mohini's approach: instead of saying "here's what I think we should do," she started asking "what have you tried so far? What do you intend to do next?" The book also emphasizes that pushing decision-making down requires providing the knowledge and context teams need to make good decisions.   [The Scrum Master Toolbox Podcast Recommends]

Organizations invest heavily in recruiting top talent, but without effective onboarding, much of that investment is at risk. In fact, companies with strong onboarding programs improve new hire retention by up to 82% and boost productivity by over 70%. The good news? With the right approach, onboarding can become one of the most powerful drivers of culture and performance.In this episode of Bring Out the Talent, we're joined by Shauna Bona, a learning strategist and organizational development leader who has helped companies transform low-energy onboarding into programs that truly deliver results. With deep expertise in designing experiences that blend strategy, adaptability, and creativity, Shauna brings practical insights into how organizations can energize new hires from day one.This conversation is all about how agile thinking can revitalize onboarding programs that feel stale or uninspired. From spotting the warning signs of a program that's lost momentum, to building in continuous feedback loops, to balancing consistency with adaptability, Shauna shares actionable strategies leaders can use to turn onboarding into a long-term engine for engagement, productivity, and success. Tune in for an insightful discussion that will leave you rethinking the role of onboarding in shaping employee experience and organizational outcomes.

What happens when good intentions collide with finite capacity? In many law practices, it shows up as overload, missed deadlines, and promises that quietly slip through the cracks.In this episode, I'm introducing the idea of a promise-keeping machine and explaining why making work visible is the first and most important step toward building one. You'll learn how simple visual systems like Kanban help lawyers see their true commitments, protect capacity, and make more credible promises to clients, colleagues, and themselves.Get full show notes, transcript, and more information here: agileattorney.com/102Take your law practice from overwhelmed to optimized with GreenLine LegalFollow along on LinkedIn: linkedin.com/in/johnegrant

What happens when Agile, Extreme Programming, and Test-Driven Development meet a world dominated by hardware, graphical programming, and binary artifacts? In this episode of the Mob Mentality Show, we're joined by Sam Taggart to explore what it really takes to introduce modern software engineering practices into environments like LabVIEW, embedded systems, and industrial software teams. These are contexts where deployment can be slow, feedback loops can be expensive, and “just refactor it” feels like it is not an option. We dig into why applying XP, TDD, mob programming, and continuous integration looks very different when your software is tightly coupled to physical devices, firmware, and test equipment. Sam shares practical insights on adapting Agile ideas so they actually work in hardware-constrained environments, rather than forcing patterns designed for web apps onto teams that live in a very different reality. A major theme of the conversation is change. How do you sell new engineering practices to skeptical teams? How do you introduce better ways of working without triggering resistance or fear? And how do you help organizations move forward when legacy code, specialized tools, and long-established habits get in the way? We also spend time on a deceptively simple but critical idea: knowing what “good” looks like. From testing strategies and code quality to team collaboration and delivery confidence, having a clear vision of good engineering makes it far easier to experiment with better practices and avoid cargo-cult Agile. This episode is especially relevant if you work with LabVIEW, embedded systems, firmware, industrial or hardware-adjacent software, or if you're leading teams where Agile adoption feels harder than the books make it sound. Topics include: - Applying TDD and XP in graphical, binary, and legacy codebases - Mob programming and collaboration in hardware-heavy environments - Continuous integration and delivery when deployment is constrained - Introducing Agile ideas without alienating experienced engineers - Reducing risk while improving feedback and quality - Helping teams see and aim for better engineering outcomes Video and Show Notes: https://youtu.be/Kxzn_2aYMIM 

Mohini Kissoon: How to Break the Cycle of Dominant Personalities in Agile Teams 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 confused silence with agreement. My silence as a facilitator had been giving the wrong impression to the team: that this kind of dynamic is acceptable." - Mohini Kissoon   In her first year as a Scrum Master, Mohini was full of energy and deeply committed to doing Scrum by the book. She had just earned her certification and joined a mid-sized product team where a senior developer—let's call him Tom—was brilliant but quite dominant. In every session, Tom would speak first, speak longest, and often override the ideas of junior developers. Mohini noticed this pattern but didn't intervene, assuming that Tom's experience and the others' silence meant agreement. Over several sprints, stand-ups became reporting sessions to Tom rather than collaborative planning. Junior developers gradually stopped offering ideas in fear of being shut down. When Mohini finally reached out to the team members individually, one of them was even considering leaving the organization—they felt like "just a cog in the machine." This was the wake-up call Mohini needed. She realized she had been focusing intensely on the mechanics while missing the human dynamics entirely. The solution came through coaching Tom on active listening and introducing facilitation techniques like silent brainstorming and round-robin sharing, giving everyone the opportunity to contribute without being influenced.   Self-reflection Question: When you observe dominant voices silencing others on your team, do you intervene immediately, or do you wait to see if the situation resolves itself—and what does that choice cost your team?   [The Scrum Master Toolbox Podcast Recommends]

Donara Jaghinyan – Transformation and Integration Leader Donara Jaghinyan, returns for Part 2 of our conversation on what actually breaks integrations after the deal closes. This episode tackles the messy reality of post-merger execution: integration debt that piles up when long-tail items don't get done, change management as a practical framework (not corporate fluff), and the cultural friction that surfaces in cross-border deals. Donara shares firsthand experiences navigating gender-based hierarchy in Middle Eastern TSA negotiations, building trust across geographies, and managing the communication breakdowns that create employee uncertainty. If you missed Part 1, listen to that first—then come back for the operational realities that determine whether your deal actually delivers value. Things You'll Learn What integration debt actually is and why long-tail items get forgotten six months post-close without a formal tracking system Change management as a framework, not fluff—identifying friction points, enabling change agents, and communicating up to seven times before messages reach end users Cross-border cultural challenges that don't show up in diligence, including hierarchy-based decision-making and relationship-building strategies that work globally  _____________

I made a VERY controversial Podcast Episode on January 1st and I think people may have completely missed it! There will be 3 CRAZY-BIG changes happening on the Agile Landscape in 2026:

Great leaders aren't born—they're made through great followership. Bob and Josh explore why mastering the art of following is essential to leading, including Amazon's "disagree and commit" principle, how to support without being a yes-person, and why you should never embarrass your leader in public. Real stories from football fields and conference rooms reveal what separates good followers from great ones.Steve Jobs "Insult Response" at WWDC 1997Disagree and commit - WikipediaAmazon's "Disagree and Commit" Leadership PrincipleHumble Leadership by Edgar H. Schein and Peter A. ScheinStay 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!

Recorded at Metatopia 2024 Presented by Stephanie Bryant and Melissa Lewis-Gentry What's Agile and why would I use it? Join us for a quick overview of Agile principles and practices that can help you tune your game design process into more flexible, powerful, and satisfying ways of working, whether you're a solo designer or leader of an entire team.

Carmela Then: Why the Best Product Owners Let Go of What They're Best At The Great Product Owner: The Humble Leader Who Served His Team Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "He was there, he was present, he was serving the team." - Carmela Then   Carmela worked with a Product Owner at a bank who embodied everything servant leadership should look like. This wasn't a PO who lorded his business expertise over the team—instead, he brought cookies, cracked jokes, and made everyone feel valued regardless of their role. He knew the product landscape intimately and participated in every refinement session, yet remained approachable and coachable.  When team members came to him confused about stakeholder requests, he willingly stepped in as a mediator. Perhaps most impressively, he actively worked to break down the hierarchical mindset that often plagues traditional organizations. In the beginning, testers felt they couldn't question the business analyst or Product Owner.  By the end, QA team members were confidently pointing out missing scenarios and use cases—and the PO would respond with genuine appreciation: "Oh yes! We missed it! Let's prioritize that story for the next sprint." This PO understood that his role wasn't to have all the answers, but to create an environment where anyone could contribute their expertise. The result was a truly flat, collaborative Scrum team operating exactly as Scrum was designed to work.   Self-reflection Question: How accessible are you to your team, and do you create an environment where anyone—regardless of role—feels comfortable challenging your thinking? The Bad Product Owner: When Expertise Becomes a Barrier to Collaboration 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 knows everything himself, and everything is in his head. So nobody else knows what he has in his head." - Carmela Then   Carmela describes a Product Owner who wasn't a bad person—in fact, he was incredibly capable. He knew the business from front to back, understood the systems intimately from years of analyst work, and could even write pseudocode himself. The problem? His very competence became a barrier to team collaboration.  Because he knew so much, he struggled to articulate his ideas to others. Frustrated that developers couldn't read his mind, he started writing the code himself and handing it to developers with instructions to simply implement it. The result was disengaged developers who had no understanding of the bigger picture, and a PO who was drowning in work that wasn't his to do.  Carmela approached this with humility, asking what she calls "dumb questions" and requesting that he draw things on paper so she could understand. She made excuses about her "bad memory" to create documentation that could be shared with the whole team.  Over multiple Program Increments, she gently coached him to trust his team: "You are one person. Please let the team help you. The developers are great at what they do—if you share what you're trying to achieve, they can write code that's more efficient and easier to maintain." Eventually, he learned to let go of the coding and focus on what only he could do: sharing his deep business knowledge.   Self-reflection Question: As a leader, what tasks are you holding onto that you should be delegating—and what is your reluctance costing your team?   [The Scrum Master Toolbox Podcast Recommends]

Carmela Then: Why Teams Hate Agile (And How to Change That) 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 just hate it. They absolutely hate it. They had Agile fatigue." - Carmela Then   Carmela describes what success looks like for a Scrum Master, and her answer might surprise you. Years ago, she might have pointed to metrics like cycle time. Today, she measures success by whether teams embrace Agile and Scrum rather than resent it.  She joined a team that was exhausted and bitter—their previous Scrum Master had been a micromanaging project manager in disguise. Stories were broken into disconnected tasks: one for development, one for testing, with no relationship between them. At the end of a sprint, nobody could answer whether something actually worked in production. The team hated Agile with a passion.  Carmela approached them differently—not as a threatening authority figure, but as a humble business analyst there to help. She let the Product Owner vent his frustrations about Agile in a retrospective.  Then, without preaching, she simply showed them another way: how to break down features properly, how to create end-to-end visibility, how to write stories that delivered actual value. Slowly, the team began to experience what Agile was meant to feel like. They stopped being "task deliverers" and started becoming value creators. The transformation wasn't overnight, but the result was a team that finally understood—and even appreciated—why Agile works.   Self-reflection Question: If you asked your team whether they love or hate Agile, what would they say—and are you brave enough to ask? Featured Retrospective Format for the Week: Emotional Seismograph Carmela recommends the Emotional Seismograph as her go-to retrospective format. The setup is simple but powerful: create a graph with the sprint days on the horizontal axis and emotion levels on the vertical (happy at the top, sad at the bottom). Each team member draws a line showing how they felt throughout the sprint. The visual result is striking—and the conversations it triggers are invaluable. Carmela focuses on the extremes: moments of great happiness and moments of stress. She has team members add sticky notes to explain those peaks and valleys, allowing common themes to emerge. Her philosophy is that positive emotions drive productivity: "When the team is having a positive experience throughout their workday, they're actually more productive. Stress is the silent killer—it makes people sick, takes them out physically and mentally, and people will just quit." By putting a finger on the emotional pulse of the team, Scrum Masters can identify what to continue doing and what needs to change to lift the team into a better experience.   [The Scrum Master Toolbox Podcast Recommends]

Pivot your career by becoming an Agile Business Outcomes Partner. Help companies get what they’re begging for – real, measurable business value from their Agile investments. Buy the audio+PDF playbook here. The State Of Agile Report Finally Dropped For a bit there, I thought I’d missed it. I’m not 100% sure if there ever was a 2025 report, but for no good reason, I checked this week, and voila! There it was. The 2026 edition. I don’t exactly set my watch to the annual State Of Agile report, but it IS very very good. What I like most about it is the data focus. We’re not hearing from pundits or experts. The authors poll 350 organizations with a set of prepared questions about Agile as it is today; in doing so, they’re able to draw contrasts to how it looked in past years. They ask about adoption rates, satisfaction, quality issues or improvements, Agile role definitions, Agile’s impact on planning and business strategy…and the answers give a good internal temperature of how we’re impacting business and technology. Calling Out Trends The State Of Agile Report spends a good amount of space on trending stats. It’s good to know how things ARE, but even better to know where they’re going. There’s been some sharp changes since the last report, and they reflect what you’ve probably been feeling out there in the field. Investment Is Up, But Trust and Quality Are Down When you see all of the layoffs and dried-up opportunities, you’d likely assume that spending on Agile is down. That was the big surprise in the 18th State Of Agile Report…Investment is actually UP. Most companies are increasing or sustaining existing investment in Agile. And yet, we can clearly see that interest is waning. How can this be? Whether its sunk-cost fallacy or the commitment and consistency principle, companies are not ready to cancel all their Agile programs quite yet. For reasons discussed later, there is a lot more order and automation in development operations, and apparently that’s worth spending to keep in place. Buyers Demand Proof of ROI But at the same time, one of the biggest jumps in this year’s State Of Agile Report is the increased scrutiny on Value. Folks want to know – how is Agile impacting my core business metrics? Where is this investment mapped to improved business outcomes? The answer is often “we don’t know”. That’s causing a lot of shifting in how much companies invest – which is why we see roles being eliminated, repurposed, combined or redefined. Three quarters of respondents say there is an increased pressure to defend or prove the ROI of their Agile spend. Three quarters. This is a huge signal. Roles are Changing Most respondents reported that their Agile roles have changed in some small way. A small number have shifted off of Agile tasks altogether, but most have found their roles hybrid-ized with traditional PM or project/product roles. Some have found that the coaching-only role is diminished. Others still report that they are responsible for ensuring Agile has traceability back to business outcomes, as described above. Systems are Nice, But They Don’t Help Make Better Decisions It’s subtle, but its there….what we’ve professed all along is actually supported by data. Systems, tools and processes, while important, take a back seat to business imperatives. Many respondents in the State Of Agile Report describe satisfaction with they’re systems, in terms of visibility into the development pipleine. But again, the link between that pipeline and measurable value is cloudy at best. Ai Can Help (But Maybe Not Yet) But wait! Isn’t AI going to save Agile? Maybe someday, but not quite yet, according to The State of Agile Report. The problem with AI is the spotty, disorganized adoption. Guardrails are few and inadequate. Agentic AI shows promise for automating end-to-end workflows, but only if we treat AI like any other employee or business partner. Reading Between The Lines There’s good news and bad news in The State Of Agile Report. After a quarter-century, Agile has definitely settled in. A lot of what we used to be tresured for has become table-stakes. But the future belongs to those who can become Business Outcomes Partners – those who are able to tie Agile investment to business value. Get The State Of Agile Report Here Donwload your own copy here: https://digital.ai/resource-center/analyst-reports/18th-state-of-agile-report/ Get My Guide to Becoming A Business Outcome Partner Be the first to get this career-changing guide. If you get it before January 12, 2026, you can use coupon code BOXINGSAVE15 at checkout to save 15% off your total price. BOXING WEEK SALE Save 15% Off ALL MY PRODUCTS until Jan 12 2026. Use code BOXINGSAVE15 at checkout. https://learning.fusechamber.com **FORGE GENESIS IS HERE** All the skills you need ot stop relying on job postings and start enjoying the freedom of an Agile career on YOUR terms. First cohort starts in Jan 2026 https://learning.fusechamber.com/forge-genesis **THE ALL NEW FORGE LIGHTNING** 12 Weeks to elite leadership! https://learning.fusechamber.com/forge-lightning **JOIN MY BETA COMMUNITY FOR AGILE ENTREPRENEURS AND INTRAPRENEURS** The latest wave in professional Agile careers. Get the support you need to Forge Your Freedom! Join for FREE here: https://learning.fusechamber.com/offers/Sa3udEgz **CHECK OUT ALL MY PRODUCTS AND SERVICES HERE:** https://learning.fusechamber.com **ELEVATE YOUR PROFESSIONAL STORYTELLING – Now Live!** The most coveted communications skill – now at your fingertips! https://learning.fusechamber.com/storytelling **JOIN THE FORGE*** New cohorts for Fall 2025!  Email for more information: contact@badassagile.com **BREAK FREE OF CORPORATE AGILE!!*** Download my FREE Guide and learn how to shift from roles and process and use your agile skills in new and exciting ways! https://learning.fusechamber.com/future-of-agile-signup We’re also on YouTube! Follow the podcast, enjoy some panel/guest commentary, and get some quick tips and guidance from me: https://www.youtube.com/c/BadassAgile ****** Follow The LinkedIn Page: https://www.linkedin.com/showcase/badass-agile ****** Our mission is to create an elite tribe of leaders who focus on who they need to become in order to lead and inspire, and to be the best agile podcast and resource for effective mindset and leadership game. Contact us (contact@badassagile.com) for elite-level performance and agile coaching, speaking engagements, team-level and executive mindset/agile training, and licensing options for modern, high-impact, bite-sized learning and educational content. If you like this episode, you might also like… State of Agile Report 2024 Review Win Executive Support by Marketing Your Agile POV Episode 224 – Circulate Value – The Agile Survival Skill

Carmela Then: From Requirements Chaos to Story Mapping Success—How Planning Transforms Agile Teams 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.   "We can't continue to do this. Something has to change." - Carmela Then   Carmela shares a story of organizational chaos that will resonate with many Agile practitioners. She joined a company where teams would jump straight into writing requirements without pausing to understand what they were trying to achieve. Vendor deliverables were thrown "over the fence" to internal technology teams with the assumption that everyone would magically know what to do. For almost a year, this pattern continued: teams writing stories on the fly while building, creating massive rework, confusion, and burnout.  The Product Owner faced constant stakeholder disappointment, having to explain what wasn't delivered and why. Then came the breakthrough moment—the PO reached out and said, "We can't continue to do this." Carmela introduced a structured approach: workshops that brought business stakeholders and subject matter experts together to walk through end-to-end business processes. She implemented story mapping—visualizing the journey from beginning to end, with each major step broken into smaller, actionable stories.  Critically, she built in feedback loops: playback sessions where the team validated their understanding with stakeholders before committing to development. The result? Teams could now distinguish between well-understood work they could start immediately and the "hairy" items that needed more investigation. The Product Owner could make informed prioritization decisions, and the entire team gained visibility into the bigger picture.   Self-reflection Question: How often does your team pause to map the full end-to-end journey before diving into requirements, and what might you be missing by skipping this step?   [The Scrum Master Toolbox Podcast Recommends]

Carmela Then: When Remote Teams Stop Listening—The Silent Killer of Agile Collaboration 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.   "Two minutes into it, my mind's starting to wander and I started to do my own thing." - Carmela Then   Carmela paints a vivid picture of a distributed team stretched across Sydney, New Zealand, India, and beyond—a team where communication had quietly become the enemy of progress. The warning signs were subtle at first: in meetings with 20 people on the call, only two or three would speak for the entire hour or two, with no visual aids, no PowerPoints, no drawings. The result? Within minutes, attention drifted, and everyone assumed someone else understood the message.  The speakers believed their ideas had landed; the listeners had already tuned out. This miscommunication compounded sprint after sprint until, just two months before go-live, the team was still discussing proof of concept. Trust eroded completely, and the Product Owner resorted to micromanagement—tracking developers by the hour, turning what was supposed to be an Agile team into a waterfall nightmare. Carmela points to a critical missing element: the Scrum Master had been assigned delivery management duties, leaving no one to address the communication dysfunction.  The lesson is clear—in remote, cross-cultural teams, you cannot simply talk your way through complex ideas; you need visual anchors, shared artifacts, and constant verification that understanding has truly been achieved.   In this segment, we talk about the importance of visual communication in remote teams and psychological safety.   Self-reflection Question: How do you verify that your message has truly landed with every team member, especially when working across time zones and cultures? Featured Book of the Week: How to Win Friends and Influence People by Dale Carnegie Carmela recommends How to Win Friends and Influence People by Dale Carnegie, a timeless classic that remains essential reading for every Scrum Master. As Carmela explains, "We work with people—customers are people, and our team, they are human beings as well. Whether we want it or not, we are leaders, we are coaches, and sometimes we could even be mentors." Written during the Great Depression and predating software entirely, this book emphasizes that relationships and understanding people are the foundation of personal and professional success. Carmela was first introduced to the book by a successful person outside of work who advised her not just to read it once, but to revisit it every year. For Scrum Masters navigating team dynamics, stakeholder relationships, and the human side of Agile, Carnegie's principles remain as relevant today as they were nearly a century ago.   [The Scrum Master Toolbox Podcast Recommends]

A new year and a new number on the podcast episodes feels like the perfect time to slow down for a moment and get back to some foundational questions. In this episode, I'm kicking off a reboot of The Agile Attorney Podcast with a return to first principles.You'll discover why so many legal professionals feel pressure to do more and more work, why that so often leads to overwhelm and burnout, and how you can start to prevent that overwhelm by focusing on what it really means to be agile in a world that keeps demanding more.Get full show notes, transcript, and more information here: agileattorney.com/101Take your law practice from overwhelmed to optimized with GreenLine LegalFollow along on LinkedIn: linkedin.com/in/johnegrant

Carmela Then: The Scrum Master Who Learned That Perfect Boards Don't Build Perfect Teams 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 failure part is, instead of leading the team to work toward a common vision, I was probably one of the persons that helped the divide." - Carmela Then   Carmela shares a vulnerable story from her first Scrum Master role at a bank. Armed with training, certifications, and the ability to build a beautiful physical Scrum board with perfectly straight lines, she believed she was ready to lead. But Carmela quickly discovered a crucial truth: mastering the mechanics of Scrum is vastly different from serving a team's real needs. Instead of showing up as a humble learner willing to grow alongside her team, she put on a facade of competence and confidence.  When two Product Owners began fighting for dominance, rather than stepping back and focusing the teams on their shared purpose, Carmela found herself drawn into the political battle, supporting one PO over the other. The result was devastating—a toxic environment where one PO was demoted, and talented team members left the organization entirely. Looking back, Carmela recognizes that her failure wasn't about the Scrum board or ceremonies; it was about not putting the customer and common goals at the center. She learned that Scrum Masters must lead with humility, focus on outcomes rather than egos, and help teams unite rather than divide.   In this episode, we refer to John C. Maxwell and Failing Forward by John C. Maxwell.   Self-reflection Question: When was the last time you prioritized looking competent over truly serving your team's needs, and what did that cost you?   [The Scrum Master Toolbox Podcast Recommends]

Bob and Josh share their favorite things from 2025—from fountain pens and Batman comics to Claude AI, Drizzle ORM, and the books that kept them turning pages. Plus honest talk about therapy, daily walks, and why community still matters. A lighter episode celebrating what brought joy during a challenging year.Pilot Vanishing Point PenBadass Agile Coaching MasterclassTriadAgileAgile2025 | Agile AllianceCrunchyrollAbsolute BatmanJim AcostaPostHog SubstackLeadership LighthouseSusan Cain's The Quiet LifeDungeon Crawler Carl by Matt DinnimanFourth Wing by Rebecca YarroStay 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!

Steve Martin: Coaching Product Owners to Be the Voice of the Customer In this episode, we refer to Henrik Kniberg's "Product Owner in a Nutshell" video and Product Ownership by Geoff Watts. The Great Product Owner: Rob Gard's Customer Obsession 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 role of the PO really is to help the team empathize with the user, the customer of the product, because that's how they can develop great solutions." - Steve Martin   Rob Gard worked at a fintech firm and is now CPO of a major fintech company. Steve describes him as having a brilliant mind and being a real agileist—someone Steve learned a huge amount about Agile from. Rob's defining characteristic was his absolute obsession with the user. Everything focused on customer pain points. Working with engineering teams serving military customers, Rob held regular workshops with those customers to understand their pain firsthand. He was literally the voice of the customer, not theoretically but practically. Rob pushed and challenged teams to be more innovative, always looking for better ways of providing better software. His gift was communication—specifically, briefing the team on the problem rather than just reading out stories in refinement sessions. This is the anti-pattern many Product Owners fall into: going through the motions, reading requirements without context. Real product ownership, as Rob demonstrated, is telling a story that helps the team empathize and understand the pain. When teams can internalize customer problems, they develop better solutions. Rob's ability to communicate the problem into the minds of teams enabled them to serve customers more effectively. This is the essence of great Product Ownership: not being a proxy for management, not juggling multiple teams, but being deeply connected to customer pain and translating that pain into context the team can work with.   Self-reflection Question: Do your refinement sessions tell stories that help the team empathize with customer pain, or do you just read out requirements? The Bad Product Owner: Proxies for Management Instead of Customer Advocates 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 weren't a team, they were a group of individuals working on multiple different projects." - Vasco Duarte   Steve emphasizes that Product Owners often have great intentions but struggle due to lack of training and coaching. The anti-patterns are systemic: commercial managers "dressed up" as Product Owners without understanding the role. Project managers transitioning to PO roles—though Steve notes PMs can make really good POs with proper support. The most damaging pattern is Product Owners spread across multiple teams, having very little time to focus on any single team or their customers. These POs become proxies—representing the voice of senior management rather than the voice of the customer. They cascade requirements downward instead of bringing customer insights upward. The solution isn't to criticize these struggling Product Owners but to help them understand their role and see what good looks like. Steve recommends Henrik Kniberg's "Product Owner in a Nutshell" video—15 minutes, 15 years old, still profoundly relevant. He also points to Product Ownership by Geoff Watts and formal training like CSPO or IC Agile Product Ownership courses. The fundamental issue is meeting Product Owners where they are, providing coaching and support to transform them from management proxies into customer advocates. When POs understand their role as empathy builders between customers and teams, everything changes.   Self-reflection Question: Is your Product Owner the voice of senior management or the voice of the customer?   [The Scrum Master Toolbox Podcast Recommends]

Steve Martin: Making Scrum Master Success Visible with OKRs That Actually Work 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 is not the retrospective that is the success of the retrospective. It is the ownership and accountability where you take improvements after the session." - Steve Martin   The biggest problem for Scrum Masters isn't just defining success—it's being able to shout it from the rooftops with tangible evidence. Steve champions OKRs as an amazing way to define and measure success, but with a critical caveat: they've historically been poorly written and implemented in dark rooms by executives, then cascaded down to teams who never bought in. Steve's approach is radically different. Create OKRs collectively with the team, stakeholders, and end users. Start by focusing on the pain—what problems or pain points do customers, users, and stakeholders actually experience? Make the objective the goal to solve that problem, then define how to measure progress with key results. When everyone is bought in—Scrum Master, engineers, Product Owner, stakeholders, leaders—all pulling in the same direction, magic happens. Make progress visible on the wall like a speedometer, showing exactly where you are at any moment. For an e-commerce checkout, the problem might be too many steps. The objective: reduce pain for users checking out quickly. The baseline: 15 steps today. The target: 5 clicks in three months. Everyone can see the dial moving. Everything should focus on the customer as the endpoint. The challenge is distinguishing between targets imposed from above ("increase sales by 10%") and objectives created collaboratively based on factors the team can actually control. Find what you can control first, work with customers to understand their pain, and start from there.   Self-reflection Question: Can you articulate your team's success with specific, measurable outcomes that everyone—from developers to executives—understands and owns? Featured Retrospective Format for the Week: Post-Retro Actions and Ownership The success of a retrospective isn't the retrospective itself—it's what happens after. Steve emphasizes that ownership and accountability matter more than the format of the session. Take improvements from the retrospective and bring them into the sprint as user stories with clear structure: this is the problem, how we'll solve it, and how we'll measure impact. Assign collective ownership—not just a single person, but the whole team owns the improvement. Then bring improvements into the demo so the team showcases what changed. This creates cultural transformation: the team themselves want to bring improvements, not just because the Scrum Master pushed them. For ongoing impediments, conduct root cause analysis. Create a system to escalate issues beyond the team's control—make these visible on another board or with the leadership team. Find peers in pain: teams with the same problems can work together collectively. The retrospective format matters less than this system of ownership, action, measurement, and visibility. Stop retrospective theatre—going through the motions without taking action. Make improvements real by treating them like any other work: visible, measured, owned, and demonstrated.   [The Scrum Master Toolbox Podcast Recommends]

The Future of Agile in 2026 - My TOP 3 Predictions!This video WILL BE the number ONE MOST listened to episode for 2026 and beyond! Here I make three predictions about the future of Agile in 2026 and beyond. 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/

Steve Martin: Why Agile Fatigue Means We Need to Change Our Approach 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.   "We teach transformation, we support transformation, we help change, but we don't really understand what they're changing from." - Steve Martin   Steve believes Agile as a whole is on the back foot, possibly regressing. There's palpable fatigue in the industry, and transformation in its current form hasn't been the success we hoped. Organizations still need to work in a state of agility—making rapid decisions, aligning teams, delivering value at pace—but they're exhausted by how we've implemented Agile. As Agile professionals, Steve argues, we have a responsibility to take stock and reflect on what's not working. The problem isn't that organizations don't need agility; it's that we've been force-feeding them frameworks without understanding their context. Steve invokes an ancient principle: "When the student is ready, the teacher will appear." But we haven't waited for readiness—we've barged in with Big Bang transformations, bringing 10, 15, or 20 Agile coaches to "save the world." The solution requires meeting people where they are, understanding what they're changing from, not just what they're changing to. Steve's coaching conversation centers on a radical idea: stop trying to help teams that don't want to be helped. Focus on teams already interested in incremental, adaptable delivery. Run small pilots, learn what works, then scale when ready. The age of prescriptive transformation is over. We need to adapt to the reality of the moment, experiment with what works, and have the courage to change the plan when our approach isn't working.   Self-reflection Question: Are you forcing Agile on teams that aren't ready, or are you working with those who genuinely want to improve their delivery approach?   [The Scrum Master Toolbox Podcast Recommends]

Empowering Digital Autonomy and Intersectional Equity in the Age of AIIn this episode of Women Making Moves, host Amy Pons speaks with Yvonne Jackson, a change management talent and AI strategy advisor with a significant background in big corporations like Apple and Whirlpool. Yvonne discusses her transition from corporate to developing ethical digital engagement frameworks. They delve into the intricacies of Agile versus Kanban methodologies, the importance of addressing technical debt early, and the pivotal role of intersectionality in equity conversations. Yvonne emphasizes the need for organizations to redesign their processes and systems to support true diversity, equity, and inclusion. Additionally, she introduces her framework 'Eden'—Ethical Digital Engagement Norms—as a pragmatic blueprint for engaging ethically in the digital age. Throughout the conversation, the critical importance of addressing intersectional identities in AI algorithms is underscored, along with a call to action for everyone to reflect deeply on their engagement practices to foster genuine equity and inclusion.00:00 Introduction and Guest Introduction00:50 Yvonne's Career Journey and Agile Methodology02:52 Challenges in Technology and AI Integration07:23 Intersectionality and Gender in the Workplace15:40 Historical Context and Feminism19:45 Systemic Issues and DEI22:13 Creating Systems for Equity22:33 The Power of Petitions23:02 Target's DEI Dilemma23:34 Building Our Own Ecosystems23:59 The Importance of Digital Autonomy24:13 Challenges in DEI Implementation25:54 The Cost of Ignoring DEI28:56 AI and Intersectionality33:35 Ethical Digital Engagement42:00 Final Thoughts and Call to ActionVisit Yvonne on her business website, personal website, and check out her strategic AI planning project (in beta), and be sure to follow her on LinkedIn.Thank you for tuning in to Women Making Moves, be sure to rate and subscribe to the show on your favorite podcast platform and follow along on Instagram and Bluesky. Visit Amy at Unlock the Magic, and follow on Instagram and LinkedIn.Women Making Moves is for personal use only and general information purposes, the show host cannot guarantee the accuracy of any statements from guests or the sufficiency of the information. This show and host is not liable for any personal actions taken.

Steve Martin: When a Distributed Team's Energy Vanishes into the Virtual Void 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 weren't a team, they were a group of individuals working on multiple different projects." - Vasco Duarte (describing Steve's team situation)   The infrastructure team looked promising on paper: Product Owner in Italy, hardware engineers in Budapest, software engineers in Bucharest, designers in the UK. The team started with energy and enthusiasm, but within a month, something shifted. People stopped showing up for daily stand-ups. Cameras went dark during meetings. Engagement in retrospectives withered. This wasn't just about being distributed—plenty of teams work across time zones successfully. The problem ran deeper. The Scrum Master had a conflict of interest, serving dual roles as both facilitator and engineer. Team members were simultaneously juggling three or four other projects, treating this work as just another item on an impossibly long list. Steve spent a couple of months watching the deterioration before recognizing the root cause: there was no leadership sponsorship or buy-in. Stakeholders weren't invested. The team wasn't actually a team—they were individuals happening to work on the same project. Steve considers this a failure because he couldn't solve it. Sometimes, the absence of organizational support creates an unsolvable puzzle. Without leadership commitment, even the most skilled Scrum Master can't manufacture the conditions for team success.   In this episode, we refer to The Phoenix Project by Gene Kim, a book about organizational culture disguised as a DevOps novel.   Self-reflection Question: Is your team truly dedicated to one mission, or are they a collection of individuals spread across competing priorities? Featured Book of the Week: The Phoenix Project by Gene Kim "There's a lot of good lightning bulb moments that go off." - Steve Martin   Steve describes The Phoenix Project as a book about culture, not just DevOps. Written like a novel following a mock company, it creates continuous light bulb moments for readers. The book resonated deeply with Steve because it exposed patterns he'd experienced firsthand—particularly the anti-pattern of single points of failure. Steve had worked with an engineer who would spend entire weekends doing releases, holding everything in his head, then burning out and taking three days off to recover. This engineer was the bottleneck, the single point of failure that put the entire system at risk. The Phoenix Project illuminates how knowledge hoarding and dependency on individuals creates organizational fragility. The solution isn't just technical—it's cultural. Teams need to share knowledge and understanding, deliberately de-risking the concentration of expertise in one person's mind. Steve recommends this book for anyone trying to understand why organizational transformation requires more than process changes—it demands a fundamental shift in how teams think about knowledge, risk, and collaboration.   [The Scrum Master Toolbox Podcast Recommends]

It's New Year's Eve-Eve, and instead of recording from our usual virtual setups, we did something we've talked about for years: we hit record in the same room. If you're watching on YouTube, you can actually see us together. If you're listening on audio, you'll just have to trust us—this one was in-person. In this special episode of Building Better Developers (our Building Better Foundations season), we keep it simple: a Year-End Reflection for Developers. What are we ready to leave behind from this year? What do we want to carry into the next one? And what's the reality behind the loudest tech conversations? A Year-End Reflection for Developers isn't about perfection. It's about clarity—keeping what worked, dropping what didn't, and starting the next year lighter. Year-End Reflection for Developers: What We're Ready to Leave Behind We opened the discussion with a question you can ask your team, your friends, or yourself: What are you ready to see go away? For Rob, it was the endless, extreme framing around AI. Not AI itself—he uses it and enjoys it—but the constant "AI will save everything" or "AI will destroy everything" energy that dominated so many conversations this year. The truth is, we're still going to talk about AI next year. The goal is to move the conversation toward reality: what it can do well, what it can't, and how to use it responsibly without acting like it's magic—or doom. Year-End Reflection for Developers on AI Hype vs Reality A big part of this Year-End Reflection for Developers was dialing down the panic and dialing up practical thinking. AI tools can absolutely help developers move faster. They can help summarize, brainstorm, refactor, and even unblock you when you're stuck. But the hype has pushed people into extremes, and extremes aren't useful when you're shipping software. If you used AI this year, you already know the real story: sometimes it's brilliant, and sometimes it confidently hands you nonsense. Use AI like a tool, not a truth machine. A Year-End Reflection for Developers should include one rule: verify before you trust. Year-End Reflection for Developers on "AI Caused the Layoffs" Michael took the AI conversation in a different direction: big businesses blaming AI for layoffs. Yes, AI will impact jobs over time. But what we're seeing right now often looks more like companies correcting after the COVID-era "no hire / no fire" period. In other words, the bottom line is driving decisions, and AI is becoming a convenient headline. If you're cutting roles for financial reasons, just say that. Don't hide behind buzzwords. That honesty matters—not just for employees, but for the industry. Developers don't benefit from fear-based narratives. We benefit from transparency and real strategy. Year-End Reflection for Developers: Studio Audience Takeaways Because we had an in-room setup, we passed the mic to a few of our "studio audience" members. Ian shared the positive side of his year: getting hands-on experience in Agile and learning what it's like to build alongside a team of developers on a large project. It had hangups, and it ran longer than expected—but that's real work, and real growth. Wesley echoed the burnout around AI buzzwords and made a strong point: when we say "AI," we need to be specific. A lot of what people mean right now is "large language models," and lumping everything under "AI" only adds confusion. He also called out how hype can warp markets—like hardware prices skyrocketing when everyone jumps on the trend. Year-End Reflection for Developers: Less Fear, More People Natalie brought the most human answer of the night: she wants less fear. Less fear, less uncertainty, less constant tension—and more remembering that we're all in this together. That hit home, because a Year-End Reflection for Developers isn't just about tech. It's about how we work, how we treat each other, and how we show up next year. Year-End Reflection for Developers: What's Next We closed with a simple message: go enjoy the next few days. Get out. Socialize. Be kind. Let go of the fear and anger where you can. We'll see you in 2026. Stay Connected: Join the Developreneur Community We invite you to join our community and share your coding journey with us. Whether you're a seasoned developer or just starting, there's always room to learn and grow together. Contact us at info@develpreneur.com with your questions, feedback, or suggestions for future episodes. Together, let's continue exploring the exciting world of software development. Additional Resources Strategies for Your New Year Planning Make a Final Push to Setup a Great New Year Become A Better Developer In The New Year Building Better Foundations Podcast Videos – With Bonus Content

When massive technology projects spiral out of control, teams often feel like they're trapped in an endless cycle of changing requirements, missed deadlines, and mounting frustration.In this episode, I sit down with my GreenLine co-founder, Dimitri Ponomareff, to explore how he discovered a different way forward during one of those classic "death march" projects early in his career. You'll discover the Agile lessons he carried forward from his early Agile experiments, and how they translate directly into the way modern law firms can operate with more calm, more confidence, and far more control.Get full show notes, transcript, and more information here: agileattorney.com/bonus2Take your law practice from overwhelmed to optimized with GreenLine LegalFollow along on LinkedIn: linkedin.com/in/johnegrantFollow Dimitri on LinkedIn: linkedin.com/in/dimka5

Steve Martin: When the Gospel of Agile Becomes a Barrier to Change 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 took me a while to realize that that's what I was doing. I felt the reason wasn't working was them, it wasn't me." - Steve Martin   Steve carried the Scrum Guide like a Bible in his early days as an Agile coach. He was a purist—convinced he had an army of Agile practitioners behind him, ready to transform every team he encountered. When teams questioned his approach, he would shut down the conversation: "Don't challenge me on this, because this is how it's supposed to be." But pushing against the tide and spreading the gospel created something unexpected: resistance. The more Steve insisted on his purist view, the more teams pushed back. It took him a couple of years to recognize the pattern. The problem wasn't the teams refusing to change—it was his approach. Steve's breakthrough came when he started teaching and realized he needed to meet people where they are, not force them to come to him. Like understanding a customer's needs, he learned to build empathy with teams, Product Owners, and leaders. He discovered the power of creating personas for the people he was coaching, understanding their context before prescribing solutions. The hardest part wasn't learning this lesson—it was being honest about his failures and admitting that his righteous certainty had been the real impediment to transformation.   Self-reflection Question: Are you meeting your teams where they are, or are you pushing them toward where you think they should be?   [The Scrum Master Toolbox Podcast Recommends]

Fighting the word “Accountability” Whether or not you like the word, you can’t run a high-performing team without accountability. I recently read a post that blamed accountability and commitment for all of Agile’s failures. One commenter went so far as to suggest that accountability was an affront; an assault. If you’re on a team, or even if you’re being paid to do a job, you’re accountable for something. Someone, somewhere needs you to sign up for a result. They need you to do a certain thing by a certain date. That’s a commitment. That’s accountability. Changing The Word Won’t Help Sure, we can get rid of the word, but it won’t do much to address the reality that makes us fear it; visibility, responsibility and persistence are required to make a great Agile team. There’s little value in being comfortable and easy. Instead, developing the muscle of making small promises and delivering on them CONSISTENTLY is what builds reputation AND speed. Maybe scale too. **BOXING WEEK SALE** Save 15% Off ALL MY PRODUCTS until Jan 12 2026. Use code BOXINGSAVE15 at checkout. https://learning.fusechamber.com **FORGE GENESIS IS HERE** All the skills you need ot stop relying on job postings and start enjoying the freedom of an Agile career on YOUR terms. First cohort starts in Jan 2026 https://learning.fusechamber.com/forge-genesis **THE ALL NEW FORGE LIGHTNING** 12 Weeks to elite leadership! https://learning.fusechamber.com/forge-lightning **JOIN MY BETA COMMUNITY FOR AGILE ENTREPRENEURS AND INTRAPRENEURS** The latest wave in professional Agile careers. Get the support you need to Forge Your Freedom! Join for FREE here: https://learning.fusechamber.com/offers/Sa3udEgz **CHECK OUT ALL MY PRODUCTS AND SERVICES HERE:** https://learning.fusechamber.com **ELEVATE YOUR PROFESSIONAL STORYTELLING – Now Live!** The most coveted communications skill – now at your fingertips! https://learning.fusechamber.com/storytelling **JOIN THE FORGE*** New cohorts for Fall 2025! Email for more information: contact@badassagile.com **BREAK FREE OF CORPORATE AGILE!!*** Download my FREE Guide and learn how to shift from roles and process and use your agile skills in new and exciting ways! https://learning.fusechamber.com/future-of-agile-signup We’re also on YouTube! Follow the podcast, enjoy some panel/guest commentary, and get some quick tips and guidance from me: https://www.youtube.com/c/BadassAgile ****** Follow The LinkedIn Page: https://www.linkedin.com/showcase/badass-agile ****** Our mission is to create an elite tribe of leaders who focus on who they need to become in order to lead and inspire, and to be the best agile podcast and resource for effective mindset and leadership game. Contact us (contact@badassagile.com) for elite-level performance and agile coaching, speaking engagements, team-level and executive mindset/agile training, and licensing options for modern, high-impact, bite-sized learning and educational content. If you liked this epsiode, why not try… Episode 118 – How To Improve Accountability Episode 172 – Commitment Culture Episode 199 – Should We Eliminate Commitment?

Bob calls it the worst tech job market in 45 years. Josh has been grinding harder than ever with a slower pipeline. In this raw year-in-review episode, the hosts share what's actually helped them survive 2025—human networking over LinkedIn vanity metrics, community over isolation, and resilience over despair. Plus: Bob announces he's quitting the Scrum Alliance and both hosts call out the AI bandwagon for what it is. 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!

BONUS: The Operating System for Software-Native Organizations - The Five Core Principles In this BONUS episode, the final installment of our Special Xmas 2025 reflection on Software-native businesses, we explore the five fundamental principles that form the operating system for software-native organizations. Building on the previous four episodes, this conversation provides the blueprint for building organizations that can adapt at the speed of modern business demands, where the average company lifespan on the S&P 500 has dropped from 33 years in the 1960s to a projected 12 years by 2027. The Challenge of Adaptation "What we're observing in Ukraine is adaptation happening at a speed that would have been unthinkable in traditional military contexts - new drone capabilities emerge, countermeasures appear within days, and those get countered within weeks." The opening draws a powerful parallel between the rapid adaptation we're witnessing in drone warfare and the existential threats facing modern businesses. While our businesses aren't facing literal warfare, they are confronting dramatic disruption. Clayton Christensen documented this in "The Innovator's Dilemma," but what he observed in the 1970s and 80s is happening exponentially faster now, with software as the accelerant. If we can improve businesses' chances of survival even by 10-15%, we're talking about thousands of companies that could thrive instead of fail, millions of jobs preserved, and enormous value created. The central question becomes: how do you build an organization that can adapt at this speed? Principle 1: Constant Experimentation with Tight Feedback Loops "Everything becomes an experiment. Not in the sense of being reckless or uncommitted, but in being clear about what we're testing and what we expect to learn. I call this: work like a scientist: learning is the goal." Software developers have practiced this for decades through Test-Driven Development, but now this TDD mindset is becoming the ruling metaphor for managing products and entire businesses. The practice involves framing every initiative with three clear elements: the goal (what are we trying to achieve?), the action (what specific thing will we do?), and the learning (what will we measure to know if it worked?). When a client says "we need to improve our retrospectives," software-native organizations don't just implement a new format. Instead, they connect it to business value - improving the NPS score for users of a specific feature by running focused retrospectives that explicitly target user pain points and tracking both the improvements implemented and the actual NPS impact. After two weeks, you know whether it worked. The experiment mindset means you're always learning, never stuck. This is TDD applied to organizational change, and it's powerful because every process change connects directly to customer outcomes. Principle 2: Clear Connection to Business Value "Software-native organizations don't measure success by tasks completed, story points delivered, or features shipped. Or even cycle time or throughput. They measure success by business outcomes achieved." While this seems obvious, most organizations still optimize for output, not outcomes. The practice uses Impact Mapping or similar outcome-focused frameworks where every initiative answers three questions: What business behavior are we trying to change? How will we measure that change? What's the minimum software needed to create that change? A financial services client wanted to "modernize their reporting system" - a 12-month initiative with dozens of features in project terms. Reframed through a business value lens, the goal became reducing time analysts spend preparing monthly reports from 80 hours to 20 hours, measured by tracking actual analyst time, starting with automating just the three most time-consuming report components. The first delivery reduced time to 50 hours - not perfect, but 30 hours saved, with clear learning about which parts of reporting actually mattered. The organization wasn't trying to fulfill requirements; they were laser focused on the business value that actually mattered. When you're connected to business value, you can adapt. When you're committed to a feature list, you're stuck. Principle 3: Software as Value Amplifier "Software isn't just 'something we do' or a support function. Software is an amplifier of your business model. If your business model generates $X of value per customer through manual processes, software should help you generate $10X or more." Before investing in software, ask whether this can amplify your business model by 10x or more - not 10% improvement, but 10x. That's the threshold where software's unique properties (zero marginal cost, infinite scale, instant distribution) actually matter, and where the cost/value curve starts to invert. Remember: software is still the slowest and most expensive way to check if a feature would deliver value, so you better have a 10x or more expectation of return. Stripe exemplifies this principle perfectly. Before Stripe, accepting payments online required a merchant account (weeks to set up), integration with payment gateways (months of development), and PCI compliance (expensive and complex). Stripe reduced that to adding seven lines of code - not 10% easier, but 100x easier. This enabled an entire generation of internet businesses that couldn't have existed otherwise: subscription services, marketplaces, on-demand platforms. That's software as amplifier. It didn't optimize the old model; it made new models possible. If your software initiatives are about 5-10% improvements, ask yourself: is software the right medium for this problem, or should you focus where software can create genuine amplification? Principle 4: Software as Strategic Advantage "Software-native organizations use software for strategic advantage and competitive differentiation, not just optimization, automation, or cost reduction. This means treating software development as part of your very strategy, not a way to implement a strategy that is separate from the software." This concept, discussed with Tom Gilb and Simon Holzapfel on the podcast as "continuous strategy," means that instead of creating a strategy every few years and deploying it like a project, strategy and execution are continuously intertwined when it comes to software delivery. The practice involves organizing around competitive capabilities that software uniquely enables by asking: How can software 10x the value we generate right now? What can we do with software that competitors can't easily replicate? Where does software create a defensible advantage? How does our software create compounding value over time? Amazon Web Services didn't start as a product strategy but emerged from Amazon building internal capabilities to run their e-commerce platform at scale. They realized they'd built infrastructure that was extremely hard to replicate and asked: "What if we offered it to others?" AWS became Amazon's most profitable business - not because they optimized their existing retail business, but because they turned an internal capability into a strategic platform. The software wasn't supporting the strategy - the software became the strategy. Compare this to companies that use software just for cost reduction or process optimization - they're playing defense. Software-native companies use software to play offense, creating capabilities that change the competitive landscape. Continuous strategy means your software capabilities and your business strategy evolve together, in real-time, not in annual planning cycles. Principle 5: Real-Time Observability and Adaptive Systems "Software-native organizations use telemetry and real-time analytics not just to understand their software, but to understand their entire business and adapt dynamically. Observability practices from DevOps are actually ways of managing software delivery itself. We're bootstrapping our own operating system for software businesses." This principle connects back to Principle 1 but takes it to the organizational level. The practice involves building systems that constantly sense what's happening and can adapt in real-time: deploy with feature flags so you can turn capabilities on/off instantly, use A/B testing not just for UI tweaks but for business model experiments, instrument everything so you know how users actually behave, and build feedback loops that let the system respond automatically. Social media companies and algorithmic trading firms already operate this way. Instagram doesn't deploy a new feed algorithm and wait six months to see if it works - they're constantly testing variations, measuring engagement in real-time, adapting the algorithm continuously. The system is sensing and responding every second. High-frequency trading firms make thousands of micro-adjustments per day based on market signals. Imagine applying this to all businesses: a retail company that adjusts pricing, inventory, and promotions in real-time based on demand signals; a healthcare system that dynamically reallocates resources based on patient flow patterns; a logistics company whose routing algorithms adapt to traffic, weather, and delivery success rates continuously. This is the future of software-native organizations - not just fast decision-making, but systems that sense and adapt at software speed, with humans setting goals and constraints but software executing continuous optimization. We're moving from "make a decision, deploy it, wait to see results" to "deploy multiple variants, measure continuously, let the system learn." This closes the loop back to Principle 1 - everything is an experiment, but now the experiments run automatically at scale with near real-time signal collection and decision making. It's Experiments All The Way Down "We established that software has become societal infrastructure. That software is different - it's not a construction project with a fixed endpoint; it's a living capability that evolves with the business." This five-episode series has built a complete picture: Episode 1 established that software is societal infrastructure and fundamentally different from traditional construction. Episode 2 diagnosed the problem - project management thinking treats software like building a bridge, creating cascade failures throughout organizations. Episode 3 showed that solutions already exist, with organizations like Spotify, Amazon, and Etsy practicing software-native development successfully. Episode 4 exposed the organizational immune system - the four barriers preventing transformation: the project mindset, funding models, business/IT separation, and risk management theater. Today's episode provides the blueprint - the five principles forming the operating system for software-native organizations. This isn't theory. This is how software-native organizations already operate. The question isn't whether this works - we know it does. The question is: how do you get started? The Next Step In Building A Software-Native Organization "This is how transformation starts - not with grand pronouncements or massive reorganizations, but with conversations and small experiments that compound over time. Software is too important to society to keep managing it wrong." Start this week by doing two things.  First, start a conversation: pick one of these five principles - whichever resonates most with your current challenges - and share it with your team or leadership. Don't present it as "here's what we should do" but as "here's an interesting idea - what would this mean for us?" That conversation will reveal where you are, what's blocking you, and what might be possible.  Second, run one small experiment: take something you're currently doing and frame it as an experiment with a clear goal, action, and learning measure. Make it small, make it fast - one week maximum, 24 hours if you can - then stop and learn. You now have the blueprint. You understand the barriers. You've seen the alternatives. The transformation is possible, and it starts with you. Recommended Further Reading Tom Gilb and Simon Holzapfel episodes on continuous strategy  The book by Christensen, Clayton: "The Innovator's Dilemma"  The book by Gojko Adzic: Impact Mapping  Ukraine drone warfare Company lifespan statistics: Innosight research on S&P 500 turnover  Stripe's impact on internet businesses Amazon AWS origin story DevOps observability practices About Vasco Duarte Vasco Duarte is a thought leader in the Agile space, co-founder of Agile Finland, and host of the Scrum Master Toolbox Podcast, which has over 10 million downloads. Author of NoEstimates: How To Measure Project Progress Without Estimating, Vasco is a sought-after speaker and consultant helping organizations embrace Agile practices to achieve business success. You can link with Vasco Duarte on LinkedIn.

The Day After Christmas: Carry the Light ForwardHey everyone, and welcome to today's Agile Daily Standup.If you're listening to this on the Friday after Christmas, chances are things feel… a little quieter.The presents are unwrapped.The calendars are lighter.The pace is slower.And honestly? That's not a bad thing.Because the day after Christmas gives us something rare — space.Space to breathe.Space to reflect.Space to decide what we want to carry forward instead of rushing straight back into “busy.”Christmas — no matter how you celebrate — is a reminder of something important:That the most meaningful things in life don't arrive with noise or urgency. They arrive quietly.In Agile, we talk a lot about delivery.But today is about direction.Before the year accelerates again, ask yourself three simple questions:What gave me energy this year?What drained me?And what am I ready to leave behind as we step into the new one?This isn't about resolutions. It's about intentionality.Great teams don't just plan work — they create space for learning, gratitude, and renewal.Great leaders don't just push forward — they pause long enough to make sure they're headed the right way.So today, be kind to yourself.Be patient with your team.And remember that progress doesn't always look like motion.Sometimes, progress looks like rest.As we move toward a new year, carry the best parts of this season with you — the gratitude, the generosity, the hope — and let those guide how you show up for the people around you.Thanks for spending a few minutes with me today.I'm grateful for you, for this community, and for the journey we're all on together.Until next time — stay kind, stay curious, and stay 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/

Send Bidemi a Text Message!In this episode, host Bidemi Ologunde spoke with Ivan Gekht, CEO of Gehtsoft, a family-run software company with over 20 years of Agile R&D experience. They explored Ivan's journey from Siberia to building a team that tackles “impossible” business challenges with science, adaptability, and integrity. How can Agile methods truly reduce project risk instead of becoming just another buzzword? What does it take to build healthier, more productive relationships with technology—both for teams and end users? And how can tech companies meaningfully support minority-, women-, and veteran-owned businesses while still innovating and scaling?Support for The Bid Picture Podcast comes from Skylight Calendar—the family-friendly digital calendar that helps everyone stay on the same page. With a quick setup and an easy-to-read display in a shared space, Skylight makes it simple to keep track of school events, practices, appointments, and family plans—so mornings run smoother and everyone knows what's next. Make your home the place where schedules finally make sense. Skylight Calendar—because family life works better when it's shared. Learn more at myskylight.com.Support for The Bid Picture Podcast comes from Black Rifle Coffee Company, a veteran-founded coffee brand roasting premium beans for people who love a strong start to the day. From bold blends to convenient ready-to-drink cans, Black Rifle Coffee keeps you fueled for whatever's ahead. Check them out at blackriflecoffee.com.Support the show

BONUS: Breaking Through The Organizational Immune System - Why Software-Native Organizations Are Still Rare With Vasco Duarte In this BONUS episode, we explore the organizational barriers that prevent companies from becoming truly software-native. Despite having proof that agile, iterative approaches work at scale—from Spotify to Amazon to Etsy—most organizations still struggle to adopt these practices. We reveal the root cause behind this resistance and expose four critical barriers that form what we call "The Organizational Immune System." This isn't about resistance to change; it's about embedded structures, incentives, and mental models that actively reject beneficial transformation. The Root Cause: Project Management as an Incompatible Mindset "Project management as a mental model is fundamentally incompatible with software development. And will continue to be, because 'project management' as an art needs to support industries that are not software-native." The fundamental problem isn't about tools or practices—it's about how we think about work itself. Project management operates on assumptions that simply don't hold true for software development. It assumes you can know the scope upfront, plan everything in advance, and execute according to that plan. But software is fundamentally different. A significant portion of the work only becomes visible once you start building. You discover that the "simple" feature requires refactoring three other systems. You learn that users actually need something different than what they asked for. This isn't poor planning—it's the nature of software. Project management treats discovery as failure ("we missed requirements"), while software-native thinking treats discovery as progress ("we learned something critical"). As Vasco points out in his NoEstimates work, what project management calls "scope creep" should really be labeled "value discovery" in software—because we're discovering more value to add. Discovery vs. Execution: Why Software Needs Different Success Metrics "Software hypotheses need to be tested in hours or days, not weeks, and certainly not months. You can't wait until the end of a 12-month project to find out your core assumption was wrong." The timing mismatch between project management and software development creates fundamental problems. Project management optimizes for plan execution with feedback loops that are months or years long, with clear distinctions between teams doing requirements, design, building, and testing. But software needs to probe and validate assumptions in hours or days. Questions like "Will users actually use this feature?" or "Does this architecture handle the load?" can't wait for the end of a 12-month project. When we finally discover our core assumption was wrong, we need to fully replan—not just "change the plan." Software-native organizations optimize for learning speed, while project management optimizes for plan adherence. These are opposing and mutually exclusive definitions of success. The Language Gap: Why Software Needs Its Own Vocabulary "When you force software into project management language, you lose the ability to manage what actually matters. You end up tracking task completion while missing that you're building the wrong thing." The vocabulary we use shapes how we think about problems and solutions. Project management talks about tasks, milestones, percent complete, resource allocation, and critical path. Software needs to talk about user value, technical debt, architectural runway, learning velocity, deployment frequency, and lead time. These aren't just different words—they represent fundamentally different ways of thinking about work. When organizations force software teams to speak in project management terms, they lose the ability to discuss and manage what actually creates value in software development. The Scholarship Crisis: An Industry-Wide Knowledge Gap "Agile software development represents the first worldwide trend in scholarship around software delivery. But most organizational investment still goes into project management scholarship and training." There's extensive scholarship in IT, but almost none about delivery processes until recently. The agile movement represents the first major wave of people studying what actually works for building software, rather than adapting thinking from manufacturing or construction. Yet most organizational investment continues to flow into project management certifications like PMI and Prince2, and traditional MBA programs—all teaching an approach with fundamental problems when applied to software. This creates an industry-wide challenge: when CFOs, executives, and business partners all think in project management terms, they literally cannot understand why software needs to work differently. The mental model mismatch isn't just a team problem—it's affecting everyone in the organization and the broader industry. Budget Cycles: The Project Funding Trap "You commit to a scope at the start, when you know the least about what you need to build. The budget runs out exactly when you're starting to understand what users actually need." Project thinking drives project funding: organizations approve a fixed budget (say $2M over 9 months) to deliver specific features. This seems rational and gives finance predictability, but it's completely misaligned with how software creates value. Teams commit to scope when they know the least about what needs building. The budget expires just when they're starting to understand what users actually need. When the "project" ends, the team disbands, taking all their accumulated knowledge with them. Next year, the cycle starts over with a new project, new team, and zero retained context. Meanwhile, the software itself needs continuous evolution, but the funding structure treats it as a series of temporary initiatives with hard stops. The Alternative: Incremental Funding and Real-Time Signals "Instead of approving $2M for 9 months, approve smaller increments—maybe $200K for 6 weeks. Then decide whether to continue based on what you've learned." Software-native organizations fund teams working on products, not projects. This means incremental funding decisions based on learning rather than upfront commitments. Instead of detailed estimates that pretend to predict the future, they use lightweight signals from the NoEstimates approach to detect problems early: Are we delivering value regularly? Are we learning? Are users responding positively? These signals provide more useful information than any Gantt chart. Portfolio managers shift from being "task police" asking "are you on schedule?" to investment curators asking "are we seeing the value we expected? Should we invest more, pivot, or stop?" This mirrors how venture capital works—and software is inherently more like VC than construction. Amazon exemplifies this approach, giving teams continuous funding as long as they're delivering value and learning, with no arbitrary end date to the investment. The Business/IT Separation: A Structural Disaster "'The business' doesn't understand software—and often doesn't want to. They think in terms of features and deadlines, not capabilities and evolution." Project thinking reinforces organizational separation: "the business" defines requirements, "IT" implements them, and project managers coordinate the handoff. This seems logical with clear specialization and defined responsibilities. But it creates a disaster. The business writes requirements documents without understanding what's technically possible or what users actually need. IT receives them, estimates, and builds—but the requirements are usually wrong. By the time IT delivers, the business need has changed, or the software works but doesn't solve the real problem. Sometimes worst of all, it works exactly as specified but nobody wants it. This isn't a communication problem—it's a structural problem created by project thinking. Product Thinking: Starting with Behavior Change "Instead of 'build a new reporting dashboard,' the goal is 'reduce time finance team spends preparing monthly reports from 40 hours to 4 hours.'" Software-native organizations eliminate the business/IT separation by creating product teams focused on outcomes. Using approaches like Impact Mapping, they start with behavior change instead of features. The goal becomes a measurable change in business behavior or performance, not a list of requirements. Teams measure business outcomes, not task completion—tracking whether finance actually spends less time on reports. If the first version doesn't achieve that outcome, they iterate. The "requirement" isn't sacred; the outcome is. "Business" and "IT" collaborate on goals rather than handing off requirements. They're on the same team, working toward the same measurable outcome with no walls to throw things over. Spotify's squad model popularized this approach, with each squad including product managers, designers, and engineers all focused on the same part of the product, all owning the outcome together. Risk Management Theater: The Appearance of Control "Here's the real risk in software: delivering software that nobody wants, and having to maintain it forever." Project thinking creates elaborate risk management processes—steering committees, gate reviews, sign-offs, extensive documentation, and governance frameworks. These create the appearance of managing risk and make everyone feel professional and in control. But paradoxically, the very practices meant to manage risk end up increasing the risk of catastrophic failure. This mirrors Chesterton's Fence paradox. The real risk in software isn't about following the plan—it's delivering software nobody wants and having to maintain it forever. Every line of code becomes a maintenance burden. If it's not delivering value, you're paying the cost forever or paying additional cost to remove it later. Traditional risk management theater doesn't protect against this at all. Gates and approvals just slow you down without validating whether users will actually use what you're building or whether the software creates business value. Agile as Risk Management: Fast Learning Loops "Software-native organizations don't see 'governance' and 'agility' as a tradeoff. Agility IS governance. Fast learning loops ARE how you manage risk." Software-native organizations recognize that agile and product thinking ARE risk management. The fastest way to reduce risk is delivering quickly—getting software in front of real users in production with real data solving real problems, not in demos or staging environments. Teams validate expected value by measuring whether software achieves intended outcomes. Did finance really reduce their reporting time? Did users actually engage with the feature? When something isn't working, teams change it quickly. When it is working, they double down. Either way, they're managing risk through rapid learning. Eric Ries's Lean Startup methodology isn't just for startups—it's fundamentally a software-native management practice. Build-Measure-Learn isn't a nice-to-have; it's how you avoid the catastrophic risk of building the wrong thing. The Risk Management Contrast: Theater vs. Reality "Which approach actually manages risk? The second one validates assumptions quickly and cheaply. The first one maximizes your exposure to building the wrong thing." The contrast between approaches is stark. Risk management theater involves six months of requirements gathering and design, multiple approval gates that claim to prevent risk but actually accumulate it, comprehensive test plans, and a big-bang launch after 12 months. Teams then discover users don't want it—and now they're maintaining unwanted software forever. The agile risk management approach takes two weeks to build a minimal viable feature, ships to a subset of users, measures actual behavior, learns it's not quite right, iterates in another two weeks, validates value before scaling, and only maintains software that's proven valuable. The second approach validates assumptions quickly and cheaply. The first maximizes exposure to building the wrong thing. The Immune System in Action: How Barriers Reinforce Each Other "When you try to 'implement agile' without addressing these structural barriers, the organization's immune system rejects it. Teams might adopt standups and sprints, but nothing fundamental changes." These barriers work together as an immune system defending the status quo. It starts with the project management mindset—the fundamental belief that software is like construction, that we can plan it all upfront, that "done" is a meaningful state. That mindset creates funding models that allocate budgets to temporary projects instead of continuous products, organizational structures that separate "business" from "IT" and treat software as a cost center, and risk management theater that optimizes for appearing in control rather than actually learning. Each barrier reinforces the others. The funding model makes it hard to keep stable product teams. The business/IT separation makes it hard to validate value quickly. The risk theater slows down learning loops. The whole system resists change—even beneficial change—because each part depends on the others. This is why so many "agile transformations" fail: they treat the symptoms (team practices) without addressing the disease (organizational structures built on project thinking). Breaking Free: Seeing the System Clearly "Once you see the system clearly, you can transform it. You now know the root cause, how it manifests, and what the alternatives look like." Understanding these barriers is empowering. It's not that people are stupid or resistant to change—organizations have structural barriers built on a fundamental mental model mismatch. But once you see the system clearly, transformation becomes possible. You now understand the root cause (project management mindset), how it manifests in your organization (funding models, business/IT separation, risk theater), and what the alternatives look like through real examples from companies successfully operating as software-native organizations. The path forward requires addressing the disease, not just the symptoms—transforming the fundamental structures and mental models that shape how your organization approaches software. Recommended Further Reading Vasco's article on 5 examples of software disasters that show we are in the middle of another software crisis NoEstimates movement: Vasco Duarte's work and book Impact Mapping: Gojko Adzic's framework Lean Startup: Eric Ries, "The Lean Startup" Outcome-based funding model Spotify squad model: Henrik Kniberg's materials Chesterton's fence paradox About Vasco Duarte Vasco Duarte is a thought leader in the Agile space, co-founder of Agile Finland, and host of the Scrum Master Toolbox Podcast, which has over 10 million downloads. Author of NoEstimates: How To Measure Project Progress Without Estimating, Vasco is a sought-after speaker and consultant helping organizations embrace Agile practices to achieve business success. You can link with Vasco Duarte on LinkedIn.

From all of us at Cloud Realities, MERRY CHRISTMAS!!!! Back in our December 2022 Christmas special, we explored the far reaches of reality, asking whether we live in a simulation and if that even matters. Now, we return to that question with fresh perspectives and new challenges…In this last Cloud Realities podcast of 2025, Dave, Esmee and Rob return to the simulation with Anders Indset, philosopher, author, and long-time friend of the show, revisiting a question that's been quietly running underneath everything we've discussed since 2022: If reality itself is information and what does that mean for being human? TLDR:00:58 – It's Christmas!08:32 – Major announcement and reflections on the Cloud Realities podcast journey15:32 – Celebrating three big wins: B2B Marketing Awards (Best Content, Best Customer Retention) and The Drum (Best Creative Audio)22:55 – Is there a next thing?23:30 – Welcoming Anders Indset, who shares his vision for practical philosophy and the future of human/AI co-evolution32:02 – Exploring the Quantum Economy and the Singularity Paradox58:10 – Deep dive into the Simulation Hypothesis, revisiting the 2022 discussion and Rob is again confused...01:27:45 – Anders enjoying Christmas in the Norwegian wilderness01:29:40 – Edit pointGuestAnders Indset: https://www.linkedin.com/in/andersindset/ or andersindset.comAdditional information: thequantumeconomy.com and tomorrowmensch.comHostsDave Chapmanger: https://www.linkedin.com/in/chapmandr/Esmee van de Gluhwein: https://www.linkedin.com/in/esmeevandegiessen/Rob Snowmananahan: https://www.linkedin.com/in/rob-kernahan/ProductionDr Mike van Der Buabbles: https://www.linkedin.com/in/marcel-vd-burg/Dave Chapmanger: https://www.linkedin.com/in/chapmandr/ SoundBen Jingle: https://www.linkedin.com/in/ben-corbett-3b6a11135/Louis Snow:  https://www.linkedin.com/in/louis-corbett-087250264/ 'Cloud Realities' is an original podcast from Capgemini

In this episode I'm going to do something a little different. As we wind down for the year, we're going to be running some of our favorites from 2025 until the new year begins.Let's take a look back at some of the overall themes discussed and point out a few highlights for me. I won't be able to highlight everything of course but I found 5 themes really interesting. And, I won't lie - I had a little help from AI in doing this. But that's also kind of the point. We have all been using AI to do things to make our work easier, and I thought that poring through 150+ episodes recorded over 12 months is a perfect thing to have AI help me with. About Greg Kihlström Greg Kihlström is a best-selling author, speaker, and entrepreneur, and serves as an advisor and consultant to top companies on marketing technology, marketing operations, and digital transformation initiatives. He has worked with some of the world's top brands, including Adidas, Coca-Cola, FedEx, HP, Marriott, Nationwide Insurance, Victoria's Secret, and Toyota. He is a multiple-time Co-Founder and C-level leader, leading his digital experience agency to be acquired in 2017, successfully exited an HR technology platform provider he co-founded in 2020, and led a SaaS startup to be acquired by a leading edge computing company in 2021. He currently advises and sits on the Board of a marketing technology startup.In addition to his experience as an entrepreneur and leader, he earned his MBA, is currently a doctoral candidate for a DBA in Business Intelligence, and teaches several courses and workshops as a member of the School of Marketing Faculty at the Association of National Advertisers. He has served on the Virginia Tech Pamplin College of Business Marketing Mentorship Advisory Board, the University of Richmond's CX Advisory Board, and was the founding Chair of the American Advertising Federation's National Innovation Committee.  Greg is Lean Six Sigma Black Belt certified, is an Agile Certified Coach (ICP-ACC), and holds a certification in Business Agility (ICP-BAF).  Greg Kihlström on LinkedIn: https://www.linkedin.com/in/gregkihlstrom Resources The Agile Brand Podcast: https://www.gregkihlstrom.com The Agile Brand podcast is brought to you by TEKsystems. Learn more here: https://www.teksystems.com/versionnextnow Catch the future of e-commerce at eTail Palm Springs, Feb 23-26 in Palm Springs, CA. Go here for more details: https://etailwest.wbresearch.com/ Enjoyed the show? Tell us more at and give us a rating so others can find the show at: https://ratethispodcast.com/agileConnect with Greg on LinkedIn: https://www.linkedin.com/in/gregkihlstromDon't miss a thing: get the latest episodes, sign up for our newsletter and more: https://www.theagilebrand.showCheck out The Agile Brand Guide website with articles, insights, and Martechipedia, the wiki for marketing technology: https://www.agilebrandguide.com The Agile Brand is produced by Missing Link—a Latina-owned strategy-driven, creatively fueled production co-op. From ideation to creation, they craft human connections through intelligent, engaging and informative content. https://www.missinglink.company

Xmas Special: Recovering the Essence of Agile - What's Already Working in Software-Native Organizations In this BONUS Xmas Special episode, we explore what happens when we strip away the certifications and branded frameworks to recover the essential practices that make software development work. Building on Episode 2's exploration of the Project Management Trap, Vasco reveals how the core insights that sparked the Agile revolution remain valid - and how real organizations like Spotify, Amazon, and Etsy embody these principles to thrive in today's software-driven world. The answer isn't to invent something new; it's to amplify what's already working. Agile as an Idea, Not a Brand "The script (sold as the solution) will eventually kill the possibility of the conversation ever happening with any quality." We establish a parallel between good conversations and good software development. Just as creating "The Certified Conversational Method™" with prescribed frameworks and certification levels would miss the point of genuine dialogue, the commodification of agile into Agile™ has obscured its essential truth. The core idea was simple and powerful: build software in small increments, get it in front of real users quickly, learn from their actual behavior, adapt based on what you learn, and repeat continuously. This wasn't revolutionary - it was finally recognizing how software actually works. You can't know if your hypothesis about user needs is correct until users interact with it, so optimize for learning speed, not planning precision. But when the need to certify and validate "doing Agile right" took over, the idea got packaged, and often the package became more important than the principle. Four Fundamental Practices That Enable Living Software "Every deployment was a chance to see how users actually responded." Software-native organizations distinguish themselves through core practices that align with software as a living capability. In this episode, we review four critical ones: First, iterative delivery means shipping the smallest valuable increment possible and building on it - Etsy's transformation from quarterly releases in 2009 to shipping 50+ times per day by 2012 exemplifies this approach, where each small change serves as a learning opportunity. Second, tight feedback loops get software in front of real users as fast as possible, whether through paper prototypes or production deployments. Third, continuous improvement of the process itself creates meta-feedback loops, as demonstrated by Amazon's "You Build It, You Run It" principle introduced by Werner Vogels in 2006, where development teams running their own services in production learn rapidly to write more resilient code. Fourth, product thinking over project thinking organizes teams around long-lived products rather than temporary projects, allowing teams to develop deep expertise and become living capabilities themselves, accumulating knowledge and improving over time. Spotify's Evolutionary Approach "The Spotify model has nothing to do with Spotify really. It was just a snapshot of how that one company worked at the time." Spotify's journey reveals a critical insight often missed in discussions of their famous organizational model. Starting with standard Scrum methodology pre-2012, they adopted the squad model around 2012 with autonomous teams organized into tribes, documented in Henrik Kniberg and Anders Ivarsson's influential white paper (direct PDF link). But post-2016, internal staff and agile coaches noted that the "Spotify model" had become mythology, and the company had moved on from original concepts to address new challenges. As Kniberg himself later reflected, the model has taken on a life of its own, much like Lean's relationship to Toyota. The key insight isn't the specific structure - it's that Spotify treated their own organizational design as a living capability, continuously adapting based on what worked and what didn't rather than implementing "the model" and declaring victory. That's software-native thinking applied to organization design itself. Amazon's Two-Pizza Teams and Massive Scale "Amazon deploys code every 11.7 seconds on average. That's over 7,000 deployments per day across the organization." (see this YouTube video of this talk) Amazon's two-pizza team principle goes far deeper than team size. Teams small enough to be fed with two pizzas (roughly 6-10 people) gain crucial autonomy and ownership: each team owns specific services and APIs, makes their own technical decisions, runs their services in production, and manages inter-team dependencies through APIs rather than meetings. This structure enabled Amazon to scale massively while maintaining speed, as teams could iterate independently without coordinating with dozens of other teams. The staggering deployment frequency - over 7,000 times per day as of 2021 - is only possible with a software-native structure for the company itself, demonstrating that this isn't just about managing software delivery but touches everything, including how teams are organized. Why These Practices Work "These practices work because they align with what software actually is: a living, evolvable capability." The effectiveness of software-native approaches stems from their alignment with software's true nature. Traditional project approaches assume we can know requirements upfront, estimate accurately, build it right the first time, and reach a meaningful "done" state. Software-native approaches recognize that requirements emerge through interaction with users, estimation is less important than rapid learning, "right" is discovered iteratively rather than designed upfront, and "done" only happens when we stop evolving the software. When Etsy ships 50 times per day, they're optimizing for learning where each deployment is a hypothesis test. When Amazon's teams own services end-to-end, they're creating tight feedback loops where teams feel the pain of their own decisions directly. When Spotify continuously evolves their organizational model, they're treating their own structure as software that should adapt to changing needs. The Incomplete Picture and the Question of Universal Adoption "If these approaches work, why aren't they universal?" We're not trying to paint a unrealistically rosy picture - these organizations aren't perfect. Spotify has had well-documented challenges with their model, Amazon's culture has been criticized as demanding and sometimes brutal, and Etsy has gone through multiple strategic shifts. But what matters is that they're practicing software-native development at scale, and it's working well enough that they can compete and thrive. They're not following a playbook perfectly but embodying principles and adapting continuously. This raises the critical question that will be explored in the next episode: if these approaches work, why do so many organizations still operate in project mode, and why do "agile transformations" so often fail to deliver real change? Understanding the resistance - what we call The Organizational Immune System - is essential to overcoming it. References for Further Reading A book on the shift from "projects" to "products": "Project to Product" by Mik Kersten About Vasco Duarte Vasco Duarte is a thought leader in the Agile space, co-founder of Agile Finland, and host of the Scrum Master Toolbox Podcast, which has over 10 million downloads. Author of NoEstimates: How To Measure Project Progress Without Estimating, Vasco is a sought-after speaker and consultant helping organizations embrace Agile practices to achieve business success.  You can link with Vasco Duarte on LinkedIn.

Xmas Special: Why project management tools fail software development - and what works instead! In this BONUS episode, we dive deep into The Project Management Trap, continuing our exploration from Episode 1 where we established that software is societal infrastructure being managed with tools from the 1800s. We examine why project management frameworks - designed for building railroads and ships - are fundamentally misaligned with software development, and what happens when we treat living capabilities like construction projects with defined endpoints. The Origin Story - Where Project Management Came From "The problem isn't that project management is bad. The problem is that software isn't building a railroad or a building, or setting up a process that will run forever (like a factory)." Project management emerged from industries with hard physical constraints - building the Transcontinental Railroad in the 1860s, coordinating factory machinery, managing finite and expensive materials. The Gantt chart, invented in the 1910s for factory scheduling, worked brilliantly for coordinating massive undertakings with calculable physics, irreversible decisions, and clear completion points. When the rails met, you were done. When the bridge was built, the project ended. These tools gave us remarkable precision for building ships, bridges, factories, and highways. But software operates in a completely different reality - one where the raw materials are time and brainpower, not minerals and hardware, and where the transformation happens in unique creative moments rather than repeated mechanical movements. The Seductive Clarity Of Project Management Artifacts "In software, we almost never know either of those things with certainty." Project management is tempting for software leaders because it offers comforting certainty. Gantt charts show every task laid out, milestones mark clear progress, "percent complete" gives us a number, and a defined "done" promises relief. The typical software project kickoff breaks down into neat phases: requirements gathering (6 weeks), design (4 weeks), development (16 weeks), testing (4 weeks), deployment (2 weeks) - total 32 weeks, done by Q3. Leadership loves this. Finance can budget it. Everyone can plan around it. But this is false precision. Software isn't pouring concrete where you measure twice and pour once. Every line of code is a hypothesis about what users need and how the system should behave. That 32-week plan assumes we know exactly what to build and exactly how long each piece takes - assumptions that are almost never true in software development. The Completion Illusion "Software products succeed by evolving. Projects end; products adapt." "Done" is the wrong goal for living software. We expand on the Slack story from Episode 1 to illustrate this point. If Slack's team had thought in project terms in 2013, they might have built a functional tool with channels, direct messages, file sharing, and search - shipped on time and on budget by Q2 2014, project complete. But that wasn't the end; it was the beginning. Through continuous user feedback and evolution, Slack added threaded conversations (2017), audio/video calls (2016), workflow automation (2019), and Canvas for knowledge management (2023). Each wasn't maintenance or bug fixing - these were fundamental enhancements. Glass's research shows that 60% of maintenance costs are enhancements, not fixes. By 2021, when Salesforce acquired Slack for $27.7 billion, it bore little resemblance to the 2014 version. The value wasn't in that initial "project" - it was in the continuous evolution. If they'd thought "build it, ship it, done," Slack would have died competing against HipChat and Campfire. When Projects Succeed (Well, Some Do, Anyway) But Software Fails "They tried to succeed at project management. They ended up failing at both software delivery AND project management!" Vasco references his article "The Software Crisis is Real," examining five distinct cases from five different countries that represent what's wrong with project thinking for software. These projects tried hard to do everything right by project management standards: detailed requirements (thousands of pages), milestone tracking, contractor coordination, hitting fixed deadlines, and proper auditing. What they didn't have was iterative delivery to test with real users early, feedback loops to discover problems incrementally, adaptability to change based on learning, or a "living capability" mindset. Project thinking demanded: get all requirements right upfront (otherwise no funding), build it all, test at the end, launch on deadline. Software thinking demands: launch something minimal early, get real user feedback, iterate rapidly, evolve the capability. These projects succeeded at following project management rules but failed at delivering valuable software. What Software-Native Delivery Management Looks Like "Software is unpredictable not because we're bad at planning - it's unpredictable because we're creating novel solutions to complex problems, and in a completely different economic system." If not projects, then what? Vasco has been exploring this question for years, since publishing the NoEstimates book. The answer starts with thinking in products and capabilities, not projects - recognizing that products have ongoing evolution, capabilities are cultivated and improved rather than "delivered" and done, and value is measured in outcomes rather than task completion. Instead of comprehensive planning, we need iteration and constant decision-making based on validated hypotheses: start with "We believe users need X," run experiments by building small and testing with real users, then learn and adapt. Instead of fixed scope, define the problem (not the solution), allow the solution to evolve as you learn, and optimize for learning speed rather than task completion.  The contrast is clear: project thinking says "We will build features A, B, C, D, and E by Q3, then we're done." Software-native thinking says "We're solving problem X for users. We'll start with the riskiest hypothesis, build a minimal version, ship it to 100 users next week, and learn whether we're on the right track." The appropriate response to software's inherent unpredictability isn't better planning - it's faster learning. References for Further Reading Vasco Duarte's article on the Software Leadership Workshop newsletter: "The Software Crisis is Real"  Glass, Robert L. "Facts and Fallacies of Software Engineering" - Fact 42: "Enhancement is responsible for roughly 60 percent of software maintenance costs. Error correction is roughly 17 percent. Therefore, software maintenance is largely about adding new capability to old software, not fixing it." NoEstimates Book: How To Measure Project Progress Without Estimating Slack evolution timeline: Company history and feature releases  The unexpected design challenge behind Slack's new threaded conversations Slack voice and video chat Slack launches admin workflow automation and announcement channels  Meet Slack Canvas - Slack's answer to the knowledge management problem. About Vasco Duarte Vasco Duarte is a thought leader in the Agile space, co-founder of Agile Finland, and host of the Scrum Master Toolbox Podcast, which has over 10 million downloads. Author of NoEstimates: How To Measure Project Progress Without Estimating, Vasco is a sought-after speaker and consultant helping organizations embrace Agile practices to achieve business success. You can link with Vasco Duarte on LinkedIn.

Xmas Special: Software Industry Transformation - Why Software Development Must Mature Welcome to the 2025 Xmas special - a five-episode deep dive into how software as an industry needs to transform. In this opening episode, we explore the fundamental disconnect between how we manage software and what software actually is. From small businesses to global infrastructure, software has become the backbone of modern society, yet we continue to manage it with tools designed for building ships in the 1800s. This episode sets the stage for understanding why software development must evolve into a mature discipline. Software Runs Everything Now "Without any single piece, I couldn't operate - and I'm tiny. Scale this reality up: software isn't just in tech companies anymore." Even the smallest businesses today run entirely on software infrastructure. A small consulting and media business depends on WordPress for websites, Kajabi for courses, Stripe for payments, Quaderno for accounting, plus email, calendar, CRM systems, and AI assistants for content creation. The challenge? We're managing this critical infrastructure with tools designed for building physical structures with fixed requirements - an approach that fundamentally misunderstands what software is and how it evolves. This disconnect has to change. The Oscillation Between Technology and Process "AI amplifies our ability to create software, but doesn't solve the fundamental process problems of maintaining, evolving, and enhancing that software over its lifetime." Software improvement follows a predictable pattern: technology leaps forward, then processes must adapt to manage the new complexity. In the 1960s-70s, we moved from machine code to COBOL and Fortran, which was revolutionary but led to the "software crisis" when we couldn't manage the resulting complexity. This eventually drove us toward structured programming and object-oriented programming as process responses, which, in turn, resulted in technology changes! Today, AI tools like GitHub Copilot, ChatGPT, and Claude make writing code absurdly easy - but writing code was never the hard part. Robert Glass documents in "Facts and Fallacies of Software Engineering" that maintenance typically consumes between 40 and 80 percent of software costs, making "maintenance" probably the most important life cycle phase. We're overdue for a process evolution that addresses the real challenge: maintaining, evolving, and enhancing software over its lifetime. Software Creates An Expanding Possibility Space "If they'd treated it like a construction project ('ship v1.0 and we're done'), it would never have reached that value." Traditional project management assumes fixed scope, known solutions, and a definable "done" state. The Sydney Opera House exemplifies this: designed in 1957, completed in 1973, ten times over budget, with the architect resigning - but once built, it stands with "minimal" (compared to initial cost) maintenance. Software operates fundamentally differently. Slack started as an internal tool for a failed gaming company called Glitch in 2013. When the game failed, they noticed their communication tool was special and pivoted entirely. After launching in 2014, Slack continuously evolved based on user feedback: adding threads in 2017, calls in 2016, workflow builder in 2019, and Canvas in 2023. Each addition changed what was possible in organizational communication. In 2021, Salesforce acquired Slack for $27.7 billion precisely because it kept evolving with user needs. The key difference is that software creates possibility space that didn't exist before, and that space keeps expanding through continuous evolution. Software Is Societal Infrastructure "This wasn't a cyber attack - it was a software update gone wrong." Software has become essential societal infrastructure, not optional and not just for tech companies. In July 2024, a faulty software update from cybersecurity firm CrowdStrike crashed 8.5 million Windows computers globally. Airlines grounded flights, hospitals canceled surgeries, banks couldn't process transactions, and 911 services went down. The global cost exceeded $10 billion. This wasn't an attack - it was a routine update that failed catastrophically. AWS outages in 2021 and 2023 took down major portions of the internet, stopping Netflix, Disney+, Robinhood, and Ring doorbells from working. CloudFlare outages similarly cascaded across daily-use services. When software fails, society fails. We cannot keep managing something this critical with tools designed for building physical things with fixed requirements. Project management was brilliant for its era, but that era isn't this one. The Path Ahead: Four Critical Challenges "The software industry doesn't just need better tools - it needs to become a mature discipline." This five-episode series will address how we mature as an industry by facing four critical challenges: Episode 2: The Project Management Trap - Why we think in terms of projects, dates, scope, and "done" when software is never done, and how this mindset prevents us from treating software as a living capability Episode 3: What's Already Working - The better approaches we've already discovered, including iterative delivery, feedback loops, and continuous improvement, with real examples of companies doing this well Episode 4: The Organizational Immune System - Why better approaches aren't universal, how organizations unconsciously resist what would help them, and the hidden forces preventing adoption Episode 5: Software-Native Organizations - What it means to truly be a software-native organization, transforming how the business thinks, not just using agile on teams Software is too important to our society to keep getting it wrong. We have much of the knowledge we need - the challenge is adoption and evolution. Over the next four episodes, we'll build this case together, starting with understanding why we keep falling into the same trap. References For Further Reading Glass, Robert L. "Facts and Fallacies of Software Engineering" - Fact 41, page 115  CrowdStrike incident: https://en.wikipedia.org/wiki/2024_CrowdStrike_incident  AWS outages: 2021 (Dec 7), 2023 (June 13),  and November 2025 incidents  CloudFlare outages: 2022 (June 21), and November 2025 major incident  Slack history and Salesforce acquisition: https://en.wikipedia.org/wiki/Slack_(software)  Sydney Opera House: https://en.wikipedia.org/wiki/Sydney_Opera_House About Vasco Duarte Vasco Duarte is a thought leader in the Agile space, co-founder of Agile Finland, and host of the Scrum Master Toolbox Podcast, which has over 10 million downloads. Author of NoEstimates: How To Measure Project Progress Without Estimating, Vasco is a sought-after speaker and consultant helping organizations embrace Agile practices to achieve business success. You can link with Vasco Duarte on LinkedIn.

Natalia Curusi: From Spreadsheets to Discovery—Helping POs Make the Transition The Great Product Owner: Taking Ownership and Coaching the Team Forward 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.   "That person was not just a great product owner, but a great coach—he had excellent communication and stakeholder management skills, and he coached myself as a Scrum Master, showing me how product ownership should look like." - Natalia Curusi   Natalia worked with a Product Owner who embodied everything the role should be. He didn't come from a technical background, but he possessed exceptional domain knowledge, outstanding communication skills, and stakeholder management expertise you rarely find in one person. What made him truly remarkable was that he coached everyone around him, including Natalia as the Scrum Master.  He demonstrated full empowerment and ownership—making decisions himself rather than constantly escalating to higher management. When risks needed to be taken, he took them with courage and conviction. The team trusted him completely because he balanced business needs with team capacity, always understanding what they could realistically achieve. Over the past five years, this person has been promoted multiple times and now serves as a global director of product, still with the same company.  When Natalia thinks about what great product ownership looks like, she thinks of him—someone who combined technical understanding with coaching ability, took genuine ownership of outcomes, and empowered the team through clear vision and decisive leadership. These are exactly the skills that are hardest to find in the market, yet when you find them, the impact is transformative for the entire organization.   Self-reflection Question: Does your Product Owner take ownership and make decisions, or do they constantly escalate to higher management, preventing the team from moving forward with confidence? The Bad Product Owner: Assigned Without Training, Support, or Willingness "She was a great subject matter expert with deep domain knowledge, but the organization assigned her the product owner role without her willingness, without training, and while she was already 80% loaded with other responsibilities." - Natalia Curusi   Natalia encountered a Product Owner anti-pattern that reveals a systemic organizational failure. The person was an exceptional subject matter expert with incredible domain knowledge, but when the organization decided to adopt Agile, they assigned her the PO role like sticking a label on a box—no training, no consent, no preparation. She was already working at 80% capacity on other responsibilities and had no understanding of what product ownership meant. Frustrated and overwhelmed, she approached the role from a command-and-control mindset. At the project start, she brought a massive spreadsheet of requirements, expecting the team to implement them sequentially.  The team tried a different approach, wanting to understand problems before discussing solutions, but the PO surprised everyone by re-introducing the spreadsheet in a later meeting—a clear sign of misalignment and broken trust. Natalia, recognizing this was a battle she couldn't win without organizational support, chose to manage the relationship rather than create open conflict. She worked to mediate between the PO's spreadsheet approach and the team's need for discovery and iterative development. The real anti-pattern wasn't the individual—it was the organization assigning critical roles without providing training, time, or psychological safety. This situation illustrates why product ownership fails: not from bad people, but from bad systems that set people up to fail.   Self-reflection Question: When you see a struggling Product Owner, are you addressing the individual's behavior or the systemic conditions that set them up to fail in the first place?   [The Scrum Master Toolbox Podcast Recommends]

Natalia Curusi: Measuring What Matters Beyond Velocity and Story Points 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.   "We as Scrum Masters need to put a scope for ourselves—we need to aim to leave the place where we work a little bit better than it was, and to make sure that this place could improve itself without us." - Natalia Curusi   Natalia defines success for Scrum Masters with crystal clarity: leave the organization better than you found it, and ensure it can continue improving when you're gone. This means fostering independence and ownership in teams so they can perform whether you're on vacation, in another meeting, or have moved to coaching other teams.  The opposite pattern—where everything falls apart when the Scrum Master isn't present—reveals someone who hasn't truly succeeded in the role. Natalia also emphasizes the importance of establishing metrics early, but not the traditional ones.  Using velocity as a metric is an anti-pattern that focuses teams on the wrong outcomes. Instead, she recommends metrics like predictability, team morale, psychological safety measured through 360 feedback, and the quality of conversations both within teams and with stakeholders. But metrics alone don't tell the story.  Natalia champions the concept of Gemba walks—going to see what's actually happening, talking to people, observing the reality rather than just reviewing dashboard numbers. Some metrics are easily gamed, others provide only narrow perspectives on reality. The most important practice is using metrics to trigger reflection and adaptation, not as fixed targets. Natalia believes strongly that the quality of conversations—how teams discuss options, make decisions together, and adapt when facing pressure—reveals more about a Scrum Master's success than any velocity chart ever could. The ultimate question: can your team succeed without you?   Self-reflection Question: If you disappeared from your team tomorrow, would they continue improving, or would progress stop until someone replaced you? Featured Retrospective Format for the Week: Spotify Squad Health Check "This is a multidimensional retro that I run with teams every 2 to 3 months—you need around 30 minutes for it, and I often get insights and new ideas from this retrospective that help me as a Scrum Master." - Natalia Curusi   The Spotify Squad Health Check is Natalia's favorite retrospective format because it provides a comprehensive view of team health across multiple dimensions. Unlike traditional retrospectives that might focus on a single sprint or specific issue, this format examines the team's overall state across areas like teamwork, support, mission clarity, and technical quality. Teams rate themselves on various health indicators, creating a visual representation that reveals patterns over time.  What makes this particularly valuable is that it works whether you know the team well or are just starting with them—either way, you gain insights and "aha moments" about where the team truly stands. The multidimensional nature prevents teams from optimizing just one aspect while neglecting others, and the regular cadence (every 2-3 months) allows you to track trends and celebrate improvements.  For Natalia, this format consistently surfaces the hidden challenges that teams might not raise in regular retrospectives, making it an essential tool in her Scrum Master toolkit.   [The Scrum Master Toolbox Podcast Recommends]

Yesterday, I had the chance to visit the Pentagon and sit down with General Chance Saltzman, Chief of Space Operations—the head of the United States Space Force. We talk about the service 6 years into its existence, the state of acquisitions, the threats and space environment today, and what the future may hold for the Space Force when it comes to human spaceflight.This episode of Main Engine Cut Off is brought to you by 32 executive producers—Russell, Natasha Tsakos, Will and Lars from Agile, Theo and Violet, David, Matt, Better Every Day Studios, Warren, The Astrogators at SEE, Josh from Impulse, Stealth Julian, Joakim, Frank, Pat, Joel, Donald, Ryan, Tim Dodd (the Everyday Astronaut!), Joonas, Jan, Steve, Fred, Lee, Kris, Heiko, and four anonymous—and hundreds of supporters.TopicsUnited States Space ForceB. Chance Saltzman > United States Space Force > DisplaySpace Force roadmap set to define what the service needs and why - SpaceNewsUS intel officials “concerned” China will soon master reusable launch - Ars TechnicaAsked why we need Golden Dome, the man in charge points to a Hollywood film - Ars TechnicaSpace Force rolls out new naming scheme for satellites and space weapons - SpaceNewsAndrew Jones on X: “Outrageous images of China's Shijian-26, an apparent new-gen Earth observation satellite, from Maxar. SSD of 1.9 cm.”Andrew Jones on X: “China's CGST has returned the favour, using its Jilin-1 sats to image a Maxar Worldview Legion 2 satellite.”Scott Tilley

Natalia Curusi: Demonstrating Your Value When the Market Questions Agile Roles 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.   "My challenging topic is about the demand of agility in the market—how do we fit ourselves as scrum masters in that AI era? How can we demonstrate our competence and contribution when there's a perception that agile roles bring little value?" - Natalia Curusi   Natalia faces the challenge every Scrum Master in 2025 grapples with: how to demonstrate value in an era when business perceives agile roles as optional overhead. The market has contracted, companies are optimizing budgets, and Scrum Masters often appear first on the chopping block.  There's talk of "blended roles" where developers are expected to absorb Scrum Master responsibilities, and questions about how AI might replace the human facilitation work that coaches provide. But Natalia believes the answer lies in understanding something fundamental: the Scrum Master is a deeply situational and contextual role that adapts to what the team needs each day.  Some teams need help with communication spaces, others need work structure like Kanban boards, still others need translation between technical realities and stakeholder expectations. The challenge is that this situational nature makes it incredibly hard to explain to business leaders who think in fixed job descriptions and measurable outputs. Natalia's approach involves bringing metrics—not velocity, which focuses on the wrong things, but metrics around team independence, continuous improvement, and organizational capability. She suggests concepts like Gemba walks—going to see what's actually happening rather than relying only on numbers. The real question Natalia poses is this: the biggest value we can bring to an organization is to leave it better than we found it, but how do we make that visible and tangible to business stakeholders who need justification for our roles?   Self-reflection Question: If you had to demonstrate your value as a Scrum Master using only observable evidence from the past month, what would you show your leadership?   [The Scrum Master Toolbox Podcast Recommends]

Natalia Curusi: The Dark Side of High-Performing Dream Teams 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 was proud of this team—I helped form them from the start, we traveled to the client together, they were mature and independent, they even jelled outside the workplace. This was my dream team." - Natalia Curusi   Natalia had built something special. The team was technically strong, emotionally connected, and highly productive. They socialized outside work, traveled together to client sites, and operated with remarkable independence. But when a new junior developer joined, everything started to unravel.  The existing team members were like heroes—fast, skilled, confident. The newcomer couldn't keep pace, and slowly Natalia noticed something disturbing: the team started making fun of the new member during retrospectives and stand-ups. The person became an outlier, a black swan ignored by the group. Natalia conducted one-on-one meetings with both the new member and the team, but the situation only worsened. The new person insisted they were fine and didn't need help. The team members claimed they were just joking around. Meanwhile, the team structure and morale deteriorated.  Natalia realized she was watching her dream team self-destruct through a form of bullying—something she hadn't even recognized at the time. Finally, she understood she couldn't handle this alone and escalated to the head of discipline and the organizational psychologist. Together, they decided to rotate the person to another team where they felt more comfortable. Natalia learned a painful lesson: as Scrum Masters, we don't need to solve everything ourselves, and sometimes the best solution is recognizing when to use the support structure around us rather than treating it as a personal failure.   In this episode, we refer to Coaching Agile Teams by Lyssa Adkins and Training from the Back of the Room by Sharon Bowman.   Self-reflection Question: When have you witnessed subtle forms of exclusion in your team, and did you recognize them early enough to intervene effectively? Featured Book of the Week: Coaching Agile Teams by Lyssa Adkins "This was the first book about agile coaching that I read, and it's how I understood that I was already playing the scrum master role without even knowing it—I understood that I was already acting like a glue for the team." - Natalia Curusi   Natalia discovered Coaching Agile Teams at a pivotal moment in her career. The book revealed something profound: if you're irreplaceable, there's a problem. A great Scrum Master or coach makes themselves obsolete by growing team members who can replace them. The team should be able to perform independently when you're on vacation or move to another assignment. Lyssa Adkins showed Natalia that she needed to let go of over-control and over-responsibility, focusing instead on growing the team's capabilities. The book remains one of Natalia's top recommendations for every junior Scrum Master wanting to embrace the role, alongside Training from the Back of the Room, which teaches facilitators how to run interactive workshops where people learn from each other rather than just listening to slides.   [The Scrum Master Toolbox Podcast Recommends]

Natalia Curusi: When Your Technical Expertise Becomes Your Biggest Scrum Master Weakness 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 thought my technical background was my biggest strength, but I understood that this was my biggest weakness—I was coming into stand-ups saying 'I know how we need to fix that issue,' and I was a Scrum Master." - Natalia Curusi   Natalia stepped into her first blended role as team leader and Scrum Master full of confidence. With years of programming experience behind her, she believed she could guide her team through any technical challenge. But during morning stand-ups, she found herself suggesting solutions, directing technical approaches, and sharing her expertise freely. The team listened—after all, she was their former leader. They implemented her suggestions, but when those solutions failed, the team didn't have the thinking process to adapt them to their context.  Natalia realized she was preventing the team's learning and ownership by taking control away from them. The turning point came when she made a deliberate choice: she selected the most technical person on the team to become the technical authority and committed to never stepping on his feet again. From that moment forward, she focused purely on the Scrum Master role—asking questions, fostering collaboration, and shutting up to listen actively.  Years later, that technical lead followed her to another job, and they remain friends to this day. Natalia learned that her contribution wasn't about giving solutions—it was about keeping the team from losing ownership of their work.   Self-reflection Question: When you attend your team's daily stand-up, are you contributing to collaboration, or is your contribution keeping the team from owning their work?   [The Scrum Master Toolbox Podcast Recommends]