POPULARITY
Categories
Steve Martin: Making Scrum Master Success Visible with OKRs That Actually Work Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "It is not the retrospective that is the success of the retrospective. It is the ownership and accountability where you take improvements after the session." - Steve Martin The biggest problem for Scrum Masters isn't just defining success—it's being able to shout it from the rooftops with tangible evidence. Steve champions OKRs as an amazing way to define and measure success, but with a critical caveat: they've historically been poorly written and implemented in dark rooms by executives, then cascaded down to teams who never bought in. Steve's approach is radically different. Create OKRs collectively with the team, stakeholders, and end users. Start by focusing on the pain—what problems or pain points do customers, users, and stakeholders actually experience? Make the objective the goal to solve that problem, then define how to measure progress with key results. When everyone is bought in—Scrum Master, engineers, Product Owner, stakeholders, leaders—all pulling in the same direction, magic happens. Make progress visible on the wall like a speedometer, showing exactly where you are at any moment. For an e-commerce checkout, the problem might be too many steps. The objective: reduce pain for users checking out quickly. The baseline: 15 steps today. The target: 5 clicks in three months. Everyone can see the dial moving. Everything should focus on the customer as the endpoint. The challenge is distinguishing between targets imposed from above ("increase sales by 10%") and objectives created collaboratively based on factors the team can actually control. Find what you can control first, work with customers to understand their pain, and start from there. Self-reflection Question: Can you articulate your team's success with specific, measurable outcomes that everyone—from developers to executives—understands and owns? Featured Retrospective Format for the Week: Post-Retro Actions and Ownership The success of a retrospective isn't the retrospective itself—it's what happens after. Steve emphasizes that ownership and accountability matter more than the format of the session. Take improvements from the retrospective and bring them into the sprint as user stories with clear structure: this is the problem, how we'll solve it, and how we'll measure impact. Assign collective ownership—not just a single person, but the whole team owns the improvement. Then bring improvements into the demo so the team showcases what changed. This creates cultural transformation: the team themselves want to bring improvements, not just because the Scrum Master pushed them. For ongoing impediments, conduct root cause analysis. Create a system to escalate issues beyond the team's control—make these visible on another board or with the leadership team. Find peers in pain: teams with the same problems can work together collectively. The retrospective format matters less than this system of ownership, action, measurement, and visibility. Stop retrospective theatre—going through the motions without taking action. Make improvements real by treating them like any other work: visible, measured, owned, and demonstrated. [The Scrum Master Toolbox Podcast Recommends]
Steve Martin: Why Agile Fatigue Means We Need to Change Our Approach Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "We teach transformation, we support transformation, we help change, but we don't really understand what they're changing from." - Steve Martin Steve believes Agile as a whole is on the back foot, possibly regressing. There's palpable fatigue in the industry, and transformation in its current form hasn't been the success we hoped. Organizations still need to work in a state of agility—making rapid decisions, aligning teams, delivering value at pace—but they're exhausted by how we've implemented Agile. As Agile professionals, Steve argues, we have a responsibility to take stock and reflect on what's not working. The problem isn't that organizations don't need agility; it's that we've been force-feeding them frameworks without understanding their context. Steve invokes an ancient principle: "When the student is ready, the teacher will appear." But we haven't waited for readiness—we've barged in with Big Bang transformations, bringing 10, 15, or 20 Agile coaches to "save the world." The solution requires meeting people where they are, understanding what they're changing from, not just what they're changing to. Steve's coaching conversation centers on a radical idea: stop trying to help teams that don't want to be helped. Focus on teams already interested in incremental, adaptable delivery. Run small pilots, learn what works, then scale when ready. The age of prescriptive transformation is over. We need to adapt to the reality of the moment, experiment with what works, and have the courage to change the plan when our approach isn't working. Self-reflection Question: Are you forcing Agile on teams that aren't ready, or are you working with those who genuinely want to improve their delivery approach? [The Scrum Master Toolbox Podcast Recommends]
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]
I denne episode af Scrum med mere dykker vi ned i det emne, som alle taler om: AI. Men hvad er det egentlig for en størrelse? Vi tager fat på de store sprogmodeller (LLM’er) og forsøger at give et nøgternt billede af, hvad de kan – og i særdeleshed hvad de ikke kan. Vi gennemgår […] Source
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.
Das ist kein klassischer Jahresrückblick mit Sektlaune. Das ist ein Hausputz. Marc macht in dieser letzten Folge des Jahres den Reality-Check. Für 2026 gilt: Fitteres Agil statt mehr Agil. In dieser Episode erfährst du, welchen Ballast du jetzt abwerfen musst, um im neuen Jahr lieferfähig zu bleiben – und warum Harmonie dich innovationstechnisch ruiniert. DAS NIMMST DU MIT (KEY TAKEAWAYS): Der Tod des Selbstzwecks: Warum wir aufhören müssen zu fragen "Ist das Scrum?" und anfangen müssen zu fragen "Hilft das dem Kunden?". Schluss mit Kuscheln: Warum "Psychologische Sicherheit" oft mit Nettigkeit verwechselt wird und warum wir wieder professionelle Reibung brauchen, um Innovation zu erzeugen. Done > Perfect: Warum Perfektionismus (gerade in Deutschland) unser größter Bremsklotz ist und warum eine 80%-Lösung, die heute live geht, besser ist als eine 100%-Lösung, die nie kommt. Der Mindset-Shift 2026: Warum wir nicht auf die Politik warten dürfen, sondern als Scrum Master und Agile Leader selbst die Verantwortung für den Erfolg übernehmen müssen. ZITATE ZUM TEILEN: "Wir sollten 2026 nicht fragen 'Ist das Scrum?', sondern 'Hilft das dem Kunden?'" "Psychologische Sicherheit heißt eben nicht, dass wir alle kuscheln. [...] Wir wollen wieder mehr Reibung haben, weil mehr Reibung bringt mehr Innovation." "Lieber eine 80 % Lösung liefern wie eine 80 % Lösung [planen]. [...] Done is better than perfect." ACTION ITEM: Hör auf, Vorsätze zu schmieden. Mach eine "Not-To-Do"-Liste. Druck dir diese 3 Punkte aus, knüll sie zusammen und wirf sie weg – symbolisch für den Ballast, den du 2026 nicht mehr brauchst.
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.
Natalia Curusi: From Spreadsheets to Discovery—Helping POs Make the Transition The Great Product Owner: Taking Ownership and Coaching the Team Forward Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "That person was not just a great product owner, but a great coach—he had excellent communication and stakeholder management skills, and he coached myself as a Scrum Master, showing me how product ownership should look like." - Natalia Curusi Natalia worked with a Product Owner who embodied everything the role should be. He didn't come from a technical background, but he possessed exceptional domain knowledge, outstanding communication skills, and stakeholder management expertise you rarely find in one person. What made him truly remarkable was that he coached everyone around him, including Natalia as the Scrum Master. He demonstrated full empowerment and ownership—making decisions himself rather than constantly escalating to higher management. When risks needed to be taken, he took them with courage and conviction. The team trusted him completely because he balanced business needs with team capacity, always understanding what they could realistically achieve. Over the past five years, this person has been promoted multiple times and now serves as a global director of product, still with the same company. When Natalia thinks about what great product ownership looks like, she thinks of him—someone who combined technical understanding with coaching ability, took genuine ownership of outcomes, and empowered the team through clear vision and decisive leadership. These are exactly the skills that are hardest to find in the market, yet when you find them, the impact is transformative for the entire organization. Self-reflection Question: Does your Product Owner take ownership and make decisions, or do they constantly escalate to higher management, preventing the team from moving forward with confidence? The Bad Product Owner: Assigned Without Training, Support, or Willingness "She was a great subject matter expert with deep domain knowledge, but the organization assigned her the product owner role without her willingness, without training, and while she was already 80% loaded with other responsibilities." - Natalia Curusi Natalia encountered a Product Owner anti-pattern that reveals a systemic organizational failure. The person was an exceptional subject matter expert with incredible domain knowledge, but when the organization decided to adopt Agile, they assigned her the PO role like sticking a label on a box—no training, no consent, no preparation. She was already working at 80% capacity on other responsibilities and had no understanding of what product ownership meant. Frustrated and overwhelmed, she approached the role from a command-and-control mindset. At the project start, she brought a massive spreadsheet of requirements, expecting the team to implement them sequentially. The team tried a different approach, wanting to understand problems before discussing solutions, but the PO surprised everyone by re-introducing the spreadsheet in a later meeting—a clear sign of misalignment and broken trust. Natalia, recognizing this was a battle she couldn't win without organizational support, chose to manage the relationship rather than create open conflict. She worked to mediate between the PO's spreadsheet approach and the team's need for discovery and iterative development. The real anti-pattern wasn't the individual—it was the organization assigning critical roles without providing training, time, or psychological safety. This situation illustrates why product ownership fails: not from bad people, but from bad systems that set people up to fail. Self-reflection Question: When you see a struggling Product Owner, are you addressing the individual's behavior or the systemic conditions that set them up to fail in the first place? [The Scrum Master Toolbox Podcast Recommends]
Natalia Curusi: Measuring What Matters Beyond Velocity and Story Points Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "We as Scrum Masters need to put a scope for ourselves—we need to aim to leave the place where we work a little bit better than it was, and to make sure that this place could improve itself without us." - Natalia Curusi Natalia defines success for Scrum Masters with crystal clarity: leave the organization better than you found it, and ensure it can continue improving when you're gone. This means fostering independence and ownership in teams so they can perform whether you're on vacation, in another meeting, or have moved to coaching other teams. The opposite pattern—where everything falls apart when the Scrum Master isn't present—reveals someone who hasn't truly succeeded in the role. Natalia also emphasizes the importance of establishing metrics early, but not the traditional ones. Using velocity as a metric is an anti-pattern that focuses teams on the wrong outcomes. Instead, she recommends metrics like predictability, team morale, psychological safety measured through 360 feedback, and the quality of conversations both within teams and with stakeholders. But metrics alone don't tell the story. Natalia champions the concept of Gemba walks—going to see what's actually happening, talking to people, observing the reality rather than just reviewing dashboard numbers. Some metrics are easily gamed, others provide only narrow perspectives on reality. The most important practice is using metrics to trigger reflection and adaptation, not as fixed targets. Natalia believes strongly that the quality of conversations—how teams discuss options, make decisions together, and adapt when facing pressure—reveals more about a Scrum Master's success than any velocity chart ever could. The ultimate question: can your team succeed without you? Self-reflection Question: If you disappeared from your team tomorrow, would they continue improving, or would progress stop until someone replaced you? Featured Retrospective Format for the Week: Spotify Squad Health Check "This is a multidimensional retro that I run with teams every 2 to 3 months—you need around 30 minutes for it, and I often get insights and new ideas from this retrospective that help me as a Scrum Master." - Natalia Curusi The Spotify Squad Health Check is Natalia's favorite retrospective format because it provides a comprehensive view of team health across multiple dimensions. Unlike traditional retrospectives that might focus on a single sprint or specific issue, this format examines the team's overall state across areas like teamwork, support, mission clarity, and technical quality. Teams rate themselves on various health indicators, creating a visual representation that reveals patterns over time. What makes this particularly valuable is that it works whether you know the team well or are just starting with them—either way, you gain insights and "aha moments" about where the team truly stands. The multidimensional nature prevents teams from optimizing just one aspect while neglecting others, and the regular cadence (every 2-3 months) allows you to track trends and celebrate improvements. For Natalia, this format consistently surfaces the hidden challenges that teams might not raise in regular retrospectives, making it an essential tool in her Scrum Master toolkit. [The Scrum Master Toolbox Podcast Recommends]
How I Turn Around a Struggling Scrum Team in 90 DaysPeople often assume you can “fix” a struggling Scrum team by tightening ceremonies, updating Jira / Azure Devops, or pushing velocity. It's a nice idea, but it's not real. Teams don't turn around because you run cleaner standups. They turn around because the system around them becomes clearer, more aligned, and more stable.After coaching and leading delivery teams across banks, telcos, utilities, airports, insurers, and product companies, I've seen the same pattern repeat. A real turnaround takes time. Ninety days is the right horizon. Not because teams are slow, but because real change happens in stages.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/
В этом выпуске «Scrum‑мастерской» Мария Дьякова разговаривает с Артуром Неком, лидером направления целеполагания в Сбере. Он рассказывает, как пришёл к OKR через задачи стыковки подразделений в ритейле и построение системы целеполагания в компании Reg.ru, почему увидел именно в этом подходе не только способ считать цифры, но и инструмент для осмысленного диалога между командами и руководителями.Гости разбирают, чем OKR отличаются от KPI, какие задачи реально решают с их помощью разные компании — от Intel до Amazon, и какие существуют «школы» применения OKR. Артур делится примерами типичных ошибок в формулировке целей, объясняет, что такое амбициозность в метриках на самом деле, и показывает, как OKR помогают фокусироваться на важных рычагах роста, вовремя «переобуваться» и снижать конфликты между уровнями управления.Слушайте выпуск на всех популярных платформах: ⚪️ Apple: https://apple.co/467bc3C
Natalia Curusi: Demonstrating Your Value When the Market Questions Agile Roles Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "My challenging topic is about the demand of agility in the market—how do we fit ourselves as scrum masters in that AI era? How can we demonstrate our competence and contribution when there's a perception that agile roles bring little value?" - Natalia Curusi Natalia faces the challenge every Scrum Master in 2025 grapples with: how to demonstrate value in an era when business perceives agile roles as optional overhead. The market has contracted, companies are optimizing budgets, and Scrum Masters often appear first on the chopping block. There's talk of "blended roles" where developers are expected to absorb Scrum Master responsibilities, and questions about how AI might replace the human facilitation work that coaches provide. But Natalia believes the answer lies in understanding something fundamental: the Scrum Master is a deeply situational and contextual role that adapts to what the team needs each day. Some teams need help with communication spaces, others need work structure like Kanban boards, still others need translation between technical realities and stakeholder expectations. The challenge is that this situational nature makes it incredibly hard to explain to business leaders who think in fixed job descriptions and measurable outputs. Natalia's approach involves bringing metrics—not velocity, which focuses on the wrong things, but metrics around team independence, continuous improvement, and organizational capability. She suggests concepts like Gemba walks—going to see what's actually happening rather than relying only on numbers. The real question Natalia poses is this: the biggest value we can bring to an organization is to leave it better than we found it, but how do we make that visible and tangible to business stakeholders who need justification for our roles? Self-reflection Question: If you had to demonstrate your value as a Scrum Master using only observable evidence from the past month, what would you show your leadership? [The Scrum Master Toolbox Podcast Recommends]
Natalia Curusi: The Dark Side of High-Performing Dream Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "I was proud of this team—I helped form them from the start, we traveled to the client together, they were mature and independent, they even jelled outside the workplace. This was my dream team." - Natalia Curusi Natalia had built something special. The team was technically strong, emotionally connected, and highly productive. They socialized outside work, traveled together to client sites, and operated with remarkable independence. But when a new junior developer joined, everything started to unravel. The existing team members were like heroes—fast, skilled, confident. The newcomer couldn't keep pace, and slowly Natalia noticed something disturbing: the team started making fun of the new member during retrospectives and stand-ups. The person became an outlier, a black swan ignored by the group. Natalia conducted one-on-one meetings with both the new member and the team, but the situation only worsened. The new person insisted they were fine and didn't need help. The team members claimed they were just joking around. Meanwhile, the team structure and morale deteriorated. Natalia realized she was watching her dream team self-destruct through a form of bullying—something she hadn't even recognized at the time. Finally, she understood she couldn't handle this alone and escalated to the head of discipline and the organizational psychologist. Together, they decided to rotate the person to another team where they felt more comfortable. Natalia learned a painful lesson: as Scrum Masters, we don't need to solve everything ourselves, and sometimes the best solution is recognizing when to use the support structure around us rather than treating it as a personal failure. In this episode, we refer to Coaching Agile Teams by Lyssa Adkins and Training from the Back of the Room by Sharon Bowman. Self-reflection Question: When have you witnessed subtle forms of exclusion in your team, and did you recognize them early enough to intervene effectively? Featured Book of the Week: Coaching Agile Teams by Lyssa Adkins "This was the first book about agile coaching that I read, and it's how I understood that I was already playing the scrum master role without even knowing it—I understood that I was already acting like a glue for the team." - Natalia Curusi Natalia discovered Coaching Agile Teams at a pivotal moment in her career. The book revealed something profound: if you're irreplaceable, there's a problem. A great Scrum Master or coach makes themselves obsolete by growing team members who can replace them. The team should be able to perform independently when you're on vacation or move to another assignment. Lyssa Adkins showed Natalia that she needed to let go of over-control and over-responsibility, focusing instead on growing the team's capabilities. The book remains one of Natalia's top recommendations for every junior Scrum Master wanting to embrace the role, alongside Training from the Back of the Room, which teaches facilitators how to run interactive workshops where people learn from each other rather than just listening to slides. [The Scrum Master Toolbox Podcast Recommends]
Episode Overview In this episode of the John Kitchens Coach Podcast, John Kitchens and Joel Perso break down Milestone 5 of the Agent to CEO Framework: The Execution Roadmap—the critical bridge between strategy and real-world results. Most agents don't fail because they lack ideas or effort. They fail because they work on the wrong things, in the wrong order, with no execution rhythm. John and Joel unpack why second-best problems kill momentum, how to identify the single biggest constraint in your business, and how elite CEOs turn long-term vision into focused 90-day sprints. This episode is a masterclass in prioritization, accountability, and disciplined execution—designed for agents and team leaders who are done guessing and ready to scale with intention. Key Topics Covered Why Most Businesses Stall The real reason businesses fail: working hard on the wrong problems Why second-best problems only create incremental results How to identify the one thing that can 2–3X your business in 90 days The CEO Mindset Shift Moving from task-based thinking to purpose-driven execution Understanding your role as a leader in an AI-powered, consumer-driven market Why your value must go beyond tasks that can be automated Identifying Your True Constraint The most common constraints at each revenue level: Under six figures: no compelling offer Six figures to $500K: not enough leads $500K–$1M: conversion issues $1M–$3M: delivery bottlenecks and owner dependency Traffic, conversion, fulfillment, and retention—how to diagnose what's really broken The Execution Roadmap Explained Turning strategy into a focused 90-day action plan Why one priority per quarter beats five half-finished initiatives How to reverse engineer outcomes instead of guessing your way forward Setting Objectives That Actually Work Writing clear, measurable objective statements Defining success before starting Avoiding vague goals filled with buzzwords and zero accountability Key Results & Accountability How to define results—not tasks Why numbers matter more than opinions Creating key results that stretch the team without overwhelming them Ownership & Execution Rhythm The power of single-point ownership (one person, not a committee) Using weekly sprints to maintain momentum Why reporting beats brainstorming in execution meetings How Scrum principles accelerate progress without chaos Build, Fix, or Optimize Deciding whether your next move is: Building something new Fixing what's broken Optimizing what's already working Why optimization often produces the fastest ROI Resources & Mentions Agent to CEO Framework – Core operating system for scaling with clarity Scrum by Jeff Sutherland – Execution rhythm and sprint methodology Good Strategy / Bad Strategy by Richard Rumelt CoachKitchens.ai – AI-powered execution support for real estate CEOs John Kitchens Executive Coaching → https://johnkitchens.coach Final Takeaway Execution—not effort—is the difference between agents who stay stuck and CEOs who scale. If you can identify your real constraint, commit to one priority, assign clear ownership, and execute in focused 90-day sprints, everything changes. Clarity eliminates overwhelm. Discipline creates momentum. And momentum compounds into freedom. "If you could only work on one thing for the next 90 days that would 2–3X your business, what would it be?" That question—and your willingness to answer it honestly—determines your next level. Connect with Us: Instagram: @johnkitchenscoach LinkedIn: @johnkitchenscoach Facebook: @johnkitchenscoach If you enjoyed this episode, be sure to subscribe and leave a review. Stay tuned for more insights and strategies from the top minds. See you next time!
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]
In this episode, I share a counterintuitive realization I had after noticing my own behaviour around Black Friday—and how it completely changed the way I think about New Year's resolutions, procrastination, and consistency.Book mentioned in the video: Oblomov by Ivan GoncharovVideo about chaotic ambition: https://youtu.be/o3XosnSnGPULearn about my private membership where we cultivate a focused life: https://monthlymethod.com/focus-room/?utm_source=podcast&utm_medium=social&utm_term=&utm_content=Why I Didn't Start on January 1st&utm_campaign=Work with me 1-on-1: https://monthlymethod.com/meaningful-month/?utm_source=podcast&utm_medium=social&utm_term=&utm_content=Why I Didn't Start on January 1st&utm_campaign=Chapters:00:00 Intro00:16 The Black Friday Story02:37 How Black Friday is similar to New Year's Resolutions04:46 My best decision of last year05:53 New Year's resolutions never worked for me in the past06:12 New Year - Old Me07:42 Picking the hardest time to start09:16 The most consistent year10:39 Not needing a perfect start point11:43 The parenting analogy12:42 What are we teaching our brain?13:55 Waiting can be great15:38 What's so magical about January 1?16:50 Practicing the new lesson daily17:09 My favourite book about procrastination20:48 My proposal ★ Support this podcast on Patreon ★
Episode Overview In this episode of the John Kitchens Coach Podcast, John Kitchens and Joel Perso break down Milestone 5 of the Agent to CEO Framework: The Execution Roadmap—the critical bridge between strategy and real-world results. Most agents don't fail because they lack ideas or effort. They fail because they work on the wrong things, in the wrong order, with no execution rhythm. John and Joel unpack why second-best problems kill momentum, how to identify the single biggest constraint in your business, and how elite CEOs turn long-term vision into focused 90-day sprints. This episode is a masterclass in prioritization, accountability, and disciplined execution—designed for agents and team leaders who are done guessing and ready to scale with intention. Key Topics Covered Why Most Businesses Stall The real reason businesses fail: working hard on the wrong problems Why second-best problems only create incremental results How to identify the one thing that can 2–3X your business in 90 days The CEO Mindset Shift Moving from task-based thinking to purpose-driven execution Understanding your role as a leader in an AI-powered, consumer-driven market Why your value must go beyond tasks that can be automated Identifying Your True Constraint The most common constraints at each revenue level: Under six figures: no compelling offer Six figures to $500K: not enough leads $500K–$1M: conversion issues $1M–$3M: delivery bottlenecks and owner dependency Traffic, conversion, fulfillment, and retention—how to diagnose what's really broken The Execution Roadmap Explained Turning strategy into a focused 90-day action plan Why one priority per quarter beats five half-finished initiatives How to reverse engineer outcomes instead of guessing your way forward Setting Objectives That Actually Work Writing clear, measurable objective statements Defining success before starting Avoiding vague goals filled with buzzwords and zero accountability Key Results & Accountability How to define results—not tasks Why numbers matter more than opinions Creating key results that stretch the team without overwhelming them Ownership & Execution Rhythm The power of single-point ownership (one person, not a committee) Using weekly sprints to maintain momentum Why reporting beats brainstorming in execution meetings How Scrum principles accelerate progress without chaos Build, Fix, or Optimize Deciding whether your next move is: Building something new Fixing what's broken Optimizing what's already working Why optimization often produces the fastest ROI Resources & Mentions Agent to CEO Framework – Core operating system for scaling with clarity Scrum by Jeff Sutherland – Execution rhythm and sprint methodology Good Strategy / Bad Strategy by Richard Rumelt CoachKitchens.ai – AI-powered execution support for real estate CEOs John Kitchens Executive Coaching → https://johnkitchens.coach Final Takeaway Execution—not effort—is the difference between agents who stay stuck and CEOs who scale. If you can identify your real constraint, commit to one priority, assign clear ownership, and execute in focused 90-day sprints, everything changes. Clarity eliminates overwhelm. Discipline creates momentum. And momentum compounds into freedom. "If you could only work on one thing for the next 90 days that would 2–3X your business, what would it be?" That question—and your willingness to answer it honestly—determines your next level. Connect with Us: Instagram: @johnkitchenscoach LinkedIn: @johnkitchenscoach Facebook: @johnkitchenscoach If you enjoyed this episode, be sure to subscribe and leave a review. Stay tuned for more insights and strategies from the top minds. See you next time!
The Rugby Odds: George Hook solves Scrum Crisis, Shameful Sharks, Super Saints, Glasgow Game, Dupont by Matt McCarthy
In this episode of the Scrum.org Community Podcast, host Dave West sits down with authors Sander Dur and Ryan Brook to explore their new book, The Anatomy of a Product—a practical field guide that uses the human body as a metaphor to demystify modern product management.Dave, Sander, and Ryan dive into why so many organizations still struggle to define and manage products effectively, and how this book helps bridge the gap between theory and real-world practice. They discuss treating products as living systems, the dangers of “marshmallow backlogs,” the need for evidence-driven decisions, and why continuous care and adaptation are essential for healthy products.The authors share insights from working with organizations like Miro, unpack common “product diseases,” and offer actionable guidance for Product Owners, product teams, and leaders seeking clarity in today's complex environment.Listeners are invited to connect with the authors and join them at their book launch event in Amsterdam on January 13!Key Points Why the Book?Clarifies what a product is and offers a practical guide from definition to retirement.Human Body MetaphorProducts are like living systems—interconnected, adaptive, and influenced by their environment.Theory vs. PracticeHelps teams apply product concepts realistically, beyond Silicon Valley-style theory.Insights from real examplesReal-world examples showing how to balance strategy, business thinking, and everyday product work.Backlog HealthAvoid “marshmallow backlogs” by filtering work through strategic goals and focusing on value.Validation & EvidenceEmphasizes validating ideas early and aligning efforts to outcomes, not just requirements.Product HealthIntroduces “product diseases” and how to diagnose and prevent common issues.Links:Book Launch eventThe Anatomy of a Product
Let's learn about game production tools! There are a lot of them out there, but which ones are right for my team size, game scope, and budget? We'll discuss industry standards, the pros and cons of several tools, and their applicability to different production methods such as Scrum and Kanban.
We're doing Scrum. Why does everything take so long to finish?For many teams, delivery bogs down because of the way individuals approach the work itself.Most teams are still working in a sequence: one person finishes their part, hands it off, and then the next person begins. Designers wait for analysis to finish. Developers wait for designs. Testers wait for the code to be done. Everyone's optimizing for their own efficiency — but the team as a whole slows down.That might feel to individuals like the “right” way to work, but it comes with real costs: Mistakes go unnoticed until late in the process — and keep happening until then.Too much work is started toward the end of the sprint, creating bottlenecks and delays, which means features take longer to reach your users, and feedback takes longer to reach the team.Time to market, or time to value, is extended.Even when teams are doing “agile” on the surface, these large handoffs are the opposite of how an agile team works.To deliver value quickly, team members have to learn to stop waiting for someone else to finish before they start–in other words, they need to overlap work.When one type of task looks like it's dependent on another type of task, teams accustomed to overlapping work find ways to begin the second task before the first is completed. Coders start coding while the designer is still designing. Testers start creating tests even while the coder is coding.Why do teams cling to this outdated way of working?When teams first try working this way, many team members resist it. They're used to holding on to their work until it's perfect and “ready.” They might find the idea of overlapping work to be too messy and inefficient.Consider, for example, a tester. To be as efficient as possible, this tester would like to begin testing only after coding is complete. To test any earlier risks repeating work by re-running, or even re-designing, tests.What these team members need to realize is that optimizing for the efficiency of any one role prolongs the amount of time it takes to complete each new feature. Overlapping work is key to working in an agile way.For example, imagine that a developer is building a search results page for an eCommerce site. The page allows users to filter results by product attributes such as size, color, and more. Results can also be sorted by price, popularity, rating, and so on. If a programmer develops all of that before handing it over to a tester then no work has overlapped.If, however, the programmer handed it to the tester in pieces then testing could overlap with programming. The programmer could, for example, provide the tester with a version of the page without filtering or sorting. While a tester checks that, the developer adds filtering by size. Then color. Then sorting. The work overlaps — and everything moves faster.Two simple ways to encourage this way of working:Ask teams to shrink task size. Breaking big tasks into bite-sized pieces makes it easier for roles to overlap and collaborate. As handoffs get smaller, collaboration gets easier.Try swarming. Swarming is an extreme form of overlapping work that helps teams learn to let go of a “my work, your work” mindset and sequential “finish-to-start” mentality. When a team swarms, the whole team focuses on just one (or maybe two) items at a time.I'm not suggesting swarming as a long-term solution or the optimal way to work. It's a temporary, artificial constraint on work in process designed to force teams to find new ways to collaborate and move faster together. The goal is to remove the limit later, and have team members continue to apply the lessons they learned when they were forced to over-collaborate.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/
(04:11) Brought to you by JellyfishAI tools alone won't transform your engineering org. Jellyfish provides insights into AI tool adoption, cost, and delivery impact – so you can make better investment decisions and build teams that use AI effectively. See for yourself at jellyfish.co/platform/ai-impact.Are you managing your team the same way you did five years ago? With AI agents now part of the workforce, the old playbook no longer applies.In this episode, Jurgen Appelo, author of “Human Robot Agent” and creator of Management 3.0 and unFIX, challenges conventional thinking about management, organizational design, and the future of work in the AI era. He explains why rigid frameworks like Scrum are becoming bottlenecks to AI speed and why he believes we need to completely rethink how organizations operate.The conversation dives into the concept of creating “fast tracks” for AI agents while maintaining “slow tracks” for human collaboration. Jurgen also breaks down why team sizes are shrinking and why professionals must move beyond T-shaped skills to become M-shaped, multidisciplinary workers to remain relevant. He also shares his controversial take on why Scrum is “done” and why he trusts AI more than the average human when solving complex problems.Key topics discussed:Managing systems vs people in hybrid human-AI teamsWhy patterns beat frameworks for organization designWhy Scrum is done: adapting Agile for the AI eraM-shaped workers: the new multidisciplinary skillFast and slow tracks: redesigning work for AIWhy AI outperforms average humans at complex problemsCritical thinking as the essential leadership skillThe new optimal team size and dynamic reteamingTimestamps:(00:00:00) Trailer & Intro(00:02:20) Career Turning Points: Seven-Year Career Pivots(00:05:29) Origins of Management 3.0(00:08:31) Managing Systems, Not People(00:12:35) Everlasting Management Principles(00:17:21) unFIX: Patterns Over Frameworks(00:24:27) Core unFIX Patterns(00:31:39) Pipedrive Case Study: unFIX in Action(00:38:16) M3K: Merging Management 3.0 and unFIX(00:41:33) Skeptical Enthusiast: Balanced AI Perspective(00:47:18) Co-Creating with Humans and Machines(00:51:51) From T-Shaped to M-Shaped Workers(00:56:38) Why I Trust AI More Than Humans(01:00:19) Scrum is Done (Not Dead)(01:05:50) Redesigning Organizations for AI: Fast and Slow Tracks(01:09:25) 3 Tech Lead Wisdom_____Jurgen Appelo's BioJurgen Appelo is an author, speaker, and entrepreneur who helps leaders rewire their organizations for AI-driven leadership and autonomous digital agents. Recognized by Inc.com as a Top 50 Leadership Expert and Top 100 Leadership Speaker, he bridges opposing worldviews: human ingenuity and AI, leadership versus governance, stability with innovation, and individual growth fueling collective success. As founder of The unFIX Company (and previously founder of Management 3.0 and co-founder of Agile Lean Europe), Jurgen pioneers the future of work through stories, games, tools, and practices that challenge conventional thinking.Follow Jurgen:LinkedIn – linkedin.com/in/jurgenappeloWebsite – jurgenappelo.comSubstack – substack.jurgenappelo.com Human Robot Agent – https://jurgenappelo.com/pages/human-robot-agentLike this episode?Show notes & transcript: techleadjournal.dev/episodes/242.Follow @techleadjournal on LinkedIn, Twitter, and Instagram.Buy me a coffee or become a patron.
End-of-year retrospectives don't have to feel like grim post-mortems or blame-fests. In this episode, Kate Megaw and Ryan Smith break down how to run a year-in-review retrospective that's fun, psychologically safe, and actually leads to change!Drawing on the Team KatAnu R3 facilitation model (READY-REACH-RAP), they walk through how to set your retro up for success, design engaging activities (for in-person and virtual teams), and keep the focus on improving the process -not attacking people. You'll hear practical ideas like emotion timelines, appreciation rounds, dot-voting on themes, and using a “what we can/can't influence” bullseye to keep energy on what the team can control.Whether your team uses Scrum or not, you'll leave with a simple, repeatable structure for looking back at 2025, choosing one or two meaningful changes, and stepping into 2026 with clear, actionable experiments instead of vague resolutions.
Scott Smith: Empathy and Availability Define Excellent Product Ownership Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Always Present, Always Available, Always Curious "They are always present. They always make themselves available for team members that need them." - Scott Smith Scott is currently working with a Product Owner who exemplifies what great PO collaboration looks like. This person is always present—not just physically but mentally engaged with the team's work and challenges. They make themselves available for team members who need them, responding actively on the team chat and interacting consistently. What makes this PO stand out is their empathy and curiosity. Instead of being defensive when questions arise or challenges emerge, they lean into helping the team understand and solve problems. They show genuine curiosity about what the team is experiencing, asking questions and exploring solutions together rather than dictating answers. This PO understands that their role isn't to be the smartest person in the room but to be the most available, most collaborative, and most curious. The result is a team that feels supported and empowered, with clear direction and someone who genuinely helps them answer the hard questions. Scott's experience with this PO demonstrates that presence, availability, empathy, and curiosity are the foundations of great Product Owner work. Self-reflection Question: How present and available are you to your team, and do you approach their questions with curiosity or defensiveness? The Bad Product Owner: Never There When the Team Needs Direction "The PO was never present. The team had lack of clarity, and vision, and had no direction or someone who would help answer those questions." - Scott Smith Scott has also experienced the opposite extreme—a Product Owner who was never present. This absence created a cascade of problems for the team. Without regular access to the PO, the team lacked clarity about priorities, vision, and direction. They had questions that went unanswered and decisions that couldn't be made. The result was frustration and a team that couldn't move forward effectively. An absent PO creates a vacuum where uncertainty thrives. Teams end up making assumptions, second-guessing decisions, and feeling disconnected from the purpose of their work. The lack of someone who can help answer strategic questions or provide guidance means the team operates in the dark, building things without confidence that they're building the right things. Scott's experience highlights a fundamental truth about Product Ownership: presence isn't optional. Teams need a PO who shows up, engages, and stays connected to the work. Without that presence, even the most skilled team will struggle to deliver value because they can't align their efforts with the product vision and customer needs. Self-reflection Question: If your team were asked whether you're present and available as a Product Owner or Scrum Master, what would they say? [The Scrum Master Toolbox Podcast Recommends]
Scott Smith: Using MIRO to Build a Living Archive of Learning 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're in a servant leadership role. So, ask: is the team thriving? That's a huge indication of success." - Scott Smith For Scott, success as a Scrum Master isn't measured by velocity charts or burn-down graphs—it's measured by whether the people are thriving. This includes everyone: the development team and the Product Owner. As a servant leader, Scott's focus is on creating conditions where teams can flourish, and he has practical ways to gauge that health. Scott does a light touch check on a regular basis and a deeper assessment quarterly. Mid-sprint, he conducts what he calls a "vibe" check—a quick pulse to understand how people are feeling and what they need. During quarterly planning, the team retrospects and celebrates achievements from the past quarter, keeping and tracking actions to ensure continuous improvement isn't just talked about but lived. Scott's approach recognizes that success is both about the work being done and the people doing it. When teams feel supported, heard, and valued, the work naturally flows better. This people-first perspective defines what great servant leadership looks like in practice. Self-reflection Question: How often do you check in on whether your team is truly thriving, and what specific indicators tell you they are? Featured Retrospective Format for the Week: MIRO as a Living History Museum "Use the multiple retros in the MIRO board as a shared history museum for the team." - Scott Smith Scott leverages MIRO not just as a tool for running retrospectives but as a living archive of team learning and growth. He uses MIROVERSE templates to bring diversity to retrospective conversations, exploring the vast library of pre-built formats that offer themed and structured approaches to reflection. The magic happens when Scott treats each retrospective board not as a disposable artifact but as part of the team's shared history museum. Over time, the accumulation of retrospective boards tells the story of the team's journey—what they struggled with, what they celebrated, what actions they took, and how they evolved. This approach transforms retrospectives from isolated events into a continuous narrative of improvement. Teams can look back at previous retros to see patterns, track whether actions were completed, and recognize how far they've come. MIRO becomes both the canvas for current reflection and the archive of collective learning, making improvement visible and tangible across time. [The Scrum Master Toolbox Podcast Recommends]
Welcome to Episode 416 of the Microsoft Cloud IT Pro Podcast. In this week’s episode, Ben finally has a chance to sit down with Henrik Wojcik. Henrik has been a long-time listener as well as a fellow Microsoft MVP in Security and we finally had the chance to sit down and record an episode together, something we’ve talked about doing for years. As they sit down and enjoy a sunny afternoon in at Microsoft Ignite in San Francisco they discuss security in the financial sector, EU regulations (N2 and DORA), integrating Data Lake with Sentinel, optimizing log analytics, and the latest on Security Copilot and E5 licensing. They also spend some time chatting about some of their conference highlights, assisting as proctors in the hands-on labs, and the unique experience of Ignite in San Francisco. Your support makes this show possible! Please consider becoming a premium member for access to live shows and more. Check out our membership options. Show Notes Microsoft Ignite (with sessions on demand) Microsoft Ignite Book of News Catch up on Microsoft Security sessions and announcements from Ignite 2025 Microsoft Sentinel benefit for Microsoft 365 E5, A5, F5, and G5 customers Learn about Security Copilot inclusion in Microsoft 365 E5 subscription Microsoft Sentinel data lake: Unify signals, cut costs, and power agentic AI What is Microsoft Sentinel data lake? KQL and the Microsoft Sentinel data lake Henrik F. Wojcik Henrik has worked in the IT industry since 2003. He’s always had a passion for learning new technologies and expanding his knowledge through various means such as online courses, webinars, and reading up on the latest developments in the industry. Throughout his career, he’s gained experience in various areas of IT, making him a true jack of all trades. However, his latest interests lie in the security space, modern workplace and management in Azure, with a particular focus on cyber security. He has experience working with products such as Defender for Endpoint, Defender for Identity, Defender for Cloud Apps, Defender for Office 365, Conditional Access, Microsoft Sentinel, and Microsof t Entra ID. His primary focus is on security on Azure workloads and identity (Entra ID). He prioritizes security awareness and believe that learning never stops, which is why He’s always eager to expand my knowledge and skillset. In the past, He’s also worked with various tools and technologies such as Cisco, Citrix, Dynamics AX, Exchange, ITIL, Azure, SCCM & SCOM, Scrum & Kanban, VMware, Windows Servers, and Windows Desktops. About the sponsors Would you like to become the irreplaceable Microsoft 365 resource for your organization? Let us know!
In this Scrum.org Community Podcast episode, Lindsay Velecina from Scrum.org sits down with Robb Pieper and Jason Malmstadt of Responsive Advisors to answer the real, practical questions practitioners have about self-management in Scrum in a live Ask a PST session.Listeners submitted questions like:How do you get management to support self-management?What should you do when a team resists taking ownership?How do you handle a disruptive team member without taking over?What metrics show that self-management actually works?How can junior Scrum Masters enable self-management when they're not technical?AND MANY MORE!Robb and Jason tackle these questions head-on, sharing stories from the field, strategies for creating healthy team boundaries, and tools to make decision-making transparent — including Delegation Poker, feedback loops, and working agreements. They also discuss how to tie self-management to real business outcomes to gain leadership buy-in.Whether you're just beginning your Scrum journey or coaching mature teams, this episode gives you actionable guidance and small experiments you can start using today.
Scott Smith: Building a Coaching Service Where Survey Scores Become Living Improvement 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. "Success is about feedback from coaching clients." - Scott Smith Scott is tackling one of the most challenging aspects of organizational transformation: turning annual survey results into continuous improvement. Working with a domain of about 30 people, Scott is exploring how to create a coaching service that doesn't just react to once-a-year data but actively drives ongoing growth. The typical pattern in many organizations is familiar—conduct an annual survey, review the scores, maybe have a few discussions, and then wait another year. Scott is experimenting with a different approach. He's setting up a coaching service that focuses on real-time feedback from the people being coached, making improvement a living practice rather than an annual event. The strategy starts with a pilot, testing the concept before scaling across the entire domain. Scott's measure of success is pragmatic and human-centered: feedback from coaching clients. Not abstract metrics or theoretical frameworks, but whether the people receiving coaching find value in what's being offered. This approach reflects a fundamental principle of Agile coaching—start small, experiment, gather feedback, and iterate based on what actually works for the people involved. Scott is building improvement infrastructure that puts continuous learning at the center, transforming how organizations think about growth from an annual checkbox into an ongoing conversation. Self-reflection Question: If you were to implement a coaching service in your organization, how would you measure its success beyond traditional survey scores? [The Scrum Master Toolbox Podcast Recommends]
Welcome to Wednesday's Rugby Daily, with Cameron Hill.Coming up, Ireland find out their opponents for the Rugby World Cup in Australia,Mack Hansen is in a race to be fit for the Six Nations,The Stormers head coach has come out strongly against yellow cards for scrum penalties,And could we see a league-union crossover next year?Rugby on Off The Ball with Bank of Ireland | #NeverStopCompeting
I don't want a team of people who are so frantic and actually being unproductive because they don't know actually if they're coming or going. Bee Craft, Head of Performance Marketing at Golfbreaks, has found the cure for frantic, noisy marketing environments: the scrum methodology. On the podcast, she explains: How applying structured two-week sprints to campaign planning brings down the stress and increases productivity levels Why scrums are great for accountability and transparency in marketing How it's not just about the data - but also very much about humans, on both sides of the marketing coin.
In this week's Rugby Pod, the lads wrap up the Quilter Nations Series before diving head-first into the return of domestic rugby, with big Premiership and URC results to get stuck into. We're also welcoming Springbok legend Gurthrö Steenkamp for an unbelievable deep-dive into scrum culture, Rassie's revolution, and life in France. We check in on Bath's statement win at the StoneX to Exeter's comeback in Sale, plus a massive round in the URC as the Stormers storm Thomond and Scarlets stun Glasgow. The Rugby F.C. documentary has blown up on YouTube, fans are asking how to help Rugby Lions FC, and we're back on the road with a London live show this Wednesday ahead of the Champions Cup kicking off exclusively on Premier Sports. Add in some transfer news, a few reds in France, and all the Good, Bad & Ugly, and some shoutouts, and it's another stacked episode of the world's most listened-to rugby podcast. Learn more about your ad choices. Visit podcastchoices.com/adchoices
Scott Smith: Why Great Scrum Masters Create Space for Breaks 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. "Think of the people involved. Put yourself in the shoes of the other." - Scott Smith Scott found himself in the middle of rising tension as voices escalated between the Product Owner and the development team. The PO was harsh, emotions were running high, and the conflict was intensifying with each exchange. In that moment, Scott knew he had to act. He stepped in with a simple but powerful reminder: "We're on the same team." That pause—that momentary break—allowed everyone to step back and reset. Both the PO and the team members later thanked Scott for his intervention, acknowledging they needed that space to cool down and refocus on their shared outcome. Scott's approach centers on empathy and perspective-taking. He emphasizes thinking about the people involved and putting yourself in their shoes. When tensions rise, sometimes the most valuable contribution a Scrum Master can make is creating space for a break, reminding everyone of the shared goal, and helping teams focus on the outcome rather than the conflict. It's not about taking sides—it's about serving the team by being the calm presence that brings everyone back to what matters most. Self-reflection Question: When you witness conflict between team members or between the team and Product Owner, do you tend to jump in immediately or create space for the parties to find common ground themselves? Featured Book of the Week: An Ex-Manager Who Believed "It was about having someone who believed in me." - Scott Smith Scott's most influential "book" isn't printed on pages—it's a person. After spending 10 years as a Business Analyst, Scott decided to take the Professional Scrum Master I (PSM I) course and look for a Scrum Master position. That transition wasn't just about skills or certification; it was about having an ex-manager who inspired him to chase his goals and truly believed in him. This person gave Scott the confidence to make a significant career pivot, demonstrating that sometimes the most powerful catalyst for growth is someone who sees your potential before you fully recognize it yourself. Scott's story reminds us that great leadership isn't just about managing tasks—it's about inspiring people to reach for goals they might not have pursued alone. The belief and encouragement of a single person can change the trajectory of someone's entire career. [The Scrum Master Toolbox Podcast Recommends]
Is Scrum Slowly Taking Away Your Will To Live?On the surface, it sounds innocent, doesn't it? Cheerful even. Like something British schoolchildren might play on a muddy field before promptly breaking an ankle. But no. In reality, Scrum is a framework for managing work in software development, and it is somehow both wildly popular and completely misunderstood by… well, almost everyone.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/
Scott Smith: The Spotlight Failure That Taught a Silent Lesson About Recognition 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. "Not everybody enjoys the limelight and being called out, even for great work." - Scott Smith Scott was facilitating a multi-squad showcase with over 100 participants, and everything seemed to be going perfectly. Each squad had their five-minute slot to share achievements from the sprint, and Scott was coordinating the entire event. When one particular team member delivered what Scott considered fantastic work, he couldn't help but publicly recognize them during the introduction. It seemed like the perfect moment to celebrate excellence in front of the entire organization. But then his phone rang. The individual he had praised was unhappy—really unhappy. What Scott learned in that moment transformed his approach to recognition forever. The person was quiet, introverted, and conservative by nature. Being called out without prior notice or permission in front of 100+ people wasn't a reward—it was uncomfortable and unwelcome. Scott discovered that even positive recognition requires consent and awareness of individual preferences. Some people thrive in the spotlight, while others prefer their contributions to be acknowledged privately. The relationship continued well afterward, but the lesson stuck: check in with individuals before publicly recognizing them, understanding that great coaching means respecting how people want to be celebrated, not just that they should be celebrated. Self-reflection Question: How do you currently recognize team members' achievements, and have you asked each person how they prefer to be acknowledged for their contributions? [The Scrum Master Toolbox Podcast Recommends]
This week, Mike is joined by Ben Johnson, CEO and Founder of Particle 41, for a sharp, energizing look at what it really takes to lead in today's tech world. With more than 20 years of software experience and over $30 million raised across five startups, Ben brings the hard-earned lessons only a seasoned builder can offer. Ben breaks down the traits of effective tech leadership—setting a clear vision, empowering teams, and avoiding micromanagement. He shares candid stories from his early days as a founder, including a memorable misunderstanding of "burn rate." He explains why learning to speak the language of investors is essential for every entrepreneur. The conversation dives into what it takes to build strong, predictable teams through communication, structure, and proven frameworks like Scrum, Kanban, and the "Cone of Certainty." Ben also highlights the importance of starting with an MVP, validating demand, and iterating quickly—illustrated through the growth of Forte, an online music lesson platform that found success through smart, agile execution. Ben also opens up about the four pillars that ground his life—faith, family, fitness, and finance—and shares a touching story about helping his son conquer a fear of heights, a moment that shaped his own philosophy on courage and leadership. Ben then previews Particle 41's new AI Transformation service, designed to help companies integrate AI through smarter workflows and human-like digital agents. His perspective is clear: AI isn't a threat—it's a tool every business can harness to unlock its next level of performance. Packed with practical insights and inspiring lessons, this episode is a must-listen for anyone building products, leading teams, or stepping into the future of tech. IN THIS EPISODE:
BONUS: When AI Knows Your Emotional Triggers Better Than You Do — Navigating Mindfulness in the AI Age In this thought-provoking conversation, former computer engineer and mindfulness leader Mo Edjlali explores how AI is reshaping human meaning, attention, and decision-making. We examine the critical question: what happens when AI knows your emotional triggers better than you know yourself? Mo shares insights on remaining sovereign over our attention, avoiding dependency in both mindfulness and technology, and preparing for a world where AI may outperform us in nearly every domain. From Technology Pioneer to Mindfulness Leader "I've been very heavily influenced by technology, computer engineering, software development. I introduced DevOps to the federal government. But I have never seen anything change the way in which human beings work together like Agile." — Mo Edjlali Mo's journey began in the tech world — graduating in 1998, he was on the front line of the internet explosion. He remembers the days before the internet, watched online multiplayer games emerge in 1994, and worked on some of the most complicated tech projects in federal government. Technology felt almost like magic, advancing at a logarithmic rate faster than anything else. But when Mo discovered mindfulness practices 12-15 years ago, he found something equally transformative: actual exercises to develop emotional intelligence and soft skills that the tech world talked about but never taught. Mindfulness provided logical, practical methods that didn't require "woo-woo" beliefs — just practice that fundamentally changed his relationship with his mind. This dual perspective — tech innovator and mindfulness teacher — gives Mo a unique lens for understanding where we're headed. The Shift from Liberation to Dependency "I was fortunate enough, the teachers I was exposed to, the mentality was very much: you're gonna learn how to meditate on your own, in silence. There is no guru. There is no cult of personality." — Mo Edjlali Mo identifies a dangerous drift in the mindfulness movement: from teaching independence to creating dependency. His early training, particularly a Vipassana retreat led by S.N. Goenka, modeled true liberation — you show up for 10 days, pay nothing, receive food and lodging, learn to meditate, then donate what you can at the end. Critically, you leave being able to meditate on your own without worshiping a teacher or subscribing to guided meditations. But today's commercialized mindfulness often creates the opposite: powerful figures leading fiefdoms, consumers taught to listen to guided meditations rather than meditate independently. This dependency model mirrors exactly what's happening with AI — systems designed to make us rely on them rather than empower our own capabilities. Recognizing this parallel is essential for navigating both fields wisely. AI as a New Human Age, Not Just Another Tool "With AI, this is different. This isn't like mobile computing, this isn't like the internet. We're entering a new age. We had the Bronze Age, the Iron Age, the Industrial Age. When you enter a new age, it's almost like knocking the chess board over, flipping the pieces upside down. We're playing a new game." — Mo Edjlali Mo frames AI not as another technology upgrade but as the beginning of an entirely new human age. In a new age, everything shifts: currency, economies, government, technology, even religions. The documentary about the Bronze Age collapse taught him that when ages turn over, the old rules no longer apply. This perspective explains why AI feels fundamentally different from previous innovations. ChatGPT 2.0 was interesting; ChatGPT 3 blew Mo's mind and made him realize we're witnessing something unprecedented. While he's optimistic about the potential for sustainable abundance and extraordinary breakthroughs, he's also aware we're entering both the most exciting and most frightening time to be alive. Everything we learned in high school might be proven wrong as AI rewrites human knowledge, translates animal languages, extends longevity, and achieves things we can't even imagine. The Mental Health Tsunami and Loss of Purpose "If we do enter the age of abundance, where AI could do anything that human beings could do and do it better, suddenly the system we have set up — where our purpose is often tied to our income and our job — suddenly, we don't need to work. So what is our purpose?" — Mo Edjlali Mo offers a provocative vision of the future: a world where people might pay for jobs rather than get paid to work. It sounds crazy until you realize it's already happening — people pay $100,000-$200,000 for college just to get a job, politicians spend millions to get elected. If AI handles most work and we enter an age of abundance, jobs won't be about survival or income — they'll be about meaning, identity, and social connection. This creates three major crises Mo sees accelerating: attacks on our focus and attention (technology hijacking our awareness), polarization (forcing black-and-white thinking), and isolation (pushing us toward solo experiences). The mental health tsunami is coming as people struggle to find purpose in a world where AI outperforms them in domain after domain. The jobs will change, the value systems will shift, and those without tools for navigating this transformation will suffer most. When AI Reads Your Mind "Researchers at Duke University had hooked up fMRI brain scanning technology and took that data and fed it into GPT 2. They were able to translate brain signals into written narrative. So the implications are that we could read people's minds using AI." — Mo Edjlali The future Mo describes isn't science fiction — it's already beginning. Three years ago, researchers used early GPT to translate brain signals into written text by scanning people's minds with fMRI and training AI on the patterns. Today, AI knows a lot about heavy users like Mo through chat conversations. Tomorrow, AI will have video input of everything we see, sensory input from our biometrics (pulse, heart rate, health indicators), and potentially direct connection to our minds. This symbiotic relationship is coming whether we're ready or not. Mo demonstrates this with a personal experiment: he asked his AI to tell him about himself, describe his personality, identify his strengths, and most powerfully — reveal his blind spots. The AI's response was outstanding, better than what any human (even his therapist or himself) could have articulated. This is the reality we're moving toward: AI that knows our emotional triggers, blind spots, and patterns better than we do ourselves. Using AI as a Mirror for Self-Discovery "I asked my AI, 'What are my blind spots?' Human beings usually won't always tell you what your blind spots are, they might not see them. A therapist might not exactly see them. But the AI has... I've had the most intimate kind of conversations about everything. And the response was outstanding." — Mo Edjlali Mo's approach to AI is both pragmatic and experimental. He uses it extensively — at the level of teenagers and early college students who are on it all the time. But rather than just using AI as a tool, he treats it as a mirror for understanding himself. Asking AI to identify your blind spots is a powerful exercise because AI has observed all your conversations, patterns, and tendencies without the human limitations of forgetfulness or social politeness. Vasco shares a similar experience using AI as a therapy companion — not replacing his human therapist, but preparing for sessions and processing afterward. This reveals an essential truth: most of us don't understand ourselves that well. We're blind navigators using an increasingly powerful tool. The question isn't whether AI will know us better than we know ourselves — that's already happening. The question is how we use that knowledge wisely. The Danger of AI Hijacking Our Agency "There's this real danger. I saw that South Park episode about ChatGPT where his wife is like, 'Come on, put the AI down, talk to me,' and he's got this crazy business idea, and the AI keeps encouraging him along. It's a point where he's relying way too heavily on the AI and making really poor decisions." — Mo Edjlali Not all AI use is beneficial. Mo candidly admits his own mistakes — sometimes leaning into AI feedback over his actual users' feedback for his Meditate Together app because "I like what the AI is saying." This mirrors the South Park episode's warning about AI dependency, where the character's AI encourages increasingly poor decisions while his relationships suffer. Social media demonstrates this danger at scale: AI algorithms tuned to steal our attention and hijack our agency, preventing us from thinking about what truly matters — relationships and human connection. Mo shares a disturbing story about Zoom bombers disrupting Meditate Together sessions, filming it, posting it on YouTube where it got 90,000 views, with comments thanking the disruptors for "making my day better." Technology created a cannibalistic dynamic where teenagers watched videos of their mothers, aunts, and grandmothers being harassed during meditation. When Mo tried to contact Google, the company's incentive structure prioritized views and revenue over human decency. Technology combined with capitalism creates these dangerous momentum toward monetizing attention at any cost. Remaining Sovereign Over Your Attention "Traditionally, mindfulness does an extraordinary job, if you practice right, to help you regain your agency of your focus and concentration. It takes practice. But reading is now becoming a concentration practice. It's an actual practice." — Mo Edjlali Mo identifies three major symptoms affecting us: attacks on focus/attention, polarization into black-and-white thinking, and isolation. Mindfulness practices directly counter all three — but only if practiced correctly. Training attention, focus, and concentration requires actual practice, not just listening to guided meditations. Mo offers practical strategies: reading as concentration practice (asking "does anyone read anymore?" recognizing that sustained reading now requires deliberate effort), turning off AirPods while jogging or driving to find silence, spending time alone with your thoughts, and recognizing that we were given extraordinary power (smartphones) with zero training on how to be aware of it. Older generations remember having to rewind VHS tapes — forced moments of patience and stillness that no longer exist. We need to deliberately recreate those spaces where we're not constantly consuming entertainment and input. Dialectic Thinking: Beyond Polarization "I saw someone the other day wear a shirt that said, 'I'm perfect the way I am.' That's one-dimensional thinking. Two-dimensional thinking is: you're perfect the way that you are, and you could be a little better." — Mo Edjlali Mo's book OpenMBSR specifically addresses polarization by introducing dialectic thinking — the ability to hold paradoxes and seeming contradictions simultaneously. Social media and algorithms push us toward one-dimensional, black-and-white thinking: good/bad, right/wrong, with me/against me. But reality is far more nuanced. The ability to think "I'm perfect as I am AND I can improve" or "AI is extraordinary AND dangerous" is essential for navigating complexity. This mirrors the tech world's embrace of continuous improvement in Agile — accepting where you are while always pushing for better. Chess players learned this years ago when AI defeated humans — they didn't freak out, they accepted it and adapted. Now AI in chess doesn't just give answers; it helps humans understand how it arrived at those answers. This partnership model, where AI coaches us through complexity rather than simply replacing us, represents the healthiest path forward. Building Community, Not Dependency "When people think to meditate, unfortunately, they think, I have to do this by myself and listen to guided meditation. I'm saying no. Do it in silence. If you listen to guided meditation, listen to guided meditation that teaches you how to meditate in silence. And do it with other people, with intentional community." — Mo Edjlali Mo's OpenMBSR initiative explicitly borrows from the Agile movement's success: grassroots, community-centric, open source, transparent. Rather than creating fiefdoms around cult personalities, he wants mindfulness to spread organically through communities helping communities. This directly counters the isolation trend that technology accelerates. Meditate Together exists specifically to create spaces where people meditate with other human beings around the world, with volunteer hosts holding sessions. The model isn't about dependency on a teacher or platform — it's about building connection and shared practice. This aligns perfectly with how the tech world revolutionized collaborative work through Agile and Scrum: transparent, iterative, valuing individuals and interactions. The question for both mindfulness and AI adoption is whether we'll create systems that empower independence and community, or ones that foster dependency and isolation. Preparing for a World Where AI Outperforms Humans "AI is going to need to kind of coach us and ease us into it, right? There's some really dark, ugly things about ourselves that could be jarring without it being properly shared, exposed, and explained." — Mo Edjlali Looking at his children, Mo wonders what tools they'll need in a world where AI may outperform humans in nearly every domain. The answer isn't trying to compete with AI in calculation, memory, or analysis — that battle is already lost. Instead, the essential human skills become self-awareness, emotional intelligence, dialectic thinking, community building, and maintaining agency over attention and decision-making. AI will need to become a coach, helping humans understand not just answers but how it arrived at those answers. This requires AI development that prioritizes human growth over profit maximization. It also requires humans willing to do the hard work of understanding themselves — confronting blind spots, managing emotional triggers, practicing concentration, and building genuine relationships. The mental health tsunami Mo predicts isn't inevitable if we prepare now by teaching these skills widely, building community-centric systems, and designing AI that empowers rather than replaces human wisdom and connection. About Mo Edjlali Mo Edjlali is a former computer engineer, and also the founder and CEO of Mindful Leader, the world's largest provider of Mindfulness-Based Stress Reduction training. Mo's new book Open MBSR: Reimagining the Future of Mindfulness explores how ancient practices can help us navigate the AI revolution with awareness and resilience. You can learn more about Mo and his work at MindfulLeader.org, check out Meditate Together, and read his articles on AI's Mind-Reading Breakthrough and AI: Not Another Tool, but a New Human Age.
In this episode we're in conversation with Manjit Singh, the president and founder of Agilious and an instructor at ACT-IAC Academy. They delve into the importance of agile frameworks, particularly scrum, for government IT acquisition and modernization. Manjit shares his extensive technical background and the significance of scrum mastery in managing projects efficiently. He discusses the role of a Scrum Master, common misconceptions, the importance of asking the right questions, and the impact of emerging technologies like AI. The episode also highlights continuous upskilling and the value of lean principles in achieving productivity.Subscribe on your favorite podcast platform to never miss an episode! For more from ACT-IAC, follow us on LinkedIn or visit http://www.actiac.org.Learn more about membership at https://www.actiac.org/join.Donate to ACT-IAC at https://actiac.org/donate. Intro/Outro Music: See a Brighter Day/Gloria TellsCourtesy of Epidemic Sound(Episodes 1-159: Intro/Outro Music: Focal Point/Young CommunityCourtesy of Epidemic Sound)
Can teams pull in more work during a sprint? - Mike Cohn“Can we bring in more work if we're ahead in a sprint?"It's one of the most common questions I get from Scrum teams — and honestly, for a long time, I couldn't understand why. The answer felt obvious.Of course you can bring in more work if you're ahead and clearly going to finish everything you committed to do. Just like you can drop work if you're behind.A sprint plan is a forecast — a best guess at what the team thinks it can get done. It's not a contract. No one gets it perfect every time, and that's OK.But I kept hearing this question over and over, so I started asking why. Why does adding work spark so much hesitation — even fear? Here's what I learned: Teams are afraid that starting something they can't fully complete within the sprint is somehow breaking the rules, or even worse, a failure.That fear leads teams to hesitate to pick up something new unless they're 100 percent sure they can finish it before the sprint ends.Let me reassure you. Being halfway done with one or two things at the end of a sprint isn't a problem. Sometimes, it's even desirable.It only becomes a problem if a team is consistently halfway done with several things or worse, everything.If the team is genuinely ahead, and they've completed what they committed to, they can absolutely pull in something new — even if they might not finish it.Good agile teams always try to finish everything, just like good sports teams try to make every attempt on goal or get a hit at every at bat.And when given the opportunity, great agile teams don't hesitate to make progress on something new even if they might not finish.What's the real issue underneath the question?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/
Welcome to Tuesday's Rugby Daily, with Cameron Hill.Coming up today, we'll round off the reaction to Ireland's defeat to South Africa on Saturday.Squad updates from the provinces with the URC back this weekend, and the start of the Champions Cup fast approaching.And Felipe Contepomi reveals the physical confrontation he had with an England star at Twickenham this weekend...Rugby on Off The Ball with Bank of Ireland | #NeverStopCompeting
The ARP rates the All Blacks progress and who the top contenders are two years from the 2027 Rugby World Cup. We decide whether the Boks scrum is possibly rugby's greatest weapon, weigh-in on the great Dublin card game and celebrate Malcolm Marx finally getting Player of the Year. Hosted on Acast. See acast.com/privacy for more information.
Sara Di Gregorio: Coaching Product Owners from Isolation to Collaboration Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Using User Story Mapping to Break Down PO Isolation "One of the key strengths is the ability to build a strong collaborative relationship with the Scrum team. We constantly exchange feedback, with the shared goal of improving both our collaborating and the way of working." - Sara Di Gregorio Sara considers herself fortunate—she currently works with Product Owners who exemplify what great collaboration looks like. One of their key strengths is the ability to build strong collaborative relationships with the Scrum team. They don't wait for sprint reviews to exchange feedback; instead, they constantly communicate with the shared goal of improving both collaboration and ways of working. These Product Owners involve the team early, using techniques like user story mapping after analysis phases to create open discussions around upcoming topics and help the team understand potential dependencies. They make themselves truly available—they observe daily stand-ups not as passive attendees but as engaged contributors. If the team needs five minutes to discuss something afterward, the Product Owner is ready. They attend Scrum events with genuine interest in working with the team, not just fulfilling an attendance requirement. They encourage open dialogue, even participating in retrospectives to understand how the team is working and where they can improve collaboration. What sets these Product Owners apart is their communication approach. They don't come in thinking they know everything or that they need to do everything alone. Their mindset is collaborative: "We're doing this together." They recognize that developers aren't just executors—they're users of the product, experts who can provide valuable perspectives. When Product Owners ask "Why do you want this?" and developers respond with "If we do it this way, we can be faster, and you can try your product sooner," that's when magic happens. Great Product Owners understand that strong communication skills and collaborative relationships create better products, better teams, and better outcomes for everyone involved. Self-reflection Question: How are your Product Owners involving the team early in discovery and analysis, and are they building collaborative relationships or just attending required events? The Bad Product Owner: The Isolated Expert Who Thinks Teams Just Execute "Sometimes they feel very comfortable in their subject, so they assume they know everything, and the team has only to execute what they asked for." - Sara Di Gregorio Sara has encountered Product Owners who embody the worst anti-pattern: they believe they don't need to interact with the development team because they're confident in their subject matter expertise. They assume they know everything, and the team's job is simply to execute what they ask for. These Product Owners work isolated from the development team, writing detailed user stories alone and skipping the interesting discussions with developers. They only involve the team when they think it's necessary, treating developers as order-takers rather than collaborators who could contribute valuable insights. The impact is significant—teams lose the opportunity to understand the "why" behind features, Product Owners miss perspectives that could improve the product, and collaboration becomes transactional instead of transformational. Sara's approach to addressing this anti-pattern is patient but deliberate. She creates space for dialogue and provides training with the Product Owner to help them understand how important it is to collaborate and cooperate with the team. She shows them the impact of including the team from the beginning of feature study. One powerful technique she uses is user story mapping workshops, bringing both the team and Product Owner together. The Product Owner explains what they want to deliver from their point of view, but then something crucial happens: the team asks lots of questions to understand "Why do you want this?"—not just "I will do it." Through this exercise, Sara watched Product Owners have profound realizations. They understood they could change their mindset by talking with developers, who often are users of the product and can offer perspectives like "If we do it this way, we can be faster, and you can try your product sooner." The workshop helps teams understand the big picture of what the Product Owner is asking for while helping the Product Owner reflect on what they're actually asking. It transforms the relationship from isolation to collaboration, from directive to dialogue, from assumption to shared understanding. In this segment, we refer to the User Story Mapping blog post by Jeff Patton. Self-reflection Question: Are your Product Owners writing user stories in isolation, or are they involving the team in discovery to create shared understanding and better solutions? [The Scrum Master Toolbox Podcast Recommends]
Sara Di Gregorio: How to Know Your Team Has Internalized Agile Values 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. "Scrum isn't just a process to follow, it's a way of working." - Sara Di Gregorio For Sara, success as a Scrum Master isn't measured by what the team delivers—it's measured by how they grow. She knows that if you facilitate team growth in communication and collaboration, delivery will naturally improve. The indicators she watches for are subtle but powerful. When teams come to her with specific requests outside the regular schedule—"Can we have 30 minutes to talk and reflect mid-sprint?"—she knows something has shifted. When teams want to reflect outside the retrospective cycle, it means they've internalized the value of continuous improvement, not just going through the motions. She listens for the word "goal" during sprint planning. When team members start their planning by talking about goals, she feels a surge of recognition: "Okay, for me, this is very, very, very important." Success shows up in unexpected places. One of her colleague's teams pushed back during a cross-team meeting, saying "We're going out of the timebox" and suggesting they move the discussion to a different time. That kind of proactive leadership and accountability signals maturity. It means the team isn't just attending Scrum events because they have to—they truly understand why each event matters and actively participate to make them valuable. When Sara first met a team, they asked if she wanted to change things. She said no. What she focuses on is how people improve and understand the process better. For her, it starts with the people—when people change and understand the value, that's when real changes happen in the company. It's about helping people feel good and be guided well, because when they're working well, that's when transformation becomes possible. As Sara reminds us, Scrum isn't just a process to follow—it's a way of working that teams must embrace, understand, and make their own. Self-reflection Question: Are your teams coming to you asking for reflection time outside scheduled events, and what does that tell you about how deeply they've internalized continuous improvement? Featured Retrospective Format for the Week: Unstructured Retrospective After facilitating many structured retrospectives, Sara started experimenting with an unstructured format that brought new energy to team reflection. Instead of using predefined frameworks, she brings white paper, sticky notes, and sharpies of different colors. She opens with a simple question: "Guys, what impacted you mostly during the last week? How do you feel today?" Sometimes she starts with data and metrics; other times, she begins with how the team is feeling. The key is creating open space for conversation rather than forcing it into a predetermined structure. What Sara discovered is remarkable: "They are more engaged, more open, and more present in the conversation, maybe because it was something new." Instead of the same structured format every time, the unstructured approach breaks the routine and creates space for true reflections that bring out something deeper and more meaningful. It allows people to express what's genuinely going on for them, not just what fits into a predefined template. Sara doesn't abandon structured formats entirely—she alternates between structured and unstructured to keep retrospectives fresh and engaging. She also recommends, if you work hybrid, trying to schedule unstructured retrospectives for days when the team is in the office together. The physical presence combined with the open format creates an environment where teams can be more vulnerable, more creative, and more honest about what's really happening. The unstructured retrospective isn't about chaos—it's about trusting the team to surface what matters most to them, with the Scrum Master providing light facilitation and space for authentic reflection. [The Scrum Master Toolbox Podcast Recommends]
5 Essential Skills Every Scrum Master NeedsBeing a Scrum Master isn't just about booking meetings and quoting the Scrum Guide. It's about showing up every day as a change agent — the one who helps people work better together, face complexity with courage, and actually deliver value.It's easy to forget that Scrum is fundamentally about people.Your job as a Scrum Master is to unlock that potential — not by managing them, but by enabling them.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/
Sara Di Gregorio: Facilitating Deeper Retrospectives—When to Step In and When to Step Back Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "When they start connecting and having an interesting discussion, I go to the corner, and I'm only trying to listen." - Sara Di Gregorio Sara faces a challenge that many Scrum Masters encounter: teams that want to discuss too many topics during retrospectives without going deep on any of them. The team had plenty to talk about, but conversations stayed surface-level, never reaching the insights that drive real improvement. Sara recognized that the aim of the retrospective isn't to talk about everything—it's to go deeper on topics the team genuinely cares about. So she started coaching teams to select just three main topics they wanted to discuss, helping them understand why prioritization matters and making explicit which topics are most important. But her real skill emerged in how she facilitated the discussions. When she saw communication starting to flow and team members becoming deeply connected to the topic, she moved to the corner and listened. She didn't abandon the team—she remained present, ready to help shy or quiet members speak up, watching the clock to respect timeboxes. But she understood that when teams connect authentically, the Scrum Master's job is to create space, not fill it. Sara learned to ask better questions too. Instead of repeatedly asking "Why? Why? Why?"—which can feel accusatory—she reformulated: "How did you approach it? What happens?" When teams started blaming other teams, she redirected: "What can we influence? What can we do from our side?" She used visual tools like white paper, sharpies, and sticky notes to help teams visualize their discussion steps and create structured moments for questions. Sometimes, when teams discussed complex technical topics beyond her understanding, she empowered them: "You are the main expert of this topic. Please, when someone sees that we're going out of topic or getting too detailed, raise your hand and help me bring the communication back to what we've chosen to talk about." This balance—knowing when to step in with structure and when to step back and listen—is what transforms retrospectives from checkbox events into genuine opportunities for team growth. Self-reflection Question: In your facilitation, are you creating space for deep team connection, or are you inadvertently filling the space that teams need to discover insights for themselves? [The Scrum Master Toolbox Podcast Recommends]
Sara Di Gregorio: Rebuilding Agile Team Connection in the Remote Work Era Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "The book helped me to shift from reacting to connecting, which completely changed the quality of conversation." - Sara Di Gregorio When COVID forced Sara's team into full remote work, she noticed something troubling—the team was losing real connection. Replicating in-office meetings online simply didn't work. People attended meetings but weren't truly present. The spontaneous coffee machine conversations that built relationships and surfaced important information had vanished. So Sara started experimenting. She introduced 5-minute chit-chat sessions at the start of every meeting: "Guys, how are you today? What happened yesterday?" She created "coffee all together" moments—10-minute virtual breaks where the team could drink coffee or have aperitivos together, sometimes three times per week. She established weekly feedback sessions every Friday morning—30 minutes to recap the week and understand what could improve. These weren't just social niceties; they were deliberate efforts to recreate the human connections that remote work had stripped away. Sara recognized that mechanized interactions—"here are the things I need you to do, let's talk next steps"—kill team dynamics. Teams need moments where they relate to each other as people, not just as functions. The experiments worked because they created space for genuine connection, allowing the team to maintain the trust and collaboration that makes effective teamwork possible, even when working remotely. In this episode, we refer to Non-Violent Communication concepts and practices. Self-reflection Question: How are you creating moments for your remote or hybrid team to connect as people, not just as colleagues executing tasks? Featured Book of the Week: Nonviolent Communication by Marshall Rosenberg Sara credits Nonviolent Communication by Marshall Rosenberg (translated in Italian as "Words are Windows, or They are Walls") as having a deep impact on her career. The book explores how to listen without judging, how to ask the right questions, and how to observe people to understand their real needs. But above all, it teaches how to communicate in a way that builds connection rather than creating barriers. For Sara, the book was remarkably practical—she didn't just read it, she experimented with the techniques afterward. She explains: "I think that without this mindset, it's easy to fall into reactive communication, trying to defend, justify, or give quick answers. But that often blocks real understanding." The book helped her shift from reacting to connecting, which completely changed the quality of her conversations. As a Scrum Master working with people every day—facilitating meetings, mediating conflicts, supporting teams—the way we communicate determines whether we open dialogue or close it. Sara found that taking time to reflect instead of giving quick answers transformed her ability to help teams discover dependencies, improve dialogue, and address communication issues. For anyone in the Scrum Master role, this book provides essential skills for building the kind of connection that makes true collaboration possible. In this segment, we also refer to the NVC episodes we have on the podcast. Check those out to learn more about Nonviolent Communication [The Scrum Master Toolbox Podcast Recommends]
Sara Di Gregorio: When Teams Lose Trust—How Scrum Masters Rebuild It One Small Change at a Time Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "I continue to approach this situation with openness, positivity, and trust, because I truly believe that even the smallest changes can make a difference over time." - Sara Di Gregorio Sara faced one of the most challenging situations a Scrum Master can encounter—a team member who had lost all trust in change, creating a negative atmosphere that weighed heavily on the entire team. She remembers the heaviness on her shoulders, feeling personally responsible for the team's wellbeing. The negativity was palpable during every meeting, and it threatened to undermine the team's progress. But Sara refused to give up. She started experimenting with different approaches: one-to-one conversations to understand what was happening, bringing intentional energy to meetings, and trying new facilitation techniques in retrospectives. She added personal check-ins, asking "How are you today?" at the start of stand-ups, consciously bringing positive energy even on days when she didn't feel it herself. She discovered that listening—truly listening, not just hearing—means understanding how people feel, not just what they're saying. Sara learned that the energy you bring to interactions matters deeply. Starting the day with genuine interest, asking about the team's wellbeing, and even making small comments about the weather could create tiny shifts—a small smile that signaled something had changed. Her approach was rooted in persistence and belief: she continued approaching the situation with openness, positivity, and trust, knowing that even the smallest changes can make a difference over time. For Sara, reestablishing a good environment wasn't about quick fixes—it was about showing up every day with the right energy and never giving up on her team. Self-reflection Question: What energy are you bringing to your interactions with the team today, and how might that be shaping the team's atmosphere? [The Scrum Master Toolbox Podcast Recommends]
BONUS: Flawless Execution — Translating Fighter Pilot Precision to Business Results In this powerful conversation, former fighter pilot Christian "Boo" Boucousis reveals how military precision translates into agile business leadership. We explore the FLEX model (Plan-Brief-Execute-Debrief), the critical difference between control-based and awareness-based leadership, and why most organizations fail to truly embrace iterative thinking. From Cockpit to Boardroom: An Unexpected Journey "I learned over time that it doesn't matter what you do if you're always curious, and you're always intentional, and you're always asking questions." — Christian "Boo" Boucousis Christian's path from fighter pilot to leadership consultant wasn't planned—it was driven by necessity and curiosity. After 11 years as a fighter pilot (7 in Australia, 4 in the UK), an autoimmune condition ended his flying career at age 30. Rather than accepting a comfy job flying politicians around, he chose entrepreneurship. He moved to Afghanistan with a friend and built a reconstruction company that grew to a quarter billion dollars in four years. The secret? The debrief skills he learned as a fighter pilot. By constantly asking "What are you trying to achieve? How's it going? Why is there a gap?" he approached business with an agile mindset before he even knew what agile was. This curiosity-driven, question-focused approach became the foundation for everything that followed. The FLEX Model: Plan-Brief-Execute-Debrief "Agile and scrum were co-created by John Sutherland, who was a fighter pilot, and its origins sit in the OODA loop and iteration. Which is why it's a circle." — Christian "Boo" Boucousis The FLEX model isn't new—fighter pilots have used this Plan-Brief-Execute-Debrief cycle for 60 years. It's the ultimate simple agile model, designed to help teams accelerate toward goals using the same accelerated learning curve the Air Force uses to train fighter pilots. The key insight: everything in this model is iterative, not linear. Every mission has a start, middle, and end, and every stage involves constant adaptation. Afterburner (the company Christian now leads as CEO) has worked with nearly 3,800 companies and 2.8 million people over 30 years, teaching this model. What's fascinating is that the DNA of agile is baked into fighter pilot thinking—John Sutherland, co-creator of Scrum, wrote the foreword for Christian's book "The Afterburner Advantage" because they share the same roots in the OODA loop and iterative thinking. Why Iterative Thinking Doesn't Come Naturally "Iterative thinking is not a natural human model. Most of the time we learn from mistakes. We don't learn as a habit." — Christian "Boo" Boucousis Here's the hard truth: agile as a way of working is very different from the way human beings naturally think. Business leadership models still hark back to Frederick Winslow Taylor's 1911 book on scientific management—industrial era leadership designed for building buildings, not creating software. Time is always linear (foundation, then structure, then finishing), and this shapes how we think about planning. Humans also tend to organize like villages with chiefs, warriors, and gatherers—hierarchical and political. Fighter pilots created a parallel system where politics exist outside missions, but during execution, personality clashes can't interfere. The challenge for business isn't the method—it's getting human minds to embrace iteration as a habit, not just a process they follow when forced. Planning: Building Collective Consciousness, Not Task Lists "Planning isn't all about sequencing actions—that's not planning. That's the byproduct of planning, which is collectively agreeing what good looks like at the end." — Christian "Boo" Boucousis Most people plan in their head or in front of a spreadsheet by themselves. That's not planning—that's collecting thoughts. Real planning means bringing everyone on the team together to build collective consciousness about what's possible. The plan is always "the best idea based on what we know now." Once airborne, everything changes because the enemy doesn't cooperate with your plan. Planning is about the destination, not the work to get there. Think about airline pilots: they don't tell you about traffic delays on their commute or maintenance issues. They say "Welcome aboard, our destination is Amsterdam, there's weather on the way, we'll land 5 minutes early." That's a brief—just the effect on you based on all their work. Most business meetings waste 55 minutes on backstory and 5 minutes deciding to have another meeting. Fighter pilots focus entirely on: What are we trying to achieve? What might get in the way? Let's go. Briefing: The 25-Minute Focus Window "You need 25 minutes of focus before your brain really focuses on the task. You program your brain for the mission at hand." — Christian "Boo" Boucousis The brief is the moment between planning and execution when the plan is as accurate as it'll ever get. It's called "brief" for a reason—it's really short. The team checks that everyone understands the plan in today's context, accounting for last-minute changes (broken equipment, weather, personnel changes). Then comes the critical part: creating the mission bubble. From the brief until mission end, there are no distractions, no notifications. If someone tries to interrupt a fighter pilot walking to the jet, the response is clear: "I'm in my mission bubble. No distractions." This isn't optional—research shows it takes 25 minutes of uninterrupted focus before your brain truly locks onto a task. Yet most business leaders expect constant availability, with notifications pinging every few minutes. If you need everyone to have notifications on to run your business, you're doing a really bad job at planning. Execution: Awareness-Based Leadership vs. Control-Based Leadership "The reason we have so many meetings is because the leader is trying to control the situation and own all the awareness. It's not humanly possible to do that." — Christian "Boo" Boucousis During execution, fighter pilots fly the plan until it doesn't work anymore—then they adapt. A mission commander might lead 70 airplanes, but can't possibly track all 69 others. Instead, they create "gates"—checkpoints where everyone confirms they're in the right place within 10 seconds. They plan for chaos, creating awareness points where the team is generally on track or not. The key shift: from control-based leadership (the leader tries to control everything) to awareness-based leadership (the leader facilitates and listens for divergences). This includes "subordinated leadership"—any of the four pilots in a formation can take the lead if they have better awareness. If a wingman calls out a threat the leader doesn't see, the immediate response is "Press! You take the lead." This works because they planned for it and have criteria. Business teams profess to want this kind of agile collaboration, but struggle because they haven't invested in the planning and shared understanding that makes fluid leadership transitions possible. Abort Criteria: Knowing When to Stop "We have this concept called abort criteria. If certain criteria are hit, we abort the mission. I think that's a massive opportunity for business." — Christian "Boo" Boucousis There are degrees of things going wrong: a little bit, a medium amount, and everything going wrong. When everything's going wrong, fighter pilots stop and turn around—they don't keep pressing a bad situation. This "abort criteria" concept is massively underutilized in business. Too often, teams press bad situations, transparency disappears, people stop talking, and everyone goes into survival mode (protect myself, blame others). This never happens with fighter pilots. If something goes wrong, they take accountability and make the best decision. The most potent team size is four people: a leader, deputy leader, and two wingmen. This small team size with clear roles and shared abort criteria creates psychological safety to call out problems and adapt quickly. The Retrospective Mindset: Not Just a Ritual "A retrospective isn't a ritual. It's actually a way of thinking. It's a cognitive model. If you approached everything as a retrospective—what are we trying to achieve? How's it going? Why is it not going where we want? What's the one action to get back on track?" — Christian "Boo" Boucousis The debrief—the retrospective—is the most important part of fighter pilot culture translated into agile. It's not just a meeting you have at the end of a sprint. It's a mindset you apply to everything: projects, relationships, personal development. Christian introduces "Flawless Leadership" built on three M's: Method (agile practices), Mindset (growth mindset developed through acting iteratively), and Moments (understanding when to show up as a people leader vs. an impact leader). The biggest mistake in technology: teams do retrospectives internally but don't include the business. They get a brief from the business, build for two months, come back, and the business says "What is this? This isn't what I expected." If they'd had the business in every scrum, every iteration, trust would build naturally. Everyone involved in the mission must be part of the planning, briefing, executing, and debriefing. Leading in the Moment: Three Layers of Leadership "Your job as a scrum master, as a leader—it doesn't matter if you're leading a division of people—is to be aware. And you're only going to be aware by listening." — Christian "Boo" Boucousis Christian breaks leadership into three layers: People Leadership (political, emotional, dealing with personalities and overwhelm), Impact Leadership (the agile layer, results-driven, scientific), and Leading Now (the reactive, amygdala-driven panic response when things go wrong). The mistake: mixing these layers. Don't try to be a people leader during execution—that's not the time. But if you're really good at impact leadership (planning, breaking epics into stories, getting work done), you become high trust and high credibility. People leadership becomes easier because success eliminates excuses. During execution, watch for individual traits and blind spots. Use one-on-ones with a retrospective mindset: "What does good look like for you? How do we get to where you're not frustrated?" When leaders aren't present—checking phones and watches during meetings—they lose people. Your job as a leader is to turn your ears on, facilitate (not direct), and listen for divergences others don't see. The Technology-Business Disconnect "Every time you're having a scrum, every time you're coming together to talk about the product, just have the business there with you. It's easy." — Christian "Boo" Boucousis One of the biggest packages of work Afterburner does: technology teams ask them to help build trust with the business. The solution is shockingly simple—include the business in every scrum, every planning session, every retrospective. Agile is a tech-driven approach, creating a disconnect. Technology brings overwhelming information about how hard they're working and problems they've solved, but business doesn't care about the past. They care about the future: what are you delivering and when? During the Gulf War, the military scaled this fighter pilot model to large-scale planning. Fighter pilots work with marines, special forces, navy, CIA agents—everyone is part of the plan. If one person is missing from planning, execution falls apart. If someone on the ground doesn't know how an F-18 works, the jet is just expensive decoration. Planning is about learning what everyone else does and how to support them best—not announcing what you'll do and how you'll do it. High-Definition Destinations: Beyond Goals "Planning is all about the destination, not the work to get there. Think about when you hop on an airplane—the pilot doesn't tell you the whole backstory. They say 'Welcome aboard, our destination is Amsterdam, there's weather on the way, we'll land 5 minutes early.' All you want is the effect on you." — Christian "Boo" Boucousis Christian uses the term "High-Definition Destinations" rather than goals. The difference is clarity and vividness. When you board a plane, you don't get the pilot's commute story or maintenance details—you get the destination, obstacles, and estimated arrival. That's communication focused on effect, not process. Most business communication does the opposite: overwhelming context, backstory, and detail, with the destination buried somewhere in the middle. The brief should always be: Here's where we're going. Here's what might get in the way. Let's go. This communication style—focused on outcomes and effects rather than processes and problems—transforms how teams align and execute. It eliminates the noise and centers everyone on what actually matters: the destination. About Christian "Boo" Boucousis Christian "Boo" Boucousis is a former fighter pilot who now helps leaders navigate today's fast-moving world. As CEO of Afterburner and author of The Afterburner Advantage, he shares practical, people-centered tools for turning chaos into clarity, building trust, and delivering results without burning out. You can link with Christian "Boo" Boucousis on LinkedIn, visit Afterburner.com, check out his personal site at CallMeBoo.com, or interact with his AI tool at AIBoo.com.