When Communication Clarity Matters More Than Technical Complexity, A Healthcare Project That Fell Apart | Iryna Stelmakh

Summary

Podcast Summary: Scrum Master Toolbox Podcast

Episode: When Communication Clarity Matters More Than Technical Complexity, A Healthcare Project That Fell Apart
Host: Vasco Duarte
Guest: Iryna Stelmakh
Date: March 24, 2026

---

Episode Overview

In this candid Team Tuesday episode, Vasco Duarte welcomes Iryna Stelmakh, who shares a deeply personal and instructive story from her career: the unraveling of a highly complex healthcare project not due to technical shortfalls, but because of foundational weaknesses in communication and team alignment. The discussion dives into the criticality of making the implicit explicit, asking the right questions early, and the risks of unchecked assumptions in Agile projects—especially when cross-cultural teams are involved.

---

Key Discussion Points and Insights

1. Book Recommendations and Foundational Lessons for Scrum Masters

[01:14 – 04:59]

• Team Topologies:

  • Iryna praises this book for highlighting that Agile isn't just about process, but also about organizational structure, clear roles, and communication.
  • “Great Agile leadership is not only about frameworks, but it's about communication, influence and the ability to align people around shared goals.” (B, 02:20)
  • Personal anecdote: Facing a team with high resistance, burnout, and negativity after management and priority changes, Iryna relied on lessons from this book to rebuild team motivation and trust.

• Never Split the Difference (Chris Voss):

  • Iryna describes it as "next level"—critical for any Scrum Master who must influence, communicate, and negotiate without formal authority.
  • “Because the team is also like the stakeholder... the communication in swas is one of the most important skill that you have to have as a Scrum master position.” (B, 04:28)

---

2. A Painful Project Failure: When Communication Breaks Down

[05:30 – 12:44]

The Context

• Domain: Highly technical healthcare project—cancer treatment data analysis.
• Structure: Iryna was managing multiple projects (up to 9) and mentoring a Scrum Master lead. She only agreed to this project if there was a strong technical lead to own technical direction, while she focused on delivery and client communication.

The Initial Misalignment (Sales vs Client Needs)

• The project began with unclear requirements:

  • Sales communicated a need to “redesign a database”.
  • The client in reality needed a “migration to a different database type”—a similar-sounding, but fundamentally different requirement.

• For three months, the team operated under a partial discovery process—but communication and understanding never aligned.

  • “The project began with limited clarity about what the client actually needed... the client needed immigration to a different database type. So close, right? Such a similar request, but that was quite different things.” (B, 06:10)

The Compounding Factors

• Cross-cultural, remote communication (Ukrainian team for a US client, English as lingua franca).

• Divided responsibility: Iryna trusted the technical lead’s positive reports and did not participate in every technical meeting.

  • “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, that’s right. Everything is right.” (B, 09:09)

• Assumptions built up on both sides—project carried forward without validating those assumptions directly with the client.

The Results and Realization

• The client eventually lost confidence and left the project.
• Iryna reflects candidly on owning the failure, the damage of implicit assumptions, and the absence of proactive clarification.
  • “Communication clarity is more important than technical complexity. Because if you do not understand, it's pretty hard to execute…” (B, 07:53)
  • “Team must have people who can ask the right questions early or ask on the right time. Because we didn’t ask.” (B, 08:00)
• She emphasizes the lesson: Verify, don’t just trust—especially when the risks of misunderstanding are high.

---

Notable Quotes and Memorable Moments

• On Rebuilding Demotivated Teams:

  • “I joined a team with a high level of resistance... burnt out, with a negative attitude to the new manager. That book helped me to restart this motivation and build them around one goal again.” (B, 02:52)

• The Core Lesson:

  • “I realized that communication clarity is more important than technical complexity. Because if you do not understand, it’s pretty hard to execute.” (B, 07:53)

• On Power and Responsibility:

  • “I wasn’t the one who was able to stop the project... I didn’t have the power of position to make such decisions. But at the end, I was the last person and the first person who was responsible and who was asked, hey, why it happened?” (B, 11:30)

• Relying vs. Checking:

  • “I made a mistake. I relied instead of checking.” (B, 12:27)

• Project Management Parallels:

  • “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.” (B, 12:44)

---

Important Segment Timestamps

• Book Recommendations and Context: 01:14 – 04:59
• Beginning of Failure Story: 05:30
• Breakdown of Communication/Assumptions: 08:50
• Admitting Responsibility & Reflection: 11:00 – 12:44

---

Core Takeaways

• Communication > Complexity:
  Never underestimate the cost of unclear communication; technical expertise cannot compensate for misunderstanding the problem.

• Ask, Check, Verify:
  Scrum Masters must encourage questioning and clarification, especially when leading distributed or cross-cultural teams.

• Authority vs. Accountability:
  Even without decision-making authority, you may be held accountable. Don’t be afraid to press for clarity or escalate unclear expectations.

• Retrospective Learning:
  Integration of learnings from failure—shared openly—becomes invaluable for the agile community.

---

Recommended Reading (per guest):

• Team Topologies
• Never Split the Difference

---

This episode is a powerful reminder for Scrum Masters and Agile Coaches: seek clarity actively, don’t just hope for it, and remember that failure can be the crucible for your professional growth—if you’re honest about it.

Transcript

[A]

Hello everyone. Quick heads up before we start today's episode. The Global Agile Summit is happening on May 4th. Yes, May 4th. And even with a big blowout Star wars party you have to join. It will be online and it's like always free to attend. We have four tracks this year that I'm really excited about and I think you will too. Stick around to the end of the episode to know what they are. If you want to check it out already now you can check it out at bit ly globalagile 26. That's the numerals 2 and 6 at the end. So one more time, that's bit ly globalagile 2, 6, all one word, all lowercase. And 2 and 6 are the numerals 2 and 6. So stick around till the end of the episode and I'll tell you what's in store. But for now, on to today's episode. Hello everybody. Welcome to our Team Tuesday. This week we have with us Irina Stellmak. Hey, Irina, welcome back.

[B]

Hi there, guys. Hi Vasko.

[A]

So, Irina Tuesday is Team Tuesday here on the podcast? Of course. But before we dive into the team story, share with us what was the book that most inspired you in your career as a Scrum Master?

[B]

Oh, I brought here two tips for you guys. One is about Scrum Master. Precisely. And another book is more about next level. Could I say shit to be online Next level things, let's say like that. So first is about strongly influence and the work with the teams in Agile approach. And this is team topology. What I like about this book is that it explains something about many companies and what that companies miss Agile about Agile? Yeah, that it is not just about team process, but it's about how organization structure, teams and responsibilities. So the point is here, great Agile leadership is not only about frameworks, but it's about communication, influence and the ability to align people around shared goals. Why it was so important for me, I had the case where I joined the team with a high level of the resistance. Why so? Because they were working on the same goal. It was a mature team with a high level of professionals in their fields. Magento and net developers, 15 people, I guess. But on the way to their goal, the team lost their motivation because of management changes and because of the priorities changes which were related to the business. And the team were burnt out. I would like to say like that and with a negative attitude to the new manager. And when I joined, it was pretty hard for me to manage them and pretty hard to, you know, to restore this collaboration inside of the team and within the whole project because it was one of the team from the whole account. And that's why that book helped me to realize how to build a team around one goal again. So it helps me to. To restart, actually to restart this motivation and. And to build them. But here I will slowly shift my focus to another book actually to build the trust. And there is one more book, Never split the Difference. I'm really in love with that. This is next level things. This is more about collaboration and more about communication and the influence tactics. How you could talk with your teams, with your stakeholders. Yes. Because the team is also like the stakeholder of your. And how you could explain them better and make the right correct influence on their decisions. Because if you're a Scrum master, you are not the one who could decide how to develop. Right. And but your real goal is to facilitate the team and to serve them. So the communication in swas is one of the most important skill that you have to have as a Scrum master position. So never Split the Difference. May help you with that.

[A]

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]

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]

Why do you think that happened?

[B]

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]

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]

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]

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]

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]

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]

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]

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.