Scrum Master Toolbox Podcast: Agile storytelling from the trenches

Viktor Glinka: Why Context Is King for Scrum Master Success — Building Capabilities That Drive Business Goals
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.
 
"Product management skills are crucial for Scrum Masters. Once you understand how retention impacts your return on investment, you will be able to coach your product owner." - Viktor Glinka
 
Viktor offers a nuanced perspective on Scrum Master success by distinguishing between short-term and long-term success. On the long-term side, he argues that the purpose of a Scrum Master extends beyond working with teams — it's about helping improve the system as a whole. To do that, you need to connect your contribution to the product's success by helping build specific capabilities. Viktor grounds this in practical terms: start by asking what the business goal of your company is, and check whether people around you actually know it. Never assume everyone does. That simple act of curiosity gives you the information you need to figure out how to contribute. In his experience, the key capability his teams needed to develop was multi-learning — the ability to work across components — and that directly served the business goal. Viktor makes a strong case that Scrum Masters need product management skills. Understanding how metrics like retention impact long-term success allows you to coach product owners and analyze product dynamics. His practical advice: if you're not experienced in this, go shadow your product owner, spend time with the sales department, and look through customer support tickets. You'll understand far more about the system than staying at the development organization level.
 
Self-reflection Question: Can you clearly explain how your work as a Scrum Master contributes to your product's success? What specific capability are you helping the system build right now?
Featured Retrospective Format for the Week: Data-Driven Discussions with Actionable Outcomes
Viktor's approach to retrospectives is refreshingly pragmatic: it depends on the team. For teams not yet used to actionable improvements, he starts simple — review previous retro decisions, ensure new concrete ones are created, and bring data as food for thought. He particularly likes using the cumulative flow diagram and time distribution histogram to help teams reflect on consistency in delivery. One team he worked with adopted this as a natural habit over time. For mature teams, format matters less — one team ran a simple "good, bad, to improve" retro in 30 minutes on their own, without a Scrum Master, and it was one of the most engaged and effective retrospectives Viktor had ever seen. He also values the free-talk format when first meeting a new team, coming in with genuine curiosity and no biases. And when something clearly went wrong — an incident, a failure — Viktor drops whatever format he had prepared. "In those moments, it's important to trust your instinct, read the room, sense the tension, and step into the danger directly."
 
[The Scrum Master Toolbox Podcast Recommends]
🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥
Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.
 
🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.
 
Buy Now on Amazon
 
[The Scrum Master Toolbox Podcast Recommends]
 
About Viktor Glinka
 
Viktor is an organisational consultant and Professional Scrum Master who helps teams and leaders find simpler ways to deliver value while keeping the human side of work at the center. He's practical, curious, and focused on real outcomes rather than buzzwords. His true passion is adaptability - both in business and in personal life.
 
You can link with Viktor Glinka on LinkedIn.

Viktor Glinka: From Component Teams to Cross-Functional Teams — How to Navigate the Hardest Agile Transformation
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.
 
"Our customers do not buy our components. They use the product as a whole. And when it comes to integration, the real problem pops up." - Viktor Glinka
 
Viktor brings a challenge many Scrum Masters face: transitioning from component teams to cross-component, cross-functional teams in a large-scale Scrum setup. Picture 8 to 10 teams, each owning their own part of the system, never touching anything else — and the company stuck in delivery for months. The premise behind component teams sounds logical: specialization leads to speed. But as Viktor explains, that speed is local — optimized for the component, not the product. When integration time arrives, responsibility gaps appear, rework multiplies, and teams start identifying with their components rather than the product. "We're the billing team — we don't deal with anything else." When they reorganized into cross-functional teams, the complaints were immediate: "I was really productive before, and now I can't finish anything." Viktor and his fellow Scrum Masters took a two-pronged approach. First, they secured time credit from leadership — a couple of months where learning was prioritized over deadlines. They ran mob programming sessions, coached teams, and removed impediments. Second, they shifted focus from outputs to outcomes, organizing customer interviews that helped developers understand what users actually needed. The development director reinforced this by joining refinement sessions, telling teams: "You might not develop anything if it still satisfies the customer need." The result was a shift from transactional stakeholder relationships to genuine cooperation, and teams that began to see beyond their component boundaries.
 
Self-reflection Question: If your teams are organized around components, what would it take to run one experiment — just one sprint — where a team picks up work outside their usual component? What would you need to make that safe?
 
[The Scrum Master Toolbox Podcast Recommends]
🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥
Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.
 
🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.
 
Buy Now on Amazon
 
[The Scrum Master Toolbox Podcast Recommends]
 
About Viktor Glinka
 
Viktor is an organisational consultant and Professional Scrum Master who helps teams and leaders find simpler ways to deliver value while keeping the human side of work at the center. He's practical, curious, and focused on real outcomes rather than buzzwords. His true passion is adaptability - both in business and in personal life.
 
You can link with Viktor Glinka on LinkedIn.

Viktor Glinka: When Internal and External Team Members Have Divergent Goals — The Silent Killer of 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.
 
"The root causes for destructive team patterns often lie outside the team itself." - Viktor Glinka
 
Viktor shares a story from a manufacturing organization where one team stood out — and not in a good way. The team was composed of both internal and external members, and what no one saw coming was that their implicit goals were fundamentally divergent: the external members were focused on maximizing revenue for their own company, while the internal members cared deeply about product quality. The signs were visible to anyone who approached them — they barely talked to each other and preferred to work individually. When Viktor tried to raise the topic of cooperation and trust, he was met with awkward silence. One team member finally told him: "I don't want the team to blow up. In my previous experience, I raised this topic and that was the end of the team." Fear kept the truth underground. Viktor brought his observations to the manager, who acknowledged the lack of a shared goal as the root cause — but couldn't fix it because he wasn't authorized to manage the external people. The takeaway was clear: three key success factors for any team are the right team composition with people who want to work together, a shared goal that unites diverse perspectives, and clear expectations set by their manager.
 
In this segment, we talk about LeSS self-designing team workshops and the importance of team composition in scaled setups.
 
Self-reflection Question: Does your team have a shared goal that everyone — including external members and contractors — genuinely understands and cares about? When was the last time you checked?
Featured Book of the Week: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland
Viktor recommends The Art of Doing Twice the Work in Half the Time by Jeff Sutherland as the book that sparked his passion for Scrum. As he puts it: "I know the title is very controversial and often criticized, but I could deeply relate to the stories inside the book. They sparked a passion that is still with me." Viktor also recommends a bonus book: Reinventing Organizations by Frederic Laloux, which showed him the real power of self-organization and validated what he had already started experimenting with in his project management career. It pushed him to explore holacracy, sociocracy, intent-based leadership, and coaching.
 
[The Scrum Master Toolbox Podcast Recommends]
🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥
Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.
 
🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.
 
Buy Now on Amazon
 
[The Scrum Master Toolbox Podcast Recommends]
 
About Viktor Glinka
 
Viktor is an organisational consultant and Professional Scrum Master who helps teams and leaders find simpler ways to deliver value while keeping the human side of work at the center. He's practical, curious, and focused on real outcomes rather than buzzwords. His true passion is adaptability - both in business and in personal life.
 
You can link with Viktor Glinka on LinkedIn.

Viktor Glinka: When Passion Becomes the Problem — How Pushing for Agile Change Too Fast Creates Resistance
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 wanted to change the organization overnight with my eagerness and passion. Instead of helping the system to evolve, I created resistance. I became the problem myself." - Viktor Glinka
 
Viktor shares one of the most honest failure stories we've heard on the show. Early in his Scrum Master career, he joined a finance organization as a Scrum Master for a newly created department — his first experience in a scaled setup. Each team owned a particular part of the user journey, organized around components. After getting exposed to Large-Scale Scrum (LeSS) through a colleague, Viktor became overexcited. He started pushing for structural changes daily, telling the head of department that the current team composition was wrong and they needed cross-functional feature teams. But he was disconnected from reality. For this particular organization, even having partially cross-functional teams was already a big stretch. Worse, the head of department wasn't even authorized to make the changes Viktor was pushing for. Instead of helping the system evolve, he created resistance. What proved his approach wrong? That same department later received a European Award for being the best mortgage department. It took Viktor a few more years and similar cases to fully absorb the lesson: read the room, develop sensitivity to the system's pace, and stimulate reflection in decision makers rather than pushing your own agenda.
 
In this episode, we refer to organizational development, LeSS (Large-Scale Scrum), and systems analysis. Viktor also mentions the interview with Bas Vodde on the Scrum Master Toolbox Podcast.
 
Self-reflection Question: When was the last time you pushed for a change because you believed it was right, without checking whether the system was ready for it? What would happen if you started by asking decision makers what they think would be a good next step?
 
[The Scrum Master Toolbox Podcast Recommends]
🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥
Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.
 
🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.
 
Buy Now on Amazon
 
[The Scrum Master Toolbox Podcast Recommends]
 
About Viktor Glinka
 
Viktor is an organisational consultant and Professional Scrum Master who helps teams and leaders find simpler ways to deliver value while keeping the human side of work at the center. He's practical, curious, and focused on real outcomes rather than buzzwords. His true passion is adaptability - both in business and in personal life.
 
You can link with Viktor Glinka on LinkedIn.

BONUS: From 3,000 Scripts to 3 Tools - Building AI-Last Software With Conversational AI Pioneer Peter Swimm
In this special BONUS episode, Peter Swimm—conversational AI veteran, creator of BotKit (the open-source chatbot framework that powered Slack and Teams bots), and former Principal Product Manager at Microsoft Copilot Studio—shares what 25+ years in tech taught him about working with AI. From his brutal experiment of running an entire business on voice-based AI for a week, to why he treats AI more like R2-D2 than C-3PO, Peter offers a grounded, practical perspective on where AI fits in software development teams.
From BotKit to Copilot Studio: A Front-Row Seat to the AI Evolution
"We had the number one bot in the Slack app store, because there were only 8 bots, and ours used regex. To show you how far we've come."
 
Peter's journey into conversational AI started with a newspaper ad and a creative writing background. When Slack launched its API, Peter and BotKit co-creator Ben Brown immediately saw that building bots wasn't just a technical challenge—it was a social and creative one, like writing scripts for plays that interface with people in their daily lives. That insight powered BotKit into becoming the backbone of Slack and Teams bots, and eventually led to Microsoft acquiring the company. Peter spent years inside Microsoft shaping Copilot Studio, working on connectors that bridge the gap between APIs and real-world work. But the experience also gave him a healthy dose of perspective: he can show you slide decks from 2016 that promise the same things today's AI pitches promise, always saying "within 5 years." That pattern recognition shapes his practical, no-hype approach.
The 3,000 Scripts Experiment: Why AI-Last Beats AI-First
"At the end of the day, if I've been prompting all day, I should have a computer program that works offline, that works without a subscription. Otherwise, I didn't really make anything."
 
Peter ran a week-long experiment trying to run his entire business using only voice-based conversational AI. The result: 3,000 generated scripts. After static code analysis, he discovered it was really only 5 programs made thousands of times—and those 5 programs were really just 2 or 3 core abilities. He deleted 36 gigabytes of generated code and kept 50 megabytes of what actually worked. This brutal compression led him to an "AI-last" philosophy: build reliable runtime software that works confidently in one click, then use AI only for exploration, connection-making, and creative riffing. The payoff is striking—within 3 weeks of a given application, his team sees a 90% reduction in AI usage in the first week, dropping to 0% within 13 days, because once a computer program does everything you need, you don't need AI anymore.
R2-D2, Not C-3PO: How to Think About AI on Your Team
"I think of our AI use more like R2-D2 than C-3PO. R2-D2 doesn't talk—bonus points. He doesn't interject his fear. He saves your butt. He's silent until you need him, and visible when you need him."
 
Peter's Star Wars analogy captures his team's philosophy on AI integration. AI should be like a smarter linter—a quiet, capable tool that handles the boring, repetitive tasks so humans can focus on creativity and shipping. His team treats AI as a "super junior" with infinite time: set it up as if it invented Python, have it write buy-the-book code with unit tests, and then a human reviews and accepts (or rejects) the output. The tooling isn't consistent enough to ship autonomously or commit directly into the codebase—even frontier providers don't fully understand what their models do. The practical benefit is enormous for setup and configuration: what used to be a painful, arcane process of tracking down dozens of AWS or Azure docs becomes a 20-minute "hello world" that's actually a working proof of concept. Your job isn't to become an expert at cloud services—it's to ship product.
The Biggest Mistake: Automating Broken Processes at AI Speed
"All it does is automate all the mistakes you made, all the way, at AI speed."
 
When asked about the most common mistake organizations make with AI, Peter is blunt: they port their existing infrastructure into AI-governed systems instead of rebuilding from the ground up. Companies with a self-inflated opinion of their processes think AI is just a million-person force multiplier—so they'll ship faster. But if your process was broken before AI, you'll just generate broken output at unprecedented scale. That 3,000-script experiment proved this firsthand. Peter's recommendation: rebuild from the bolts up. Start with AI-last architecture where reliable, offline-capable software handles the core, and AI is reserved for the edges—filling gaps, translating between systems, and making connections that don't exist yet.
SaaS Is Bloated: The Case for AI Transformation Layers
"The one thing AI is good at is transforming between boundaries."
 
Peter's team has been divesting from SaaS providers, replacing the patchwork of middleware subscription plans that forced everyone to copy and paste between CMS, Excel, meeting notes, and email. His approach: product people use Notion, developers use GitHub, and the two cross-sync without needing Jira as an arbitration layer. Everyone tracks work in the tool they already live in. AI's real superpower here is translation—between APIs, between languages, between formats. Peter sees a future where small translation layers between CRUD operations replace the bloated, one-size-fits-all SaaS tools that are "built for 99% of users with generalized features nobody uses." His team also freed themselves from tools like Figma: the designer works in their preferred graphics program, the developer in their preferred IDE, and AI arbitrates the differences.
Teams, Velocity, and Reinvesting the AI Dividend
"5 to 7 people is still good, because you need a diverse set of people who are intensely focused on certain areas. But they should be allotted that savings in time to ship all the things that get cut."
 
Peter pushes back on the idea that AI changes the ideal team size. The 5-to-7 person team still works—what should change is what those people do with the time they save. Instead of loading teams onto more projects or increasing portfolio velocity, reinvest the AI productivity dividend into quality: ship with unit tests from day one, ship WCAG-compliant from day one, and stop cutting features to hit deadlines. Version 1.0 should no longer need an immediate 1.1 follow-up. Peter also challenges the notion that AI eliminates the need for experienced practitioners—velocity metrics become meaningless when a 6-week coding plan finishes in 25 minutes. What matters is using the saved time to make software genuinely better.
The Future: Demo-First Development and Solid Releases
"I can show you a working demo of the thing at the first meeting, and you can pay for it. And then we can make it better than your dreams."
 
Peter sees AI transforming the consulting and product development lifecycle from "launch, listen, and learn" to "listen, iterate, and launch." As a consultant, he now brings working demos to first meetings instead of $20,000 six-week proposals. Clients see the product in motion and immediately identify improvements—before money changes hands. This shifts the power dynamic: products iterate toward quality before launch, not after. Peter envisions a future where we ship solid releases that iterate in quality, with interfaces that show users only what's relevant to them instead of "90,000 buttons that don't apply to me."
 
About Peter Swimm
 
Peter Swimm is a conversational AI veteran with 25+ years in tech — from managing data centers to building Botkit (the open-source chatbot framework that powered Slack and Teams bots), to serving as Principal Product Manager at Microsoft Copilot Studio. He's the founder of Toilville, a consultancy helping businesses build conversational AI solutions.
 
You can link with Peter Swimm on LinkedIn and visit his website at peterswimm.com.