Podcasts about Agile

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/

In the final episode of the Podcast-to-Book series, host Susan Diaz sits down with change leader and AI education lead Melissa Penton (Sun Life) for a human-first conversation about what actually makes AI adoption work. They talk productivity vs room-for-life, why one-prompt culture is snake oil, the shift from prompt engineering to context engineering, and the simplest enterprise question that changes everything: "What would make Monday easier for employees?" Episode summary Susan closes out the Podcast-to-Book sprint with a conversation that feels like the point of the whole series: AI isn't a tool problem. It's a people problem disguised as a tool problem. Melissa Penton shares her lens as a long-time change manager working in AI readiness and education inside a large organisation. Her focus isn't faster work. It's making room for what matters - and designing adoption in a way that's safe, honest, and grounded in real human tension points. Together, Susan and Melissa unpack why generic prompting courses aren't enough, why people get hives when they hear words like "workflow" and "agentic," and how leaders can create real change by starting with everyday pain. They also go deep on psychological safety, the fear of "training your robot replacement," and what it looks like to lead with humility in the biggest transformation most of us will live through.   Key takeaways Productivity is the doorway. Room-for-life is the goal. Saving time is nice. The real win is using that time to live in your "zone of genius" and have space for the things you care about. One-prompt culture is snake oil. Useful AI work is iterative, messy, and conversational. The magic isn't the prompt. It's the human steering, correcting, and refining. Prompt engineering is evolving into context engineering. The skill isn't "write a clever prompt." It's learning to give the right context, ask better questions, and build on responses. Enterprise adoption should start with one simple question: "What would make Monday easier for my employees?" That question forces leaders to solve real friction instead of buying shiny tools. The biggest people problem masquerading as an AI problem is readiness. AI is being thrown at people who don't know where to start, how it fits their real lives, or how it changes their work without threatening them. Training should be experiential, not theoretical. Courses can help. But capability sticks when people learn by doing, inside real workflows, with real tasks, and real feedback loops. Psychological safety is non-negotiable. People won't share pain points if they fear automation will erase their job. Leaders shouldn't make promises they can't keep. They should make learning safe and transferable. Workflows don't have to be scary. A workflow is just the steps you already take. "Ask a question → make notes → read notes → act." That's a workflow. Low-risk experiments lead to higher-risk breakthroughs. The "AI coffee warmer" might feel silly. But it's part of the lab. Small experiments teach the muscles needed for bigger transformations. Leadership in the AI era requires humility. Admit you're learning. Model curiosity. Use AI to explore recurring organisational stuck points, mediate perspectives, and surface patterns in conversations.   Timestamps  00:03 — Susan sets the scene: the final stretch of the 30-day podcast-to-book sprint 01:12 — Meet Melissa: change management, training, and leading AI education/readiness 02:31 — Productivity vs "making room for what matters" (crochet, hikes, real life) 03:29 — Time saved is table stakes… what are we doing with the time? 03:58 — Zone of Genius living and why AI should move you toward it 06:44 — Snake-oil prompts, "one prompt fixes your life," and why it makes Susan grumpy 08:02 — "I am the prompt": AI as an iterative, human conversation 09:21 — Prompting → context engineering (asking better questions is the skill) 09:50 — The enterprise question: "What will make Monday easier for employees?" 11:02 — Voice mode and why it changes tone, cadence, and output quality 14:27 — The biggest "AI problem" is actually a people/readiness problem 16:20 — Start with real tension points, not an abstract AI adoption plan 18:23 — Why "prompting courses" can repel people (language matters) 20:39 — Courses aren't bad… they're just not sufficient 21:49 — Cleaning workflows as the gateway drug to agentic thinking 22:44 — Agentic AI explained simply: consecutive steps without you in the middle 23:20 — "Workflow" definition for normal humans (no hives required) 24:12 — First 3 moves in 30 days: Monday, conversations, embedded learning 26:00 — Psychological safety: fear of replacement and why honesty matters 31:03 — Skill recognition: you're learning transferable capability, not training your replacement 33:35 — Whole-human value: you are not your job title 34:22 — The spiritual lens: AI should expand what humans can become 35:34 — Why "small silly tools" still matter (science lab thinking) 37:29 — Low-risk testing as the path to bigger breakthroughs 38:00 — Leadership advice: be humble, be curious, use AI to explore stuck patterns 40:58 — Where to find Melissa: LinkedIn + Substack 41:30 — "Purple person": bridging tech and business communication   Connect with Melissa Penton on LinkedIn Substack: Confessions of an AI User   If you're leading AI adoption, steal this question and use it today:  "What would make Monday easier for our people?" Then pick one friction point. Make it safer. Make it simpler. Let the learning compound. Connect with Susan Diaz on LinkedIn to get a conversation started. Agile teams move fast. Grab our 10 AI Deep Research Prompts to see how proven frameworks can unlock clarity in hours, not months. Find the prompt pack here.

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.

As leaders gain responsibility, honest feedback disappears. Bob and Josh explore why power dynamics silence your team, how to find truth tellers who will call you out, and why no criticism isn't good news—it's a warning sign. Learn to mine for feedback and fix your leadership blind spots. 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!

The world of delivery has changed—and program leaders must change with it.Join a new generation of leaders mastering Agile, PMBOK, and program leadership through a modern, AI-aware lens. This residency-style certification is designed for experienced professionals ready to step beyond projects and lead complex programs and portfolios with confidence, clarity, and judgment.

We love to say we're Agile… but then we bury our teams under complexity, overstuffed user stories, bloated processes, and “just in case” documentation.In this episode, Kate Megaw and Ryan Smith unpack one deceptively simple piece of Scrum wisdom inspired by a quote from Steven Merchant: You can always simplify.From product backlog items that read like novels, to daily scrums that feel like executive status meetings, to processes that exist only because “that's the rule” - this conversation dives into why teams overcomplicate, how fear sneaks into our work, and what Scrum looks like when we finally let go.If your teams feel busy but not effective, this one's for you.

From Enron to Agile.Burke Willis quit Enron at the right time, and that experience helped shape a career grounded in integrity and change. He is now helping reshape how internal audit projects are done.We talk about why perfect audit plans don't exist, how two-week cycles accelerate insight, why auditors should tell business stories (not just report numbers), and the power of defining “done” and getting there sooner.

The world of delivery has changed—and program leaders must change with it.Join a new generation of leaders mastering Agile, PMBOK, and program leadership through a modern, AI-aware lens. This residency-style certification is designed for experienced professionals ready to step beyond projects and lead complex programs and portfolios with confidence, clarity, and judgment.

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]

What happens when curiosity, resilience, and storytelling collide over a lifetime of building something meaningful? In this episode, I welcome Nick Francis, founder and CEO of Casual Films, for a thoughtful conversation about leadership, presence, and what it takes to keep going when the work gets heavy. Nick's journey began with a stint at BBC News and a bold 9,000-mile rally from London to Mongolia in a Mini Cooper, a spirit of adventure that still fuels how he approaches business and life today. We talk about how that early experience shaped Casual into a global branded storytelling company with studios across five continents, and what it really means to lead a creative organization at scale. Nick shares insights from growing the company internationally, expanding into Southeast Asia, and staying grounded while producing hundreds of projects each year. Along the way, we explore why emotionally resonant storytelling matters, how trust and preparation beat panic, and why presence with family, health, and purpose keeps leaders steady in uncertain times. This conversation is about building an Unstoppable life by focusing on what matters most, using creativity to connect people, and choosing clarity and resilience in a world full of noise. Highlights: 00:01:30 – Learn how early challenges shape resilience and long-term drive. 00:06:20 – Discover why focusing on your role creates calm under pressure. 00:10:50 – Learn how to protect attention in a nonstop world. 00:18:25 – Understand what global growth teaches about leadership. 00:26:00 – Learn why leading with trust changes relationships. 00:45:55 – Discover how movement and presence restore clarity. About the Guest: Nick Francis is the founder and CEO of Casual, a global production group that blends human storytelling, business know-how, and creativity turbo-charged by AI. Named the UK's number one brand video production company for five years, Casual delivers nearly 1,000 projects annually for world-class brands like Adobe, Amazon, BMW, Hilton, HSBC, and P&G. The adventurous spirit behind its first production – a 9,000-mile journey from London to Mongolia in an old Mini – continues to drive Casual's growth across offices in London, New York, LA, San Francisco, Amsterdam, Barcelona, Sydney, Singapore, Hong Kong and Greater China. Nick previously worked for BBC News and is widely recognised for his expertise in video storytelling, brand building, and corporate communications. He is the founding director of the Casual Films Academy, a charity helping young filmmakers develop skills by producing films for charitable organisations. He is also the author of ‘The New Fire: Harness the Power of Video for Your Business' and a passionate advocate for emotionally resonant, behaviorally grounded storytelling. Nick lives in San Francisco, California, with his family. Ways to connect with Nick**:** Website: https://www.casualfilms.com/ YouTube: https://www.youtube.com/@casual_global  Instagram: https://www.instagram.com/casualglobal/  Facebook: https://www.facebook.com/CasualFilms/  Nick's LinkedIn: https://www.linkedin.com/in/nickfrancisfilm/  Casual's LinkedIn: https://www.linkedin.com/company/casual-films-international/  Beyond Casual - LinkedIn Newsletter: https://www.linkedin.com/build-relation/newsletter-follow?entityUrn=6924458968031395840 About the Host: Michael Hingson is a New York Times best-selling author, international lecturer, and Chief Vision Officer for accessiBe. Michael, blind since birth, survived the 9/11 attacks with the help of his guide dog Roselle. This story is the subject of his best-selling book, Thunder Dog. Michael gives over 100 presentations around the world each year speaking to influential groups such as Exxon Mobile, AT&T, Federal Express, Scripps College, Rutgers University, Children's Hospital, and the American Red Cross just to name a few. He is Ambassador for the National Braille Literacy Campaign for the National Federation of the Blind and also serves as Ambassador for the American Humane Association's 2012 Hero Dog Awards. https://michaelhingson.com https://www.facebook.com/michael.hingson.author.speaker/ https://twitter.com/mhingson https://www.youtube.com/user/mhingson https://www.linkedin.com/in/michaelhingson/ accessiBe Links https://accessibe.com/ https://www.youtube.com/c/accessiBe https://www.linkedin.com/company/accessibe/mycompany/ https://www.facebook.com/accessibe/ Thanks for listening! Thanks so much for listening to our podcast! If you enjoyed this episode and think that others could benefit from listening, please share it using the social media buttons on this page. Do you have some feedback or questions about this episode? Leave a comment in the section below! Subscribe to the podcast If you would like to get automatic updates of new podcast episodes, you can subscribe to the podcast on Apple Podcasts or Stitcher. You can subscribe in your favorite podcast app. You can also support our podcast through our tip jar https://tips.pinecast.com/jar/unstoppable-mindset . Leave us an Apple Podcasts review Ratings and reviews from our listeners are extremely valuable to us and greatly appreciated. They help our podcast rank higher on Apple Podcasts, which exposes our show to more awesome listeners like you. If you have a minute, please leave an honest review on Apple Podcasts. Transcription Notes: Michael Hingson  00:00 Access Cast and accessiBe Initiative presents Unstoppable Mindset. The podcast where inclusion, diversity and the unexpected meet. Hi, I'm Michael Hingson, Chief Vision Officer for accessiBe and the author of the number one New York Times bestselling book, Thunder dog, the story of a blind man, his guide dog and the triumph of trust. Thanks for joining me on my podcast as we explore our own blinding fears of inclusion unacceptance and our resistance to change. We will discover the idea that no matter the situation, or the people we encounter, our own fears, and prejudices often are our strongest barriers to moving forward. The unstoppable mindset podcast is sponsored by accessiBe, that's a c c e s s i capital B e. Visit www.accessibe.com to learn how you can make your website accessible for persons with disabilities. And to help make the internet fully inclusive by the year 2025. Glad you dropped by we're happy to meet you and to have you here with us. Michael Hingson  01:21 Well, hello everyone. I am your host, Mike hingson, that's kind of funny. We'll talk about that in a second, but this is unstoppable mindset. And our guest today is Nick Francis, and what we're going to talk about is the fact that people used to always ask me, well, they would call me Mr. Kingston, and it took me, as I just told Nick a master's degree in physics in 10 years to realize that if I said Mike hingson, that's why they said Mr. Kingston. So was either say Mike hingson or Michael hingson. Well, Michael hingson is a lot easier to say than Mike hingson, but I don't really care Mike or Michael, as long as it's not late for dinner. Whatever works. Yeah. Well, Nick, welcome to unstoppable mindset. We're glad you're Nick Francis  02:04 here. Thanks, Mike. It's great to be here. Michael Hingson  02:08 So Nick is a marketing kind of guy. He's got a company called casual that we'll hear about. Originally from England, I believe, and now lives in San Francisco. We were talking about the weather in San Francisco, as opposed to down here in Victorville. A little bit earlier. We're going to have a heat wave today and and he doesn't have that up there, but you know, well, things, things change over time. But anyway, we're glad you're here. And thanks, Mike. Really looking forward to it. Tell us about the early Nick growing up and all that sort of stuff, just to get us started. Nick Francis  02:43 That's a good question. I grew up in London, in in Richmond, which is southwest London. It's a at the time, it wasn't anything like as kind of, it's become quite kind of shishi, I think back in the day, because it's on the west of London. The pollution from the city used to flow east and so, like all the kind of well to do people, in fact, there used to be a, there used to be a palace in Richmond. It's where Queen Elizabeth died, the first Queen Elizabeth, that is. And, yeah, you know, I grew up it was, you know, there's a lot of rugby played around there. I played rugby for my local rugby club from a very young age, and we went sailing on the south coast. It was, it was great, really. And then, you know, unfortunately, when I was 10 years old, my my dad died. He had had a very powerful job at the BBC, and then he ran the British Council, which is the overseas wing of the Arts Council, so promoting, I guess, British soft power around the world, going and opening art galleries and going to ballet in Moscow and all sorts. So he had an incredible life and worked incredibly hard. And you know, that has brought me all sorts of privileges, I think, when I was a kid. But, you know, unfortunately, age 10 that all ended. And you know, losing a parent at that age is such a sort of fundamental, kind of shaking of your foundations. You know, you when you're a kid, you feel like a, you're going to live forever, and B, the things that are happening around you are going to last forever. And so, you know, you know, my mom was amazing, of course, and, you know, and in time, I got a new stepdad, and all the rest of it. But you know, that kind of shaped a lot of my a lot of my youth, really. And, yeah, I mean, Grief is a funny thing, and it's funny the way it manifests itself as you grow. But yeah. So I grew up there. I went to school in the Midlands, near where my stepdad lived, and then University of Newcastle, which is up in the north of England, where it rains a lot. It's where it's where Newcastle Football Club is based. And you know is that is absolutely at the center of the city. So. So the city really comes alive there. And it was during that time that I discovered photography, and I wanted to be a war photographer, because I believe that was where life was lived at the kind of the real cutting edge. You know, you see the you see humanity in its in its most visceral and vivid color in terrible situations. And I kind of that seemed like an interesting thing to go to go and do. Michael Hingson  05:27 Well, what? So what did you major in in college in Newcastle? So I did Nick Francis  05:31 history and politics, and then I went did a course in television journalism, and ended up working at BBC News as a initially running on the floor. So I used to deliver the papers that you know, when you see people shuffling or not, they do it anymore, actually, because everything, everything's digital now digital, yeah, but when they were worried about the the auto cues going down, they we always had to make sure that they had the up to date script. And so I would be printing in, obviously, the, you know, because it's a three hour news show, the scripts constantly evolving, and so, you know, I was making sure they had the most up to date version in their hands. And it's, I don't know if you have spent any time around live TV Mike, but it's an incredibly humbling experience, like the power of it. You know, there's sort of two or 3 million people watching these two people who are sitting five feet in front of me, and the, you know, the sort of slightly kind of, there was an element of me that just wanted to jump in front of them and kind of go, ah. And, you know, never, ever work in live TV, ever again. But you know, anyway, I did that and ended up working as a producer, writing and developing, developing packets that would go out on the show, producing interviews and things. And, you know, I absolutely loved it. It was, it was a great time. But then I left to go and set up my company. Michael Hingson  06:56 I am amazed, even today, with with watching people on the news, and I've and I've been in a number of studios during live broadcasts and so on. But I'm amazed at how well, mostly, at least, I've been fortunate. Mostly, the people are able to read because they do have to read everything. It isn't like you're doing a lot of bad living in a studio. Obviously, if you are out with a story, out in the field, if you will, there, there may be more where you don't have a printed script to go by, but I'm amazed at the people in the studio, how much they are able to do by by reading it all completely. Nick Francis  07:37 It's, I mean, the whole experience is kind of, it's awe inspiring, really. And you know, when you first go into a Live, a live broadcast studio, and you see the complexity, and you know, they've got feeds coming in from all over the world, and you know, there's upwards of 100 people all working together to make it happen. And I remember talking to one of the directors at the time, and I was like, How on earth does this work? And he said, You know, it's simple. You everyone has a very specific job, and you know that as long as you do your bit of the job when it comes in front of you, then the show will go out. He said, where it falls over is when people start worrying about whether other people are going to are going to deliver on time or, you know, and so if you start worrying about what other people are doing, rather than just focusing on the thing you have to do, that's where it potentially falls over, Michael Hingson  08:29 which is a great object lesson anyway, to worry about and control and don't worry about the rest Nick Francis  08:36 for sure. Yeah, yeah, for sure. You know, it's almost a lesson for life. I mean, sorry, it is a lesson for life, and Michael Hingson  08:43 it's something that I talk a lot about in dealing with the World Trade Center and so on, and because it was a message I received, but I've been really preaching that for a long time. Don't worry about what you can't control, because all you're going to do is create fear and drive yourself Nick Francis  08:58 crazy, completely, completely. You know. You know what is it? Give me the, give me this. Give me the strength to change the things I can. Give me the give me the ability to let the things that I can't change slide but and the wisdom to know the difference. I'm absolutely mangling that, that saying, but, yeah, it's, it's true, you know. And I think, you know, it's so easy for us to in this kind of modern world where everything's so media, and we're constantly served up things that, you know, shock us, sadness, enrage us, you know, just to be able to step back and say, actually, you know what? These are things I can't really change. I'd have to just let them wash over me. Yeah, and just focus on the things that you really can change. Michael Hingson  09:46 It's okay to be aware of things, but you've got to separate the things you can control from the things that you can and we, unfortunately aren't taught that. Our parents don't teach us that because they were never taught it, and it's something. That, just as you say, slides by, and it's so unfortunate, because it helps to create such a level of fear about so many things in our in our psyche and in our world that we really shouldn't have to do Nick Francis  10:13 completely well. I think, you know, obviously, but you know, we've, we've spent hundreds, if not millions of years evolving to become humans, and then, you know, actually being aware of things beyond our own village has only been an evolution of the last, you know what, five, 600 years, yeah. And so we are just absolutely, fundamentally not able to cope with a world of such incredible stimulus that we live in now. Michael Hingson  10:43 Yeah, and it's only getting worse with all the social media, with all the different things that are happening and of course, and we're only working to develop more and more things to inundate us with more and more kinds of inputs. It's really unfortunate we just don't learn to separate ourselves very easily from all of that. Nick Francis  11:04 Yeah, well, you know, it's so interesting when you look at the development of VR headsets, and, you know, are we going to have, like, lenses in our eyes that kind of enable us to see computer screens while we're just walking down the road, you know? And you look at that and you think, well, actually, just a cell phone. I mean, cell phones are going to be gone fairly soon. I would imagine, you know, as a format, it's not something that's going to abide but the idea that we're going to create technology that's going to be more, that's going to take us away from being in the moment more rather than less, is kind of terrifying. Because, I would say already, even with, you know, the most basic technology that we have now, which is, you know, mind bending, compared to where we were even 20 years ago, you know, to think that we're only going to become more immersive is, you know, we really, really as a species, have to work out how we are going to be far better at stepping away from this stuff. And I, you know, I do, I wonder, with AI and technology whether there is, you know, there's a real backlash coming of people who do want to just unplug, yeah, Michael Hingson  12:13 well, it'll be interesting to see, and I hope that people will learn to do it. I know when I started hearing about AI, and one of the first things I heard was how kids would use it to write their papers, and it was a horrible thing, and they were trying to figure out ways so that teachers could tell us something was written by AI, as opposed to a student. And I almost immediately developed this opinion, no, let AI write the papers for students, but when the students turn in their paper, then take a day to in your class where you have every student come up and defend their paper, see who really knows it, you know. And what a great teaching opportunity and teaching moment to to get students also to learn to do public speaking and other things a little bit more than they do, but we haven't. That hasn't caught on, but I continue to preach it. Nick Francis  13:08 I think that's really smart, you know, as like aI exists, and I think to to pretend somehow that, you know, we can work without it is, you know, it's, it's, it's, yeah, I mean, it's like, well, saying, you know, we're just going to go back to Word processors or typewriters, which, you know, in which it weirdly, in their own time, people looked at and said, this is, you know, these, these are going to completely rot our minds. In fact, yeah, I think Plato said that was very against writing, because he believed it would mean no one could remember anything after that, you know. So it's, you know, it's just, it's an endless, endless evolution. But I think, you know, we have to work out how we incorporate into it, into our education system, for sure. Michael Hingson  13:57 Well, I remember being in in college and studying physics and so on. And one of the things that we were constantly told is, on tests, you can't bring calculators in, can't use calculators in class. Well, why not? Well, because you could cheat with that. Well, the reality is that the smart physicists realized that it's all about really learning the concepts more than the numbers. And yeah, that's great to to know how to do the math. But the the real issue is, do you know the physics, not just the math completely? Nick Francis  14:34 Yeah. And then how you know? How are the challenges that are being set such that you know, they really test your ability to use the calculator effectively, right? So how you know? How are you lifting the bar? And in a way, I think that's kind of what we have to do, what we have to do now, Michael Hingson  14:50 agreed, agreed. So you were in the news business and so on, and then, as you said, you left to start your own company. Why did you decide to do that? Nick Francis  14:59 Well, a friend of. Ryan and I from University had always talked about doing this rally from London to Mongolia. So, and you do it in an old car that you sort of look at, and you go, well, that's a bit rubbish. It has to have under a one liter engine. So it's tiny, it's cheap. The idea is it breaks down you have an adventure. And it was something we kind of talked about in passing and decided that would be a good thing to do. And then over time, you know, we started sending off. We you know, we applied, and then we started sending off for visas and things. And then before we knew it, we were like, gosh, so it looks like we're actually going to do this thing. But by then, you know, my job at the BBC was really taking off. And so I said, you know, let's do this, but let's make a documentary of it. So long story short, we ended up making a series of diary films for Expedia, which we uploaded onto their website. It was, you know, we were kind of pitching this around about 2005 we kind of did it in 2006 so it was kind of, you know, nobody had really heard of YouTube. The idea of making videos to go online was kind of unheard of because, you know, broadband was just kind of getting sorry. It wasn't unheard of, but it was, it was very, it was a very nascent industry. And so, yeah, we went and drove 9000 miles over five weeks. We spent a week sitting in various different repair yards and kind of break his yards in everywhere from Turkey to Siberia. And when we came back, it became clear that the internet was opening up as this incredible medium for video, and video is such a powerful way to share emotion with a dispersed audience. You know, not that I would have necessarily talked about it in that in those terms back then, but it really seemed like, you know, every every web page, every piece of corporate content, could have a video aspect to it. And so we came back and had a few fits and starts and did some, I mean, we, you know, we made a series of hotel videos where we were paid 50 quid a day to go and film hotels. And it was hot and it was hard work. And anyway, it was rough. But over time, you know, we started to win some more lucrative work. And, you know, really, the company grew from there. We won some awards, which helped us to kind of make a bit of a name for ourselves. And this was, there's been a real explosion in technology, kind of shortly after when we did this. So digital SLRs, so, you know, old kind of SLR cameras, you know, turned into digital cameras, which could then start to shoot video. And so it, there was a real explosion in high quality video produced by very small teams of people using the latest technology creatively. And that just felt like a good kind of kick off point for our business. But we just kind of because we got in in kind of 2006 we just sort of beat a wave that kind of started with digital SLRs, and then was kind of absolutely exploded when video cell phones came on the market, video smartphones. And yeah, you know, because we had these awards and we had some kind of fairly blue chip clients from a relatively early, early stage, we were able to grow the company. We then expanded to the US in kind of 2011 20 between 2011 2014 and then we were working with a lot of the big tech companies in California, so it felt like we should maybe kind of really invest in that. And so I moved out here with some of our team in 2018 at the beginning of 2018 and I've been here ever since, wow. Michael Hingson  18:44 So what is it? What was it like starting a business here, or bringing the business here, as opposed to what it was in England? Nick Francis  18:53 It's really interesting, because the creatively the UK is so strong, you know, like so many, you know, from the Beatles to Led Zeppelin to the Rolling Stones to, you know, and then on through, like all the kind of, you know, film and TV, you know, Brits are very good at kind of Creating, like, high level creative, but not necessarily always the best at kind of monetizing it, you know. I mean, some of those obviously have been fantastic successes, right? And so I think in the UK, we we take a lot longer over getting, getting to, like, the perfect creative output, whereas the US is far more focused on, you know, okay, we need this to to perform a task, and frankly, if we get it 80% done, then we're good, right? And so I think a lot of creative businesses in the UK look at the US and they go, gosh. Firstly, the streets are paved with gold. Like the commercial opportunity seems incredible, but actually creating. Tracking it is incredibly difficult, and I think it's because we sort of see the outputs in the wrong way. I think they're just the energy and the dynamism of the US economy is just, it's kind of awe inspiring. But you know, so many businesses try to expand here and kind of fall over themselves. And I think the number one thing is just, you have to have a founder who's willing to move to the US. Because I think Churchill said that we're two two countries divided by the same language. And I never fully understood what that meant until I moved here. I think what it what he really means by that is that we're so culturally different in the US versus the UK. And I think lots of Brits look at America and think, Well, you know, it's just the same. It's just a bit kind of bigger and a bit Brasher, you know, and it and actually, I think if people in the US spoke a completely different language, we would approach it as a different culture, which would then help us to understand it better. Yeah. So, yeah. I mean, it's been, it's been the most fabulous adventure to move here and to, you know, it's, it's hard sometimes, and California is a long way from home, but the energy and the optimism and the entrepreneurialism of it, coupled with just the natural beauty is just staggering. So we've made some of our closest friends in California, it's been absolutely fantastic. And across the US, it's been a fantastic adventure for us and our family. Michael Hingson  21:30 Yeah, I've had the opportunity to travel all over the US, and I hear negative comments about one place or another, like West Virginia, people eat nothing but fried food and all that. But the reality is, if you really take an overall look at it, the country has so much to offer, and I have yet to find a place that I didn't enjoy going to, and people I never enjoyed meeting, I really enjoy all of that, and it's great to meet people, and it's great to experience so much of this country. And I've taken that same posture to other places. I finally got to visit England last October, for the first time. You mentioned rugby earlier, the first time I was exposed to rugby was when I traveled to New Zealand in 2003 and found it pretty fascinating. And then also, I was listening to some rugby, rugby, rugby broadcast, and I tuned across the radio and suddenly found a cricket game that was a little bit slow for me. Yeah, cricket to be it's slow. Nick Francis  22:41 Yeah, fair enough. It's funny. Actually, we know what you're saying about travel. Like one of the amazing things about our Well, I kind of learned two sort of quite fundamentally philosophical things, I think, you know, or things about the about humans and the human condition. Firstly, like, you know, traveling across, you know, we left from London. We, like, drove down. We went through Belgium and France and Poland and Slovenia, Slovakia, Slovenia, like, all the way down Bulgaria, across Turkey into Georgia and Azerbaijan and across the Caspian Sea, and through Turkmenistan, Uzbekistan, Kyrgyzstan, Kazakhstan, into Russia, and then down into Mongolia. When we finished, we were due north of Jakarta, right? So we drove, we drove a third of the way around the world. And the two things that taught me were, firstly that human people are good. You know, everywhere we went, people would invite us in to have meals, or they'd like fix our car for not unit for free. I mean, people were so kind everywhere we went. Yeah. And the other thing was, just, when we get on a plane and you fly from here to or you fly from London, say to we, frankly, you fly from London to Turkey, it feels unbelievably different. You know, you fly from London to China, and it's, you know, complete different culture. But what our journey towards us, because we drove, was that, you know, while we might not like to admit it, we're actually quite, you know, Brits are quite similar to the French, and the French actually are quite similar to the Belgians, and Belgians quite similar to the Germans. And, you know, and all the way through, actually, like we just saw a sort of slowly changing gradient of all the different cultures. And it really, you know, we are just one people, you know. So as much as we might feel that, you know, we're all we're all different, actually, when you see it, when you when you do a drive like that, you really, you really get to see how slowly the cultures shift and change. Another thing that's quite funny, actually, was just like, everywhere we went, we would be like, you know, we're driving to Turkey. They'd be like, Oh, God, you just drove through Bulgaria, you know, how is like, everything on your car not been stolen, you know, they're so dodgy that you Bulgarians are so dodgy. And then, you know, we'd get drive through the country, and they'd be like, you know, oh, you're going into Georgia, you know, gosh, what you go. Make, make sure everything's tied down on your car. They're so dodgy. And then you get into Georgia, and they're like, Oh my God, you've just very driven through Turkey this, like, everyone sort of had these, like, weird, yeah, kind of perceptions of their neighbors. And it was all nonsense, yeah, you know. Michael Hingson  25:15 And the reality is that, as you pointed out, people are good, you know, I think, I think politicians are the ones who so often mess it up for everyone, just because they've got agendas. And unfortunately, they teach everyone else to be suspicious of of each other, because, oh, this person clearly has a hidden agenda when it normally isn't necessarily true at all. Nick Francis  25:42 No, no, no, certainly not in my experience, anyway, not in my experience. But, you know, well, oh, go ahead. No, no. It's just, you know, it's, it is. It's, it is weird the way that happens, you know, well, they say, you know, if, if politicians fought wars rather than, rather than our young men and women, then there'd be a lot less of them. Yeah, so Well, Michael Hingson  26:06 there would be, well as I tell people, you know, I I've learned a lot from working with eight guy dogs and my wife's service dog, who we had for, oh, gosh, 14 years almost, and one of the things that I tell people is I absolutely do believe what people say, that dogs love unconditionally, unless they're just totally traumatized by something, but they don't trust unconditionally. The difference between dogs and people is that dogs are more open to trust because we've taught ourselves and have been taught by others, that everyone has their own hidden agenda. So we don't trust. We're not open to trust, which is so unfortunate because it affects the psyche of so many people in such a negative way. We get too suspicious of people, so it's a lot harder to earn trust. Nick Francis  27:02 Yeah, I mean, I've, I don't know, you know, like I've been, I've been very fortunate in my life, and I kind of always try to be, you know, open and trusting. And frankly, you know, I think if you're open and trusting with people, in my experience, you kind of, it comes back to you, you know, and maybe kind of looking for the best in everyone. You know, there are times where that's not ideal, but you know, I think you know, in the overwhelming majority of cases, you know, actually, you know, you treat people right? And you know what goes what goes around, comes around, absolutely. Michael Hingson  27:35 And I think that's so very true. There are some people who just are going to be different than that, but I think for the most part, if you show that you're open to trust people will want to trust you, as long as you're also willing to trust Nick Francis  27:51 them completely. Yeah, completely. Michael Hingson  27:54 So I think that that's the big thing we have to deal with. And I don't know, I hope that we, we will learn it. But I think that politicians are really the most guilty about teaching us. Why not to trust but that too, hopefully, will be something we deal with. Nick Francis  28:12 I think, you know, I think we have to, you know, it's, it's one of the tragedies of our age, I think, is that the, you know, we spent the 20th century, thinking that sex was the kind of ultimate sales tool. And then it took algorithms to for us to realize that actually anger and resentment are the most powerful sales tools, which is, you know, it's a it's something which, in time, we will work out, right? And I think the problem is that, at the minute, these tech businesses are in such insane ascendancy, and they're so wealthy that it's very hard to regulate them. And I think in time, what will happen is, you know, they'll start to lose some of that luster and some of that insane scale and that power, and then, you know, then regulation will come in. But you know whether or not, we'll see maybe, hopefully our civilization will still be around to see that. Michael Hingson  29:04 No, there is that, or maybe the Vulcans will show up and show us a better way. But you know, Nick Francis  29:11 oh, you know, I'm, I'm kind of endlessly optimistic. I think, you know, we are. We're building towards a very positive future. I think so. Yeah, it's just, you know, get always bumps along the way, yeah. Michael Hingson  29:24 So you named your company casual. Why did you do that? Or how did that come about? Nick Francis  29:30 It's a slightly weird name for something, you know, we work with, kind of, you know, global blue chip businesses. And, you know, casual is kind of the last thing that you would want to associate with, a, with a, with any kind of services business that works in that sphere. I think, you know, we, the completely honest answer is that the journalism course I did was television, current affairs journalism, so it's called TV cadge, and so we, when we made a film for a local charity as part of that course. Course, we were asked to name our company, and we just said, well, cash, cash casual, casual films. So we called it casual films. And then when my friend and I set the company up, kind of formally, to do the Mongol Rally, we, you know, we had this name, you know, the company, the film that we'd made for the charity, had gone down really well. It had been played at BAFTA in London. And so we thought, well, you know, we should just, you know, hang on to that name. And it didn't, you know, at the time, it didn't really seem too much of an issue. It was only funny. It was coming to the US, where I think people are a bit more literal, and they were a bit like, well, casual. Like, why casual, you know. And I remember being on a shoot once. And, you know, obviously, kind of some filmmakers can be a little casual themselves, not necessarily in the work, but in the way they present themselves, right? And I remember sitting down, we were interviewing this CEO, and he said, who, you know, who are you? Oh, we're casual films. He's like, Oh, is that why that guy's got ripped jeans? Is it? And I just thought, Damn, you know, we really left ourselves open to that. There was also, there was a time one of our early competitors was called Agile films. And so, you know, I remember talking to one of our clients who said, you know, it's casual, you know, when I have to put together a little document to say, you know, which, which supplier we should choose, and when I lay it on my boss's desk, and one says casual films, and one says agile films, it's like those guys are landing the first punch. But anyway, we, you know, we, what we say now is like, you know, we take a complex process and make it casual. You know, filmmaking, particularly for like, large, complex organizations where you've got lots of different stakeholders, can be very complicated. And so, yeah, we sort of say, you know, we'll take a lot of that stress off, off our clients. So that's kind of the rationale, you know, that we've arrived with, arrived at having spoken to lots of our clients about the role that we play for them. So, you know, there's a kind of positive spin on it, I guess, but I don't know. I don't know whether I'd necessarily call it casual again. I don't know if I'm supposed to say that or not, but, oh, Michael Hingson  32:00 it's unique, you know? So, yeah, I think there's a lot of merit to it. It's a unique name, and it interests people. I know, for me, one of the things that I do is I have a way of doing this. I put all of my business cards in Braille, so the printed business cards have Braille on them, right? Same thing. It's unique completely. Nick Francis  32:22 And you listen, you know what look your name is an empty box that you fill with your identity. They say, right? And casual is actually, it's something we've grown into. And you know it's we've been going for nearly 20 years. In fact, funny enough for the end of this year is the 20th anniversary of that first film we made for the for the charity. And then next summer will be our 20th anniversary, which is, you know, it's, it's both been incredibly short and incredibly long, you know, I think, like any kind of experience in life, and it's been some of the hardest kind of times of my entire life, and some of the best as well. So, you know, it's, it is what it is, but you know, casual is who we are, right? I would never check, you know? I'd never change it. Michael Hingson  33:09 Now, no, of course not, yeah. So is the actual name casual films, or just casual? Nick Francis  33:13 So it was casual films, but then everyone calls us casual anyway, and I think, like as an organization, we probably need to be a bit more agnostic about the outcome. Michael Hingson  33:22 Well, the reason I asked, in part was, is there really any filming going on anymore? Nick Francis  33:28 Well, that's a very that's a very good question. But have we actually ever made a celluloid film? And I think the answer is probably no. We used to, back in the day, we used to make, like, super eight films, which were films, I think, you know, video, you know, ultimately, if you're going to be really pedantic about it, it's like, well, video is a digital, digital delivery. And so basically, every film we make is, is a video. But there is a certain cachet to the you know, because our films are loved and crafted, you know, for good or ill, you know, I think to call them, you know, they are films because, because of the, you know, the care that's put into them. But it's not, it's, it's not celluloid. No, that's okay, yeah, well, Michael Hingson  34:16 and I know that, like with vinyl records, there is a lot of work being done to preserve and capture what's on cellular film. And so there's a lot of work that I'm sure that's being done to digitize a lot of the old films. And when you do that, then you can also go back and remaster and hopefully in a positive way, and I'm not sure if that always happens, but in a positive way, enhance them Nick Francis  34:44 completely, completely and, you know, it's, you know, it's interesting talking about, like, you know, people wanting to step back. You know, obviously vinyl is having an absolute as having a moment right now. In fact, I just, I just bought a new stylist for my for my record. Play yesterday. It sounded incredible as a joy. This gave me the sound quality of this new style. It's fantastic. You know, beyond that, you know, running a company, you know, we're in nine offices all over the world. We produce nearly 1000 projects a year. So, you know, it's a company. It's an incredibly complicated company. It's a very fun and exciting company. I love the fact that we make these beautifully creative films. But, you know, it's a bit, I wouldn't say it's like, I don't know, you don't get many MBAs coming out of business school saying, hey, I want to set up a video production company. But, you know, it's been, it's been wonderful, but it's also been stressful. And so, you know, I've, I've always been interested in pottery and ceramics and making stuff with my hands. When I was a kid, I used to make jewelry, and I used to go and sell it in nightclubs, which is kind of weird, but, you know, it paid for my beers. And then whatever works, I say kid. I was 18. I was, I was of age, but of age in the UK anyway. But now, you know, over the last few 18 months or so, I've started make, doing my own ceramics. So, you know, I make vases and and pictures and kind of all sorts of stuff out of clay. And it's just, it's just to be to unplug and just to go and, you know, make things with mud with your hands. It's just the most unbelievably kind of grounding experience. Michael Hingson  36:26 Yeah, I hear you, yeah. One of the things that I like to do is, and I don't get to do it as much as I would like, but I am involved with organizations like the radio enthusiasts of Puget Sound, which, every year, does recreations of old radio shows. And so we get the scripts we we we have several blind people who are involved in we actually go off and recreate some of the old shows, which is really a lot of fun, Nick Francis  36:54 I bet, yeah, yeah, sort of you know that connection to the past is, is, yeah, it's great radio. Radio is amazing. Michael Hingson  37:03 Anyway, what we have to do is to train some of the people who have not had exposure to old radio. We need to train them as to how to really use their voices to convey like the people who performed in radio, whatever they're doing, because too many people don't really necessarily know how to do that well. And it is, it is something that we're going to work on trying to find ways to get people really trained. And one of the ways, of course, is you got to listen to the old show. So one of the things we're getting more and more people to do when we do recreations is to go back and listen to the original show. Well, they say, Well, but, but that's just the way they did it. That's not necessarily the way it should be done. And the response is, no, that's not really true. The way they did it sounded natural, and the way you are doing it doesn't and there's reality that you need to really learn how to to use your voice to convey well, and the only way to do it is to listen to the experts who did it. Nick Francis  38:06 Yeah, well, it's, you know, it's amazing. The, you know, when the BBC was founded, all the news readers and anyone who appeared on on the radio to to present or perform, had to wear like black tie, like a tuxedo, because it was, you know, they're broadcasting to the nation, so they had to, you know, they had to be dressed appropriately, right, which is kind of amazing. And, you know, it's interesting how you know, when you, when you change your dress, when you change the way you're sitting, it does completely change the way that you project yourself, yeah, Michael Hingson  38:43 it makes sense, yeah, well, and I always enjoyed some of the old BBC radio shows, like the Goon Show, and completely some of those are so much fun. Nick Francis  38:54 Oh, great, yeah, I don't think they were wearing tuxedo. It's tuxedos. They would Michael Hingson  38:59 have been embarrassed. Yeah, right, right. Can you imagine Peter Sellers in a in a tux? It just isn't going to happen. Nick Francis  39:06 No, right, right. But yeah, no, it's so powerful. You know, they say radio is better than TV because the pictures are better. Michael Hingson  39:15 I agree. Yeah, sure, yeah. Well, you know, I I don't think this is quite the way he said it, but Fred Allen, the old radio comedian, once said they call television the new medium, because that's as good as it's ever going Nick Francis  39:28 to get. Yeah, right, right, yeah. Michael Hingson  39:32 I think there's truth to it. Whether that's exactly the way he said it or not, there's truth to that, yeah, but there's also a lot of good stuff on TV, so it's okay. Nick Francis  39:41 Well, it's so interesting. Because, you know, when you look at the it's never been more easy to create your own content, yeah, and so, you know, and like, in a way, TV, you know, he's not wrong in that, because it suddenly opened up this, this huge medium for people just to just create. Right? And, you know, and I think, like so many people, create without thinking, and, you know, and certainly in our kind of, in the in the world that we're living in now with AI production, making production so much more accessible, actually taking the time as a human being just to really think about, you know, who are the audience, what are the things that are going to what are going to kind of resonate with them? You know? Actually, I think one of the risks with AI, and not just AI, but just like production being so accessible, is that you can kind of shoot first and kind of think about it afterwards, and, you know, and that's never good. That's always going to be medium. It's medium at best, frankly. Yeah, so yeah, to create really great stuff takes time, you know, yeah, to think about it. Yeah, for sure, yeah. Michael Hingson  40:50 Well, you know, our podcast is called unstoppable mindset. What do you think that unstoppable mindset really means to you as a practical thing and not just a buzzword. Because so many people talk about the kinds of buzzwords I hear all the time are amazing. That's unstoppable, but it's really a lot more than a buzzword. It goes back to what you think, I think. But what do you think? Nick Francis  41:15 I think it's something that is is buried deep inside you. You know, I'd say the simple answer is, is just resilience. You know, it's, it's been rough. I write anyone running a small business or a medium sized business at the minute, you know, there's been some tough times over the last, kind of 1824, months or so. And, you know, I was talking to a friend of mine who she sold out of her business. And she's like, you know, how are things? I was like, you know, it's, it's, it's tough, you know, we're getting through it, you know, we're changing a lot of things, you know, we're like, we're definitely making the business better, but it's hard. And she's like, Listen, you know, when three years before I sold my company, I was at rock bottom. It was, I genuinely thought it was so stressful. I was crushed by it, but I just kept going. And she's just like, just keep going. And the only difference between success and failure is that resilience and just getting up every day and you just keep, keep throwing stuff at the wall, keep trying new things, keep working and trying to be better. I think, you know, it's funny when you look at entrepreneurs, I'm a member of a mentoring group, and I hope I'm not talking out of school here, but you know, there's 15 entrepreneurs, you know, varying sizes of business, doing all sorts, you know, across all sorts of different industries. And if you sat on the wall, if you were fly on the wall, and you sit and look at these people on a kind of week, month to month basis, and they all present on how their businesses are going. You go, this is this being an entrepreneur does not look like a uniformly fun thing, you know, the sort of the stress and just, you know, people crying and stuff, and you're like, gosh, you know, it's so it's, it's, it's hard, and yet, you know, it's people just keep coming back to it. And yet, I think it's because of that struggle that you have to kind of have something in built in you, that you're sort of, you're there to prove something. And I, you know, I've thought a lot about this, and I wonder whether, kind of, the death of my father at such a young age kind of gave me this incredible fire to seek His affirmation, you know. And unfortunately, obviously, the tragedy of that is like, you know, the one person who would never give me affirmation is my dad. And yet, you know, I get up every day, you know, to have early morning calls with the UK or with Singapore or wherever. And you know, you just just keep on, keeping on. And I think that's probably what and knowing I will never quit, you know, like, even from the earliest days of casual, when we were just, like a couple of people, and we were just, you know, kids doing our very best, I always knew the company was going to be a success act. Like, just a core belief that I was like, this is going to work. This is going to be a success. I didn't necessarily know what that success would look like. I just but I did know that, like, whatever it took, we would map, we'd map our way towards that figure it out. We'd figure it out. And I think, you know, there's probably something unstoppable. I don't know, I don't want to sound immodest, but I think there's probably something in that that you're just like, I am just gonna keep keep on, keeping on. Michael Hingson  44:22 Do you think that resilience and unstoppability are things that can be taught, or is it just something that's built into you, and either you have it or you don't? Nick Francis  44:31 I think it's something that probably, it's definitely something that can be learned, for sure, you know. And there are obviously ways that it can there's obviously ways it can be taught. You know, I was, I spent some time in the reserve, like the Army Reserve in the UK, and I just, you know, a lot of that is about teaching you just how much further you can go. I think what it taught me was it was so. So hard. I mean, honestly, some of the stuff we did in our training was, like, you know, it's just raining and raining and raining and, like, because all your kits soaking wet is weighs twice what it did before, and you just, you know, sleeping maybe, you know, an hour or two a night, and, you know, and there wasn't even anyone shooting at us, right? So, you know, like the worst bit wasn't even happening. But like, and like, in a sense, I think, you know, that's what they're trying to do, that, you know, they say, you know, train hard and fight easy. But I remember sort of sitting there, and I was just exhausted, and I just genuinely, I was just thought, you know, what if they tell me to go now, I just, I can't. I literally, I can't, I can't do it. Can't do it. And then they're like, right, lads, put your packs on. Let's go and just put your pack on. Off you go, you know, like, this sort of, the idea of not, like, I was never going to quit, just never, never, ever, you know, and like I'd physically, if I physically, like, literally, my physical being couldn't stand up, you know, I then that was be, that would be, you know, if I was kind of, like literally incapacitated. And I think what that taught me actually, was that, you know, you have what you believe you can do, like you have your sort of, you have your sort of physical envelope, but like that is only a third or a quarter of what you can actually achieve, right, you know. And I think what that, what the that kind of training is about, and you know, you can do it in marathon training. You can do it in all sorts of different, you know, even, frankly, meditate. You know, you train your mind to meditate for, you know, an hour, 90 minutes plus. You know, you're still doing the same. You know, there's a, there's an elasticity within your brain where you can teach yourself that your envelope is so much larger. Yeah. So, yeah, you know, like, is casual going to be a success? Like, I'm good, you know, I'm literally, I won't I won't stop until it is Michael Hingson  46:52 right, and then why stop? Exactly, exactly you continue to progress and move forward. Well, you know, when everything feels uncertain, whether it's the markets or whatever, what do you do or what's your process for finding clarity? Nick Francis  47:10 I think a lot of it is in having structured time away. I say structured. You build it into your calendar, but like, but it's unstructured. So, you know, I take a lot of solace in being physically fit. You know, I think if you're, if you feel physically fit, then you feel mentally far more able to deal with things. I certainly when I'm if I'm unfit and if I've been working too much and I haven't been finding the time to exercise. You know, I feel like the problems we have to face just loom so much larger. So, you know, I, I'll book out. I, you know, I work with a fan. I'm lucky enough to have a fantastic assistant who, you know, we book in my my exercise for each week, and it's almost the first thing that goes in the calendar. I do that because I can't be the business my my I can't be the leader my business requires. And it finally happened. It was a few years ago I kind of, like, the whole thing just got really big on me, and it just, you know, and I'm kind of, like, being crushed by it. And I just thought, you know what? Like, I can't, I can't fit other people's face mask, without my face mask being fit, fitted first. Like, in order to be the business my business, I keep saying that to be the lead in my business requires I have to be physically fit. So I have to look after myself first. And so consequently, like, you know, your exercise shouldn't be something just get squeezed in when you find when you have time, because, you know, if you've got family and you know, other things happening, like, you know, just will be squeezed out. So anyway, that goes in. First, I'll go for a bike ride on a Friday afternoon, you know, I'll often listen to a business book and just kind of process things. And it's amazing how often, you know, I'll just go for a run and, like, these things that have been kind of nagging away in the back of my mind, just suddenly I find clarity in them. So I try to exercise, like, five times a week. I mean, that's obviously more than most people can can manage, but you know that that really helps. And then kind of things, like the ceramics is very useful. And then, you know, I'm lucky. I think it's also just so important just to appreciate the things that you already have. You know, I think one of the most important lessons I learned last year was this idea that, you know, here is the only there. You know, everyone's working towards this kind of, like, big, you know, it's like, oh, you know, when I get to there, then everything's going to be okay, you know. And actually, you know, if you think about like, you know, and what did you want to achieve when you left college? Like, what was the salary band that you want? That you wanted to achieve? Right? A lot of people, you know, by the time you hit 4050, you've blown way through that, right? And yet you're still chasing the receding Summit, yeah, you know. And so actually, like, wherever we're trying to head to, we're already there, because once you get there, there's going to be another there that you're trying to. Head to right? So, so, you know, it's just taking a moment to be like, you know, God, I'm so lucky to have what I have. And, you know, I'm living in, we're living in the good old days, like right now, right? Michael Hingson  50:11 And the reality is that we're doing the same things and having the same discussions, to a large degree, that people did 50, 100 200 years ago. As you pointed out earlier, the fact is that we're, we're just having the same discussions about whether this works, or whether that works, or anything else. But it's all the same, Nick Francis  50:33 right, you know. And you kind of think, oh, you know, if I just, just, like, you know, if we just open up these new offices, or if we can just, you know, I think, like, look, if I, if I'd looked at casual when we started it as it is now, I would have just been like, absolute. My mind would have exploded, right? You know, if you look at what we've achieved, and yet, I kind of, you know, it's quite hard sometimes to look at it and just be like, Oh yeah, but we're only just starting. Like, there's so much more to go. I can see so much further work, that we need so many more things, that we need to do, so many more things that we could do. And actually, you know, they say, you know, I'm lucky enough to have two healthy, wonderful little girls. And you know, I think a lot of bread winners Look at, look at love being provision, and the idea that, you know, you have to be there to provide for them. And actually, the the truest form of love is presence, right? And just being there for them, and like, you know, not being distracted and kind of putting putting things aside, you know, not jumping on your emails or your Slack messages or whatever first thing in the morning, you know. And I, you know, I'm not. I'm guilty, like, I'm not, you know, I'm not one of these people who have this kind of crazy kind of morning routine where, like, you know, I'm incredibly disciplined about that because, you know, and I should be more. But like, you know, this stuff, one of the, one of the things about having a 24 hour business with people working all over the world is there's always things that I need to respond to. There's always kind of interesting things happening. And so just like making sure that I catch myself every so often to be like, I'm just going to be here now and I'm going to be with them, and I'm going to listen to what they're saying, and I'm going to respond appropriately, and, you know, I'm going to play a game with them, or whatever. That's true love. You know? Michael Hingson  52:14 Well, there's a lot of merit to the whole concept of unplugging and taking time and living in the moment. One of the things that we talked about in my book live like a guide dog, that we published last year, and it's all about lessons I've learned about leadership and teamwork and preparedness from eight guide dogs and my wife's service dog. One of the things that I learned along the way is the whole concept of living in the moment when I was in the World Trade Center with my fifth guide dog, Roselle. We got home, and I was going to take her outside to go visit the bathroom, but as soon as I took the harness off, she shot off, grabbed her favorite tug bone and started playing tug of war with my retired guide dog. Asked the veterinarians about him the next day, the people at Guide Dogs for the Blind, and they said, Well, did anything threaten her? And I said, No. And they said, there's your answer. The reality is, dogs live in the moment when it was over. It was over. And yeah, right lesson to learn. Nick Francis  53:15 I mean, amazing, absolutely amazing. You must have taken a lot of strength from that. Michael Hingson  53:20 Oh, I think it was, it was great. It, you know, I can look back at my life and look at so many things that have happened, things that I did. I never thought that I would become a public speaker, but I learned in so many ways the art of speaking and being relaxed at speaking in a in a public setting, that when suddenly I was confronted with the opportunity to do it, it just seemed like the natural thing to do. Nick Francis  53:46 Yeah, it's funny, because I think isn't public speaking the number one fear. It is. It's the most fit. It's the most feared thing for the most people. Michael Hingson  53:57 And the reality is going back to something that we talked about before. The reality is, audiences want you to succeed, unless you're a jerk and you project that, audiences want to hear what you have to say. They want you to be successful. There's really nothing to be afraid of but, but you're right. It is the number one fear, and I've never understood that. I mean, I guess I can intellectually understand it, but internally, I don't. The first time I was asked to speak after the World Trade Center attacks, a pastor called me up and he said, we're going to we're going to have a service outside for all the people who we lost in New Jersey and and that we would like you to come and speak. Take a few minutes. And I said, Sure. And then I asked him, How many people many people were going to be at the service? He said, 6000 that was, that was my first speech. Nick Francis  54:49 Yeah, wow. But it didn't bother me, you know, no, I bet Michael Hingson  54:54 you do the best you can, and you try to improve, and so on. But, but it is true that so many people. Are public speaking, and there's no reason to what Nick Francis  55:03 did that whole experience teach you? Michael Hingson  55:06 Well, one of the things that taught me was, don't worry about the things that you can't control. It also taught me that, in reality, any of us can be confronted with unexpected things at any time, and the question is, how well do we prepare to deal with it? So for me, for example, and it took me years after September 11 to recognize this, but one of the things that that happened when the building was hit, and Neither I, nor anyone on my side of the building really knew what happened. People say all the time, well, you didn't know because you couldn't see it. Well, excuse me, it hit 18 floors above us on the other side of the building. And the last time I checked X ray vision was fictitious, so nobody knew. But did the building shake? Oh, it tipped. Because tall buildings like that are flexible. And if you go to any tall building, in reality, they're made to buffet in wind storms and so on, and in fact, they're made to possibly be struck by an airplane, although no one ever expected that somebody would deliberately take a fully loaded jet aircraft and crash it into a tower, because it wasn't the plane hitting the tower as such that destroyed both of them. It was the exploding jet fuel that destroyed so much more infrastructure caused the buildings to collapse. But in reality, for me, I had done a lot of preparation ahead of time, not even thinking that there would be an emergency, but thinking about I need to really know all I can about the building, because I've got to be the leader of my office, and I should know all of that. I should know what to do in an emergency. I should know how to take people to lunch and where to go and all that. And by learning all of that, as I learned many and discovered many years later, it created a mindset that kicked in when the World Trade Center was struck, and in fact, we didn't know until after both towers had collapsed, and I called my wife. We I talked with her just before we evacuated, and the media hadn't even gotten the story yet, but I never got a chance to talk with her until after both buildings had collapsed, and then I was able to get through and she's the first one that told us how the two buildings had been hit by hijacked aircraft. But the mindset had kicked in that said, You know what to do, do it and that. And again, I didn't really think about that until much later, but that's something that is a lesson we all could learn. We shouldn't rely on just watching signs to know what to do, no to go in an emergency. We should really know it, because the knowledge, rather than just having information, the true intellectual knowledge that we internalize, makes such a big difference. Nick Francis  57:46 Do you think it was the fact that you were blind that made you so much more keen to know the way out that kind of that really helped you to understand that at the time? Michael Hingson  57:56 Well, what I think is being blind and growing up in an environment where so many things could be unexpected, for me, it was important to know so, for example, when I would go somewhere to meet a customer, I would spend time, ahead of time, learning how to get around, learning how to get to where they were and and learning what what the process was, because we didn't have Google Maps and we didn't have all the intellectual and and technological things that we have today. Well intellectual we did with the technology we didn't have. So today it's easier, but still, I want to know what to do. I want to really have the answers, and then I can can more easily and more effectively deal with what I need to deal with and react. So I'm sure that blindness played a part in all of that, because if I hadn't learned how to do the things that I did and know the things that I knew, then it would have been a totally different ball game, and so sure, I'm sure, I'm certain that blindness had something to do with it, but I also know that, that the fact is, what I learned is the same kinds of things that everyone should learn, and we shouldn't rely on just the signs, because what if the building were full of smoke, then what would you do? Right? And I've had examples of that since I was at a safety council meeting once where there was somebody from an electric company in Missouri who said, you know, we've wondered for years, what do we do if there's a fire in the generator room, in the basement, In the generator room, how do people get out? And he and I actually worked on it, and they developed a way where people could have a path that they could follow with their feet to get them out. But the but the reality is that what people first need to learn is eyesight is not the only game in town. Yeah, right. Mean, it's so important to really learn that, but people, people don't, and we take too many things for granted, which is, which is really so unfortunate, because we really should do a li

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]

In this last episode of the special AI mini-series, we now explore the human side of transformation, where technology meets purpose and people remain at the center. From future jobs and critical thinking to working with C-level leaders, how human intervention and high-quality data drive success in an AI-powered world.This week Dave, Esmee , Rob sit down with Johanna Hutchinson, CDO at BAE systems about why data matters, the rise of Sovereign AI, and the skills shaping the intelligence age. TLDR00:55 Introduction of Johanna Hutchinson02:09 Explaining the State of AI mini-series with Craig06:01 Conversation with Johanna34:20 Weaving today's data tapestries with AI40:20 Going to a rave GuestJohanna Hutchinson: https://www.linkedin.com/in/johanna-hutchinson-95b95568/ HostsDave Chapman: https://www.linkedin.com/in/chapmandr/Esmee van de Giessen: https://www.linkedin.com/in/esmeevandegiessen/Rob Kernahan: https://www.linkedin.com/in/rob-kernahan/with co-host Craig Suckling: https://www.linkedin.com/in/craigsuckling/ProductionMarcel van der Burg: https://www.linkedin.com/in/marcel-vd-burg/Dave Chapman: https://www.linkedin.com/in/chapmandr/ SoundBen Corbett: https://www.linkedin.com/in/ben-corbett-3b6a11135/Louis Corbett:  https://www.linkedin.com/in/louis-corbett-087250264/ 'Cloud Realities' is an original podcast from Capgemini

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]

The Secret Ingredient Every Agile Team NeedsI still remember the sprint retrospective that changed everything.One of our quietest developer, had been silent for three retrospectives straight.But this time, she raised her hand. “I think our deployment process is broken,” she said, her voice barely above a whisper. “And I have an idea to fix it.”The room went quiet.In my previous teams, this would have been the moment when someone senior would have shut down the conversation with a dismissive “We've always done it this way.”But not here. Not anymore.How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

In this episode, I share an interview with Mike Wrathall, where I explore his background in strategy, agile methods and sustainability. His early career involved building digital services, primarily for government and social housing organizations, such as streamlining the process for getting people who are homeless or victims of domestic violence into safe housing quicker. Continue Reading

In this special episode, I explore the three drivers that have sustained this podcast: perspiration, inspiration, and determination. I share personal stories that shaped my mission and the lessons learned. After 100 episodes of sharing tactics and advice, this is my chance to pull back the curtain on the bigger picture of building practices that are profitable, sustainable, and scalable. Get full show notes, transcript, and more information here: agileattorney.com/100 Take your law practice from overwhelmed to optimized with GreenLine Legal Follow along on LinkedIn: linkedin.com/in/johnegrant

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]

Solving the Agile Executive Support Problem There is a statistic in the Agile community: the number one reason Agile initiatives fail is a lack of executive support. We see this stat, we nod our heads, and then we proceed to complain that leadership just “doesn’t get it.” But CEOs and executives aren’t sitting around wondering how to make YOU and your team more effective. They are worried about revenue, market share, and survival. If you don’t have executive support for your initiative, it's not because they don’t care; it's because you haven't given them a compelling reason to care. Executive support is something WE have to take responsibility for soliciting. The problem is that most Agile practitioners have zero experience driving high-stakes conversations with people in power. We are great at talking to teams, but we freeze up when it comes to the C-Suite. So, how do you fix this? You don’t do it by waiting for the next quarterly review to make your case. You do it by practicing in public. The “Muscle” of Influence Speaking to power is a skill, not a talent. Like any muscle, it needs resistance training to grow. You need to get in the habit of having a strong point of view on what Agile success actually looks like, and you need to start marketing that opinion aggressively. Here’s what I did. I took a specific, tactical approach to building this muscle: Start doing LinkedIn Lives. This isn’t about getting “likes.” It is about two critical outcomes: Clarifying Your Message: When you commit to broadcasting your expertise, you force yourself to articulate your thoughts clearly. You stop hiding behind jargon and start speaking in value. Building an Audience that trusts you: By hosting a platform, you create a space where you can invite leaders, stakeholders, and people of influence to join you. It changes the dynamic. You are no longer the person begging for five minutes of their time; you are the host offering them a spotlight. Stop Wishing for Executive Support. Claim it. If you want executive support, stop treating Agile like a methodology and start treating it like a product you have to sell. When you market your POV publicly, you build credibility. You build trust. Most importantly, you practice the art of holding your ground in a conversation. By the time you actually need to pitch an initiative or ask for executive support to your internal leadership, you won’t be nervous. You will have had that conversation a dozen times already on your livestreams. Don’t wait for permission to be a leader. Turn on the camera, state your case, and build the executive support you need to change minds and create Agile success. If you liked this episode, you might also like: Episode 228 – Agile Has Lost The Script Episode 230 – The Difference-Makers How To Revive Agile (And Your Career **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.

Are your questions undermining your leadership credibility? Bob Galen and Josh Anderson expose the hidden dangers of over-questioning, from "death by a thousand questions" to weaponized curiosity. Learn when to ask, when to declare, and how to avoid losing the room. Practical tips for agile leaders, coaches, and managers who want to build trust, not erode it. 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!

Why do so many AI rollouts stall right after the tools ship?In this episode of Alexa's Input (AI), Alexa talks with Melissa Reeve, author of the book Hyper Adaptive: Rewiring the Enterprise to Become AI Native, about what it actually takes to get AI adopted in large organizations.Melissa shares how her background in lean, Agile, and DevOps transformation shaped her view that AI adoption is less about “buying the tool” and more about rewiring how work happens. Together, they break down why many AI initiatives fail (and why ROI is slow), the FOCUS framework, the “AI time paradox,” and how support structures like AI activation hubs, social learning, and better success metrics can raise quality and accelerate impact.A must-listen for engineering leaders, product teams, and executives trying to move beyond pilots and turn AI into real operational leverage.Learn more about Melissa and Hyper Adaptive below.LinksWatch: ⁠⁠⁠https://www.youtube.com/@alexa_griffith⁠⁠⁠Read: ⁠⁠⁠⁠⁠https://alexasinput.substack.com/⁠⁠⁠⁠⁠Listen:⁠ https://creators.spotify.com/pod/profile/alexagriffith/⁠More: ⁠⁠⁠https://linktr.ee/alexagriffith⁠⁠⁠Website: ⁠⁠⁠https://alexagriffith.com/⁠⁠⁠LinkedIn: ⁠⁠⁠https://www.linkedin.com/in/alexa-griffith/⁠⁠⁠Find out more about the guest at:LinkedIn: https://www.linkedin.com/in/melissamreeve/Book: https://itrevolution.com/product/hyperadaptive/KeywordsAI adoption, enterprise transformation, Hyper Adaptive model, organizational change, DevOps, Lean, Agile, AI integration, customer-centricity, innovation accounting, social learningChapters00:00 Introduction to AI Adoption in Enterprises03:00 Melissa's Journey and the Foundation of AI Thinking06:06 The Analogy of DevOps and AI Implementation08:47 Cultural Shifts vs. Tooling in AI Adoption11:49 The Hyper Adaptive Model for AI Integration14:48 Sociology of Workflows and Organizational Change17:49 Understanding AI Initiative Failures21:00 Customer Centricity in AI Solutions23:58 The AI Time Paradox and Learning26:58 AI Activation Hubs and Their Role30:54 The Role of Human Oversight in AI Automation34:03 Incentivizing AI Engagement in Organizations35:59 Social Learning and AI: The Power of Collaboration40:57 Practical Applications of AI in Daily Life44:44 Quality vs. Productivity: The AI Dilemma46:13 The Focus Framework: Prioritizing AI Use Cases48:23 Influencing AI Adoption in Organizations51:07 The Future of Hyper Adaptive Organizations55:08 Decision-Making in the Age of AI57:37 Key Takeaways for Leaders in the AI Revolution

BONUS: The Agile Organization as a Learning System Think Like a Farmer, Not a Factory Manager "Go slow to go fast. If you want to go somewhere, go together as a team. Take a farmer's mentality."   Simon contrasts monoculture industrial thinking with the permaculture approach of Joel Salatin. Industrial approaches optimize for short-term efficiency but create fragile systems. Farmer thinking recognizes that healthy ecosystems require patience, diversity, and nurturing conditions for growth. The nervous system that's constantly stressed never builds much over time—think of the body, trust the body, let the body be a body. Value Masters, Not Scrum Masters "We need value masters, not Scrum Masters. Agile is a useful tool for delivering value, but value itself is primary. Everything else is secondary—Agile included."   Tom makes his most provocative point: if you asked a top manager whether they'd prefer an agile person or value delivery, the answer is obvious. Agile is one tactic among many for delivering value—not even a necessary one. The shift required is from process mastery to value mastery, from Scrum Masters to people who understand and can deliver on critical stakeholder values. The DOVE Manifesto "I wrote a paper called DOVE—Deliver Optimum Values Efficiently. It's the manifesto focusing on delivering value, delivering value, delivering value."   Tom offers his alternative to the Agile Manifesto: a set of principles laser-focused on value delivery. The document includes 10 principles on a single page that can guide any organization toward genuine impact. Everything else—processes, frameworks, methodologies—are secondary tools in service of this primary goal. Read Tom's DOVE manifesto here.  Building the Glue Between Social and Physical Technology "Value is created in interactions. That's where the social and physical technology meet—that joyous boundary where stuff gets done."   Simon describes seeing the world through two lenses: physical technology (visible tools and systems) and social technology (culture, relationships, the air we breathe). Eric Beinhoeker's insight is that progress happens at the intersection. The Gilbian learning loops provide the structure; trust and human connection provide the fuel. Together, they create organizations that can actually learn and adapt.   Further Reading To Support Your Learning Journey Resources & Further Reading Explore these curated resources to deepen your understanding of strategic planning, value-based management, and transformative organizational change.    

BONUS: Quality 5.0—Quantifying the "Unmeasurable" With Tom Gilb and Simon Holzapfel Clarification Before Quantification "Quantification is not the main idea. The key idea is clarification—so that the executive team understands each other."   Tom emphasizes that measurement is a means to an end. The real goal is shared understanding. But quantification is a powerful clarification tactic because it forces precision. When someone says they want a "very fast car," asking "can we define a scale of measure?" immediately surfaces the vagueness. Miles per hour? Acceleration time? Top speed? Each choice defines what you're actually optimizing for. The Scale-Meter-Target Framework "First, define a scale of measure. Second, define the meter—the device for measuring. Third, set numbers: where are we now, what's the minimum to survive, and what does success look like?"   Tom's framework makes the abstract concrete:   Scale of measure: What dimension are you measuring? (e.g., time to complete task) Meter: How will you measure it? (e.g., user testing with stopwatch) Past/Status: Where are you now? (e.g., currently takes 47 seconds) Tolerable: What's the minimum acceptable? (e.g., must be under 30 seconds to survive) Target/Goal: What does success look like? (e.g., 15 seconds or less)   Many important concepts like "usability" decompose into 10+ different scales of measure—you're not looking for one magic number but a set of relevant metrics. Trust as the Organizational Hormone "Change moves at the speed of trust. Once there's trust, information flows. Once information flows, the system comes to life and can learn. Until there's trust, you have the Soviet problem."   Simon introduces trust as the "human growth hormone" of organizational change—it's fast, doesn't require a user's manual, and enables everything else. Low-trust environments hoard information, guaranteeing poor outcomes. The practical advice? Make your work visible to your manager, alignment-check first, do something, show results. Living the learning cycle yourself builds trust incrementally. And as Tom adds: if you deliver increased critical value every week, you will build trust.   About Tom Gilb and Simon Holzapfel   Tom Gilb, born in the US, lived in London, and then moved to Norway in 1958. An independent teacher, consultant, and writer, he has worked in software engineering, corporate top management, and large-scale systems engineering. As the saying goes, Tom was writing about Agile before Agile was named. In 1976, Tom introduced the term "evolutionary" in his book Software Metrics, advocating for development in small, measurable steps. Today, we talk about Evo, the name Tom uses to describe his approach. Tom has worked with Dr. Deming and holds a certificate personally signed by him. You can listen to Tom Gilb's previous episodes here.    You can link with Tom Gilb on LinkedIn    Simon Holzapfel is an educator, coach, and learning innovator who helps teams work with greater clarity, speed, and purpose. He specializes in separating strategy from tactics, enabling short-cycle decision-making and higher-value workflows. Simon has spent his career coaching individuals and teams to achieve performance with deeper meaning and joy. Simon is also the author of the Equonomist newsletter on Substack. And you can listen to Simon's previous episodes on the podcast here.    You can link with Simon Holzapfel on LinkedIn.  

BONUS: Testing as Measurement—Why Bug-Hunting Misses the Point With Tom Gilb and Simon Holzapfel The Revelation That Almost Caused a Car Crash "Tom said like 10 sentences in a row, kind of like a geometric proof, that just so blew my mind I almost drove off the road. I realized I had wasted hundreds of hours in boardrooms arguing about errors of which we were aware of perhaps 10%."   Simon shares the moment Tom's framework clicked for him. The insight? Traditional testing—finding bugs and defects—is the wrong focus entirely. It's a programmer's view of the world. Managers don't care about bugs; they care about results, about improvements in their business. Tom calls this shift moving from "testing" to "measurement of enhanced or increased value at every cycle." The American Toast Problem "How do we make toast in America? We burn the toast, and then we pay someone to scrape off the black bits off the bread."   Vasco invokes Deming's classic analogy to describe traditional software testing. The entire testing-at-the-end approach is fundamentally wasteful. Instead, Tom advocates for continuous measurement against quantified values. If you expected 3% progress toward your goals this week and didn't get it, you've learned something critical: your strategy needs to change. If you did get it, keep going with confidence. Four Questions at Every Checkpoint "Where are we going? Where are we now? Where should we have been at this point? And why is there a gap?"   Drawing from fighter pilot doctrine, these four questions should be asked at every micro-cycle—not just at quarterly reviews. Fighter pilots ask these questions every minute during critical missions, with clear abort criteria if answers are unacceptable. Most organizations have no abort criteria for their strategies at all, guaranteeing they'll discover failures far too late.   About Tom Gilb and Simon Holzapfel   Tom Gilb, born in the US, lived in London, and then moved to Norway in 1958. An independent teacher, consultant, and writer, he has worked in software engineering, corporate top management, and large-scale systems engineering. As the saying goes, Tom was writing about Agile before Agile was named. In 1976, Tom introduced the term "evolutionary" in his book Software Metrics, advocating for development in small, measurable steps. Today, we talk about Evo, the name Tom uses to describe his approach. Tom has worked with Dr. Deming and holds a certificate personally signed by him. You can listen to Tom Gilb's previous episodes here.    You can link with Tom Gilb on LinkedIn    Simon Holzapfel is an educator, coach, and learning innovator who helps teams work with greater clarity, speed, and purpose. He specializes in separating strategy from tactics, enabling short-cycle decision-making and higher-value workflows. Simon has spent his career coaching individuals and teams to achieve performance with deeper meaning and joy. Simon is also the author of the Equonomist newsletter on Substack. And you can listen to Simon's previous episodes on the podcast here.    You can link with Simon Holzapfel on LinkedIn.

BONUS: Continuous Strategy Engineering—Beyond Waterfall Planning With Tom Gilb and Simon Holzapfel Strategy Professors Are Decades Behind "The professors of strategy have no clue as to what Evo is. They are locked in decades ago, waterfall mode."   Tom's analysis is stark: the people teaching strategy in business schools haven't undergone the same agile transformation that software development experienced. They still think in terms of 5-year plans that get tested at the end—a guaranteed recipe for discovering failure too late. The alternative? Decompose any large strategy into weekly value delivery steps. And if you think that's impossible, ask any AI to do it for you—it will produce 52 reasonable weekly increments in about a minute. Why OKRs Aren't Enough for Complex Systems "If you're doing small-scale stuff that OKRs were designed for, like planning your personal work 14 days hence, OKRs are wonderful. If you're designing the air traffic control system for Europe, they're just too simple."   Tom distinguishes between tools appropriate for personal productivity and those needed for complex organizational strategy. OKRs force some thinking, which is good, but they weren't designed for—and have never been adapted to—large-scale systems engineering. His paper "What is Wrong with OKRs?" documents roughly 100 gaps between simple OKRs and what robust value requirements actually require. Check out Tom Gilb's paper on what's wrong with OKR's and how to fix it.  The Missing Alignment Layer "We have no mental model for most of leadership about how you actually align people around clear vision."   Simon introduces the concept of a Hoshin-Kanri "sprinkler" system—imagine strategic clarity flowing from the top and misting over everyone's desk as alignment. Most organizations lack anything resembling this. They have Moses descending from expensive consultant retreats with tablets, but no continuous two-way flow of strategic information. The result? Teams work hard on things that don't matter while critical values go unaddressed. About Tom Gilb and Simon Holzapfel   Tom Gilb, born in the US, lived in London, and then moved to Norway in 1958. An independent teacher, consultant, and writer, he has worked in software engineering, corporate top management, and large-scale systems engineering. As the saying goes, Tom was writing about Agile before Agile was named. In 1976, Tom introduced the term "evolutionary" in his book Software Metrics, advocating for development in small, measurable steps. Today, we talk about Evo, the name Tom uses to describe his approach. Tom has worked with Dr. Deming and holds a certificate personally signed by him. You can listen to Tom Gilb's previous episodes here.    You can link with Tom Gilb on LinkedIn    Simon Holzapfel is an educator, coach, and learning innovator who helps teams work with greater clarity, speed, and purpose. He specializes in separating strategy from tactics, enabling short-cycle decision-making and higher-value workflows. Simon has spent his career coaching individuals and teams to achieve performance with deeper meaning and joy. Simon is also the author of the Equonomist newsletter on Substack. And you can listen to Simon's previous episodes on the podcast here.    You can link with Simon Holzapfel on LinkedIn.

Stephen Clark of Ars Technica joins me to talk about a ton of stories in the news—Jared Isaacman was back in front of Congress, a few Starliner flights have been cut from the ISS manifest, Starship received environmental approval to proceed at SLC-37, Zhuque-3 almost stuck its first landing attempt, the Soyuz launch pad fell apart at Baikonur, and the Space Force has a new mission naming scheme.This episode of Main Engine Cut Off is brought to you by 32 executive producers—Matt, Fred, Kris, Natasha Tsakos, Josh from Impulse, Better Every Day Studios, Joakim, Joel, Ryan, The Astrogators at SEE, Tim Dodd (the Everyday Astronaut!), Heiko, Jan, Theo and Violet, Donald, Pat, Will and Lars from Agile, Lee, Russell, Joonas, Warren, Steve, Frank, Stealth Julian, David, and four anonymous—and hundreds of supporters.TopicsAuthor: Stephen Clark - Ars TechnicaNASA nominee appears before Congress, defends plans to revamp space agency - Ars TechnicaCongress warned that NASA's current plan for Artemis “cannot work” - Ars TechnicaNASA seeks a “warm backup” option as key decision on lunar rover nears - Ars TechnicaIt's official: Boeing's next flight of Starliner will be allowed to carry cargo only - Ars TechnicaA spectacular explosion shows China is close to obtaining reusable rockets - Ars TechnicaBefore a Soyuz launch Thursday someone forgot to secure a 20-ton service platform - Ars TechnicaRivals object to SpaceX's Starship plans in Florida—who's interfering with whom? - Ars TechnicaSpaceX on X: “We've received approval to develop Space Launch Complex-37 for Starship operations at Cape Canaveral Space Force Station. Construction has started. With three launch pads in Florida, Starship will be ready to support America's national security and Artemis goals as the world's…”Attack, defend, pursue—the Space Force's new naming scheme foretells new era - Ars TechnicaThe 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