A (3:53)

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.

B (4:32)

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.

A (6:04)

And so by, by 100% baked, mean they would need to have all of the details, even the little minutia.

B (6:10)

Right. And so then user stories became overwhelmingly long.

A (6:14)

Hard to agree to, I'm sure.

B (6:16)

Yeah. And then they started to be like, you know, sort of be lawyers almost. Right.

A (6:20)

That's like, that's what it gets to. Of course.

B (6:23)

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.

A (6:56)

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?

B (7:46)

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.

A (9:28)

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?

B (10:30)

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.

A (10:57)

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.

B (11:14)

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.

A (12:20)

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.