The Expert Who Couldn't Connect: An Agile Team Integration Challenge | Salum Abdul-Rahman

Summary

---

Scrum Master Toolbox Podcast: The Expert Who Couldn't Connect – An Agile Team Integration Challenge

Guest: Salum Abdul-Rahman (Agile Coach, Reactor)
Host: Vasco Duarte
Date: August 25, 2025

---

Overview

In this episode, Vasco Duarte sits down with Salum Abdul-Rahman, agile coach at Reactor, to dissect a challenging team integration failure involving a senior software architect who struggled to connect with an established, egalitarian Scrum team. Salum shares a candid, reflective story from his early days as a Scrum Master, illuminating the human and cultural factors that can hinder even the most technically proficient professionals from fitting into agile teams. The conversation is rich with insights on leadership, team dynamics, and the personal growth required to support diverse contributors in Agile environments.

---

Key Discussion Points & Insights

1. Salum’s Journey into Scrum Mastery

• Scout Leadership Roots:
  • Salum starts by tracing his leadership philosophy back to Scout camps: "Like everybody has to contribute if you want to sleep in a warm, dry tent and to eat food [...] it really doesn't matter what your title is. Like everybody is responsible for everybody." (02:08)
  • Emphasizes the importance of shared responsibility drawn from both volunteering and professional software roles.
• Natural Evolution to Scrum Master:
  • Describes stepping into the Scrum Master role by always picking up slack for the team, before even knowing the title existed.

2. Team Leadership in Agile vs. Traditional Hierarchies

• Shifting Paradigms:
  • Vasco highlights, "That's what we expected leaders to be in the first place," reflecting on how Scrum Masters embody a servant-leader model. (04:05)
• Historical Hierarchies:
  • Salum notes Western workplaces’ "deeply rooted culture of hierarchical leadership," even though modern organizations, including military units like the SEALs, are adapting toward expertise-based structures. (04:34)

3. Fail Monday – The Story of the Disconnected Expert

• The Setup:
  • Project context: Large public sector agile project, several teams, Salum as Scrum Master for one.
  • Integration challenge: "A senior software developer, software architect. He was hired with the title software architect [...] contributing good work, but he was struggling with the team." (06:13)
• Conflict Unfolds:
  • The architect’s concerns were overlooked in retrospectives, and his communication style was authoritative, not collaborative.
  • "Whenever we had retrospectives, his concerns were not picked up by the rest of the team. [...] He was in open conflict with another developer [...] who was hired as a software architect title. So this was a bit of a surprise for me." (06:13–07:18)
  • Attempts at mediation using NVC (Nonviolent Communication) failed, and the architect eventually withdrew, ceased sharing, and left the project and company.

4. Underlying Causes & Dynamics

• Missed Connections:
  • The team's initial cohesion—being a greenfield project with decisions made before the architect joined—contributed to his outsider status.
  • "He was not part of the initial decisions and discussions." (09:05)
• Communication Style as a Barrier:
  • "A lot of his argumentation for what should be done came from a position of authority of experts instead of basing his arguments on data." (09:05)
  • Vasco distills: "Rather than making a case, he basically said 'I know better.'" (09:43)
  • Salum confirms, "Yes." (09:50)
• Cultural Mismatch:
  • Architect’s background in a large corporation may have shaped a hierarchical outlook, clashing with the team’s egalitarian norms. "He joined from a larger corporation, so he probably had a different cultural experience than the rest of the team." (10:00)
• Empathy Gap:
  • Salum: “I really couldn't empathize to the extent that I could have really like formed a connection.” (10:00)

5. Reflections & Learnings

• Not All Departures are Failures:
  • Vasco: "It's not always a failure that one team member or even several team members leave the team. Sometimes that actually is better." (10:33)
• Personal Growth as a Coach:
  • Salum, in hindsight:
    • "Currently I'm better equipped [...] I would have language that might be able to connect better." (11:27)
• Limitations and Readiness:
  • Not everyone is prepared for team-centric, egalitarian environments:
    • "[He] was not mature enough already for working in like this egalitarian agile way." (11:27)
    • Vasco notes: "Some people are just not ready to work in an environment where everybody's contribution is expected and appreciated." (12:15)
• The Value in Failure:
  • Salum’s story is acknowledged as a learning-rich episode: "That was a great story and definitely filled with learnings and insights." (12:15)

---

Notable Quotes

• Salum:
  • "It really doesn't matter what your title is. Like everybody is responsible for everybody." (02:08)
  • "Whenever we had retrospectives, his concerns were not picked up by the rest of the team." (06:34)
  • "A lot of his argumentation for what should be done came from a position of authority of experts instead of basing his arguments on data." (09:05)
  • "I really couldn't empathize to the extent that I could have really like formed a connection." (10:00)
  • "Currently I'm better equipped [...] I would have language that might be able to connect better." (11:27)
• Vasco:
  • "It's not always a failure that one team member or even several team members leave the team. Sometimes that actually is better." (10:33)
  • "Some people are just not ready to work in an environment where everybody's contribution is expected and appreciated." (12:15)
  • "Rather than making a case, he basically said 'I know better.'" (09:43)

---

Timeline of Key Segments

• [02:08] Salum’s leadership philosophy & origins in the Scouts
• [04:05–04:34] Discussion: Leadership models in Agile vs. traditional hierarchies
• [06:13–07:18] The architect integration failure: Story walk-through
• [09:05–10:00] Analysis of team dynamics and communication breakdowns
• [10:33–12:34] Reflections, lessons, and the idea that some departures are necessary

---

Summary & Insights

This episode offers a valuable exploration of why technical expertise alone doesn't guarantee success in Agile teams. Cultural fit, humility, communication style, and the willingness to adopt shared responsibility are crucial. Salum’s reflections underscore the need for Scrum Masters to develop empathy, cultural awareness, and mediation skills, especially when integrating experienced professionals with different backgrounds. Sometimes, despite best intentions, team fit just isn’t achievable—and that, too, is a form of organizational learning.

---

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.

[B]

Hello everybody. Welcome to one more week of the Scrum Master Toolbox podcast. And this week, joining us from beautiful and still warm at the time of recording Finland is Salum Abdul Rahman. Hey Saloon, welcome to the show.

[C]

Hello. Thank you. Good to see you again.

[B]

Absolutely. It's a pleasure to have you. So Saloom is an agile coach at Reactor, which is one of the pioneering agile consulting companies in Finland, and experienced leader driving sustainable knowledge work. He's passionate about enabling teams to work with complexity and conflict and he also builds communities in and outside work and has 18 years of experience working with software, mostly as a consultant within the public sector. So Saloon, that was a short intro. Tell us a little bit more about yourself and how did you end up becoming a Scrum Master?

[C]

Well, I think my, my path to Scrum Mastership starts like in the 90s. I joined the Scouts because a friend was, was in them. And one of the things you learn and learn in the Scouts is that like everybody has to contribute if you want to sleep in a warm, dry tent and to eat food. So I think like the leadership lessons you get from going into the woods with friends and coming back alive and healthy, which everybody having everything attached, is that it really doesn't matter what your title is. Like everybody is responsible for everybody. And taking that shared responsibility led me to volunteering while at university, like taking care of people. And then when I started working in software projects, I realized that often developers were just developing the code and then supporting the po, finding out what's actually necessary. People weren't picking up the slack on that. So I just started Doing it, it meant also I was taking care of my colleagues. And at some point I just realized that, okay, this is a formal position known as a Scrum Master. So I ended up being called a Scrum Master. And the more I did it, the less time I had to work on code and with more complex projects.

[B]

It's really interesting that you relate that to the position of the Scrum Master. And what I'm thinking is that's what we expected leaders to be in the first place. Why is it that Scrum Masters ended up being the ones that take that position of being the helpful contributor so that everybody can bring the best out of them and contribute to a goal that is shared?

[C]

Yeah, that's an interesting question. I think we do have this. I think it's like, I would like to blame like the military type leadership, but it's sort of interesting because originally the Scouts were formed to provide military training, military style training for children, like teenage boys, so that they would develop wilderness survival skills that would be useful when they joined the military. So, and there's been a lot of discourse, I think lately that even military organizations like SEALs are turning into more expert led organizations. But I do think there is a deeply rooted culture of hierarchical leadership in the Western world, at least in Finland, that I know of. Absolutely.

[B]

I think this would be a great topic for a much more in depth episode, maybe with some other people, Salum, maybe we get together and start digging into that story. But today's Monday, It's Fail Monday here on the podcast and we want to explore one of those stories of failure. Now, when we talk about failure, of course we are interested in the lessons learned. But lessons learned come very often in difficult moments. So Saloon, tell us that story, walk us through the steps, what was happening, what were the things you were observing, what ended up happening, and then we'll dive into the details and insights later. Tell us the story first.

[C]

So I was working in a large project as a Scrum Master. I think there were several teams, but I was a Scrum Master for one team, responsible for one part of the system in the public sector. And we had, we had started with a core team and we expanded and we brought in new people. And there was one senior software developer, software architect. He was hired with the title software Architect. We were a consultancy and he joined the project and he worked with us for some months and he was contributing good work, but he was struggling with the team. So whenever we had retrospectives, his concerns were not picked up by the rest of the team. And because we were an egalitarian team. That was not a problem for the team. And then I tried to have some discussions and talk with him about how to communicate in order to be heard, but the situation just escalated. And then we had. And then we came to a point where he was in open conflict with another developer. He would participate in retrospectives and sit there with his hands crossed. And this was the person who was hired as a software architect title. So this was a bit of a surprise for me. And I tried to have an NVC discussion with him and he just completely shut down. He would not share anything about himself anymore. And then he ended up leaving the project and leaving the company. And this I consider a failure on my part.

[B]

Interesting part of the story as I heard it was that this person felt that they were not being heard. But as far as I understand, and of course you were there, so you know, it doesn't seem from how you told the story that the team was making any effort to try to incorporate his insights. Do you have an idea why that was happening? Do you have an understanding of why that dynamic might have developed?

[C]

Well, there was a. I think one part was that there was some of the developers had already been working on the software since it was a greenfield project and he had joined six months after the start. So he was not part of the initial decisions and discussions. And then a lot of his argumentation for what should be done came from a position of authority of experts. Instead of like basing his arguments on data or.

[B]

Argumentation rather than making a case, he basically said I know better.

[C]

Yes.

[B]

Okay, that will definitely alienate some people, especially self motivated and experienced developers. Right?

[C]

Yeah, yeah. So he joined from a larger corporation, so he probably had a different cultural experience than the rest of the team. And I've worked with larger corporations, but at that point in my career, not a lot. So I really couldn't emphasize emphas. Empathize to the extent that I could have really like formed a connection.

[B]

One of the questions, I mean this type of conflicts can emerge at any time, right? Like it doesn't even need to be in the beginning of a project can be somewhere in the middle when people already know each other. We never know why these things might start in the first place, but we can certainly see them when they are there. And one of the things I was thinking about this story was that it's not always a failure that one team member or even several team members leave the team. Sometimes that actually is better. That doesn't mean we're happy that things didn't work well. But it means that we realize that it's not always a possibility that team and this individual could work well together. When you look back at that story, how do you think about this now that you have a lot more experience and of course you've seen a of lot other cases after that?

[C]

Well, I do feel that currently I'm better equipped to like just for maturity and working with a lot of people and working with large corporations, I would be in a better position to help him understand his situation. I would have language that might be able to connect better. On the other hand, before he left the company, I think he joined another project and there were issues with his behavior there as well. So it could just be that he was not mature enough already for working in like this egalitarian agile way.

[B]

That's also realization some people are just not ready to work in an environment where everybody's contribution is expected and appreciated. Absolutely. Well, that was a great story and definitely filled with learnings and insights. So thank you for sharing that saloon.

[C]

No problem.

[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 membership 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.

[B]

Slack we really hope you liked our show. And if you did, why not rate.

[A]

This podcast on Stitcher or itunes?

[B]

Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.