When a Distributed Team's Energy Vanishes into the Virtual Void | Steve Martin

Summary

Podcast Summary: Scrum Master Toolbox Podcast — When a Distributed Team’s Energy Vanishes into the Virtual Void | Steve Martin

Date: December 30, 2025
Host: Vasco Duarte
Guest: Steve Martin

---

Episode Theme & Purpose

This "Team Tuesday" episode of the Scrum Master Toolbox Podcast focuses on the challenges of distributed agile teams, particularly when the team’s energy and engagement vanish, leaving the Scrum Master and Agile Coach struggling to recover momentum. Steve Martin, an experienced Agile Coach, shares a real-life story about a geographically dispersed platform team facing resistance, disengagement, and structural barriers to high performance.

---

Key Discussion Points & Insights

1. Influential Books & Lightbulb Moments in Agile Careers

• Steve’s Inspiration: Steve highlights several formative Agile books, but singles out The Phoenix Project by Gene Kim as a pivotal influence, especially as he transitioned from Scrum Master to Agile Coach.
  • “It’s really about culture…So many lightbulb moments…That’s exactly the experience I’ve had.” — Steve Martin [02:29]
  • Biggest lesson: The danger of a single point of failure in a team or organization, and the need to spread knowledge and responsibilities.
  • Notable Quote:
    “You can’t have one person with all the knowledge in an organization. It [is] just so high risk.” — Steve Martin [04:21]

2. The Shift to Team Productivity & Team Failure Modes

• The Team as the Unit of Productivity:
  Vasco emphasizes that productivity now centers on teams, not individuals, increasing the impact of dysfunctional patterns.
  • Notable Quote:
    “The unit of productivity in software development is no longer the individual, it’s the team.” — Vasco Duarte [05:11]

3. Story: When a Distributed Team’s Energy Vanished

a. Team Context & Structure

• Platform/Infrastructure team within the telecommunications sector.
• Fully distributed across Europe (Italy, Budapest, Bucharest, UK).
• Average age over 40; established engineering backgrounds with some initial resistance to Agile methods.
• Pre-pandemic scenario (remote/distributed work less common).

b. Early Dynamics & Signs of Struggle

• Initial energy and engagement as the team formed and participated in workshops.

• Rapid decline in engagement:

  • Team members missing stand-ups.
  • Cameras off during meetings.
  • Lack of participation in retrospectives.
  • Decline in transparency and communication.
  • Data showed lack of focus and engagement.

• Scrum Master also doubled as an engineer, creating role conflict.

  • “People, people stop turning up for the daily stand up, cameras go off, people are not as engaged in the retrospectives and things start to ... The actual information doesn’t become apparent.” — Steve Martin [08:27]

c. Underlying Structural Challenges

• Team members were assigned to multiple projects (three or four at once), splitting focus and reducing sense of ownership.
• Lack of clear leadership and stakeholder buy-in aggravated the situation.

  • Absence of a unified backlog, conflicting priorities, and unclear timelines.

  • Scrum Master juggled engineering and facilitation duties, limiting ability to address dysfunctions.

  • “They weren’t working on one thing, they were working on multiple things. ... That is in my mind like setting up the team for failure.” — Vasco Duarte [13:15]

d. Failed Recovery & Lessons Learned

• Steve attempted to empower the Scrum Master and build team relationships, but found himself lacking the authority and experience to enact lasting change.

• The team persisted more as a group of individuals than a cohesive unit.

  • “To be honest, I didn’t. I didn’t solve it. And that’s another failure really for me.” — Steve Martin [11:57]

e. Broader Takeaways

• Leadership buy-in is critical: Without engagement and sponsorship from leadership, teams will struggle with conflicting demands and unclear priorities.

• Clear focus matters: Teams need a single, prioritized backlog and clear goals to succeed; working on multiple projects breeds disengagement and fear of failure.

• Recognize limits: It’s important to accept when problems are systemic and beyond an individual Scrum Master or coach’s ability to solve.

  • “For me... they weren’t really a team. Let’s call it out what it is. They weren’t a team. They were a group of individuals working on multiple different projects.” — Steve Martin [14:40]

---

Memorable Quotes & Notable Moments

• “You can’t have one person with all the knowledge in an organization. It [is] just so high risk.” — Steve Martin [04:21]
• “The unit of productivity in software development is no longer the individual, it’s the team.” — Vasco Duarte [05:11]
• “People stop turning up for the daily stand up, cameras go off, people are not as engaged in the retrospectives...” — Steve Martin [08:27]
• “To be honest, I didn’t. I didn’t solve it. And that’s another failure really for me.” — Steve Martin [11:57]
• “They weren’t a team. They were a group of individuals working on multiple different projects.” — Steve Martin [14:40]

---

Timestamps of Important Segments

• [02:29] — Steve discusses key Agile books and the “single point of failure” lesson from The Phoenix Project.
• [05:11] — Vasco underscores importance of teams as the productivity unit.
• [06:07] — Steve introduces the distributed platform team story.
• [08:27] — Early warning signs: disengagement, missed meetings, cameras off.
• [10:41] — Steve uncovers the team’s divided focus across multiple projects.
• [11:57] — Admission that the issue could not be solved; lessons about process limitations.
• [13:15] — Vasco contextualizes the inherent setup for team failure.
• [14:40] — Steve sums up the team’s lack of cohesion and functioning.

---

Conclusion & Overall Tone

The episode delivers a candid, humble account of the reality for many distributed teams: even experienced Agile professionals sometimes confront unresolved systemic dysfunctions. The conversation remains open, reflective, and empathetic, focusing on learning and the complexities of Agile coaching rather than simple solutions. Listeners gain practical insight into both the symptoms of disengaged distributed teams and the organizational preconditions that must be present for team success.

---

This summary distills the episode’s key lessons and narrative for Agile practitioners, team leaders, and anyone interested in the day-to-day realities of coaching distributed teams in complex environments.

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.

[C]

It is Team Tuesday here on the podcast and this week, joining us to talk about teams is Steve Martin.

[A]

Hey Steve, welcome back.

[D]

Hey, Vasco.

[A]

All right, so Steve, teams are the.

[C]

Focus of today's conversation.

[A]

But before we dive into that, share.

[C]

With us what, what was the book that most inspired you in your career as a Scrum Master?

[D]

Yeah, well, you know, there's been several books that have kind of hit me at the right time throughout my Agile career. You know, I can reel off a whole load, a whole load that sort of were just right for the right time. For me, things like Scrum Mastery by Jeff Watts. Five Dysfunctions Start with why. Culture Code by Daniel Coyle. Coaching Agile Teams by Lisa Atkins. The one that really stands out for me, the one that I think was at the big turning point, was the Phoenix Project. It's a book by Gene Kim. And the reason it sticks out for me is because I was just moving into coaching at that time and I was moving away from, from being a team Scrum Master and sort of looking a bit more beyond that. And the book itself isn't just about DevOps, right? It's about, it's really about culture. And so much of it resonated with me that I, it was so many light bulb moments was just going off all the time, is that that's exactly the experience that I've had. And it just because it follows a kind of a mock company and it's written like a novel, it can just flow so nicely and give you such a good insight into how organizations are structured and how teams are where they fit in the industry or in their organization. And so for me there was a lot of really good learnings from that. But it was a great inspiration because I took that book and I was like, right, everybody has to read this. Right.

[A]

Can you share one of those light.

[C]

Bulb moments that you had while reading the book, something that stayed with you even until today?

[D]

Yeah, well, the biggest one for me really was about being a single point of failure. And I actually had it in one of my scrum teams working with a software company was we'd have one guy that would just work all weekend to do a release, see that? The engineer and I think the project manager would be basically working with them. They just do a whole weekend and then they would just burn out on a Monday morning. They'd all go back, they go back to three days off because they were just burned. And we needed them. Right. We needed the lead engineer. And in the Phoenix project, that's exactly what was happening with this guy. There was this one guy who's just completely. Everything was in his head. He was the single point of failure and when it came to some real critical need, he wasn't there. And what they realized for the organizational challenge in the book was that you need to be able to share the knowledge and share the understanding and build and de risk this kind of thing happening because you can't have one person with all the knowledge in an organization. It just so high risk. So for me that was the biggest learning curve. But there's a lot of, a lot of good lightning bolt moments that go off.

[C]

Absolutely. And of course, when we think about organizations, how they are structured, one of the key components of any organization is the team. In fact, I usually say that the unit of productivity in software development is no longer the individual, it's the team. And that's why teams are so important and how they can be so impactful if they start to veer towards self destructive patterns. And that's what we want to hear today, a story about a team, Steve.

[A]

That maybe it all looked okay in.

[C]

The surface or maybe it didn't, but.

[A]

There were these kind of little behaviors.

[C]

And attitudes and patterns that started emerging and eventually became a problem for that team. So share that with us, tell us a little bit about the context so that we know what kind of team we're talking about and then walk us.

[A]

Through how those behaviors and patterns kind.

[C]

Of started growing and became a problem for the team.

[D]

Yeah, I mean there's quite a few different teams that I couldn't pick out really, but one that really Stands out based on what you're mentioning. There is a team, I worked, it was an infrastructure team, platform team, working in television, telecoms, telecoms a few years ago. And they were spread out all over Europe. Right. So you had product owner based down in Italy, you had hardware engineers based in Budapest, you had software engineers based over in Bucharest, you had designers based in the uk. I mean it was just, it was, and this is before lockdown, before COVID a few years before that. So the idea of trying to coordinate these, this kind of team was, was already a challenge. Right now they were a completely new agile team. They weren't, they, they'd been working together for a little bit, but they hadn't actually. I started with them and spent four days with them doing training and, and workshops and things to get them started up. The average age of the team was in there, it was over 40. So you can imagine this kind of bright spot coming in with all this great funky ideas of agile, trying to explain how to basically work differently for them. And they are quite long in the teeth. They've been in engineering for many, many years. So there was already a sense of resistance. Now I never put, I mean something I've learned over the years is never to put the blame of resistance on the individual. There's always a reason for their resistance that is beyond, it's a much broader, much deeper challenge that we need to be very, very cognizant of. But at the time I just felt that they were really against what I was trying to teach them or help.

[C]

Probably true, but maybe the context of why they were against it was not completely transparent.

[D]

Yeah, absolutely. And the issues that started to come up in the beginning, I think all teams, when you have that immediate burst of energy when they first come together, there's a, there's some real excitement, real, you know, there's a real buzz in the team when you start, when you start off. But very, very quickly the day to day gets, you know, the, the actual working patterns start to appear. The, they start getting pressure from elsewhere because they're not on, on that they haven't built the momentum because they're trying to acquire a different way of working. So what, what tends to happen is that you, you, you start off all right and then after, after a month or so, maybe, maybe a couple of months, you, you start to sense that there's something not quite right and you know, people, people stop turning up for the daily stand up, cameras go off, people are not as engaged in the retrospectives and things start to, you Know, the. The actual information doesn't become apparent. You're not being told. You're almost like the outsider. Right. And. And as a. And as a coach, it's really difficult to work with that. You're. You're there to help them. So. So I'm starting to see these patterns appearing of, you know, the Scrum Master, very. It was. Was also doing engineering in the team as well. You know, that the. What became apparent and it wasn't something that was given directly to me. I basically respond, to use my. My senses was that they were. This wasn't the only project that they were working on. They were. There was other. They had. They had about three or four others.

[C]

When did that became obvious?

[D]

It took a while. It took a good couple of months to.

[C]

How did it become obvious that they were maybe working on multiple projects at the same time?

[D]

Basically because when they started to stand off from things that they weren't as engaged, it became apparent that they weren't focused and it was reflective in the data as well. So I was starting to see that actually the data wasn't really.

[C]

What did you do then? Did you confront them?

[D]

Yes. I started working with the Scrum Master because I wanted to really empower him to build that relationship with the team and start to offer that. And he was under a lot of pressure because he also had commitments as an engineer. Right. So there was a conflict of interest. Plus he was an engineer, so he was part of the team, part of the engineering team. So for me, it was actually a real learning curve in trying to coordinate as well as coach this group. And I didn't feel I had the empowerment or the authority or the experience to really challenge them.

[C]

How did you solve it or did you solve it?

[D]

To be honest, I didn't. I didn't solve it. And that's another failure really for me is that the. The team themselves would just. It was just something that I couldn't. I couldn't really.

[C]

One of the things that I hear in the. In this story. So, okay, the obvious thing is that there's multiple levels of interaction, right? Like first you're a coach, then there's the Scrum Master. The Scrum Master isn't just the Scrum Master, they are also an engineer. So that's already two levels of interaction with just one person.

[A]

And then the team is working in.

[C]

Multiple projects, which probably means that the Scrum Master needed to keep a lot of other people happy. There's yet another level of interaction. Maybe you did have access to that, maybe you didn't have access to that. I don't know. But what is interesting for me in this story is that one of the core assumptions we have in Agile is that a team is working on one set of things, whether it is a backlog or a queue, if you're using.

[A]

Kanban or.

[C]

A very specific time frame in a sprint or an iteration. And what I hear from you is that none of that was in place. They were not working on one thing, they were working on multiple things. There was not one specific timeline because of course when you have multiple stakeholders, pardon me, there's multiple timelines. And that is in my mind like setting up the team for failure. And of course nobody wants to fail. So when people feel that they are fail, what do they get? They get scared, they get resistant, they get edgy. Right. Because when you are afraid of failing, you're always feeling that you're being judged by others around you. So it's not a very conducive environment for even the team to do whatever they were already assigned to do, let alone do that and improve their ways of working.

[D]

Yeah, 100%. And they also came down to leadership buy in as well. So it was very, very apparent that they didn't have the sponsorship and engagement from their leaders. So there was high demands of their time, high demands of their work they were doing where their stakeholders were just not invested into it. So, so they were, they were battling and obviously appeasing their stakeholders to try and they want to do a good job. Right. That's, you know, no, no, no team that I've ever worked with has ever wanted to be disruptive or be, you.

[C]

Know, do a bad job. Right?

[D]

Yeah. Do a bad job. Nobody wants to do. Norman, Kurt's famous quote, right? Everybody wants to, wants to do good, but we are all products of our environment, we're products of our, of our surroundings and the people that we're interacting, engaging with, the leadership they're engaging with. So for me, as a, as a team, I mean they weren't really a team. Let's, let's, let's call it out what it is. They weren't a team. They were a group of individuals working on multiple different projects and different projects and products.

[C]

And it also reminds us that we can't always solve all the problems, but it's important to have the language and the mental models to be able to identify them, to know what we are facing.

[A]

So thank you for sharing that story with us, Steve.

[D]

Yeah, no problem. All of these things are great. Learning, good experience. Took me a while.

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

[C]

It's the best place to connect with.

[A]

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.

[C]

I'll see you in the community Slack.

[B]

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 Masters know about this valuable resource for their work. Remember that sharing is caring.