How "Fake Kanban" Fooled the Metrics, And What This Agile Coach Did to Fix It | Christian Thordal

Summary

Podcast Summary: Scrum Master Toolbox Podcast

Episode: How "Fake Kanban" Fooled the Metrics, And What This Agile Coach Did to Fix It
Host: Vasco Duarte
Guest: Christian Thordal
Date: May 19, 2026

---

Overview of the Episode

This episode of the Scrum Master Toolbox Podcast centers on Christian Thordal’s real-world experience with a team that adopted a “Kanban-style” approach—but quickly drifted into anti-patterns that masked underlying team dysfunctions. The discussion focuses on the dangers of "fake Kanban," how misleading metrics can obscure team challenges, and concrete steps Christian took to get the team back on track. Key topics include ownership, backlog management, role clarity, and intent-based leadership, illustrated with colorful metaphors and practical advice.

---

Key Discussion Points & Insights

1. The Power of Intent-Based Leadership

• Christian's book recommendation:
  • Turn the Ship Around by David Marquet inspired him as a leader by focusing on intent-based leadership, encouraging team ownership and engagement.
  • Quote:

    "Instead of asking permission, you kind of give intent. So this is about intent-based leadership. So tell me what you want to do and I'm better equipped to help you with the solution on what you want to do." – Christian (01:32)

2. The Origins of “Fake Kanban” and Team Dysfunction (03:18)

• Team Characteristics:
  • The team appeared "busy" but suffered from low process, low effectiveness, and low learning despite boasting impressive cycle times.
  • Ownership gaps were revealed: the Product Owner (PO) didn’t actively engage in their leadership role, and "Kanban" was interpreted loosely as “do whatever we want.”
  • The daily standups devolved into social check-ins rather than meaningful progress updates.
  • Quote:

    "This team is low in process, it is low in effectiveness and low in learning. But when I look at cycle time, for instance, it's pretty low. So how can they be low in efficiency and processes when they're actually performing?" – Christian (03:27)

3. Symptoms and Consequences (04:38 – 09:54)

• Lack of PO Engagement:
  • Backlog management was inconsistent; backlog items lacked detailed descriptions and prioritization.
  • During standups, the PO failed to drive clarity or facilitate coordination, resulting in fragmented work and role confusion.
• The Backlog in Limbo:
  • Most work originated from ad hoc Slack discussions, with items bypassing proper backlog grooming and prioritization.
  • The backlog ballooned to over 150 items, with more than 50 in progress but lacking team engagement or accountability.
  • Metaphor:

    “The team is reacting more like birds in a nest waiting to get fed.” – Christian (09:28)

• Metrics Mask Dysfunction:
  • Fast cycle time gave a false impression of healthy workflow, hiding real process issues.
  • Quote:

    “The measurement can stand alone. So I need to look at something else.” – Christian (10:00)

4. Realization and Course Correction (09:54 – 10:47)

• Restarting the Backlog:
  • Christian and the PO collaborated to refresh the backlog, cutting it down from 150 to about 30 meaningful items.
  • Team involvement in backlog refinement increased engagement and clarity.
  • Work-in-progress (WIP) limits were established to promote pull-based flow, not push.
• Moving Towards True Kanban:
  • The change helped the team refocus on prioritization, ownership, and transparency.

---

Notable Quotes & Memorable Moments

• On PO Ownership:

  “He has somehow become the bottleneck for everyone, because he’s kind of scrum mom if you want to…he’s the bottleneck for not being more firm, but also having requirement and expectations and communicating them to the team.” – Christian (07:11)

• On Team Dependency:

  “The team is reacting more like birds in a nest waiting to get fed.” – Christian (09:28)
  “Very dependent on the PO. Yeah. But actually able to…they are very skilled developers, so they can execute very fast.” – Christian (09:39)

• On Masked Problems:

  “Which probably hides the problem. Right, because they can get whatever done very quickly.” – Vasco (09:54)
  “Exactly. So, I mean, that’s another takeaway. I mean, the measurement can stand alone.” – Christian (10:00)

• On the Fix:

  “I’ve actually restarted the backlog…And we also decided on having a WIP limit, so we would create that pull instead of a push.” – Christian (10:00–10:36)

---

Timestamps for Key Segments

• [01:32] — Book recommendation & intent-based leadership
• [03:18] — Team anti-patterns discovered: Fake Kanban, busy-ness, low effectiveness
• [04:38]–[06:08] — PO's lack of ownership and backlog management
• [07:11] — PO as bottleneck; team dynamic and bottleneck analogy
• [09:28] — Birds in a nest metaphor for passive, dependent team
• [09:54] — Metrics (cycle time) hiding root problems
• [10:00–10:36] — Backlog reset, team engagement, and introduction of WIP limits

---

Episode Takeaways

• Metrics can be misleading: Fast throughput may hide deeper issues if roles and ownership aren't clear.
• True Kanban requires discipline: A loosely interpreted, unstructured process leads to dependency, chaos, and disengagement.
• Ownership drives results: When both POs and teams engage, clarify, and refine backlogs together, practices (and motivation!) improve.
• Leadership is about intent and clarity: Setting clear expectations and transferring ownership back to the team are key.

---

This episode is a practical case study on how “fake Kanban” can fool even experienced teams, why agile roles matter, and the importance of measuring the right things—for teams seeking to improve, and Scrum Masters/Agile Coaches everywhere.

Transcript

[A]

Hey there agile adventurer, just a quick question.

[B]

What if for the price of a

[A]

fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame warfree and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's the Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership. That's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast.

[B]

Hello everybody. Welcome to our Team Tuesday. This week we have with us Christian Tordal. Hey Christian, welcome back.

[C]

Hey Vasco.

[B]

So Team Tuesday, as the name says, is all about teams. But before we dive into that, Christian, share with us, we what was the book that most inspired you in your career as a Scrum Master?

[C]

Oh, there's a lot, Vasco, but I think the one that's closest to the heart and what comes to mind when asked that question is a book called Turn the Ship around by David Marquet. I think he's called former U.S. navy Commander of the submarine, nuclear submarine Santa Fe. And why it speaks to me is because instead of asking permission, you kind of give the intent. So this is about intent based leadership. So tell me what you want to do and I'm better equipped to help you with the solution on what you want to do. For me it does two things and it was also kind of the reminder of how you used to do things within the military. On the way I saw leadership. You transfer ownership to the team and you also have them engage and you make them accountable for what they ask for or what they tell you.

[B]

Yeah, absolutely. There's a lot to dig into when it comes to intent based leadership. Check out everybody the link in the show, notes to the book, of course, but also to the episodes that we've recorded with David. They are wonderful conversations, really worth digging into. So Christian, but of course we are here to talk about teams as well. So let's dive into the team story. So we'd like to explore these patterns or behaviors, ways of acting that maybe start small but eventually develop over time and create problems for the team. So tell us that story, Christian.

[C]

So team is a team that I'm working with right now and this is a team that always seems kind of busy. So what we did was we kind of looked into, okay, how can I rate the system of the domain that I'm within? Because it helps us highlight the size of where the team's not functioning. So this team is low in process, it is low in effectiveness and low in learning. But when I look at cycle time, for instance, it's pretty low. So how can they be low in efficiency and processes when they're actually performing? So what I figured out, and it's to do with ownership. So they want to do a Kanban style approach to how they work. But kanban in this context means we can do whatever we want. A basic misconception of a great framework. So what I found out is that my PO is not really taking accountability for the leadership that is within that role. So for instance, tell us a little

[B]

bit more about what you mean by that.

[C]

Taking the leadership. Yeah. So for instance, when we have daily, I like to kind of pull out the board and then I ask every individual within the team, so what are you working on? What needs to happen for it to get finished? Are you blocked? And do you need to communicate with anyone or coordinate with anyone? And the PO is not really doing it. That 15 minutes we have every morning basically becomes a social check in. And this reflects also in Jira where the backlog is 100 and something items to do and we have, I think it's over 50 in progress and there's no accountability. And the description of the, the backlog item is usually just a headline. So he's not really owning the role right now. So that's what I'm kind of.

[B]

So what you're saying is he kind of performs the high level of the product owner role but doesn't take the. You called it the ownership, but the way I translate it in my mind is doesn't take the responsibility for making sure that everybody else knows what needs to be done, what priority it needs to be done with. Is that what you would describe?

[C]

That's one of the symptoms. The other one is that instead of doing an actual planning, when you do Kanban, you refine all the time. So you make sure the backlog is filled with stuff that's prioritized. You could just pull into your work. We have something called napkin and because of the way we're doing it, it's only a few specialists within the team that's able to do the tasks and we're only able to react on what comes in. So we can only predict the week ahead, which is basically, what are you going to do this week? So by the ownership, I mean that he has somehow become the bottleneck for everyone, because he's kind of scrum mom if you want to scrum dad in that sense, because we talked a lot about mercenaries and missionaries and we have a lot of mercenaries on this team. And he's the bottleneck for not

[A]

being

[C]

more firm, but also having requirement and expectations and communicating them to the team. So this is what I need for you in order to get better and having a better backlog towards the product.

[B]

So it's almost like, if I get you right, it's almost like the backlog is a little bit in limbo. Sometimes it gets attention, sometimes it doesn't. But it has direct and concrete consequences when it's not ready.

[A]

Right.

[B]

Like the team doesn't know what to pick up, or they don't have anything they could pick up with pick up from the backlog, or they need a lot more insight before they can start working on something they want to pick up. Is that how you see it?

[C]

No, I think that the backlog doesn't get the attention that it deserves. It is more like the way work comes in is that either PO or the developers huddle on Slack for like 30 minutes and within that period they have come with a solution and it's go do. Instead of saying thank you, I'll put it in the backlog so I can prioritize it. Because within this company, we're doing OKRs, but it's hard for us to actually reach those goals and those okrs when you're only planning a week ahead. So basically we're missing a strict backlog and we're missing the engagement from the team to actually drive the items themselves.

[B]

Yeah, absolutely. So it's almost like the team is navigating without a compass, right?

[C]

It's like, yeah, you could say that.

[B]

And when the islands are not visible, they really just go in a random direction.

[C]

Yeah. And then you wait for the PO to come and say something or give you something to kind of navigate for those islands, right?

[B]

Yeah, absolutely. So what I imagine is that in teams that are in that kind of circumstance or situation, the work would feel rather like a chore, not really engaging. The vision is probably murky or not understood, and people just look at the backlog as a source of tasks to do rather than an inspiring Deliverable that they could commit to. Is that how you, how you see the team react?

[C]

No, I see the team reacting more like birds in a nest waiting to get fed.

[B]

Or dependent.

[C]

Very dependent on the po. Yeah. But actually able to. I mean, they are very skilled developers, so they can execute very fast. And that's also what we see in the cycle time that they have.

[B]

Which probably hides the problem. Right, because they can get whatever done very quickly.

[C]

Exactly. So, I mean, that's another takeaway. I mean, the measurement can stand alone. So I need to look at something else. But what I've done is I've actually restarted the backlog and luckily the PO was smart enough to say, let's do it, but let's bring in the team. So they kind of got up to speed on what are we doing. And I think we're down to from 150 items to some 30 or something. And we still have missed that part, the last part. And we also decided on having a whip limit, so we would create that pull instead of a push.

[B]

Absolutely. It sounds like great, concrete steps towards actually using Kanban in practice. Wonderful story. Thank you for sharing that, Christian.

[A]

All right, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you. The members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing agile. Every day we're talking access to over 700 hours of agile gold, CTO level strategy talks, summit keynotes, live workshops, E courses, deep dive interviews, books, and if you're into no estimates, we got the pioneers of no estimates in those deep dive interviews as well. Agile business intelligence, creating product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of all of that AI slop you see everywhere. And of course, without the flame wars, it's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the details@score scrummastertoolbox.org membership because listening is great, it's important, but doing it together, that's next level. I'll see you in the community.

[B]

Slack. We really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes. Share this podcast and let other Scrum Masters know about this valuable resource for their work. Remember that sharing is caring.