A (4:59)

Absolutely. We'll put the link to those books in the show notes to make sure that everybody can easily find them. And I really like how you frame that. And of course you talked about a team a moment ago and we're going to talk about a team right now again. This time we want to hear from you the story of that team that self destructed. Sometimes these things start with little behaviors or patterns that then grow and become a problem for the team. So tell us that story, Irina.

B (5:30)

I have a great story here, Vasco. Actually this is one of the most painful story for me and I was thinking I'm okay to share it with you. But I decided to be very honest because again, this is the experience and the best things that we could do is experience integrated for the future to make the retrospective and to share it with others. To help the others to avoid right or to make it better. So the story is here. One of the most painful lessons in my career came from a project in the healthcare domain which is by itself complicated. Right. The project focused on research data connected to cancer treatment analysis, a very serious and technically complex domain. At that time I was responsible for multiple projects at once. I guess around 9 and I had to mentor a Scrum master lead, you know, so it was pretty hard to manage. This project arrived quickly after Covid. I mean many new contractors started appearing and I agreed to take just on the one condition. If we would have a strong technical lead who could own the Technical direction while I focus on delivery and client communication. So let's say I would be a scrum master and I would have a technical lead. So he will be responsible for the technical part. And yeah, the project began with limited clarity about what the client actually needed. Sales had communicated that we needed to redesign a database, but in real life, the client needed immigration to a different database type. So close. Right. Such a similar request, but that was quite different things. So for three months we worked through research and discovery phases trying to understand the problem. It was my idea, and thanks God we did this R and D concept, research and development. But the communication gaps was unclear. Questions and large barrier prevented us from identifying the real need. Eventually, the client lost confidence and left. And it was just an only one project in my career that I would honestly call a failure, partial failure from my side, because I was the last person who agreed to join and who agreed to manage the project. And here we have the lessons. I got the clear lesson. I realized that communication clarity is more important than technical complexity. Because if you do not understand, it's pretty hard to execute. Yeah, you have the probability to aim the goal, but the probability is low. It would be better to understand. Second thing is, team must have people who can ask the right questions early or ask on the right time. Because we didn't ask.

A (8:47)

Why do you think that happened?

B (8:50)

That happened because we didn't know exactly what we have to execute and we didn't ask properly. And we had the communication gap because at that time I was working with Ukrainian outsourcing team and we executed for United States client. So we were talking in English and this gap between the US and Ukrainian stakeholders made this issue. I didn't know, like, I didn't join each meeting, each technical meeting. I mean, and that's why the technical lead, when I asked him, he was always like, yeah, yeah, that's right. Everything is right. We. We know perfectly what we are executing. Yeah. Here we are talking about the database. We have to, like, we had to make the redesign. And I was like, yeah, okay. Then I came to the client and client agreed. Yeah, yeah. Because we were talking with the technical lead and he knows, actually.

A (9:53)

So, yeah, it was like miscommunication, but implicit. Like there was a lot of implicit assumptions that were not kind of first of all discovered, but then they were not explored by different people that were involved. Is that so. Is that how you see it?

B (10:11)

Yeah, exactly. We were able to explore that. We were able to stop that project from the beginning. As soon as, like, the client was ready to move. But the right thing was to stop it and to ask at first to clarify, to make this clarity, you know, and then to move it. I have one more thing. And that was exactly the same situation where the project was already in the delivery phase. The client was ready for the development, but there was no clear how to execute it. And previously I made this code, but it was my initiative, you know, and I. I wasn't. I wasn't the one who was able to stop the project, actually, but I did this. But it was the project from another domain, and in this case, I wasn't able to stop it. I was responsible just for execution, as a project manager, Scrum Master. That's why I didn't have the power of the position, you know, to make such decisions. That's why I say, okay, if you like, my managers say that I have to move further with that and you are aware about the unknown part. So let me proceed then, because if I do not have the right to choose, right, but here should be the agreement, because at the end, I was the last person and the first person who was responsible and who was asked, hey, why it happened.

A (11:44)

Of course. So basically you accepted the project, knowing that there were gaps, but trusting your managers that everything was correctly understood and defined. But in the end what happened was that it really proved that not everything was at least agreed in the same way or understood in the same way.

B (12:07)

Partially, yes. I wouldn't say that I know about the gap, because if I knew it would be differently, probably I didn't know. I was told that everything is fine and everything is clear, but you have just to manage the team and to move further, you know, and that's why I relied on that. I made a mistake. I relied instead of checking.

A (12:29)

Yeah, absolutely. That's actually a great lesson, right? Relying instead of checking. It's okay to trust, but we should always check, because in the end, as you said, we're always the ones that are going to be asked, why didn't this work exactly?

B (12:44)

Do you know the project management phases? Like we have monitoring and controlling phase. That's why we could rely. But you have to monitor and control at least time to time.

A (12:55)

Absolutely. That's a good reference. Thank you for sharing that story with us. Irina, welcome. 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 Mirete 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 ly globalagile 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.