Podcasts about scrum masters

Maria Skvortsova: When Agile Labels Hide Waterfall Reality — A Scrum Master's Wake-Up Call in SAP Migration 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 realized that even if I like Scrum and Agile, and I think they are really good ways of thinking, some areas cannot adapt them because they are completely different from the mindset and ways of working." — Maria Skvortsova   Maria came to Agile with the fire of a true believer. After a decade as a C++ developer, she'd found something that matched how she thought and felt about building software — something that went beyond controlling budgets and roadmaps. When a boutique SAP consulting company hired her as an Agile coach to transform their entire organization, she was all in. She built what she describes as a "really good" training for senior management, designed to sell them on Agile ways of working. But when she stepped out of the PMO role and into a real SAP migration project as delivery manager, the ground shifted beneath her. The iron triangle — fixed cost, fixed scope, fixed time — ruled everything. Teams ran "sprints" that were really just boxed iterations with no feedback loops, no value delivery, just a march toward a go-live date. Maria realized she was putting Agile labels on a fundamentally waterfall process. The hardest part wasn't the discovery — it was accepting that she needed to redirect her energy to environments where Agile could genuinely take root, rather than forcing it where the mindset simply didn't exist. Her advice: recognize when labels don't match reality as quickly as possible, and have the courage to choose environments that align with how you want to work.   Self-reflection Question: Are you putting Agile labels on processes that are fundamentally waterfall? How quickly would you recognize the mismatch — and what would you do about it?   [The Scrum Master Toolbox Podcast Recommends]

What Servant Leadership Actually MeansWhen I first heard the term “servant leader,” I pictured someone endlessly helpful. Always available. Always saying yes. Smoothing every edge, softening every message, making sure nobody was ever uncomfortable.I was wrong. And for a while, that misunderstanding made me a less effective Scrum Master.Here's the truth I had to learn the hard way: Servant leadership isn't about making everyone comfortable. It's about making everyone capable.How to connect with AgileDad:- [website] ⁠⁠⁠https://www.agiledad.com/⁠⁠⁠- [instagram] ⁠⁠⁠https://www.instagram.com/agile_coach/⁠⁠⁠- [facebook] ⁠⁠⁠https://www.facebook.com/RealAgileDad/⁠⁠⁠- [Linkedin] ⁠⁠⁠https://www.linkedin.com/in/leehenson/

Njegos Ilic: The "Painting by Numbers" Scrum Master vs. The Quiet Leader Who Made the Team Self-Sufficient In this episode, we refer to the concepts of Scrum Master as facilitator and team empowerment. The Bad Scrum Master: The "Painting by Numbers" Approach That Leaves Product Owners Working Alone 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 basically feel totally alone because you are trying to deliver value as a team, but if nobody asks anything and nobody challenges anything, you end up defining everything yourself." - Njegos Ilic   Njegos describes the worst Scrum Master anti-pattern he's witnessed: the "painting by numbers" Scrum Master who runs every ceremony by the book — dailies, refinements, plannings, retros, reviews — but without understanding the purpose behind any of them. The meetings become a reporting cycle: "What did you do yesterday?" with no interaction, no challenging, no real engagement. From the product owner's perspective, this is devastating. Njegos describes feeling completely alone — trying to deliver value as a team while nobody engages, nobody asks questions, nobody pushes back on assumptions. The downstream effect is predictable: gaps that could have been caught early with a single conversation only surface during development or after deployment. Worse, the lack of engagement creates doubt and overthinking — the product owner starts over-defining requirements because there's no feedback loop, which reinforces the very passivity that caused the problem.   Self-reflection Question: Are the ceremonies on your team creating genuine engagement and learning — or have they become a reporting cycle that nobody actually needs? The Great Scrum Master: The Quiet, Impactful Leader Who Made the Team Self-Sufficient 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 Scrum Masters I worked with were invisible — they knew always when to speak, they sensed the pulse of the team, and they weren't afraid to jump in when needed." - Njegos Ilic   The best Scrum Masters Njegos has worked with share a common trait: they were almost invisible. They didn't dominate meetings or insert themselves where they weren't needed. But they were always present — sensing the team's pulse, knowing when to step in, unafraid to say "we're out of time, let's take this offline." They were knowledgeable about the product, which earned them genuine respect from developers. And perhaps most powerfully, they delegated facilitation itself. Njegos shares an example where a Scrum Master introduced a round-robin system: when new developers joined the team, everyone took turns facilitating meetings — planning, retros, dailies. This wasn't just delegation for efficiency; it was empowerment by design. Team members who facilitated a retrospective suddenly understood how hard it is to lead one. That empathy changed how they participated when someone else was facilitating. The Scrum Master remained the guide, but the team grew its own capacity to self-organize.   Self-reflection Question: If your Scrum Master disappeared tomorrow, would your team know how to facilitate its own ceremonies — and if not, what does that say about how the role is being used?   [The Scrum Master Toolbox Podcast Recommends]

Njegos Ilic: Why Measuring Your Product Bets Is the Key to Product Owner Success Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "If you cannot measure what you build, you will just be depending on who is screaming the loudest and using your gut feeling — which is not a good thing long term." - Njegos Ilic   Njegos defines product owner success through three pillars: the ability to measure product bets, deep knowledge of the industry and product, and the humility to admit mistakes and be challenged. The measurement piece is central — without it, he argues, you're flying blind, making decisions based on opinions rather than evidence, reacting to whoever screams loudest rather than what the data shows. But Njegos is honest that not every environment makes measurement easy. Some companies lack the tooling, the culture, or the historical infrastructure to set up proper analytics. In those situations, he turns to user interviews as the next best thing — getting direct feedback from users, even though he acknowledges that opinions are still limited without data to fact-check them against. His most powerful suggestion: invite the whole team to user interviews, not just the product trio. When developers hear directly from users, they connect to real-world problems, and conversations during refinements become richer and more grounded.   In this episode, we refer to The Mom Test by Rob Fitzpatrick and Shift: From Product to People by Michael Dougherty and Pete Oliver-Kruger.   Self-reflection Question: How do you currently measure whether the features you shipped actually delivered the value you expected — and if you can't measure it, what's your fallback? Featured Retrospective Format for the Week: Start With a Relaxing Exercise Njegos doesn't advocate for a specific retrospective template — and that's the point. From his product owner perspective, he values retrospectives that begin with a relaxing, informal exercise to set the tone. Not everything needs to feel like business as usual. This casual opening allows people to connect as humans first, which opens them up to think differently about what they learned during the sprint. Njegos is candid about the reality: some teams love icebreakers, while others find them childish and just want to get to the point. His advice is to sense the pulse of the team and adapt. The format matters less than whether it creates an environment where people can be honest about what went well, what didn't, and what to improve. A Scrum Master who reads the team's vibe and adjusts accordingly — that's what makes the difference.   [The Scrum Master Toolbox Podcast Recommends]

Njegos Ilic: How a Miro Board Experiment Changed the Way His Team Understood the Big Picture 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.   "Every feature is a product bet. I would call this a process bet — just try to see what works best for you." - Njegos Ilic   Njegos shares a change story from his time working with a tech lead who had previously been a Scrum Master — a partnership that made all the difference. Together, they introduced a simple but powerful change: visualizing the team's work on a Miro board instead of relying on a standard ticket board with cards and status columns. They mapped out concepts, connected ticket numbers to a visual representation of how different pieces of work fit together, and used this board during dailies and refinements to track progress in context. The change wasn't imposed top-down — Njegos and his tech lead simply said, "Give us one sprint to try this. If it doesn't work, we drop it." The result was immediate: dailies became more engaging, the team could see how their individual work connected to the bigger picture, and Njegos found it much easier to track progress as a visual thinker. His advice for Scrum Masters and product owners who want to introduce something similar is refreshingly simple — frame it as a "process bet," just like you'd frame a product bet. Try it, measure what happens, and if it doesn't work, drop it and try something else. The willingness to experiment with your own process is a prerequisite for experimenting with the product itself.   Self-reflection Question: What "process bet" has your team been avoiding — and what would it take to just try it for one sprint?   [The Scrum Master Toolbox Podcast Recommends]

Njegos Ilic: Why the Product Trio Breaks the Hand-Off Mentality That Kills Team Engagement 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 can't change people, but I can definitely involve them." - Njegos Ilic   Njegos describes a pattern he's encountered multiple times as a product owner: teams where engagement is almost nonexistent. He walks into a refinement session, presents ideas, asks for feedback — and gets crickets. Nobody pushes back, nobody asks questions, nobody challenges the assumptions. The result is a product owner working in isolation, defining everything alone, only to discover gaps during development that could have been caught early with a single conversation. Njegos is honest about the limits of what any one person can do — you can't change people's personalities, and expecting a Scrum Master to do so is unrealistic. But what you can do is involve people. His approach when joining a new team: don't come in announcing how things will work. Instead, learn how the team already works, meet them where they are, and then find ways to fit new concepts into their existing rhythm. For the non-negotiable things — the red lines — he's precise, open, and always provides an alternative rather than just pushing his way.   In this segment, we talk about Discovery and Delivery and the Product Trio concept.   Self-reflection Question: When you join a team meeting and get silence instead of feedback, do you assume agreement — or do you treat it as a signal that something deeper needs to change? Featured Book of the Week: Inspired by Marty Cagan Njegos recommends Inspired by Marty Cagan as the book that most shaped his approach to product ownership. He highlights the entire SVPG series — including Empowered and Transformed (available as the Product is Hard SVPG Box Set) — but points to the Product Trio concept as especially powerful. As Njegos puts it, the Product Trio — bringing together a product manager, a tech lead, and a designer — removes the hand-off mentality where each discipline works in isolation. Instead of the product owner defining everything alone and handing it to the team, the trio shapes problems together during discovery, so that by the time work reaches the team, there's shared understanding of why they're building something, not just what to build.   [The Scrum Master Toolbox Podcast Recommends]

Christian Thordal: The Jazz Duo Effect and The Absent PO — Two Sides of Agile Product Ownership The Great Product Owner: Clarity, Accountability, and a Partnership That Fills in the Blanks 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 kind of filled in the blanks for each other, and it felt very natural — it's grown organically into this partnership where we're extremely aligned on how we see and do things." - Christian Thordal   Christian describes his best Product Owner as someone he currently works with — a person who combines deep product clarity with genuine leadership. This PO is fully accountable for the backlog, sets clear expectations toward the teams, and isn't afraid to push them. What makes this PO stand out is how they use reporting as a communication tool: alongside the backlog, they proactively communicate to the product leader whether things are within or outside scope, always with a plan ready. Christian and this PO hold weekly follow-ups to discuss the team, the backlog, and the product direction. Over time, their alignment has become so strong that during facilitation sessions they naturally fill in blanks for each other — one picks up where the other leaves off. Vasco compared it to a jazz duo, where each musician picks up on the other's leads in real time. This kind of organic partnership in leadership direction reflects positively on the entire team, creating a sense of coherence and momentum that everyone can feel.   Self-reflection Question: How aligned are you with your Product Owner on leadership direction, and what would it take to build the kind of partnership where you naturally fill in the blanks for each other? The Bad Product Owner: When the PO Disappears and the Scrum Master Becomes the Glue 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 inspire, you can motivate, but you can't really do the work for them." - Christian Thordal   Christian shares an experience from a larger logistics company in Denmark where the Product Owner was a great, likable person — but didn't understand the role. The backlog was high-level, consisting primarily of Epics with no acceptance criteria. Then the warning signs started: the PO became increasingly hard to get a hold of, started canceling refinement meetings (sometimes on the same day), began working more from home, and became physically more distant from the team. Christian and the team were left to navigate on their own, breaking down epics into stories and tasks without knowing if they were building the right product. Christian tried setting up weekly one-hour sessions to help the PO work through the backlog, but the fundamental problem remained — you cannot do the PO's work for them. Eventually, Christian found himself filling in for the PO, which is itself an anti-pattern: the Scrum Master becoming the glue that holds the product together. The symptoms to watch for are clear: a PO who starts missing meetings, backlog items that remain unrefined, a PO who becomes physically or remotely distant, and — the biggest red flag — a Scrum Master who feels compelled to step in and do the PO's job.   Self-reflection Question: Are there signs that your Product Owner is drifting away from the team, and have you caught yourself filling in gaps that aren't yours to fill?   [The Scrum Master Toolbox Podcast Recommends]

Christian Thordal: Structure Creates Freedom, How an Agile Coach Measures Success by Becoming Less Needed 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 less I shine and the more the team shines, the better I perform." - Christian Thordal   Christian shares how his definition of success has fundamentally shifted over the years. Early in his career, the question was "How can I shine?" Today, it is the opposite — success means becoming invisible. For Christian, a high-performing Scrum Master builds teams that no longer depend on them, much like raising a child to become a functional adult by eighteen. They can always call dad for coaching or to borrow money, but they can stand on their own. He illustrates this with a team he moved from what he calls "cowboy loose Kanban" to an adapted Scrum framework. The structure gave the team freedom: he can now miss dailies and planning sessions, and the team still produces a solid plan, sprint backlog, and sprint goal. He drops by to give pointers and encourage good behaviors. Christian also highlights the importance of the Scrum Master and Product Owner partnership — "the mom and dad of the team" — and how building predictability and flow matters more than heroics. A key tactical insight: he created a one-pager roadmap for his domain leader showing issues, plans, milestones, and metrics. This simple artifact gave leadership the comfort that things were under control, buying Christian the autonomy to do his best work. This proved critical when his team was decimated by departures in late 2025 — he hired new people, stabilized the group, and got them delivering again.   Self-reflection Question: What would it look like if your team could run a full sprint cycle without you present — and what is stopping that from happening today? Featured Retrospective Format for the Week: The Four-Box Retrospective Christian shares a retrospective format he calls the Four-Box Retrospective — a structured, pragmatic approach that resonates especially well with engineer-minded teams. The session begins with a team check-in to get the vibe in the room. Next, the team reviews last week's agreements: who was accountable, and are those items still alive or handled? Anything still alive moves forward automatically, ensuring nothing falls through the cracks. Then comes the core mechanic: topic creation divided into four boxes — Tech (tools and tech stacks), Team (issues within the team), Outside (external dependencies and blockers), and Parking Lot (everything else). Presenters explain their topics briefly to give context, and the group uses dot voting to surface the most pressing issues. Discussion follows, with clear accountability assignments and action items written down. The pre-grouping into four boxes saves significant time by giving topics a natural home before discussion begins. Named owners for every action item create real progress between retrospectives. Christian values this format because it is grounded in actual operational problems — people can see the direct application of every conversation, which keeps engagement high and outcomes tangible.   [The Scrum Master Toolbox Podcast Recommends]

Organizations are still struggling to deliver what their customers want, when they want it, and the loudest question in delivery right now is whether agile and traditional project management are stronger together.Some Scrum practitioners are pursuing PMP certifications for the first time, traditional project managers are picking up the updated PMI-ACP, and the lines between Scrum Master and Project Manager have blurred in the marketplace.  Both disciplines bring real strengths. Forward thinking leaders are leaning into the blend instead of defending a camp.Most organizations are not picking sides anymore.  They are picking outcomes. The question is no longer "are we doing real Scrum" or "are we doing proper Project Management."  The question is whether your teams are delivering value, learning fast, and treating their customers like the heroes of the story.In this episode, we discuss:Why "Technical Project Manager" and "Scrum Master" have quietly become the same role on most job boardsHow the updated PMI-ACP is bridging traditional project management and agile leadershipThe hybrid skills organizations are hungry forThe leadership move that changes everything, regardless of title or framework

Peter Merel: Leadership as a Service — Why Scrum Masters Should Work Themselves Out of a Job and How Quality Circles Make Learning Flow 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 Scrum Master is a self-defeating role. If you have worked yourself out of a job, then you've succeeded." - Peter Merel   Peter Merel challenges the very notion of the Scrum Master as a permanent organizational role. He argues that calling someone a "master" makes everyone else a servant — the opposite of what agile teams need. Instead, Peter advocates for leadership as a service, where every team member provides leadership to their team and every member of a swarm provides leadership to their swarm. He points to the Haudenosaunee Confederacy — the successful direct democratic republic that existed in North America before the USA, and which influenced the American founding fathers — as a model for distributed leadership. The protocol is simple enough to apply universally, regardless of organizational structure. Peter's practical approach to success measurement is equally compelling: build a thin steel thread of alignment, prove it works in 8 to 12 weeks, then split it and backfill with the most progressive people in the organization. He describes growing a group of 300 in just 9 months using this approach. The key insight is that coaches should not think of themselves as change agents, but rather as people who transform change participants into change leaders. Once a team can self-organize without you, your job is to move on to the next challenge — and that's what success looks like.   In this episode, we refer to the concept of leadership as a service and the XScale Alliance.   Self-reflection Question: If you stepped away from your team tomorrow, could they self-organize effectively — and if not, what's the one thing you could teach them this week that would bring them closer to not needing you? Featured Retrospective Format for the Week: Quality Circles Peter Merel recommends quality circles as a cross-team retrospective format drawn from the Toyota Production System. The concept is simple but powerful: take three teams of six people and break them into six quality circles of three — one person from each team in each circle. These circles meet regularly for 10 to 30 minutes, ideally before team planning sessions, to share problems, ideas, and ways they can help each other. The magic of three people is that while one person explains, another listens, and the third is already thinking about where the conversation goes next — creating what Peter calls "a beautiful hum." Each circle brings two kinds of ideas back to their team: proposals for work that would benefit the teams as a whole, and treaties — working agreements between teams. The teams remain autonomous and can decide how to respond. Peter emphasizes that this approach scales naturally — representatives from groups of teams can form quality circles at higher levels, keeping face-to-face communication alive across entire organizations. As Peter puts it, "Learnings flow across the organization — and that's more valuable than anything you can come up with in a retrospective by yourself."   [The Scrum Master Toolbox Podcast Recommends]

Peter Merel: When Telling a Manager "You Don't Have a Role" Backfires — A Lesson in Agile Coaching Humility 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 failure is not a failure. A failure is just the first step." - Peter Merel   Peter Merel became a Scrum Master by stealth — long before the title existed. Credited in Kent Beck's first XP book and present at the first agile conference, Peter was practicing lightweight processes at Hewlett Packard in the late 1990s. When he took a role at GMAC, the residential finance arm of General Motors, he brought XP practices with him and found early success. After six months of strong results, the project manager, Mike Alakom, sat Peter down and asked the most dangerous management question: "What do I do?" Peter gave what he now calls the stupidest answer possible — "You don't really have a role in this process." The next day, Mike called an all-hands meeting and calmly maneuvered Peter into crediting the entire way of working as Mike's idea. Peter stayed on for another six months, but at arm's length. In hindsight, Peter recognizes Mike did exactly what he should have done. The second failure came at Commonwealth Bank of Australia, where Peter was brought in to coach agile but was actually being set up to fail — a ripcord the organization could pull when it wasn't ready for change. The delivery manager, Des Webster, told Peter directly: "You were set up to fail." Peter walked away, thinking he'd never return. But six years later, every person he had coached had moved up in the organization, and Peter came back as principal coach for 50,000 people. The CIO declared Agile one of the bank's five pillars. Just because you hit the wall doesn't mean it's the end — it might be the beginning.   Self-reflection Question: When was the last time you failed at introducing change, and have you considered that the seeds you planted might still be growing in ways you can't yet see?   [The Scrum Master Toolbox Podcast Recommends]

The framework wars are over, and the only question that still matters is whether the work is landing in your customers' hands.This episode dives into the great convergence of project management and agility. Job titles are blending, PMI is leaning hard into adaptive approaches, and the new PMBOK reads nothing like the tablet of stone we used to study. The lines between Scrum Master and Project Manager have blurred in the marketplace, and forward-thinking leaders are leaning into the blend instead of fighting it.Most organizations are not picking sides anymore; they are picking outcomes. The question is no longer "are we doing real Scrum" or "are we doing proper Project Management." The question is whether your teams are delivering value, learning fast, and treating their customers like the heroes of the story.In this episode, we discuss:Why "technical project manager" and "Scrum Master" have quietly become the same role on most job boardsHow PMI and Agile Alliance moved from rivals to partners, and what the new PMBOK signals about the futureThe Shuhari path of mastery, and why so many teams skip straight to “ri” without earning itThe better questions leaders should be asking instead of arguing about labels

BONUS: Why Your Agile Transformation Keeps Snapping Back — And What Systems Thinking Says About It Natalia Curusi co-authored a book that doesn't tell you what agile should look like — it tells you what actually happens when you try to transform an organization. Friday-night deployments, zombie teams going through the motions, transformations that met a wall of silence. In this episode, we unpack the real lessons from the front lines: how personal values drive the shift to agile, why some teams have all the ceremonies but none of the substance, and what systems thinking reveals about why transformations fail — or snap back. When Your Values Don't Match Your Ways of Working "I felt like there is a mismatch in my values, my moral values and principles, and customer-centric orientation. So when I found out about Agile around 2010, I understood — okay, this is the answer. Now I have the answer how I can map my moral values and principles with software delivery."   Natalia's journey to agile didn't start with a methodology — it started with a gut feeling that something was wrong. Working in large corporations in the early 2000s with fixed-scope contracts, late deployments, and scripts running directly in production, she sensed a disconnect between how work was done and how it should be done. When she moved to a smaller company around 2010 and experienced transparency, collaboration, and the freedom to ask any question without fear, she realized this was the agile mindset — even before she knew the term. The key insight: agile isn't something you adopt, it's something that aligns with values you may already hold. That alignment between personal principles and ways of working is what makes the difference between going through the motions and genuinely transforming how a team operates. Don't Be an Agile Zombie "The first thing I observe — if I go to some of the ceremonies and I see that stand-up becomes like a status meeting, and everybody is reporting to somebody. People are afraid to say some of the things, afraid to escalate risks or assumptions."   One of the strongest chapters in the book is titled "Don't Be an Agile Zombie." Natalia describes teams that have all the boards, all the roles, all the right meeting cadences — but nothing is actually changing. The Scrum Master becomes a secretary. The Product Owner is a proxy afraid to make decisions. The tell-tale signs? Fear and formality. When people report upward instead of collaborating sideways, when risks go unspoken because the environment punishes transparency, that's a watermelon project — green on the outside, red on the inside. Natalia's approach starts with observing the tone and dynamics in ceremonies. If the stand-up feels like a status report and not a coordination meeting, something deeper is broken. And her advice is direct: if an organization is delivering waterfall and happy with the predictability and value, that's fine — just call it what it is. Don't put lipstick on a pig. As Rebecca Homkes discussed on this podcast, the key is to communicate the truth with care, but communicate it nonetheless. Task-Driven vs. Value-Driven: The Real Spectrum "It's not right to say that you are agile if you are not. Just name the things how they are — name the things using the right word."   Rather than the old waterfall-vs-agile binary, a more useful lens is the spectrum between task-driven and value-driven product development. On the task-driven side, somebody creates the list of tasks — requirements, architecture document, design document — and a project manager distributes them. Teams execute but aren't asked to be creative or adaptable. On the value-driven side, what matters is the impact of what teams build. Value is discovered through the dynamic interaction of functionality with customers — it can't be predetermined. Most organizations sit somewhere on this spectrum, and many are slowly moving toward the value-driven end even if they don't call it agile. The practical takeaway: transformation should be tailored to where an organization actually is, not where a framework says it should be. The book argues for a pragmatic, hybrid approach rather than evangelical purity. Systems Thinking: Why Transformations Snap Back "We did a big agile transformation — five years of real transformation. Then the company was bought, merged with a bigger payment provider. And now they are working with SAFe. And that's the end of the story."   In the later part of the book, Natalia and her co-author move into systems thinking — Cynefin, the Iceberg Model, causal loop diagrams. Many agile practitioners stop before they get here because it feels academic. But Natalia argues it's essential, and she illustrates why with a real example: a payment company that went through five years of successful agile transformation using LeSS, only to be acquired by a larger organization that pushed SAFe — and the transformation snapped back. This is the basin of attraction concept: a system has to pass through a point of genuine disruption before it can settle into a new stable state. Without that, it returns to where it was. For practitioners looking to get started with systems thinking, Natalia recommends The Fifth Discipline by Peter Senge and learning to build causal loop diagrams — a practical tool that creates productive conversations about how organizational dynamics actually work. The Post-Agile Era: Beyond Labels "It's like comparing apples and orchestras. You cannot compare agile and AI — they are completely different things. Agile is not enough, but it's also not dead."   Natalia addresses the "Agile is dead" debate head-on. Her argument: comparing agile to AI is a category error. An apple cannot play an orchestra, and an orchestra cannot replace an apple — they serve entirely different purposes. AI can handle a significant portion of day-to-day tasks, but it lacks common sense, empathy, and the ability to read a room. Rather than declaring agile dead, Natalia sees a post-agile era — not one where agile disappears, but where we move beyond the label wars. The trends that matter aren't about whether agile is popular; they're about collaboration, adaptability, and understanding how teams and organizations actually work. We can finally talk about what matters in our industry without being pressured to label it. About Natalia Curusi Natalia Curusi is an Agile Coach at Endava with over 20 years in software delivery, specializing in agile transformations, delivery optimization, and systems thinking. She leads Asia Pacific initiatives driving business agility. She is co-author of From Resistance to Resilience: Practical Agile Lessons for Transformation.   You can link with Natalia Curusi on LinkedIn and visit her website at nataliacurusi.com. You can also join the Agile Continuum community on LinkedIn.

BONUS: Hard Hats and Standups — Why the Construction Industry Is Going Agile at GAS26 Felipe Engineer-Manriquez is one of the co-hosts of the Agile in Construction track at the Global Agile Summit 2026. In this preview episode, he and Vasco talk about why Agile belongs on the construction site, what the track's speakers discovered when they stopped following the plan, and why software people should pay close attention to an industry that builds hospitals, not apps. Construction Is 20 Years Behind — And That's the Opportunity "People don't realize that those ideas absolutely work in other industries. Agile's been successfully applied everywhere, and I think where it gets the least amount of publicity is in the construction sector."   When most people hear "Agile," they think standups in a tech office, not concrete and rebar. Felipe wants to change that. Construction, he says, is always about 20 years behind whatever process or technology the rest of the world adopts — a "very safe stock of keeping tradition." That gap is exactly what makes this track valuable. Agile is alive and growing in construction, and the translation turns out to be simpler than you'd expect. Most of what needs to change isn't the framework — it's the vocabulary. The sessions in this track show how practitioners made that jump with surprisingly small tweaks. The Speakers Don't Know How Good They Are "Half the speakers that I asked were like, 'what, me? Do I have a story to share?' I was like, yeah, you have this really amazing... people just don't realize how awesome they are."   One of the things that struck Felipe while assembling the track was how humble the speakers are. People who have transformed how their companies deliver work — including the keynote speaker, Brian, whose organization celebrated 10 years and saw dramatic before-and-after results — genuinely didn't think their stories were remarkable. They grew up in an industry with 100 years of project management tradition, where PMI-style thinking is the water they swim in. They don't see how different things look from the outside. Some of these practitioners couldn't even work across projects before adopting Agile — and now they're doing it routinely. That capacity shift alone is a data point worth paying attention to. Stop Following the Plan — Start Responding to Change "It's just ground into you, that thou shalt follow a plan. But in reality... they have to do heroic things to make those plans happen. Because the plans are just wrong."   Felipe zeroed in on the Agile value of responding to change over following a plan as the single biggest shift his speakers experienced. In construction, plan adherence is gospel — you follow the schedule, period. But in practice, teams were performing heroics just to make flawed plans appear to work. As speakers adopted Agile, they stopped forcing broken plans and started adapting. Felipe gives a nod to #NoEstimates — calling Vasco "the granddaddy of #NoEstimates" — as part of the same insight: the plans are wrong, and the sooner you accept that, the sooner you can respond to what's actually happening. The second pattern was equally powerful: for the first time, construction workers started thinking about who actually uses what they build. You'd think building a school or hospital makes the end user obvious, but Felipe says people in the industry can work for years and never once consider who receives their work. Agile forced that question, and the answers changed how they prioritize. What Software People Should Steal From Construction "Inside of every process are people. Everyone faces resistance to change... when I stopped trying to teach people, and I started inviting people, things changed."   Here's the cross-industry lesson Felipe wants software practitioners to hear: resistance to change is universal, and the breakthrough is the same everywhere. Every speaker in the track had a moment where they learned something new and didn't want to go back to the old way. That's the same moment every Scrum Master, product owner, and developer has lived through. The universal tactic that worked? Showing rather than telling. Case study after case study revealed that the real breakthroughs came not from training sessions or slide decks, but from demonstrating results and inviting people in. Stop teaching, start inviting — that's a principle that works whether you're pouring concrete or shipping code. Come Monday, You'll Ask Better Questions "The best thing you're gonna do on Monday after the summit is you're gonna start to ask really intelligent questions. That is gonna be priceless. That's something that AI doesn't even do for people."   Felipe's take on what attendees will walk away with isn't a new framework or a certification. It's a shift in the questions they ask. Twenty years into practicing Lean Construction, Agile, and Scrum, Felipe says asking better questions is the one thing that has stuck with him the entire time. Better questions melt away resistance, open up new perspectives, and make new ways of working accessible. The ideas in the track are, in his words, "not terribly complicated — they're actually quite simple, and I would even say elegant." And the speakers are approachable — Felipe personally vouches that every speaker in his track answers emails. There will also be live Q&A sessions during the summit for direct interaction. When Your AI Agent Tells You to Build a Website, You Listen "My chief orchestrator said, you should have your own website. So felipe.engineer was built."   In a delightful closing moment, Felipe shared that his personal website at felipe.engineer was built by his AI agent. Not suggested and then hand-coded — fully built, complete with a style guide the agent had strategically created two weeks earlier. Felipe jokes that the AI was setting him up: first planting the seed that he needed a style guide, then recommending it be applied to a brand-new personal site. Felipe also has a session in the track about building an AI bot for construction sites — another reason to check out the full lineup at globalagilesummit.com. About Felipe Engineer-Manriquez Felipe Engineer-Manriquez is a best-selling author, international speaker, and host of The EBFC Show. A force in Lean and Agile, he helps teams build faster with less effort. Felipe trains and coaches changemakers worldwide — and wrote Construction Scrum to make work easier, better, and faster for everyone.   You can link with Felipe Engineer-Manriquez on LinkedIn.   You can also find Felipe at thefelipe.bio.link, check out The EBFC Show podcast, and join the EBFC Scrum Community of Practice.

What does it really take to make AI work, not just technically, but organizationally? In this episode of the Scrum.org Community Podcast, host Dave West sits down with Dr. Alan Brown, researcher, advisor, and author of the new book Making AI Work for Britain, to explore the complex realities of AI adoption in large organizations and government.Drawing on decades of experience in enterprise digital transformation from Rational Software to IBM to advising public sector institutions, Alan unpacks why AI is both an evolutionary step and a fundamental disruption, and why most organizations are struggling to bridge the gap between technological capability and organizational readiness.Alan and Dave explore how lessons from the UK's digital government journey of consolidating demand, diversifying supply, offer a practical lens for every team navigating AI adoption today. They also dig into three principles Alan believes are at the heart of any disciplined approach to AI: value, risk, and trust and why that last one might be the most transformative idea yet for Scrum Teams.Whether you're a Scrum Master, Product Owner, or senior leader trying to make sense of AI in your organization, this conversation offers a grounded, thought-provoking framework for moving from pilot chaos to purposeful delivery.Book details can be found at https://futureofai.uk/Blog: Making AI Work: What Scrum Gets Right and Organizations Get Wrong

BONUS: Why the People Track Exists — And What It Will Help You See at GAS26 The Global Agile Summit kicks off on May 4th, and the People track is one of the most loaded lineups this year. In this episode, track co-hosts Pete Oliver-Krueger and Alina Thapliyal share the story behind the track, the sessions they're most excited about, and why — in a world increasingly focused on technology and AI — the people dimension is more critical than ever. The Story Behind the People Track "Every transformation still comes down to how people feel, how they communicate, how they work with each other, how decisions are made, and how leaders can create a space and conditions for them to thrive."   The People track isn't new to the Global Agile Summit — it's been part of the event for several years, sometimes combined with the Product track. But this year, the volume and quality of submissions made it clear that the topic deserves its own dedicated space. Alina frames it in terms of the VUCA world we operate in: volatility, uncertainty, complexity, and ambiguity make the people dimension more important, not less. Pete picks up the thread with a sharper edge — as AI and technology increasingly dominate the conversation, it's easy to lose sight of the people creating, designing, using, and selling the products. That tension is exactly why he wrote Shift: From Product to People with his co-author Michael. The book exists to pull practitioners out of product-as-a-thing thinking and into product-as-people thinking. Product as a Thing vs. Product as People "When we lose sight of the people around the product is when things start to suffer."   When Pete reviewed the track submissions, he noticed a telling pattern — a divergence that confirmed the track's reason for existing. Many submissions talked about product as an artifact, focused on deliverables and outcomes, with no connection to the humans involved. Then there was a second group that immediately saw themselves in the People track. Pete explains the dynamic: we all start by caring about people and solving problems, but at some point we pick a solution and the work of getting it done becomes all-consuming. The task becomes the goal and the people become objects. Unless we consciously leave space to think about relationships and human dynamics, we drift into laser focus on things. The sessions in this track are designed to be the antidote. Marcus Bullock's Keynote — A People-First Success Story "It's so inspiring to just listen to it and think that I can also do it. We can give people a second chance. We can focus on what's good and increase the good, rather than focus on what's bad."   Both Alina and Pete highlighted Marcus Bullock's keynote as a must-watch. Marcus, CEO of Flikshop, started from a deeply difficult place and built his way to leading a business and empowering others. What makes his story stand out isn't the arc from adversity to success — it's the honesty. Pete, who has known Marcus for over 15 years, points out that Marcus's story includes genuine ups and downs, and his people-first approach is what helped him weather all of them. Alina was struck by the energy Marcus brings and his focus on amplifying what's good in people rather than minimizing what's bad. It's a message that resonates whether you lead a team of five or an organization of five thousand. Usability Theater — The Courage to Shut Up and Listen "Take a product, give it to a customer, and don't say anything. Just let the customer try it, let the customer experience the product. We need to have the courage to shut up."   Alina's second highlight was the session on usability theater, where the core idea is deceptively simple: put your product in front of a customer and resist the urge to explain anything. No "look what we did here," no guided tour. Just observe how people actually interact with what you've built. It takes real courage, Alina says, because our instinct is to showcase and defend our work. But the insights you gain from silence and observation are worth far more than the comfort of narration. This is one of those sessions that sounds simple but could change how you run your next product review or demo. Agency — Breaking the Permission Loop "There is a necessity to understand ourselves and have some of this confidence, but that's true for everybody, even our leaders. They may be stuck in permission loops with their own bosses."   Tara Scott's session on agency and breaking the permission loop touched a nerve for both hosts. Alina shared that in companies she's worked for, drawn-out decision processes wasted resources and drove people to leave. Tara's session tackles how to empower people to actually make decisions. Pete adds a crucial nuance: the permission loop isn't just a top-down problem. Leaders are stuck in their own permission loops too. Everyone in the chain faces the same challenge, and the solution can't be found in a vacuum — it requires understanding where each person is coming from and building flexibility across the team and organization. If this topic hits close to home, Tara is also doing a live Q&A during the summit. Neurodiversity, Jeff Patton, and the Full Lineup "Every time I have a conversation with Jeff Patton, it just goes in all kinds of directions, and I have so much fun."   Pete flagged two more sessions worth watching. The neurodiversity session with Anita promises to open up a topic that deserves more airtime in the agile community — how different minds experience and contribute to team dynamics. And Jeff Patton, whose conversations with Pete apparently never follow a straight line, brings his signature blend of product thinking and people awareness. The full track covers a wide range: trust, leadership, inclusion, decision-making, neurodiversity. As Alina puts it, these topics are universal — they're about human behavior, and that's valuable in any field where you work with people. A New Lens for Monday Morning "I think people can take away from the track the ability to see other dynamics in their workplace that maybe they currently aren't spending a lot of time paying attention to, or didn't even realize were there."   When asked what attendees will walk away with, both Alina and Pete landed on the same metaphor: a new lens. Alina described it as a better understanding of how human dynamics shape culture and performance, paired with practical tips that can be applied immediately — no theory, just real-life stories from real practitioners. Pete took the metaphor further, comparing it to putting on night vision goggles. After watching these sessions, you'll start noticing dynamics you'd been walking past every day — relationship patterns, permission loops, communication gaps. And with that new visibility comes influence. You'll realize you have more ability to shape your environment than you thought, simply because you can now see what was always there. About Pete Oliver-Krueger Pete Oliver-Krueger is an Executive Coach with the Library of Agile, and co-author of the book "Shift: From Product to People", a novel that tells the complex story of how leading "people-first" is required to solve tomorrow's biggest problems.   You can link with Pete Oliver-Krueger on LinkedIn, and visit Pete OK's website at https://www.shiftingpeople.com/. About Alina Thapliyal Alina Thapliyal is the Scrum Master for a team within the public sector. Her aspiration is to become an agile coach. She grew up in Romania and has been living in Germany for 13 years. She loves jogging, reading and actively listening to people's life stories.   You can link with Alina Thapliyal on LinkedIn.

Viktor Glinka: The Curious Product Owner and the Disempowered One — How Scrum Masters Can Help POs Find Their Voice In this episode, we refer to product owner anti-patterns and product owner interviews on the Scrum Master Toolbox Podcast. The Great Product Owner: The Curious Negotiator Who Uses Data and Passion 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.   "Great product owners are always asking: what if? How can we do it differently? How can we simplify?" - Viktor Glinka   Viktor describes great product owners as fundamentally curious people who constantly look for simpler, better ways to do things. But curiosity alone isn't enough — they're also skilled negotiators who navigate conversations with teams, stakeholders, and customers. In scaled setups, their work shifts from clarification to prioritization, and they delegate effectively. Viktor highlights their visualization skills with a concrete example: one product owner showed stakeholders a work composition chart revealing that more than 50% of the team's work was technical debt, making it impossible to deliver new features. That single visualization changed the conversation. Great product owners are also systems thinkers who understand dynamics and root causes, avoiding local optimization. Viktor adds something rarely discussed in frameworks: mindfulness. Product owners face constant pressure, and the ability to make peace with decisions — to move forward without regret — is critical. They also share their passion and vulnerability with development teams, telling them personally why they want to build something. It's the emotional complement to data-driven negotiation.   Self-reflection Question: Does your product owner use data and visualization to negotiate with stakeholders, or do they rely on authority and deadlines? How could you help them build those skills? The Bad Product Owner: The Disempowered Middleman Who Can't Give 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.   "This fear of not being allowed — it's an illusion. You can always do more. Just try. No one will fire you for a suggestion." - Viktor Glinka   For Viktor, the worst product owner anti-pattern isn't about skill or knowledge — it's about empowerment. He believes every person can learn to become a great product owner if they are empowered and trusted by the organization. The red flags are clear: when a product owner talks about deadlines and commitments but never about return on investment or outcomes, that's a sign they're being pushed rather than empowered. Viktor shares the story of a product owner who was struggling to give direction because stakeholders just wanted their features delivered. He was a middleman — afraid to communicate his own vision to the team, afraid to challenge stakeholders. But inside, there was a spark of passion about the product. Viktor helped him uncover it using a simple tool: the product vision canvas. They sat down together and put his thoughts on paper. Once the vision was written, the product owner started thinking about the next step on his own: "What if I show this to stakeholders? What if I tell them there's a better way?" The product vision canvas became the bridge from learned helplessness to ownership.   Self-reflection Question: Is your product owner telling themselves "I'm not allowed to" when they actually could do more? What's the smallest experiment you could run together to test that assumption?   [The Scrum Master Toolbox Podcast Recommends]

Viktor Glinka: Why Context Is King for Scrum Master Success — Building Capabilities That Drive Business Goals Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Product management skills are crucial for Scrum Masters. Once you understand how retention impacts your return on investment, you will be able to coach your product owner." - Viktor Glinka   Viktor offers a nuanced perspective on Scrum Master success by distinguishing between short-term and long-term success. On the long-term side, he argues that the purpose of a Scrum Master extends beyond working with teams — it's about helping improve the system as a whole. To do that, you need to connect your contribution to the product's success by helping build specific capabilities. Viktor grounds this in practical terms: start by asking what the business goal of your company is, and check whether people around you actually know it. Never assume everyone does. That simple act of curiosity gives you the information you need to figure out how to contribute. In his experience, the key capability his teams needed to develop was multi-learning — the ability to work across components — and that directly served the business goal. Viktor makes a strong case that Scrum Masters need product management skills. Understanding how metrics like retention impact long-term success allows you to coach product owners and analyze product dynamics. His practical advice: if you're not experienced in this, go shadow your product owner, spend time with the sales department, and look through customer support tickets. You'll understand far more about the system than staying at the development organization level.   Self-reflection Question: Can you clearly explain how your work as a Scrum Master contributes to your product's success? What specific capability are you helping the system build right now? Featured Retrospective Format for the Week: Data-Driven Discussions with Actionable Outcomes Viktor's approach to retrospectives is refreshingly pragmatic: it depends on the team. For teams not yet used to actionable improvements, he starts simple — review previous retro decisions, ensure new concrete ones are created, and bring data as food for thought. He particularly likes using the cumulative flow diagram and time distribution histogram to help teams reflect on consistency in delivery. One team he worked with adopted this as a natural habit over time. For mature teams, format matters less — one team ran a simple "good, bad, to improve" retro in 30 minutes on their own, without a Scrum Master, and it was one of the most engaged and effective retrospectives Viktor had ever seen. He also values the free-talk format when first meeting a new team, coming in with genuine curiosity and no biases. And when something clearly went wrong — an incident, a failure — Viktor drops whatever format he had prepared. "In those moments, it's important to trust your instinct, read the room, sense the tension, and step into the danger directly."   [The Scrum Master Toolbox Podcast Recommends]

Viktor Glinka: From Component Teams to Cross-Functional Teams — How to Navigate the Hardest Agile Transformation Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Our customers do not buy our components. They use the product as a whole. And when it comes to integration, the real problem pops up." - Viktor Glinka   Viktor brings a challenge many Scrum Masters face: transitioning from component teams to cross-component, cross-functional teams in a large-scale Scrum setup. Picture 8 to 10 teams, each owning their own part of the system, never touching anything else — and the company stuck in delivery for months. The premise behind component teams sounds logical: specialization leads to speed. But as Viktor explains, that speed is local — optimized for the component, not the product. When integration time arrives, responsibility gaps appear, rework multiplies, and teams start identifying with their components rather than the product. "We're the billing team — we don't deal with anything else." When they reorganized into cross-functional teams, the complaints were immediate: "I was really productive before, and now I can't finish anything." Viktor and his fellow Scrum Masters took a two-pronged approach. First, they secured time credit from leadership — a couple of months where learning was prioritized over deadlines. They ran mob programming sessions, coached teams, and removed impediments. Second, they shifted focus from outputs to outcomes, organizing customer interviews that helped developers understand what users actually needed. The development director reinforced this by joining refinement sessions, telling teams: "You might not develop anything if it still satisfies the customer need." The result was a shift from transactional stakeholder relationships to genuine cooperation, and teams that began to see beyond their component boundaries.   Self-reflection Question: If your teams are organized around components, what would it take to run one experiment — just one sprint — where a team picks up work outside their usual component? What would you need to make that safe?   [The Scrum Master Toolbox Podcast Recommends]

Viktor Glinka: When Passion Becomes the Problem — How Pushing for Agile Change Too Fast Creates Resistance Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "I wanted to change the organization overnight with my eagerness and passion. Instead of helping the system to evolve, I created resistance. I became the problem myself." - Viktor Glinka   Viktor shares one of the most honest failure stories we've heard on the show. Early in his Scrum Master career, he joined a finance organization as a Scrum Master for a newly created department — his first experience in a scaled setup. Each team owned a particular part of the user journey, organized around components. After getting exposed to Large-Scale Scrum (LeSS) through a colleague, Viktor became overexcited. He started pushing for structural changes daily, telling the head of department that the current team composition was wrong and they needed cross-functional feature teams. But he was disconnected from reality. For this particular organization, even having partially cross-functional teams was already a big stretch. Worse, the head of department wasn't even authorized to make the changes Viktor was pushing for. Instead of helping the system evolve, he created resistance. What proved his approach wrong? That same department later received a European Award for being the best mortgage department. It took Viktor a few more years and similar cases to fully absorb the lesson: read the room, develop sensitivity to the system's pace, and stimulate reflection in decision makers rather than pushing your own agenda.   In this episode, we refer to organizational development, LeSS (Large-Scale Scrum), and systems analysis. Viktor also mentions the interview with Bas Vodde on the Scrum Master Toolbox Podcast.   Self-reflection Question: When was the last time you pushed for a change because you believed it was right, without checking whether the system was ready for it? What would happen if you started by asking decision makers what they think would be a good next step?   [The Scrum Master Toolbox Podcast Recommends]

Efe Gümüs: The People-Pleasing Product Owner and the PO Who Understood User Value — Two Sides of Product Ownership In this episode, we refer to the SPIDR slicing method. The Great Product Owner: The PO Who Understood User Value 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 your product owner can phrase what the user wants to do — not what the button should look like — it is going to be a night and day difference." - Efe Gümüs   Efe describes the great product owner as someone who creates focus and a clear product vision, so the team knows what they're building and why. The foundation is simple but powerful: describe what the user will be able to do, not what the interface should look like. Instead of specifying a red subscribe button with exact text in three languages, say "as a user, I want to subscribe to my favorite channel." That shift unlocks the team's ability to contribute design insights, architecture decisions, and user journey thinking — the kind of expertise no product owner could anticipate alone. Efe highlights the SPIDR slicing method as one of his favorite tools for breaking product backlog items into consumable pieces — by interface (iOS, Android, web), by data, by rules. When the PO frames work around user value and slices it effectively, the team delivers visible value in iterations, and sprint goals become meaningful. Without this, the team becomes a ticket delivery machine.   Self-reflection Question: When you look at your product backlog right now, are items described in terms of what users can do — or in terms of what the interface should look like? The Bad Product Owner: The People-Pleasing PO Who Says Yes to Everything 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 you are doing everything your customer says, then you are not managing your product. That's the foundation." - Efe Gümüs   Efe names people-pleasing as the worst product owner anti-pattern — the "customer is always right" mentality applied to product management. When a PO says yes to every request, the consequences cascade quickly: multiple priorities competing simultaneously, everything marked urgent, no meaningful sprint goal, constant context switching, and new items injected mid-sprint. The team loses focus entirely. Efe has seen this in startups where the CEO walks in with urgent customer requests, and in larger organizations where multiple customers each demand customizations. In both cases, the PO becomes a pass-through instead of a decision-maker. The customer might be happy today, but will they be satisfied in six months when nothing is coherent? As Vasco notes, when you're serving multiple customers and saying yes to one, you're saying no to all the others — you just haven't told them yet. The result is chaos: steering blindfolded without navigational tools, trying to go everywhere at the same time. A product owner's most important skill is coherent, aligned decision-making — and that means learning to say no.   Self-reflection Question: How often does your product owner say no to stakeholder requests — and when they do say yes, is it because the request aligns with the product vision or because they want to avoid conflict?   [The Scrum Master Toolbox Podcast Recommends]

Efe Gümüs: Success as a Scrum Master Means People Feel Safe Enough to Speak Up Before It's Too Late 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 healthier your collaboration with other roles — developers, product owners, managers — the more successful as a Scrum Master you are." - Efe Gümüs   Efe defines Scrum Master success not through team velocity or timely deliveries, but through the health of relationships. A successful Scrum Master actively contributes to organizational matters, increases transparency on both problems and solutions, and bridges the gap between roles. At the team level, the signal is clear: if people feel safe enough to approach you with their problems, if they speak freely in team events without fear of blame, if they can raise risks before the last day of the sprint — that's success. But Efe is honest about how hard this is to maintain. Relationships with stakeholders have constant ups and downs, and the work of understanding people never stops. His advice starts with empathy — not just reading the room in the moment, but understanding that every colleague carries a different career history, different coping mechanisms, and different experiences that shape how they react to change. For younger Scrum Masters especially, Efe emphasizes that what worked for you won't work for everyone. Speak the common language, understand their perspective, give them assurance through visible, outcome-focused progress. The health of those relationships is the measure of your impact.   Self-reflection Question: Beyond metrics and deliverables, how would you describe the health of your relationship with the key stakeholders around your team — and what's one thing you could do this week to strengthen the weakest one? Featured Retrospective Format for the Week: The Diamond Retrospective "When you have diverse perspectives, a growth zone, converged thinking, and then action points — that diamond — people actually own the actions." - Efe Gümüs   Efe doesn't name a single retrospective format as his favorite — instead, he describes the structure that makes any retrospective effective: the diamond. Start by opening up diverse perspectives (diverge), create space for exploration and growth (the growth zone), then converge the thinking toward clear action points. This diamond pattern — diverge, explore, converge, act — ensures that the team moves from broad reflection to specific, owned commitments. The key word is "owned": when people arrive at actions through this structured exploration rather than being told what to improve, they commit to the follow-through. Efe connects this directly to his broader philosophy: the best systems don't depend on any single person, and the best retrospectives produce actions that the team drives forward without needing the Scrum Master to push.   [The Scrum Master Toolbox Podcast Recommends]

Efe Gümüs: Why Enforcing a Framework on Your Organization Will Never Be a Real Agile Transformation Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Honor the wisdom of the group — they are more wise than any management, than any agile coach, because they are in the whole process themselves." - Efe Gümüs   Efe brings a challenge he's seen repeated across every company he's worked with: transformation itself. Organizations adopt the Spotify model or launch Agile DevOps transformations expecting that applying a structure will produce results. But as Efe puts it, bringing developers and operations together does not make DevOps for you. The real question most organizations skip is: what makes sense for our business, our products, our clients, our architecture? The transformation that works is the one you co-create with the people doing the work, not the one imposed from above. Efe points out that traditional management needs numbers and progress reports — and when transformations can't deliver those in familiar formats, managers feel uneasy. His approach: include managers in the transformation activities so they see the small gears of execution firsthand. When they experience the complexity directly, they stop expecting a webinar to change behavior. The key insight is the difference between telling people and people realizing it themselves — self-discovery always generates higher buy-in than directives. Set the direction, let people own the path, and build a system that functions without single-person dependencies.   In this episode, we refer to the Spotify model.   Self-reflection Question: In the last transformation you were part of, was it designed as something done with the organization or to the organization — and what would you change if you could do it again?   [The Scrum Master Toolbox Podcast Recommends]

Efe Gümüs: When Daily Stand-ups Become Status Updates — The Warning Signs of a Team Falling Apart Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "When people start creating their own bubble inside the team, it's because they either don't feel safe, or they don't feel relevant to what the rest of the team is doing." - Efe Gümüs   Efe shares the story of an integration team — back-end and front-end developers working across legacy components, a monolithic environment, and a microservices transformation all at once. With so many different workstreams, team members ended up with their own individual projects. The daily stand-up became a status update: people shared what they were doing, but nobody was listening because nobody else's work affected them. The daily grew from 15 minutes to 30, sometimes an hour, morphing into an unplanned refinement session. Participation dropped — some stopped showing up, others attended but went silent. The team that had once been interactive and collaborative splintered into silos. Informal conversations disappeared entirely, and that was when Efe knew it was too late to make small fixes. Without trust, without a common goal, they were no longer a team — just a group of people sitting together. Then COVID hit, and remote work removed the last chance for accidental collaboration. The daily meeting, Efe realized, is your best radar for team health: pay attention to the energy, the interaction, the engagement — and you'll see the deeper dynamics before they become irreversible.   Self-reflection Question: How engaged is your team during the daily stand-up right now — and does the level of interaction tell you something about how connected they feel to each other's work? Featured Book of the Week: Psycho-Cybernetics by Maxwell Maltz "The book is all about building success mechanisms inside your own mind. If you can set your life goal, then it's way easier for you to set your career goal, your team goal, your sprint goal." - Efe Gümüs   Efe's most influential book isn't about Agile at all — it's Psycho-Cybernetics by Maxwell Maltz, a psychology book about building success mechanisms in your mind. Recommended by a fellow agile coach, the book helped Efe see the parallels between personal goal-setting and the iterative progress at the heart of Scrum. When you feel lost or stagnating, the exercises in the book help you create small pieces of progress — not quick wins, but genuine forward movement that builds momentum. Efe connects this directly to Agile: every event, every sprint, every review is a small achievement toward the next one. If you can set a clear life goal, setting a sprint goal becomes natural. The clarity of purpose unlocks action — and that's as true for individuals as it is for teams.   [The Scrum Master Toolbox Podcast Recommends]

The Sprint That Never DeliveredThree sprints in a row. Less than half of what the team committed — delivered.As a Scrum Master, that's the kind of pattern that keeps you up at night. Not because of the numbers themselves, but because of what comes next: the questions from management, the looks in the retrospective, the slow erosion of the team's belief in themselves.This was Team A. And they were trying. That much was clear.How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

Efe Gümüs: The Hidden Cost of Splitting the Scrum Master Role — And Why Stance Changes Make or Break Your Impact Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "The biggest problem when I reflect on it now is the stance changes, because as Scrum Masters, we have to establish our impartiality when we are facilitating and when we are coaching." - Efe Gümüs   Efe started his career as a network operation automation engineer, fresh out of an electrical and electronics engineering degree. When his manager asked him to take on a part-time Scrum Master role alongside his developer duties, the challenge of switching between those two stances became immediately real. As a developer, your mind focuses on solving problems. As a Scrum Master, your job is to help teams own the solution — not solve it yourself. That split led Efe to a bigger realization about scope and boundaries. When he stepped too far into the Scrum Master role, he created an unintended authority dynamic. When he stepped too far back, he became invisible. The turning point came when he stopped an alignment call that wasn't working — the information was flowing one way, and the Scrum Masters didn't feel like peers. By naming the problem and co-creating the session format, he found the middle ground: describe your expectations, get agreement, and let people tell you where they need help. One small action from you can move a problem forward in two or three steps — but only if you know about it.   Self-reflection Question: When was the last time you paused a meeting that wasn't working and explicitly renegotiated how the group would interact — and what held you back from doing it sooner?   [The Scrum Master Toolbox Podcast Recommends]

Nate Amidon: The Leadership Void — What Happens When Product Owners Forget They're Part of the Scrum Team In this episode, we refer to Nate's previous BONUS episode on the brief-execute-debrief cycle and alignment. The Great Product Owner: The Team Player Who Leads From the Trenches 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 product owners are really part of the team. They attend all the ceremonies, they give their daily stand-up status, they're shoulder-to-shoulder in the trenches." - Nate Amidon   For Nate, the best product owners he's worked with share one defining trait: they act like teammates, not managers. They show up to daily stand-ups and report on what they worked on, what they completed, and what they're blocked on — just like everyone else. They listen to ideas from the team without being dismissive, recognizing that engineers often know the user just as well as they do. They don't treat the product owner role as a position of authority over the team, but as a different function within the same unit. Nate draws from his military background: leadership is "care and feeding of the people." When product owners internalize that the team's success is their success — when they feel genuine allegiance to the people they work with — backlogs get better organized, priorities become clearer, and collaboration happens naturally. As Vasco adds, alignment is the real purpose behind Scrum ceremonies, and when POs are there, alignment follows.   Self-reflection Question: As a product owner, do your team members see you as someone who is part of the team — or as someone the team works for? The Bad Product Owner: The Leadership Void That Creates Corporate Game of Thrones 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 eventually becomes a leadership void on the team that someone will step up and fill — and usually it's an engineer, or the Scrum Master becomes a quasi-product owner." - Nate Amidon   Nate views the product owner role as fundamentally a leadership position — leadership of the backlog, prioritization, and the connection between business needs and team execution. When a PO doesn't embrace that responsibility, the symptoms are predictable: throwing half-baked stories over the fence with a "just figure it out" attitude, constantly shifting priorities without considering the downstream impact on a team that just spent two weeks building something, and being absent from the daily conversations that keep everyone aligned. What follows is what Nate calls a "leadership void" — someone else on the team, often an engineer or the Scrum Master, steps in as a quasi-product owner because the work still needs direction. Meanwhile, without a PO acting as a filter, stakeholders start shoulder-tapping the team directly, competing directors play corporate Game of Thrones over whose priorities win, and the team gets whiplashed between conflicting demands. The biggest red flag? When you hear the team say: "We just did what you told us."   Self-reflection Question: If your product owner disappeared for two weeks, would anyone on the team notice a gap in leadership and direction — or has someone already quietly stepped in to fill that void?   [The Scrum Master Toolbox Podcast Recommends]

Nate Amidon: Why Scrum Master Success Means Owning the Entire Idea-to-Deployed Pipeline Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Success for a Scrum Master is maximizing value of the product through the organization. That's a full stop statement." - Nate Amidon   Running a company of contract Scrum Masters gives Nate a unique perspective on what success actually looks like. For him, it comes down to one thing: are you increasing the value of the product through the system? Everything else is either a leading or lagging indicator. Practically, this means starting with the most fundamental question: why does your team exist? Nate suggests asking three team members separately what the team does and who they do it for — and checking whether the answers match. Once you have clarity on purpose, you can work with product and the organization to figure out how to measure whether you're getting closer. But here's where Nate pushes boundaries: he believes a Scrum Master's scope isn't limited to the Scrum team. If success is measured by value flowing through the system, then you have to take ownership of the entire idea-to-deployed pipeline — product prioritization, cross-team dependencies, QA processes, CI/CD, release schedules. You happen to work as a Scrum Master on a team, but your responsibility extends to anywhere value gets stuck.   In this episode, we refer to Vasco's OTOG (One Team, One Goal) principle and Nate's previous episode about the brief-execute-debrief cycle.   Self-reflection Question: If someone asked three different members of your team what the team exists to do and who they do it for, would the answers match — and have you checked recently? Featured Retrospective Format for the Week: Meme Retro Nate's favorite retrospective format might surprise you: the Meme Retro. Give everyone 5-10 minutes to find a meme on the internet that describes the last sprint. Then go around the room, share the meme, and explain why you chose it. It sounds lighthearted — and it is — but that's exactly the point. As Vasco notes, "laughs per minute" is a great metric for retros, because when people are laughing, they can talk about serious issues without defensiveness. The memes give a different angle on what happened during the sprint, surfacing deeper feelings and patterns that traditional formats might miss. It's especially useful when teams are getting fatigued from running the same retro format over and over.   [The Scrum Master Toolbox Podcast Recommends]

The Unglamorous Truth About Building Trust I spent my first few months as a Scrum Master chasing the wrong thing. I thought trust was something you earned with one big moment. Deliver a miracle sprint. Shield the team from an impossible deadline. Stand up to that one difficult stakeholder in a meeting. I was waiting for my chance to be heroic.How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

Nate Amidon: When the Blame Game Between Product and Engineering Destroys Your Scrum Team From the Inside Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Product and engineering are in the same boat. We need to visualize and internalize that it's one team, one fight." - Nate Amidon   Nate was working as a Scrum Master on a full-stack team building an internal mobile application when he noticed tension forming between product and engineering. It started small — finger-pointing about missed requirements — but quickly escalated into a full-blown blame game. The QA started siding with product, creating a product-and-QA-versus-engineers dynamic. Engineers began refusing user stories unless they were "100% baked" with every detail spelled out, turning the team into lawyers negotiating contracts rather than collaborators building software. What's revealing about this pattern is what it looks like from the outside: a project manager might see meticulously detailed user stories and think the team is doing great work. In reality, it's a symptom of broken trust. Nate points out that in high-performing teams, you actually see less detail in the issue tracker — because people are talking, aligned, and adapting together in real time. His approach? He drew stick figures in a boat on sticky notes — one labeled PO, the other Engineering — and stuck them on people's monitors. Simple, visual, and direct: you're in the same boat.   Self-reflection Question: What are the smells you're noticing in your team's interactions — and could overly detailed user stories actually be masking a deeper trust problem between product and engineering? Featured Book of the Week: Deep Work by Cal Newport Nate recommends every Scrum Master read Deep Work, and here's why: "Shoulder taps are expensive. If you go and bother an engineer that's in the zone, in deep work, you're adding about a 15-minute reset for them to get back into that zone." For Nate, safeguarding engineers' time is one of the most important things a Scrum Master can do. He also recommends Project to Product by Mik Kersten for Scrum Masters moving into Agile coaching — especially its emphasis on team structure and why "the team needs to be sacrosanct, and work should go to teams."   [The Scrum Master Toolbox Podcast Recommends]

Nate Amidon: When Overconfidence Breaks the Trust You Worked So Hard to Build 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 had built up the trust quotient, but then I didn't think about continually maintaining it." - Nate Amidon   Nate had done everything right. As a junior Scrum Master on an internal software team, he started by building trust — showing up, listening, and letting the team know he wasn't going to make things worse. He even managed to shift their reporting metrics from velocity to predictability, a move the team embraced because it focused on what they could actually control: how well they broke down and executed their plan. But then came the overconfidence. Riding on the capital he'd built, Nate proactively designed a "sprint churn" metric to track how much work swapped in and out of a sprint. The idea wasn't bad — but he rolled it out without consulting the team first. The pushback hit hard. Engineers pushed back: adding more work mid-sprint shouldn't automatically be negative, they argued. And they were right. The real failure wasn't the metric itself — it was bypassing the collaborative process that had earned him trust in the first place. Nate learned that trust isn't something you build once and bank on. It's an everyday job. As he puts it, the Scrum Master's role is to help the team, not direct it — and the moment you start solving problems the team hasn't agreed exist, you're directing.   In this episode, we also refer to Nate's previous BONUS episode on the podcast, where he discussed the brief-execute-debrief cycle from military aviation.   Self-reflection Question: When was the last time you introduced a change to your team without first checking if they saw the same problem you did — and what happened to your trust quotient as a result?   [The Scrum Master Toolbox Podcast Recommends]

BONUS: Why Your Plan Is Lying to You — #NoEstimates, Throughput, and the Superstition of Project Management This episode is a cross-post from The EBFC Show, Felipe Engineer-Manriquez's podcast exploring Lean and Agile in construction. In this conversation, Felipe interviews Vasco about the #NoEstimates movement, throughput-based planning, and why traditional project management is still stuck in the middle ages of managing creative work. The Human Side of Scrum That the Scrum Guide Doesn't Cover "When you go into a daily meeting and you start looking at the people in that room, maybe they are the exact same people that were there yesterday, but the team is totally different. Somebody might have had a bad night's sleep, somebody might have had an argument with their spouse. These are human beings. These are not machines that you can just distribute work to."   Vasco's path to agile coaching started with a realization that most practitioners eventually reach: the problems in software development aren't technological. They're about people — getting agreements, sharing information at the right time, making the collective brain of a team actually function. The Scrum Guide gives you organizing principles — how many meetings, who's in them — but it says almost nothing about the real-time feedback cycle between humans that makes or breaks a team. That's why the Scrum Master role exists: to be the lubricant for human interactions, to break down complex ideas into items the collective mind can process. It's the piece that makes Scrum work, and it's the piece that's hardest to teach. From Project Manager to #NoEstimates — The Bet That Changed Everything "The PM wanted 15 items per sprint, and the team said 'yeah, we can do 15.' I said, this is not gonna happen. The team had been delivering between five and eight items per sprint. I said, I'm gonna be positive — I'm gonna say seven. And no surprise, by the end of the sprint, they delivered seven."   Vasco started as a project manager — and not the easy certification kind. He went through IPMA, which means six months of training, a four-hour written exam, and an expert interview, just for the entry level. Planning and estimating was the job. Then he ran his first Scrum project, specifically to prove it couldn't work. By the second month, he couldn't understand how anything else could work. The team delivered something to show every single sprint — something that never happened with traditional project management. The turning point came when he made a bet with a product manager: the PM needed 15 items per sprint, the team committed to 15, but historical throughput was 5-8 items. Reality delivered seven. That moment crystallized the #NoEstimates insight: we can't fight reality, but we can choose which seven items to deliver. Reality Is a Bitch — Why Linear Predictive Planning Fails "Never believe the plan. Or as in Scarface — never get high on your own supply. It's so unbelievable how project managers still today believe their freaking plans."   At Nokia, Vasco managed a program of 500 people across 100 teams on four continents. No way to get everyone in a room. So he tracked system-level throughput — features delivered to integration per week. Six months into a twelve-month project, the data said they'd be at least six months late. He told the program manager: cut scope now. The program manager did what every PMI-trained program manager does — sent an email asking all 100 teams if they'd deliver on time. Every single team said yes. Nobody wants to be first to admit they're late. Twelve months in, they discovered they were six months late. The project got canceled. 500 people, millions of euros, all because somebody believed the plan. Linear predictive planning is useful for exploring what might be possible if nothing goes wrong. It is not reality. The only tool that reflects reality is throughput — the number of items completed per unit of time. Earned Value Management — George Orwell at His Best "It's not earned, it's spent. It's not value, it's cost. It's not management, it's just observation. Monty Python could not have come up with a better name."   Felipe shares a story that mirrors the absurdity: an industrial project with a dedicated 35-person earned value management department. Before the meeting even started, the department head announced, "Let's all acknowledge that earned value management is more an art than a science." Their charts were made up, the contractor's charts were made up, and the goal of the meeting was to agree that the project would finish on time — regardless of what any data said. This is where traditional project management ends up when it disconnects from throughput: a $30 million scope addition with zero additional time, defended by charts that a mediocre attorney can invalidate in the first week of litigation. Felipe knows — he spent a year being cross-examined by forensic schedulers whose full-time job is proving that construction schedules are fiction. One Small Experiment to Test #NoEstimates "Never convince anyone. Convince yourself. Once you're convinced, whatever other people say, it doesn't really matter because you're not gonna take them seriously anyway."   Here's how to validate throughput-based planning with your own data: take the last 10 sprints (or periods). Calculate the average throughput and control limits from the first five. Then check whether the next five sprints fall within that range. They will. If you're in software and using Jira, you already have this data. You don't need anyone's permission. You don't need to change anything. Just look at what your team actually delivers versus what they planned to deliver. The gap between those two numbers is the gap between superstition and reality. About Felipe Engineer-Manriquez Felipe Engineer-Manriquez is a best-selling author, international keynote speaker, Project Delivery Services Director at The Boldt Company, host of The EBFC Show podcast, and a proven construction change-maker implementing Lean and Agile practices on projects from millions to billions of dollars worldwide. He is a Registered Scrum Trainer™ (RST), Registered Scrum Master™ (RSM), and recipient of the Lean Construction Institute Chairman's Award. His book Construction Scrum is the first practical guide for applying Scrum in construction.   You can link with Felipe Engineer-Manriquez on LinkedIn.

Bhavin Shukla: Why Scrum Master Success Means Confronting the Ugly Truth With Data 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 not always good vibes, good environment for us as Scrum Masters. For me, it's about confronting the reality, the ugly truth, which takes the team to tougher conversations, more constructive challenges." - Bhavin Shukla   Bhavin shares a pivotal moment in his career that redefined what success means for a Scrum Master. He was working with a fantastic team — great culture, people who believed in quality, knowledge sharing, strong bonds. But sprint goals weren't being met, and stakeholders were constantly chasing the Product Owner and Scrum Master for answers. Bhavin got his hands dirty with the data: lack of clarity on work, context switching, patterns emerging. When he presented the data to the team, he was met with silence — a confronting kind of silence. The team was essentially saying, "We were happy. Why would you do this to us?" Bhavin's response was direct: going for coffees and laughing together isn't the whole job. If he wasn't showing them reality, he couldn't look at himself in the mirror. The team eventually used that data to raise their own voice, pointing out systemic issues with external vendors and organizational constraints. The data gave them a platform to speak truth — not as blame, but as discovery.   Self-reflection Question: What conversations did you avoid this week that could have unlocked progress for your team? Are you bringing data to those conversations, or relying on vibes? Featured Retrospective Format for the Week: Newspaper Headline Retrospective Bhavin shares an unconventional use of the newspaper headline technique — typically used for roadmaps and vision — as a retrospective format. The idea is simple but powerful: ask the team to write the newspaper headline they want to see about themselves. What would the story say when they succeed? By authoring their own headline, the team takes ownership of the narrative — they define what success looks like, what must go right, and what risks could derail them. "Putting them in that newspaper headline, they authored the story. They own the accountability to make it successful," Bhavin explains. He also shares a second technique for Kanban teams under pressure: a rolling two-column whiteboard — "Frustration of the Day" and "Success of the Day" — with no meetings required, just real-time data capture that becomes a continuous retrospective, reviewed every 2-3 weeks.   [The Scrum Master Toolbox Podcast Recommends]

Bhavin Shukla: The Hidden Cost of Always Saying Yes — How a Helpful Scrum Team Nearly Self-Destructed 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 was sort of making me feel as a Scrum Master, like it's a slow self-destruction mode they are in. Good intentions, but it wasn't helping them, and that's something that they were not able to notice." - Bhavin Shukla   Bhavin tells the story of a banking team that looked like every Scrum Master's dream on day one — humming, cracking jokes, in the zone. But underneath the positive energy, the data told a different story. Sprint commitments kept overflowing, tech debt was rising, P1 and P2 production issues were climbing, and decision latency was immense. The root cause? This team of genuinely helpful people couldn't say no. They wanted to help everyone who came to them, and that desire was slowly drowning them. No one was giving them feedback about the consequences — missed sprint goals were met with "that's okay, we'll do it next sprint." Bhavin introduced two simple tools: an anonymous happiness meter on the wall (rate 1-5, leave a note if below 3) and a gratitude wall. The data revealed the truth — the team was burning out, handling weekend incidents with no escalation path. Armed with this data, Bhavin coached the team on negotiation techniques: you don't have to be rude to say no, you can negotiate the yes, you can negotiate the no.   In this segment, we talk about the importance of collecting regular data to surface hidden patterns, and the anti-pattern of teams operating without feedback on the consequences of their decisions.   Self-reflection Question: Is your team's positive energy masking underlying problems? What data would help you discover whether good vibes are hiding unsustainable patterns? Featured Book of the Week: Make Work Visible by Dominica DeGrandis Bhavin recommends Make Work Visible by Dominica DeGrandis because it goes beyond values and principles to put them into practice in a grounded, system-focused way. "One clear message I get from that book is it's not the people who are the problem, it's the system that we need to work on to improve ways of working," Bhavin shares. The book introduces concepts like the five thieves of time, visualizing work, dependencies, and bottlenecks — connecting lean thinking, Kanban principles, and behavioral patterns into a practical guide for any Scrum Master looking to understand the systems their teams operate in.   [The Scrum Master Toolbox Podcast Recommends]

Bhavin Shukla: When Protecting Your Agile Team Becomes the Barrier to Their Growth 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 perception I had was safe space means insulation from creating that transparency. It was not about protecting the teams. It was actually about giving them the voice, giving them the platform." - Bhavin Shukla   Bhavin shares a story from early in his Scrum Master journey, working with two teams building a BI and regulatory platform in Australia. When he arrived, team morale was low — people buried in their screens, going for coffee alone, no healthy debates happening. His natural instinct kicked in: protect the team, help them gel, get the best out of them. But his coach asked a question that changed everything: "What's the balance between protecting the team and creating visibility and transparency?" Bhavin realized he'd been shielding the team from stakeholders, keeping ceremonies closed and conversations siloed. When the team opened up their reviews to stakeholders with clear expectations, something shifted. The backlog started changing based on real feedback, healthy tension built up, and the team started humming. The lesson was profound — creating a safe space doesn't mean insulating the team from reality. Psychological safety isn't the absence of difficult emotions; it's the freedom to have them without destructive patterns. By isolating the team, Bhavin had actually been undermining their trust and growth.   Self-reflection Question: Are you protecting your team in ways that might actually be preventing them from building the stakeholder relationships and transparency they need to grow?   [The Scrum Master Toolbox Podcast Recommends]

Iryna Stelmakh: The Almost Invisible Scrum Master, Why Team Independence Is the Ultimate 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.   "A successful Scrum Master is almost invisible — not because they don't contribute, but because the team is no longer dependent on them for every decision." — Iryna Stelmakh   Iryna offers a powerful definition of success for Scrum Masters: becoming almost invisible. Not because the Scrum Master isn't contributing, but because the system works — with or without them. The team takes ownership of delivery, solves problems collaboratively, and continuously improves its own process. Each team member can propose, vote, and suggest changes because the environment has a high level of trust.   When that happens, Iryna explains, the Scrum Master becomes more of a system observer and catalyst rather than a daily driver. As Vasco adds, this perspective is valuable because it looks beyond personal metrics — it examines behaviors across all the interactions the Scrum Master facilitates: between the team and the product owner, between the team and stakeholders during reviews, and within the team itself. The Scrum Master role sits at the nexus of many interactions, and success means those interactions work well even when you step back.   Self-reflection Question: If you were absent for a full sprint, would your team maintain the same quality of collaboration, decision-making, and delivery — or would things fall apart without you? Featured Retrospective Format for the Week: The Energy Retrospective Iryna shares her favorite retrospective format — one she calls the Energy Retrospective. Instead of the standard "what went well / what didn't" framing, it asks three questions: What gave us energy this sprint? What drained our energy? And what should we start, stop, or continue doing to keep our energy at the right level?   This approach shifts the conversation from purely technical task problems to real human dynamics. As Iryna explains, closing technical tasks and resolving issues is important, but so is the wellness of the team. The Energy Retrospective creates space for both. She also notes that retrospective format should match the team: for open, trusting teams, a straightforward format works fine. But for new teams or teams with high resistance — those still in the forming stage where the Scrum Master isn't yet a trusted figure — she uses metaphorical approaches, like asking team members to pick pictures that represent their feelings about the sprint. Even a happy, sad, or frustrated monkey picture can surface insights that direct questions might not.   [The Scrum Master Toolbox Podcast Recommends]  

The Most Underrated Advantage of Short Sprints - Mike CohnA recent Gallup survey found that 80% of employees who received meaningful feedback in the past week are engaged at work.For comparison, Gallup's overall engagement numbers are often around 30%.That's a striking gap.It suggests something many leaders overlook: performance may depend less on changing team structure and more on improving feedback inside the structure you already have.When results lag, organizations often reach for the org chart. They reorganize teams, redraw reporting lines, or debate how many teams a coach or Scrum Master should work with.Sometimes those changes help. But they rarely go far if feedback is infrequent, unclear, or missing altogether.Feedback isn't just a management technique. It's a strategic advantage.And agile teams have been building that advantage into the way they work for years. When people talk about one- or two-week sprints, they usually focus on speed. “We need to move faster.”“We need more output.”“We need shorter release cycles.”But speed isn't the real advantage of short sprints.The advantage is shortening the time between action and learning.A sprint isn't a delivery cycle. It's a feedback cycle.Each sprint gives a team a natural point to stop and ask: Did we build the right thing?Did we misunderstand the need?Are we still aligned with stakeholders?Are we learning what we hoped to learn?The shorter the sprint, the shorter the gap between assumption and validation.That's not about velocity. That's about reducing risk. Early Scrum teams often worked like this:Sprint, sprint, sprint… then release.That pattern made sense at the time in the 1990s and early 2000s. It was a huge improvement over what had come before. But it meant some feedback arrived in a big, delayed batch after the release.Over time, many teams evolved to:Sprint, release, sprint, release.And today, many modern teams have gone further still. They release whenever it makes sense—sometimes multiple times per sprint, sometimes many times per day.In other words, modern agile teams have largely decoupled sprints from releases.So if sprints aren't primarily about shipping anymore, what are they for?Sprints provide a reliable cadence for feedback and alignment—even when delivery happens continuously. Many organizations treat the Sprint Review as a demo.It's not.It's where reality gets a vote.The Sprint Review is where the team inspects what was built with the people who care about it, and adjusts course based on what they learn.When that meeting becomes optional, rushed, or performative, you don't just lose a ceremony. You lose your learning loop. And you start optimizing for finishing work instead of finishing the right work.If weekly feedback really is one of the biggest drivers of engagement and performance—as Gallup's numbers suggest—then the Sprint Review isn't overhead. It's how you reduce rework, prevent expensive surprises, and stay aligned with what actually matters. Of course, simply running one-week sprints doesn't guarantee meaningful feedback.Stakeholders can skip reviews.Teams can ignore input.The conversation can stay superficial.Short cycles create the opportunity for feedback. Leaders decide whether to use it.That's where the advantage lives.If you're running one- or two-week sprints, ask yourself:Are we using sprints as delivery deadlines—or as learning deadlines?Because the real power of agile isn't producing more every two weeks.It's learning more every two weeks.And that's a competitive advantage that will help you succeed with agileHow to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

Iryna Stelmakh: When Communication Clarity Matters More Than Technical Complexity, A Healthcare Project That Fell Apart 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.   "Communication clarity is more important than technical complexity, because if you do not understand, it's pretty hard to execute." — Iryna Stelmakh   Iryna shares one of her most painful career stories — a project in the healthcare domain focused on cancer treatment research data. When she joined, she was managing around 9 projects simultaneously and agreed to take this one on the condition that a strong technical lead would own the technical direction. The project began with a critical misunderstanding: sales had communicated that the client needed a database redesign, but the client actually needed a migration to a different database type. Similar words, fundamentally different work.   For three months, the team worked through research and discovery phases, trying to understand the actual problem. But communication gaps — compounded by language barriers between the Ukrainian development team and the US-based client — prevented them from identifying the real need in time. Iryna trusted the technical lead's reports that everything was on track. She relied instead of checking. Eventually, the client lost confidence and left. It remains the only project in her career she considers a genuine failure.   The lesson cuts deep: teams must have people who can ask the right questions early. As Vasco observes, the root cause was implicit assumptions that were never discovered or explored by the different people involved.   In this episode, we also talk about the importance of the monitoring and controlling phase in project management.   Self-reflection Question: When you trust a team member's assessment that "everything is fine," what verification steps do you take to confirm that understanding is truly shared across all stakeholders? Featured Book of the Week: Team Topologies by Matthew Skelton and Manuel Pais Iryna recommends Team Topologies by Matthew Skelton and Manuel Pais as a book that changed how she thinks about Agile leadership. "Great agile leadership is not only about frameworks, but it's about communication, influence, and the ability to align people around shared goals," she explains. The book helped her understand that Agile isn't just about team process — it's about organizational structure, team boundaries, and responsibilities. She also recommends Never Split the Difference by Chris Voss for Scrum Masters who want to sharpen their communication and influence tactics. As Iryna puts it, communication is one of the most important skills a Scrum Master must have.   [The Scrum Master Toolbox Podcast Recommends]  

Iryna Stelmakh: When "Agile" Becomes a License to Change Everything, The Cost of No Rules in Backlog Management Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "For me, it was pretty hard to explain that Agile is about cost reduction, and not about cost increasing." — Iryna Stelmakh   Iryna shares a story from one of her first projects as a Scrum Master, working with a client from Israel who saw Scrum as an open invitation to add anything to the backlog at any time. For this client, agility meant unlimited flexibility — the freedom to extend not just the product backlog but the sprint backlog, multiple times per sprint. As Vasco points out, this is a pattern many teams recognize: when there's no cost to disrupting a sprint, it becomes effortless to keep piling on work, destroying the very predictability that sprints are designed to create.   Iryna struggled to push back. It was one of her first projects, and the client was confident in his approach. But the experience taught her a lasting lesson: the collaboration with external clients must start with an agreement about how the team works. That means explaining the methodology during the pre-sale phase, documenting it in the contract, and teaching the client the benefits of the process before the work begins. As she puts it, when she checked back with the sales and engagement teams, she realized nobody had set those expectations. She relied instead of checking — and paid the price. Once she held sessions with the client to explain how Scrum works and what it delivers, things shifted. New tasks went into the product backlog and were prioritized properly through refinement, not dumped into active sprints.   Self-reflection Question: When was the last time you verified that your client or stakeholders truly understand how your team works — not just the label, but the actual rules and commitments?   [The Scrum Master Toolbox Podcast Recommends]  

BONUS: Why Every Organization Reinvents Silos—And What to Do About It Today we speak with Roland Flemm, co-creator of Org Topologies and co-author of 10X Org — Powered by Org Topologies. Roland has spent decades in the trenches—first as a developer, then in infrastructure, and finally as a Scrum Master, trainer, and organizational design consultant. In this episode, he explains why even teenagers with zero corporate experience instinctively create departmental silos, why making every team faster doesn't make the whole organization faster, and how leaders can use the Org Topologies map to see their organization as it actually is—not as the org chart says it should be. From Developer to Org Designer: Four Decades of Hitting the Same Wall "I felt many, many times the limitations of organizational structures stopping me from using my common sense to make people work together in a proper way."   Roland's career spans over 40 years, starting as a developer in 1984. After a decade writing code and another decade in infrastructure, he moved into Scrum and agile coaching. But even as a highly effective Scrum Master, he kept hitting the same ceiling: local team improvements couldn't break through organizational boundaries. You could have wins with your team, but the moment you needed multiple teams to work together, someone higher up would shut it down. That frustration led him to Large-Scale Scrum (LeSS) by Bas Vodde and Craig Larman, which offered a more educated approach to multi-team collaboration—and eventually to co-creating Org Topologies as a way to help leaders see and change the structures that block real collaboration. Bas has been on the podcast to share his view on scaling Scrum with LeSS, listen to his episode here. The Hydrogen Car That Built Its Own Silos "If you don't think about your org design—the way that you want to collaborate—then something like this happens."   One of the most striking stories in Roland's book comes from the Technical University of Delft, where student engineers were thrown together to build a hydrogen racing car. These were teenagers—no corporate experience, no boss who'd worked in a traditional company. And within weeks, they'd organized themselves into departmental silos, each sticking to their specialty. The mechanical engineers stayed on their turf, the electrical engineers on theirs. It was automatic. Roland traces this instinct deep: from school, where you choose a specialty; from the army and the church, where hierarchy is the default; from society itself, where "you're a plumber, so then we know what you are." The pattern of drawing boundaries and appointing leads when faced with complexity isn't corporate culture—it's human nature. And the problem isn't that it exists. The problem is that we don't know there are alternatives. The Ferrari Effect: Why Local Speed Creates Global Congestion "It's not that people choose to do fewer things. They just push more into the system because it can handle it. And that's where things go wrong."   Roland uses a vivid analogy from the book: swapping every car on the road for a Ferrari doesn't fix traffic congestion. The same principle applies in organizations. Everyone feels faster individually—teams are delivering, sprints are moving—but the whole isn't getting better. The HealthCare.gov story makes the case dramatically: 55 vendor firms, $1.7 billion in spending, and on launch day, six people successfully enrolled. Then a ten-person cross-functional team fixed it in six weeks. Roland sees this pattern repeat in banks that adopt delivery-oriented structures like SAFe: they create value streams, but because they don't make hard choices about what not to do, the freed-up coordination capacity immediately fills with new demands. The congestion returns, just at a different level. In this segment, we talk about the Cynefin Framework.  Three Topologies: Resource, Delivery, and Adaptive "The third topology is interesting—that's where the hands and the heads are merged. They're no longer separated."   Roland walks through the Org Topologies map, each suited to different contexts:   Resource Topology — The "hands" are separated from the "heads." Coordinators design and direct; specialists execute narrow, deep tasks. This works in environments with low variability and deep technical expertise—think ASML's university-level hardware engineers, or a bank's core transaction processing team running COBOL. The focus is on utilization of expensive specialists.   Delivery Topology — Still has coordination overhead, but teams are cross-functional and can handle more complex problems end to end. A team owns the customer page and does design, testing, and deployment. This model favors speed of delivery, but breaks down when new work doesn't fit neatly onto existing value streams—like needing a retention initiative when no retention team exists. Work falls through the cracks.   Adaptive Topology — The hands and heads merge. People who coordinate can also do the work, and they self-organize around problems as they emerge. It's like a startup—"four guys and a dog in a garage"—but with hundreds of people. This model thrives in high-variability, high-learning environments where the investment in cross-training pays off because the challenges keep changing.   The key insight: none of these is "better." It's about fit for purpose. A single organization—like a large bank—might need all three topologies operating simultaneously in different parts of the business. The MADE Loop: Map, Assess, Design, Elevate "First, we all agree that the system that we're looking at is really the system that we're looking at. And then we can start talking about how to improve."   Rather than the typical transformation playbook—hire consultants, roll out a framework, hope for the best—Roland advocates for the MADE loop: Map the reality of how work actually flows (not what the org chart says), Assess whether that structure is fit for the strategic purpose, Design targeted improvements using the Org Topologies map, and Elevate through small experiments. Maybe two teams temporarily share members. Maybe one person switches team membership for a sprint. The changes are gradual, measurable, and reversible. Roland is emphatic about one principle from the book: "Own, Not Rent." Real structural change can't be outsourced to a consulting firm. Leaders have to see the system themselves—go to where the work happens, understand the flow, and make informed choices about what to change. AI Is About to Reshape the Map "As AI comes, you might want to get at least a part of that work transferred lower in the organization to more execution-oriented teams, because they can now use resources like AI to make proper decisions."   Roland makes a forward-looking point about how AI will shift the boundaries between topologies. Work that required deep specialist silos—like legal review or compliance decisions—may soon be handleable by cross-functional teams using AI tools. This means the threshold for when an adaptive or delivery topology makes sense will shift. Organizations that understand their current topology will be better positioned to adapt; those that don't will find their structures obsolete without understanding why.   About Roland Flemm   Roland Flemm is co-creator of Org Topologies and co-author of 10X Org — Powered by Org Topologies (2026) — a framework and book about elevating organizational performance through people-centered, strategy-driven redesign. He works with leaders in scale-ups and enterprises across Europe, helping them see how their org structure shapes — or blocks — their ability to learn, adapt, and deliver.   You can link with Roland Flemm on LinkedIn. Learn more about Roland's work at 10xorg and https://www.orgtopologies.com

"The key is not to prioritise what's on your schedule, but to schedule your priorities."  Ah, Stephen Covey got it right. If you don't know what your priorities are, whatever's on your calendar will be prioritised, which often means low-value meetings and other people's urgencies. Not a great way to work if you want to be more productive and better at managing your time.  This week, we're looking at identifying your core work and eliminating the non-essential.  Links: Email Me | Twitter | Facebook | Website | Linkedin The Hybrid Productivity Course  Get Your Copy Of Your Time, Your Way: Time Well Managed, Life Well Lived The Working With… Weekly Newsletter Carl Pullein Learning Centre Carl's YouTube Channel Carl Pullein Coaching Programmes Subscribe to my Substack  The Working With… Podcast Previous episodes page Script | 408 Hello, and welcome to episode 408 of the Your Time, Your Way Podcast. A podcast to answer all your questions about productivity, time management, self-development, and goal planning. My name is Carl Pullein, and I am your host of this show.  Something that came up in last weekend's Ultimate Productivity Workshop was around identifying your core work. The work you are employed to do or what you do to put food on your table.  In the past, this was easy to do. Job descriptions were simple, and job titles included things like salesperson, accountant, lawyer, administrator, receptionist, lifeguard, and office manager. It was very clear what your responsibilities were, and defining your core work was simple.  Today, hmmm, something's gone disastrously wrong. Now we have job titles such as Empathy Engineer (a software designer), Scrum Master (a project manager of sorts from the twenty-teens Agile trend) or Digital Overlord (a website or systems manager). These are unclear and ill-defined, and figuring out what these jobs entail is challenging, to say the least, but not impossible with some thought.  Then there are jobs such as the “C” roles: CEO, CFO, COO, etc. These are notoriously difficult to define because they are intentionally vague and depend on the company's size, its goals and often the state of the company when a person starts the role.  When Tim Cook took over from Steve Jobs in 2011, he took over a company on the up. When Satya Nadalla took over Microsoft, Microsoft was struggling in the rapidly growing mobile market. Same job titles, but entirely different roles given the state each company was in when they took over. In today's episode, we're looking at core work and, more importantly, how to define your role so you can pull out the tasks you need to do consistently to perform well and make it easier to prioritise the things important to you.  So, without further ado, let me hand you over to the Mystery Podcast Voice for this week's question.  This week's question comes from Chris. Chris asks, hi Carl, I am really struggling to define my core work. I am a sales manager in a medium-sized car dealership. I manage a team of 12 salespeople, and I report directly to the General Manager. The part I am struggling with is what my tasks should be each week. Could you help? Hi Chris, thank you for your question.  For those of you unfamiliar with the concept of core work, your core work is the work you are employed to do. It's how you are evaluated and the reason you were employed. The issue with core work is that over time, the scope of your work can expand to a point where you have so many competing priorities that it becomes practically impossible to decide what needs your attention. And that's when backlogs of important work start to grow uncontrollably.  This can be caused by our innate human need to please people, so we say “yes” to too many things without considering whether we have the time to do the work we ‘volunteered' to do.  The problem here is that once you have said yes to the work outside your core work, you own it. It is now your responsibility to get the job done. Do this too often, and the line between what you are responsible for and what you volunteered to do becomes blurred.  A few years ago, I worked with a client who was a product manager in a pharmaceutical company. Her core work was to ensure that her product's labelling, literature, and local branding were accurate and up to date. She was also responsible for three sales campaigns each year.  Unfortunately, Sam was a people pleaser. She couldn't say no to anyone. She volunteered to be on the Annual kick-off event committee (each year the company had an off-site retreat to motivate the team for the new year), she volunteered to be the lead of a breast cancer awareness campaign her company wanted to run, and if a sales manager asked her to do a presentation to their sales people, she'd always say yes.  But her people pleasing was not confined to her professional life. She volunteered to help organise events at her church, committed to watching her husband play football every weekend and would help her friends out at the drop of a hat.  When I began working with Sam, she was a mess. Her weight had ballooned because she had no time for any physical movement or to watch what she ate; she wasn't able to sleep properly, and she was suffering quite badly from eczema, brought on by stress and a lack of sleep.  The first thing I did was get Sam to write down her original core work. I remember her having to pull out her job description to remind her what that was.  When she looked at it, she began to cry. She confessed that what she did at work was nothing like what was written on those sheets of paper.  So that's where we started.  I also got her to talk to her boss about stepping down from all the volunteer roles she'd accepted so she could focus on the work she was employed to do.  Her boss was brilliant. She helped Sam remove herself from the volunteer roles so she could focus on what mattered.  Within six months, Sam's product was the top-selling product in the company. She'd lost 20 pounds in weight, she was sleeping well, and her eczema had all but disappeared.  She was focused on what mattered and did that brilliantly. So much so that she was promoted after a further year.  I tell that story because it demonstrates why defining your core work is so important. If you are not clear about what you are employed to do, in an effort to look busy and not upset anyone, you will keep accepting more and more roles outside the scope of the job you were employed to do.  This does not mean that you should never accept voluntary roles or help out your colleagues from time to time. It means you should never lose sight of what you are employed to do. And to do that, you first need to identify what it is, then take it to the next level.  That level identifies what doing your core work looks like at the task level. In other words, what do you actually do to perform your core work? So, returning to your role, Chris, as a sales manager, a part of your role will be to support your sales team. What does that look like at a doing level? Does that mean you need to schedule weekly one-to-ones with your team? Maybe you are also responsible for ensuring that the sales data is correct and up to date.  Scheduling weekly one-to-ones is relatively straightforward. You may choose to dedicate a day to doing this, so your focus is on supporting your team and, in doing so, removing a weekly decision.  For example, if you choose to hold your meetings on Mondays, you can block your calendar on those days and get them all done in one day.  Maintaining your sales admin may involve 30 minutes a day of updating your company's internal reporting system. If so, when will you do that?  You may also be responsible for the training of your team. I know many managers are. If so, what does that involve, and what do you need to do personally to ensure it happens?  So what you are doing is looking at the type of work you do and then asking yourself what that looks like at a doing level.  Many medical doctors I speak with tell me their work is more than just seeing patients. Some of their additional roles include renewing prescriptions, completing insurance claims, and sorting out referrals to specialists.  This means being a general practitioner is not as simple as walking into their clinic, going to their office and examining patients all day. They need to find time to do the additional work, which is often an extra 2 hours or more each day.  Once you have identified your core work and pulled out what that looks like at the task level, the next step is to calculate how much time you will need to complete those tasks each week.  In theory, this is easy. After all, if you have done something before, you should be able to figure out how long it will take you to do the same task in the future.  Hahaha, not so easy. We are not machines, and some days we are not at our best. We might be tired, distracted or feeling ill.  And those distractions may not even be of our own choosing. Other people interrupt you, ask you questions, or you are prevented from doing one of your critical tasks because a colleague has not given you the information you need.  I remember talking with a gentleman who ran a car servicing business, and he told me that the biggest issue he had each day was something called “back orders”. This is where a part for a customer's car was out of stock and on order.  Nobody knew when the part would be back in stock, so they could not tell the customer when to bring their car in for the repair, or, worse, the customer could not come in to pick up their repaired car.  In these situations, all you can do is work on the averages.  I've been writing a weekly blog post of around 1,000 words each week for over ten years. You would have thought I would know how long writing a blog post would take by now, after doing it over 500 times. Not a chance.  Some weeks it can take me forty minutes; other weeks, as much as two hours, to write the first draft.  It's the same for these podcasts. This week's episode is number 408, which means I've written 407 scripts, and yet some weeks it takes two hours; others, four. And the worst thing is, I have no idea when I sit down to write the script how long it will take.  In these situations, all you can do is work on averages. I allow two hours for writing these scripts. Most weeks, I can do it in that time; other weeks, I need to find additional time later in the week to finish them.  Same with my blog posts. I have two hours each week protected for writing the posts. Most weeks, I finish well within that time; other weeks, I need the whole time.  I'm working on averages, which ensures the bulk of what needs to be done gets done every week.  And this brings us to the main reason for identifying your core work:  Once you know what your core work is and what you need to do at a task level, you know how much time you need to protect for this work each week. That information alone will tell you how many meetings and voluntary work you can accept each week.  Not knowing what your core work looks like at a task level risks putting yourself in Sam's shoes. And if Sam were here with me, I know she'd be telling you never to let that happen to you. It destroys your health and leaves you feeling rotten every day.  There you go, Chris. Thank you for your question, and thank you to all of you who attended the Ultimate Productivity Workshop over the last two weeks. It's always a joy to help you, and it helps me see where you are struggling with productivity and time management.  Thank you for listening, and it's time for me now to wish you all a very, very productive week.   

Junaid Shaikh: How Scrum Masters Can Measure Their Own Impact, Practical Self-Assessment Metrics Junaid's favorite retrospective format? The vanilla: what went well, what could have gone better, what to do better next. He's tried many formats — the Three L's (liked, learned, lacked), the Three Little Pigs, the sailboat — but the core principle is always the same. His practical advice: stick with a consistent format so the team gets better at the process itself rather than constantly adjusting to new concepts. One addition he insists on for any format: an appreciation component. In the rush to analyze processes and outcomes, teams often skip acknowledging how another team member, PO, or Scrum Master helped during the sprint. That appreciation builds trust, respect, and openness that feeds into subsequent sprints. On defining success as a Scrum Master, Junaid starts with a Peter Drucker quote: "You cannot improve something you cannot measure." He proposes several practical self-assessment metrics: First, the Agile Team Maturity Index — a spider graph that shows where the team stands across multiple criteria, making gaps visible and actionable. Second, track retrospective action items. Create tiger teams for specific issues, run small iterative experiments, and measure in the next retrospective whether the trend is improving. Third, watch for shared sprint goals. Junaid once saw a team with nine sprint goals for a two-week sprint — those weren't goals, they were individual tasks. A real sprint goal should be something multiple team members work together to achieve. Fourth, self-organizing teams. If the team falls apart when the Scrum Master is absent for a sprint, there's a problem. Coach teams to self-organize, and their ability to function independently becomes a success metric. Fifth, communication patterns. Too many emails flying around can signal hidden conflicts or trust barriers. If communication happens through the right channels — dailies, direct interactions — you're likely in good shape. Sixth, Scrum event health. If events get canceled too frequently, the team may be reverting to traditional ways of working. [The Scrum Master Toolbox Podcast Recommends]

Junaid Shaikh: Managing Uncertainty As A Scrum Master, How Scrum's Rhythm Creates Stability In Unstable Times For this week's coaching conversation, Junaid brings a challenge that resonates well beyond any single team: dealing with uncertainty. He references the World Uncertainty Index report from February 2026, which showed the highest levels of global uncertainty ever recorded — surpassing both the COVID pandemic and the 2008 financial crisis. This uncertainty doesn't stay at the geopolitical level. It seeps into teams. People show up stressed, unsure about what the next month or three months will bring. As Scrum Masters, we need to be cognizant of where our team members are coming from. Vasco adds an important layer: uncertainty operates at multiple levels within organizations. A colleague you depend on might be out sick for two weeks. A supplier might not deliver on time. Every dependency is a source of uncertainty. The question becomes: what in our processes is designed to accept and adapt to that uncertainty? Junaid's answer is powerful in its simplicity: Scrum's rhythm. The sprint, the planning, the daily, the retrospective — these events at a defined cadence create internal predictability. "When you have a rhythm, when you have a known sequence of events in front of you, that takes away a lot of uncertainty." Vasco builds on this: Scrum creates a boundary — the sprint — that accepts uncertainty outside while reducing it inside. Internal versus external predictability. Inside the sprint, the team can fail in small ways without exposing every failure to the outside. Compare that with traditional project planning, where every task on the critical path has external visibility and impact. For practical tools, Junaid shares how he used the Eisenhower matrix with a team to convert uncertainty into actionable priorities. They listed all activities from recent sprints, plotted them on the matrix, and found they could delegate or deprioritize 20-25% of their work. That freed them to focus with certainty on the remaining 75%. Combined with timeboxing as an uncertainty management mechanism, teams can create pockets of predictability even in turbulent times. [The Scrum Master Toolbox Podcast Recommends]

Junaid Shaikh: Why Teams Go Through The Motions of Agile Without Being Agile, And What To Do About It Junaid's book recommendation is The Culture Map by Erin Meyer. As a Scrum Master working at companies like Ericsson and ABB — organizations that are a "United Nations" of cultures — understanding cultural tendencies has been essential. But Junaid goes further: you can customize the Culture Map framework even within a team of people from the same country, using the parameters to map different personalities. It's about how you use the tool, not just where people come from. He also recommends Scrum Mastery: From Good to Great Servant Leadership by Geoff Watts for practical advice on the servant leadership role, and regularly visits Scrum Alliance and Scrum.org for real-world insights from the community. On the topic of teams that self-destruct, Junaid paints a picture that many listeners will recognize. He picked up a team's retrospective history and cumulative flow diagrams and found problems at every level: managers who declared "from tomorrow we're going agile" without understanding what that meant, then started comparing velocity across teams. Product owners who took PO training but reverted to command-and-control project management. A previous Scrum Master doing what Junaid calls "zombie Scrum" — implementing the framework mechanically without understanding its purpose. The pattern underneath it all: people enveloping their traditional mindset under an agile umbrella. The ceremonies happen, the daily standups run, but nobody is questioning why they're doing any of it. As Vasco observes, this zombie pattern isn't limited to Scrum — it happens with code reviews, architecture reviews, any process that gets adopted without critical thinking about its purpose. Junaid's insight: if you don't understand the basics with the right mindset, every event feels like overhead. Teams complain about "too many meetings" because they're running agile ceremonies on top of their old informal processes. "If you don't get out of your previous shell, you cannot get into a new shell." [The Scrum Master Toolbox Podcast Recommends]

Junaid Shaikh: The Eager Scrum Master Trap, Why Proposing Solutions Too Early Can Backfire In this episode, Junaid shares a story from his early days as a Scrum Master when enthusiasm got ahead of experience. Fresh from a CSM certification and full of ideas, he walked into teams and started proposing solutions — "No, this is not how you should do it." It felt obvious. It wasn't. The wake-up call came when he proposed working agreements to a team that had been collaborating well for two years. The pushback was immediate: "Why do we need this?" He realized he was bringing a tool he'd seen elsewhere without first understanding whether the team actually had the problem that tool was meant to solve. This led to a key shift in his approach: stop assuming. Instead of going in with answers, Junaid started creating small tiger teams with the affected people, facilitating sessions where they owned the solution. The result? Much higher acceptance and genuine continuous improvement. These days, Junaid tests his ideas before bringing them to the full team. He connects with individual team members first — his "closer allies" — to validate whether his analysis matches reality. Only when a few people confirm "yes, this is a real problem" does he bring the proposal to the group. As Vasco puts it: not all tools are appropriate at all times for all people. The same working agreements that were wrong for one team at one moment might be exactly right for a different team, or the same team at a different moment. [The Scrum Master Toolbox Podcast Recommends]

Nigel Baker: Why Scrum Masters Should Be Measured on Outcomes, Impacts, and Team Happiness 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 customer's going to come to you and say, do you know why I bought your product? Your remarkable compliance with your internal development process. What they're interested in is outcomes and impacts." - Nigel Baker   Nigel challenges the traditional ways of measuring Scrum Master success. He points to tools like the Nokia test—which, he jokes, was neither a test nor invented by Nokia—as examples of process fidelity assessments that miss the point entirely. Compliance with a process tells you nothing about whether customers are satisfied or whether the team is delivering value. Instead, Nigel argues for measuring Scrum Masters on outcomes and impacts: customer satisfaction, revenue generation, and efficiencies—the same things a Product Owner gets judged on.  But he adds a crucial dimension that POs often overlook: team happiness. Not as an end goal, but as a leading indicator. Happy teams don't leave. Happy teams do better work. Team contentness is a KPI that signals whether the deeper success factors are in place. When your team is deeply unhappy, no amount of velocity or story completion will save you from attrition and decline.   Self-reflection Question: How are you currently measuring your success as a Scrum Master—on process compliance, or on the outcomes, impacts, and wellbeing your team actually delivers? Featured Retrospective Format for the Week: Keep It Fresh—A Different Format Every Sprint Nigel's answer to the "favorite retrospective format" question is deliberately controversial: he doesn't have one. His approach is to use a different format every single sprint. Retrospective formats, he argues, "age like milk"—by Sprint 12, asking "what should we do differently?" with the same structure produces diminishing returns. Novelty creates energy. He sometimes gets teams to invent their own formats, which produces some of the most forensic and intense retrospectives he's seen—teams building "superweapons" and then realizing they have to turn those weapons on themselves. But Nigel's most practical tip is using retrospective techniques inside the Sprint Review. The Review is a product retrospective, and stakeholders shouldn't sit "like Roman emperors in the Colosseum, watching the developers as gladiators." Instead, use facilitation methods to extract "sweet, juicy, honey-flavoured feedback" from stakeholders about what they'd change in the product.   [The Scrum Master Toolbox Podcast Recommends]

Nigel Baker: When Teams Slowly Decay by Anointing a Hidden Dictator 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 world won't end with a bang, but with a whimper. My great fear is not teams exploding like a bomb—that shows they care. The big thing for me is teams that decay slowly." - Nigel Baker   Nigel shares a pattern he has witnessed repeatedly: teams that self-destruct not through dramatic conflict, but through a slow, quiet decay. Referencing The Five Dysfunctions of a Team by Patrick Lencioni, he points to something even more insidious than inattention to results—teams that avoid taking responsibility for decision-making.  When teams struggle with self-organization, they often try to "self-organize themselves out of self-organization" by anointing a hidden dictator: the big brain, the big mouth, the tech lead, or the project manager who everyone secretly defers to. Nigel offers two practical tools to counter this pattern.  First, the "yes and" technique from improv comedy—instead of taking ownership away from team members, you accept their idea and add to it, keeping the ownership where it belongs.  Second, Socratic questioning, where instead of passing knowledge from you to them, you help them pass knowledge from themselves to themselves. But Nigel adds an important caution: the Agile community has swung too far into pure coaching mode. Sometimes people genuinely need help, not therapy—they need to know which server the files are on, not a deep coaching question about their feelings.   In this segment, we talk about Paul Goddard's work on improv comedy in Agile, and the power of the "yes and" technique for keeping ownership with teams.   Self-reflection Question: Is your team quietly deferring all decisions to one person, and if so, what practical steps can you take to redistribute that ownership? Featured Book of the Week: Leading Self-Directed Work Teams by Kimball Fisher Nigel's book recommendations reflect his belief that the most inspiring ideas come from adjacent fields rather than Agile literature itself. Leading Self-Directed Work Teams by Kimball Fisher stands out because it explores similar principles to the Scrum Master role but without any Agile jargon—showing how a completely different industry arrived at the same insights about empowered teams. Nigel also recommends the Strategyzer books by Alex Osterwalder, including Business Model Generation and Testing Business Ideas, for the business thinking that coaches need but rarely pick up at work. Scrum Mastery by Geoff Watts remains his go-to foundational text for new Scrum Masters. And the book he waited 4.5 years for—until Amazon cancelled the pre-order—is the latest edition of The Facilitator's Guide to Participatory Decision Making by Sam Kaner, a deeply practical reference guide that gives real people real tools for real situations.   [The Scrum Master Toolbox Podcast Recommends]

Nigel Baker: The Scrum Master Mistake of Copy-Pasting Success Instead of Recreating the Journey Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "I was trying to recreate the results of our team, not recreate the journey. And that is what killed me to begin with." - Nigel Baker   Nigel fell into Scrum Mastery almost by accident. Working at British Telecom in 2002—before most people had even heard of Scrum—his team adopted it not to speed up, but to add rigor to an already fast-moving tactical unit full of "pirates" who could get stuff done but needed guardrails. His first Scrum Master, Geoff Watts, got promoted and moved on, leaving a vacancy. Nigel was the third person asked—and the first to say yes. He loved the role, but his earliest mistake became his most enduring lesson.  On his very first daily Scrum, Nigel brought a big leather book and wrote down what every team member was doing, acting like a proto-project manager collecting status reports. The team already had all this information in their system—he was unconsciously positioning himself as the authority figure, having people report to him rather than to each other.  As Nigel evolved into an Agile Coach, the bigger failure emerged: trying to copy-paste the process that worked with his first team onto other teams, recreating the results rather than the journey that got them there. Each team needs to evolve its own process—there are no shortcuts to that growth.   In this episode, we refer to the importance of self-awareness and servant leadership in the Scrum Master role.   Self-reflection Question: Are you trying to replicate a successful process from a previous team, or are you investing in helping your current team discover their own path to effectiveness?   [The Scrum Master Toolbox Podcast Recommends]

Lai-Ling Su: What Scrum Masters Must Do More of in 2026—Think Like a Business Owner 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 so contextual. And I think the definitions and measurements of success also change over time. So, only you can definitively say what success is at any given time and how to appropriately measure it for your situation." - Lai-Ling Su   Lai-Ling frames success for Scrum Masters around what she'd love to see more of in 2026: smart, strategic, and commercial decision-making. She observes a distinct gap in the business landscape—too few people are making decisions that balance customer value, revenues, expenses, and long-term sustainability.  This could mean reducing SKUs to enhance operational flow and reduce burnout, investing in change management from day one of a transformation, or cutting unused software licenses to save a colleague's job or fund product innovation. To help Scrum Masters develop this capability, Lai-Ling puts them in the shoes of a business owner—whether through simulations, shadowing business leaders, or pairing with product owners to understand the business side of products beyond just the build side.  She emphasizes the difference between learning strategy through theory (like an MBA) versus learning it through actually operating a business, where consequences are real and immediate.   Self-reflection Question: When did you last consider how a decision in your domain impacts the broader commercial viability of your organization? Featured Retrospective Format for the Week: LEGO Serious Play Lai-Ling loves using LEGO for deeply reflective retrospectives, and she's a certified LEGO Serious Play facilitator. The approach works beautifully for tender and courageous conversations because building with LEGO does several things simultaneously: it's fun, the physical act of building helps process and articulate thoughts you didn't have words for, and it depersonalizes what's said because participants talk about a physical object rather than directly about people. You don't need expensive certified kits—just grab basic bricks from a local shop, pose a reflective question, and let people build.  Lai-Ling notes that her best retrospectives have often been the most deeply uncomfortable ones for participants, because of how much personal and emotional truth emerges when you create that safe space for constructive dialogue. The kinetic and visual elements help crystallize ideas that would otherwise not come out so easily.   [The Scrum Master Toolbox Podcast Recommends]

Lai-Ling Su: When Leadership Changes—Supporting Teams Through the Uncertainty 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 a once in a generational or once in a lifetime type of opportunity to fundamentally work with these leaders to shift the workplace environments and the workplace dynamics in the way that we've been trying to craft in the world of product and agile for the last few decades." - Lai-Ling Su   Lai-Ling brings a systems-level challenge that has profound implications for Scrum Masters everywhere. Australia is on the brink of its largest intergenerational wealth transfer in history—$3.5 trillion over the next couple of decades—with 70% of private and family businesses planning to sell or succeed as part of this generational change.  This creates leadership vacuums as business leaders transition out and new ones step in. Some are family members stepping into roles without the full capability to lead; others are external CEOs facing resistance when they do things differently.  These transitions stall decisions, lose customer confidence, and fracture once tight-knit teams. Lai-Ling sees this as an unprecedented opportunity for Scrum Masters to support both outgoing and incoming leaders through succession planning, capability uplift, and protecting teams during the transition.  Teams need to be respected for what they've achieved, and Scrum Masters can serve as bridges—creating awareness about the team's strengths and facilitating dialogue between old and new leadership to ensure continuity.   Self-reflection Question: How might you proactively prepare your team to navigate an upcoming leadership transition, whether it's anticipated or unexpected?   [The Scrum Master Toolbox Podcast Recommends]