When the Blame Game Between Product and Engineering Destroys Your Scrum Team From the Inside | Nate Amidon - Scrum Master Toolbox Podcast: Agile storytelling from the trenches

Loading summary

Transcript21 lines

[00:02]
A
Hello, everyone. Quick heads up before we start today's episode. The Global Agile Summit is happening on May 4th. Yes, May 4th. And even with a big blowout Star wars party, you have to join. It will be online and it's like always free to attend. We have four tracks this year that I'm really excited about and I think you will too. Stick around to the end of the episode to know what they are. If you want to check it out already now you can check it out at bit ly globalagile 26. That's the numerals 2 and 6 at the end. So one more time, that's bit ly globalagile 2, 6, all one word, all lowercase. And 2 and 6 are the numerals 2 and 6. So stick around till the end of the episode and I'll tell you what's in store. But for now, on to today's episode. Hello, everybody. Welcome to our Team Tuesday. This week we have with us Nate Amidan. Hey, Nate, welcome back.
[01:10]
B
Hey, pleasure to be back. Divasco.
[01:12]
A
Absolutely. So today's Team Tuesday, we'll talk about how sometimes team become their own worst enemies. But before we dive into that, do share with us, Nate, what's the book that most inspired you in your career as a Scrum Master?
[01:30]
B
Do I have to pick one?
[01:32]
A
You have to pick at least one, but okay, maybe not more than ten.
[01:36]
B
I'm gonna give you two. Okay. The first one I think every Scrum Master should read is Deep Work. And so the reason why Deep Work is so important is because software engineering is complicated and complex and it takes a lot of focus. And now that we're back in the office, a lot more teams are back in the office understanding that shoulder taps are expensive. And what I mean by that is there might be a time as a Scrum Master, you have a mildly irrelevant question. Like if you go and just bother an engineer or someone that's in the zone in Deep Work, you know, you're adding about a 15 minute time for them to get back into that zone. So I have everyone in my company read that book because at, at the core of we're serving servant leaders of Scrum Masters, we need to, we need to, to safeguard our engineers time. It needs, that needs to be one of the most important things that we do as Scrum Masters. Give them more time to do the things that they do because we can't do what they do. And then the second one I think is also really important for Scrum Masters is project to product. Now this one's A little more senior. You know, if you're a junior Scrum master just coming in, it's probably a good read. But if you start moving into more agile coaching and you starting to influence how organizations are thinking about how they operate at a program, at a programmatic level or a program level, really thinking about the importance of the team structure. And so, and I say this all the time, which is, look, you, the team needs to be sacrosanct and work should go to teams and people should go to teams and those teams can change and they can fluctuate. But the idea that there is a team of people that own a specific thing and they're responsible for that specific thing I think is one of the most important aspects to any sort of agile implementation, especially at an organizational level.
[03:53]
A
Yeah, absolutely great references, deep work and project to product. Absolutely amazing book. So I'll put the link in the show notes for everybody to go and find them and check it out from Nate's recommendation. Which one might be more interesting for you to start with. But Nate, of course, Tuesday is team Tuesday and we'll talk about teams now and sometimes they create their own problems. So we want to hear the story of a team a little bit about their context so that we know what we're talking about and then walk us through how those maybe little behaviors, patterns eventually evolved and became a big problem for the team.
[04:33]
B
Yeah, sure. So I was a Scrum master on a team that was building an internal mobile application. So it was for their internal employees. And so they had, it was, it was a front end, back end, you know, kind of a full stack team. And, and so the team was operating pretty well, but there, there was, there was tension between product and engineering. And what you, what I started to find was that as, as like issues would come up, they'd find bugs or features would be delayed. There started to be this, this blame game between product and engineering. And the product owner would say things like, you know, hey you, you guys missed this requirement. And then the end. And then the engineers would say, you never gave us this requirement. Um, and, and that started and it just progressed and got worse to a point where people were pulling up historical user stories to prove that they were right and who, and who was, who was wrong. Q. We had a team that a QA on the team. The QA started to be on the product team's allies. So it was kind of like product and QA against engineers. And you know, we really started to, uh. And then what? Then teams wouldn't accept stories unless they were 100% baked. Right.
[06:04]
A
And so by, by 100% baked, mean they would need to have all of the details, even the little minutia.
[06:11]
B
Right. And so then user stories became overwhelmingly long.
[06:15]
A
Hard to agree to, I'm sure.
[06:17]
B
Yeah. And then they started to be like, you know, sort of be lawyers almost. Right.
[06:21]
A
That's like, that's what it gets to. Of course.
[06:23]
B
Yeah. And so what really happened was it just slowed everything down. Right. It just put. It just put sand in the gears of everything and pretty soon it started to just completely fray. Right. And so that's a team where really things started to be self destructive. And I've seen this multiple times. This isn't an uncommon thing from my perspective, where you have this tension between product and engineering.
[06:57]
A
Yeah, absolutely. And this tension can develop for many reasons. And I really like how you describe the symptoms. Right. The stories started to be overly detailed, it was too slow to agree on all of the details, and they became almost lawyers because that's how it feels like. Right. Like that we are antagonists and we are trying to make sure that, hey, I'm gonna make you work at this with so many details that there's no chance for me to make a mistake. But then you make a mistake and then you figure out that actually you didn't have all of the details and the cycle just grows. But what is interesting is why does this pattern, or anti pattern, I should say, develop in the first place? So what were the potential causes for this pattern in that specific story, Nate?
[07:47]
B
Well, I mean, there could be a lot of root causes to having this scenario happen. Some can be at an organizational level, and this could just be a byproduct of a product director and engineering director and then a product VP and an engineering vp and they don't ever connect until even the CEO sometimes. Right. They can be totally different organizations and then it can just be personality driven. Right. And so you can get into the product owner position, not constantly having to give timeline forecasts that they don't trust and then constantly having to be the person in the meeting getting blamed for why things aren't happening. And then on the flip side, and so that can just devolve, Right. I mean, it can happen on the same thing on the engineering side where, you know, engineering bugs can. Can happen and they feel like it's product's fault. And so it really just starts to fray out a team. And so there can be lots of reasons. It can be personality driven, but it's something I always watch out for. I Always say the higher performing team you have, the less details there are in Azure DevOps or in Jira or in whatever task management system you're in. Because everyone's talking, right? They have a relationship, they know what they're saying. If you go back to a military perspective, you often hear about the special operations teams where they don't even really communicate because everyone just knows what everyone's doing. And so there's kind of a version of that on an Agile team or a Scrum team.
[09:29]
A
Yeah, I really like how you describe it. Right. Like that in very well functioning teams you don't see a lot of the details in whatever issue tracking system you're using because most of the conversations are happening real time and the decisions and adaptations are being done together with people together. Now this also in itself has other anti patterns like collaboration with other teams where they don't have the details. But without going into that level of detail, I think that this also highlights how important it is to, to have this good sense for what a great team feels like. Because an external, a project manager, a line manager, whatever, an external might see the attention to detail in the user stories as a positive sign when in fact it might actually be a reflection of lack of trust, lack of collaboration, antagonistic relationships and so on. Right?
[10:31]
B
Yes, no, absolutely that's the case. And yeah, that's one of the things that we really specialize in when we come in having done this in the military is understanding knowing how to pick up on those cues, trying to see the bad smells. For a team that can, can help you identify where there might be issues and then try to address them.
[10:57]
A
Yeah, that's a great reflection question. What are the smells you're noticing when you get into those meetings, those conversations? And that can help us kind of detect patterns before they become self destructing stories for the team.
[11:15]
B
Yeah, by trying to address those early, you can really, I mean it comes back, you can, it comes back to the business value of the team. Like if this gets bad enough, if the product and engineering are at odds long enough, the team can stop functioning completely and then the organization is just wasting money. Right. And so I, I think it's, it's so important to address early and you know what I ended up doing was this. One of my favorite things that I do a lot is I'll take a bunch of sticky notes and I'll draw a boat with two stick figures and one and then I say po and then the other one I put engineering and then I just stick them on people's computers because product and engineering are in the same boat. Like we need. We need to visualize and internalize that. It's one team. One team. It's one fight. We have to work together if we want to deliver value.
[12:20]
A
Absolutely. We have to work together if we want to deliver value. That's very well said. Thank you for sharing that story with us, Nate. Hi there, friends. Thanks for sticking around till the end of the episode. So let me tell you what's coming on May 4th. We're running the Global Agile Summit. It will be online and I want you there this year. We have four tracks and each one is built around real conversations with practitioners. No slides, no keynote theater, just honest interviews with people doing the work, just like you. The first track is AI in organizations where practitioners show what actually works. No hype, just AI that makes your Monday better. Happy Monday, everybody. And then we have the people track, honest conversations about putting humans at the center of how we work and keeping them there. And third is Agile in Construction. And yes, I really mean Brick and mortar construction. Lean and Agile. Actual job sites. Field leaders Removing waste. Teams transforming how buildings get built. Stay tuned for what I think will be a super track on Agile in construction. And the fourth track is Agile in Gaming. How game Studios Ship without Burning out Agile Inside the Creative Pressure Cooker over the years we've had more than 12,000 participants since 2017, the time of the first summit organized with the podcast, and this year we're making it easier than ever to join. You can register for free and get access to the summit sessions live during the event week. That's May 4th to May 6th. Or you can grab the Practitioner Pass and get immediate access to last year's keynotes from Jurgen Apollo, Gojko Adi and Miretech Kangas right now, even before the Summit starts. So grab your Practitioner Pass and start learning today. Head on over to Bitly GlobalAgile 26. That's 2, 6. The numerals 2 and 6 sign up and I'll see you on May 4th. And one more time, here we go. Bit Lynn Global Agile 26. All lowercase, all one word and 26. That's the numeral 2 and the numeral 6. I'll see you on the conference floor.

Summary5 min read

Episode Overview

Episode Title: When the Blame Game Between Product and Engineering Destroys Your Scrum Team From the Inside
Podcast: Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Host: Vasco Duarte
Guest: Nate Amidon, Experienced Scrum Master
Date: April 7, 2026

This "Team Tuesday" episode centers on a recurring dysfunction in Scrum teams: the destructive dynamic that emerges when product and engineering slide into a blame game. Nate Amidon shares a cautionary tale from his experience and provides actionable insights for spotting and addressing early warning signs before dysfunction takes root. The discussion also explores the importance of trust, effective collaboration, and how the structure and health of team relationships can predict overall team performance.

Key Discussion Points & Insights

Nate Amidon's Foundational Books for Scrum Masters

Deep Work by Cal Newport, essential for understanding focus and minimizing disruptions in complex work environments.

“As a Scrum Master, we need to safeguard our engineers’ time... It needs to be one of the most important things that we do.” — Nate [02:15]
Project to Product, for understanding how team structures affect organizational agility and delivery at scale.

“The team needs to be sacrosanct and work should go to teams... There is a team of people that own a specific thing.” — Nate [03:25]

(See References section for timestamps.)

Anatomy of a Dysfunctional Team: The Blame Game

[04:32] Nate describes a team building an internal mobile app, initially functioning well but soon poisoned by escalating tensions between product and engineering.

Signs the Team Was Becoming Its Own Worst Enemy:

Blaming between product and engineering over bugs and feature delays.

“The product owner would say things like, ‘Hey, you guys missed this requirement.’ And then the engineers would say, ‘You never gave us this requirement.’” — Nate [04:50]
Historical user stories used to “prove” who was right or wrong.
QA aligning itself with the product team, further polarizing the group.
Stories only accepted if “100% baked” — detailing minutiae to cover every edge case.

“User stories became overwhelmingly long ... they started to be like, you know, sort of be lawyers almost.” — Nate [06:10]
Result: Everything slowed down, and the collaboration culture was replaced by adversarial, transactional behaviors.

Deeper Causes and Patterns

[07:46] Vasco and Nate discuss potential root causes:

Organizational Structure: Product and engineering silos can exist all the way up the hierarchy, even to the CEO.
Role Pressures: Product owners being forced into unreliable forecasting reinforce defensive behaviors.
Personality Dynamics: Conflict can spread organically from individual stress or friction points.

“There could be a lot of root causes... Some can be at an organizational level... and then it can just be personality-driven.” — Nate [07:46]

Symptoms of Dysfunctional vs. High-Performing Teams

High-performing teams: Less detail in ticketing systems like Jira or Azure DevOps; rely more on active real-time communication.

“The higher-performing team you have, the less details there are in Azure DevOps or in Jira... because everyone’s talking, they have a relationship.” — Nate [08:30]
Dysfunctional teams: Excessive detail signals a lack of trust and poor collaboration.

“Someone external might see the attention to detail in the user stories as a positive sign, when in fact it might actually be a reflection of lack of trust, lack of collaboration...” — Vasco [10:18]

Detecting “Bad Smells” Early

[10:57] Importance of noticing cultural cues in meetings and interactions to pre-empt dysfunction.

“Trying to see the bad smells for a team can help you identify where there might be issues and then try to address them.” — Nate

Tactical Solutions & Takeaways

Visualization as a Catalyst for Team Unity

Nate’s practical ritual: drawing a boat with two stick figures labeled “PO” and “Engineering,” sticking the illustration visibly in the workspace to reinforce shared fate.

“Product and engineering are in the same boat... It’s one team. One fight. We have to work together if we want to deliver value.” — Nate [11:55]

Business Impact of Unchecked Dysfunction

The “blame game” dynamic can halt team progress and waste organizational resources if not quickly addressed.

“If product and engineering are at odds long enough, the team can stop functioning completely and then the organization is just wasting money.” — Nate [11:24]

Reflection Questions for Scrum Masters

Vasco recommends routinely asking: “What are the smells you’re noticing in meetings and conversations?” as an early-warning diagnostic.

Notable Quotes & Memorable Moments

On the cost of interruptions: “You’re adding about a 15 minute time for [engineers] to get back into that zone.” — Nate [02:00]
On adversarial user stories: “They started to be like, you know, sort of be lawyers almost.” — Nate [06:16]
On team unity: “It’s one team. One fight. We have to work together if we want to deliver value.” — Nate [11:55]
On noticing dysfunction: “Trying to see the bad smells... can help you identify where there might be issues.” — Nate [10:57]

Timestamps for Key Segments

Recommendations for Scrum Master reading: [01:29] – [03:53]
Story of team dysfunction/blame game starts: [04:32]
Detailed user stories as symptom: [06:04]
Root causes and organization-level patterns: [07:46]
Differences: functional vs. dysfunctional teams: [08:30]–[10:30]
Detecting early smells and patterns: [10:57]
Nate’s boat visualization ritual: [11:14]

Conclusion

This episode serves as a clear warning about the slow, corrosive effects of blame-driven relationships between product and engineering. The key takeaway—visualize and nurture a unified sense of purpose, address tensions early, and pay close attention to the subtle “smells” in your team’s communication patterns. High-performing Scrum teams succeed not because they are flawless, but because they trust, collaborate, and continuously choose unity over antagonism.

References:

Deep Work by Cal Newport [01:36], [02:15]
Project to Product [03:25]
Insights and visual metaphors [11:14]

Loading summary

Transcript21 lines

[00:02]
A
Hello, everyone. Quick heads up before we start today's episode. The Global Agile Summit is happening on May 4th. Yes, May 4th. And even with a big blowout Star wars party, you have to join. It will be online and it's like always free to attend. We have four tracks this year that I'm really excited about and I think you will too. Stick around to the end of the episode to know what they are. If you want to check it out already now you can check it out at bit ly globalagile 26. That's the numerals 2 and 6 at the end. So one more time, that's bit ly globalagile 2, 6, all one word, all lowercase. And 2 and 6 are the numerals 2 and 6. So stick around till the end of the episode and I'll tell you what's in store. But for now, on to today's episode. Hello, everybody. Welcome to our Team Tuesday. This week we have with us Nate Amidan. Hey, Nate, welcome back.
[01:10]
B
Hey, pleasure to be back. Divasco.
[01:12]
A
Absolutely. So today's Team Tuesday, we'll talk about how sometimes team become their own worst enemies. But before we dive into that, do share with us, Nate, what's the book that most inspired you in your career as a Scrum Master?
[01:30]
B
Do I have to pick one?
[01:32]
A
You have to pick at least one, but okay, maybe not more than ten.
[01:36]
B
I'm gonna give you two. Okay. The first one I think every Scrum Master should read is Deep Work. And so the reason why Deep Work is so important is because software engineering is complicated and complex and it takes a lot of focus. And now that we're back in the office, a lot more teams are back in the office understanding that shoulder taps are expensive. And what I mean by that is there might be a time as a Scrum Master, you have a mildly irrelevant question. Like if you go and just bother an engineer or someone that's in the zone in Deep Work, you know, you're adding about a 15 minute time for them to get back into that zone. So I have everyone in my company read that book because at, at the core of we're serving servant leaders of Scrum Masters, we need to, we need to, to safeguard our engineers time. It needs, that needs to be one of the most important things that we do as Scrum Masters. Give them more time to do the things that they do because we can't do what they do. And then the second one I think is also really important for Scrum Masters is project to product. Now this one's A little more senior. You know, if you're a junior Scrum master just coming in, it's probably a good read. But if you start moving into more agile coaching and you starting to influence how organizations are thinking about how they operate at a program, at a programmatic level or a program level, really thinking about the importance of the team structure. And so, and I say this all the time, which is, look, you, the team needs to be sacrosanct and work should go to teams and people should go to teams and those teams can change and they can fluctuate. But the idea that there is a team of people that own a specific thing and they're responsible for that specific thing I think is one of the most important aspects to any sort of agile implementation, especially at an organizational level.
[03:53]
A
Yeah, absolutely great references, deep work and project to product. Absolutely amazing book. So I'll put the link in the show notes for everybody to go and find them and check it out from Nate's recommendation. Which one might be more interesting for you to start with. But Nate, of course, Tuesday is team Tuesday and we'll talk about teams now and sometimes they create their own problems. So we want to hear the story of a team a little bit about their context so that we know what we're talking about and then walk us through how those maybe little behaviors, patterns eventually evolved and became a big problem for the team.
[04:33]
B
Yeah, sure. So I was a Scrum master on a team that was building an internal mobile application. So it was for their internal employees. And so they had, it was, it was a front end, back end, you know, kind of a full stack team. And, and so the team was operating pretty well, but there, there was, there was tension between product and engineering. And what you, what I started to find was that as, as like issues would come up, they'd find bugs or features would be delayed. There started to be this, this blame game between product and engineering. And the product owner would say things like, you know, hey you, you guys missed this requirement. And then the end. And then the engineers would say, you never gave us this requirement. Um, and, and that started and it just progressed and got worse to a point where people were pulling up historical user stories to prove that they were right and who, and who was, who was wrong. Q. We had a team that a QA on the team. The QA started to be on the product team's allies. So it was kind of like product and QA against engineers. And you know, we really started to, uh. And then what? Then teams wouldn't accept stories unless they were 100% baked. Right.
[06:04]
A
And so by, by 100% baked, mean they would need to have all of the details, even the little minutia.
[06:11]
B
Right. And so then user stories became overwhelmingly long.
[06:15]
A
Hard to agree to, I'm sure.
[06:17]
B
Yeah. And then they started to be like, you know, sort of be lawyers almost. Right.
[06:21]
A
That's like, that's what it gets to. Of course.
[06:23]
B
Yeah. And so what really happened was it just slowed everything down. Right. It just put. It just put sand in the gears of everything and pretty soon it started to just completely fray. Right. And so that's a team where really things started to be self destructive. And I've seen this multiple times. This isn't an uncommon thing from my perspective, where you have this tension between product and engineering.
[06:57]
A
Yeah, absolutely. And this tension can develop for many reasons. And I really like how you describe the symptoms. Right. The stories started to be overly detailed, it was too slow to agree on all of the details, and they became almost lawyers because that's how it feels like. Right. Like that we are antagonists and we are trying to make sure that, hey, I'm gonna make you work at this with so many details that there's no chance for me to make a mistake. But then you make a mistake and then you figure out that actually you didn't have all of the details and the cycle just grows. But what is interesting is why does this pattern, or anti pattern, I should say, develop in the first place? So what were the potential causes for this pattern in that specific story, Nate?
[07:47]
B
Well, I mean, there could be a lot of root causes to having this scenario happen. Some can be at an organizational level, and this could just be a byproduct of a product director and engineering director and then a product VP and an engineering vp and they don't ever connect until even the CEO sometimes. Right. They can be totally different organizations and then it can just be personality driven. Right. And so you can get into the product owner position, not constantly having to give timeline forecasts that they don't trust and then constantly having to be the person in the meeting getting blamed for why things aren't happening. And then on the flip side, and so that can just devolve, Right. I mean, it can happen on the same thing on the engineering side where, you know, engineering bugs can. Can happen and they feel like it's product's fault. And so it really just starts to fray out a team. And so there can be lots of reasons. It can be personality driven, but it's something I always watch out for. I Always say the higher performing team you have, the less details there are in Azure DevOps or in Jira or in whatever task management system you're in. Because everyone's talking, right? They have a relationship, they know what they're saying. If you go back to a military perspective, you often hear about the special operations teams where they don't even really communicate because everyone just knows what everyone's doing. And so there's kind of a version of that on an Agile team or a Scrum team.
[09:29]
A
Yeah, I really like how you describe it. Right. Like that in very well functioning teams you don't see a lot of the details in whatever issue tracking system you're using because most of the conversations are happening real time and the decisions and adaptations are being done together with people together. Now this also in itself has other anti patterns like collaboration with other teams where they don't have the details. But without going into that level of detail, I think that this also highlights how important it is to, to have this good sense for what a great team feels like. Because an external, a project manager, a line manager, whatever, an external might see the attention to detail in the user stories as a positive sign when in fact it might actually be a reflection of lack of trust, lack of collaboration, antagonistic relationships and so on. Right?
[10:31]
B
Yes, no, absolutely that's the case. And yeah, that's one of the things that we really specialize in when we come in having done this in the military is understanding knowing how to pick up on those cues, trying to see the bad smells. For a team that can, can help you identify where there might be issues and then try to address them.
[10:57]
A
Yeah, that's a great reflection question. What are the smells you're noticing when you get into those meetings, those conversations? And that can help us kind of detect patterns before they become self destructing stories for the team.
[11:15]
B
Yeah, by trying to address those early, you can really, I mean it comes back, you can, it comes back to the business value of the team. Like if this gets bad enough, if the product and engineering are at odds long enough, the team can stop functioning completely and then the organization is just wasting money. Right. And so I, I think it's, it's so important to address early and you know what I ended up doing was this. One of my favorite things that I do a lot is I'll take a bunch of sticky notes and I'll draw a boat with two stick figures and one and then I say po and then the other one I put engineering and then I just stick them on people's computers because product and engineering are in the same boat. Like we need. We need to visualize and internalize that. It's one team. One team. It's one fight. We have to work together if we want to deliver value.
[12:20]
A
Absolutely. We have to work together if we want to deliver value. That's very well said. Thank you for sharing that story with us, Nate. Hi there, friends. Thanks for sticking around till the end of the episode. So let me tell you what's coming on May 4th. We're running the Global Agile Summit. It will be online and I want you there this year. We have four tracks and each one is built around real conversations with practitioners. No slides, no keynote theater, just honest interviews with people doing the work, just like you. The first track is AI in organizations where practitioners show what actually works. No hype, just AI that makes your Monday better. Happy Monday, everybody. And then we have the people track, honest conversations about putting humans at the center of how we work and keeping them there. And third is Agile in Construction. And yes, I really mean Brick and mortar construction. Lean and Agile. Actual job sites. Field leaders Removing waste. Teams transforming how buildings get built. Stay tuned for what I think will be a super track on Agile in construction. And the fourth track is Agile in Gaming. How game Studios Ship without Burning out Agile Inside the Creative Pressure Cooker over the years we've had more than 12,000 participants since 2017, the time of the first summit organized with the podcast, and this year we're making it easier than ever to join. You can register for free and get access to the summit sessions live during the event week. That's May 4th to May 6th. Or you can grab the Practitioner Pass and get immediate access to last year's keynotes from Jurgen Apollo, Gojko Adi and Miretech Kangas right now, even before the Summit starts. So grab your Practitioner Pass and start learning today. Head on over to Bitly GlobalAgile 26. That's 2, 6. The numerals 2 and 6 sign up and I'll see you on May 4th. And one more time, here we go. Bit Lynn Global Agile 26. All lowercase, all one word and 26. That's the numeral 2 and the numeral 6. I'll see you on the conference floor.