Don't Scale Dysfunction—Fix the Team First | Karim Harbott

Summary

Podcast Summary: "Don't Scale Dysfunction—Fix the Team First"

Podcast: Scrum Master Toolbox Podcast
Host: Vasco Duarte
Guest: Karim Harbott
Date: November 6, 2025

---

Overview

In this "Success Thursday" episode, Vasco Duarte and guest Karim Harbott dig into fundamental ideas about measuring success for Scrum Masters and Agile coaches. The central theme is clear: Organizations should fix problems at the team level before scaling, as scaling dysfunction only amplifies issues. Drawing on Karim's experience as an Agile coach, trainer, and non-executive director, the conversation highlights actionable strategies for defining, measuring, and driving team success—eschewing vanity metrics in favor of real value.

---

Key Discussion Points & Insights

1. Karim's Favorite Retrospective Format

[01:21–03:39]

• Karim admits he's "always slightly struggled with retros," especially with the more playful formats. Instead, he prefers systems modeling, which he learned about through the book Scaling Lean & Agile Development.

• Systems modeling makes visible the many interconnected elements within a team and demonstrates how a change in one area can affect others.

• Quote:

  "Modeling complex systems and trying to show how each thing impacts everything else ... I've found to be a very powerful way of identifying experiments that may or may not improve the team effectiveness over time." — Karim Harbott [02:53]

• He especially recommends causal loop diagrams to uncover systemic causes and experiment areas.

---

2. Karim's Facilitation Approach

[03:39–04:33]

• Karim uses a relaxed, informal style—encouraging people to stand up, shout out ideas, and engage in spontaneous dialogue.
• While mindful of personality types (balancing introverts and extroverts), he values active participation over traditional facilitation rules.
• Quote:

  "I probably break a lot of the traditional rules of facilitation because I just kind of get everyone up and we're all shouting things out ... It's kind of a much more informal about it." — Karim Harbott [03:48]

---

3. Defining Success for Scrum Masters & Agile Coaches

[04:33–06:45]

• Karim draws an analogy between football managers and Scrum Masters: the team's success = the manager’s (or Scrum Master’s) success.
• True success isn't about personal outputs ("number of retros" or "reports created") but rather on improving the team’s effectiveness and helping them achieve their goals.
• Quote:

  "It's about, is the team better than the team was before in whichever way we've defined better ... your measures are outside of your control. ... I enabled others to be better." — Karim Harbott [05:36]

---

4. Getting Organizations to Define Success

[06:45–08:38]

• Karim starts with "inquiry, not advocacy" but notes that most leaders want teams to deliver value, not just outputs.
• Effective success measures are a blend of:
  • Delivery/process effectiveness
  • Customer and internal metrics
  • Product management effectiveness
  • Team culture
• A "team balanced scorecard" can capture these multiple dimensions.
• Quote:

  "You're trying to get them out of the project and outputs mindset more into the product and outcomes mindset." — Karim Harbott [07:52]

---

5. Moving Beyond "Easy" Metrics

[08:38–10:32]

• Leaders often default to easy, misleading metrics (e.g., velocity, code written, bugs found). Karim suggests always linking team-level goals to organizational objectives.

• He leverages his board experience to tie strategy and team work to high-level outcomes (e.g., revenue, Net Promoter Score, customer impact).

• Quote:

  "Will delivering more story points help increase revenue? ... Could I deliver more story points without delivering more revenue or more value? Yes. Okay, so it's not story points we want. What is it?" — Karim Harbott [09:52]

• If a measure (e.g., velocity) doesn't connect to a strategic goal, it's not a true indicator of success.

---

6. The Dangers of Scaling Dysfunction

[10:32–11:57]

• Modern hype, such as with AI, can drive focus onto "more" rather than "better."
• Karim warns that scaling an immature or ineffective process simply multiplies the dysfunction.
• Quote:

  "When you scale, you get more of what you're doing. And if what you're doing is just not valuable, you'll get more not valuable. ... So don't scale dysfunction." — Karim Harbott [10:55]

• Memorable exchange:
  • Vasco: "I like the phrase don't scale dysfunction because you can scale it."
  • Karim: "Actually, you can scale it very easily. It's the easiest thing to scale dysfunction." [11:38–11:49]

---

Notable Quotes

| Time | Speaker | Quote | |--------|---------|-------| | 02:53 | Karim | "Modeling complex systems ... is a very powerful way of identifying experiments that may or may not improve the team effectiveness over time." | | 03:48 | Karim | "I probably break a lot of the traditional rules of facilitation because I just kind of get everyone up and we're all shouting things out ..." | | 05:36 | Karim | "It's about, is the team better than the team was before in whichever way we've defined better ... I enabled others to be better." | | 07:52 | Karim | "You're trying to get them out of the project and outputs mindset more into the product and outcomes mindset." | | 09:52 | Karim | "Will delivering more story points help increase revenue? ... so it's not story points we want. What is it?" | | 10:55 | Karim | "When you scale, you get more of what you're doing. And if what you're doing is just not valuable, you'll get more not valuable. ... So don't scale dysfunction." | | 11:49 | Karim | "It's the easiest thing to scale dysfunction." |

---

Timestamps for Key Segments

| Timestamp | Segment Description | |-----------|--------------------| | 01:21 | Karim's reflection on retrospectives and systems modeling | | 03:39 | Approaches to facilitation: causal loop diagrams, group participation | | 04:33 | How Karim defines success for Scrum Masters and Agile coaches | | 06:45 | Techniques for helping organizations define team success | | 08:38 | Converting "easy" metrics to outcome-based conversations | | 10:32 | Dangers of scaling dysfunction and AI-driven metric distortions | | 11:38 | Closing thoughts and "don't scale dysfunction" quip |

---

Conclusion

This episode offers rich, candid insight into the mindset of an experienced Agile leader. Karim Harbott challenges listeners to move beyond superficial measures—like lines of code or story points—and stay fiercely focused on the team’s value delivery and alignment with organizational goals. His message is a warning: If you scale a broken system, you amplify the dysfunction—so fix the team first.

The conversation is a must-listen for Scrum Masters, Agile coaches, and leaders intent on creating meaningful, impactful change within their organizations.

Transcript

[A]

Hey there, agile adventurer, just a quick question. What if, for the price of 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 war free 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 this 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. Hello everybody. Welcome to our Success Thursday. The big question of the week this week with Karim Harbot. Hey, Karim, welcome back.

[B]

Success Thursday. It sounds exciting.

[A]

Yeah, absolutely. Before we dive into success, do share with us, Karim, what's your favorite retrospective format and why?

[B]

Yeah, I will. You know, I don't want to sound like a grumpy old man, right? But I'm going to be one, right? Because I have to say I've always slightly struggled with retrospectives. Not that I don't think they're valuable. The continuous improvement is incredibly, the concept of them is very valuable. But I'm just, you know, some of the sort of, the more out there techniques that are in the agile world and the kind of more sort of playful, fun things and I get them and I get that you may want to drop them in. It's just never, I've just never been particularly congruent with me or. But one I love is actually bringing in the concept of systems modeling into a retrospective. It's a bit more serious but very powerful. And I mentioned, I think in the first episode, the book that's been very impactful on me, scaling Lean and agile development. This is where I was introduced to it. And as I've got to know Craig Lahmann a lot over the past, well, 10 years really, it was 2015 where we were where I met him. He's such a, such a passionate advocate of that that I've learned more and more and I've implemented it more and more. The reason I love just kind of, it just shows how many elements of the system there are and how they're all interacting with each other and how if you change this, it might impact that, but it then will also impact six other things. So we need to be careful about that. So. And it really helps you to pin down something you could never really get going in your head and identify some experiments that might improve the system in a slightly more analytical way than maybe some things. And so that really appeals to me, modeling complex systems and trying to show how each thing impacts everything else and how when you change one thing, it's actually multiple things that are impacted and it may not go in your favor. And I think getting the team to be involved with that and buy into those experiments and come up with those experiments, I've found to be a very powerful way of identifying experiments that may or may not improve the team effectiveness over time. So I've always liked to bring in some systems modeling, particularly if you have more than one team working together.

[A]

There are favorite facilitation strategy that you use for systems modeling in the context of a retrospective with a team.

[B]

Just standard. I use causal loop diagrams. But you know, I'm very relaxed in my facilitation style. You know, I probably break a lot of the traditional rules of facilitation because I just kind of get everyone up and we're all shouting things out, which, you know, you have to be mindful that maybe bringing out the sort of, the more introverts and holding back the more extroverts. But I like people stood up against the wall shouting stuff out, someone's writing it down and then saying, why do you think this? I think that let's have a chat about this. And it's kind of, it's a bit more light touch facilitation when I do it. There's some brilliant facilitators in the agile world. I never really became an expert in that field. I think there are some great people doing that. I'm just kind of a much more informal about it.

[A]

Yeah, absolutely. And there's no wrong way of doing facilitation. There's just ways that deliver results and ways that don't deliver results. So it's upon us to then experiment and find our way for sure. Karim and of course we do causal loop diagrams and other types of conversations to try and help others succeed as Scrum masters and agile coaches. But we also need and need to take responsibility over defining and achieving our own success. So how do you define for yourself success as a Scrum master or Agile coach? Karim?

[B]

Yeah, that is a very challenging question. I'll tell you why, right? Because, you know, let's take it out of Agile for a minute, right? I'm an Arsenal fan.

[A]

How?

[B]

How? Got to get that in there.

[A]

How.

[B]

How do you. Other North London teams are available, too. How do you define the success of a football manager? Right. Mikhail Arteta, what's success look like? Well, I think for. For him this season, Arsenal winning something, ideally the Premier League. Is that so? You define your success as a manager by the team being successful, not by you being successful. Right. If the team's successful, you are successful. And I think the same is true of a scrum master. It's not what you do. Hey, I did all these reports or I did this or where stage 20 retrospectives last year, right? It's about, is the team better than the team was before in whichever way we've defined better, right? And we can come to talk about that. But it has to be that because what's the point of view as a scrum master? It's the effectiveness of the scrum team, and you're accountable for that. So your measures are outside of your control. In many ways, just like a leader is in the organization, your effectiveness, you are measured on the success of the company, not on the success of you. Right? It's kind of different if you're a sprinter. You just, hey, I ran faster than everyone else. But this is. I enabled others to be better. So it's tricky. It's tricky. But I think that's how I would define it. I would say, here's where the team is, here's where we want the team to be. Okay, did I help the team get there?

[A]

What are some of the things you've learned about helping leaders, organizations, and ultimately teams define what that success is for them? Because, of course, if our success is their success, or rather the other way around, if their success is our success, then we need to look at that and somehow work with the teams, work with the organization, work with the leaders to define it so that we can start working towards it. So how do you do that, Karim?

[B]

It's normally a similar set of things, if I'm honest. I mean, I go in with. With a mindset of inquiry, not advocacy, but in my head, I kind of know where it's going to land most of the time, right? So you're. You're having conversations with. With leadership, and they'll ask a few questions, you'll ask a few questions back. It normally starts off with, I want them to deliver. And it's like, okay, well, deliver what? So more Features or more velocity or more. Is that really what you want? Okay, because we can do that. But. But actually it turns out I want them to deliver more value. Like, okay, well there's a delivery aspect to this in terms of their processes. There's also a product management aspect to this. Are we building the right things? So now we've got our internal processes and effectiveness, we've got great product management, we've got customer metrics, internal metrics, quality metrics, and we've also got team culture metrics. It tends to just be a collection of these things in some kind of team balance scorecard if you like. And so yeah, when you prod, when you pristine the surface, what the leaders really want, they want the team to deliver value and move you towards the organizational goals. It's like, okay, great, we can do that and we can set some targets for ourselves to do that. So it ends up being that. But you're speaking to leaders and you're trying to get them out of the project and outputs mindset more into the product and outcomes mindset. And that's actually a reasonably straightforward thing for people to get their heads around.

[A]

So one of the things that I struggle with, and I'm sure I'm not the only one, is to actually help people do that transition. Because if I ask a developer more lines of code, if I ask a tester, more bugs found or less bugs released, if I ask a manager more story points, how do you have those conversations? What are the things, the tips that you have learned about having those conversations so that we don't get stuck in the easy metrics, like, you know, more story points, more stories, whatever that might.

[B]

Be, you have to link it to organizational outcomes. Now this is where my role as a non executive director comes in very, very handy, right? Because I sit on boards and what you're doing as boards is you are working with the management of the company on strategy, on vision, on culture and banon, sort of 2, 3, 4 high level organizational objectives, strategic objectives, whatever you want to call them, right? High level okrs. And, and it's like, okay, great, that should, that should cascade down. And everything you do as a delivery team should be aligned to one of those objectives. If it's like, the question is like, will delivering more story points help increase revenue? Like, will it? Why? And they might say, well, because more story points, more features means it's like, but does it? But could I deliver more story points without delivering more revenue or more value? Yes. Okay, so it's not story points we want what Is it? Well, we want to move the needle on conversion or on Net promoter score or on. It's like, okay, great, why don't we set that as the goal, right? And so if you start linking to organization objectives, suddenly look at these things become meaningless. Your organization doesn't care about your velocity, about any of that stuff. It doesn't care about lines of code written. You think the CEO is going off, we could just write more lines of code, right?

[A]

Well, I mean, some are, to be fair. Like, I know I'm playing a little bit the devil's advocate, but if you see the latest hype on AI, basically we are seeing institutionalized and mass narrative that more lines of code equals better.

[B]

I'd rather we didn't see that. So for me, what does AI do? It allows you to deliver more value. But of course, if what you're delivering is invaluable in the first place, then you'll just deliver more. Nonsense. Right? So the way I looked at it, and again, I think this is probably a bust of audit. Right? It's like when you scale, you get more of what you're doing. And if what you're doing is just not valuable, you'll get more. Not valuable. Right. If you've got one team working well delivering value and you scale that, you'll get hopefully lots of teams working well. So don't scale dysfunction. And I think most organizations are so focused on more that they forget about good. And so you have to start by defining those metrics. Well, but I mean, yes, sure, more lines of code.

[A]

Great.

[B]

What will that give me?

[A]

I like the phrase don't scale dysfunction because you can scale it.

[B]

Actually, you can scale it very easily.

[A]

Right?

[B]

It's the easiest thing to scale dysfunction.

[A]

That's a very important conversation. Absolutely. Karim, thank you very much for sharing that with us.

[B]

No worries. Anytime.

[A]

Alright, 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 for and join the community that's shaping the future of Agile. We have so much for you, so check out all the [e-mail] membership because listening is great, it's important. But doing it together, that's next level. I'll see you in the community. 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.