A (5:38)

And by the way, we have an episode with Bas Vode, so for those interested, check it out. He introduces less and why less was the approach that they took way back when at Nokia Networks. It's good to mention that because I was on the other side, on the Nokia mobile phone side and we were trying to adopt safe while the Nokia networks was adopting what is now less. At the time it wasn't called less, it was just scaled agile. But of course we do this. We read the books, we learn because we want to help teams succeed. But sometimes teams kind of create their own problems. So today's Team Tuesday. Karim. So we want to explore a story of a team and maybe how they develop these ways of interacting, these behaviors, these patterns that maybe started small in the beginning but eventually grew and became a problem for that team. Tell us that story.

B (6:35)

Well, I'm going to slightly defend the team in my answer because I believe, and I've come to believe this over the years, that individuals and teams do the best job they can do in the system that's been designed for them to do the work in the context in which they're operating. So if what we're seeing are anti patterns, our behaviors that we don't want to see or are exhibiting a lack of results, then for me it's less useful to look at the people and look at the teams and it's more useful to look at the system that's been designed around them. One, because you can't change people, you can change yourself, you can't change other people. And two, because you can change the system and that's going to have a disproportionate, disproportionate effect. So whenever I've seen this, it's always been system changes that, that have, that have resolved it. And, and I'll give you, I'll give you an example of one, by the way, I've been very influenced by Leif Babin and Jocko Willink is a, there's a great book called Extreme Ownership. No bad teams, just bad leaders. They say that or I like to change that to leadership. And, and you mentioned David Marquet yesterday. And I think that, that he's another person who's A big advocate of change the environment, not the people. So I'm going to take you back probably to somewhere around 2011 12. I'm a sort of scrum master, sort of agile coach, trying to scale. I'm at a big UK retail bank now. Big messy sort of developments going on and I've got a few teams with I'm working, but one of them in particular is exhibiting a crazy amount of defects in the Sprint. Like I'm talking, we were spending 30, 40% of the sprint testing, fixing, testing, fixing, right? Now you think of all of the productivity you're losing by spending time finding and fixing defects, right? And I couldn't work this out. I've never seen so many defects before in a team. So I'm a big fan of the technique specification by example or behavior driven development, whichever version or flavor you like. And a shout out to Goiko Adzic, the creator of that from back in the day. So I decided, let's have a session in the retrospective. Let's try and get developers and testers collaborating more because they're really not at the moment, developers are building in a silo, testers are testing in a silo, and it's back in its fourth and it's back and it's forth. It didn't help that they were at different, different ends of Pune out in India, right? They were in different locations, right? So this didn't help. So I was like, look, let's get together, let's have some chats early on and let's understand what we're building, let's create some scenarios, let's get a shared understanding before a line of code is written so that we can reduce and in my experience, you can reduce sort of 80, 90% of the defects if you use these techniques well, especially in non trivial software development. I thought, this has worked before, I think this is going to work brilliantly. And I had such stony faces, they're looking at me like, I don't want to do this. And I'm thinking, why would you not want to reduce defects? Like, is it me? Do you like defects? Do you enjoy them? I don't understand. And so basically I had no traction at all. And it was by chance I was talking to someone in a different team. And what I realized is the testers were from one company, the developers were from another company, which is why they went in the same office. And it gets worse. The testers were paid by the number of defects they found and then the developers were paid by the number of defects they fixed. Right. So you can't make this up. And I was thinking to myself, who's written this contract? This is a terrible idea.

A (10:35)

I think Kafka wrote the contract.

B (10:39)

What is going on? Right. So this is an example of how basically team wasn't talking, team wasn't collaborating negative behaviors, but actually it was entirely rational behavior. They were doing what was reasonable for them to do. And so we had to spend months going back and we actually couldn't change the suppliers. But what we did is we. We got testers and developers from one company, testers and developers from another company. So we still had the same number of people from each company, but we actually just had like one organization did one team, one did another team, and now they can chat to each other. And we did. I mean, this took about eight months. It took about eight months. We finally got to the point where the team was sitting together. They don't even have to be sitting together. Right? But they were talking and they were coming up with scenarios. They were ironing out those misunderstandings before they wrote a line of code. And then of course, when they came to test, they found far fewer defects. This is incredibly important because now that 30, 40% of the sprint that was spent doing all the test, fix, retest, retest, refix, that was just building new features or collaborating with customers or something else that's valuable. Imagine if you could be 30, 40% more productive, right? Just that tweak.

A (11:56)

Easily 30% more productive. I mean, can you think about it? Just the amount of time that is spent reading and writing emails and then doing the investigation to understand what the hell the email meant in the first place. Let's not forget that most humans are not very good at explaining themselves in a written format. Right? Like without this, you know, interaction, physical interaction where you see each other and point at things and do whiteboarding and whatever. That is such a great story that illustrates so well how a bad system will always beat down a good person. Every time.

B (12:34)

And I see it, and sometimes it's more subtle, people say, oh, my team just isn't motivated. And I was like, well, why are you hiring demotivated people? It's like, oh, we're not. It's like, okay, then you're demotivating them somehow, right? So stop doing that.

A (12:48)

Right.

B (12:49)

And what is it that you're doing that's leading to that behavior? It's always something. The culture and the systems and the governance is the problem. So when we address those, I think it's incredibly important, but you can't. It's very hard to be a high performing team in a dysfunctional system, right? Yeah, absolutely.

A (13:06)

Great story. Thank you for sharing that. Karim.

B (13:09)

No worries.

A (13:13)

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, 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 details@scrummastertoolbox.org 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.