Scrum Master Toolbox Podcast: Agile storytelling from the trenches

Kaloyan Chalakov: Coaching Organizations to Challenge the Beliefs Behind Agile Pressure 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. "What's happening with the team is just the symptom of what's happening with the whole system." - Kaloyan Chalakov Kaloyan brings a common Scrum Master challenge: a team under pressure from a Product Owner who starts acting more like a project manager. Planning turns into a list of tasks, Daily Scrum becomes a status report, and pressure flows from customers and market competition, through management, to the Product Owner, and finally to the team. In the conversation, Vasco and Kaloyan map the system and notice something deeper than pressure: the belief that a competitor's release will directly damage the company unless the team moves faster. That belief becomes the real intervention point. Kaloyan reflects that Scrum Masters can challenge assumptions, turn beliefs into testable hypotheses, and introduce alternative beliefs that reduce pressure instead of passing it down. The practical insight is powerful: do not fight pressure by adding more pressure. Look for the source, test the assumptions behind it, and design small conversations that change the system around the team. In this episode, we refer to systems thinking and limiting beliefs. Self-reflection Question: What belief is creating pressure in your organization, and how could you test it with one small conversation this week? [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 Kaloyan Chalakov Kaloyan Chalakov spent years making high-stakes decisions at sea before moving into Agile and organisational change, bringing lessons from safety-critical systems into how modern teams work. You can link with Kaloyan Chalakov on LinkedIn.

Kaloyan Chalakov: The Agile Team That Built Great Architecture But Forgot the Customer 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. "You don't have to build it only because we can. We need to lead to a purpose." - Kaloyan Chalakov Kaloyan worked with a technically strong team that could build impressive architecture, pipelines, and infrastructure fast. Sprint after sprint, they showed the quality of the technical system they were creating. But the hard question stayed unanswered: what customer problem were they solving? The wake-up moment came in a sprint review, when a client finally joined and told the team that the network and architecture were nice, but they did not solve the actual problem. The customer needed one small piece of functionality, and the team could not point to it. The room went silent. The Product Owner felt exposed, the team felt embarrassed, and Kaloyan saw the moment as painful but necessary. Because the mistake happened early, it became a learning opportunity instead of a product disaster. The team learned to connect technical excellence to product value, and to ask sooner whether their work solved the customer's real need. In this segment, we talk about customer feedback and Sprint Review. Self-reflection Question: What are you building because it is technically interesting, and how will you test whether it solves a real customer problem? Featured Book of the Week: Start With Why by Simon Sinek Kaloyan recommends Start With Why by Simon Sinek because it changed how he thinks before acting. The book pushed him to pause before solving a problem and ask what the real purpose is. He started applying that question in workshops, team conversations, and product discussions. When a team member asked why a leadership workshop included a specific activity, Kaloyan realized his explanation had not landed. Instead of pushing forward, he stopped, reset, and rebuilt the workshop around a clearer purpose. For Kaloyan, the "why" is not a one-time statement. It is a question to ask at every step, because people do better work when they understand how their part connects to the bigger goal. [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 Kaloyan Chalakov Kaloyan Chalakov spent years making high-stakes decisions at sea before moving into Agile and organisational change, bringing lessons from safety-critical systems into how modern teams work. You can link with Kaloyan Chalakov on LinkedIn.

Kaloyan Chalakov: When Textbook Scrum Hurt the Team, Learning to Adapt as a Scrum Master Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "It doesn't matter if it works for you. The most important thing is that it doesn't work for me." - Kaloyan Chalakov Kaloyan Chalakov came into Agile after years in safety-critical environments, where control and preparation mattered. That background helped him, but it also created his first big Scrum Master trap: trying to be the "perfect" Scrum Master from the books. He pushed two-week sprints, events, and practices because that was how Scrum was supposed to work. Then one team member pulled him aside and told him the truth: the process did not work for him. Kaloyan's first reaction was defensive, because his pride was hurt. But that feedback became a signal. He started using that team member as a barometer for whether the change was actually helping. The lesson was simple and hard: one approach does not fit every team. Real Scrum Mastery starts when we treat resistance as information, take smaller steps, and adapt the system to the people doing the work. In this episode, we refer to Agile adaptation and Scrum Master role. Self-reflection Question: Where are you defending a process because it is "right," instead of listening to the team signals that show whether it is useful? [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 Kaloyan Chalakov Kaloyan Chalakov spent years making high-stakes decisions at sea before moving into Agile and organisational change, bringing lessons from safety-critical systems into how modern teams work. You can link with Kaloyan Chalakov on LinkedIn.

BONUS: The Chip Race Behind AI With Rakesh Kumar AI feels like a software revolution, but Rakesh Kumar argues that the next limits may come from chips, energy, and the physical systems underneath our code. In this BONUS episode, Rakesh explains why AI progress is tied to hardware, what software teams need to relearn about efficiency, and why the economics of data centers should matter to product leaders. Why Chips Became a Society Topic "The race about AI essentially becomes the race about chips." Rakesh traces his path from a small town in India to computer science, chip research, entrepreneurship, and eventually writing The Chip Age. The turning point came during the COVID-era chip shortages, when cars, appliances, and everyday electronics became harder to buy. That moment made chips visible to people outside engineering. AI then raised the stakes further: the promise of new medicines, new materials, and major productivity gains depends on models that require enormous amounts of computation. For software people, that means chips are no longer background infrastructure. They are part of the product strategy, the cost model, and the operating constraint. AI Progress Depends on Computation "To the first order, the more chips you can use and the more data you throw in at training AI models, the more powerful an AI model becomes." Vasco frames the shift with a sharp comparison: AlexNet used two GPUs in 2012, while newer frontier models use tens or hundreds of thousands of GPUs. Rakesh connects that growth to AI scaling laws. The problems AI is asked to solve have changed, from recognizing cats and dogs to scientific discovery and complex reasoning tasks. That creates pressure to train larger models with more data and more chips. The result is a world where software teams cannot assume that compute is cheap, abundant, or invisible. AI roadmaps are now connected to chip availability, data center capacity, energy, and the ability to use hardware well. Software Teams Need to Care About Efficiency Again "Software developers now have to refocus on performance, because that dictates the quality of AI you can serve and the cost of AI when you're serving AI." For years, software teams could often rely on hardware getting faster underneath them. Rakesh says AI changes that habit. If two teams have access to the same number of chips, the team that extracts more useful work from those chips has an advantage. That advantage shows up in model quality, inference cost, latency, and energy consumption. Efficiency is no longer a niche concern for low-level specialists. It becomes a product concern. Teams building with AI need to understand where computation goes, how much energy it consumes, and which architectural choices make expensive infrastructure work harder than it needs to. The Hardware and Software Boundary Is Moving "Because of AI, the hardware design and the software design at some level, those abstractions have started merging." Rakesh points to new AI-assisted chip design workflows, including the Jalapeno chip example Vasco mentions, as a sign that software and hardware work are moving closer together. Chip design that once took years can now be accelerated with AI-supported automation and specialized partners. At the same time, hardware choices are becoming more tailored to AI workloads. General-purpose chips offer flexibility, but specialized chips may offer much better efficiency. That creates a trade-off familiar to software leaders: optimize too narrowly and the target may move; stay too general and the system may be too costly to run. The Data Center Constraint "I think we have to figure out how to do AI efficiently. The current way of doing AI seems pretty unsustainable to me." Rakesh warns that AI data centers are running into physical constraints. Large facilities can consume gigawatts of power, and a significant share of that power is used to move heat out of the system. There are also inefficiencies in generation, transmission, distribution, cooling, and in the short useful life of expensive GPUs when model requirements change quickly. For agile teams and product leaders, this matters because energy and infrastructure are becoming part of the real cost of AI features. The question is not only whether an AI feature works. It is whether it can be served responsibly, affordably, and at scale. What Breaks First in the AI Supply Chain? "The capacity of the grid grows really slowly. We have this slowly increasing supply now hitting against the AI exponential." When Vasco asks what may break first if AI demand keeps rising, Rakesh ranks energy supply as the biggest challenge. New transmission lines and grid connections can take years, while AI demand grows much faster. Chip supply comes next: can the industry build enough chips fast enough? Cost is also a pressure point, especially for smaller companies, developing countries, and individual consumers. Rakesh also flags a broader economic risk: data centers can cost billions, and some financing is backed by older chips as collateral. If the economics fail, the impact may reach beyond individual AI companies. What Software Developers Should Prepare For "Generating functional code will be a lot easier in future than generating functional code that meets your performance and energy objectives and constraints." Rakesh argues that every software engineer needs to become fluent with AI, but that is only the starting point. The valuable work may shift toward areas where AI still struggles: physical AI, robotics, IoT, sensors, performance, energy, and verification. If AI writes more code, teams still need ways to build confidence in that code. Vasco connects this to familiar engineering practices such as testing, performance testing, security testing, and maturation. The future may include much more software than today, but the scarce skill may be knowing how to make software trustworthy, efficient, and suitable for the physical systems it touches. About Rakesh Kumar Rakesh Kumar is a Professor and John Bardeen Faculty Scholar in Computer Engineering at Illinois and author of The Chip Age. He studies chips and computer systems, co-founded chip companies, advised companies and governments, and developed technologies now used in phones, tablets, and computers. You can follow Rakesh Kumar's work on his University of Illinois webpage and read The Chip Age.

Marcin Klimaszewski: The Product Owner View of Great Scrum Masters in Agile Teams In this episode, we refer to Design Thinking, Product Build Day, and The Mom Test by Rob Fitzpatrick. The Great Product Owner: A Scrum Master Who Knows When to Step Into Product Work Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "The skill of a great Scrum Master is being flexible with the role." - Marcin Klimaszewski Because this is a Product Owner week, Marcin closes the week by describing what great Scrum Masters look like from the product side. The key word is flexibility. A great Scrum Master protects team rhythm and alignment, but also understands when the team needs something outside the textbook process. Marcin shares the example of a product or epic kickoff where the Scrum Master worked with the Product Owner and Product Designer to create a useful workshop. The team did not only hear what was expected. They clarified assumptions, named missing data, discussed whether discovery was needed, and identified risks early. That kind of kickoff can save weeks later because it gives the whole team a shared understanding of what they are trying to deliver and how they need to deliver it. For Product Owners, that Scrum Master is not a process guardian standing aside. They are a partner who notices when product clarity, team alignment, and delivery confidence need help. Self-reflection Question: Where could you step in this week to help the team clarify product assumptions before sprint execution begins? The Bad Product Owner: The Scrum Master Anti-Pattern of Staying Inside the Role Description Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "Scrum Masters could go to someone else to get inspiration. This flexibility can come from different directions." - Marcin Klimaszewski The anti-pattern in Marcin's story is the Scrum Master who treats the role description as a boundary instead of a starting point. Product work often contains uncertainty: outdated data, missing discovery, technical blockers, stakeholder tension, or unclear decisions. A Scrum Master does not need to be a product expert, designer, architect, or developer to help. They need to sense the tension and know how to inquire. Vasco gives a simple example: hear tension in a meeting, ask the architect for coffee, and learn what is really blocking the team. Marcin adds that Scrum Masters can learn from their own background and from other specialists, just as therapists use supervisors to think through difficult situations. The lesson for Scrum Masters is practical: flexibility is not improvising randomly. It is knowing when the process is not enough, asking better questions, and helping the team find the conversation that needs to happen. Self-reflection Question: Are you using the Scrum Master role to create clarity, or to avoid stepping into unclear conversations? [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 Marcin Klimaszewski Marcin Klimaszewski runs Product Build Days. One day to validate a business idea. Teams build the app themselves with AI tools, use synthetic users to sort out the usability, and design the sharpest test they can run the next day with real users. For founders, PMs, designers and other non-coders. An idea that cannot survive one day is not worth a quarter. You can link with Marcin Klimaszewski on LinkedIn. You can also learn more at Product Build Day.

Marcin Klimaszewski: Product Owner Ownership That Gives Agile Teams Real Direction 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. "Ownership is one of the most important things, and knowing how to hold this ownership." - Marcin Klimaszewski Marcin defines Product Owner success through ownership. The word is in the title, but in many organizations the role is not actually given the authority, clarity, or support needed to make decisions. A successful Product Owner protects the team from conflicting stakeholder pressure, becomes a reliable decision point, and gives the team a clear sense that product decisions will lead somewhere. Marcin shares a Product Build Day example where a founder entered the day with a clear statement: the prototypes and tests would inform real product direction, not become a fun internal exercise. That clarity changed the team's energy. People knew the work mattered, the decision would affect future sprints, and the Product Owner would own the result. Vasco connects this to Extreme Ownership by Jocko Willink: Product Owners cannot hide behind "someone told me so." They need to own the goal, the trade-offs, and the decisions that guide the team. Self-reflection Question: Does your team know which product decisions are real decisions, and who owns them? Featured Retrospective Format for the Week: Silent Notes, Clustering, and Dot Voting Marcin's favorite retrospective format starts quietly. Everyone writes feedback on sticky notes, online or offline, often anonymously. The notes are then revealed, grouped into similar themes, named by the team, and voted on so the group can select the most important topic to address. The strength of this format is that it gives quieter people room to contribute, makes everyone read what others wrote, and reduces the chance that the loudest voice defines the whole conversation. Vasco adds a useful sanity check: after voting, ask whether anyone sees a better idea on the board that did not get selected. That small pause helps the team guard against groupthink. Marcin's tip: do not use any retrospective format too many times in a row. Change the format to create fresh thinking. [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 Marcin Klimaszewski Marcin Klimaszewski runs Product Build Days. One day to validate a business idea. Teams build the app themselves with AI tools, use synthetic users to sort out the usability, and design the sharpest test they can run the next day with real users. For founders, PMs, designers and other non-coders. An idea that cannot survive one day is not worth a quarter. You can link with Marcin Klimaszewski on LinkedIn.

Marcin Klimaszewski: Product Owner Discovery When Agile Stakeholders Want Delivery First 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. "If I can ship everything by the weekend, what is worth shipping?" - Marcin Klimaszewski Marcin's current challenge is one many Product Owners recognize immediately: convincing stakeholders to invest time and money in discovery. Everyone says they want to understand the customer, but when discovery becomes real work, the pressure returns to plans, backlogs, and delivery. Marcin points to the Double Diamond design process as a useful way to explain the work. The first diamond explores problems and decides which problem deserves attention. The second diamond explores solutions. Many companies rush into the second diamond and become feature factories. The backlog is already large, stakeholders already have promises, and discovery can feel like more uncertainty instead of progress. Marcin's experiment is to shrink discovery into something stakeholders can tolerate and teams can actually run: Product Build Day, a one-day workshop where people build AI-assisted prototypes, pitch options, and design the sharpest user test for the next day. The larger shift is clear: product development is a search problem, not just a delivery problem. In this episode, we refer to Design Thinking's Double Diamond and Product Build Day. Self-reflection Question: How much of your backlog exists because the team is avoiding the uncertainty of discovery? [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 Marcin Klimaszewski Marcin Klimaszewski runs Product Build Days. One day to validate a business idea. Teams build the app themselves with AI tools, use synthetic users to sort out the usability, and design the sharpest test they can run the next day with real users. For founders, PMs, designers and other non-coders. An idea that cannot survive one day is not worth a quarter. You can link with Marcin Klimaszewski on LinkedIn.

Marcin Klimaszewski: The Product Owner Lesson From Agile Teams That Forget the User 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 user never wants to log in. That is never the goal of the user." - Marcin Klimaszewski Marcin describes a pattern he has seen too often: teams speak about users as if the team already knows what users need. In one EdTech example, the obvious solution looked simple from the development side: students should log in. But in a classroom with twenty or thirty students and only forty-five minutes, login was not a neutral feature. A few forgotten passwords, a few typos, and the teacher suddenly became an administrator instead of a teacher. The Product Owner needed the team to see the real problem, not just the technically familiar solution. The eventual answer was simpler for the users: the teacher logged in and shared a code with the students. That gave the product enough identification without stealing classroom time. Marcin connects this to the Sam Walton reminder that the customer is the real boss. For Product Owners and Scrum Masters, the work is not to defend our preferred solution. The work is to keep asking what problem the user is trying to solve. In this segment, we talk about EdTech and the Sam Walton idea that the customer can fire everyone by spending money somewhere else. Self-reflection Question: Where is your team solving an internal business problem and calling it a user need? Featured Book of the Week: The Mom Test by Rob Fitzpatrick Marcin recommends The Mom Test by Rob Fitzpatrick because it helps product people and Scrum Masters ask better questions. The trap is familiar: we explain our idea, ask whether people like it, and receive polite opinions instead of useful evidence. Marcin points out that better discovery starts with people's real experiences, problems, and past behavior. He also recommends Sprint by Jake Knapp, a practical guide to design sprints and structured product discovery. Sprint helped him see workshops as sequenced decisions toward a larger goal, not ceremonies to follow blindly. The method is useful only when it helps the team learn, align, prototype, test, and decide. [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 Marcin Klimaszewski Marcin Klimaszewski runs Product Build Days. One day to validate a business idea. Teams build the app themselves with AI tools, use synthetic users to sort out the usability, and design the sharpest test they can run the next day with real users. For founders, PMs, designers and other non-coders. An idea that cannot survive one day is not worth a quarter. You can link with Marcin Klimaszewski on LinkedIn.

Marcin Klimaszewski: When Product Owner Success Creates Blind Spots for 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. "I am not the user. That is how I learned how important it is to keep your ego small." - Marcin Klimaszewski Marcin Klimaszewski started in product as a webmaster, writing HTML and CSS, before discovering UX design through a colleague who became his mentor. That shift changed how he looked at software: not as screens to build, but as problems to understand. In this episode, Marcin shares an EdTech product story where the team had everything a product person could hope for: access to students and teachers, weekly validation, a strong Product Owner, and a confident team. The problem was that success started to distort the team's relationship with the rest of the organization. As the team received positive user testing feedback, they began to see themselves as the best team in the company. From the outside, that confidence looked like arrogance, and critical dependencies with sales, marketing, e-commerce, and payments became harder to manage. The product eventually launched, but never reached the sales targets. For Marcin, the lesson is sharp: user testing is not market testing, and Product Owners need Scrum Masters who help teams stay connected to reality before the market does it for them. In this episode, we refer to EdTech and Product Build Day. Self-reflection Question: Where is your team getting positive feedback that may be hiding the real market risk? [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 Marcin Klimaszewski Marcin Klimaszewski runs Product Build Days. One day to validate a business idea. Teams build the app themselves with AI tools, use synthetic users to sort out the usability, and design the sharpest test they can run the next day with real users. For founders, PMs, designers and other non-coders. An idea that cannot survive one day is not worth a quarter. You can link with Marcin Klimaszewski on LinkedIn.

Joseph Osei-Kusi: Great Product Owners Bring Customer Problems, Not Just Backlog Items In this episode, we refer to Product Owner anti-patterns and how Scrum Masters can coach Product Owners without becoming the hidden Product Owner. The Great Product Owner: Clarity, Courage, and Customer Context 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. "This product owner gave the team the problem, and not just the solution." - Joseph Osei-Kusi Joseph describes a great Product Owner who changed the team's dynamic by bringing clarity, courage, and context. Instead of feeding tickets to developers, this Product Owner explained the customer problem, the business outcome, and what success would look like. That gave the team room to think. Developers started asking better questions: What should we build? Is there a simpler way to solve this? Can we test this with a smaller release first? The Product Owner was also clear about what the team was not doing. When urgent stakeholder requests appeared, the question became: Is this more important than the current Sprint Goal? That single question made trade-offs visible. Vasco highlights an important effect: starting with the customer problem creates empathy and brings the Product Owner into the team's problem-solving space. Self-reflection Question: Does your Product Owner bring your team customer problems to solve, or mostly solutions to implement? The Bad Product Owner: The Order-Taker Backlog 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 everything is priority one, nothing is truly priority one." - Joseph Osei-Kusi Joseph's Product Owner anti-pattern is the order-taker PO. This Product Owner cared and worked hard, but had become a pass-through for stakeholder requests. Every request entered the backlog. Everything was urgent. Everything was high priority. The backlog became a storage room for everyone's wishes, and the impact on the team was predictable: weak Sprint Goals, context switching, and developers building features without understanding the outcome behind them. Joseph helped by coaching through questions instead of making decisions for the PO. What problem are we solving? What outcome matters now? What happens if we do not do this right now? What are we willing to say no to? Those questions helped the Product Owner move from taking orders to making decisions, while keeping the Scrum Master out of the hidden Product Owner trap. Self-reflection Question: What decision-making questions could help your Product Owner say "not now" with more confidence? [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 Joseph Osei-Kusi Joseph is an Agile coach and Scrum Master obsessed with the human side of delivery. He has focused on moving teams beyond just "following the process" to delivering value. He champions radical transparency and psychological safety, and believes that when you get the people part right, everything else falls into place. You can link with Joseph Osei-Kusi on LinkedIn.

Joseph Osei-Kusi: Success for Scrum Masters Is a Team That Improves Without You Driving Every Conversation Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "Success is when a team can improve without having me drive every conversation." - Joseph Osei-Kusi For Joseph, Scrum Master success is not a clean Jira board or perfectly run events. Success shows up when the team becomes more honest, more autonomous, and more able to inspect and adapt without depending on the Scrum Master for every conversation. He looks for small accountability signals: team members raising risks early, developers challenging unclear priorities, people calling out broken working agreements, and retrospectives leading to real experiments. If the Product Owner and developers only talk when the Scrum Master arranges the conversation, the role has become a dependency. Joseph also watches how stakeholders are brought into the improvement loop without letting them take control of the team. The point is to create the right conversations and protect the team's ability to make decisions. For Scrum Masters, the invitation is clear: measure success through team behavior, not through ceremony performance. Self-reflection Question: If you stepped away for two weeks, which improvement conversations would your team still have without you? Featured Retrospective Format for the Week: Mad/Sad/Glad Plus One Concrete Experiment Joseph's favorite retrospective format is Mad/Sad/Glad followed by one concrete experiment. The format helps teams talk about the human experience of the sprint instead of staying at the level of mechanics. What made us mad? What made us sad? What made us glad? But Joseph does not let the team stop at venting. Once the patterns are visible, he asks for one small experiment the team is willing to try in the next sprint. One real experiment has a better chance of changing behavior than ten action items nobody owns. In the next retrospective, the team can inspect whether the experiment helped, whether to continue it, change it, or stop it. [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 Joseph Osei-Kusi Joseph is an Agile coach and Scrum Master obsessed with the human side of delivery. He has focused on moving teams beyond just "following the process" to delivering value. He champions radical transparency and psychological safety, and believes that when you get the people part right, everything else falls into place. You can link with Joseph Osei-Kusi on LinkedIn.

Joseph Osei-Kusi: Helping Agile Managers Move from Control to Enablement 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. "Their value is not knowing every ticket status. It is creating the conditions where the team can deliver without friction." - Joseph Osei-Kusi Joseph brings a current challenge he calls the middle management squeeze. As Agile teams become more self-organized, some managers experience autonomy as a loss of control, visibility, or even identity. That fear can show up as more status requests, being copied on every conversation, or stepping back into decisions the team should be making. Joseph does not frame those managers as blockers. He starts with empathy, because managers are often accountable for outcomes while being asked to trust a system they did not help design. The coaching move is to shift the conversation from managing tasks to improving the system. Instead of inspecting every ticket, managers can help with approval delays, conflicting priorities, dependencies, and unclear stakeholder expectations. Vasco and Joseph explore one useful experiment: create intentional contact points where managers can support the team without taking over the backlog or sprint details. In this episode, we refer to servant leadership and the Scrum Master role in helping managers become enablers of flow, not controllers of tasks. Self-reflection Question: Which manager around your team may need a clearer, more useful role in the Agile system? [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 Joseph Osei-Kusi Joseph is an Agile coach and Scrum Master obsessed with the human side of delivery. He has focused on moving teams beyond just "following the process" to delivering value. He champions radical transparency and psychological safety, and believes that when you get the people part right, everything else falls into place. You can link with Joseph Osei-Kusi on LinkedIn.

Joseph Osei-Kusi: How Artificial Harmony Silences Agile Teams Before the Real Problems Surface 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. "Silence can be more dangerous than conflict, because at least with conflict something is being expressed." - Joseph Osei-Kusi Joseph shares a team story from a high-stakes migration project where the team looked mature on the outside. Meetings were calm. Nobody argued. Plans were accepted quickly. But what looked like alignment was really artificial harmony. Stakeholders brought pressure and proposed solutions, while the team softened their message instead of making risks visible. Over time, that silence created bottlenecks, delayed difficult conversations, increased technical debt, and left the team with fewer options. Joseph learned to treat unusual quietness as data. When a team agrees too quickly, he asks questions like: What would make this plan work? What would make it fail? What concerns are we not saying out loud? The goal is not to create drama. The goal is to make reality visible early, while the team and stakeholders still have room to choose. In this segment, we talk about artificial harmony and how Scrum Masters can help teams make trade-offs visible before silence becomes expensive. Self-reflection Question: Where might your team be choosing politeness over useful honesty? Featured Book of the Week: The Five Dysfunctions of a Team by Patrick Lencioni Joseph recommends The Five Dysfunctions of a Team by Patrick Lencioni because it helped him see that many team issues are trust problems before they are process problems. Poor planning, quiet retrospectives, weak working agreements, and missed commitments often point to something deeper: people avoiding conflict because the trust is not there. Vasco also mentions The Speed of Trust by Stephen M. R. Covey, a useful companion for understanding the business impact of high-trust versus low-trust environments. For Joseph, these books reinforce a core Scrum Master lesson: teams do not always need another process tweak. Sometimes they need to rebuild trust and learn how to disagree productively. [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 Joseph Osei-Kusi Joseph is an Agile coach and Scrum Master obsessed with the human side of delivery. He has focused on moving teams beyond just "following the process" to delivering value. He champions radical transparency and psychological safety, and believes that when you get the people part right, everything else falls into place. You can link with Joseph Osei-Kusi on LinkedIn.

Joseph Osei-Kusi: When the Jira Board Looked Fine but the Agile Team Was Drained 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. "Metrics are conversation starters, not the full truth." - Joseph Osei-Kusi Joseph Osei-Kusi joins us from New York to share a failure from early in his Scrum Master journey, when he became what he calls the "Jira observer Scrum Master." The board looked clean, the metrics looked acceptable, and the tasks appeared to be moving. Underneath that tidy surface, the team was losing energy. People had stopped speaking up, agreement came too quickly, and the real conversations moved outside the meetings. Joseph realized too late that he had been paying more attention to the board than to the people doing the work. The cost was real: two developers left the team. That moment changed how he approached the role. Today, Joseph uses metrics as an invitation to ask better questions: What changed? How does the team feel? What are we not seeing? For Scrum Masters, the warning is simple: a board can look healthy while the human system is already struggling. In this episode, we refer to psychological safety and how Scrum Masters can use metrics as a doorway into better team conversations. Self-reflection Question: What quiet signals might your team be sending that do not show up on your Jira board? [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 Joseph Osei-Kusi Joseph is an Agile coach and Scrum Master obsessed with the human side of delivery. He has focused on moving teams beyond just "following the process" to delivering value. He champions radical transparency and psychological safety, and believes that when you get the people part right, everything else falls into place. You can link with Joseph Osei-Kusi on LinkedIn.

BONUS: AI Changes Management, Not Leadership In this BONUS episode, we explore what AI changes for software leaders, and what it leaves firmly in human hands. Mateo Bervejillo, CEO of Xseed Solutions and author of Back to Basics, brings the view of a manager of managers: AI can help us process information faster, but leadership still happens through clarity, judgment, and relationships. From Attorney to Software CEO: Clarity as a Leadership Skill "What are we building? Why are we building it? What's the benefit for the client? What's the business value?" Mateo started his career as an attorney, then moved through operations, vendor management, business development, and finally into software company leadership. That path gave him an unusual advantage in technology: an obsession with clear definitions. In law, unclear scope creates risk. In software, unclear scope creates waste, frustration, and products that miss the point. For Mateo, leadership starts before execution, with crisp answers to simple questions: what problem are we solving, why does it matter, and what would success look like? AI Removes Busywork, But It Does Not Replace Leadership "There's a part about management that is moving information around, up and down, sideways. That is changing drastically because of AI." Mateo sees AI transforming the administrative side of management: gathering data, processing updates, preparing reports, and helping managers stay on top of follow-ups. But he draws a firm line between management mechanics and leadership. AI can make managers faster at moving information, but it cannot choose the right people, create trust, provide meaningful feedback, or understand what motivates each person. The danger is that organizations may conclude they need fewer leaders because the reporting work became easier, while the human work actually becomes more important. The One-on-One Cannot Become a Slack Check-In "If you have one manager leading 50 people, that one-on-one that was so important now becomes a Slack message." One of the risks Mateo calls out is the pressure to flatten organizations and stretch managers across too many people. On paper, AI makes that look possible. In practice, it can turn leadership into status collection. Mateo described his own weekly rhythm: face-to-face conversations, walking meetings, and one-hour one-on-ones where the work is to listen, ask questions, understand what is happening in the person's life and work, and keep the company aligned around its North Star. That is not overhead. It is the work that keeps teams healthy before problems become escalations. Use AI as a Sparring Partner, Not as the Thinker "The problem of the blank page goes away with AI. You can have a conversation." Mateo uses AI as an assistant for podcast preparation, idea generation, research, outreach, and even book writing. When drafting Back to Basics, he used AI to challenge the structure and ask what was missing, which led to several chapters he had not planned. The point is not to outsource judgment. It is to remove the fear of starting, create better first drafts, and pressure-test thinking. For Scrum Masters and agile coaches, that means AI can help design workshops, prepare questions, and explore options, but the leader still has to understand the context and make the call. Outcomes Keep Leaders Away From Micromanagement "Too much focus on the inputs can be misleading and you forget about the outcome, which is where the client sits." AI gives managers more visibility into activity, and that can quickly become control. Mateo's antidote is to keep the organization focused on outputs and outcomes instead of inputs. Story points, process steps, and activity metrics can be useful, but they can also pull leaders into managing the wrong thing. Clients care about outcomes. Teams need clarity about the result, then room to decide how to get there. When leaders become obsessed with the how of every input, they move from creating clarity into micromanagement. Managing Up With AI, Managing People With Care "Today we are going through a time where we need to stay close to people more than ever and make it personal." In Mateo's book, leadership is framed across four dimensions: managing up, managing yourself, managing teams, and managing sideways. Through the AI lens, he sees the biggest immediate gain in managing up: clearer communication, faster delivery, better follow-up, and fewer things falling through the cracks. But when it comes to managing teams, the basic human work becomes more important. People are anxious about AI and jobs, even when they are not saying it openly. Leaders need to stay close, make the relationship personal, and create the conditions where people can thrive. About Mateo Bervejillo Mateo Bervejillo is CEO of Xseed Solutions, a Montevideo-based software development and staff augmentation company helping US firms build high-performing LATAM engineering teams. An attorney by background, he brings a results-first view to tech leadership. He wrote Back to Basics, a practical leadership guide for new managers in technology. LinkedIn. You can link with Mateo Bervejillo on LinkedIn, learn more about Xseed Solutions, and listen to Mateo's podcast, The Future Of The Future.

Oluyomi Emmanuel: Product Owners Who Turn Feedback Into Agile Team Learning The Great Product Owner: Listening, Investing, and Learning With the Team 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. "A great product owner is not the person with all the answers. It is the person who creates access to the right evidence." - Oluyomi Emmanuel Oluyomi shares the example of a Product Owner whose strongest habit was asking the team for feedback, listening without defending himself, and then acting on what he heard. In one sprint review, the team looked at internal metrics and raised a difficult concern: they were completing work, but it did not always seem closely connected to what customers needed. The Product Owner could have defended the roadmap or blamed incomplete metrics. Instead, he treated the feedback as evidence worth investigating. He secured a training budget and enrolled both himself and the whole team in behavior-driven development training. More importantly, the training did not remain a certificate exercise. The Product Owner joined the learning and helped bring BDD practices into refinement, stakeholder conversations, and interviews. The team's conversations moved from abstract requirements to specific situations and expected outcomes. Hidden assumptions became visible earlier, and the team could challenge unclear requirements constructively before implementation began. Self-reflection Question: How does your Product Owner show the team that feedback changes real behavior? The Bad Product Owner: The Absent Product Owner as a Role Design Problem 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. "An absent product owner is often not an individual time management problem. It is usually a role design problem." - Oluyomi Emmanuel Oluyomi also describes the absent Product Owner anti-pattern. In his example, the Product Owner was not careless or uninterested. The structural problem was that the same person was both Product Owner and line manager, so the Product Owner role kept being squeezed into whatever time remained. Epics existed, but the team lacked enough context to refine them. Questions accumulated, refinement became a place to discover missing information, and important decisions waited for someone who was rarely available. Oluyomi first asked for more Product Owner availability, but that did not change the system because the competing responsibilities remained. He then created a stakeholder map for the major areas of work: who had the business problem, who owned the desired outcome, who had specialist knowledge, and who would be affected by the change. Inviting relevant stakeholders into refinement gave developers direct access to context. The lesson was not to remove product ownership, but to stop making the Product Owner the only messenger between the team and every stakeholder. In this segment, we refer to behavior-driven development, product ownership, and stakeholder collaboration. Self-reflection Question: Are you compensating for an unavailable Product Owner in a way that keeps the real organizational design problem hidden? [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 Oluyomi Emmanuel Oluyomi is a Scrum Master, Agile Coach, and Product Lead with over seven years of experience helping teams work better and deliver meaningful digital products. Having worked across energy, consumer platforms, and fintech, he is passionate about building high-performing teams, creating clarity, and turning Agile principles into real business and customer value. You can link with Oluyomi Emmanuel on LinkedIn.

Oluyomi Emmanuel: Constructive Independence as a Scrum Master Success Metric Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "Success is when the team increases its capacity to notice, discuss, and solve the problems that stand between them and meaningful outcomes." - Oluyomi Emmanuel Oluyomi's definition of Scrum Master success has changed over time. Today, he measures success by the team's growing ability to notice, discuss, and solve the problems that stand between them and meaningful outcomes. One practical signal is when someone in the team says or does something he would previously have needed to prompt: a developer challenges an unclear requirement, a tester raises a risk before anyone asks, or a team member names a problem directly. Oluyomi calls the strongest indicator "constructive independence." That does not mean the team no longer needs support. It means the team's mental model has matured enough that people act earlier, with more ownership and less dependency. To keep himself accountable, Oluyomi runs a small personal retrospective at the end of each workday. He starts the day with a few things he wants to measure himself by, then later uses Copilot as a reflection partner to compare intention with action. Vasco notes that this is one useful way AI tools can help Scrum Masters maintain the discipline of reflection without relying only on memory. Self-reflection Question: What would tell you that your team is becoming constructively independent? Featured Retrospective Format for the Week: True or False Statements Oluyomi does not pick a retrospective format before understanding the sprint. He watches patterns during the iteration: how work waits, how conflict is handled, whether decisions are revisited, and whether people ask for help early. One format he often uses is a set of true-or-false statements about the sprint and collaboration. For example: "We finished work before starting more work" or "We asked for help early enough during the sprint." Team members vote silently first, either on a Miro board or with physical cards. The value is not the majority answer. The value appears when different people interpret the same sprint differently. Instead of asking who is right, Oluyomi asks what each group observed that led to its answer. [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 Oluyomi Emmanuel Oluyomi is a Scrum Master, Agile Coach, and Product Lead with over seven years of experience helping teams work better and deliver meaningful digital products. Having worked across energy, consumer platforms, and fintech, he is passionate about building high-performing teams, creating clarity, and turning Agile principles into real business and customer value. You can link with Oluyomi Emmanuel on LinkedIn.

Oluyomi Emmanuel: Creating Agile Value Stream Visibility Without More Administration 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. "Transparency is not created by displaying more information. Transparency is created when people share enough meaning to interpret that information in the same way." - Oluyomi Emmanuel Oluyomi's current challenge is helping an organization create end-to-end visibility and ownership across several value streams without turning the solution into another layer of administration. At first, the problem looked like a Jira hierarchy issue: initiatives, epics, stories, and tasks needed shared definitions. But the conversations exposed something deeper. Different groups used the same work item names to mean different things, and those differences made prioritization, dependency management, coordination, and reporting harder. Together with a colleague, Oluyomi framed the work as alignment experiments instead of a large rollout. One workshop asked what makes an initiative different from an epic, what information must exist before work moves forward, and when the next level of work should be created. The biggest tension was ownership, not terminology. A second experiment, a cross-value-stream visibility session, used real initiatives to expose overlapping work, unclear ownership, and weak links to outcomes. Vasco then pushed the conversation toward intake: perhaps the problem was not only shared meaning, but the absence of a single view of what the organization needs to do. Oluyomi's next experiment is linking initiatives to quarterly goals and OKRs to see what really deserves attention. In this episode, we refer to value streams, OKRs, and portfolio management. Self-reflection Question: Does your organization have one visible list of important work, or many competing lists with unclear ownership? [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 Oluyomi Emmanuel Oluyomi is a Scrum Master, Agile Coach, and Product Lead with over seven years of experience helping teams work better and deliver meaningful digital products. Having worked across energy, consumer platforms, and fintech, he is passionate about building high-performing teams, creating clarity, and turning Agile principles into real business and customer value. You can link with Oluyomi Emmanuel on LinkedIn.

Oluyomi Emmanuel: From My Task to Our Work 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. "We shifted their thinking from my task to our work." - Oluyomi Emmanuel Oluyomi describes a destructive pattern many Scrum Masters will recognize: local responsibility inside a supposedly shared team. The team looked collaborative during Scrum events, but once the meetings ended, developers, testers, and reviewers behaved like separate specialists. Developers finished coding and moved on. Testers waited for the right context or environment. Pull requests sat in review. Everyone looked busy, and everyone could explain their own behavior, but work was not reaching Done. The board already showed the queues, yet visibility alone did not change behavior because the team still spoke in individual language: "my development is finished," "testing belongs to QA," and "my task is done." The change started in a retrospective, where the team stopped asking who caused the delay and began asking where work stopped flowing. They tested small experiments: swarming around items waiting in testing, reviewing aging work together, and avoiding new starts when existing work needed help. The daily standup became a place to ask a better question: what does this item still need before value can be delivered? In this segment, we talk about flow, team ownership, and work in progress. Self-reflection Question: What language in your daily standup reinforces "my task" instead of "our work"? Featured Book of the Week: Handbook of Facilitative Leadership by Pepe Nummi Oluyomi recommends Handbook of Facilitative Leadership: Concrete Ways to Boost Performance by Pepe Nummi. The book helped him see that leadership is not always about having the strongest opinion or offering the solution. Sometimes leadership means designing the process through which a group can think, contribute, decide, and take ownership together. For Scrum Masters, that distinction matters because the people in the room often already have the knowledge needed to solve the problem. The knowledge is just distributed across the team. Facilitative leadership helps bring that knowledge into the open. [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 Oluyomi Emmanuel Oluyomi is a Scrum Master, Agile Coach, and Product Lead with over seven years of experience helping teams work better and deliver meaningful digital products. Having worked across energy, consumer platforms, and fintech, he is passionate about building high-performing teams, creating clarity, and turning Agile principles into real business and customer value. You can link with Oluyomi Emmanuel on LinkedIn.

Oluyomi Emmanuel: When Agile Team Trust Breaks Before the Scrum Master Acts 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. "Once that trust is broken, everything else, nothing else matters." - Oluyomi Emmanuel Oluyomi Emmanuel started his Scrum Master journey after a strategic move toward Agile ways of working changed his project coordinator role into something deeper: helping people communicate when the answers were unclear. In this episode, he shares a hard lesson from a newly formed software team of eight people, where tension between a tech lead and a new developer first appeared in GitHub pull request comments. There were sarcastic replies, cameras switched off during the daily standup, and a growing distance when the team worked in the same office. Oluyomi initially treated it as a normal forming-stage conflict and waited for the team environment to absorb the tension. By the time the tech lead escalated concerns to the developer's line manager, trust had already deteriorated. A facilitated feedback session produced an improvement plan, but the developer experienced the feedback as judgment rather than support and left the team less than a month later. Oluyomi's lesson was clear: a Scrum Master needs to name trust concerns early, first in one-on-ones, then together, before the relationship becomes too damaged to repair. In this episode, we refer to psychological safety, conflict resolution, and team trust. Self-reflection Question: What early sign of broken trust have you noticed but not yet named with your team? [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 Oluyomi Emmanuel Oluyomi is a Scrum Master, Agile Coach, and Product Lead with over seven years of experience helping teams work better and deliver meaningful digital products. Having worked across energy, consumer platforms, and fintech, he is passionate about building high-performing teams, creating clarity, and turning Agile principles into real business and customer value. You can link with Oluyomi Emmanuel on LinkedIn.

BONUS: Why AI Needs More Than Silicon Valley Moonshots With Salima Bhimani AI is changing the work of software teams, but Salima Bhimani argues that the bigger question is not only what AI can automate. In this BONUS episode, Salima shares what she learned inside Alphabet's moonshot ecosystem, why breakthrough ideas may be hiding in plain sight, and how more people can become moonshot makers when technology meets lived intelligence. Invention Starts in Real-World Constraints "Invention is something that is always happening in relationship to something that's in the world." Salima traces her view of invention back to a family history of migration, adaptation, and rebuilding under constraints. Her roots go from India to East Africa, where her family had to learn new languages, new land, and new ways to survive. That experience shaped a practical view of innovation: invention is not only the work of a lone genius in a lab. It often starts in friction, necessity, and the daily encounter between people and the systems around them. We May Be Thinking Too Small About Innovation "We've actually shrunk our ability to see what's out there in the world by limiting who's in the room." Salima respects what Silicon Valley has built, from search to self-driving technology to AI. But her challenge is that the dominant innovation model often starts with a small group defining the problem, building a product, and then deploying it into the world. That can miss the collective intelligence already present in the places where the problems live. For software leaders and agile practitioners, the question becomes sharper: what would change if discovery started earlier, closer to the real ecosystem, with more forms of expertise present before the solution is framed? AI as Infrastructure, Not the Destination "The software itself is not just the solution. The software is the catalyst." Salima argues that many organizations are still focused on AI as a tool for optimization: saving seconds, making teams more productive, or automating parts of the work. Those uses matter, but they can keep leaders thinking too narrowly. When AI becomes infrastructure, it becomes part of the platform that unlocks growth, capacity, and new ways to work across a system. In software organizations, that means shifting attention from "what tool should we apply?" to "what outcome could this platform make possible?" Breakthroughs Come From Asking What the World Needs "The greatest breakthroughs come from people really sitting down and asking what the world needs or doesn't need." Working around Alphabet's moonshot environment taught Salima that breakthrough ideas are not only born from research labs or visionary founders. The next generation of innovation may come from people asking better ecosystem-level questions: how education changes with AI, how talent changes, how information is consumed, and how the labor market shifts around new infrastructure. The barrier to entry is lower now, which means more people can stand in the place where moonshots are imagined. Third-Space Moonshots Bring the Lab to the Street "Technology is not the breakthrough. Technology is a partner that allows us to unlock something in a system." In Invent Now, Salima describes third-space moonshots as the convergence of three forces: technology as a co-partner, complex systems such as health, education, mobility, or energy, and human ingenuity from lived experience. This is not simply adding more people to a workshop. It is a different way of discovery, where an engineer, a scientist, a historian, and a street vendor may each see an opportunity the others would miss. As Vasco framed it, this is about bringing street smarts to the lab, and the lab to street smarts. Humanity Is the Moonshot "Humanity is the moonshot, not technology." The Zimbabwe Bush Pump example in Salima's book challenges the usual mental model of moonshots. It may not look like a Silicon Valley breakthrough, but it asks a deeper question: who gets to define what counts as invention, and what kind of impact matters? AI may help us build more, faster, and with lower barriers. But Salima's point is that the real opportunity is not replacing human ingenuity. It is helping more people bring their lived experience into the act of building what their communities, teams, and systems actually need. Becoming a Moonshot Maker "It's a book to spar with. It's not a book to just read." Salima does not describe Invent Now as a playbook. She describes it as an invitation to spar with ideas, disagree, and use the book to provoke new thinking. For Scrum Masters, agile coaches, product leaders, and software teams, that invitation is practical: stop treating AI as the whole story, and start using it as one partner in a broader discovery conversation. The biggest opportunities may already be visible to people inside the system. The work is to notice them, bring the right knowledge together, and build from there. About Salima Bhimani Dr. Salima Bhimani is the author of Invent Now: The Next Leap in Moonshots and CEO of 10X Responsible Tech. A former Alphabet chief strategist for responsible technology, business, and leaders, she worked across Waymo, Wing, DeepMind, and Google X. Her work focuses on AI, moonshots, and inclusive innovation. LinkedIn You can link with Salima Bhimani on LinkedIn, learn more at salimabhimani.com, and read her book Invent Now: The Next Leap in Moonshots.

Pankaj Kumar: Product Owners Who Prepare the Ground for Agile Teams The Great Product Owner: Proactive Preparation Before the Team Asks 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. "Before the team asks, you know that this is the prerequisite for this user story." - Pankaj Kumar Pankaj's example of a great Product Owner is someone who did the homework before meeting the team. This PO understood what the team needed to deliver, prepared the acceptance criteria, talked to UX early, and made sure design inputs were available before developers were blocked. Vasco describes this as "preparing the ground" for the team. The PO was not just pushing features into a sprint. He was listening to what the team could achieve, translating stakeholder needs into clearer work, and reducing waiting time so the team could focus on execution. For Scrum Masters, this is a useful pattern to notice: great Product Owners protect the team's flow by handling communication and dependency work early. Self-reflection Question: What does your Product Owner prepare before the team discovers it needs help? The Bad Product Owner: Pushing Urgent Work Into an Already Full Sprint 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 team was already having everything on the plate, and they can't take any more." - Pankaj Kumar The anti-pattern Pankaj highlights is a Product Owner who treats urgency as permission to ignore capacity. In one sprint, a PO arrived with an important customer case and insisted that it had to enter the current sprint backlog. The team was already overloaded, but the PO was not ready to hear the tradeoff. Pankaj's advice is to slow the conversation enough to make the real decision visible. Why is this urgent? Who is the stakeholder? What is the risk? What is the impact? Can it wait until the next sprint? If it cannot wait, what will be adjusted? Agile welcomes change, but change still has a cost. A Product Owner who says yes without making the tradeoff visible risks damaging trust with the team. In this segment, we refer to root cause analysis, capacity planning, and Product Owner anti-patterns. Self-reflection Question: When urgent work enters the sprint, what does your team explicitly remove or renegotiate? [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 Pankaj Kumar Pankaj Kumar is an experienced Scrum Master and Agile Coach with over 18 years in IT. He helps teams adopt Agile ways of working, improve collaboration, remove impediments, and deliver value consistently. He facilitates Scrum ceremonies, coaches teams and stakeholders, and supports Agile transformation across organizations. You can link with Pankaj Kumar on LinkedIn.

Pankaj Kumar: The Scrum Master Success Metric of Team Independence 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 best thing to measure the success of a Scrum Master is that the team is not dependent on the Scrum Master." - Pankaj Kumar For Pankaj, Scrum Master success has a clear test: can the team work, decide, inspect, and improve without depending on the Scrum Master for every step? He looks for self-organization, confidence in Scrum events, and a team that can continue improving without constant intervention. But he does not rely only on impressions. Pankaj uses team metrics such as velocity, backlog health, lead time, cycle time, and Cumulative Flow Diagrams when Kanban is in use. He also pays attention to team satisfaction and regular feedback. The frequency of that reflection depends on team maturity. Mature teams may need a two-week check-in rhythm, while newer teams need closer weekly attention. His maturity model is deliberately adapted team by team, because every team's product, skills, technical context, and backlog are different. The bigger point for Scrum Masters is useful: success is not being needed in every conversation. Success is seeing the team grow enough that your presence becomes lighter. Self-reflection Question: What would your team do this week if you were not available to guide the Scrum events? Featured Retrospective Format for the Week: Anonymous Action-Tracking Spreadsheet Pankaj keeps retrospectives simple and practical. Before the retrospective, he shares a spreadsheet where team members can add what went well, what needs improvement, the action needed, who is accountable, the deadline, and the status of previous actions. He also allows anonymous input, which helps quieter team members raise points they may not want to voice live. During the meeting, the team reviews previous retrospective actions and then discusses the current sprint. Pankaj is careful about who is in the room. Sometimes supervisors are needed, but often their presence changes what people are willing to say. For him, facilitation starts with creating the right audience for the conversation. [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 Pankaj Kumar Pankaj Kumar is an experienced Scrum Master and Agile Coach with over 18 years in IT. He helps teams adopt Agile ways of working, improve collaboration, remove impediments, and deliver value consistently. He facilitates Scrum ceremonies, coaches teams and stakeholders, and supports Agile transformation across organizations. You can link with Pankaj Kumar on LinkedIn.

Pankaj Kumar: Using Agile Prioritization to Handle Competing Roles Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "Who am I going to deliver to, and how urgent is this task for them?" - Pankaj Kumar Pankaj's current challenge will sound familiar to many Scrum Masters and Product Owners: too many important demands, all arriving at once. He runs his consultancy, Test2Deploy, works with a startup, serves as a board member in Agile Finland, and is also building a healthcare app. The problem is not motivation. The problem is deciding what deserves attention when everything looks valuable. Pankaj uses a simple prioritization matrix built around value and importance, then adds practical filters: deadline, effort, risk, impact, stakeholder, and the stage of the work. Is it still planning? Is it in execution? Can it be delegated? Can it be removed? Vasco connects this personal challenge back to product work, because teams face the same question every sprint. Prioritization is not just a private calculation. The stakeholder matters because they understand urgency, tradeoffs, and business consequences. Pankaj's approach gives Scrum Masters a useful coaching angle: help teams make the decision criteria visible before the pressure hits. In this episode, we refer to prioritization, stakeholder management, and Product Ownership. Self-reflection Question: What criteria does your team use when two pieces of work both look urgent? [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 Pankaj Kumar Pankaj Kumar is an experienced Scrum Master and Agile Coach with over 18 years in IT. He helps teams adopt Agile ways of working, improve collaboration, remove impediments, and deliver value consistently. He facilitates Scrum ceremonies, coaches teams and stakeholders, and supports Agile transformation across organizations. You can link with Pankaj Kumar on LinkedIn.

Pankaj Kumar: The Agile Team Split Between Seniors and Juniors 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 have to focus not on individual tasks, but the team goals. Shared goals." - Pankaj Kumar Pankaj describes a team that had all the ingredients for friction: senior people with deep experience, junior people who needed support, and a Sprint Goal that required everyone to move together. The weak signal showed up in the retrospective. The junior team members were quiet, and the seniors were implicitly treating mentoring as work that did not help them. Pankaj started with one-on-one conversations to understand what was behind the silence. Then he reframed mentoring around the team outcome. The senior people were not being asked to "lose time" helping juniors. They were being asked to build the capability the whole team needed to deliver. He also pointed out that learning flows both ways: junior team members often bring fresh technical knowledge that experienced people have not yet seen. By pairing senior and junior people on shared tasks, the team started to build trust, empathy, and confidence. The result was visible outside the team too. Stakeholders could see the difference in sprint reviews when the team showed up with more alignment. In this segment, we talk about team dynamics, psychological safety, and mentoring. Self-reflection Question: Where is your team still optimizing for individual tasks when the real need is a shared outcome? Featured Book of the Week: Straight from the Gut by Jack Welch Pankaj mentions several leadership books that shaped his thinking, including Start With Why by Simon Sinek, Leaders Eat Last by Simon Sinek, and Stay Hungry Stay Foolish by Rashmi Bansal. The one that stayed with him most was Straight from the Gut by Jack Welch. What connected the book to his Scrum Master work was the push against bureaucracy and the image of building a speedboat instead of a large, slow ship. For Pankaj, that linked directly to empowered teams, fast learning, and the Scrum Master responsibility to help people move from hierarchy into ownership. [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 Pankaj Kumar Pankaj Kumar is an experienced Scrum Master and Agile Coach with over 18 years in IT. He helps teams adopt Agile ways of working, improve collaboration, remove impediments, and deliver value consistently. He facilitates Scrum ceremonies, coaches teams and stakeholders, and supports Agile transformation across organizations. You can link with Pankaj Kumar on LinkedIn.

Pankaj Kumar: Building Agile Trust One Small Scrum Sprint at a Time Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "We are here to learn. Learning is the key." - Pankaj Kumar When Pankaj Kumar first moved from QA lead into the Scrum Master role, the organization was also moving from waterfall into Scrum. The team had been used to long project cycles, and suddenly they were being asked to deliver working software every two weeks. The difficult part was not the process language or the events. It was the fear behind the change. Pankaj saw that the team needed trust before it could take the first real step. He started with one-on-one conversations, made the pilot explicit, and kept bringing people back to a shared outcome instead of individual tasks. The breakthrough came when the team stopped trying to prove that "Scrum works" all at once. Instead, they picked small pieces of work, delivered something tangible, and celebrated the first signs of progress. That sense of accomplishment helped the team replace fear of failure with confidence. For Pankaj, the lesson was simple: a Scrum Master helps the team stretch, but not so far that people stop feeling safe enough to try. In this episode, we refer to psychological safety and Scrum. Self-reflection Question: What is the smallest useful increment your team could deliver this sprint to build confidence in itself? [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 Pankaj Kumar Pankaj Kumar is an experienced Scrum Master and Agile Coach with over 18 years in IT. He helps teams adopt Agile ways of working, improve collaboration, remove impediments, and deliver value consistently. He facilitates Scrum ceremonies, coaches teams and stakeholders, and supports Agile transformation across organizations. You can link with Pankaj Kumar on LinkedIn.

BONUS: Why AI Is Agile's Best Use Case With Melissa Reeve AI is often framed as a technology rollout, but Melissa Reeve makes a different case: organizations that already know how to learn, adapt, and improve are better prepared for AI. In this BONUS episode, we connect Lean, Agile, DevOps, and AI-native work, and explore why Scrum Masters may be closer to the center of AI adoption than they think. From Toyota Production System to AI-Native Work "I didn't really have words for what would later be my career. I didn't know about systems thinking. I didn't know about this thing called Agile." Melissa traces the through-line from studying the Toyota Production System in Tokyo, to early Agile marketing, to developing intellectual property at Scaled Agile, and finally to AI. Her point is that Lean, Agile, and AI-native work are not separate conversations. They all depend on sensing what is happening, shortening feedback loops, learning from reality, and improving the system instead of only optimizing individual tasks. The DevOps Lesson for AI Adoption "People go from doing the task to building, monitoring, and maintaining the automations that do the task." Melissa's AI turning point came after ChatGPT arrived in November 2022. At first she was skeptical, then she started seeing end-to-end marketing workflows that could be changed with AI. That reminded her of the DevOps shift, where software teams moved away from throwing work over the wall and toward automated testing, deployment, and delivery pipelines. For Scrum Masters, the lesson is practical: AI is not only about automating Jira tasks or writing user stories faster. It changes the workflow, the roles around the workflow, and the learning loops that keep the work useful. Scrum Masters as AI Change Leaders "What are Scrum Masters really good at? They're good at helping teams adopt new ways of working." Melissa sees a positive opening for Scrum Masters and Agile coaches. Organizations have bought AI licenses and told people to experiment, but many leaders are still unclear about how AI should change real work. Scrum Masters already work with flow, bottlenecks, experiments, psychological safety, and improvement backlogs. That gives them a useful place to start: map one or two workflows with the team, clarify decision rights, identify where AI can remove or improve steps, and surface concrete wins that others can learn from. From Linear Organizations to Hyperadaptive Work "A hyperadaptive organization compresses both of those dimensions." In Hyperadaptive, Melissa contrasts linear organizations with hyperadaptive ones. Linear organizations move through strategy, execution, concept, and delivery with many handoffs and delays. Hyperadaptive organizations compress those delays by organizing around value, distributed decisions, and continuous learning. She points to Tomorrow.io as an example of an AI-native company that could run a much smaller marketing team because workflows were designed differently from the start. She also uses Moderna to show the other side: a large pharmaceutical company using AI to pursue a goal that would be impossible under normal industry timelines. Learning Loops, Communities of Practice, and the Retrospective Backlog "We surface our backlog of improvement items and there they sit." For Scrum Masters, Melissa brings the conversation back to familiar territory: communities of practice, retrospectives, and improvement backlogs. Moderna's AI rollout included ways to identify power users and spread learning through a community. Scrum teams already have the bones of that system, but the weak point is often follow-through. Teams identify improvements, then lose track of them. Melissa's challenge is to use AI to manage those learning loops better: keep improvement items visible, help prioritize them, watch capacity, and make sure learning from retrospectives turns into action. The FOCUS Framework for Choosing AI Use Cases "Is it organizational? Does it fit with your organizational goals or your team goals? Or is it just a random act of AI?" Melissa uses the FOCUS framework to help teams choose high-value AI work instead of chasing every new possibility. Fit asks whether the idea connects to team or organizational goals. Organizational pull asks whether others will use it, or whether it is a one-person tool. Capability checks whether the team can actually build it. Underlying data asks whether the data is good enough. Success metrics ask how the team will know the AI initiative made a difference. This is a natural fit for Scrum Masters because it connects AI adoption to value, capacity, and inspect-and-adapt thinking. The Five Stages of AI Adoption "AI learning is social learning, and we need to harvest the learning from each other and spread it." Melissa outlines five stages of AI adoption. Stage 1 is foundation: named AI leads and AI councils. She warns against assuming the best power users are automatically the best AI leads, because the role needs change-agent skills. Stage 2 is AI augmentation, where teams examine workflows and build support structures such as an AI Activation Hub. Stage 3 is automating end-to-end workflows. Stage 4 is scaling those automations. Stage 5 is interconnected value streams driven by AI and AI telemetry. Stages 3 and 4 are the messy middle, because jobs shift, roles change, and organizations move from functional silos toward value-stream orientation. AI, M-Shaped Skills, and More Complete Teams "I'm hopeful that in the age of AI, with these adjacent competencies, that we can create more complete teams." Vasco and Melissa connect AI-native work with the idea of M-shaped people: people with deep skills in some areas and useful range across others. Melissa notes that AI can unlock adjacent competencies, making it easier for teams to cover skills that used to require fractional specialists. For Scrum Masters, that means the future is less about defending a title and more about understanding durable skills, purpose, and the contribution they can make as team boundaries and role boundaries keep changing. About Melissa Reeve Melissa Reeve is the author of Hyperadaptive: Rewiring the Enterprise to Become AI-Native. She's worked with the Toyota Production System, Agile marketing, and executive leadership at Scaled Agile. She helps organizations move beyond AI pilots by building the human, learning, and operating-model capabilities needed for AI-native work at scale. LinkedIn You can link with Melissa Reeve on LinkedIn and learn more about her work at Hyperadaptive Solutions.

BONUS: Real-Time Research for Change Leaders Using AI AI is changing how Scrum Masters, Agile coaches, and change leaders make sense of organizations. In this BONUS episode, Ari-Pekka Skarp shares how he uses AI as a research assistant, a workspace partner, and a way to bring qualitative research into day-to-day change leadership. From Curiosity to Research Assistant "It felt like having a research assistant." Ari-Pekka's first serious AI use did not start in his full-time change leadership role. It started with side projects, research, psychotherapy-related work, and watching his son build websites with Lovable. That curiosity became practical when Ari-Pekka began using AI to support his PhD research. Instead of spending a full day scanning articles, he could find relevant sources, generate useful summaries, and decide where to go deeper in about half an hour. The key was not that AI replaced his judgment. Because he already knew the research area, he could evaluate the quality of what the AI returned and use it as a complement to his own expertise. AI Expands the Research Surface "With the help of AI, I could actually make a little more of these sidetracks." One of the biggest changes Ari-Pekka noticed was that AI made side paths cheaper to explore. In research and change work, we often ignore interesting but uncertain threads because time and attention are limited. AI gave him a way to examine adjacent ideas without losing the main direction. At the same time, he points out a real risk: AI can guide us toward something too quickly. Sometimes a slower, more intuitive decision is more aligned with the deeper research goal. For Scrum Masters and coaches, that is an important distinction: AI can widen the field of inquiry, but it should not quietly take over the choice of where to look next. Workspaces for Change Leadership "I can create this kind of bird's eye perspective of the organization or the given project quite quickly." Ari-Pekka describes a major shift when he started using Visual Studio Code and AI agents as a workspace for knowledge work, not only for software. In his workspaces, he organizes goals, themes, source material, Jira data, Confluence material, meeting notes, and other organizational signals so that AI can help him analyze and visualize the big picture. This gives him a practical way to represent relationships, dependencies, open threads, and organizational responses to interventions. For change leaders, the point is not the tool itself. The deeper idea is to structure the work so AI can help process the data while the human still owns the interpretation. Bringing Qualitative Research Into Daily Change Work "I try to form a hypothesis of what I find from the data, and then I see whether those hypotheses are correct or not." Ari-Pekka uses his qualitative research background to teach AI how to process organizational data in a consistent way. He is not just asking for a summary. He is thinking like a researcher: what is the question, what data is available, what method should be used, and what output format will make interpretation possible? Vasco connects this to the work Scrum Masters already do: hypothesis thinking, looking for evidence beyond our own biases, and using data to test what is really happening in the system. AI makes it possible to bring those research habits into day-to-day work, instead of reserving them for long academic projects. PDCA With Larger and Messier Data Sets "Now we can just use far more extensive data sets from many different sources and integrate it with the help of AI." Ari-Pekka links AI-supported change work to PDCA: plan, do, check, act. The cycle is familiar, but the available data has changed. Teams and organizations now generate large amounts of textual, conversational, and workflow data across tools like Jira, Teams, Slack, and Confluence. AI can help integrate those sources, but Ari-Pekka warns that organizations are missing an understanding of research methodology. When the same AI tool can produce different answers from the same data, small changes in the research question, method, and prompt matter. Scrum Masters do not need to become full-time researchers, but they do need enough discipline to ask better questions and separate method from interpretation. A Small Experiment: Analyze Power Relations in Meeting Transcripts "With the help of AI, anybody can have a little bit of this kind of experiment in real time." For a practical experiment, Ari-Pekka suggests starting with meeting transcripts, with explicit consent from the people involved. A Scrum Master or Agile coach can ask AI to perform a power-relation or discourse analysis of the conversation and look for patterns in who speaks, who defines the agenda, which ideas are ignored, and how decisions emerge. Organizational psychologists and researchers have studied these dynamics for years, but the work has traditionally been slow and specialized. AI makes it possible to try a lightweight version of that analysis quickly, then use the results as a prompt for reflection, not as a final judgment. About Ari-Pekka Skarp Ari-Pekka is not only a very experience Agile Coach, but he's also a Psychotherapist, and Organizational Psychologist with over 20 years of experience working with organizations. As an author of several books on topics such as Complexity, the mind, and Mindfulness, Ari-Pekka blends deep psychological insight with practical expertise to help leaders and teams navigate the evolving landscape of work. You can link with Ari-Pekka Skarp on LinkedIn. You can read Ari-Pekka's Finnish writing at Mielen laboratorio and his English blog at Fractal Sauna. You can also find Ari-Pekka's previous Scrum Master Toolbox Podcast episodes on his guest page.

BONUS: From AI Curiosity to Practical Project Tools With William Davis AI becomes useful when it moves from generic answers into the daily work of solving real problems. In this BONUS episode, William Davis shares how he started building his own AI-assisted project management tools, what went wrong when the code grew too fast, and how Scrum Masters can use AI more carefully at individual, team, and project levels. When AI Stops Being a Curiosity "I really need to get a handle on how to productively use AI in my job." William's shift started with a familiar problem: release plans are full of uncertainty, but stakeholders still need to understand what might happen and when. Instead of handcrafting uncertain delivery ranges in Excel, William used AI to build a desktop application that created probabilistic Gantt charts. In his work, these were not traditional command-and-control schedules. They were release plans that showed stakeholders a realistic range of possible delivery dates, making uncertainty visible instead of hiding it behind a false promise. The Euphoria and the Crash "Anybody can prompt an app into existence, but if you want an app that is actually enterprise-worthy, it does take a little bit of software engineering knowledge to know what questions to ask." The first experience felt almost magical: ask questions, get code, assemble the pieces, and see a working application appear. But the magic faded when William kept extending the tool and the code started breaking in familiar ways. The AI forgot previous decisions, repeated mistakes, and produced a growing mass of tangled code. The lesson was direct: AI can move fast, but it still needs architecture, tests, and software engineering judgment. Without that, teams can build quickly and still end up with something hard to use, hard to maintain, and hard to trust. AI as a Partner Inside the Tool "The collaboration has a third partner, the AI." William's work expanded from one application to several tools for forecasting, story mapping, release planning, and budgeting. The more interesting change was not only using AI to build tools, but building tools that could connect to AI while people used them. Through Model Context Protocol, William's tools can work with an LLM partner to help teams turn rough product ideas, emails, and scattered artifacts into structured story maps. The team still edits, challenges, moves, splits, and reframes the result. AI helps create a first model faster, but the team keeps responsibility for meaning and decisions. Security Starts With Where the Data Lives "Start with the easy sell: I'm building a tool, and the data that I'm creating is stored locally on your employer-managed device." William is clear that AI adoption in organizations cannot ignore infrastructure and cybersecurity concerns. His first approval path came from designing tools that default to local storage in the browser, on an employer-owned and managed device. That made experimentation easier because sensitive project data did not need to leave the company environment. For teams using MCP or company AI platforms, the same question matters: where is the data going, who governs it, and what agreements protect it from being used for model training? Scrum Masters and software leaders need to treat security as part of the coaching conversation, not as an afterthought. Better Questions, Earlier in the Work "My goal is to solve the problems that I have at the moment that I'm having them." For William, AI changed the work by removing delays between seeing a problem and trying a solution. A release forecast that once took 30 minutes to handcraft can now be updated in a few minutes during the team conversation. In a cloud ERP evaluation, AI allowed him to ask vendor-specific timeline questions much earlier than before. Instead of waiting deep into an RFP process to discover how different solutions would change the implementation plan, he could compare likely timelines upfront and make the trade-offs visible sooner. Go Slow to Go Fast With AI "Ask three different sessions the same question." One of William's strongest warnings is that a single LLM answer can feel more certain than it really is. LLMs are probabilistic, and the same prompt can produce different answers across models or sessions. His workaround is to slow down the design step: ask multiple sessions or models to analyze the same problem, then use an orchestrator session to compare the answers and improve the design. For architecture questions, he may use Claude, ChatGPT, Grok, and Gemini. For smaller product improvements, he uses multiple sessions inside one LLM ecosystem. This is not a return to big upfront design. It is short-cycle research, planning, and implementation, repeated in small increments. A Practical First Step for Scrum Masters "Rather than just read about how to use AI, just start using it." William's practical advice is to choose one real problem and ask your LLM how to approach it. If you are not familiar with MCP, start there: ask your preferred model how to connect to a tool through MCP, and experiment with a low-risk use case. William also invites listeners to try the free tools at SPERT Suite, where the default local mode keeps data on your own device. His broader point is simple: AI becomes useful when it is connected to a specific work problem, a clear feedback loop, and a human who still owns the judgment. About William Davis William Davis is a seasoned IT professional with four decades of experience as a software developer, project manager, and agile advocate. A certified Scrum expert and PMP, he promotes personal and organizational agility, delivers customized training, and mentors agile practitioners. Creator of Statistical PERT® and SPERT® Suite, William innovates with free, AI-powered project management tools for today's agile teams. You can link with William Davis on LinkedIn and explore William's free tools at SPERT Suite.

BONUS: How Scrum Masters Can Use AI Without Losing the Human in the Loop AI makes it easier than ever to build software, prototypes, courses, and coaching tools. In this BONUS episode, Mike Lyons and Greg Pfister share what that speed changes for Scrum Masters, why product judgment becomes more important, and how coaches can start using AI without outsourcing the conversations their teams still need. When AI Stops Being a Curiosity and Starts Saving Real Time "It's not that the work is wrong or not needed, it is needed. That's an important step. Retrospectives are critical." Greg's first practical AI moment came while trying to build an "Ask Mike" capability for self-paced courses. After a frustrating outsourcing attempt, he started using ChatGPT to help him rebuild the tool himself, eventually moving into Cursor, Claude Code, and the Superpowers plugin for Claude Code. Mike's moment was less technical: using AI inside Mural to affinity-map retrospective notes. The lesson for Scrum Masters is not that AI removes the work, but that it can remove enough friction to let facilitators spend more time on judgment, listening, and follow-through. The Bottleneck Moves From Building Fast to Building the Right Thing "The cost to produce prototypes for software engineering is approaching zero." Mike and Greg argue that AI does not create the "wrong feature" problem, but it makes the problem much easier to multiply. If a prototype can appear before lunch, the old excuses disappear. Teams still need to ask whether the customer problem is real, whether the payoff matters, whether there is proof from users or data, and whether this work deserves priority now. For Scrum Masters and Agile coaches, this is a clear invitation to help Product Owners slow down the decision before accelerating the delivery. Building AskMe With AI as the Engineering Partner "I'm really playing product manager. That's really what I'm doing." Greg describes AskMe as an AI-enabled coaching tool embedded into training courses. Instead of asking learners to pass obvious multiple-choice quizzes, AskMe asks them to apply what they learned to their own context, then reflects back practical coaching based on the course material, instructor context, and learner profile. In their own product development, Greg uses AI as an engineering partner while Mike keeps asking the product question: should we build it? Their 4P lens is simple: problem, payoff, proof, and priority. The Scrum Master Role Becomes More Important, Not Less "Don't just outsource your brain, your decision making power." When leaders push teams to "adopt AI," Mike warns Scrum Masters not to let the tool become the decision maker. AI can cluster retrospective notes, summarize long threads, propose learning plans, or help prepare for a hard conversation, but the human still needs to inspect the output and understand the consequences. Greg adds the practical security angle: teams must be careful about what they paste into AI systems, especially personal, customer, or sensitive company information. Start Small: Context, Role Play, and Shared Learning "Context is king when you're talking with your AI." Greg suggests starting with basic AI training, then practicing with small workflow improvements: prioritizing work, summarizing material, or drafting communication that the Scrum Master then edits. Mike's practical starter experiment is role play: describe a difficult team situation without names, ask the AI to act as the other person, and practice the one-on-one conversation. Vasco adds a simple working habit: keep a running context file with meeting notes, team insights, worries, decisions, and open questions, then use that context when asking AI for help. Resources for Scrum Masters Learning AI "Let AI help you get smart about AI." Mike recommends the PMI AI in Project Management learning resources and the 37signals Rework podcast for pragmatic thinking about how AI fits into work. Greg recommends learning directly from the AI tool providers, exploring how to configure projects and context, and reading Marty Cagan's Inspired to strengthen the product judgment that becomes more important when teams can build faster. About Mike Lyons and Greg Pfister Mike Lyons and Greg Pfister are the team behind KaiRise, where they've used AI to build new products, including AskMe, an AI coaching tool, and to create their most recent certified Product Management training course end-to-end. Greg Pfister works with Mike at KaiRise on AI-enabled learning products, including AskMe and their certified Product Management training course. You can link with Mike Lyons and Greg Pfister on LinkedIn. You can find KaiRise and AskMe at kairise.com.

BONUS: The Hidden Dangers of AI at Work With Ari-Pekka Skarp AI is usually sold as a productivity tool, but Ari-Pekka Skarp argues that the real story is what it does to the conversations, skills, and purpose that hold teams together. In this BONUS episode, Ari-Pekka explores why organizations are rushing to use AI "as efficiently as possible" without defining what efficiency means, and what that rush is quietly costing us. Organizations Are Conversations "The organizations are actually conversations, conversational patterns between people." Ari-Pekka's path from software engineering in 1999 to psychology, psychotherapy, and change leadership was driven by one thread: how the mind works, both individually and socially. Meeting Ralph Stacey, Esko Kilpi, and Douglas Griffin at Nokia changed how he saw organizations. Instead of a machine made of parts, an organization is a living pattern of conversations — people responding to each other's gestures, again and again. George Mead added the idea that the human mind itself is not individual but relational. This matters for AI because a large language model is a new kind of player in those conversations, not just a tool that moves data between them. The Efficiency Fetish "It's like how much people are pressing the acceleration pedal in the car. It doesn't tell anything where the car is going." Many organizations are trying to use AI "as efficiently as possible," but Ari-Pekka points out that few have defined what efficiency means. What he sees instead is measurement of AI usage itself — how many people are prompting, how many tokens are flowing. He calls this tokenmaxxing. The car metaphor is the key: pressing the accelerator harder says nothing about direction, and going fast in the wrong direction is more costly than going slow. Efficiency only has meaning against a purpose, and purpose is itself a conversational achievement — something a team has to talk its way into. De-Skilling Is the Hidden Cost "If there's nobody in the room who could review what AI has produced and say whether it's correct or not, it's not an AI strategy. It's a liability." The risk Ari-Pekka worries about most is de-skilling. When we offload cognitive work to AI, we lose the friction that builds learning. There is neurological evidence that people who rely heavily on AI do not develop the same brain structures as those who work through challenges manually. Some skills are fine to lose — nobody needs machine code anymore — but the ability to review and judge AI output is critical, and it is exactly what erodes when we skip the slow work. The result is a double bind: senior experts burn out under the review burden of fast-produced AI output, while juniors never get the time to build the expertise they would need to review it. We Need Speed Limits for AI "We can't optimize individual going as fast as possible... we need a collective... boundaries for individuals." Ari-Pekka reaches for a historical analogy. Our biological rate of processing information is roughly ten bits per second, and it is not going to change. When we only had horses, we did not need speed limits. When we built cars that could go 200 kilometers per hour, we had to invent rules and boundaries to protect the system. AI is the same: we have reached a threshold where optimizing individual output — more code, more stories, more messages — can damage the whole organization. The control mechanism Ari-Pekka proposes is cognitive friction, deliberately added back into the system so that speed serves the system rather than breaking it. The Tokenization of Work "It's very easy to lose the purpose where you are going if you are only doing fragments of work." Ari-Pekka's article The Tokenization of Work describes what happens when the unit of work is no longer a job, a profession, or even a task. Digital tools make it easy to fragment work into tiny pieces and spread them across AI agents, and in the process the boundaries that gave work its meaning vanish. Purpose is what protects us from burnout: with a clear purpose, people can do very demanding work without burning out, because the work feeds them. Without purpose, exhaustion arrives fast. For Scrum Masters, this means grounding the work in why it matters is more important now, not less. AI Is an Echo Chamber, Not a Mirror "The AI is more kind of an echo chamber in a sense that it doesn't push back so much." Ari-Pekka compares AI to George Mead's "generalized other" — the internalized sense of how others see us. AI can play that role, but with a dangerous twist: it is programmed to be agreeable, so it behaves more like an echo chamber than a mirror. Real people push back, point out mistakes, and keep disagreeing. That friction is where learning, competence, and self-awareness grow. Ari-Pekka's practical move is to prompt AI for three different and conflicting perspectives rather than one, using it to go wider rather than only faster. It is not a perfect fix — the model still tries to merge them into one — but it is better than a single agreeable answer. A Three-Second Pause "Take a three-second pause... and just ask yourself, what are you doing?" Ari-Pekka leaves listeners with a small challenge. A few times a day, when you are about to prompt an AI, pause for three seconds and ask what you are actually doing: are you seeking information, or seeking confirmation? Then consider whether it would be better to call a person and have a real conversation. It is a tiny practice, but it points at the whole episode's message: AI is not neutral infrastructure. It changes the conversations, the skills, and the purpose of work, and the people who notice that — Scrum Masters and Agile coaches especially — are the ones who can keep it from quietly reshaping their teams. About Ari-Pekka Skarp Ari-Pekka Skarp is a psychologist, psychotherapist, Lead Change Coach, organizational psychologist, and author. He wrote Mindfulness, mielenselkeys ja myötätunto, hosts Mielen laboratorio, and researches nondualism. His work connects psychology, complexity, Agile, and AI at work. You can link with Ari-Pekka Skarp on LinkedIn. You can read Ari-Pekka's Finnish writing at tietoisuustaidot.com and his English blog at Fractal Sauna. You can also find Ari-Pekka's previous Scrum Master Toolbox Podcast episodes on his guest page.

Deborah Colombari: Product Owners Who Protect Focus and Enable Ownership In this episode, we refer to INVEST criteria and Behavior Driven Development. The Great Product Owner: Clear Outcomes, Strong Refinement, and Space for the Team 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. "He doesn't say how. That allows the team to own the solution." - Deborah Colombari Deborah describes a great Product Owner who came from project management, but learned to work deeply with upstream discovery and refinement. This PO uses INVEST criteria, Behavior Driven Development-style acceptance criteria, and explicit policies so that developers understand what needs to be done and why. He writes down expected outcomes at the epic and feature level, not only at the story level. Because he does not have a developer background, he depends on the tech lead, and Deborah sees that as a strength when the collaboration works. The PO brings business outcomes and clarity. The team brings technical options and owns the solution. That split creates room for trust. Self-reflection Question: Does your Product Owner make the outcome clear while still leaving the solution to the team? The Bad Product Owner: Adding Work Without Understanding the Consequences 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. "He was doing whatever he wanted without thinking of the consequences." - Deborah Colombari Deborah's Product Owner anti-pattern is a cross-team PO who accepted incoming requests and simply added them to the Sprint. There was no clear requirement discussion, no Definition of Done check, no Definition of Ready conversation, and no technical refinement with someone who could expose complexity. The PO treated every request as urgent, even when it was not, and told developers to stop their current work to pick up the new item. The result was more parallel work, broken Sprint Goals, less predictability, and a destabilized team system. Deborah eventually had to step partly into the Product Owner space to limit WIP and protect delivery. The lesson is blunt: Product Owners who ignore consequences turn priority into chaos. Self-reflection Question: What is the cost of every "small urgent request" your team accepts mid-Sprint? [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 Deborah Colombari Deborah is an Enterprise Agile Coach with a decade of experience championing Agile principles across organizations. Passionate about collaboration and continuous improvement, Deborah genuinely loves what she does—empowering others to work smarter, deliver value, and thrive in dynamic environments. You can link with Deborah Colombari on LinkedIn.

Deborah Colombari: Stable Agile Teams Make Delivery Predictable 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 I have a stable team, I have reliable data." - Deborah Colombari For Deborah, success as a Scrum Master comes down to one word: stability. A stable team communicates better, shares knowledge, avoids hero-driven delivery, and becomes predictable enough that the Scrum Master can use historical data instead of wishful thinking. Deborah connects stability with flow metrics and statistical thinking. When an expedite request appears, a stable team can look at its own history and forecast with a useful level of confidence. An unstable team, by contrast, creates silos, overloads key people, and turns every new request into a crisis. Vasco connects Deborah's answer to systems thinking and statistical process control: the team is part of a wider system, and its delivery capability reflects that system. The point is not to force the team to commit beyond what the system can support. The point is to observe the system, improve it, and use real data to forecast what is likely to happen. Self-reflection Question: Do you know your team's delivery capability from evidence, or are you still depending on optimistic commitments? Featured Retrospective Format for the Week: The 4Ls Retrospective Deborah recommends the 4Ls retrospective: liked, learned, lacked, and longed for. She adds one practical extension: an action-items column. Deborah likes the 4Ls because the quadrants help the team see the same issue from different angles. Something the team longed for may connect to something they learned. Something they liked may expose what was previously missing. The action-items column matters because complaint is easy, but turning a complaint into a concrete experiment is harder. Deborah uses those actions to create or update team agreements, making the retrospective outcome last beyond the meeting. [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 Deborah Colombari Deborah is an Enterprise Agile Coach with a decade of experience championing Agile principles across organizations. Passionate about collaboration and continuous improvement, Deborah genuinely loves what she does—empowering others to work smarter, deliver value, and thrive in dynamic environments. You can link with Deborah Colombari on LinkedIn.

Deborah Colombari: Coordinating Global Agile Teams Around One MVP 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 scope is clear. How we are going to deliver it is not clear." - Deborah Colombari Deborah brings a live challenge from a new global project. Her team carries the deadline, but three other teams must contribute, and those teams do not share the same priority or urgency. The question becomes: how do you align teams when only one of them feels the pressure? Deborah has already tried management alignment meetings, but they have not worked as well as needed. Her next experiment is a one-week workshop inspired by Lean Inception, where managers and teams can write down what is needed, when it is needed, and what each team can realistically contribute. Vasco and Deborah explore three practical moves: define the MVP as a real vertical slice, ask whether a person from each dependent team can join for a Sprint or a few days per week, and reduce dependencies by moving ownership closer to the team that holds the deadline. The coaching conversation ends with a useful image: even vertical slices contain thinner vertical slices. When the deadline is fixed, scope must become flexible. In this episode, we refer to Lean Inception and Minimum Viable Product. Self-reflection Question: When your team depends on others, are you managing the dependency or trying to reduce it? [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 Deborah Colombari Deborah is an Enterprise Agile Coach with a decade of experience championing Agile principles across organizations. Passionate about collaboration and continuous improvement, Deborah genuinely loves what she does—empowering others to work smarter, deliver value, and thrive in dynamic environments. You can link with Deborah Colombari on LinkedIn.

Deborah Colombari: The Agile Team Destroyed by a Toxic Feedback Loop 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. "Whenever we almost started to achieve norming, we went back to storming." - Deborah Colombari Deborah shares the story of a team of about twelve developers and QA specialists that kept losing people one by one. The early signal was not a technical problem. It was turnover. A toxic direct leader created pressure, blame, and snarky responses whenever the team tried to explain what was happening. Because that leader's own manager behaved the same way, Deborah saw a reinforced pattern rather than an isolated personality problem. The team could not stabilize. Every time it moved toward norming, someone left or someone new arrived, sending the team back into storming. Knowledge walked out the door with the people who left, delivery dates slipped, morale dropped, and a fixed-date call center project was eventually canceled. Deborah's story is a sharp systems thinking reminder for Scrum Masters: sometimes the problem is not inside the team. The team may be showing the symptoms of a system that punishes honesty, overloads people, and teaches them that leaving is safer than speaking. In this segment, we talk about Russell Ackoff, his systems thinking interview with Haynes Media Works, and the Tuckman model. Self-reflection Question: What turnover or morale signals are you treating as team problems when they may be system problems? Featured Book of the Week: Russell Ackoff Interview by Haynes Media Works Instead of a book, Deborah recommends an old Russell Ackoff interview from Haynes Media Works. She connects Ackoff's thinking to Donella Meadows and to the practical work of Scrum Masters. Deborah highlights how Ackoff explains that the outcome a system is designed to produce affects how the whole system behaves. Her example is health care: if the system rewards treating sickness, it becomes a disease-care system instead of a health system. For Scrum Masters, the lesson is direct. Teams are systems, companies are systems, and the incentives around them shape what they do. Deborah uses Ackoff's work to remind us to look at feedback loops before assuming people are the problem. [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 Deborah Colombari Deborah is an Enterprise Agile Coach with a decade of experience championing Agile principles across organizations. Passionate about collaboration and continuous improvement, Deborah genuinely loves what she does—empowering others to work smarter, deliver value, and thrive in dynamic environments. You can link with Deborah Colombari on LinkedIn.

Deborah Colombari: When Agile Principles Became a Fight With 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 was trying to go against the system, but you cannot go against the system." - Deborah Colombari Deborah Colombari's Scrum Master journey started with a sense that Agile gave her permission to work differently. After early project management work, a year in Canada exposed her to Agile, and the Scrum Master role soon "felt like a glove." But her failure story starts when a supportive leader left and a more command-driven manager arrived. Deborah pushed back hard, trying to protect the Agile practices she believed were right: dailies, burn-down and burn-up charts, transparency, and team focus. The problem was that she was fighting the manager instead of first understanding the system around him. That conflict spilled into the team and damaged morale. Looking back, Deborah says she would now sit down with the manager first, understand the goals and pressures behind the change, and look for compromise before escalating into resistance. Her key learning was pragmatic: Scrum Masters need principles, but they also need diplomacy. The work is not only helping the team inside the Agile bubble, but also translating between that bubble and the wider organization. In this episode, we refer to ITIL, the Dunning-Kruger effect, and Thinking in Systems by Donella Meadows. Self-reflection Question: Where are you fighting the system before you have understood the pressure it is trying to respond to? [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 Deborah Colombari Deborah is an Enterprise Agile Coach with a decade of experience championing Agile principles across organizations. Passionate about collaboration and continuous improvement, Deborah genuinely loves what she does—empowering others to work smarter, deliver value, and thrive in dynamic environments. You can link with Deborah Colombari on LinkedIn.

Sheik Meeajaun: Product Owners Need the Justified No to Protect Customer Value In this episode, we refer to Vasco's Product Owner episodes, where Product Owners share their own lessons from the role. The Great Product Owner: Owning the Product and Practicing the Justified No 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. "No, you cannot have this, but this is why." - Sheik Meeajaun Sheik's model for a great Product Owner came from a mentor he worked with early in his career. That PO owned his slice of the product, delivered consistently, and taught Sheik the power of the "justified no." A strong PO does not simply reject stakeholder requests. They explain the trade-off, ask what should be removed from the sprint, and make business value visible. If a stakeholder wants urgent work, the PO can ask them to get agreement from the person whose work would be displaced. That shifts the conversation from pressure to prioritization. For Sheik, great Product Owners understand that their job is to bring value to the business and delight customers. They care deeply enough about the product to protect it from random requests, HiPPO decisions, and backlog noise. They know success is not only delivery. It is the visible appreciation that comes when people recognize a product decision created real value. Self-reflection Question: Does your Product Owner have a practical way to say no that protects value without turning every request into conflict? The Bad Product Owner: The Executor Who Cannot Say No 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. "A Product Owner's primary job is to bring value." - Sheik Meeajaun The anti-pattern Sheik warns about is the Product Owner as executor. This PO does not own the product, does not know the customers deeply enough, and does not push back when leadership changes direction. They become a project manager with a backlog, accepting whatever the highest-paid person in the room asks for next. The team then loses coherence, the product loses a clear direction, and the Scrum Master is left helping the team manage the consequences of weak ownership. Sheik is careful not to blame only the individual. Many POs are placed in the role without mentoring, without a clear understanding of product ownership, and without the organizational support to say no. The result is predictable: a mountain of requests, no clear value conversation, and a team delivering work without a strong product story behind it. Self-reflection Question: Where is your Product Owner being treated as an order taker instead of the person accountable for product value? [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 Sheik Meeajaun Sheik is a seasoned product and Agile leader with over 20 years of experience scaling innovative, customer-centric digital solutions. A certified Scrum and Agile expert, he bridges strategy and execution, driving high-performance teams at enterprises like Rabobank and citizenM. As a hands-on builder, Sheik created Scrumling—a free, interactive Agile training platform—and ScrumJobs.net, a niche job board for Agile professionals. His passion lies in transforming theory into impactful, real-world results. You can link with Sheik Meeajaun on LinkedIn. You can also explore Scrumling, ScrumJobs.net, and Simatech.

Sheik Meeajaun: Scrum Master Success Starts With Trust and Ends With Teams Delivering 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 try to build trust before I build anything else." - Sheik Meeajaun For Sheik, Scrum Master success is simple to describe and hard to earn: the team delivers what it committed to, demos happen, customers are impressed, and the Scrum Master has protected the team from avoidable disruption. He sees himself as a shield, pushing back when stakeholders bypass the team or when a Product Owner wants to interrupt the sprint without acknowledging the cost. But when he joins a new team, Sheik does not start with burndown charts or velocity. He starts with one-on-one conversations. He tells people his job is to make their work easier, then asks what help they need. Those conversations reveal the real blockers that charts often hide. Trust comes first because teams deliver through people, not dashboards. When people know each other, help each other, and pick up work when someone is away, they become more than a collection of roles. They become a team with a shared future. Self-reflection Question: What do your first conversations with a new team tell people about the kind of Scrum Master you intend to be? Featured Retrospective Format for the Week: Three Words to Sum Up the Sprint Sheik starts retrospectives by asking each person for three words that sum up the sprint. The words can be simple: productive, boring, repetitive. The value comes from asking people to explain what sits behind those words. Instead of stopping at "I could not finish my story," Sheik wants the team to walk back through what happened: who was unavailable, what help was missing, where the Product Owner did not clarify, and which impediment stayed hidden too long. For him, a good retrospective creates a safe place to talk honestly about the details before the failure. The format is intentionally plain. The goal is not novelty. The goal is a conversation that finds the friction early enough for the team to do something about it. [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 Sheik Meeajaun Sheik is a seasoned product and Agile leader with over 20 years of experience scaling innovative, customer-centric digital solutions. A certified Scrum and Agile expert, he bridges strategy and execution, driving high-performance teams at enterprises like Rabobank and citizenM. As a hands-on builder, Sheik created Scrumling—a free, interactive Agile training platform—and ScrumJobs.net, a niche job board for Agile professionals. His passion lies in transforming theory into impactful, real-world results. You can link with Sheik Meeajaun on LinkedIn. You can also explore Scrumling, ScrumJobs.net, and Simatech.

Sheik Meeajaun: Scrum Masters Must Learn by Experimenting When AI Joins the Agile Team 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. "Never be afraid to admit you don't know something." - Sheik Meeajaun Sheik brings a current challenge that goes beyond one team: the gap between Scrum theory and real work when the context changes faster than the playbook. His example is AI. Scrum Masters are now asked to help teams where AI agents contribute to delivery, but no certification course can fully prepare us for that. Sheik's starting point is humility: say "I don't know," learn the domain, run small experiments, and reflect quickly. In one team, two human developers worked alongside several AI agents. They could not run a normal standup with Claude, so the team created a status report and reviewed it with the human team members. Sheik framed the agents as junior developers: useful, fast, and still requiring clear instructions, review, and guardrails. That framing helped experienced developers see AI collaboration as coaching and oversight, not as magic productivity. The key lesson is practical empiricism: try, inspect, adapt, and keep learning as the work changes. In this episode, we refer to Scrumling's AI Product Owner course and the need to adapt Scrum practice to AI-enabled work. Self-reflection Question: What new reality is your team facing where the honest Scrum Master answer should start with "I don't know yet"? [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 Sheik Meeajaun Sheik is a seasoned product and Agile leader with over 20 years of experience scaling innovative, customer-centric digital solutions. A certified Scrum and Agile expert, he bridges strategy and execution, driving high-performance teams at enterprises like Rabobank and citizenM. As a hands-on builder, Sheik created Scrumling—a free, interactive Agile training platform—and ScrumJobs.net, a niche job board for Agile professionals. His passion lies in transforming theory into impactful, real-world results. You can link with Sheik Meeajaun on LinkedIn. You can also explore Scrumling, ScrumJobs.net, and Simatech.

Sheik Meeajaun: When Spillover Becomes Normal, Scrum Teams Stop Seeing the Cost 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. "A good Scrum Master makes their Product Owner look like a superstar." - Sheik Meeajaun Sheik describes a team pattern many Scrum Masters recognize: spillover had become so normal that finishing the sprint felt like a special event. Refinement was weak, stories were often written during refinement instead of before it, and Product Backlog Items were sometimes little more than one-line titles. The Product Owner was not consistently engaged, standups had become update sessions for the PO, and nobody was connecting non-delivery to business impact. Sheik brought his Product Owner background into the Scrum Master role and started asking a more pragmatic question: what is the cost per sprint when we do not deliver? By making cost of delay visible, he helped the team see that spillover was not just a process issue. It was lost value. The experiments were practical: protect focus, prepare stories before refinement, and tackle the gaps at ground level instead of pretending the organization would fix everything first. Self-reflection Question: What does your team treat as normal today that is quietly costing the product money every sprint? Featured Book of the Week: The Scrum Guide by Ken Schwaber and Jeff Sutherland Sheik does not pretend to have a long reading list. He says experience shaped him more than any single book, because contracting exposed him to many organizations and many versions of Scrum in practice. Still, he points listeners back to The Scrum Guide as the minimum reference every Scrum Master should know. For Sheik, the guide gives the vocabulary and foundation, but experience teaches the translation work: how those ideas survive contact with real teams, weak refinement, Product Owners who are stretched thin, and organizations that say "Agile" while still behaving like escalation machines. [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 Sheik Meeajaun Sheik is a seasoned product and Agile leader with over 20 years of experience scaling innovative, customer-centric digital solutions. A certified Scrum and Agile expert, he bridges strategy and execution, driving high-performance teams at enterprises like Rabobank and citizenM. As a hands-on builder, Sheik created Scrumling—a free, interactive Agile training platform—and ScrumJobs.net, a niche job board for Agile professionals. His passion lies in transforming theory into impactful, real-world results. You can link with Sheik Meeajaun on LinkedIn. You can also explore Scrumling, ScrumJobs.net, and Simatech.

Sheik Meeajaun: The Scrum Master Who Let Standups Stay Silent Until the Team Took Ownership Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "You can't fix something until it breaks." - Sheik Meeajaun Sheik Meeajaun joins us from Bulgaria with a failure story about silence, escalation, and the uncomfortable work of helping a team own its own communication. He stepped into a hybrid team where the previous Scrum Master had led the Daily Scrum like a status meeting. When Sheik stopped driving the conversation, the team simply stopped speaking. For two weeks, the standups were painfully quiet. The Product Owner tried to take over, managers escalated complaints, and Sheik had to explain that the silence was exposing the real problem: the team had learned to wait for someone else to lead. The breakthrough came when one quiet team member finally spoke up and said what she was working on. Sheik asked her to pass the conversation to the next person, and the team slowly built the habit of talking to each other. His lesson is clear: sometimes the Scrum Master must resist rescuing the team long enough for the team to see what needs to change. Self-reflection Question: Where are you stepping in so quickly that your team never has to build the muscle of ownership? [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 Sheik Meeajaun Sheik is a seasoned product and Agile leader with over 20 years of experience scaling innovative, customer-centric digital solutions. A certified Scrum and Agile expert, he bridges strategy and execution, driving high-performance teams at enterprises like Rabobank and citizenM. As a hands-on builder, Sheik created Scrumling—a free, interactive Agile training platform—and ScrumJobs.net, a niche job board for Agile professionals. His passion lies in transforming theory into impactful, real-world results. You can link with Sheik Meeajaun on LinkedIn. You can also explore Scrumling, ScrumJobs.net, and Simatech.

BONUS: Why Software Projects Fail When Everyone Keeps Quiet Software projects rarely fail because no one noticed the problem. More often, people see the missing database, the wrong assumptions, the broken process, or the weak product ownership, but the organization has trained them to stay quiet. In this BONUS episode, Mark Stringer, author of Delivering the Impossible, helps us understand how Scrum Masters can make reality visible again. The Problem Of Intention In Software Projects "You've got here a problem of intention, and you can't fix that by coming up with new, more magical marks on the page." Mark starts with a story from the mid-1990s, before Agile was a common word in software teams. In a software development course, he heard the familiar promise: if only requirements could be captured with the right notation, the project would go correctly. His reaction was different. Software is not only a problem of documentation or process, it is a problem of translating intent into reality. That gap between marks on a page and what people actually need is where many projects begin to drift. Point Of View Can Make Smart People Miss Reality "If we see things in the wrong way, then point of view can take 80 IQ points off us." Mark uses Alan Kay's idea that point of view is worth 80 IQ points to explain why good people can still make poor project decisions. A methodology can help, but only if it helps the team see what is actually happening. When the model becomes more important than reality, teams start defending the plan instead of learning from the system they are trying to change. Scrum Masters can help by asking what the current point of view hides, not only what it explains. The Swamp: Why Project Complexity Is Not On The Diagram "The fastest way between two points in a real organization is not necessarily a straight line." In one banking project, Mark found two realities that had not survived the diagrams. First, a transaction database shown on every architecture diagram did not exist. Second, after six months of requirements work and several million pounds spent, a simple show and tell revealed that the design was organized around accounts when stakeholders needed it organized around people. The point was not that the team had failed to write enough requirements. The point was that the real environment was a swamp of legacy systems, power shifts, competing groups, regulations, users, and assumptions. You only discover that swamp by starting, showing real work, and letting stakeholders react. Agreed Activity: When The Rituals Keep Going But The Project Is Already Lost "Everybody knows why the project's failing. It's not a mystery at all." Mark calls one common failure mode "agreed activity." The team keeps attending standups, planning meetings, status reviews, and retrospectives, even when people privately know the project is not going anywhere. Often they have tried to raise the real issue before and were punished for it. After that, silence becomes rational. The organization keeps reporting activity, expenditure, and compliance with the process, while the real blockers stay untouched. For Scrum Masters, this is a warning: ceremonies are useful only when they let reality enter the conversation. Product Ownership, Bad News, And The Message Leaders Send "The message that the development team hears is: don't rock the boat, just keep taking the money." The Product Owner role can help break agreed activity, but only if the person has enough authority to make decisions and enough proximity to the team to learn. Mark describes two common anti-patterns: appointing someone junior who can be pushed around, or appointing someone so senior they have no time for the work. Worse, when someone points out a fundamental problem and gets metaphorically shot, the team learns the real rule: stay quiet. Leaders may think they are asking for positivity or commitment, but the team hears permission to cut corners, hide bad news, and treat spending as progress. Make Scrum A Hypothesis Testing Framework Again "That kind of unexpected feedback, that's the hope. That's the machine working." Mark's practical advice is to keep the cadence, but make the meetings real. A show and tell should expose assumptions. A retrospective should make uncomfortable feedback usable. Scrum works best when it is treated as an empirical, hypothesis-testing framework, not a list of meetings to implement. Mark also points to user research as a way to extend learning back into the environment. Teams cannot guess how users will react, which buttons they will press, what they will ignore, or what market and organizational changes are shaping the work. They have to test, learn, and adjust. About Mark Stringer Mark Stringer is the author of Delivering the Impossible, a 2026 Apress book on better ways of seeing software project management. He has spent 30 years in software delivery as a developer, application researcher, and project manager, working with IBM, Xerox, and Cambridge University. You can link with Mark Stringer on LinkedIn and follow Mark's writing at markstringer.github.io. You can find Delivering the Impossible on Amazon and Springer.

BONUS: When the Team Becomes the Operating System for AI — Marko Taipale on the Twin Project at Solita Most teams trying to "use AI" end up with fast individuals and a slower system. Marko Taipale ran a two-year experiment at Solita that suggests the real bottleneck isn't the tool — it's the team's operating model. In this conversation, Vasco and Marko walk through the Twin Project with ISS Finland — two teams, same ERP pricing tool, one classical agile, one with generative AI in the room — and the lessons that became the CollabAI framework. The Twin Project — Two Teams, Same Product, One With AI in the Room "We had a luxury of: do whatever you want with AI, please get at least the same results, towards the same goal." In 2024, Marko's team at Solita was set up as the counterpart to an existing Scrum team building an ERP pricing tool for ISS Finland. Same product mission, two different operating models. The first days were chaotic and exploratory — the team tried over 120 AI tools, built a custom GPT to act as a stand-in product owner, and even sent a virtual assistant to sit silently in the other team's meetings so nobody from Marko's team had to attend. The framework grew out of what kept working, not from a plan written upfront. "Fast Individuals, Slow System" — Why Buying Licenses Doesn't Fix the Bottleneck "If you don't change your structures, AI won't do anything faster. The only thing that gets faster is the queues between your decision-making gates." The line from Marko's book lands hard once you have seen it inside a team. A Copilot license speeds up the individual — and then the individual sits and waits for the rest of the system: reviews, handoffs, refinement, stakeholder meetings. Those queues are exactly what AI accelerates, and the team feels even more frustrated than before. The real intervention is upstream, in how the team shares context and makes decisions together. Without that, AI just makes the existing inefficiency more obvious. Drifting in the Solution Space — Why Sense-Making Has to Happen Together "None of the real problems are so simple that a single person can solve them. If it's that simple, you should automate it." The early Twin Project team kept seeing what Marko calls drifting — small interpretive mistakes at the start of a task that twisted the solution into something unrecognisable later. Each person was reading the same docs and the same proxy-PO conversations, and each was leaving with a slightly different picture. Individual interpretation was not enough. They moved from individuals to pairs, then to whole-team sense-making sessions. The shared context only became useful when the team processed it together — and that processing turned out to be where the learning compounded. Never Leave the Daily — When Mob Programming Becomes the Operating System "This is happening so fast, we shouldn't actually leave the daily." The team started with vanilla Scrum, extended dailies, then ran multiple per day, then realised that the meeting was the work. They drifted into mob programming without naming it — a shared virtual machine where one person controlled the screen at a time, switching every few minutes. The agile labels came later, when someone read Mob Programming by Woody Zuill (see his earlier episodes on the Scrum Master Toolbox Podcast) and saw the team's own behaviour reflected back. The takeaway: when the pace of decisions exceeds the cadence of meetings, the team has to live inside the conversation, not visit it once a day. The 40-Prototypes Moment — When the Customer Joined the Mob "You waited 37 hours to get to this point where we get feedback." This was the turning point. Marko had built 40 different prototypes of the pricing tool in one hour, then walked into a weekly review where the customer pointed out the obvious: if the prototypes took one hour to make, the team had been waiting 37 hours to get the feedback that actually mattered. From that moment the client became part of the mob. New product directions started landing every five to seven minutes. The backlog quietly disappeared — issue management stayed, but for the AI's context, not for humans. When the product owner is in the room all day, the storage-and-handover layer stops earning its keep. The Regulation Layer — Why Sustainable Pace Gets Sharper, Not Softer, With AI "AI is a machine. It won't stop. That's why we need a regulation layer — and we have to regulate together, not individually." What broke first in the Twin Project was not the technology — it was the people. Cognitive load and the brain's hunger for clarity become the new constraint once decisions are flying every few minutes. The old Scrum idea of sustainable pace gets a second life here, but it has to be a shared pace, set by the team, not an individual one. Engagement is the early warning signal — when people start disengaging, the system is already over its capacity. For Scrum Masters and coaches, this is where the work moves: watching the team's energy curve, not just its throughput. The Agentic Horizon — From Teammates to Agents Acting on the Team's Behalf "AI is a new player in this field. The next conversation is governance — and it has to start now." CollabAI was about humans and AI on one screen. The next move — what Marko is now building at Agion — is agents acting on the team's behalf. The governance shape is not optional, and it is the conversation Scrum Masters and coaches need to start having before agentic systems are everywhere on the team. Marko's article series on Agion (the brain fry posts) is the public record of what they are learning as they build the governance layer for autonomous agents. About Marko Taipale Marko Taipale is the author of CollabAI: AI Teamwork In Practice (foreword by Joe Justice) and currently works at Agion Inc. At Solita, he co-led the Twin Project with ISS — two teams building the same ERP pricing tool, one with classical agile, one with generative AI embedded end-to-end — and turned what they learned into a framework for teams that want AI as a synchronous teammate, not a faster individual tool. CollabAI book · Leanpub · LinkedIn You can link with Marko Taipale on LinkedIn.

BONUS: How Scrum Masters Turn AI Into a Thinking Partner, Not a Magic Answer Box Everybody talks about AI in theory. In this BONUS episode, Dave Westgarth talks about it in practice — the boring, everyday ways a Scrum Master and Agile Coach actually puts AI to work. From t-shirt sizing to sprint reports to a self-coded Monte Carlo forecaster, Dave shares what works, what doesn't, and the one mindset shift that separates people who get value from AI from those who just generate more noise. From "Magic Answer Box" to Personalised Partner "Instead of taking it as a magic answer box, using it as a personalised partner to work through problems, look at your ideas, and really hold them in the cold light of day before proposing things." Dave came into agile from a development background, moved through project delivery, and had already worked at AI and ML companies long before ChatGPT made the technology personal and accessible. Like most people, he first met these tools as a "magic answer box" — ask a question, get an answer, run with it. The real shift came when he stopped optimizing for output and started using AI to drive better outcomes: ping the model, get a response, then interrogate it, refine the thinking, and go around again. The value isn't the first answer. It's the conversation that sharpens your own reasoning. These Tools Aren't Neutral — So Corner Them Into Being a Critic "If you ask it to be punishing, negative, and brutal, it gives you a lot more relevant feedback." One of Dave's sharpest points: AI tools are not neutral guides. Because of their system prompts and the incentives baked in by the providers, they're relentlessly positive — they want to affirm you and keep you around, a little like social media. That makes them weak for anything where you need honest pushback: personas, user stories, feedback on ideas. Dave's fix is to flip it on its head. Rather than asking "is this any good?" (which reliably earns an "8 out of 10, but to make it a 10…"), he tells the model to be as harsh and brutal as it can and really try to punish the idea. You don't want a partner that always agrees with you — you want one that pinpoints the areas you haven't thought about. The First Real Time-Saver: Reports, and the Themes You Missed "Are there any themes that have emerged over the last 4 weeks that I might have missed in this latest deck?" The first thing that stopped feeling like a party trick was the one we all know: project documentation and reporting — sprint reports, status updates, review decks. Instead of letting AI invent the structure, Dave feeds it his own structure plus Teams recordings, notes, and existing docs, and lets it populate the format he already uses. The trick that goes a level deeper: after several sprints, feed all the AI-assisted reports back in and ask what themes have emerged across the last four weeks that this latest deck might have missed. Again, it stops being an answer box and becomes a partner and critic. AI Is Part of the Job Now — Like Spreadsheets Once Were "The way to get ahead now is figure out how to use it as effectively as you can in your role." Dave sees the early resistance movement against AI as a false economy. For delivery professionals — project managers, Scrum Masters, agile coaches — knowing how to use these tools well is fast becoming a core expectation, not a nice-to-have. Vasco draws the parallel to spreadsheets: once dismissed as too complicated and "not my kind of thing," until people started building real forecasting and capacity models with them and the work changed. AI is on the same arc — still a little mystical today, genuinely useful tomorrow, and eventually just another tool in the box. A Week With AI in the Loop "The power that these prompt-to-product tools give you to create these hyper-personalized tools that make you more effective is, in a lot of ways, magic." Dave walked through what his week actually looks like with AI in the loop: Monday primer: a scheduled ChatGPT task emails him a scene-set every Monday — last week's plan and top priorities — so he isn't spending the first half hour reconstructing where things stood. Priority calls: which items are the toughest, where the quick wins are, where he can get early traction, and where risks might be emerging that he can squash early. Everyday comms: drafting the bones of emails, pings, and project updates so he spends almost no time formatting. Prompt-to-product tools: using Base44, Lovable, and Replit to build his own tools — including a Monte Carlo forecaster that takes his team's sprint throughput and projects the remaining backlog, replacing an ugly spreadsheet with a clean web app. He also builds AI-powered widgets in Miro for retrospectives, mood check-ins, and planning poker. The theme running through all of it: hyper-personalized tooling, shaped by your team and your own skills, rather than one-size-fits-all software. The Myth That AI Makes Scrum Masters Worse "I can't see any role of a knowledge worker where having an LLM at your disposal makes you less capable, less knowledgeable, less skilled than someone that doesn't." Dave sees the same adoption spectrum among developers and Scrum Masters — from "I'll never touch it" to "I'll never write code by hand again." And he pushes back hard on an emerging prejudice that echoes the old "technical Scrum Masters are worse" debate: the idea that Scrum Masters who use AI are somehow weaker. Used well, AI lets you elevate your strengths and cover your gaps — a people-centered Scrum Master can become far more technical, and a technical one far more people-centered, each with a trusted teaching guide right there. The key competency isn't avoidance; it's discernment about when to reach for the tool and when not to. From More Output to Better Outcomes "The bottleneck has never really been typing code. The bottleneck has been understanding the problems and the customers well enough to define a solution that fixes them." Dave's clearest reframe: AI is driving the price of output down. When volume is easy — more features, more emails, more documents on demand — churning out more of it stops being a differentiator, because everyone can do it. What matters is deciding which problems are worth solving and finding the most effective solution. Experienced agile professionals have always known the real bottleneck was understanding the customer well enough to define the right solution, not the typing. AI just exposes that in a much starker way: there's nowhere left to hide behind sheer volume. What to Pay Attention To — and a Monday Experiment "It can do a lot of that manual, low-thinking, high-effort work to free you up to do more of the really impactful stuff." For Scrum Masters being told to "adopt AI," Dave's advice is to let it take the joyless work — the end-of-sprint collateral, the Jira monitoring, the reports and charts — so you can spend your time on the coaching, the strategic thinking, and the organizational-level impact that's harder to reach when you're buried in tactical chores. His concrete Monday-morning experiment: take the two or three prioritized actions from your next retrospective, bring them to ChatGPT or Claude, and ask, "which of these could you really help me with, and how could you help me move the needle?" Start a conversation. You don't have to accept its answers — the point is to sharpen your own thinking about where you can add the most value next sprint. Developing "Taste" With AI "One element of taste is being able to judge it fairly harshly — getting through the beige as quickly as you can to find the little nuggets and gems." Both Dave and Vasco land on the same skill for the year ahead: taste. These tools produce a lot of text, and not all of it is useful. Vasco shares his own aha moment — asking for ideas, getting the obvious ones, then repeating "give me more, don't repeat any" until the model finally surfaced something genuinely unexpected. That simple move turns AI into an engine for exploring the solution space until something clicks. The competency to build is the ability to move through the beige quickly and recognize the gems that materially change what you do next. About Dave Westgarth Dave Westgarth is a product and Agile practitioner exploring how AI transforms product development, experimentation, and team workflows. He shares practical insights on leveraging tools to accelerate value delivery and innovation. You can link with Dave Westgarth on LinkedIn and find him in the Miro community and on Miroverse.

BONUS: How Scrum Masters Can Use AI Without Becoming the Human API AI is already changing the practical, everyday work of Scrum Masters and Agile Coaches. In this BONUS episode, Vasco talks with Fred Deichler about moving from curiosity to real AI-supported workflows: finding team signals faster, preparing better conversations, keeping documentation in sync, and staying focused on outcomes instead of just producing more output. From Automation to an AI Sparring Partner "I have this partner I can work with to help me ideate things." Fred's journey into AI started before the current AI wave, with automation in Jira and the practical need to surface bottlenecks without manually watching every board. The turning point came when ChatGPT stopped feeling like a search box and started acting like a thinking partner. Faced with a team being pushed toward multiple sprint goals, Fred dumped the context into AI and asked for three to five options instead of one "right answer." That shift helped him move from a deterministic mindset into a problem-solving mindset, using AI to explore options, challenge his own assumptions, and prepare a better conversation with the team. The Monday Morning AI Context Builder "It instantly sets that context for me. It sets that tone for the whole week." Fred describes his weekly workflow as a very practical use of AI: on Monday morning, he opens Cursor and works with his own AI harness, Atlas. Atlas is built from markdown files containing persona, skills, history, meeting transcripts, notes, and Jira data. When Fred says "good morning," the system pulls the most relevant signals forward: aging work items, backlog health, sprint goals, and where the next team conversation should focus. Instead of starting the week by hunting for data, Fred starts with questions he can bring into the first stand-up: what is stuck, what needs refinement, and what risk is already visible? Making Flow Metrics Visible Inside Jira "If you're on a page, what do you hope you could learn without asking?" Beyond using AI as a thinking partner, Fred used AI to build a Chrome extension that surfaces useful Jira insights directly where the team already works. On the active sprint board, it shows work in progress, aging items, sprint goals, and sprint changes. In the backlog, it exposes backlog health and epic health. On the sprint report page, it adds cycle time per item so the retrospective can move from generic discussion to concrete learning. The point is not to shame the team with metrics. The point is to make the right conversation easier to start: what caused this item to take seven days, what blocked it, and what do we want to learn from that? AI as Extra Eyes and Ears for Team Conversations "It helps make sure that we don't lose sight of these things I can bring back to the team." Fred also uses AI agents to review meeting transcripts and look for patterns that are easy to miss in the flow of daily work. The system can notice hesitation, unresolved topics, or a requirement problem that was mentioned once and never followed up. For retrospectives, Fred's Atlas setup can review sprint transcripts around day nine of the sprint and suggest themes for the next retro. It can even generate prompts for a visual retrospective board in Copilot or a Miro board from a prompt. This helps Fred avoid relying only on recency bias and creates a better starting point for the conversation the team actually needs. Keep the Human in the Loop, Especially for Outcomes "It's not about building a faster hammer. It's about identifying the outcome you're going for." A major warning in the episode is that AI can make Scrum Masters faster at producing more of the same: more notes, more summaries, more documents, more reports. Fred argues that the useful question is not "can we automate this exact process?" but "what outcome are we trying to achieve?" In a Jira-to-Azure DevOps migration, for example, the goal was not to reproduce the current time-tracking process perfectly. The goal was to provide the information accounting needed. That outcome focus keeps the human accountable for direction, judgment, and value, while AI helps explore better ways to get there. The SPOT Framework for Finding AI Opportunities "If it meets three or four of those, this is a great opportunity for an automation to free me up to do that more human-centric work." Fred uses a simple filter, the SPOT framework, to decide what AI should help with and what should remain human-led. A task is a good candidate when it is simple, predictable, observable, and tedious. Simple means it requires low human judgment and could be explained on an index card. Predictable means it happens repeatedly, either on a schedule or triggered by an event. Observable means the needed data is available to the agent and not locked away in someone's head or behind policy. Tedious means it consumes energy without adding much human value. When a task matches most of those criteria, Fred looks for ways AI can handle the toil while he stays focused on facilitation, coaching, and decision-making. A Small Experiment Scrum Masters Can Try Tomorrow "If a Scrum Master finds himself operating as, like, I'm moving data from point A to point B, that is a great opportunity to say, how might we do this?" Fred's concrete advice is to start by noticing where you have become the "human API": moving data between tools, updating spreadsheets, copying information into reports, or keeping documents manually aligned with reality. Write down one tedious workflow and ask your approved work AI, "How might we automatically populate this, while keeping me in the loop?" Vasco adds a useful ideation tip: if the first five ideas are not good enough, ask for five more without repetition, then five more again. The goal is not to hand over accountability. The goal is to discover what might be possible and choose one safe, small experiment. Resources for Scrum Masters Exploring AI "It's all about building up your own idea of what's possible to start those how-might-we conversations." For listeners who want to keep learning, Fred recommends The AI Daily Brief as a way to stay current with what is happening in AI, and Jack Roberts' YouTube channel for practical ideas around personal AI and agent-based workflows. Fred also points listeners to his own work at Triforce Agility, where he shares blog posts, resources, and updates about his talks. He will be speaking at the Kansas City Developers Conference in early September about AI and career progression, and at Scrum Day in Madison, Wisconsin in October about how AI impacts Scrum Master roles. About Fred Deichler Scrum Master, Agile Coach You can link with Fred Deichler on LinkedIn and connect with Fred Deichler at Triforce Agility.