Podcasts about Agile

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]

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]

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/

Host Susan Diaz sits down with sales strategist Gazzy Amin, founder of Sales Beyond Scripts, to talk about the real ways AI is changing revenue, planning, and scale. They cover AI as a thinking partner, how to use it across departments in a small business, why audits matter more than hype, and how mindset quietly determines whether you treat AI as a threat or an advantage. Episode summary This episode is part of Susan's 30-episodes-in-30-days "podcast to book" sprint for Swan Dive Backwards. Susan and Gazzy zoom in on the selling process first. Then they zoom out to the whole business. They talk about three camps of AI users (anti, curious, invested), and why the curious group has a huge edge right now. Gazzy shares how she uses AI as a co-pilot across marketing, sales, and operations. Not just for captions. For thinking, planning, campaign creation, and building repeatable systems. They also go into mindset. Gazzy's approach is clear: protect your mental real estate. Don't let recession talk, doom narratives, or fear-based chatter shape your decisions. Use AI to help you widen perspective, challenge limiting beliefs, and plan like a CEO. Key takeaways AI is more than a copywriting tool. It's a strategic brainstorming partner that reduces burnout and speeds up decision-making. If you want to scale, map your departments and ask AI how it can support each one. Marketing, sales, finance, operations, hiring, delivery, and client experience. Do a year-end audit before you set new goals. Feed AI your revenue data, launches, offers, and calendar patterns. Then let it ask you smart questions you wouldn't think to ask yourself. AI doesn't erase experts. It raises your baseline. You show up to expert conversations more informed, so you can go deeper faster. Documentation and playbooks become an unfair advantage. When knowledge lives only in your head, your business is fragile. AI helps you turn what's in your brain into systems other people can run. Scale is doing more with less. AI can increase output without needing to triple headcount, if you're intentional about workflows and training your team. Women have a big opportunity here. AI can reduce the invisible workload, expand access to expert-level thinking, and help women-led businesses grow faster - if women stay in the conversation and keep learning. Timestamps  00:00 — Susan introduces the 30-day podcast-to-book sprint and today's guest, Gazzy Amin 01:10 — The three types of entrepreneurs using AI (anti / curious / invested) 02:10 — AI as a thinking partner vs a task-doer 03:50 — Why most people don't yet grasp AI's full capability (and why curiosity matters) 05:00 — Using AI for personal life tasks as a low-pressure entry point 06:46 — Recession narratives, standing out, and using AI to challenge limiting beliefs 07:40 — "Create an AI per department" and train it for specific use cases 09:10 — The opportunity window: access to expertise that used to cost tens of thousands 10:10 — The 2025 audit: asking AI to interview you and pull out patterns 12:55 — Will AI devalue experts? Why the human layer still matters 16:45 — How AI changes your conversations with experts (you go deeper, faster) 18:20 — Mindset tools: music, movement, and protecting your "mental real estate" 21:00 — Documentation, playbooks, and why small teams need systems 24:00 — Training AI on your real sales process to improve onboarding + client experience 27:20 — Do AI-enabled businesses become more valuable? Scale, output, and leverage 30:00 — Why people default to content (and how to make AI content actually sound like you) 34:15 — Women, AI, the wage gap, and why this moment is non-negotiable 40:00 — Gazzy shares her CEO Growth Plan Intensives and how she uses AI in sessions 42:55 — Where to connect with Gazzy (Instagram + LinkedIn) Guest info Gazzy AminFounder, Sales Beyond Scripts Best place to connect: Instagram (behind-the-scenes and real-time business building) - https://www.instagram.com/authenticgazzy/ If you want to use AI to scale in 2026, start here: Run a 2025 audit with AI. Pick one department and ask AI how to improve that workflow. Document one process that currently lives only in your head.   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.

Quitter le développement pour le produit : comment naviguer cette transition sans perdre pied ?Passer de développeur à product manager est peut-être transition qui vous intéresse. Mais comment aborder ce virage professionnel sans tomber dans les pièges classiques ?Dans cet extrait, Tamara et moi partageons nos retours d'expérience sur ce parcours qui demande autant de lâcher-prise que d'adaptabilité.On parle notamment de :➡️ Pourquoi il ne faut pas voir cette transition comme un choix définitif et irréversible.➡️ Comment utiliser son background technique comme un atout tout en acceptant de ne plus avoir le dernier mot sur les décisions techniques. ➡️ Les stratégies concrètes pour effectuer cette transition en interne, plutôt que de chercher directement un poste externe.➡️ L'importance d'être transparent sur ses limites et de reconnaître quand on n'est plus à sa place.➡️ Quitter l'étiquette de "développeur" pour un rôle plus aligné avec ses forces.Bref, un épisode où on démystifie cette transition vers le rôle de product people.Si vous envisagez d'explorer le côté produit ou à la recherche de repères pour naviguer cette transition, cet extrait est fait pour vous.Retrouvez Tamara :Sur LinkedIn : https://www.linkedin.com/in/tamara-guilbertSur son podcats Tech Your Dream : https://linktr.ee/tamaraguilbertSi cet épisode vous a plu, pensez à laisser une note et un commentaire - c'est la meilleure façon de faire découvrir le podcast à d'autres personnes !Envoyez-moi une capture de cet avis (LinkedIn ou par mail à dx@donatienleon.com) et je vous enverrai une petite surprise en remerciement.

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

If you're measuring AI success by "hours saved" you're playing the easiest game in the room. In this episode, Host Susan Diaz explains why time saved is weak and sometimes harmful, then shares a better "AI ROI stack" with five metrics that map to real business value and help you build dashboards that actually persuade leadership.   Episode summary Time saved is fine. It's also table stakes. Susan breaks down why "we saved 200 hours" is the least persuasive AI metric, and why it can backfire by punishing your early adopters with more work. She then introduces a smarter approach: a set of five metrics that connect AI usage to quality, risk, growth, decision-making, and compounding capability. If you want your AI work funded, supported, and taken seriously, you need to move the conversation from cost to investment. This episode shows you how.   Key takeaways Time saved doesn't automatically convert to value. If no one reinvests the saved time, you just made busy work faster. Hours saved can punish high performers. Early adopters save time first. They often get "rewarded" with more work. Time saved misses the second-order benefits. AI's biggest wins often show up as fewer mistakes, better decisions, faster learning, and faster response to opportunity. Susan's "AI ROI stack" has five stronger metrics: Quality lift Is the output better? Track error rate, revision cycles, internal stakeholder satisfaction, customer satisfaction, and fewer rounds of revisions (e.g., proposals going from four rounds to two). Risk reduction AI can reduce risk, not only create it. Track compliance exceptions, security incidents tied to content/data handling, legal escalations/load, and "near misses" caught before becoming problems. Speed to opportunity Measure time from idea → first draft → customer touch. Track sales cycle speed, launch time, time to assemble POV/brief/competitive responses, and responsiveness to RFPs (the "game-changing" kind of speed). Decision velocity AI can reduce drag by improving clarity. Track time-to-decision in recurring meetings, stuck work/aging reports, decisions per cycle, and decision confidence. Learning velocity This is the compounding one. Track adoption curves, playbooks/workflows created per month, time from new capability introduced → used in production, and how many documented workflows are adopted by 10+ people. Dashboards should show three layers: Leading indicators (adoption, workflow usage, learning velocity). Operational indicators (cycle time). Business outcomes (pipeline influence, time to market, cost of service). You're not investing in AI to save hours. You're building a system that produces better work, faster, with lower risk, and gets smarter every month.   Timestamps 00:01 — "If you're measuring AI success by hours saved… that's table stakes." 00:51 — Why time saved doesn't translate cleanly into value 01:12 — Time saved doesn't become value unless reinvested 01:29 — Hours saved can punish high performers (they get more work) 02:10 — Time saved misses second-order benefits (mistakes, decisions, learning) 02:45 — Introducing the "AI ROI stack" (five better metrics) 02:59 — Metric 1: Quality lift (error rate, revision cycles, satisfaction) 03:31 — Example: proposal revisions drop from four rounds to two 04:14 — Metric 2: Risk reduction (compliance, incidents, legal load, near misses) 05:19 — Metric 3: Speed to opportunity (idea to customer touch, sales cycle, launches) 06:11 — Example: RFP response in 24 hours vs five days 06:34 — Metric 4: Decision velocity (time to decision, stuck work, confidence) 07:30 — Metric 5: Learning velocity (adoption curve, workflows, time to production) 08:57 — Dashboards: leading indicators vs lagging indicators 09:15 — Dashboards should include business outcomes (pipeline, time to market, cost) 09:32 — Reframe: AI as a system that improves monthly 10:08 — "Time saved is the doorway. Quality/risk/speed/decisions/learning is the house." 10:36 — Closing + review request   If your AI dashboard is only "hours saved" keep it - but don't stop there. Add one metric from the ROI stack this month. Start with quality lift or speed to opportunity. Then watch how fast the conversation shifts from cost to investment. 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.

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.

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

Host Susan Diaz sits down with Jennifer Hufnagel (Hufnagel Consulting), an AI educator and AI readiness consultant who's trained 4K+ people. They break down what "AI readiness" actually means (spoiler: it's not buying Copilot), why AI doesn't fix broken processes or dirty data, and how leaders can build real capability through training programs, communities of practice, and properly resourced AI champions. Episode summary Susan Diaz and Jennifer Hufnagel met in "the most elite way possible": both were quoted in The Globe and Mail about women and AI. Jennifer shares her background as a business analyst and digital adoption / L&D consultant, and how she pivoted when clients began asking for AI workshops right after ChatGPT's release. Together, they map a simple but powerful framework: AI awareness (practice + play, foundational learning, early change management) AI readiness (software stack, data quality, workflows, current state, and - quietly - the "people audit") AI adoption (implementation, strategy, and ongoing integration) Jennifer explains why "audit" language scares people, but the work is essential - especially talking to humans about what's frustrating, what takes time, and where fear is showing up. She shares what she's seeing after training thousands: AI fluency is still low, people obsess over tools, and many assume AI will solve problems that are actually process or data issues. The second half gets practical: what "workflows" really mean (step-by-step checklists), how AI now makes documenting processes easier than ever (voice → SOPs), why prompt engineering isn't dead but "100 prompts for your bookkeeping business" is mostly snake oil, and why one-off training sessions don't create real fluency. They close with how to build sustainable AI capability: proper training programs, leadership-led culture, communities of practice, and protecting champions from becoming unpaid help desks. Key takeaways AI readiness is the middle of the journey. Jennifer frames AI maturity as: awareness → readiness → adoption. Most organisations skip readiness and wonder why adoption stalls. Readiness includes software, data, process… and people. You can call it a software/data/process audit, but you still have to talk to humans about their day-to-day work, pain points, and fears. That's where the truth lives. AI fluency is still lower than the headlines suggest. Jennifer questions rosy "90% adoption" stats because many rooms she's in still show low real-world usage beyond basic experimentation. Stop obsessing over tools. Companies are writing AI policy around tools and forcing everyone into a single platform. Jennifer argues the real goal is discernment, critical thinking, and clarity - not "pick one tool and pray". AI doesn't fix broken processes or dirty data. If your workflows aren't documented, AI will scale the chaos. If your data is messy, the analysis will be messy too. Readiness comes first. A workflow is just a checklist. Jennifer demystifies "workflow" as step-by-step instructions and ownership: who does what, when. Sticky notes on a wall is a valid start. Process documentation is easier than ever. You can dictate steps into a model (without passwords) and ask it to produce an SOP/checklist - getting knowledge out of people's heads and into a shareable format. Prompting isn't dead, but promise-all prompt packs are mostly hype. Prompting differs by model, and the best move is often to ask the model how to prompt it - and how to troubleshoot when output is wrong. One-off AI workshops don't create fluency. AI changes too fast. Real capability requires programs, practice, communities of practice, office hours, and change management - plus leadership modelling and culture. Don't burn out your AI champions. Champions need dedicated time, resources, and leadership sponsorship. Otherwise they become unpaid AI help desks and the entire initiative becomes fragile. Community of practice is the unlock. Jennifer shares her in-person "AI Chats & Bites" group and encourages finding online + in-person + internal communities to keep learning alive. Episode highlights 00:01 — The 30-day podcast-to-book sprint and why people are saying yes in December 00:40 — Susan + Jennifer meet via The Globe and Mail "women and AI" feature 01:21 — Jennifer's origin story: business analyst → digital adoption/L&D → AI readiness 04:09 — The three-part framework: awareness → readiness → adoption 05:03 — Readiness: software stack, data quality ("dirty data"), and mapping current state 06:13 — "People audit" without calling it that: interview humans about pain + fear 08:02 — What Jennifer sees after ~4,000 trainees: fluency still low + stats don't match reality 09:38 — AI doesn't fix broken processes; it scales whatever is there 10:55 — Workflows explained as checklists; "won the lottery" handoff test 12:18 — Dictate your process into AI → generate SOPs/checklists 14:24 — Prompting isn't dead; ask the model to help you prompt + troubleshoot 17:50 — Why one-off training doesn't work; AI fluency requires a program + practice 22:15 — Burning out champions and why AI culture must be top-down 27:49 — Communities of practice: online + local + internal 31:00 — Common mistakes: vending-machine mindset, believing output, not defining the problem 35:31 — Women and AI: opportunity, fear, resilience, and "be in the grey" 39:51 — Where to find Jennifer: hufnagelconsulting.ca + LinkedIn Guest info Jennifer Hufnagel Website: hufnagelconsulting.ca Email: hello@hufnagelconsulting.ca Best place to connect: LinkedIn - Jennifer Hufnagel If AI adoption feels stuck in your organization, don't buy another tool first. Start with readiness: Map one workflow end-to-end. Talk to the humans doing it daily. Clean up the process and data enough that AI can actually help. Then build fluency through a program - not a one-off workshop - and protect your champions with real time and resources.   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.

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!

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.

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.

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

In this episode of the Co-Created Series, Erik Rivas, Head of Employer Brand and Recruitment Marketing at Police Now, reveals how building an efficient employee content engine - balanced with high-production content - drives authenticity, agility, and measurable ROI for their employer branding and recruitment marketing.The Core Message:It's not either/or - it's about balance. High-production content fills your campaigns and website with polish, while employee-generated content gives you the agility to experiment, pivot quickly, and capture authentic day-to-day realities. Together, they create an efficient content engine that maximises return on investment.Key Topics Covered:⚖️ The 50/50 balance: When to use high-production vs employee-generated content

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]

What if shipping a new language didn't mean months of risk, rework, and late surprises? We sit down with Senior Localization Manager at HiBob, Pavel Riazanov to unpack how he dismantled a monolithic process and rebuilt it around small, iterative batches, layering in AI in ways that actually improved control and quality.

Czy Twój zespół naprawdę dowozi to, co zaplanuje? A może się przyzwyczailiście do tego, że zrealizowany jest tylko ułamek planu na iterację? Rozkładamy na czynniki pierwsze przewidywalność zespołu. Miara ta może być potężnym wsparciem dla zespołu, ale i źródłem frustracji czy złych decyzji. Pokażemy Ci jak mierzyć ją w Jira, Excelu czy innych narzędziach. Podpowiemy też, jak interpretować wyniki, by realnie ustabilizować w zespole proces dowożenia zaplanowanego zakresu prac. Cała rozmowa odnosi się do case study z naszej pracy z jednym z zespołów. Jeśli masz już dość niewykonanych planów oraz ciągłych tłumaczeń, ten odcinek jest dla Ciebie. Porządny Agile · Przewidywalność zespołu Zapraszamy Cię do obejrzenia nagrania podcastu Transkrypcja podcastu „Przewidywalność zespołu” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu Porządny Agile. Jacek: Ostatnio na naszej stronie pojawiło się nowe case study. Dotyczy ono tego, jak w jednym z zespołów poprawiliśmy przewidywalność. Uznaliśmy z Kubą, że jest to dobra okazja, żeby powiedzieć trochę więcej o przewidywalności w ramach tego odcinka. Kuba: Adres case jest nie do przedyktowania w nagraniu audio, więc po prostu zachęcam Cię do tego, żeby znaleźć wspomniany case study w notatkach do odcinka i przeczytanie tego, co Jacek tam pisze. Jacek: Jaki spis treści na dzisiaj? Przede wszystkim zdefiniujemy, czym dla nas jest przewidywalność. Opowiemy, jak mierzyć przewidywalność. Podzielimy się wskazówkami na temat stosowania przewidywalności i na koniec damy kilka wskazówek, jak faktycznie, jakimi praktykami poprawić przewidywalność zespołu. Kuba: To przechodząc do rzeczy, pierwsza część to definicja przewidywalności. Przewidywalność rozumiemy to, jak zespół dowozi czy dostarcza to, co zaplanował. W jakim stopniu realizuje ten plan, który sobie przyjął? Czy, jak mówią, że coś będzie zrealizowane, czy to faktycznie będzie? Z jakim prawdopodobieństwem zespół realizuje swoje zamiary. Jacek: Więc jest to dla nas z jednej strony miara, o której powiemy za chwilę trochę więcej, bo można ją bardzo konkretnie wyrazić, a z drugiej strony, jak mówimy o tym, że zespół jest przewidywalny, to myślimy też w kontekście takim, że jest to pewna pożądana cecha zespołu. To jest taki zespół, na którym w kontekście tych prognoz, z którymi się dzielą z organizacją, można na nim polegać. Kuba: Dla równowagi powiemy też, czym nie jest przewidywalność według nas, choć niektórzy to też tak rozumieją. Niektórzy rozumieją przewidywalność jako pewną taką cechę generyczną rozumianą jako prawdopodobieństwo dostarczania, ale również prawdopodobieństwo o bardzo niskim stopniu albo o bardzo dużej zmienności tej wartości. W sensie, takim matematycznym, to też jest przewidywalność, tak samo jak smród jest zapachem albo jakiś brunatny też jest kolorem, ale jednak jako przewidywalność rozumiemy coś pozytywnego, zjawisko korzystne. W tym sensie nie cieszy nas fakt, że jakiś zespół ma przewidywalność, tylko ta przewidywalność to jest jedno zadanie na cztery zaplanowane albo 20% planu. W sensie matematycznym to jest przewidywalność, ale my się od takiej przewidywalności i takiego rozumienia tego słowa odcinamy, uważamy, że przewidywalność jest cechą czy charakterystyką pozytywną. Miarą, która powinna dążyć też do pewnych wartości. Zespół przewidywalny to taki, który dostarcza to, co planuje, a nie dostarcza tyle, ile zazwyczaj dostarcza. Nawet jeśli zazwyczaj dostarcza bardzo mało. Zespół, który przewidywalnie dostarcza mało, to jest dla nas zespół nieprzewidywalny, a nie przewidywalny w jakimś dziwnym znaczeniu. Jacek: To prowadzi nas do pytania, w jaki sposób możemy przeżyć przewidywalność. Ogólny wzór jest bardzo prosty. W dużym uproszczeniu jest to stosunek tego, co zostało faktycznie zrealizowane w konkretnym Sprincie czy w konkretnej iteracji w stosunku do tego, co było zaplanowane. Najczęściej jest to wyrażone po prostu w procentach. Kuba: Natomiast w szczegółach już może być trochę bogato. Różne zespoły uwzględniają do tego wzoru różne składowe elementy. Najprościej, gdy po prostu bierze się wszystko to, co zespół realizuje, niezależnie od tego, jakie typy pracy, jakie typy elementów planów wchodzą w skład danego Sprintu właśnie czy iteracji. Ale wiemy też i obserwujemy, i czasem ma to sens, że są zespoły, które liczą na przykład tylko historyjki użytkownika, storki, czy jakkolwiek to się w danym zespole nazywa. Czasem ficzery, czasem jakieś wyłącznie prace rozwojowe. Inne zespoły uwzględniają zadania czy jakiś rodzaj subtasków, jakaś praca techniczna do wykonania tego, co jest potrzebne do zrobienia w danym Sprincie. Kontrowersje mogą się zaczynać gdzieś w sferze tego, gdy się zaczyna liczyć do przewidywalności zaplanowane rozwiązania błędów, które wiemy, że istnieją, gdy zaczyna się Sprint, ale jest plan w zespole, żeby je rozwiązać. No i kontrowersją mogą być też zadania utrzymaniowe, czyli jakieś zadania powtarzalne, które z góry wiadomo, że trzeba zrealizować, no i choćby nie wiadomo, co się działo, to one po prostu faktycznie są częścią pracy w Sprincie. W ewentualnej kontrowersji głębiej się nie chcemy zagłębiać. Tutaj tylko jakby sygnalizuje, że jest temat, jakie typy pracy uwzględniać w mierze przewidywalności. No moim zdaniem jest tu temat do przemyślenia i bardzo świadomego zaplanowania czy do doprecyzowania, co jest uwzględnione we wzorze dla Twojego zespołu. Jacek: Może to jest dobry czas na taki prosty, namacalny przykład. Jeżeli zespół planował dostarczyć 10 elementów, nazwijmy to bardzo ogólnie, i dostarczył tylko dwa elementy, no to dla nas, patrząc na ten wzór przewidywalność, to jest 20%. Jeżeli planował dostarczyć 10, a dostarczył 5, no to przewidywalność jest 50%, natomiast jeśli planował dostarczyć 10, a dostarczył 12, to przewidywalność wynosi 120%. Tak więc przewidywalność jest miarą, w której ta wartość oczekiwana raczej jest pewnym zakresem. Takim dla nas powiedzmy akceptowalnym punktem do rozpoczęcia rozmowy, to jest przewidywalność między 80 a 120%. I bardziej chodzi nam o przebywanie w tym zakresie, niż osiąganie jakiegoś konkretnego, precyzyjnego wyniku. W szczególności powtarzalne osiąganie 100% może oczywiście wskazywać na to, że no ta miara być może za bardzo jest traktowana jako jakiś taki punkt do osiągnięcia. Z kolei o tym zakresie, który można nazwać, że jest powiedzmy zdrowy, można myśleć tak jak na przykład o wskaźnikach, kiedy idziemy na badanie krwi. Dostajemy wylistowaną listę, dostajemy poukładaną listę wyników i najczęściej jesteśmy w stanie znaleźć informacje, czy ta konkretna wartość zbadania jest w normie, czy mieści się w jakimś tam spodziewanym zakresie. I bardzo podobnie, właściwie można powiedzieć, wręcz identycznie działa to w przypadku przewidywalności. Kuba: Jeśli chodzi o przewidywalność, warto też wspomnieć to, jak narzędziowo można to mierzyć, jak można to liczyć, czyli jak konkretnie w narzędziu, jakim sposobem to zrealizować. Jest kilka opcji, wymienimy cztery. Jacek: Tak, pierwsze narzędzie takie, no, najczęściej nadal spotykane przez nas w organizacjach, to jest JIRA. Należałoby się skierować do sekcji raportów i znaleźć tam w wersji anglojęzycznej Velocity Chart i na tym wykresie oprócz tej informacji, ile faktycznie zespół zrealizował, czyli jaka jest prędkość zespołu, no, można również znaleźć tę informację o tym, ile na dany Sprint zostało zaplanowane. Te dane, te wykresy powinny się właściwie same wyświetlić, jeśli tylko przestrzegasz jakiejś takiej podstawowej higieny pracy w JIRA. To znaczy faktycznie uruchamiane są Sprinty. We właściwych momentach takich prawdziwych, kiedy zaczyna się Sprint, to ten Sprint jest startowany, powinien też być zamykany faktycznie wtedy, kiedy Sprint się kończy. Sprint powinien zawierać w sobie tę faktycznie wykonywaną pracę. Jak również pewna taka otoczka dotycząca tego boardu, na którym się znajdujemy, czy projektu, który realizujemy, te rzeczy też powinny być poprawnie skonfigurowane, no i wtedy można powiedzieć, że ten wykres dostajemy z pudełka. Właściwie nic nie musimy dodatkowego zrobić, żeby móc zobaczyć sobie historycznie, jak ta przewidywalność się w naszym zespole układała. Kuba: Drugą opcją narzędziową jest po prostu Excel. W porównaniu do JIRA, Excel stanie się, czy jest o wiele bardziej elastyczny, co prawda nie budują się dane same, jak w JIRA. Jeśli dobrze zachować tą dyscyplinę, o której mówi Jacek, no to JIRA liczy to sama, no w Excelu siłą rzeczy, ktoś odpowiedzialny za proces, albo członek zespołu, albo jakiś jego rodzaj lidera, po prostu musi te dane do tego Excela wprowadzić. Pamiętać o tym, żeby je przepisać, żeby złapać te dane historyczne bazowe i też pewnie w odpowiednie formuły wprowadzić te dane, żeby pokazały pewien wynik. Jest to oczywiście praca trochę ręczna, ale za to po drugiej stronie, zwłaszcza gdyby zespół miał jakąś bardziej skomplikowaną sytuację, albo bardziej wysublimowane warunki, co uwzględniać, czego nie uwzględniać, no to może się okazać, że ten Excel jest bardziej wiarygodny i pod większą kontrolą, niż narzędzia, które biorą po prostu wynik jakiegoś filtru lub nie są tak dobrze prowadzone. Jacek: Innymi narzędziami mogą być wszelkiego rodzaju narzędzia, które pomagają nam wizualizować pracę i pewne koncepcje z nią związaną. Czyli z jednej strony w warunkach online’owych to może być jakiś Mural czy Miro. W warunkach stacjonarnych to może być tablica, flipchart czy nawet wręcz kartka papieru. Tak naprawdę istotne jest, żeby te dane się znalazły w tych miejscach, wokół których będziemy się skupiać jako zespół. Na bazie moich doświadczeń bardzo często zespoły pracujące online dokonują refleksji na przykład na Muralu. No i w takim przypadku śledzenie tych informacji procesowych w kontekście tego odcinka, mówię tutaj w szczególności o przewidywalności, może być takim naturalnym miejscem, na które i tak spojrzymy w momencie, kiedy będziemy realizować cotygodniową czy co dwutygodniową refleksję. Tak więc posiadając komplet informacji w miejscu, do którego i tak rutynowo zaglądamy, drastycznie zwiększa szanse, że na te dane spojrzymy i zastanowimy się co z tych informacji, które posiadamy płynie, jakie wnioski do zespołu. Kuba: Ostatnią opcją, którą wymienimy, jeśli chodzi o narzędziowe pokazanie, mierzenie i uwidacznianie przewidywalności to są narzędzia BI-owe. W kilku organizacjach niezależnie od siebie widziałem taki efekt podłączenia bazy danych. Najczęściej pod spodem była jakaś JIRA, może Azure DevOps, albo tego typu narzędzia do mierzenia zadań, pokazywania tych zadań, kończenia ich. Dane surowe z takich narzędzi można przerzucić do narzędzi BI-owych. Czy to jest Power BI, czy to jest Tablo, czy to jest jeszcze coś innego. Kilka narzędzi różnie popularnych w różnych organizacjach. Oczywiście wymaga to już pewnych konkretnych kompetencji, żeby to wszystko podłączyć, żeby też być może odpowiednio skonfigurować raporty. No potencjalnie po stronie nagrody jest dosyć atrakcyjny sposób wizualizacji, być może sposób też jakiejś konfiguracji dodatkowego filtrowania dodatkowego, może dokładania kolejnych danych. W kontekście dużej organizacji wartością w sobie samo może być też pokazanie na jednym dash-boardzie wyników wielu zespołów, czy może pewien rodzaj standaryzacji pomiędzy zespołami, jakie aspekty są tam odpowiednio uwzględniane. Potencjalnie nagroda wielka, no ale tak jak wspomniałem też potencjalnie pewien koszt. Jeśli ma się te kompetencje w zespole, to może ten koszt jest siłą rzeczy pomijalny, a czasami warto to zainwestować, żeby dostać wartościowe widoki, czy wartościowe mierniki. Kuba: Ostatnią opcją, którą wymienimy, jeśli chodzi o narzędziowe pokazanie, mierzenie i uwidacznianie przewidywalności to są narzędzia BI-owe. W kilku organizacjach niezależnie od siebie widziałem taki efekt podłączenia bazy danych. Najczęściej pod spodem była jakaś JIRA, może Azure DevOps, albo tego typu narzędzia do mierzenia zadań, pokazywania tych zadań, kończenia ich. Dane surowe z takich narzędzi można przerzucić do narzędzi BI-owych. Czy to jest Power BI, czy to jest Tablo, czy to jest jeszcze coś innego? Kilka narzędzi różnie popularnych w różnych organizacjach. Oczywiście wymaga to już pewnych konkretnych kompetencji, żeby to wszystko podłączyć, żeby też być może odpowiednio skonfigurować raporty. No potencjalnie po stronie nagrody jest dosyć atrakcyjny sposób wizualizacji, być może sposób też jakiejś konfiguracji dodatkowego filtrowania dodatkowego, może dokładania kolejnych danych. W kontekście dużej organizacji wartością w sobie samo może być też pokazanie na jednym dash-boardzie wyników wielu zespołów, czy może pewien rodzaj standaryzacji pomiędzy zespołami, jakie aspekty są tam odpowiednio uwzględniane. Potencjalnie nagroda wielka, no ale tak jak wspomniałem też potencjalnie pewien koszt. Jeśli ma się te kompetencje w zespole, to może ten koszt jest siłą rzeczy pomijalny, a czasami warto to zainwestować, żeby dostać wartościowe widoki, czy wartościowe mierniki. Kuba: I zanim przejdziemy do następnego rozdziału, przypominamy, że jeżeli chcesz pogłębić wiedzę, jeszcze bardziej niż robimy to w podcaście, to znajdziesz nasze płatne produkty na stronie porzadnyagile.pl/sklep. Jacek: Przechodzimy do kolejnej sekcji dzisiejszego odcinka, czyli kilka wskazówek na temat tego, jak stosować miary przewidywalności w praktyce. Kuba: Pierwsza rzecz, od której chcę zacząć, to uwzględnij stopień innowacyjności zespołu. Przewidywalność jako miara w typowym zespole wytwórczym powinna być mierzona. To jest też cecha, którą taki zespół powinien posiadać. Natomiast mamy w swoim doświadczeniu kilka przykładów takich zespołów, które są naprawdę mocno innowacyjne, robią zadania takie mocno polegające na jakimś rodzaju research and development, jakimś badaniu, jakimś odkrywaniu, w takim stopniu innowacyjności naprawdę dużym. Te zespoły siłą rzeczy z racji na taką dużą chaotyczność czy dużą złożoność swojej pracy badawczej, po prostu tej przewidywalności osiągnąć nie za bardzo mogą, w takim znaczeniu, o jakim mówimy w tym odcinku. Dlatego tutaj bierzemy taką poprawkę, może taką dokładamy gwiazdkę do przewidywalności. W wybranej organizacji to niektóre zespoły będą siłą rzeczy nieprzewidywalne, w których firmach może w ogóle wszystkie, bo taka jest natura produktu czy branży, w której się działa, więc może wziąć warto poprawkę na to, że nie we wszystkich zespołach, nie we wszystkich firmach ta przewidywalność, o której dzisiaj powiedzieliśmy i jeszcze będziemy mówić, jest adekwatna, czy jest miarą, na którą warto spoglądać. Jacek: Jednocześnie przy tej okazji warto zwrócić uwagę na taki pewien ewenement, który obserwujemy z Kubą, że wiele zespołów wpada w poczucie, że są właśnie takim bardzo wyjątkowym i innowacyjnym zespołem, który ze względu na naturę swojej pracy nie jest w stanie pracować w przewidywalny sposób i nasze doświadczenie jest takie, że raczej nie do końca jest tak na takiej zasadzie, że faktycznie takie zespoły spotykamy, ale tych zespołów jest zdecydowania mniejszość. Nawet jeśli to faktycznie jest ten research, o którym wspominał Kuba, takie działania też można planować, można dzielić je na mniejsze kroki, bardzo precyzyjnie sobie określać kryteria akceptacji. I też w miarę w uporządkowany sposób decydować, czy to, co zaplanowaliśmy sobie zrobić, niekoniecznie te uzyskane rezultaty, ale tę pracę wykonaną, którą planowaliśmy, jesteśmy w stanie zaplanować. Raczej większość zespołów tę pracę, którą wykonuje ona, ma najczęściej jednak charakter taki, że jesteśmy w stanie przewidzieć, co będziemy realizować. Więc tutaj chcemy z Kubą wyraźnie zaznaczyć taką potencjalną pułapkę, żeby dokonać faktycznej refleksji, czy rzeczywiście ta nasza praca nosi znamiona takiej absolutnie niezarządzalnej, nieprzewidywalnej, czy tylko wpadliśmy w tę pułapkę, że tak o tej pracy myślimy. Jacek: Druga wskazówka, świadomie wybierz zmienne do wzoru. Wspomnieliśmy, jak taki wzór mógłby wyglądać, wspomnieliśmy, w jakiej jednostce wyrażony jest wynik. Taką główną wątpliwością osób, które podchodzą do tematu przewidywalności, jest wybór tego, czy powinniśmy patrzeć na konkretne elementy, które posiadamy jako zakres w danym konkretnym Sprincie, czy iteracji, czy raczej powinniśmy patrzeć na sumę story pointów I o ile historycznie pierwsze próby mierzenia się z przewidywalnością kierowały nas z Kubą w stronę story pointów, no to dzisiaj zdecydowanie jest nam bliżej do tego, żeby raczej patrzeć na tę liczbę elementów, które bierzemy do Sprintu. Konkretnie w Jirze można sobie przestawić wykres, ustawić go na to, żeby pokazywał issue count, czyli żeby po prostu policzył nam tę liczbę elementów, którą mamy w Sprincie. No i generalnie zbliża nas to do myślenia bardziej o patrzeniu i mierzeniu przepustowości i przewidywalności na tej bazie, niż na takie klasyczne Velocity, które najczęściej wyrażane jest jako suma story pointów zaplanowanych na konkretny Sprint. Kuba: Dlaczego poświęcamy na to czas w tym nagraniu? Bo wiele zespołów poświęca niepotrzebnie czas na przykład szczegółowy wycenianie, bo inaczej nie będzie pewien element uwzględniony we wzorze, a po wszystkim zwłaszcza też niezależne próby to potwierdzają w wielu zespołach, w wielu firmach korelacja między ilością skończonych elementów a story pointami zakończonymi jest na tyle silna, że w zasadzie nie ma potrzeby wkładać dodatkowej energii w to, żeby nawyceniać wszystkie prace. Zwłaszcza jeśli ma to prowadzić do, no naszym zdaniem, absurdów takich jak wycenianie błędów czy wycenianie jakichś zadań technicznych, tylko po to, żeby one się później ładnie w słupki sumowały. Może się okazać, że prosta suma ilości elementów jakichkolwiek, które uwzględniamy w takim predictability po prostu są do wzięcia i tyle, to jest dosyć łatwe, łatwo mechanicznie wyliczyć taki wzór i po prostu niepotrzebnie nie wkładać dodatkowej energii w coś, co nie wniesie dodatkowej wartości. I zaakcentuję, czy może tak trochę refrenem powtórzę to, co powiedział Jacek, niestety domyślnie Jira pokazuje, a Jira jest też najbardziej popularnym narzędziem z tego, co widzimy, pokazuje właśnie po story pointach, co może oznaczać, że nie uwzględnia rzeczy niewycenionych do tego typu wzorów na przewidywalność, no i z drugiej strony właśnie trochę miesza w przewidywalności, jeśli zespół cierpi na zadania przechodzące między Sprintami. Jeśli zespół właśnie uwzględnia w swoich działaniach również elementy, które są niewyceniane, więc tutaj domyślny sposób pokazania przewidywalności mierzonej w story pointach może być pewną pułapką, stąd wskazówka świadomie wybierz zmienne do wzoru. Kuba: Trzecia wskazówka to traktuj przewidywalność jako wewnętrzny kompas zespołu. Dużo nieszczęścia dzieje się w organizacjach, w których zostaje się celem. Jacek już to lekko zaznaczył, ja to wzmocnię. Są organizacje, które wręcz żądają, domagają się, zostawiają w celach rocznych, uzależniają premię od tego, czy zespół będzie przewidywalny, ustawiając też konkretne oczekiwane wartości. Najczęściej spotykam, że wartością oczekiwaną jest dokładnie 100%, czyli róbcie dokładnie tyle, ile planujecie, to poprowadzi do pewnych pułapek, ale znam też organizację, w której oczekiwana wartość przewidywalności to jest nie powinna przekraczać powiedzmy 80%. Czyli przewidywalny zespół to taki, który w przewidywalny sposób zawsze trochę nie dowozi. Też nie najszczęśliwszy pomysł. Więc tutaj mocno opieramy się na pomyśle, że przewidywalność to jest raczej miara wewnętrzna do mierzenia procesu przez zespół, do traktowania go jako punkt odniesienia przy usprawnianiu się, do myślenia o nim w czasie planowania, myślenia o nim w czasie Retrospektyw, myślenia o nim w jakimś tam dłuższym horyzoncie, ale na pewno nie jako sposób czy podstawa do tego, żeby dostać nagrodę albo karę, bo siłą rzeczy, zresztą jak każda inna miara tego typu, może się to łatwo przeinaczyć czy wręcz wypaczyć, stać się celem samym w sobie zamiast wiarygodną podstawą do usprawniania. Jacek: I czwarta porada, nie polegaj wyłącznie na przewidywalności. Tutaj zdecydowanie rekomendujemy, żeby przewidywalność nie była jedyną miarą procesu, którą zespół monitoruje. Dobrze jest od czegoś zacząć, ale zdecydowanie nie spoczywałbym tutaj na laurach. Przykładowo jednocześnie warto spojrzeć na throughput, czyli na przepustowość. Można do tego dołożyć sobie jakąś miarę jakości, można dołożyć jakąś miarę wartości biznesowej. To, co jest dla nas w danym momencie istotne i to, na co chcemy zwracać uwagę i wtedy patrzeć na pewien zestaw miar. Patrzeć jak one się wzajemnie zachowują. Może być tak, że poprawa jednej konkretnej miary może pogarszać wyniki w drugiej. Warto na to zwrócić uwagę i tak sobie skonfigurować te miary, żebyśmy mieli taki dosyć pełny obraz tego, jaka jest kondycja naszego zespołu i jego otoczenia. Kuba: I ostatni rozdział. Jak poprawiać przewidywalność zespołu? Ten rozdział będzie krótki, bo tak naprawdę to, co poprawia przewidywalność było tematem masy z poprzednich odcinków. My w zasadzie sami się z Jackiem zaśmialiśmy, że tak późno z naszej strony odcinek o przewidywalności w czasie, gdy mnóstwo praktyk poprawy przewidywalności już było przez nas poruszonych. Więc tutaj nie będziemy pogłębiać tematu, co dokładnie oznacza dana praktyka. Raczej potraktuj tę zawartość tego jako pewnego rodzaju spis treści czy nasze rekomendowane tak dokładnie osiem praktyk poprawy przewidywalności. Jeśli które z nich brzmi dla Ciebie intrygująco albo coś, czego jeszcze nie stosujesz, to po prostu odsyłamy Cię do materiałów, które też zamieszczamy w opisie odcinka. Jacek: Ok, czyli jakie praktyki zastosować, żeby poprawić przewidywalność zespołu? Kuba: Przede wszystkim zacznij kończyć, skończ zaczynać. Stosuj krótkie Sprinty. Wzmacniaj odpowiedzialność zespołu za produkt i dziel pracę na mniejsze kawałki. Jacek: Dodatkowo planuj zespołowo, zarządzaj zależnościami zewnętrznymi, traktuj codzienny stand-up jako bezpiecznik i usprawniaj się w oparciu o miary dostarczania produktu. Kuba: Wszystkie wymienione koncepcje, tak jak powiedziałem, znajdziesz w naszych starszych odcinkach, które linkujemy w opisie odcinka i na stronie tego odcinka porzadnyagile.pl/140 Jacek: Przewidywalność to miara i jednocześnie pożądana cecha zespołu, który realizuje zakres pracy, jaki sobie zaplanował na Sprint. Najczęściej przewidywalność podaje się w procentach jako stosunek liczby elementów faktycznie zrealizowanych do liczby elementów pierwotnie zaplanowanych. Kuba: Przewidywalność jest miarą, której wartość oczekiwana jest zakresem. Naszym zdaniem powinna mieścić się zazwyczaj między 80 a 120 procent. Istnieje szereg praktyk wspierających przewidywalność zespołu i zachęcamy do ich zastosowania w Twoim zespole. Jacek: Przyczyny braku przewidywalności w danym zespole mogą oczywiście być różne. Jako doświadczenie eksperci dołączamy do zespołu lub wskazanej części firmy i jasno je wskazujemy wraz z rekomendacjami sposobów, aby zmienić proces wytwórczy tak, by przewidywalność faktycznie rosła. Sprawdź naszą propozycję na stronie 202procent.pl/diagnoza. Kuba: A notatki do tego odcinka, artykuł, transkrypcję, wspomniane linki do innych rekomendowanych materiałów oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/140. Jacek: I to by było wszystko na dzisiaj. Dzięki Kuba. Kuba: Dzięki Jacek. I do usłyszenia wkrótce. ________ To była pełna transkrypcja odcinka podcastu Porządny Agile. Dziękujemy za lekturę! The post Przewidywalność zespołu first appeared on Porządny Agile.

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

Welcome to another episode of Our Agile Tales, Navigating World Crises: The Agile-Law-AI Alliance in Action!In this episode, we continue our conversation with Ondřej Dvořák, CEO of Agile Lawyer and COP Solutions, and co-founder of LinkingHelp. Building on his experience supporting Ukrainian refugees, Ondřej shares how Agile practices like Scrum and Kanban made it possible to coordinate large-scale, cross-border legal aid while respecting privacy and professional responsibility.We explore how visibility and transparency enabled fast action without exposing sensitive data, why government funding often moves too slowly for crisis response, and how donation-driven initiatives struggle once a crisis becomes the “new normal.” Ondřej argues that sustainable humanitarian work must blend social impact with viable business models.The conversation also dives into AI in legal services—not as a silver bullet, but as an accelerator that only works once processes, data, and transparency are in place. We discuss why AI should assist lawyers rather than replace them, the data-protection concerns slowing adoption, and what the future holds for agile, AI-assisted law firms.Episode Outline00:00 Introduction to Agile Tales00:53 Agility in Humanitarian Efforts02:12 Transparency and Visibility in Legal Aid03:55 Challenges with Government Bureaucracy05:39 LinkingHelp's Broader Impact07:53 AI's Role in Legal Services11:11 Future of AI and Agile in Law22:07 Key Takeaways and Advice23:43 Conclusion About Ondrej DvorakOndřej is the co-founder of Linking Help, a nonprofit that mobilized legal aid for Ukrainian refugees using Scrum and Kanban to coordinate real-time support. It's a powerful story of how agility can make a real difference in humanitarian crises—far beyond the domain of business. Andre's work shows how Agile thinking can help even the most traditional sectors become more humane, responsive, and resilient. You can follow Ondřej on LinkedIn at https://www.linkedin.com/in/ondrej-dvorak-agile/Visit us at https://www.ouragiletales.com/about

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.  

I figured it was about time I addressed this one. You can’t breathe without taking in some serious AI hype right now. How much is fluff and smoke, and how much is real? AND…how will this apply to Agile? Will AI Save Agile? Great question. I have a few gut-level reactions to this. First, I think there’s a gold-rush feel to what’s going on right now. With any new technology, especially the monumental ones, there’s always speculation that this ‘changes the game forever’. But that can’t always be true. On the one hand, AI has a lot of issues. But its early stages. I think the biggest threat is the unbridled greed that goes with mass adoption. Who’s regulating the copyrights of the material AI is trained on? Who makes sure that AI doesn’t recommend or do dangerous or immoral things? But the big question I have is “why would you want so much stuff created by robots?” I can’t articulate why, but I know I don’t want to read a book or watch a play written and mounted by robots. And hey, if LLM’s need our inventions to grow, learn and innovate, what happens when we no longer create ‘things’? AI’s Role in Agility As of this writing, so much of the conversation is about using AI to take the rote tasks out of a Scrum Master’s day…preparing reports or briefs, summarizing retrospectives, and writing user stories. But there’s also discussion that maybe AI can replace Scrum Masters and Coaches. That’s a little scary for those of us who hold or want to occupy these roles in the future. So maybe someday AI can plan our sprints, produce empirical estimates, and even hold coaching conversations. But Will AI Save Agile? That supposes that the solution to all of our current Agile pains have a known solution. After all, we can’t code or teach things that we have no certain knowledge of. And until we do, it would impossible for AI to magically fix what’s wrong with Agile in 2026. That’s still very much a human concern. Stay tuned – I’ll be exporing more about AI’s role in the future of Agile in some upcoming episodes as I learn more… **THE ALL NEW FORGE LIGHTNING** 12 Weeks to elite leadership! https://learning.fusechamber.com/forge-lightning **CREATE A PROFITABLE BUSINESS FROM YOUR AGILE SKILLS WITH FORGE GENESIS** Everything you need to ideate, validate, market, and sell to enterprise OR consumers. https://learning.fusechamber.com/the-forge-genesis **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 episode, you should check out: Episode 240 – Why Big Agile Fails Non-Conformity is the Key To Your Agile Future Episode 151 – What's Next?

In this episode, Avanish and Antonio discuss:BBVA's data transformation journey, including the strategic decision in 2017 to create a global data function at the executive committee level reporting to the CEO and ChairmanBuilding hybrid data architecture combining centralized lake house (AWS) with data mesh approaches to balance agility and control across global operations in regulated environmentsThe "eight robots" framework—a top-down AI transformation agenda targeting the most critical parts of BBVA's value chain, from digital client relationships to banker productivity to risk underwritingHow BBVA defines data democratization as "responsible access" not "open access," implementing strict governance while enabling self-service analytics in a highly regulated industryReal-world AI impact: solutions reducing tasks from 11 minutes to less than 1 minute, generative assistant "Blue" serving 20+ million clients in Spain and Mexico, and IVR improvements saving minutes to secondsThe partnership and ecosystem strategy leveraging enterprise-focused innovation through AWS, OpenAI, Google Gemini, and vertical solution providers to increase speed of learning and innovationWhy the "mode in this cycle is learning—how fast you can learn, how fast you can test hypotheses"—embracing experimentation and continuous improvement as models rapidly evolveAntonio's vision for the future: using AI and data to expand bankarization globally, serving underserved populations and fueling economic growth for families and businessesAbout the host:Avanish Sahai is a Tidemark Fellow and served as a Board Member of Hubspot from 2018 to 2023; he currently serves on the boards of Birdie.ai, Flywl.com and Meta.com.br as well as a few non-profits and educational boards. Previously, Avanish served as the vice president, ISV and Apps partner ecosystem of Google from 2019 until 2021. From 2016 to 2019, he served as the global vice president, ISV and Technology alliances at ServiceNow.  From 2014 to 2015, he was the senior vice president and chief product officer at Demandbase.  Prior to Demandbase, Avanish built and led the Appexchange platform ecosystem team at Salesforce, and was an executive at Oracle and McKinsey & Company, as well as various early to mid-stage startups in Silicon Valley.About Antonio Bravo, Global Head of Data at BBVAAntonio started his career in 2009 as a consultant focused in Technology, Media and Telecom. There he had the opportunity to learn how (mobile) internet growth blurs barriers between different industries and makes them converge. One of those industries is finance. He joined BBVA in 2011 to be part of its transformation strategy, and since then he has had different jobs. Started working in the Strategy & M&A area, with focus on the BBVA Ventures team (today Propel) investing in fintech startups, continued with a role in Digital Banking Strategy team, and later in 2015 assumed the responsibility of Business Development in South America (Argentina, Chile, Colombia, Perú, Venezuela, Uruguay and Paraguay).He also held the responsibility of Agile Organization until July 2019, focused in scaling the Agile methodology through-out the entire organization, more than 33.000 people including holding and countries, to improve quality, time to market, productivity and team engagement.From July 2019 until September 2021 he held the responsibility of IT Strategy & Control within BBVA, a function that manages some of the core IT functions at a global level, such as IT strategy, finance, vendor management, PMO, first line of defense and IT spin-offs.Since September 2021 he holds the position of Head of Sustainability Strategy & Business Development, where he contributes to the design of the strategic plan for all segments and manages investment in descarbonization funds. In January 2024 he was also appointed as Head of Corporate and Investment Banking Strategy, Industrial client coverage and cross border business.In January 2025 was appointed Global Head of Data at BBVA. Antonio is responsible of leading the transformation of the Group towards a data-driven company.About BBVA:BBVA is a global financial services group founded in 1857. The bank is present in more than 25 countries, has a strong leadership position in the Spanish market, is the largest financial institution in Mexico and it has leading franchises in South America and Turkey. In the United States, BBVA also has a significant investment, transactional, and capital markets banking business.BBVA contributes with its activity to the progress and welfare of all its stakeholders: shareholders, clients, employees, providers and society in general. In this regard, BBVA supports families, entrepreneurs and companies in their plans, and helps them to take advantage of the opportunities provided by innovation and technology. Likewise, BBVA offers its customers a unique value proposition, leveraged on technology and data, helping them improve their financial health with personalized information on financial decision-making.About TidemarkTidemark is a venture capital firm, foundation, and community built to serve category-leading technology companies as they scale.  Tidemark was founded in 2021 by David Yuan, who has been investing, advising, and building technology companies for over 20 years.  Learn more at www.tidemarkcap.com.LinksFollow our host, Avanish SahaiLearn more about Tidemark

AI is transforming software development—redefining roles, creativity, and community, while challenging developers to embrace ambiguity, orchestrate specialized agents, and stay human through empathy and curiosity. Will AI make developers more creative, or will we forget how the machine really works under the hood?This week Dave, Esmee , Rob sit down with Scott Hanselman, VP Developer Community at Microsoft for a wildly energetic, deeply human, and brilliantly practical conversation about how AI is reshaping software development and what that means for creativity, careers, and all industries. TLDR00:30 – Scott Hanselman introduced as a special guest from Microsoft Ignite 2025.02:16 – Scott discusses how AI is fundamentally redesigning all industries.09:50 – Don't anthropomorphize AI, I want the computer from Star Trek!15:30 – Delegation: contrasting the roles of humans and agents.18:30 – The importance of supporting early career growth and learning.26:30 – Why specificity matters in AI and coding.35:30 – Making AI delightful and fun.45:30 – Always put humans first in AI development.46:00 – Each morning I think about lunch. GuestScott Hanselman: https://www.hanselman.com/The Hanselminutes Podcast: https://www.hanselman.com/podcasts with over 1025 podcasts! 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/ 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

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.

What can Agile leaders learn from the Marines? In this episode, Tanner Wortham joins Brian to share how principles of military leadership—like building authority into the trenches, experimenting under pressure, and prioritizing shared mission over ego—map surprisingly well to modern Agile teams.

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

BONUS: Impact Engineering—Finding Agile's Lost North Star With Tom Gilb and Simon Holzapfel The Clarity Problem: Why Organizations Start with "Fuzzy B*S*!" "Everybody seems to start from a position of fuzzy b*s*. Nice-sounding words. Management does it, professors do it, politicians do it. And they don't even feel very guilty about it."   Tom Gilb doesn't mince words when describing how most organizations define their objectives. The fundamental problem isn't a lack of ambition—it's a lack of clarity. When leaders are asked about their critical values like "extremely high security" or "employee happiness," they typically respond with circular definitions that provide no actionable direction. Tom's approach starts by exposing this gap and then demonstrating that any value—no matter how "soft" or intangible it seems—can be quantified. Using AI tools, he's shown clients over 1,400 different ways to measure human happiness alone. Why Agile Lost Its North Star "Agile's lost its North Star because the economic problems it was trying to solve within the organization are now mismatched with the digital world."   Simon Holzapfel offers a structural analysis: Agile developed primarily to allay the concerns of pre-digital capital—investors who needed reassurance that their money wouldn't disappear into failed projects. But today's digital economy operates differently. Capital now moves like a service (SaaS model), and innovation is fundamentally stochastic—you can't predict when breakthroughs will happen. Organizations using flow-focused tools when the real problem is value creation are applying yesterday's solutions to today's challenges. The First Step: Quantify Your Critical Values "If you ask AI to quantify employee happiness a hundred different ways, it will do it in one minute for free. So you can no longer be in denial."   The path forward starts with brutal honesty about what your organization actually cares about. Tom's approach involves:   Identifying the top 10 critical stakeholder values Defining clear scales of measure for each Establishing where you are now (status) Setting where you need to be to survive (tolerable level) Defining what success looks like (target/goal level)   This isn't about adding bureaucracy—it's about creating shared clarity that enables everyone to row in the same direction.   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.

Sprint Planning or Sprint Guessing?Welcome to sprint planning — that magical 90-minute meeting (that always becomes 3 hours) where:Developers turn into psychicsProduct managers become game show hostsProduct owners stare into a backlog like it's a crystal ballSound familiar?For many Agile teams, sprint planning isn't the crisp, focused ritual described in books. It's often more ambiguous, chaotic, and filled with guessing than anyone wants to admit.So… are you really planning? Or just giving your best estimate in a business suit?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/