← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
The Database Migration Disaster— Why Software Development Teams Need Psychological Safety | Shawn Dsouza
00:13:10
Shawn Dsouza: The Database Migration Disaster— Why Software Development Teams Need Psychological Safety Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast...
Loading summary
Transcript13 lines
- [00:04]
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. Hello everybody. Welcome to our team Tuesday. This week we have with us Sean de Souza. Hey Sean, welcome back.
- [01:19]
B
Hey Vasco. It's great to be back.
- [01:22]
A
So, Sean, on Tuesdays we talk about teams and how sometimes they create their own problems. But before we go there, share with us what's the book that most influenced you in your career as a Scrum Master?
- [01:36]
B
Okay, so before we get to that part, I just want to share one common habit that I had. So me as a Scrum Master, I wanted to feel important at many times that I often ended up speaking way too much in the retrospectives. So whenever there was a retrospective I wanted to add value. I often started speaking too much at try to do a lot for the team. So that is a bit of the background. So one book that helped me overcome this whole situation was this book called the Advice Trap by Michael Stainer. This book was actually gifted to me by someone called Mahesh Jade, who is an agile coach and who has been on this podcast before. He's also a mentor and a great friend of mine and I'm so glad that he gave it to me because it really changed the way I thought about helping teams. As I said, I was talking way too much in the retrospective. I was stealing their spotlight. But the Advice Trap helped me to see how that instinct, while being very well intended, can actually get in the way. It made me reflect on my own behavior in retros and release planning, where I would often do a lot and again get into the space which actually belong to the team. These were the movements where I should have stepped back and helped the team realize their potential on their own. Sustaina talks about how giving advices quickly can shut down deeper thinking and learning in others. As Scrum Masters, that's not what we want. We want to build more empowered and self organizing teams. So why should other Scrum Masters read it? Right? Because I would say it helps you to stay curious longer and it helps you to hold back the great thoughts that you have and start asking the right questions. And trust me, when I was doing that, when I was asking the right questions, what I realized is the team thought about solutions so unique that trust me, I could never have thought about it. And there is one line of that book that often stays with me, is that what Michael says is the minute you think that you have the answer, he says that you stop listening. That is one trap that I try to avoid every single day. This is one of the best books that I have read.
- [04:13]
A
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.
- [04:58]
B
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.
- [05:36]
A
Can you give an example of what that means?
- [05:41]
B
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.
- [07:57]
A
RCA root cause analysis.
- [08:00]
B
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.
- [09:15]
A
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.
- [10:35]
B
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.
- [10:45]
A
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.