scrum Archives - Scrum Master Toolbox Podcast

Deborah Colombari: When Agile Principles Became a Fight With the System

“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?

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches – Scrum Master edition audiobook includes hours of audio interviews with SM’s that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!

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: The Scrum Master Who Let Standups Stay Silent Until the Team Took Ownership

“You can’t fix something until it breaks.” – Sheik Meeajaun

Sheik Meeajaun’s Monday story, is a 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?

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

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.

5th September 2026 at 10:05 CET
BONUS Why Software Projects Fail When Everyone Keeps Quiet With Mark Stringer

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.

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

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.

Arun Parameswaran: The Scrum Master Mistake of Fixing Trust With Process

“Don’t confuse activity with progress.” – Arun Parameswaran

When Arun Parameswaran stepped into one of his first Scrum Master assignments, he joined a distributed team where everything looked normal from the outside. Meetings were happening, Jira was updated, and work appeared to be moving. Underneath that surface, knowledge was unevenly shared, communication between locations was weak, and trust was not yet strong enough for people to speak openly.

Arun’s first instinct was to add more structure: more meetings, more activities, more process. Looking back, he saw the real mistake. He was creating activity, not progress. The shift came when he stopped trying to provide answers and started listening through one-on-one conversations.

He learned where people were struggling, what they expected from him, and what the team needed to own for itself. In this episode, Arun shares why Scrum Masters must understand people before changing the process, and why the best coaching often starts by asking better questions.

Self-reflection Question: Where are you adding process today because the real issue feels harder to talk about?

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

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.