A (4:13)

That's actually a great quote. The minute you think you have the answer, you stop listening. So everybody out there pay attention to that quote because it's definitely a great mantra to have in mind. The minute we think we have the answer, we stop listening. And Sean talking about listening and thinking we have the answer. Sometimes it's the teams that think they have the answer and then get themselves into troubles. So we want to explore one of those stories, the story of a team and you know, gives a little bit of context to know how big it was, what kind of projects they were part of, but then walk us through those little behaviors or patterns that first seemed small but then grew and became a problem for the team.

B (4:57)

So yeah, I was in a project working with the team, I would say, which had all the potential. They were really skilled. And we were working in this project where we were working on a modernization project. If we were migrating some critical workflow of moving our database from the traditional RDBMS to a more cloud based system like Snowflake. And we had a very dedicated and focused team and a very strong product owner. But pretty early on, what I noticed was that our ceremonies weren't that great.

A (5:35)

Can you give an example of what that means?

B (5:40)

I'm getting to it. So during the ceremonies, as I said, team wouldn't talk about anything. They were just giving updates. We were kind of avoiding a lot of difficult conversation. Team wanted to speak a lot, but they were often avoiding it. Right. So on paper things would seem fine, but behind the scenes what I would say is there was a lot of tension that was building and we were not addressing it. What happened was after three Months we delivered the code to our breed prod environment and when the regression testing happened, I still remember this number and I don't think I would ever forget this. We had around 140 issues and. 140, 140 issues. It's a huge number. And as I said, it was a service based company and we were almost at the verge of losing that project. Right. So what happened was there were a lot of unspoken disagreements about the architecture. Somebody wanted a major refactoring, but some others just wanted to go with the flow and there was no collaboration or we just wanted to work on the surface level harmony and not actually work on the disagreements that the team had within. And this kind of later on impacted the team a lot. People lost their morale. There were a lot of sick leaves, a lot of vacation and one of the senior engineers quit mid projects and we had put in a lot of late night works but all the late night heroics kind of went worthless at the end. So again the biggest self destructive habit was that we avoided conflicts. Right. We were so obsessed with delivery and output, we ignore the health of the system that was producing it. That is our team. This is where we interpose again. For two days we didn't write a single line of code. We just did an RCA on all of those 140 bugs that we had.

A (7:57)

RCA root cause analysis.

B (7:59)

Yeah, the root cause analysis. One thing what we identified was this might sound very stupid, but it's a very simple thing. I still remember this and trust me, they'll never forget this again as well. We identified one small pattern. So whenever we were saving empty values in a traditional database system, it was getting stored as an empty value. But whenever we were saving that empty value in the cloud system, it was getting saved as none. This small issue caused 40% of the number, say 60 to 70% of the number of issues were because of this small item. And we overlooked it because we were not talking about. We were simply focusing on deliveries. Right. So this taught me two big important lessons. I would say the first one is, you know, delivery and reflections are not trade offs. You don't lose time by pausing, you kind of gain sustainability. And as Scrum masters, our job is not just to help the teams to go fast, but help them to go a distance. And yeah, so whenever we stop reflecting and stop learning. Right. That is when the team gets into the burnout territory. Absolutely. That was one of the.

A (9:15)

And also one of the other aspects which you already mentioned implicitly is that one of our responsibilities is to help the team grow in a healthy way. Right? It's not about delivering faster, although they will. It's not about delivering higher quality, although they will. It's about getting the team to feel that they are being productive and they are being collaborative and they are solving all the issues that they are facing. And they will face many issues without any major hiccups. Disagreements are not avoidable. They are important for that growth. And one of the things that you described in this story is this pattern of avoiding disagreement. So it's a great question for our audience is what are the disagreements that my team is right now avoiding discussing? Because that's probably where the big problems in the future will come from. As you said, this whole disagreements that were never talked about never allowed the team to actually discover the root cause for 40% of the bugs that they found in pre production. Right? It's like because nobody was talking about it, there was no space to actually discover what was going on.

B (10:35)

Very often happens that we just focus on the delivery and we often avoid these hard conversations and it all falls apart at one point.

A (10:45)

Very well said. Thank you for sharing that, Sean. 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. 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.