The most played episodes among Podcast App listeners.

1. 1
   Number 1: BONUS When the Team Becomes the Operating System for AI With Marko Taipale

   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.

   September 03, 2026·39min
   Play
2. 2
   Number 2: Success for Scrum Masters Means Teams Ask Better Questions Without You | Arun Parameswaran

   Arun Parameswaran: Success for Scrum Masters Means Teams Ask Better Questions Without You Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "My goal isn't to become indispensable. My goal is to create a team that doesn't depend on me." - Arun Parameswaran For Arun, Scrum Master success is not measured by how many meetings he runs or how often the team asks him for help. It is measured by the team's ability to solve problems without depending on him. If he has to remind everyone to update Jira, facilitate every difficult conversation, or resolve every obstacle, he is creating dependency. A healthier signal is when team members talk directly to each other: "This is blocked. Who can help me?" or "Let's finish this before starting something else." Arun compares the Scrum Master to a football coach watching the match from the side. The team needs space to play, make decisions, and learn. The Scrum Master still observes and coaches, but the goal is to intervene less often and more intentionally. As Vasco summarizes, this requires learning to wait before stepping in. Self-reflection Question: What would your team do differently if you waited one more minute before intervening? Featured Retrospective Format for the Week: What? So What? Now What? Arun's favorite retrospective format is "What? So What? Now What?" because it moves the team from facts to meaning to action. "What happened?" helps the team describe reality. "So what?" asks why it matters. "Now what?" turns the discussion into a small experiment for the next sprint. Arun also avoids using the same format every time. He often shares the board two or three days before the retrospective so people can reflect before the meeting, add observations, and appreciate teammates. That preparation saves time in the session and makes space for a short fun activity before the team works through the real topics. His goal is simple: every retrospective should produce learning and at least one concrete experiment. [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 Arun Parameswaran Arun is an Agile delivery leader at Bosch Global Software Technologies who builds high-performing, data-driven ecosystems. He blends flow metrics, Jira analytics, Power BI, and applied AI to turn delivery into a transparent, predictable system. You can link with Arun Parameswaran on LinkedIn.

   August 27, 2026·17min
   Play
3. 3
   Number 3: Using Scrumban and WIP Limits to Help Agile Teams Find Focus | Arun Parameswaran

   Arun Parameswaran: Using Scrumban and WIP Limits to Help Agile Teams Find Focus 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 WIP limit helped the developers not context switch." - Arun Parameswaran Arun brought a practical challenge to the Wednesday coaching conversation: a team doing both operations and development work needed more visibility and focus than their Scrum board was giving them. The trigger was context switching. Work stayed "in progress" even when blocked, people picked up new topics before finishing old ones, and stakeholders kept asking what was actually happening. Arun helped the team experiment with Scrumban, keeping useful Scrum events while adding a Kanban-style board and explicit WIP limits. The breakthrough was not just visualizing the work. It was helping the team own the limits. They created an "operator of the week," rotating the responsibility for watching WIP and calling out when the team was taking on too much. That small practice made focus a team responsibility instead of a Scrum Master lecture. Self-reflection Question: Who owns your team's WIP limits in practice, not just on the 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 Arun Parameswaran Arun is an Agile delivery leader at Bosch Global Software Technologies who builds high-performing, data-driven ecosystems. He blends flow metrics, Jira analytics, Power BI, and applied AI to turn delivery into a transparent, predictable system. You can link with Arun Parameswaran on LinkedIn.

   August 26, 2026·14min
   Play
4. 4
   Number 4: How Powerful Questions Help Scrum Teams Handle Stakeholder Conflict | Arun Parameswaran

   Arun Parameswaran: How Powerful Questions Help Scrum Teams Handle Stakeholder Conflict 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. "Sometimes the best thing a Scrum Master can give the team isn't the answer. It's a question." - Arun Parameswaran Arun describes a team pattern many Scrum Masters recognize: stakeholders bypassing the Product Owner and going straight to developers with new requests after the sprint had already started. The developers wanted to help, so they accepted the interruptions. The result was context switching, broken priorities, and a quiet loss of focus. Arun worked with the customer team, Product Owner, and developers to create a simple agreement: new work had to come through the PO, be clarified, and be prioritized before it reached the team. That agreement gave developers permission to protect the sprint without turning every conversation into a personal conflict. Arun also shares how he handled the classic misunderstanding that "being Agile" means accepting every change immediately. For him, adaptability still needs timing, clarity, and shared agreements. In this segment, we talk about the coaching stance and how Scrum Masters can use questions to help teams think together. Self-reflection Question: What agreement would help your team protect focus without shutting stakeholders out? Featured Book of the Week: Coaching Agile Teams by Lyssa Adkins Arun recommends Coaching Agile Teams by Lyssa Adkins because it helped him move beyond ceremony facilitation. The book gave him a clearer picture of the Scrum Master as a coach for individuals, the team, and the wider organization. One question stayed with him: am I solving the problem for the team, or helping the team learn to solve it themselves? That shift changed how Arun worked. Instead of telling teams what to do, he began asking questions such as "What do you think is causing this?", "What options do we have?", and "What are we not seeing?" For Arun, the book is a practical reminder that coaching is not about leading people to your answer. It is about helping people think. [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 Arun Parameswaran Arun is an Agile delivery leader at Bosch Global Software Technologies who builds high-performing, data-driven ecosystems. He blends flow metrics, Jira analytics, Power BI, and applied AI to turn delivery into a transparent, predictable system. You can link with Arun Parameswaran on LinkedIn.

   August 25, 2026·18min
   Play
5. 5
   Number 5: BONUS: The Evolution of Agile - From Project Management to Adaptive Intelligence | Mario Aiello

   BONUS: The Evolution of Agile - From Project Management to Adaptive Intelligence, With Mario Aiello In this BONUS episode, we explore the remarkable journey of Mario Aiello, a veteran agility thinker who has witnessed and shaped the evolution of Agile from its earliest days. Now freshly retired, Mario shares decades of hard-won insights about what works, what doesn't, and where Agile is headed next. This conversation challenges conventional thinking about methodologies, certifications, and what it truly means to be an Agile coach in complex environments. The Early Days: Agilizing Before Agile Had a Name "I came from project management and project management was, for me, was not working. I used to be a wishful liar, basically, because I used to manipulate reports in such a way that would please the listener. I knew it was bullshit." Mario's journey into Agile began around 2001 at Sun Microsystems, where he was already experimenting with iterative approaches while the rest of the world was still firmly planted in traditional project management. Working in Palo Alto, he encountered early adopters discussing Extreme Programming and had an "aha moment" - realizing that concepts like short iterations, feedback loops, and learning could rescue him from the unsustainable madness of traditional project management. He began incorporating these ideas into his work with PRINCE2, calling stages "iterations" and making them as short as possible. His simple agile approach focused on: work on the most important thing first, finish it, then move to the next one, cooperate with each other, and continuously improve. The Trajectory of Agile: From Values to Mechanisms "When the craze of methodologies came about, I started questioning the commercialization and monetization of methodologies. That's where things started to get a little bit complicated because the general focus drifted from values and principles to mechanisms and metrics." Mario describes witnessing three distinct phases in Agile's evolution. The early days were authentic - software developers speaking from the heart about genuine needs for new ways of working. The Agile Manifesto put important truths in front of everyone. However, as methodologies became commercialized, the focus shifted dangerously away from the core values and principles toward prescriptive mechanisms, metrics, and ceremonies. Mario emphasizes that when you focus on values and principles, you discover the purpose behind changing your ways of working. When you focus only on mechanics, you end up just doing things without real purpose - and that's when Agile became a noun, with people trying to "be agile" instead of achieving agility. He's clear that he's not against methodologies like Scrum, XP, SAFe, or LeSS - but rather against their mindless application without understanding the essence behind them. Making Sense Before Methodology: The Four-Fit Framework "Agile for me has to be fit for purpose, fit for context, fit for practice, and I even include a fourth dimension - fit for improvement." Rather than jumping straight to methodology selection, Mario advocates for a sense-making approach. First, understand your purpose - why do you want Agile? Then examine your context - where do you live, how does your company work? Only after making sense of the gap between your current state and where the values and principles suggest you should be, should you choose a methodology. This might mean Scrum for complex environments, or perhaps a flow-based approach for more predictable work, or creating your own hybrid. The key insight is that anyone who understands Agile's principles and values is free to create their own approach - it's fundamentally about plan, do, inspect, and adapt. Learning Through Failure: Context is Paramount "I failed more often than I won. That teaches you - being brave enough to say I failed, I learned, I move on because I'm going to use it better next time." Mario shares pivotal learning moments from his career, including an early attempt to "agilize PRINCE2" in a command-and-control startup environment. While not an ultimate success, this battle taught him that context is paramount and cannot be ignored. You must start by understanding how things are done today - identifying what's good (keep doing it), what's bad (try to improve it), and what's ugly (eradicate it to the extent possible). This lesson shaped his next engagement at a 300-person organization, where he spent nearly five months preparing the organizational context before even introducing Scrum. He started with "simple agile" practices, then took a systems approach to the entire delivery system. A Systems Approach: From Idea to Cash "From the moment sales and marketing people get brilliant ideas they want built, until the team delivers them into production and supports them - all that is a system. You cannot have different parts finger-pointing." Mario challenges the common narrow view of software development systems. Rather than focusing only on prioritization, development, and testing, he advocates for considering everything that influences delivery - from conception through to cash. His approach involved reorganizing an entire office floor, moving away from functional silos (sales here, marketing there, development over there) to value stream-based organization around products. Everyone involved in making work happen, including security, sales, product design, and client understanding, is part of the system. In one transformation, he shifted security from being gatekeepers at the end of the line to strategic partners from day one, embedding security throughout the entire value stream. This comprehensive systems thinking happened before formal Scrum training began. Beyond the Job Description: What Can an Agile Coach Really Do? "I said to some people, I'm not a coach. I'm just somebody that happens to have experience. How can I give something that can help and maybe influence the system?" Mario admits he doesn't qualify as a coach by traditional standards - he has no formal coaching qualifications. His coaching approach comes from decades of Rugby experience and focuses on establishing relationships with teams, understanding where they're going, and helping them make sense of their path forward. He emphasizes adaptive intelligence - the probe, sense, respond cycle. Rather than trying to change everything at once and capsizing the boat, he advocates for challenging one behavior at a time, starting with the most important, encouraging adaptation, and probing quickly to check for impact of specific changes. His role became inviting people to think outside the box, beyond the rigidity of their training and certifications, helping individuals and teams who could then influence the broader system even when organizational change seemed impossible. The Future: Adaptive Intelligence and Making Room for Agile "I'm using a lot of adaptive intelligence these days - probe, sense, respond, learn and adapt. That sequence will take people places." Looking ahead, Mario believes the valuable core of Agile - its values and principles - will remain, but the way we apply them must evolve. He advocates for adaptive intelligence approaches that emphasize sense-making and continuous learning rather than rigid adherence to frameworks. As he enters retirement, Mario is determined to make room for Agile in his new life, seeking ways to give back to the community through his blog, his new Substack "Adaptive Ways," and by inviting others to think differently. He's exploring a "pay as you wish" approach to sharing his experience, recognizing that while he may not be a traditional coach or social media expert, his decades of real-world experience - with its failures and successes - holds value for those still navigating the complexity of organizational change. About Mario Aiello Retired from full-time work, Mario is an agility thinker shaped by real-world complexity, not dogma. With decades in VUCA environments, he blends strategic clarity, emotional intelligence, and creative resilience. He designs context-driven agility, guiding teams and leaders beyond frameworks toward genuine value, adaptive systems, and meaningful transformation. You can link with Mario Aiello on LinkedIn, visit his website at Agile Ways.

   October 18, 2025·44min
   Play