Scrum Master Toolbox Podcast

BONUS: Consulting is Different—How Consulting Contracts Work Against Agile Development, With Jakob Wolman and Wilko Nienhaus  In this BONUS episode, we explore the critical differences between building software as a consultant versus inside a product company. Jakob Wolman contributed an insightful article to the Global Agile Summit book examining how third-party software development operates under entirely different constraints than in-house product development. Joined by Wilko Nienhaus, CTO of Vaimo, a consulting company in Estonia, we dive into ownership dynamics, misaligned incentives, contracting challenges, and the business pressures that shape consulting—along with practical stories from the field about what really works. The Cobbler's Shoes Problem "I come back to the office from this workshop, and suddenly, with these eyes on looking for improvements in process, I just suddenly am hit by this revelation of why things are so slow here? Why are we working so inefficiently?" Jakob describes the striking paradox many consultancies face: they excel at helping clients improve their processes while their own internal operations remain inefficient. This "shoemaker's children" phenomenon reflects a fundamental challenge in consulting—the difficulty of investing in your own improvements when all energy flows toward billable client work. Digital agencies often have outdated or poorly implemented websites despite building sophisticated solutions for others, illustrating how consultancies struggle to apply their own expertise internally. Misaligned Incentives Create Antagonistic Dynamics "It's almost as if the clients are actually paying us to be slow, because our incentive is to spend more time on achieving what the client wants, because we get paid by the hour." The incentive structures in consulting create inherent conflicts that don't exist in product companies. Consultants typically bill by the hour, creating a perverse incentive to spend more time rather than deliver efficiently. Meanwhile, clients pursue business outcomes and want results as quickly and cheaply as possible. This fundamental misalignment leads to: Clients adopting a procurement mindset, treating software development like ordering from a catalog A "wall" between stakeholders and development teams that's even stronger than in product companies Antagonistic relationships where scope changes feel like financial traps rather than necessary learning Contracting processes that reinforce waterfall thinking even when both parties claim to want agility Wilko emphasizes that contracting has a huge impact on these dynamics, and companies must deliberately change their engagement models to break free from these patterns. The Budgeting Trap and Specification Overload "Because of this budgeting process where you now need to motivate what this budget does, or you need to spend that budget, you essentially create this necessity to define everything." Consulting projects often suffer from the same problem that plagued waterfall development: annual budgeting cycles that force stakeholders to cram everything into a single specification. When there's only one chance per year to secure funding, everyone stuffs the requirements document with every conceivable feature, leading to: Massive specifications that attempt to predict all needs upfront Endless discovery meetings and documentation that add cost without improving outcomes Developers working from outdated assumptions with delayed feedback Clients who don't really know what they want but feel pressured to specify everything Jakob points out the frustration that "we've already fixed this problem" in product development through iterative approaches, yet it keeps reappearing in consulting because of the separation between entities. Ownership and Quality in Consulting Environments "Skilled engineers will be frustrated if they're not allowed to do a proper job. People that have spent a lot of time in an environment where they're never allowed to do a proper job, or maybe even punished for doing a proper job, they will have given up, and not care." The difference in ownership between product and consulting development profoundly affects how engineers think about quality, technical debt, and long-term design. In product companies, developers know they'll maintain their code, creating natural incentives for quality. In consulting, the transient nature of engagements can erode quality standards. Key challenges include: Engineers knowing they won't return to the codebase, reducing long-term thinking Clients who lack technical expertise dictating approaches they don't understand Pressure to complete fixed-scope contracts regardless of quality trade-offs The role of estimates in forcing teams to "just complete this thing" even when learning suggests changes Wilko notes that teams controlled by clients versus teams managed as stable units by the consultancy show markedly different levels of ownership and engagement. Engineers want to do great work, but without real-world feedback loops, they may either overengineer based on theoretical ideals or give up on quality entirely. Breaking the Cycle: Going Live in Two Weeks "We said to them, what if we try to actually go live in a single sprint, which in most companies is 2 weeks. And they were like, nah, we're not so sure. And we said, don't worry, you're going to get everything you want in your scope by the end. But just let's try these first 2 weeks." Wilko shares a transformative story about an e-commerce project where his team convinced a client to abandon their two-year roadmap and instead focus on going live with something—anything—in two weeks. The goal: enable one existing customer to place one order for one product they already knew. This constraint forced radical prioritization. The team didn't need images, extensive product catalogs, or elaborate descriptions. They delivered a minimal but functioning system, and the results were revelatory: The client's internal discussion shifted from "we need everything" to "what should we prioritize next?" Real customer interaction revealed unexpected problems, like internal incentive conflicts where salespeople wouldn't direct customers to the website because it threatened their commissions Senior leadership embraced the iterative approach more readily than middle management The faster feedback cycle enabled genuine agility even in a consulting context This story demonstrates that iterative approaches are more likely to lead to success in consulting, and that senior leadership is often more receptive to faster feedback cycles than people expect. The key is changing the dynamic from "deliver a complete spec" to "let's go live quickly and learn." AI as a Game-Changer for Consulting Dynamics "The groundbreaking thing that's happening right now is AI, and it really feeds into this direction. Because instead of speaking, you can actually be building, you can see things, you can do stuff that you can really test in a much more real way than you could just a few years ago." Both Jakob and Wilko see artificial intelligence as a potential solution to many consulting challenges. AI tools enable rapid prototyping and visualization, allowing teams to show rather than tell. This addresses the fundamental problem that clients don't know what they want until they see it, by dramatically reducing the cost of creating tangible demonstrations that generate meaningful feedback. If you want to know more about how AI is reshaping programming, check out our AI Assisted Coding series of episodes.  Quality and Testing Should Not Be Negotiable "I just simply think it shouldn't be a choice. We have to be very firm on this is how we work. We are the experts you are paying us." When clients ask to skip testing, reduce code reviews, or cut corners on infrastructure, Jakob argues consultancies must stand firm. Quality practices shouldn't be line items that clients can negotiate away. One consulting company that works strictly with Extreme Programming principles demonstrates this approach—they don't explain every detail to clients, but they clearly establish that "this is how we do all our projects. It's not a choice." Wilko adds that testing often saves time rather than adding cost, serving as a development tool that eliminates repetitive manual verification. The challenge comes during estimation, where padding for testing can make consultancies less competitive, creating pressure to compromise on quality. Jakob emphasizes that some responsibility lies with consultancies themselves, which sometimes over-promise and underbid to win business, then struggle to deliver quality within unrealistic constraints. This "race to the bottom" hurts the entire industry. The Path Forward: Deliberate Collaboration "It is fixable in a consultancy setting as well. I've seen it. I've been part of it. But you have to be very deliberate in your collaboration with the customer." Success in consulting requires deliberately designing the engagement model to support iterative development: Working backward from customer needs, not forward from specifications Establishing short feedback loops with both client stakeholders and end users Creating stable teams rather than assembling ad-hoc groups based on client requests Changing contracting models to align incentives (as explored in Sven Ditz's article in the Global Agile Summit book on delivering incrementally) Being firm about quality practices while remaining flexible about features Using AI and rapid prototyping to generate early, concrete feedback The consulting model doesn't have to default to waterfall, but it requires conscious effort to overcome the structural forces pushing in that direction. Recommended Reading In this episode, we refer to multiple resources for further reading. Here's a list of those resources:  Secrets of Consulting by Gerald Weinberg The Global Agile Summit book, including articles by the speakers at the conference Real World Agility by Daniel Gullo The #NoEstimates book by Vasco Duarte Extreme Programming principles About Jakob Wolman and Wilko Nienhaus Jakob Wolman is an experienced engineering leader who knows how to build great software, and how to mess it up. He has worked in both product companies and consulting environments, giving him unique insight into the contrasts between these models. You can connect with Jakob Wolman on LinkedIn. Wilko Nienhaus is CTO of Vaimo, a consulting company in Estonia, where he focuses on the challenges of delivering software in a consulting environment. He concentrates on delivery mechanisms and technical solutions for challenging projects. You can connect with Wilko Nienhaus on LinkedIn.

AI Assisted Coding: From Deterministic to AI-Driven—The New Paradigm of Software Development, With Markus Hjort In this BONUS episode, we dive deep into the emerging world of AI-assisted coding with Markus Hjort, CTO of Bitmagic. Markus shares his hands-on experience with what's being called "vibe coding" - a paradigm shift where developers work more like technical product owners, guiding AI agents to produce code while focusing on architecture, design patterns, and overall system quality. This conversation explores not just the tools, but the fundamental changes in how we approach software engineering as a team sport. Defining Vibecoding: More Than Just Autocomplete "I'm specifying the features by prompting, using different kinds of agentic tools. And the agent is producing the code. I will check how it works and glance at the code, but I'm a really technical product owner." Vibecoding represents a spectrum of AI-assisted development approaches. Markus positions himself between pure "vibecoding" (where developers don't look at code at all) and traditional coding. He produces about 90% of his code using AI tools, but maintains technical oversight by reviewing architectural patterns and design decisions. The key difference from traditional autocomplete tools is the shift from deterministic programming languages to non-deterministic natural language prompting, which requires an entirely different way of thinking about software development. The Paradigm Shift: When AI Changed Everything "It's a different paradigm! Looking back, it started with autocomplete where Copilot could implement simple functions. But the real change came with agentic coding tools like Cursor and Claude Code." Markus traces his journey through three distinct phases. First came GitHub Copilot's autocomplete features for simple functions - helpful but limited. Next, ChatGPT enabled discussing architectural problems and getting code suggestions for unfamiliar technologies. The breakthrough arrived with agentic tools like Cursor and Claude Code that can autonomously implement entire features. This progression mirrors the historical shift from assembly to high-level languages, but with a crucial difference: the move from deterministic to non-deterministic communication with machines. Where Vibecoding Works Best: Knowing Your Risks "I move between different levels as I go through different tasks. In areas like CSS styling where I'm not very professional, I trust the AI more. But in core architecture where quality matters most, I look more thoroughly." Vibecoding effectiveness varies dramatically by context. Markus applies different levels of scrutiny based on his expertise and the criticality of the code. For frontend work and styling where he has less expertise, he relies more heavily on AI output and visual verification. For backend architecture and core system components, he maintains closer oversight. This risk-aware approach is essential for startup environments where developers must wear multiple hats. The beauty of this flexibility is that AI enables developers to contribute meaningfully across domains while maintaining appropriate caution in critical areas. Teaching Your Tools: Making AI-Assisted Coding Work "You first teach your tool to do the things you value. Setting system prompts with information about patterns you want, testing approaches you prefer, and integration methods you use." Success with AI-assisted coding requires intentional configuration and practice. Key strategies include: System prompts: Configure tools with your preferred patterns, testing approaches, and architectural decisions Context management: Watch context length carefully; when the AI starts making mistakes, reset the conversation Checkpoint discipline: Commit working code frequently to Git - at least every 30 minutes, ideally after every small working feature Dual AI strategy: Use ChatGPT or Claude for architectural discussions, then bring those ideas to coding tools for implementation Iteration limits: Stop and reassess after roughly 5 failed iterations rather than letting AI continue indefinitely Small steps: Split features into minimal increments and commit each piece separately In this segment we refer to the episode with Alan Cyment on AI Assisted Coding, and the Pachinko coding anti-pattern.  Team Dynamics: Bigger Chunks and Faster Coordination "The speed changes a lot of things. If everything goes well, you can produce so much more stuff. So you have to have bigger tasks. Coordination changes - we need bigger chunks because of how much faster coding is." AI-assisted coding fundamentally reshapes team workflows. The dramatic increase in coding speed means developers need larger, more substantial tasks to maintain flow and maximize productivity. Traditional approaches of splitting stories into tiny tasks become counterproductive when implementation speed increases 5-10x. This shift impacts planning, requiring teams to think in terms of complete features rather than granular technical tasks. The coordination challenge becomes managing handoffs and integration points when individuals can ship significant functionality in hours rather than days. The Non-Deterministic Challenge: A New Grammar "When you're moving from low-level language to higher-level language, they are still deterministic. But now with LLMs, it's not deterministic. This changes how we have to think about coding completely." The shift to natural language prompting introduces fundamental uncertainty absent from traditional programming. Unlike the progression from assembly to C to Python - all deterministic - working with LLMs means accepting probabilistic outputs. This requires developers to adopt new mental models: thinking in terms of guidance rather than precise instructions, maintaining checkpoints for rollback, and developing intuition for when AI is "hallucinating" versus producing valid solutions. Some developers struggle with this loss of control, while others find liberation in focusing on what to build rather than how to build it. Code Reviews and Testing: What Changes? "With AI, I spend more time on the actual product doing exploratory testing. The AI is doing the coding, so I can focus on whether it works as intended rather than syntax and patterns." Traditional code review loses relevance when AI generates syntactically correct, pattern-compliant code. The focus shifts to testing actual functionality and user experience. Markus emphasizes: Manual exploratory testing becomes more important as developers can't rely on having written and understood every line Test discipline is critical - AI can write tests that always pass (assert true), so verification is essential Test-first approach helps ensure tests actually verify behavior rather than just existing Periodic test validation: Randomly modify test outputs to verify they fail when they should Loosening review processes to avoid bottlenecks when code generation accelerates dramatically Anti-Patterns and Pitfalls to Avoid Several common mistakes emerge when developers start with AI-assisted coding: Continuing too long: When AI makes 5+ iterations without progress, stop and reset rather than letting it spiral Skipping commits: Without frequent Git checkpoints, recovery from AI mistakes becomes extremely difficult Over-reliance without verification: Trusting AI-generated tests without confirming they actually test something meaningful Ignoring context limits: Continuing to add context until the AI becomes confused and produces poor results Maintaining traditional task sizes: Splitting work too granularly when AI enables completing larger chunks Forgetting exploration: Reading about tools rather than experimenting hands-on with your own projects The Future: Autonomous Agents and Automatic Testing "I hope that these LLMs will become larger context windows and smarter. Tools like Replit are pushing boundaries - they can potentially do automatic testing and verification for you." Markus sees rapid evolution toward more autonomous development agents. Current trends include: Expanded context windows enabling AI to understand entire codebases without manual context curation Automatic testing generation where AI not only writes code but also creates and runs comprehensive test suites Self-verification loops where agents test their own work and iterate without human intervention Design-to-implementation pipelines where UI mockups directly generate working code Agentic tools that can break down complex features autonomously and implement them incrementally The key insight: we're moving from "AI helps me code" to "AI codes while I guide and verify" - a fundamental shift in the developer's role from implementer to architect and quality assurance. Getting Started: Experiment and Learn by Doing "I haven't found a single resource that covers everything. My recommendation is to try Claude Code or Cursor yourself with your own small projects. You don't know the experience until you try it." Rather than pointing to comprehensive guides (which don't yet exist for this rapidly evolving field), Markus advocates hands-on experimentation. Start with personal projects where stakes are low. Try multiple tools to understand their strengths. Build intuition through practice rather than theory. The field changes so rapidly that reading about tools quickly becomes outdated - but developing the mindset and practices for working with AI assistance provides durable value regardless of which specific tools dominate in the future. About Markus Hjort Markus is Co-founder and CTO of Bitmagic, and has over 20 years of software development expertise. Starting with Commodore 64 game programming, his career spans gaming, fintech, and more. As a programmer, consultant, agile coach, and leader, Markus has successfully guided numerous tech startups from concept to launch. You can connect with Markus Hjort on LinkedIn.

AI Assisted Coding: Pachinko Coding—What They Don't Tell You About Building Apps with Large Language Models, With Alan Cyment In this BONUS episode, we dive deep into the real-world experience of coding with AI. Our guest, Alan Cyment, brings honest perspectives from the trenches—sharing both the frustrations and breakthroughs of using AI tools for software development. From "Pachinko coding" addiction loops to "Mecha coding" breakthroughs, Alan explores what actually works when building software with large language models. From Thermomix Dreams to Pachinko Reality "I bought into the Thermomix coding promise—describe the whole website and it would spit out the finished product. It was a complete disaster." Alan started his AI coding journey with high expectations, believing he could simply describe a complete application and receive production-ready code. The reality was far different. What he discovered instead was an addictive cycle he calls "Pachinko coding" (Pachinko, aka Slot Machines in Japan)—repeatedly feeding error messages back to the AI, hoping each iteration would finally work, while burning through tokens and time. The AI's constant reassurances that "this time I fixed it" created a gambling-like feedback loop that left him frustrated and out of pocket, sometimes spending over $20 in API credits in a single day. The Drunken PhD with Amnesia "It felt like working with a drunken PhD with amnesia—so wise and so stupid at the same time." Alan describes the maddening experience of anthropomorphizing AI tools that seem brilliant one moment and completely lost the next. The key breakthrough came when he stopped treating the AI as a person and started seeing it as a function that performs extrapolations—sometimes accurate, sometimes wildly wrong. This mental shift helped him manage expectations and avoid the "rage coding" that came from believing the AI should understand context and maintain consistency like a human collaborator. Making AI Coding Actually Work "I learned to ask for options explicitly before any coding happens. Give me at least three options and tell me the pros and cons." Through trial and error, Alan developed practical strategies that transformed AI from a frustrating Pachinko machine into a useful tool: Ask for options first: Always request multiple approaches with pros and cons before any code is generated Use clover emoji convention: Implement a consistent marker at the start of all AI responses to track context Small steps and YAGNI principles: Request tiny, incremental changes rather than large refactoring Continuous integration: Demand the AI run tests and checks after every single change Explicit refactoring requests: Regularly ask for simplification and readability improvements Take two steps back: When stuck in a loop, explicitly tell the AI to simplify and start fresh Choose the right tech stack: Use technologies with abundant training data (like Svelte over React Native in Alan's experience) The Mecha Coding Breakthrough "When it worked, I felt like I was inside a Lego Mecha robot—the machine gave me superpowers, but I was still the one in control." Alan successfully developed a birthday reminder app in Swift in just one day, despite never having learned Swift. He made architectural decisions and guided the development without understanding the syntax details. This experience convinced him that AI represents a genuine new level of abstraction in programming—similar to the jump from assembly language to high-level languages, or from procedural to object-oriented programming. You can now think in English about what you want, while the AI handles the accidental complexity of syntax and boilerplate. The Cost Reality Check "People writing about vibe coding act like it's free. But many people are going to pay way more than they would have paid a developer and end up with empty hands." Alan provides a sobering cost analysis based on his experience. Using DeepSeek through Aider, he typically spends under $1 per day. But when experimenting with premium models like Claude Sonnet 3.5, he burned through $5 in just minutes. The benchmark comparisons are revealing: DeepSeek costs $4 for a test suite, DeepSeek R1 plus Sonnet costs $16, while Open AI's O1 costs $190. For non-developers trying to build complete applications through pure "vibe coding," the costs can quickly exceed what hiring a developer would cost—with far worse results. When Thermomix Actually Works "For small, single-purpose scripts that I'm not interested in learning about and won't expand later, the Thermomix experience was real." Despite the challenges, Alan found specific use cases where AI truly delivers on the "just describe it and it works" promise. Processing Zoom attendance logs, creating lookup tables for video effects, and other single-file scripts worked remarkably well. The pattern: clearly defined context, no need for ongoing maintenance, and simple enough to verify the output without deep code inspection. For these thermomix moments, AI proved genuinely transformative. The Pachinko Trap and Tech Stack Matters "It became way more stable when I switched to Svelte from React Native and Flutter, even following the same prompting practices. The AI is just more proficient in certain tech stacks." Alan discovered that some frameworks and languages work dramatically better with AI than others, likely due to the amount of training data available. His e-learning platform attempts with React Native and Flutter kept breaking, but switching to Svelte with web-based deployment became far more stable. This suggests a crucial strategy: choose mainstream, well-documented technologies when planning AI-assisted projects. From Coding to Living with AI Alan has completely stopped using traditional search engines, relying instead on LLMs for everything from finding technical documentation to getting recommendations for books based on his interests. While he acknowledges the risk of hallucinations, he finds the semantic understanding capabilities too valuable to ignore. He's even used image analysis to troubleshoot his father's cable TV problems and figure out hotel air conditioning controls. The Agile Validation "My only fear is confirmation bias—but the conclusion I see other experienced developers reaching is that the only way to make LLMs work is by making them use agility. So look at who's dead now." Alan notes the irony that the AI coding tools that actually work all require traditional software engineering best practices: small iterations, test-driven development, continuous integration, and explicit refactoring. The promise of "just describe what you want" falls apart without these disciplines. Rather than replacing software engineering principles, AI tools seem to validate their importance. About Alan Cyment Alan Cyment is a consultant, trainer, and facilitator based in Buenos Aires, specializing in organizational fluency, agile leadership, and software development culture change. A Certified Scrum Trainer with deep experience across Latin America and Europe, he blends agile coaching with theatre-based learning to help leaders and teams transform. You can link with Alan Cyment on LinkedIn.

AI Assisted Coding: Agile Meets AI—How to Code Fast Without Breaking Things, With Llewellyn Falco In this BONUS episode we explore the practice of coding with AI—not just the buzzwords, but the real-world experience. Our guest, Llewellyn Falco, has been learning by doing, exploring the space of AI-assisted coding from the experimental and intuitive—what some call vibecoding—to the more structured world of professional, world-class software engineering. This is a conversation for practitioners who want to understand what's actually happening on the ground when we code with AI. Understanding Vibecoding "You can now program without looking at code. When you're in that space, vibecoding is the word we're using to say, we are programming in a way that does not relate to programming last year." The software development landscape shifted dramatically in early 2025. Vibecoding represents a fundamental change in how we create software—programming without constantly looking at the code itself. This approach removes many traditional limitations around technology, language, and device constraints, allowing developers to move seamlessly between different contexts. However, this power comes with responsibility, as developers can now move so fast that traditional safety practices become even more critical. From Concept to Working App in 15 Minutes "We wrote just a markdown page of ‘here's what we want this to look like'. And then we fed that to Claude Code. And 15 minutes later we had a working app on the phone." At the Agile 2025 conference in Denver, Llewellyn participated in a hackathon focused on helping psychologists prevent child abuse. Working with customer Amanda, a psychologist, and data scientist Rachel, the team identified a critical problem: clinicians weren't using the most effective parenting intervention technique because recording 60 micro-interactions in 5 minutes was too difficult and time-consuming. The team's approach embodied lean startup principles turned up to eleven. After understanding the customer's needs through exposition and conversation, they created a simple markdown specification and used Claude Code to generate a working mobile app in just 15 minutes. When Amanda tested it, she was moved to tears—after 20 years of trying to make progress on this problem, she finally had hope. Over three days, the team released 61 iterations, constantly getting feedback and refining the solution. Iterative Development Still Matters When Coding With AI "We need to see things working to know what to deliver next. That's never going to change. Unless you're building something that's already there." The team's success wasn't about writing a complete requirements document upfront. Instead, they delivered a minimal viable product quickly, tested it with real users, and iterated based on feedback. This agile approach proved essential even—or especially—when working with AI. One breakthrough came when Amanda used the number keypad instead of looking at her phone screen. With her full attention on the training video she'd watched hundreds of times, she noticed an interaction she had missed before. At that moment, the team knew they had created real value, regardless of what additional features they might build. Good Engineering Practices Without Looking at Code "We asked it to do good engineering practices, even though we didn't really understand what it was doing. We just sort of say, okay, yeah, that seems sensible." A critical moment came when the code had grown large and complex. Rather than diving into the code themselves, Llewellyn and his partner Lotta asked the AI to refactor the code to make a panel easy to switch before actually making the change. They verified functionality worked through manual testing but never looked at how the refactoring was implemented. This demonstrates that developers can maintain good practices like refactoring and clean architecture even when working at a higher level of abstraction. Key practices for AI-assisted development include: Don't accept AI's default settings—they're based on popularity, not best practices Prime the AI with the practices you want it to use through configuration files Tell AI to be honest and help you avoid mistakes, not just be agreeable Ask for explanations of architecture and evaluate whether approaches make sense Keep important decisions documented in markdown files that can be referenced later “The documentation is now executable. I can turn it into code” "The documentation is now executable. I can turn it into code. If I had to choose between losing my documentation or losing my code, I would keep the docs. I think I could regenerate the code pretty easily." In this new paradigm, documentation takes on new importance—it becomes the specification from which code can be regenerated. The team created and continuously updated markdown files for project context, architecture, and individual features. This practice allowed them to reset AI context when needed while maintaining continuity of their work. The workflow was bidirectional: sometimes they'd write documentation first and have AI generate code; other times they'd build features iteratively and have AI update the documentation. This approach using tools like Super Whisper for voice-to-text made creating and maintaining documentation effortless. Remove Deterministic Tasks from AI "AI is sloppy. It's inconsistent. Everything that can be deterministic—take it out. AI can write that code. But don't make AI do repetitive tasks." A crucial principle emerged: anything that needs to be consistently and repeatedly correct should be automated with traditional code, not left to AI. The team wrote shell scripts for tasks like auto-incrementing version numbers and created git hooks to ensure these scripts ran automatically. They also automated file creation with dates at the top, removing the need for AI to track temporal information. This principle works both ways—deterministic logic should be removed from underneath AI (via scripts and hooks) and from above AI (via orchestration scripts that call AI in loops with verification steps in between). Anti-Patterns to Avoid "The biggest anti-pattern is you're not committing frequently. I really want the ability to drop my context and revert my changes at a moment's notice." The primary anti-pattern when coding with AI is failing to commit frequently to version control. The ability to quickly drop context, revert changes, and start fresh becomes essential when working at this pace. Getting important decisions into documentation files and code into version control enables rapid experimentation without fear of losing work. Other challenges include knowing when to focus on the right risks. The team had to navigate competing priorities—customers wanted certain UX features, but the team identified data collection and storage as the critical unknown risk that needed solving first. This required diplomatic firmness in prioritizing work based on technical risk assessment rather than just user requests. Essential Tools for AI-Assisted Development "If you are using AI by going to a website, that is not what we are talking about here." To work effectively with AI, developers need agentic tools that can interact with files and run programs, not just chat interfaces. Recommended tools include: Claude Code (CLI for file interaction) Windsurf (VS Code-like interface) Cursor (code editor with AI integration) RooCode (alternative option) Super Whisper (voice-to-text transcription for Mac) Most developers working at this level have disabled safety guards, allowing AI to run programs without asking permission each time. While this carries risks, committing frequently to version control provides the safety net needed for rapid experimentation. The Power of Voice Interaction "Most of the time coding now looks like I'm talking. It's almost like Star Trek—you're talking to the computer and then code shows up." Using voice transcription tools like Super Whisper transformed the development experience. Speaking instead of typing not only increased speed but also changed the nature of communication with AI. When speaking, developers naturally provide more context and explanation than when typing, leading to better results from AI systems. This proved especially valuable in a crowded conference room where Super Whisper could filter out background noise and accurately transcribe the speakers' voices. The tool enabled natural, conversational interaction with development tools. Balancing Speed with Safety Over three days, the team released 61 times without comprehensive automated testing, focusing instead on validating user value through manual testing with the actual customer. However, after the hackathon, Llewellyn added automated testing by creating a test plan document through voice dictation, having AI clean it up and expand it, then generating Puppeteer tests and shell scripts to run them—all in about 40 minutes. This demonstrates a pragmatic approach: when exploring and validating with users, manual testing may suffice; but for ongoing maintenance and confidence, automated tests remain valuable and can be generated efficiently with AI assistance. The Future of Software Development "If you want to make something, there could not be a better time than now." The skills required for effective software development are shifting. Understanding how to assess risk, knowing when to commit code, maintaining good engineering practices, and finding creative solutions within system constraints remain critical. What's changing is that these skills are now applied at a higher level of abstraction, with AI handling much of the detailed implementation. The space is evolving rapidly—practices that work today may need adjustment in months. Developers need to continuously experiment, stay current with new tools and models, and develop instincts for working effectively with AI systems. The fundamentals of agile development—rapid iteration, customer feedback, risk assessment, and incremental delivery—matter more than ever. About Llewellyn Falco Llewellyn is an Agile and XP (Extreme Programming) expert with over two decades of experience in Java, OO design, and technical practices like TDD, refactoring, and continuous delivery. He specializes in coaching, teaching, and transforming legacy code through clean code, pair programming, and mob programming. You can link with Llewellyn Falco on LinkedIn.

AI Assisted Coding: Beyond AI Code Assistants: How Moldable Development Answers Questions AI Can't With Tudor Girba In this BONUS episode, we explore Moldable Development with Tudor Girba, CEO of feenk.com and creator of the Glamorous Toolkit. We dive into why developers spend over 50% of their time reading code—not because they want to, but because they lack the answers they need. Tudor shares how building contextual tools can transform software development, making systems truly understandable and enabling decisions at the speed of thought. The Hidden System: A Telco's Three-Year Quest "They had a system consisting of five boxes, but they could only enumerate four. If this is your level of awareness about what is reality around you, you have almost no chance of systematically affecting that reality." Tudor opens with a striking case study from a telecommunications company that spent three years and hundreds of person-years trying to optimize a data pipeline. Despite massive effort and executive mandate, the pipeline still took exactly one day to process data—no improvement whatsoever. When Tudor's team investigated, they asked for an architecture diagram. The team drew four boxes representing their system. But when Tudor's team started building tools to mirror this architecture back from the actual code, they discovered something shocking: there was an entire fifth system between the first and second boxes that nobody knew existed. This missing system was likely the bottleneck they'd been trying to optimize for three years. Why Reading Code Doesn't Scale "Developers spend more than 50% of their time reading code. The problem is that our systems are typically larger than anyone can read, and by the time you finish reading, the system has already changed many times." The real issue isn't the time spent reading—it's that reading is the most manual, least scalable way to extract information from systems. When developers read code, they're actually trying to answer questions so they can make decisions. But a 250,000-line system would take one person-month to read at high speed, and the system changes constantly during that time. This means everything you learned yesterday becomes merely a hypothesis, not a reliable answer. The fundamental problem is that we cannot perceive anything in a software system except through tools, yet we've never made how we read code an explicit, optimizable activity. The Context Problem: Why Generic Tools Fail "Software is highly contextual, which means we can predict classes of problems people will have, but we cannot predict specific problems people will have." Tudor draws a powerful parallel with testing. Nobody downloads unit tests from the web and applies them to their system—that would be absurd. Instead, we download test frameworks and build tests contextually for our specific system, encoding what's valuable about our particular business logic. Yet for almost everything else in software development, we download generic tools and expect them to work. This is why teams have tens of thousands of static analysis warnings they ignore, while a single failing test stops deployment. The test encodes contextual value; the generic warning doesn't. Moldable Development extends this principle: every question about your system should be answered by a contextual tool you build for that specific question. Tools That Mirror Your Mental Model "Whatever you draw on the whiteboard—that's your mental model. But as soon as the system exists, we want the system to mirror you back that thing. We make it the job of the system to show our mental model back to us." When someone draws an architecture diagram on a whiteboard, they're not documenting the system—they're documenting their beliefs about the system. The diagram represents wishes when drawn before the system exists, but beliefs when drawn after. Moldable Development flips this: instead of humans reading code and creating approximations, the system itself generates the visualization directly from the actual code. This eliminates the layers of belief and inference. Whether you're looking at high-level architecture, data lineage across multiple technologies, performance bottlenecks, or business domain structure, you build small tools that extract and present exactly the information you need from the system as it actually is. The Test-Driven Development Parallel "Testing was a way to find some kind of class of answers. But there are many other questions we have, and the question is: is there a systematic way to approach arbitrary questions?" Tudor explains that Moldable Development applies test-driven development principles to all forms of system understanding. Just as we write tests after we understand the functionality we need, we build visualization and analysis tools after we understand the questions we need answered. Both approaches share key characteristics: they're built contextually for the specific system, created by developers during development, and composed of many small tools that collectively model the system. The difference is that TDD focuses on functional decomposition and known expectations, while Moldable Development addresses architecture, security, domain structure, performance, and any other perspective where functional tests aren't the most useful decomposition. From Thousands of Features to Thousands of Tools "In my development environment, I don't have features. I have thousands of tools that coexist. Development environments should be focused not on what exists out of the box, but on how quickly you can create a contextual tool." Traditional development environments offer dozens of features—buttons, plugins, generic views. But Moldable Development environments contain thousands of micro-tools, each answering a specific question about a specific system. The key is making these tools composable and fast to create. Rather than building monolithic tools that try to handle every scenario, you build small inspectors that show one perspective on one object or concept. These inspectors chain together naturally as you drill down from high-level questions to detailed investigations. You might have one inspector showing test failures grouped by exception type, another showing PDF document comparisons, another showing cluster performance, and another showing memory usage—all coexisting and available when needed. The Real Bottleneck To Learning A System: Time to the Next Question "Once you do this, you will see that the interesting bottleneck is in the time to the next interesting question. This is by far the most interesting place to be spending energy." When you commoditize access to answers through contextual tools, something remarkable happens: the bottleneck shifts from getting answers to asking better questions. Right now, because answers come so slowly through manual reading and analysis, we rarely exercise the skill of formulating good questions. We make decisions based on gut feelings and incomplete data because we can't afford to dig deeper. But when answers arrive at the speed of thought, you can explore, follow hunches, test hypotheses, and develop genuine insight. The conversation between person and system becomes fluid, enabling decision-making based on actual evidence rather than belief. Moldable Development in Practice: The Lifeware Case "They are investing in software engineering as their competitive advantage. They have 150,000 tests that would take 10 days to run on a single machine, but they run them in 16 minutes distributed across AWS." Tudor shares a powerful case study of Lifeware, a life insurance software company that was featured in Kent Beck's "Test-Driven Development by Example" in 2002 with 4,000 tests. Today they have 150,000 tests and have fully adopted Moldable Development as their core practice. Their business model is remarkable: they take data from insurance companies, throw away the old systems, and reverse-engineer new systems by TDD-ing the business—replaying history to produce pixel-identical documents. They've deployed Glamorous Toolkit as their sole development environment across 100+ developers. Their approach demonstrates that Moldable Development isn't just a research concept but a practical competitive advantage that scales to large teams and complex systems. Why AI Doesn't Solve This Problem "When you ask AI, you will get exactly the same kind of answers. The answer comes quickly, but you will not know whether this is accurate, whether this represents the whole thing, and you definitely do not have an explanation as to why the answer is the way it is." In the age of AI code assistants, it might seem like language models could solve the problem of understanding systems. But Tudor explains why they can't. When you ask an AI about your architecture, you get an opinion—fast but unverifiable. Just like asking a developer to draw the architecture on a whiteboard, you receive filtered information without knowing if it's complete or accurate. Moldable Development, by contrast, extracts answers deterministically from the actual system. Software systems have almost no ambiguity in meaning—they're mathematical, not linguistic. We don't need probabilistic interpretation of source code; we need precise extraction and presentation. The tools you build give you not just answers but explanations of how those answers were derived from the actual system state. Scaling Through Language, Not Features "You need a new kind of development environment where the goal is to create tools much quicker. You need some sort of language in which to express development environments." The technical challenge of Moldable Development is enabling thousands of tools to coexist productively. This requires a fundamentally different approach to development environments. Instead of adding features—buttons and menu items that quickly become overwhelming—you need a language for expressing tools and a system for composing them. Glamorous Toolkit demonstrates this through its inspector architecture, where any object can define custom views that appear contextually. These views compose naturally as you navigate through your investigation, reusing earlier perspectives while adding new ones. The environment becomes a medium for tool creation, not just a collection of pre-built features. Making the Invisible Visible "We cannot perceive anything in a software system except through a tool. If that's so important, then the ability to control that shape is probably kind of important too." Software has no inherent shape—it's just data. Every perception we have of it comes through some tool that renders it into a form we can reason about. This means tools aren't nice-to-have accessories; they're fundamental to our ability to work with software at all. The text editor showing code is a tool. The debugger showing variables is a tool. But these are generic tools built once and reused everywhere, which means they show generic perspectives. What if we could control the shape of our software as easily as we write it? What if the system could show us exactly the view we need for exactly the question we have? That's the promise of Moldable Development. About Tudor Girba Tudor Girba is CEO of feenk.com and creator of Moldable Development. He leads the team behind Glamorous Toolkit, a novel IDE that helps developers make sense of complex systems. His work focuses on transforming how teams understand, navigate, and modernize legacy software through custom, insightful tools. Tudor and Simon Wardley are writing a book about Moldable Development which you can get at: https://moldabledevelopment.com/, and read more about in this Medium article. You can link with Tudor Girba on LinkedIn.

Tom Molenaar: When Product Owners “Eat the Grass” for Their Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Vision Catalyst "This PO had the ability to communicate the vision and enthusiasm about the product, even I felt inspired." Tom describes an exceptional Product Owner who could communicate vision and enthusiasm so effectively that even he, as the Scrum Master, felt inspired about the product. This PO excelled at engaging teams in product discovery techniques, helping them move from merely delivering features to taking outcome responsibility. The PO introduced validation techniques, brought customers directly to the office for interviews, and consistently showed the team the impact of their work, creating a strong connection between engineers and end users. The Bad Product Owner: The Micromanager "This PO was basically managing the team with micro-managing approach, this blocked the team from self-organizing." Tom encountered a Product Owner who was too controlling, essentially micromanaging the team instead of empowering them. This PO hosted daily stand-ups, assigned individual tasks, and didn't give the team space for self-organization. When Tom investigated the underlying motivation, he discovered the PO believed that without tight control, the team would underperform. Tom helped the PO understand the benefits of trusting the team and worked with both sides to clarify roles and responsibilities, moving from micromanagement to empowerment. In this segment, we refer to the book “Empowered” by Marty Cagan. Self-reflection Question: How do you help Product Owners find the balance between providing clear direction and allowing team autonomy? [The Scrum Master Toolbox Podcast Recommends]

Tom Molenaar: Purpose, Process, and People—The Three Pillars of Scrum Master Success Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "I always try to ask the team first, what is your problem? Or what is the next step, do you think? Having their input, having my input, bundle it and share it." Tom defines success for Scrum Masters through three essential pillars: purpose (achieving the team's product goals), process (effective Agile practices), and people (team maturity and collaboration). When joining new teams, he uses a structured approach combining observation with surveys to get a 360-degree view of team performance. Rather than immediately implementing his own improvement ideas, Tom prioritizes asking teams what problems they want to solve and finding common ground for a "handshake moment" on what needs to be addressed. Featured Retrospective Format for the Week: Creative Drawing of the Sprint Tom's favorite retrospective format involves having team members draw their subjective experience of the sprint, then asking others to interpret each other's drawings. This creative approach brings people back to their childhood, encourages laughter and fun, and helps team members tap into each other's experiences in ways that traditional verbal retrospectives cannot achieve. The exercise stimulates understanding between team members and often reveals important topics for improvement while building connection through shared interpretation of creative expressions. Example activity you can use to “draw the sprint”.  [The Scrum Master Toolbox Podcast Recommends]

Tom Molenaar: Systemic Change Management—Making the Emotional Side of Change Visible 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 tend to skip the phase where we just give the person the space to grieve, to not know, instead of that, we tend to move to solutions maybe too quick." Tom faces a significant challenge as he prepares to start with new teams transitioning between value streams in a SAFe environment. The teams will experience multiple changes simultaneously - new physical locations, new team dependencies, and organizational restructuring. Tom applies systemic change management principles, outlining five critical phases: sense of urgency, letting go, not knowing, creation, and new beginning. He emphasizes the importance of making the emotional "understream" visible, giving teams space to grieve their losses, and helping them verbalize their feelings before moving toward solutions. In this episode, we refer to Systemic Change Management, an approach that views organizations as complex, interconnected systems—rather than collections of independent parts. Instead of focusing only on individual skills, isolated processes, or top-down directives, SCM works with the whole system (people, structures, culture, and external environment) to create sustainable transformation. Self-reflection Question: How comfortable are you with sitting in uncertainty and allowing teams to process change without immediately jumping to solutions? [The Scrum Master Toolbox Podcast Recommends]

Tom Molenaar: How to Spot and Fix Lack of Trust in Scrum 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. "When people don't speak up, it's because there's no trust. The team showed that they did not feel free to express their opinions." Tom describes working with a team that appeared to be performing well on the surface - they were reaching their goals and had processes in place. However, deeper observation revealed a troubling dynamic: a few dominant voices controlled discussions while half the team remained silent during ceremonies. Through one-on-ones, Tom discovered team members felt judged and unsafe to express their ideas. Using the Lencioni Pyramid as a framework, he helped the team address the fundamental lack of trust that was preventing constructive conflict and genuine collaboration. Featured Book of the Week: Empowered by Marty Cagan Tom recommends "Empowered" by Marty Cagan as a book that significantly influenced his approach to team coaching. The book focuses on empowering teams and organizations to deliver great products while developing ordinary people into extraordinary performing teams. Tom appreciates its well-structured approach that covers all necessary elements without getting lost in details. The book provides practical tools for effective coaching, including techniques for regular one-on-ones, active listening, constructive feedback, setting clear expectations, celebrating success, and creating a culture of learning from failure. [The Scrum Master Toolbox Podcast Recommends]

Tom Molenaar: When To Stop Helping Agile Teams To Change—A Real Life Story 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. "Instead of slowing down and meeting the team in their resistance, I started to try and drag them because I saw the vision of the possible improvement, but they did not see it." Tom shares a powerful failure story about a team that didn't feel the urgency to improve their way of working. Despite management wanting the team to become more effective, Tom found himself pushing improvements that the team actively resisted. Instead of slowing down to understand their resistance, he tried to drag them forward, leading to exhaustion and ultimately his decision to leave the assignment. This episode explores the critical lesson that it's not our job to save teams that don't want to be saved, and the importance of recognizing when to step back. Self-reflection Question: When you encounter team resistance to change, how do you distinguish between healthy skepticism that needs addressing and fundamental unwillingness to improve? [The Scrum Master Toolbox Podcast Recommends]

BONUS: Nesrine Changuel shares how to create product delight through emotional connection! In this BONUS episode we explore the book by Nesrine Changuel: 'Product Delight - How to make your product stand out with emotional connection.' In this conversation, we explore Nesrine's journey from research to product management, share lessons from her experiences at Google, Spotify, and Microsoft, and unpack the key strategies for building emotionally resonant products that connect with users beyond mere functionality. The Genesis of Product Delight "I quickly realized that there is something that is quite intense while building Skype... it's not just that communication tool, but it was iconic, with its blue, with ringtones, with emojis. So it was clear that it's not just for making calls, but also to make you feel connected, relaxed, and part of it." Nesrine's journey into product delight began during her transition from research to product management at Skype. Working on products at major companies like Skype, Spotify, and Google Meet, she discovered that successful products don't just function well—they create emotional connections. Her role as "Delight PM" at Google Meet during the pandemic crystallized her understanding that products must address both functional and emotional user needs to truly stand out in the market. Understanding Customer Delight in Practice "The delight is about creating two dimensions and combining these two dimensions altogether, it's about creating products that function well, but also that help with the emotional connection." Customer delight manifests when products exceed expectations and anticipate user needs. Nesrine explains that delight combines surprise and joy—creating positive surprises that go beyond basic functionality. She illustrates this with Microsoft Edge's coupon feature, which proactively suggests discounts during online shopping without users requesting it. This anticipation of needs creates memorable peak moments that strengthen emotional connections with products. Segmenting Users by Motivators "We can discover that users are using your product for different reasons. I mean, we tend to think that users are using the product for the same reason." Traditional user segmentation focuses on demographics (who users are) or behavior (what they do). Nesrine advocates for motivational segmentation—understanding why users engage with products. Using Spotify as an example, she demonstrates how users might seek music for specific songs, inspiration, nostalgia, or emotional regulation. This approach reveals both functional motivators (practical needs) and emotional motivators (feelings users want to experience), enabling teams to build features aligned with user desires rather than assumptions. In this segment, we refer to Spotify Wrapped.  The Distinction from Jobs To Be Done "There's no contrast. I mean to be honest, it's quite aligned, and I'm a big fan of the job to be done framework." While aligned with Clayton Christensen's Jobs To Be Done framework, Nesrine's approach extends beyond identifying triggers to practical implementation. She acknowledges that Jobs To Be Done provides the foundational theory, distinguishing between personal emotional motivators (how users want to feel) and social emotional motivators (how they want others to perceive them). However, many teams struggle to translate these insights into actual product features—a gap her Product Delight framework addresses through actionable methodologies. Navigating the Line Between Delight and Addiction "Building for delight is about creating products that are aligned with users' values. It's about aligning with what people really want themselves to feel. They want to feel themselves, to feel a better version of themselves." The critical distinction between delight and addiction lies in value alignment. Delightful products help users become better versions of themselves and align with their personal values. Nesrine contrasts this with addictive design that creates dependencies contrary to user wellbeing. Using Spotify Wrapped as an example, she explains how reflecting positive achievements (skills learned, personal growth) creates healthy engagement, while raw usage data (hours spent) might trigger negative self-reflection and potential addictive patterns. Getting Started with Product Delight "If you only focus on the functional motivators, you will create products that function, but they will not create that emotional connection. If you take into consideration the emotional motivators in addition to the functional motivators, you create perfect products that connect with users emotionally." Teams beginning their delight journey should start by identifying both functional and emotional user motivators through direct user conversations. The first step involves listing what users want to accomplish (functional) alongside how they want to feel (emotional). This dual understanding enables feature development that serves practical needs while creating positive emotional experiences, leading to products that users remember and recommend. Product Delight and Human-Centered Design "Making products feel as if it was done by a human being... how can you make your product feel as close as possible to a human version of the product." Nesrine positions product delight within the broader human-centered design movement, but focuses specifically on humanization at the product feature level rather than just visual design. She shares examples from Google Meet, where the team compared remote meetings to in-person experiences, and Dyson, which benchmarks vacuum cleaners against human cleaning services. This approach identifies missing human elements and guides feature development toward more natural, intuitive interactions. In this segment we refer to the books Emotional Design by Don Norman, and Design for Emotion by Aarron Walter..  AI's Role in Future Product Delight "AI is a tool, and as every tool we're using, it can be used in a good way, or could be used in a bad way. And it is extremely possible to use AI in a very good way to make your product feel more human and more empathetic and more emotionally engaging." AI presents opportunities to enhance emotional connections through empathetic interactions and personalized experiences. Nesrine cites ChatGPT's conversational style—including apologies and collaborative language—as creating companionship feelings during work. The key lies in using AI to identify and honor emotional motivators rather than exploit them, focusing on making users feel supported and understood rather than manipulated or dependent. Developer Experience as Product Delight "If the user of your products are human beings... whether business consumer engineers, they deserve their emotions to be honored, so I usually don't distinguish between B2B or B2C... I say like B2H, which is business to human." Developer experience exemplifies product delight in B2B contexts. Companies like GitHub have created metrics specifically measuring developer delight, recognizing that technical users also have emotional needs. Tools like Jira, Miro, and GitHub succeed by making users feel more competent and productive. Nesrine advocates for "B2H" (business to human) thinking, emphasizing that any product used by humans should consider emotional impact alongside functional requirements. About Nesrine Changuel Nesrine is a product coach, trainer, and author with experience at Google, Spotify, and Microsoft. Holding a PhD from Bell Labs and UCLA, she blends research and practice to guide teams in building emotionally resonant products. Based in Paris, she teaches and speaks globally on human-centered design. You can connect with Nesrine Changuel on LinkedIn.

Terry Haayema: The Product Owner Who Made Retros Unsafe (And How We Fixed It) 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 biggest anti-pattern was that he made the retro unsafe... he would come to the retro and called people out for things that had not been done." The Bad Product Owner: The PO Who Made Retros Unsafe Terry describes a product owner who came from a management background focused on widgets and KPIs, completely unprepared for the collaborative nature of the product owner role. This person's biggest anti-pattern was making retrospectives unsafe by calling out individual team members for things not completed or not done to his satisfaction. When gentle coaching interventions failed, Terry took the dramatic step of excluding the PO from retrospectives entirely. Surprisingly, this shock treatment worked - when the PO asked why he wasn't invited, Terry used SBI feedback (Situation, Behavior, Impact) to help him understand how his actions were destroying team dynamics. The story has a positive ending, with the PO eventually understanding and changing his approach. In this segment, we refer to the Retrospective Prime Directive, and the SBI feedback framework. The Great Product Owner: The Customer Connector Terry's best product owner example saw their role not just as the voice of the customer, but as the connector between team and customers. Instead of relying solely on user stories and personas, this PO organized regular informal events where real customers and team members could meet, share pizza and beer, and have genuine conversations. These social connections led to deep customer understanding and resulted in their best feature ever - a simple addition that showed customers their last six orders for easy reordering. This feature increased both order frequency and size while dramatically improving the team's ability to empathize with their users. Self-reflection Question: How might you help your product owner move from being the voice of the customer to being the bridge that connects your team directly with real users? [The Scrum Master Toolbox Podcast Recommends]

Terry Haayema: Why "Working Myself Out of a Job" Is Wrong for Scrum Masters 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 for a Scrum Master is to do myself out of a job... which I don't buy into at all, because a team will always need a coach." Terry challenges the common belief that Scrum Masters succeed by working themselves out of a job, arguing instead that teams always need coaching as they continuously improve. He emphasizes the importance of separating his outcomes from the team's success to avoid becoming part of the system he's trying to help. For Terry, success is measured by the visible joy he can create in people - when leaders approach him with happiness, when team members are excited to see him, when absenteeism drops because people actually want to come to work. He shares a powerful story of how helping teams find joy not only improved their performance but reduced their stress-related sick days from the highest to the lowest in their division. Featured Retrospective Format for the Week: Drawing Retrospectives Terry loves retrospective formats that use drawings and visual metaphors, like Draw Your Feelings, or the Sailboat retrospective. He explains that when teams draw pictures instead of immediately processing thoughts through language, they generate much richer and deeper insights. The approach works by having people first draw their thoughts, then asking "What led you to draw that picture?" This method bypasses the analytical mind and taps into more intuitive understanding. For longer-term retrospectives, Terry recommends Open Space Technology, which allows groups to self-organize around the most important questions they need to answer. Self-reflection Question: How do you measure your own success as a Scrum Master, and does that measurement inspire you to do your best work? [The Scrum Master Toolbox Podcast Recommends]

Terry Haayema: When Consensus Becomes Paralysis—The Nemawashi Challenge For Agile Software Development 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 problem I'm facing is 'too much consensus'... we talk, bounce ideas, but we don't get going." Terry shares his current coaching challenge in a Japanese company where their cultural practice of Nemawashi (consensus building) has become a barrier to progress. While working across the entire organization, he's discovered that quality is suffering because teams aren't clear about desired outcomes before starting work. The excessive focus on building consensus means initiatives bounce between stakeholders without ever gaining momentum. Terry explains how he's experimenting with delaying detailed refinement to build shared understanding as teams progress, rather than trying to achieve perfect consensus upfront. He uses the metaphor of flying a plane - pilots don't stick rigidly to flight plans but constantly make small course corrections based on real-time feedback. Self-reflection Question: In your organization, what well-intentioned practices have become obstacles to the very outcomes they were designed to achieve? [The Scrum Master Toolbox Podcast Recommends]

Terry Haayema: The High Cost of Unsafe Agile Retrospectives 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. "She was kind of like the mum for the team... she was actually the glue that held the team together." Terry tells the story of a team that was functioning like a feature factory until a business analyst became their champion and "team mom." This BA supported everyone through agile transformation and helped build trust and healthy conflict. However, when she mentioned something in a retrospective that led to her being put on performance management and eventually leaving, the team rapidly self-destructed. They lost their sense of belonging and teamness, retreating back to working as independent professionals rather than collaborating. The story illustrates how leadership actions can instantly destroy weeks or months of trust-building work, and how critical psychological safety is for sustainable team performance. For more critical points on how to be a great leader, check this episode with Captain David Marquet, a thought leader in the leadership space who wrote Turn the Ship Around!  Featured Book of the Week: The Five Dysfunctions of a Team by Patrick Lencioni Terry credits The Five Dysfunctions of a Team by Patrick Lencioni as massively influential in his career, particularly praising how Lencioni demonstrates that without trust as a foundation, teams cannot achieve anything else. The book's framework shows how lack of trust prevents healthy conflict, which prevents commitment, which prevents accountability, which prevents results. Terry found the way Lencioni illustrates these dysfunctions and their cascading effects to be incredibly valuable for understanding team dynamics and what's needed to build high-performing teams. In this segment, we also refer to Agile Software Development with Scrum, by Schwaber and Beedle. Self-reflection Question: What would happen to your team's dynamics if your most supportive, trust-building team member suddenly left tomorrow? [The Scrum Master Toolbox Podcast Recommends]

Terry Haayema: When Scrum Practices Aren't Enough - Learning to Sense the System 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 didn't know how to 'sense' the system. I was focused on the scrum practices, I thought when practices were there all would be fine." Terry shares a powerful failure story from his second engagement as a Scrum Master, where he discovered that implementing Scrum practices isn't enough if you don't understand the underlying system driving team behaviors. He describes how individual KPIs were causing conflict between developers and testers - developers were measured on fewer defects while testers were measured on finding more defects. This systemic issue created dysfunction that no amount of daily standups or retrospectives could fix. Terry learned the hard lesson that Scrum Masters must be coaches for both the team and the organization, understanding how metrics and structures shape behavior before trying to implement agile practices. Self-reflection Question: What systemic forces in your organization might be working against the collaborative behaviors you're trying to foster in your teams? [The Scrum Master Toolbox Podcast Recommends]

BONUS: Jochen Issing on Building High-Performing Engineering Teams In this BONUS episode, we explore the fascinating journey of Jochen Issing, an engineering leader who brings unique insights from his background as a handball player and band member to building exceptional software development teams. From sports courts and music stages to engineering leadership, Jochen shares practical wisdom on psychological safety, team dynamics, and creating cultures where the best ideas win. From Sports and Music to Software Leadership "As soon as you complain about each other, you are starting to lose." Jochen's unconventional background as a handball player and band member has profoundly shaped his approach to engineering leadership. Drawing from team sports, he discovered that frustration leads to losing in both athletics and technology work. Great players in great teams optimize for the team's results, not individual glory. This translates directly to software development where great engineers slow down to make the team faster, recognizing that collective success trumps individual achievement. The lesson from the handball court is clear: when team members start blaming each other, they create a losing mindset that becomes self-fulfilling. Breaking the 10X Engineer Myth "It's not your success that makes our success, it's our success that makes your success." The mythology of the 10X engineer remains pervasive in software development, but Jochen challenges this with insights from team dynamics. The "hero culture" in companies often emerges when systems are already broken, requiring someone to step in and save the day. While we celebrate these heroes, we forget to ask the crucial question: how did we end up needing a hero in the first place? True high-performing teams don't require heroic individual efforts because they've built sustainable systems and shared knowledge. The goal isn't to eliminate talented individuals but to ensure that even the most skilled engineers can take time off without the organization grinding to a halt. Creating Psychological Safety Through Vulnerability "When psychological safety is missing, I try to ask ignorant questions - expose myself as being the least experienced person in the room." Building psychological safety requires intentional strategies that go beyond good intentions. Jochen employs a counterintuitive approach: when he senses team members hesitating to speak up, he deliberately asks "ignorant" questions to position himself as the least knowledgeable person in the room. This modeling behavior demonstrates that it's safe to admit uncertainty and ask questions. He also builds a culture of "challenging ourselves" by implementing ritualized dissent - assigning someone the specific job of finding flaws in proposed solutions. This prevents the dangerous harmony that can emerge when teams agree too quickly without proper scrutiny. The Power of the Expectation Sheet "I want people to share with me what might even drive them away from the company." Trust forms the foundation of effective team relationships, but building it requires explicit frameworks. Jochen uses an "expectation sheet" (See a prototype here Google Doc)- a document that formalizes mutual expectations between him and his team members. This tool establishes that he wants open, honest communication about everything, including situations that might drive someone to leave the company. The key principle is that he will never share confidential information or use personal disclosures against team members. This creates a relationship where he serves as both a representative of the company when necessary and a personal advocate for his team members when they need support navigating organizational challenges. Team-Centric Productivity and Collaboration "The team is the unit of productivity and delivery, not the individual." Effective engineering leadership requires balancing individual desires with team outcomes. Jochen emphasizes that while people naturally want to say "I did this," the focus must remain on team impact. This involves creating shared understanding of collective goals while still addressing individual needs and growth aspirations. Practical strategies include using on-call rotations to identify knowledge silos, implementing pair programming and mob programming to reinforce collaborative work patterns, and designing tasks that allow individuals to take ownership while remaining embedded in team efforts. The analogy to band dynamics is apt - when someone brings a song idea to the band, it evolves through collaboration into something different and usually better than the original vision. Building Sustainable High Performance "Great engineers slow down to make the team faster - which is how we get better teams." Sustainable high performance emerges when senior engineers invest in lifting the entire team rather than maximizing their individual output. This means senior staff level engineers focus less on their personal contributions and more on forming "tribes" across teams, coaching junior engineers, and building organizational capability. The measure of success shifts from individual heroics to collective achievement - if problems consistently require the same person to fix them, the team hasn't truly succeeded in building sustainable systems and shared knowledge. Recommended Resources for Further Reading Jochen recommends several foundational books for understanding team dynamics and engineering leadership. "The Culture Code" by Daniel Coyle explores the structure of high-performing teams and debunks myths about command-and-control leadership. "Product Development Flow" by Reinertsen provides the scientific foundation behind agile methodologies and explains what teams are really trying to solve. "The Culture Map" by Erin Meyer offers insights on working with diverse cultures and backgrounds to bring out the best in each team member. "Coaching Agile Teams" by Lyssa Adkins serves as a practical guide for developing coaching skills in technical environments. And our very own Scrum Master Toolbox podcast provides ongoing insights and real-world experiences from practitioners in the field. About Jochen Issing Jochen is an engineering leader who's all about building great teams and better developer experiences. From audio tech and cloud platforms to monorepos and feedback culture, he's done it all. A former bandmate and handball player, Jochen brings heart, trust, and collaboration into everything he builds with his teams. You can connect with Jochen Issing on LinkedIn and connect with Jochen Issing on Twitter.

Shawn Dsouza: Beyond Product Knowledge—The Hidden Skills Every Product Owner Needs 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. Shawn explores both ends of the Product Owner spectrum through real experiences. On one side, he addresses the "Forced" or "Accidental" Product Owner—a common but problematic pattern where organizations appoint someone based solely on product knowledge. He shares the story of a QA professional thrust into the PO role who knew the product inside out but lacked other essential PO skills, frustrating the team with inadequate responses. Through coaching questions inspired by "The Advice Trap," Shawn helped this reluctant PO reflect on responsibilities and develop confidence beyond technical knowledge. The Great Product Owner: The Story-Crafting Superstar Shawn celebrates a Product Owner who elevated user story writing to an art form—"the Picasso of writing user stories." This exceptional PO co-crafted clear, well-structured stories with the team and used AI to refine stories and acceptance criteria. Her meticulous preparation included intensive refinement sessions before vacations and expert story slicing techniques. By handling requirements clarity superbly, she freed the team to focus entirely on problem-solving rather than deciphering what needed to be built. The Bad Product Owner: The Forced/Accidental Product Owner Organizations frequently make the mistake of appointing the person with the highest product knowledge as Product Owner, assuming technical expertise translates to PO effectiveness. However, the Product Owner role requires diverse skills beyond product knowledge—stakeholder management, prioritization, communication, and strategic thinking. When a QA professional was thrust into this role, their deep product understanding couldn't compensate for underdeveloped PO competencies, leading to team frustration and project complications. In this segment, we refer to the Coach Your PO e-course published by your Scrum Master Toolbox Podcast! Self-reflection Question: What skills beyond domain expertise should you develop or look for when transitioning into or selecting someone for the Product Owner role? [The Scrum Master Toolbox Podcast Recommends]

Shawn Dsouza: The Marathon Mindset—Building Agile Teams That Last Beyond Sprint Deadlines 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. Shawn defines himself as a "people-first Scrum Master" who measures success not through metrics but through daily interactions and team growth. He contrasts two teams: one that hit deadlines but lacked collaboration (unsustainable success) versus another that struggled with deadlines but excelled in conversations and continuous improvement (sustainable growth). For Shawn, protecting deep work and fostering genuine team collaboration indicates true success. He emphasizes that product development is a marathon, not a sprint, and warns that lack of meaningful conversations will inevitably lead to team problems. In this segment, we refer to the book Clean Language by Sullivan and Rees.  Featured Retrospective Format for the Week: Sprint Awards Shawn champions the Sprint Awards retrospective format, moving beyond viewing retrospectives as just another Scrum event to recognizing them as critical team development opportunities. In this format, team members give awards to colleagues for various contributions during the sprint, with each award recipient explaining why they were chosen. Shawn prefers face-to-face, offline retrospectives and always starts with ice breakers to gauge how the team feels—whether they feel heard and connected. He believes in experimenting with different retrospective formats since no single approach works for every situation. Self-reflection Question: How do you balance achieving deliverable outcomes with building sustainable team relationships and collaboration patterns? [The Scrum Master Toolbox Podcast Recommends]

Shawn Dsouza: From AI Anxiety to AI Advantage: A Scrum Master's Experimental 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. Shawn faces the massive AI transformation currently reshaping the tech industry, acknowledging both its benefits and the fear it creates among professionals questioning their relevance. In his organization, he witnesses AI delivering wonders for some teams while others struggle and lose projects. Rather than viewing AI as an overwhelming wave, Shawn advocates for experimentation. He shares practical examples, like helping a Product Owner streamline story creation from Excel to JIRA using AI tools, and leveraging MIRO AI for team collaboration. His approach focuses on identifying friction points where AI experiments could add value while keeping conversations centered on possibilities rather than fears. Self-reflection Question: Instead of fearing technological changes like AI, how can you create small experiments to explore new possibilities and reduce friction in your current work processes? [The Scrum Master Toolbox Podcast Recommends]

Shawn Dsouza: The Database Migration Disaster— Why Software Development Teams Need Psychological Safety 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. Shawn worked with a skilled team migrating a database from local to cloud-based systems, supported by a strong Product Owner. Despite surface-level success in ceremonies, he noticed the team avoided discussing difficult topics. After three months of seemingly smooth progress, they delivered to pre-production only to discover 140 critical issues. The root cause? Unspoken disagreements and tensions that festered beneath polite ceremony facades. The situation deteriorated to the point where a senior engineer quit, teaching Shawn that pausing to address underlying issues doesn't cost time—it builds sustainability. In this segment, we refer to the episodes with Mahesh Jade, a previous guest on the Scrum Master Toolbox podcast. Featured Book of the Week: The Advice Trap by Michael Bungay Stanier Shawn discovered this transformative book when he realized he was talking too much in team meetings despite wanting to add value. The Advice Trap revealed how his instinct to give advice, though well-intentioned, was actually self-defeating. The book taught him to stay curious longer and ask better questions rather than rushing to provide solutions. As Shawn puts it, "The minute you think you have the answer you stop listening"—a lesson that fundamentally changed his coaching approach and helped him become more effective with his teams. Self-reflection Question: When working with teams, do you find yourself jumping to advice-giving mode, or do you stay curious long enough to truly understand the underlying challenges? [The Scrum Master Toolbox Podcast Recommends]

Shawn Dsouza: When Scrum Masters Forget to Listen - A Team Trust Crisis in Agile Implementation 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. Shawn shares a powerful lesson about the importance of listening before implementing. Working with a young, talented team drowning in firefighting, he rolled out Scrum in "full" without taking time to understand the team's context. Going through the motions of Scrum ceremonies without genuine team ownership led to dropping energy levels and lost trust. The turning point came when Shawn realized the team had lost faith in his approach, prompting him to rebuild the process collaboratively with team ownership at its core. This story highlights how good intentions can backfire when we prioritize frameworks over people. Self-reflection Question: Before implementing any new process or framework, how do you ensure you truly understand your team's current challenges and context rather than jumping straight to solutions? [The Scrum Master Toolbox Podcast Recommends]

Bernie Maloney: Problems vs. Solutions: The Great Product Owner Distinction 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: The Strategic Problem Solver Bernie describes an exemplary Product Owner from a stealth program sponsored by a CTO, where the company needed to create new intellectual property. This Great Product Owner understood that Agile operates in three dimensions: most organizations only focus on outputs and delivery (first dimension), some reach outcomes (second dimension), but the truly great ones operate in the third dimension of strategic or business agility - defining problems worth solving. This Product Owner knew that high-performing teams need to understand what problem is worth solving rather than just receiving solutions to build. They embraced the Mobius loop approach, focusing on discovering the right problems rather than jumping straight to solutions. In this segment, we refer to the Mobius Loop, and to Steve Blank's work on the job of a startup.  We also refer to the episode with Elliott Parker on the critical importance of the “startup mindset” to foster innovation in larger organizations.  The Bad Product Owner: The Backlog Jockey with Authority Issues Bernie identifies the anti-pattern of Product Owners being treated as mere "backlog jockeys" by their organizations, which forces them into solution-building mode rather than problem-solving mode. These Product Owners don't understand the importance of saying "no" and lack clarity about intent and goals. The worst case Bernie encountered was a team manager who also served as Product Owner, wielding positional authority that shut down team communication. This person would interrupt daily scrums, causing teams to revert to waiting for direction rather than self-organizing. The combination of unclear intent and positional authority creates a toxic environment that destroys team autonomy and psychological safety. Self-reflection Question: Is your Product Owner focused on defining problems worth solving, or are they primarily managing a backlog of predetermined solutions? [The Scrum Master Toolbox Podcast Recommends]

Bernie Maloney: From Permission-Seeking to Forgiveness-Begging—Agile Team Evolution in Self-Management 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. Bernie defines success for Scrum Masters as creating teams that can thrive and do their best work independently. His ultimate goal is to make himself unnecessary - developing self-directing teams that step out of waiting for direction and instead seek permission or even beg forgiveness when needed. Using the "Circles and Soup" framework, Bernie helps teams stretch their circles of influence and control. He recognizes that every manager wants teams to succeed but may lack the necessary tools, making it crucial for Scrum Masters to coach managers as well. Bernie recommends building a backlog of organizational impediments and focusing on the top priority that will move the ball forward most effectively. Featured Retrospective Format for the Week: Sailboat Bernie champions the Sailboat retrospective format for its simplicity and adaptability. While the basic format is straightforward, he appreciates that you can add layers of complexity as needed. Bernie tends to keep retrospectives simple and also mentions the "What the Duck?" technique as another valuable retrospective tool. He suggests incorporating creative elements like having people build LEGO representations of what they're discussing, which helps teams visualize and engage with concepts more effectively. To know more about LEGO Serious Play, check out the Serious Play book.  In this segment, we also refer to Dissociation in Psychology, which helps with "third position" coaching/thinking, and Bernie's video on creative retrospective formats.  Self-reflection Question: How are you measuring whether your teams are becoming more self-directing, and what specific behaviors indicate they're ready to operate with less guidance? [The Scrum Master Toolbox Podcast Recommends]

Bernie Maloney: Mastering Complexity Through Systems Thinking and NLP Coaching 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. Bernie addresses the constant challenge of mid-sprint changes by asking the crucial question: "what do you want to trade in for that new request?" His approach centers on recognizing that everyone is trying to do their best with what they have, using techniques from NLP and the three coaching positions to help people see the whole system. Bernie emphasizes rapport building as a key skill for Scrum Masters and warns against the anti-pattern of becoming judgmental when challenges arise. He advocates for moving from a plan-and-predict mentality to sense-and-respond thinking, highlighting the importance of conducting retrospectives once challenges are solved. Bernie's coaching philosophy revolves around helping people step into the "third position" - a dissociated perspective that enables better problem-solving and systems thinking. In this episode, we refer to Neuro-linguistic Programming (NLP), and to Instant Rapport by Michael Brooks, a primer on NLP. We also refer to the plan-and-predict vs sense-and-respond mentality. Self-reflection Question: How effectively are you helping your teams and stakeholders see the whole system when challenges arise, rather than just focusing on individual pain points? [The Scrum Master Toolbox Podcast Recommends]

Bernie Maloney: The Triangulation Technique—Coaching Agile Teams Through Challenges 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. Bernie identifies critical patterns that cause teams to self-destruct, with lack of clarity about intention being the most common culprit. When teams are treated as mere "task workers" without clear vision, strategy, or goals, they become depressed and directionless. Some teams seek forgiveness after failed experiments, while others get stuck seeking permission without taking enough self-leadership. Bernie emphasizes that waiting for direction is fundamentally self-destructive behavior, and Scrum Masters must create safety for teams to reach high performance. He introduces the coaching technique of triangulation, where problems become a third point that coach and coachee examine together, side by side, rather than facing each other in opposition. In this segment, we talk about “What the Duck”, a Lego Serious Play workshop. Featured Book of the Week: Start with Why by Simon Sinek Bernie champions "Start with Why" by Simon Sinek as essential reading for Scrum Masters working to transform team culture. He explains that compelling stories are how leaders truly influence others, following the sequence of Attention-Emotion-Reason. This book helps Scrum Masters understand that their job fundamentally involves changing culture, and leaders must demonstrate the change they want to see. Bernie connects this to the broader leadership challenge of developing coaching and mentoring skills within organizational structures. During this segment, we also refer to the following books:  Drive, By Dan Pink Change the Culture, Change the Game, by Connors et al. The Secret Language of Leadership, by Denning Too Many Bosses, Too Few Leaders, by Peshawaria The Geek Way, by McAfee Right Kind of Wrong, by Edmondson   Self-reflection Question: What patterns of self-destructive behavior might your teams be exhibiting, and how could you help them move from seeking permission to taking ownership? [The Scrum Master Toolbox Podcast Recommends]

Bernie Maloney: The Power of Psychological Safety in Agile Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Bernie shares a powerful story about learning what psychological safety truly means through both success and failure. Working in a high-pressure division with tight timelines and margins, Bernie discovered the transformative power of the mantra "always make a new mistake." When he made a significant error and was met with understanding rather than punishment, he experienced firsthand how psychological safety enables teams to thrive.  Later, facing a different challenge where mistrust existed between management and teams, Bernie had to navigate the delicate balance of maintaining psychological safety while addressing management's desire for transparency. His solution was innovative: conduct retrospectives with the team first, then invite managers in at the end with anonymized contributions. Bernie's approach of framing changes as experiments helped people embrace newness, knowing it would be time-bound and reversible. In this episode we refer to Neuro-linguistic Programming (NLP).  Self-reflection Question: How might your current approach to mistakes and experimentation be either fostering or undermining psychological safety within your team? [The Scrum Master Toolbox Podcast Recommends]

CTO Series: Toni Sallanmaa on Scaling Engineering Teams and Aligning Tech with Business Goals In this BONUS episode, we explore the journey of scaling technology teams and maintaining alignment between engineering and business objectives with Toni Sallanmaa, CTO at Funidata. Toni shares invaluable insights from leading the development of Sisu, a cutting-edge student information system serving over 100,000 Finnish university users, and discusses practical strategies for growing engineering organizations while preserving company culture. The Genesis of Leadership in Technology "I understood what I was really responsible for. I'm interested in the business we are running—the business adds meaning to the work." Toni's approach to technology leadership was fundamentally shaped by a pivotal moment early in his career when he first gained influence over system development and technology choices. After working with large-scale systems for 20 years, this moment of responsibility revelation transformed his perspective from purely technical to business-focused. He emphasizes that infinite curiosity drives success in tech businesses, and understanding the business context gives meaningful purpose to technical work. Bridging the Gap Between Tech and Product "Don't separate Tech from Product. We established a common language between product and technology people." One of Toni's most significant insights centers on eliminating the traditional divide between technology and product teams. As Funidata grew from a small startup to a 70-person organization, the challenges of maintaining alignment became apparent. Their solution involved several key practices: Teaching developers the language of the product domain  Banning confusing technical terms that create communication barriers Workshopping product language to ensure clarity Keeping entity names deliberately vague until true understanding emerges This approach draws heavily from Domain Driven Design principles, creating a unified vocabulary that enables seamless collaboration. Collaborative Planning and Transparency "We use transparency as a collaboration technique. Every team sees what's being proposed as a goal for the next quarter." Funidata implements a unique "marketplace of goals" approach during their quarterly big room planning sessions. Rather than using scaled agile frameworks, they focus on transparency and collaborative goal-setting. Teams present their high-level quarterly plans to each other, creating visibility across the organization. Product owners are embedded within teams, keeping communication distances short and ensuring alignment between technical execution and business objectives. Future-Forward Roadmapping "We talk about the higher level ideas regularly, but let them bubble up from the community. We hold internal hackathons." Toni's approach to roadmapping balances strategic vision with grassroots innovation. They maintain an internal technology roadmap that addresses emerging trends like AI, while allowing ideas to organically emerge from the engineering community. Internal hackathons serve as catalysts for innovation, providing structured opportunities for teams to explore new technologies and approaches that might inform future roadmap decisions. Scaling Challenges and Cultural Preservation "The biggest challenge is not technology, it was the rapid scaling of technology teams. When you scale up, keep the culture in mind." The most significant challenge Toni faced wasn't technical but organizational—rapidly scaling teams while preserving company culture. Growing from 10 to 50 people required evolving processes, from establishing internal forums for architectural discussions to implementing continuous integration flows. The key was identifying pain points proactively and maintaining open discussions with team members throughout the scaling process. Strengthening company culture became essential to successful growth. AI's Impact on Software Development "Productivity is on the rise. We see opportunities like generating test data, but we have strict requirements for cybersecurity, which puts pressure on code quality." Toni views AI's impact on software development with cautious optimism. While productivity gains are evident, particularly in areas like test data generation, the stringent cybersecurity requirements in their domain mean that AI hasn't yet significantly improved code quality where it matters most. The technology shows promise, but implementation must be carefully considered within the context of security and quality requirements. Measuring Engineering Success "We use DORA and SPACE framework. We measure how much of our work is KTLO (Keep The Lights On) and how much is elective development." Funidata employs both DORA and SPACE frameworks to measure engineering organization success. From SPACE, they particularly focus on measuring software team wellbeing, while also tracking the balance between "Keep The Lights On" (KTLO) work and elective development. Using JIRA connected to a data warehouse, they mine extensive data that serves both leadership decision-making and team improvement efforts, ensuring metrics benefit everyone in the organization. Influential Leadership Resources "The organizational books have been more influential to me than purely technical ones." Toni emphasizes that organizational leadership books have shaped his CTO approach more than technical resources. Two key influences stand out: "Team Topologies" for understanding how to structure and scale engineering teams effectively, and "Radical Candor" for building authentic, productive relationships within the organization. You can find a BONUS episode on Team Topologies with the authors Matthew Skeltton and Manuel Pais. About Toni Sallanmaa Toni leads technology and engineering at Funidata, developing Sisu—a cutting-edge student information system serving over 100,000 Finnish university users. Passionate about agile methodologies, system architecture, and software engineering, Toni specializes in technology management, software lifecycle, OOP, and relational databases to deliver innovative, scalable solutions in higher education tech. You can connect with Toni Sallanmaa on LinkedIn.

Mariano Gontchar: The Micromanagement Trap—When PO's Good Intentions Harm Agile Team Performance 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: The Visionary Leader During an agile transformation project modernizing a build system with multiple stakeholders, Mariano worked with an exceptional Product Owner who demonstrated the power of clear vision and well-defined roadmaps. This visionary Product Owner successfully navigated complex stakeholder relationships by maintaining focus on the product vision while providing clear direction through structured roadmap planning, enabling the team to deliver meaningful results in a challenging environment. The Bad Product Owner: The Task-Manager Micromanager Mariano encountered a well-intentioned Product Owner who fell into the task-manager anti-pattern, becoming overly detail-oriented and controlling. This Product Owner provided extremely detailed story descriptions and even specified who should do what tasks instead of explaining why work was needed. This approach turned the team into mere task-handlers with no space to contribute their expertise, ultimately reducing both engagement and effectiveness despite the Product Owner's good intentions. Self-reflection Question: Are you empowering your team to contribute their expertise, or are you inadvertently turning them into task-handlers through over-specification? [The Scrum Master Toolbox Podcast Recommends]

Mariano Gontchar: Fear-Free Teams—Creating Psychological Safety for High Performance 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. Mariano's definition of Scrum Master success has evolved dramatically from his early days of focusing on "deliver on time and budget" to a more sophisticated understanding centered on team independence and psychological safety. Today, he measures success by whether teams can self-manage, communicate effectively with stakeholders, and operate without fear of criticism. This shift represents a fundamental change from output-focused metrics to outcome-focused team health indicators that create sustainable high performance. Self-reflection Question: How has your definition of success evolved in your current role, and what would change if you focused on team independence rather than traditional delivery metrics? Featured Retrospective Format for the Week: Frustration-Based Retrospective Mariano's retrospective approach focuses on asking team members about their biggest frustrations from the last sprint. This format helps team members realize their frustrations aren't unique and creates psychological safety for sharing challenges. The key is always asking the team to propose solutions themselves rather than imposing fixes, making retrospectives about genuine continuous improvement rather than just complaining sessions. [The Scrum Master Toolbox Podcast Recommends]

Mariano Gontchar: From Evangelist to Facilitator—How To Lead A Successful Company Merger 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. During a complex merger between two telecom companies, Mariano faced the challenge of uniting team members with different cultures, practices, and tools. His initial approach of selling Agile theory instead of focusing on benefits failed because he forgot about the "why" of change. The breakthrough came when he shifted from being an Agile evangelist to becoming a facilitator who listened to managers' real challenges. By connecting people and letting the team present their own solutions to leadership, Mariano successfully created unity between the formerly divided groups. Self-reflection Question: Are you trying to sell your methodology or solve real problems, and what would happen if you focused on understanding challenges before proposing solutions? [The Scrum Master Toolbox Podcast Recommends]

Mariano Gontchar: Breaking Down The Clan Mentality In Agile Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Mariano encountered a competent team that was sabotaging itself through internal divisions and lack of trust. The team had formed clans that didn't trust each other, creating blind spots even during retrospectives. Rather than simply telling the team what was wrong, Mariano created an anonymous fear-based retrospective that revealed the root cause: a Product Owner who behaved like a boss and evaluated team members, creating a culture of fear. His approach demonstrates the power of empowering teams to discover and solve their own problems rather than imposing solutions from above. Self-reflection Question: What fears might be hiding beneath the surface of your team's dynamics, and how could you create a safe space for them to emerge? Featured Book of the Week: Turn the Ship Around! by David Marquet Mariano recommends "Turn the Ship Around!" by David Marquet (we have an episode with David Marquet talking about this book, check it here). Mariano highlights the fascinating story and introduction to the leader-leader model, which differs significantly from the traditional leader-follower approach. This book resonates with Mariano's journey from directive leadership to facilitative leadership, showing how empowering others rather than commanding them creates more effective and engaged teams. [The Scrum Master Toolbox Podcast Recommends]

Mariano Gontchar: From Boss to Facilitator—The Critical Role of Empathy in Scrum Mastery 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. Mariano shares his transformation from viewing himself as a boss in his project manager role to embracing the facilitator mindset essential for Scrum Masters. His journey reveals a crucial insight: you cannot implement Scrum with a "big bang" approach.  Instead, success comes through empathy and understanding your team's needs. Mariano emphasizes that working with Agile requires constant practice and learning, but the key lesson that changed everything for him was learning to empathize with his team members rather than directing them from above. Self-reflection Question: How might your current leadership style be limiting your team's potential, and what would change if you shifted from directing to facilitating? [The Scrum Master Toolbox Podcast Recommends]

BONUS: Agile Tour Vienna 2025—Building Community-Driven Agile Excellence In this BONUS episode, we explore the upcoming Agile Tour Vienna 2025 (get your ticket now!) with three passionate organizers who are bringing together the Austrian agile community for a day of learning, networking, and innovation. Join us as we dive into what makes this community-driven event special, the challenges facing today's agile practitioners, and why local connections matter more than ever in our evolving professional landscape. The Heart of Community-Driven Events "For me, it's really about creating an event from the community for the community. So at the Agile Tour Vienna we really pay a lot of attention that the contributions are made by community members." - Sabina Lammert The foundation of Agile Tour Vienna lies in its commitment to authentic community engagement. Unlike corporate-led conferences focused on sales and marketing, this event prioritizes genuine knowledge sharing and peer-to-peer learning. The organizers emphasize creating space for meaningful conversations, where participants don't just consume content but actively contribute to discussions and support one another with real-world challenges. This approach fosters an intimate atmosphere where attendees leave with valuable professional connections and practical insights they can immediately apply. Balancing Local Expertise with Global Perspectives "This local aspect is very important, but then it needs to be enhanced by bringing in ideas from people from the outside world." - Robert Ruzitschka Agile Tour Vienna strikes a unique balance between showcasing local Austrian talent and bringing in internationally renowned speakers. The event features a carefully curated mix of practical experiences from Vienna-based practitioners working directly with teams and companies, combined with keynotes from global thought leaders. This blend creates opportunities for attendees to understand both the local context of agile implementation and broader industry trends, making the learning experience both immediately relevant and strategically valuable. A Thoughtfully Designed Experience "We make sure we have a good diversity within the speakers. We also take care that we have a good mix, because for me, agile started with the engineering practices." - Richard Brenner The 2025 program demonstrates attention to creating a comprehensive learning experience. The organizers ensure language accessibility by maintaining at least one English track throughout the day while also offering German sessions. The content spans from technical engineering practices to team coaching and business strategy, reflecting agile's evolution across organizational levels. The event takes place in a stunning castle location (Auersperg Palace) that enhances the intimate, family-like atmosphere the organizers work hard to cultivate. World-Class Content in an Intimate Setting "Agile Tour Vienna is never aiming to go big, but to stay small and familiar. By the end of the day, you know new people." - Sabina Lammert This year's highlights include keynotes from Dave Farley on engineering excellence and Mirella Muse on product operations, plus an innovative Comic Agile storytelling workshop. The organizers deliberately limit attendance to maintain the conference's intimate character, ensuring meaningful networking opportunities rather than overwhelming crowds. Additional touches like a professional barista bar and ample space for informal conversations between sessions create an environment where genuine professional relationships can develop. From Concept-Based to Context-Based Agility "The biggest challenge is that we go from concept-based agility to context-based agility. Companies realize the world is complex. There is no one framework to rule them all." - Richard Brenner The agile community faces a significant evolution as the methodology matures from underground movement to established practice. Organizations are moving away from rigid framework implementations toward contextual problem-solving approaches. This shift requires practitioners to focus on solving real business issues rather than introducing agile for its own sake. The challenge lies in maintaining agile's core values while adapting to diverse organizational contexts and avoiding the trap of seeking simple solutions for complex problems. Maintaining Values-Based Working "It's not about winning over something. It's about using common sense, getting into interaction and trying to find sometimes complex solutions for complex problems." - Sabina Lammert Rather than declaring agile "dead," the community must refocus on value-based working and continuous adaptation. The real challenge involves empowering people to constantly reevaluate situations and embrace the reality that today's solutions may not work in three weeks or three years. This requires normalizing the inspect-and-adapt mindset as standard practice rather than exception, moving beyond method-focused thinking toward principle-driven decision making. Sustaining Community Spirit Through Challenging Times "In times of crisis, people tend to fall back to old patterns of behavior. We need to keep the ideas that made us work in a specific way alive." - Robert Ruzitschka Economic and political uncertainties create pressure to abandon agile practices in favor of traditional command-and-control approaches. Community events like Agile Tour Vienna play a crucial role in maintaining momentum for collaborative, adaptive working methods. The discipline required for agile practices - continuous integration, experimental approaches, market-driven feedback collection - represents a more sophisticated and ultimately more sustainable way of working than traditional project management approaches. The Discipline of Adaptability The discussion revealed an important distinction about discipline in agile environments. Agile teams demonstrate remarkable discipline through practices like continuous integration, experimental product development, and systematic feedback collection. This represents a more humane form of discipline that acknowledges complexity and enables adaptation, contrasting sharply with the rigid discipline of following predetermined plans regardless of changing circumstances. About Robert Ruzitschka, Sabina Lammert, and Richard Brenner Robert Ruzitschka is a Senior Principal Engineer at Raiffeisen Bank International and leads a team of Engineering Coaches. You can connect with Robert Ruzitschka on LinkedIn. Sabina Lammert is Founder and Agile Coach of Leadventure and supports Teams and organizations to improve their way of collaboration. You can connect with Sabina Lammert on LinkedIn. Richard Brenner is a previous guest, he started as Software Engineer and is now working as Agile Coach helping clients to adopt agile ways of working. You can connect with Richard Brenner on LinkedIn.

Salum Abdul-Rahman: Learning to Communicate Value in Public and Non-Profit Sectors' Product Development 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: The Systematic Value Communicator Salum describes working with a Product Owner who had a PhD in data science on a public sector visualization project. This exceptional PO was extremely systematic in working with stakeholders and possessed a unique ability to bridge abstract concepts with concrete implementations. In the public sector, where monetary feedback is absent, this PO excelled at thinking about value achievement and communicating it effectively to the team. They had the magical capability to involve stakeholders while demystifying complex requirements, helping the team understand not just engagement metrics but how their work would change society and the world. The Bad Product Owner: The Absentee Specialist The most common anti-pattern Salum encounters is the absentee Product Owner - typically a specialist assigned to the PO role while maintaining their full-time job as a domain expert. With only 10-20% time allocation, these POs lack the capacity to fulfill their responsibilities effectively. They often don't have the time or knowledge to develop essential PO skills, requiring extensive hand-holding to understand even basic concepts like user stories. Salum's approach involves booking time directly in their calendar for backlog refinement sessions and providing comprehensive guidance to help them understand the role, though this intensive support is necessary due to their limited availability for skill development. In this segment, we refer to the concept of ‘enshitification' by Cory Doctorow, and refer to Tom Gilb's bonus episode on the Scrum Master Toolbox Podcast.  Self-reflection Question: How do you ensure your Product Owner has both the time allocation and skill development needed to truly serve the team and stakeholders effectively? [The Scrum Master Toolbox Podcast Recommends]

Salum Abdul-Rahman: The SECI Model of Knowledge Management Applied to Team Retrospectives 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. Salum explains how the key role for Scrum Masters is to help teams develop themselves to the point where they can learn and grow without constant guidance. Success means building team resilience and operational capability while knowing when to step back. He emphasizes the importance of recalibration workshops to maintain shared understanding and the balance between supporting teams and challenging them to become self-sufficient. When teams reach this level of maturity, Scrum Masters can focus their efforts elsewhere, knowing the team has developed the capability to continue evolving independently. Featured Retrospective Format for the Week: The 5-Stage Retro Format From the book "Agile Retrospectives," this format captures the complete learning process and aligns beautifully with knowledge management principles. Salum connects the three central phases of this format to the SECI model of knowledge management, particularly referencing Nonaka and Takeuchi's work in "The Knowledge Creating Company." This retrospective structure helps teams create new knowledge and behavioral change by following a systematic approach that transforms individual insights into collective team learning and action. In this segment, we also refer to the seminal article by Takeuchi and Nonaka: “The New New Product Development Game”, which originated the work on Scrum as a framework.  Self-reflection Question: How do you recognize when your team has developed enough self-sufficiency that your role as facilitator can evolve or step back? [The Scrum Master Toolbox Podcast Recommends]

Salum Abdul-Rahman: From Lunch Conversations to Company-Wide Change—The Power of Creating Communities of Practice Within Organizations 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. Salum shares how he organically built an Agile community within his company by recognizing a shared need for discussion and learning. Starting as a software developer who took on Scrum Master tasks, he felt isolated in his Agile journey. Rather than waiting for formal training or external events, he sent out a simple invite on the company Slack for a lunch discussion during a work day. People showed up, and what began as informal conversations about different approaches to Scrum and Kanban evolved into monthly gatherings. Over time, this grassroots community grew to organize company-wide events and even found new leadership when Salum moved on, demonstrating the power of identifying shared needs and taking initiative to address them. Self-reflection Question: What shared learning needs exist in your organization that you could address by simply reaching out and organizing informal discussions? [The Scrum Master Toolbox Podcast Recommends]

Salum Abdul-Rahman: From Isolation to Integration—Rebuilding Agile Team Connection For Remote 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. Salum describes working with a grocery ecommerce team during COVID that fell into the trap of prioritizing individual convenience over team collaboration. Remote work led team members to design their work around personal preferences, with the lead developer becoming increasingly isolated and unresponsive to team communication. This anti-pattern of "what works for me" over "what works for the whole team" created significant dysfunction. Despite management intervention, the situation required creative solutions like organizing face-to-face sessions and shared working sessions with digital whiteboards to rebuild team cohesion. Featured Book of the Week: Agile Retrospectives One of the most important roles of Scrum Masters is to help teams develop themselves. Salum emphasizes that you can't tell the team what to do - you have to help them discover it themselves. "Agile Retrospectives" provides the foundation for running meaningful retrospectives that become the key tool for team self-development. The book's emphasis on variation and building retrospectives to match your team's needs and maturity level makes it essential for empowering teams to grow and evolve continuously. Self-reflection Question: How might your team's current work arrangements prioritize individual convenience over collective effectiveness, and what steps could you take to shift this balance? [The Scrum Master Toolbox Podcast Recommends]

Salum Abdul-Rahman: The Expert Who Couldn't Connect: An Agile Team Integration Challenge 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. Salum shares a challenging situation where a software architect with deep expertise struggled to integrate with the team. Despite the architect's technical knowledge, his expert-based communication style and inability to justify reasoning created friction with other developers. The conflict escalated when the architect disengaged from teamwork and ultimately left the company. This experience highlights the importance of understanding organizational dynamics in large corporations and recognizing when separation might be the best solution for everyone involved. In this episode, we refer to Nonviolent Communication, a topic we've discussed often here on the podcast.  Self-reflection Question: How do you balance respecting expertise while ensuring all team members communicate in ways that foster collaboration rather than create hierarchies? [The Scrum Master Toolbox Podcast Recommends]

BONUS: Captain David Marquet's Guide to Becoming Your Own Best Coach In this BONUS episode, we dive deep into Captain David Marquet's latest book "Distancing: How Great Leaders Reframe to Make Better Decisions." Captain Marquet, renowned for transforming the USS Santa Fe from the worst-performing submarine to the best in the fleet, shares powerful insights on psychological distancing and how stepping outside ourselves can dramatically improve our decision-making abilities. Make sure you also check the previous episode with Captain Marquet, where we discuss the key lessons from his book: Turn The Ship Around! A very often referred book on the Scrum Master Toolbox Podcast.  The Genesis of Distancing "What I really needed was people to think, not just comply, not just do what they were told." Captain Marquet traces the origins of his distancing concept back to his submarine experience. After realizing that giving orders gave people "a pass on thinking," he developed a system where crew members would say "I intend to..." instead of waiting for commands. However, he noticed that officers would sometimes make decisions that were good for their department but not optimal for the submarine as a whole. This led him to ask different questions - like having the engineer sit in the captain's chair and think from that perspective. The breakthrough came when he started asking himself, "What would my six-month-from-now self want me to do today?" The Three B's of Better Decision Making "The problem with your decision making isn't gathering more market data. The problem is your internal, your egoic biases that just come from the fact that you view the decision from inside your own head." Marquet introduces the "3 B's of better decision making": Be someone else, be somewhere else, be sometime else. These psychological distancing techniques help overcome the limitations of our "immersed self" - the version of us trapped in immediate pressures, deadlines, and ego-driven concerns. When we distance ourselves temporally (thinking as our future self), socially (thinking as someone else), or spatially (imagining being somewhere else), we access what psychologists call our "distanced self," which aligns more closely with our ideal self and core values. The Jeff Bezos Example "When I'm 80, when am I going to regret more? Am I going to regret trying this idea and failing or not trying the idea?" Marquet shares how Jeff Bezos used temporal distancing when deciding whether to leave his Wall Street job to start Amazon. By imagining himself at 80 looking back, Bezos was able to see past immediate concerns like his upcoming bonus and rent payments to focus on what would truly matter in the long term. This shift in perspective transforms how our brain processes decisions - from viewing them as "scary change" to considering them through the lens of potential regret. Practical Applications for Teams "I want you to imagine that a team in Singapore is going to work on the same kind of project next month. What would we want them to know?" The distancing technique has powerful applications for team retrospectives and decision-making. Instead of asking "What could we have done better?" (which triggers defensiveness), Marquet suggests reframing as helping a future team in another location. This approach employs all three B's simultaneously:  Be someone else: Helping another team rather than critiquing yourself  Be sometime else: Focusing on future improvement rather than past mistakes Be somewhere else: Imagining the team in a different location removes personal attachment Becoming Your Own Coach "You become your own friend, you become your own coach." Marquet emphasizes that leaders cannot effectively coach others until they learn to coach themselves. He challenges leaders who want their teams to change by asking, "What have you changed recently?" The coach perspective provides the elevated view needed to see the whole field rather than being immersed in the immediate action. Like a sports coach who doesn't feel the hits but sees the strategy, our "coach self" can provide objective guidance to our "player self." The Language of Leadership "The people who said 'you can do it' exerted more energy and felt better than the people who said 'I can do it.'" Building on his previous work in "Leadership is Language," Marquet demonstrates how changing from first-person to second or third-person language creates psychological distance. Studies show that athletes performing endurance tests while saying "you can do it" outperformed those saying "I can do it." This simple language shift helps separate us from the immersed self and provides a slight but meaningful perspective advantage. The Intel Transformation Story "What if we got fired? And the board brought in new people to run the company. What would the new people do?" Marquet shares the pivotal moment when Intel founders Gordon Moore and Andy Grove used distancing to make the crucial decision to abandon memory chips for microprocessors. For a year, they couldn't make this decision because their identity was tied to being "memory chip makers." Only when Grove asked Moore to imagine what new leadership would do were they able to immediately see the obvious answer: focus on microprocessors. This decision saved Intel and created the company we know today. Stopping Time: Planning the Pause "The best thing is you have to plan the pauses. The best case is when you plan the pause ahead of time." Marquet explains that once we're in our reactive, immersed state, it's nearly impossible to climb out without System 2 override. The solution is to schedule pauses proactively. When teams know there will be scheduled reflection points, they're more willing to commit to execution while also noting areas for improvement. This is why agile methodologies are so effective - they build in regular pause points for reflection and course correction. Overcoming Defensive Reactions "Your brain will curate the input - it will always choose to pay attention to things that prove you're right and ignore things that prove you wrong." The immersed self creates defensive reactions during evaluations, retrospectives, or any situation involving performance assessment. Our brains naturally filter information to support our existing self-image, remembering successes while forgetting failures. Distancing techniques help bypass these defensive mechanisms by removing the ego from the equation, allowing for more objective analysis and better decision-making. Acting Your Way to New Thinking "We act our way to new thinking. You want to do different things. We act your way to a new mindset. You don't mindset your way to new actions." Marquet concludes with a crucial insight about change: behavior change leads to mindset change, not the other way around. Rather than trying to convince people to think differently, leaders should focus on creating small, actionable changes that gradually shift thinking patterns. His "Leadership Nudges" concept embodies this approach, offering brief, practical tools that teams can implement immediately. About Captain David Marquet Captain David Marquet, a former U.S. Navy submarine commander, revolutionized leadership by empowering his crew to become leaders themselves. Through his Intent-Based Leadership® model, he transformed the USS Santa Fe from the worst-performing submarine to the best in the fleet. Today, he inspires organizations worldwide to cultivate leaders at every level. You can connect with Captain David Marquet on LinkedIn and follow him on his website at davidmarquet.com. You can also explore his YouTube channel "Leadership Nudges" for a library of over 500 short leadership videos.

BONUS: The Platform-as-Product Revolution: How to Turn Your Biggest Cost Center Into Your Secret Weapon With Alvaro Lorente In this BONUS episode we explore a topic that's creating a lot of discussion—and sometimes confusion—in the software community: Platform Teams vs DevOps. In this conversation, we dive into Alvaro Lorente's journey from delivery teams to platform leadership, exploring how to treat platforms as products, avoid common pitfalls, and build bridges between engineering and product leadership. The Evolution from DevOps Role to Platform Team "DevOps is a culture, not a role." Alvaro's journey into platform work began when he joined a company where the infrastructure team was left behind and struggling with traditional DevOps approaches. Initially, they had a single DevOps person who became a bottleneck rather than an enabler. This experience highlighted a fundamental misunderstanding that many organizations face—treating DevOps as a job title rather than a cultural shift toward collaboration and shared responsibility. The team experimented with a "DevOps buddy" approach, placing experienced individuals within each delivery team, before eventually consolidating into a dedicated platform team with the clear intention of treating it as a product-focused unit. Platform as a Product: A Scaling Strategy "Platform as a product is a scaling strategy. Look for common problems that you can then solve once, and serve many." The concept of treating platforms as products emerged from recognizing that feature delivery teams have continuity and ongoing needs that a platform team should serve. Rather than solving their own problems first, successful platform teams focus on making other teams' work easier and more comfortable while managing costs effectively. This approach requires identifying common problems across multiple teams and creating solutions that can be implemented once but serve many. The key insight is that platform teams exist to facilitate the delivery of value in a scalable way for other teams, not to pursue their own technical interests. Understanding Your Customer and Validating Value "I want to see platform team members talking to their customers. Understand their pains, and what they struggle with." Effective platform teams operate like any other product team by actively listening to their customer-teams rather than pushing ideas onto them. This means platform team members should regularly engage with their internal customers to understand pain points and struggles. Success requires defining clear KPIs for the platform and focusing on the quality of deliverables including release notes, demos, bug fixing processes, and feature prioritization. The validation comes from observing whether teams willingly adopt platform features rather than being mandated to use them. Building Bridges with Product Leadership "Focus on the key impact and value that the platform team can bring to the company." Making the case for investing product talent in platform teams requires demonstrating concrete business value. This includes quantifying how many incidents are being resolved faster or prevented entirely, and highlighting the money saved through internal platform development versus external solutions. Platform work offers excellent growth opportunities for Product Owners, serving as a training ground for product thinking and stakeholder management. The focus should always be on measurable impact rather than technical complexity. Avoiding Common Platform Team Traps "Don't just start working on what you think is important! Start with the Product process, listen to the client-teams, and help them directly." When standing up a platform team, several critical mistakes can derail success. The most important trap to avoid is immediately diving into what the platform team thinks is important without first understanding customer needs. Platform teams should resist delivery pressure that might compromise quality and never mandate adoption of their features—teams should want to use what the platform provides. Treating the platform as a genuine product with quality standards is essential, and leaders should view the creation of a platform team as the beginning of a change management process rather than just a technical reorganization. Resources and Continuous Learning "One size does NOT fit all!" For teams looking to improve their platform work, Alvaro recommends Camille Fournier's work on platform teams and resources focused on "The value of product thinking in platform teams." The key is to get experiments running within your team and recognize that there's no universal solution—each organization must find its own path based on its unique context and needs. About Alvaro Lorente Currently Director of Engineering at Voxel (an Amadeus company), Alvaro is a software engineer who has grown in the people leadership path, experimenting with everything from product development to startups and open source projects. He embraces the idea of being a jack of all trades, helping wherever needed to drive value and impact. You can connect with Alvaro Lorente on LinkedIn and follow his insights through his Substack newsletter titled Leads Horizons.

Irene Castagnotto: Building Bridges—How Great Product Owners Create Team Alignment 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: Building Trust Through Transparency and Purpose Irene emphasizes that exceptional Product Owners excel at building trust with their teams by consistently sharing the "why" behind decisions and features. They trust their teams completely and ensure that team members understand the purpose and reasoning behind every request. This transparency creates a foundation of mutual trust where teams feel confident in the Product Owner's direction. Great Product Owners use moments when features don't work as expected as opportunities to explore and reinforce the underlying purpose, turning potential setbacks into learning experiences that strengthen team understanding and alignment. The Bad Product Owner: When Stories Replace Truth Irene witnessed a Product Owner who, when facing difficult client conversations without positive information to share, chose to "make up stories" rather than being transparent about challenges. This lack of honesty led to delivering something the client couldn't accept, resulting in an angry client during the demo. This anti-pattern of using "good words" instead of honest communication ultimately damages client relationships and team credibility. The lesson learned: Product Owners must be transparent with clients about what is and isn't possible, even when the news is difficult to deliver. Self-reflection Question: How do you balance protecting your team from client frustration while maintaining the transparency necessary for successful product development? [The Scrum Master Toolbox Podcast Recommends]

Irene Castagnotto: The Risk-Aware Scrum Master: Preventing Problems Before They Happen 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. Irene defines success for Scrum Masters as helping teams anticipate and manage risks before they become unexpected problems. She focuses on ensuring teams don't face surprise risks during sprints and don't start work with missing requirements. Her approach includes using user story mapping with Product Owners to visualize potential risks and maintaining team happiness as a key success indicator. For Irene, creating a positive team environment is a crucial deliverable that Scrum Masters must actively work on. She emphasizes the importance of listening to team feedback and regularly assessing whether the team feels supported and engaged. In this segment, we refer to W. Edwards Deming, and his famous quote “a bad system will beat a good person, every time!” Featured Retrospective Format for the Week: The Good/Bad/Risk Retrospective This retrospective format works particularly well with younger teams and uses humor to help teams discuss emotionally challenging topics. The format focuses on three key areas: what went well (Good), what didn't work (Bad), and what potential risks the team sees ahead (Risk). Irene recommends this approach because it helps teams surface risks that aren't visible to anyone else, creating opportunities to address potential problems proactively. By incorporating the language of risk into everyday conversations, teams become more aware of potential challenges and can plan accordingly. The humor element helps reduce the emotional intensity that often accompanies difficult discussions about team performance and challenges. In this segment, we refer to the book “How to Make Good Things Happen: Know Your Brain, Enhance Your Life” by Marian Rojas Estape. Self-reflection Question: How comfortable is your team with discussing risks openly, and what techniques could you use to make these conversations more approachable? [The Scrum Master Toolbox Podcast Recommends]

Irene Castagnotto: Timing Is Everything - Learning When Agile Teams Are Ready for 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. Irene shares a powerful story about discovering team dependencies and proposing solutions that management initially rejected. When her team identified that Epics weren't organized to avoid dependencies between teams, they proposed using a single unified backlog to manage these challenges. Despite the logical solution, management wasn't ready to accept it. A month later, the same management team returned with the identical proposal. This experience taught Irene that timing is crucial in change management—you don't decide when the right time is; the people involved determine their own readiness. She emphasizes the importance of socializing changes early and often, collecting feedback before proposing major transformations, especially when those changes affect management structures. Self-reflection Question: How do you balance persistence with patience when you know a change is needed but the organization isn't ready to embrace it? [The Scrum Master Toolbox Podcast Recommends]

Irene Castagnotto: Three Toxic Conditions That Destroy Agile Team Effectiveness 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. Irene encountered a team where everything appeared perfect on the surface, but underneath lay a complete lack of transparency. The team displayed negativity while their manager prevented them from taking responsibility, asking them to complete tasks without explaining the reasoning. These three toxic conditions—negativity, lack of transparency, and micromanagement—combined to destroy the team's effectiveness. Initially hesitant to speak up, Irene ultimately chose to leave. Reflecting on this experience, she emphasizes the importance of addressing problems directly with leadership rather than simply escaping the situation. In this segment, we refer to the 5 monkeys experiment, as comment on conditioning that happens in groups. Featured Book of the Week: Switch by the Heath Brothers Switch: How to Change Things When Change Is Hard by the Heath Brothers focuses on understanding change and why it's challenging for people. According to Irene, change isn't difficult because people resist it, but because it creates internal conflict within us. The Heath Brothers explain the three essential elements needed for successful change: the rational rider (logical thinking), the emotional elephant (feelings and motivation), and the path (the environment and systems). The book provides practical guidance on how to facilitate change and help people navigate transitions effectively, emphasizing the importance of celebrating achievements throughout the change process. Self-reflection Question: What internal conflicts might be preventing positive changes in your team, and how can you address both the rational and emotional aspects of resistance? [The Scrum Master Toolbox Podcast Recommends]

Irene Castagnotto: When Proactive Help Backfires - A Gen Z Scrum Master's Learning Journey 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. Irene shares a valuable lesson about the pitfalls of being overly proactive without proper communication. As a new Scrum Master, she observed Product Owners struggling with role changes and took initiative to help them understand and implement changes. However, she discovered that her well-intentioned proposals weren't aligned with what the POs actually wanted. The key insight: when people don't speak up during your proposals, it often means they're not on board but are avoiding conflict. Irene learned that asking questions and letting others express what changes they're ready for is far more effective than assuming what help is needed. Self-reflection Question: How can you better gauge whether your team is genuinely on board with your suggestions, especially when they remain silent during discussions? [The Scrum Master Toolbox Podcast Recommends]

BONUS: Rob Gallaher Reveals The Management Revolution Transforming Company Culture and Employee Engagement In this BONUS episode, we dive deep into the transformative power of profit sharing with Rob Gallaher, CEO of Gallaher Co. Rob shares his journey from an overworked entrepreneur sacrificing family time to building a thriving business model that aligns employee success with company growth. Through practical insights and hard-learned lessons, we explore how monthly profit sharing can revolutionize workplace dynamics and create genuine shared success. The Genesis of a Profit Sharing Revolution "I was an entrepreneur, working long hours and sacrificing family time. I realized my situation in life was not so good anymore, and even my health was suffering." Rob Gallaher's journey to profit sharing began with a personal crisis. As a successful entrepreneur, he found himself trapped in the classic founder's dilemma - working endless hours while his health and family relationships suffered. This realization prompted him to seek alternative business models from other successful owners. His discovery of profit sharing wasn't immediate magic, but rather a methodical approach to solving the fundamental disconnect between business success and employee engagement. Since implementing it in 2015, Rob has refined his approach through real-world application, leading him to document his learnings in his book after others began noticing the remarkable success of his companies. Defining True Profit Sharing "Take the company's financial success and share it with individuals that make it happen. The main thing: it must be monthly." Rob's definition of profit sharing goes beyond traditional annual bonuses or stock options. His approach centers on taking actual company profits and distributing them to the people who directly contribute to generating those profits. The cornerstone of his system is monthly distribution, recognizing that people manage their personal finances on a monthly basis, not quarterly or annually. This frequency ensures that profit sharing becomes integrated into employees' monthly budgets and thinking patterns, creating immediate behavioral impact rather than distant, abstract benefits. The Power of Immediate Impact "No one manages quarterly their personal life. The profit sharing needs to adapt to that monthly reality. If we don't affect people's monthly budget we don't affect how they think." The monthly frequency of Rob's profit sharing system creates tangible, immediate impact on employees' financial lives. Unlike equity or long-term bonuses that feel distant and uncertain, monthly profit sharing becomes part of employees' regular financial planning. This immediacy changes how people approach their work, leading them to ask "what can I do to get it" and investing more personally in company success. Rob emphasizes making the amounts substantial - recommending four-digit numbers that genuinely affect people's monthly reality rather than token gestures that get lost in regular paychecks. Rethinking Performance Management "I don't like the word 'review'. I prefer the word 'reflection', we do it every 6 months. I wanted to change the tone and what was happening in those meetings." Traditional performance reviews create antagonistic dynamics where employees feel anxious and stressed, often leading to negotiations that feel like battles. Rob has completely reimagined this process by separating profit sharing from performance evaluations and changing the language from "reviews" to "reflections." This shift eliminates the transactional nature of traditional reviews where employees feel they must fight for raises and promotions. Instead, profit sharing operates independently of individual performance metrics, creating a more collaborative and less stressful environment for genuine performance discussions. Strategic Implementation Framework "You need a business that makes a profit, you need to have accurate accounting, and you need to be a leader - you need to have the respect and trust of your leadership." Rob outlines three fundamental prerequisites for successful profit sharing implementation. First, the business must be genuinely profitable - you cannot share what doesn't exist. Second, accurate accounting systems are essential to track and calculate profits transparently. Third, leadership credibility is crucial because profit sharing requires employees to trust that leaders will follow through on commitments. Rob recommends starting with a flat rate and minimum amount, such as $1,000, and focusing on decision-makers who directly affect company profitability rather than attempting to include every employee from the start. Targeting Decision Makers "Who are the people who make decisions that affect the profit of your business? Share the profit with the decision makers that affect profit." Rather than implementing company-wide profit sharing immediately, Rob advocates for a targeted approach focusing on employees who make decisions directly impacting profitability. This strategic selection ensures that profit sharing reaches the people whose daily choices most influence company success. By identifying and rewarding these key decision-makers first, companies can create a focused impact that generates measurable results before expanding the program to additional team members. Getting Started: First Steps for Implementation "Figure out your average profit." For companies interested in profit sharing but unsure where to begin, Rob recommends starting with fundamental financial analysis. Understanding average monthly profits provides the baseline for determining sustainable sharing amounts. This analysis helps leaders set realistic expectations and design a program that won't compromise business stability while still providing meaningful benefits to employees. The key is ensuring that profit sharing enhances rather than threatens the company's financial foundation. About Rob Gallaher Rob Gallaher, CEO of Gallaher Co., leads five companies across industries. Since founding his construction firm in 2010, he's championed profit sharing as a catalyst for growth. His book, Profit Sharing: The Power of Shared Success, and upcoming course reflect his passion for aligning employee and company success. You can also learn more about Rob's Profit Sharing strategy with his online course at Profitx.co. You can link with Rob Gallaher on LinkedIn, and connect with Rob Gallaher on facebook.

Somya Mehra: When Technical Expertise Becomes Product Owner Micro-Management 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: The Clear Communicator and Dependency Master Somya worked with an exceptional Product Owner on a project with multiple team dependencies. This PO excelled at clear, direct communication with both stakeholders and the team. They were proactive in stakeholder communication and maintained strong focus on what was needed and why. Their backlog management was exemplary, creating proper epics with comprehensive information including dependencies, enabling the team to easily know who to contact. This approach led to a much more motivated team. The Bad Product Owner: The Technical Micro-Manager Somya encountered a technically strong Product Owner whose knowledge became a liability. While technical strength can be beneficial, this PO used their expertise to control the team, telling developers exactly what solutions to implement. Initially, developers accepted this direction, but it escalated to every feature and task. The developers became uncomfortable voicing their perspectives, creating an unhealthy dynamic where the PO's technical knowledge stifled team autonomy and creativity. Self-reflection Question: How do you help Product Owners leverage their technical knowledge without falling into micro-management patterns? [The Scrum Master Toolbox Podcast Recommends]

Somya Mehra: Why Collaboration Should Be Your Team's Primary Goal 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. Unlike technical roles where success is tangible, Scrum Master success can be harder to measure, especially for those transitioning from tech roles. Somya defines successful Scrum Master performance through team behaviors: when teams trust and respect each other, and when collaboration becomes their goal. She emphasizes the importance of observing behaviors and discussing them with team members early enough to foster the right behaviors within the team. Featured Retrospective Format for the Week: The 2 Pillars Retrospective Somya recommends the 2 Pillars retrospective format, which she intentionally varies to keep teams engaged and curious. Her core structure focuses on two essential questions: "What went well?" and "How can we improve?" She notices that using the same retrospective format repeatedly leads to team boredom, so she adds variety while maintaining these fundamental pillars. In specific cases, she includes a gratitude section to ensure team members feel appreciated. Self-reflection Question: How do you measure your success as a Scrum Master when the results aren't as tangible as in technical roles? [The Scrum Master Toolbox Podcast Recommends]

Somya Mehra: From Top-Down to Collaborative—Reimagining Organizational Restructuring 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. During a business unit split and reorganization focused on creating smaller teams, Somya and her fellow Scrum Masters were invited to create the new structure process. After hearing feedback that teams felt excluded from previous changes, they decided to include teams in the reorganization process to give them a sense of control. They started by asking top management for constraints, then applied them to see what was possible. They facilitated workshops with Product Owners to divide the product portfolio and determine team assignments, ensuring people felt involved in the change process. Self-reflection Question: When leading organizational change, how do you balance the need for structure with giving teams meaningful input into decisions that affect them? [The Scrum Master Toolbox Podcast Recommends]

Somya Mehra: How Upper Management Can Destroy a High-Performing Team in Minutes 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. While working as a business analyst at a startup building an exam evaluation product for universities, Somya witnessed a well-functioning team with good collaboration and timely delivery. However, upper management began challenging the team lead and Scrum Master, accusing the team of padding story points. When leadership confronted the team, the tech lead threw the entire team under the bus, breaking all trust. The CEO's declaration that he could detect padding in estimates shattered the relationship between developers and leadership, leading team members to want to leave. Featured Book of the Week: Agile Retrospectives by Larsen and Derby Somya recommends "Agile Retrospectives" by Larsen and Derby because doing Scrum right means doing retrospectives right. As someone who wanted to excel as a retro facilitator, she found this book invaluable due to its excellent reviews and practical examples. The book provides several examples of how to facilitate retrospectives effectively, making it her go-to recommendation for Scrum Masters wanting to improve their retrospective facilitation skills. Self-reflection Question: How do you maintain trust between your team and leadership when management questions the team's estimates or performance? [The Scrum Master Toolbox Podcast Recommends]