Coaching the Outsider In—Helping a Distrustful Team Through Transformation | Danil Chernyshev

Summary

---

Podcast Summary

Podcast: Scrum Master Toolbox Podcast: Agile storytelling from the trenches

Episode: Coaching the Outsider In—Helping a Distrustful Team Through Transformation | Danil Chernyshev

Date: July 29, 2026
Host: Vasco Duarte
Guest: Danil Chernyshev

---

Episode Overview

This episode dives into the practical challenges of coaching a development team that is distrustful of organizational outsiders—specifically, Scrum Masters and Product Owners—amidst a broader Agile transformation. Danil Chernyshev shares a real-world case where developers and QAs faced disruption due to a change from a subcontractor-led structure to a more transparent, Agile organization, and Vasco guides Danil through nuanced solutions for building trust and integrating new ways of working.

---

Key Discussion Points & Insights

1. Background and Initial Team Dynamics

• Drastic Change Context:

  • The organization transitioned their development team from subcontractor to an in-house model as part of a digital transformation.
  • Teams had been isolated, with no contact with business stakeholders, limited planning, and unpredictable delivery cycles.
  • “They used to work together, they used to work isolated from business… every communication was prohibited.” —Danil (03:04)

• Transparency Suddenly Introduced:

  • The new process introduced visibility into work, adding Agile frameworks (Scrum, SDLC, CI).
  • Teams unfamiliar with Scrum; required to estimate work, attend new meetings, and integrate with stakeholders.

• Challenge:

  • Developers and QAs trust each other—but distrust outsiders, namely the Scrum Master, Product Owner, and Business Analysts.

---

2. Symptoms of Distrust and Coping Mechanisms

• Estimation Dysfunction:

  • The team provided non-differentiated story point estimates (almost all 3s and 5s), with no open discussion on why.
  • Whenever Danil probed for deeper conversations, the team would defer:
    • “They will discuss internally and bring answer back to me tomorrow or later in the day.” —Danil (04:51)
  • Suspected that the team was holding secret “internal” daily scrums, excluding the Scrum Master.

• Attempted Interventions:

  • Danil focused on trust-building and sharing that meetings are safe spaces—not for blame, but for problem-solving.
  • Considered introducing “no estimates” approaches, such as confidence-based sprint planning, realizing this would require broader organizational buy-in.

---

3. Root Causes Explored (07:50 – 09:32)

• Transparency as the Most Disruptive Change:

  • Vasco probes which change was most disruptive: “Was it the change that had to do with the organization processes, or was it more the change that the stakeholders were now all visible to them…?” (07:09)
  • Danil asserts transparency was most destabilizing:
    • “Now they exposed, process is exposed, and progress on the features is also exposed… I’ve noticed that they are trying with… estimates, they are trying to actually hide what’s going on.” —Danil (07:58)

• Product Owner’s Role:

  • There was a single, empowered Product Owner, aligning work streams and prioritizations.
  • But even the PO was new to the role, sometimes adding questionable stories (e.g., meetings) to the backlog, blurring priorities and possibly undermining trust.

---

4. Relationships and Trust Loops

• Product Owner–Team Dynamics:

  • Product Owner was trying to balance command-and-control with team protection, but their actions (like over-specifying stories) reflected lack of experience and confidence.
  • “It’s a big journey Ahead of us having and coaching product owner… It’s a big part of it. And because product owner is one person... not that challenging [as] the team…” —Danil (10:39)

• The Value of Insider–Outsider Trios (11:29 – 14:23)

  • Vasco recommends creating a “trio” of Product Owner, Scrum Master, and a well-connected team insider to prepare for refinement meetings and foster connection.
    • “When it’s the whole team and the product owner, the product owner will necessarily be the outsider... But if we establish a closer relationship with one of the team members... maybe we can move things forward.” —Vasco (13:04)
  • This smaller preparation group spreads trust and eases new practice adoption without formal training or top-down mandates.
  • Encourages organically seeding “no estimates” and more pragmatic practices via peer encouragement.
    • “What if we just try this no estimates approach for the next couple of sprints… kind of creating a collegial relationship between an insider… and the outsider…” —Vasco (13:04)

---

5. Notable Quotes & Moments

• On the real source of team discomfort:

  • “Transparency actually something that confused them the most.” —Danil (07:50)

• On team coping under new demands:

  • "I almost suspect that they had a separate daily Scrum without a Scrum Master." —Danil (04:35)

• On Product Owner’s learning curve:

  • "There were a lot of aspects and a lot of things to tackle… for months that we had with this organization and with those teams, it’s almost nothing and there is a big journey Ahead of us..." —Danil (10:39)

• On the trio approach:

  • "Kind of creating a collegial relationship between an insider... and the outsider... Do you see what I mean? Like, without anyone having to go there and doing official training and telling someone what to do..." —Vasco (14:08)

• Danil’s Reaction to the Trio Experiment:

  • “Yeah, I really like it. Definitely. That’s a great advice. Thank you for that. We’re definitely going to try it.” —Danil (14:23)

---

6. Actionable Takeaways & Closing Insights

• Building Trust Takes Time:

  • Progress will be slow when uprooting long-standing distrust and secrecy.
  • Coaching is as much about facilitating small, safe relational experiments as process changes.

• Start Small, Use Insiders:

  • Integrate the Product Owner (or Scrum Master) more deeply via relationships with existing trusted team members.
  • Use trios to experiment and prepare together—leading to more organic, less threatening change adoption.

• Coaching Both Sides:

  • Support the Product Owner’s learning journey just as much as the team’s, clarifying backlog priorities, and ensuring non-value-adding work (e.g., meetings as stories) is minimized.

• Experimentation Mindset:

  • Frame changes—such as dropping estimation or trialing “no estimates”—as experiments with clear boundaries and safety.

---

Timelines for Important Segments

• [01:42] Introduction of Challenge & Team Background
• [03:04] Explanation of Team’s Previous Isolation
• [04:39 – 06:37] Dysfunctional Estimation and Trust Issues Surface
• [07:50] Transparency Identified as Core Disruption
• [09:15] Product Owner’s Role and Their Growing Pains
• [11:29] Exploring Relationships Between Team/PO and the Trio Approach
• [13:04] Rationale and Potential for Trio Collaboration
• [14:23] Danil Embraces Experimentation / Actionable Advice

---

Conclusion

This episode offers a rich case study of the struggles teams undergo during rapid change, and highlights the importance of focusing on trust, relationship dynamics, and safe experimentation. For Scrum Masters and Agile Coaches, the key message is to leverage insider relationships and nurture new role holders to build transparency, one step at a time.

---

Transcript

[A]

Hey there, agile adventurer, just a quick question.

[B]

What if, for the price of a

[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 warfree 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 the 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.

[B]

Hello everybody. Welcome to our Wednesday the challenge question of the week and also the coaching conversation of the week. This week we have with us Danil Chernichev. Hey, Daniel, welcome back.

[C]

Hello. Hello Waska.

[B]

So let's talk about a challenge that you're facing. Something we can work through, we can explore together and eventually come up with some ideas for experiments. So what challenge do you bring to us this week, Danil?

[C]

So here's the story. Organization, I wouldn't name it had subcontractor that had a lot and that managed developers and the subcontractor actually worked only on development software for this particular organization modifier. So they decided to actually bring some transparency to the process because before that it was their developers. So they actually were sitting on the same tables in the same spots, but changed the contractor and changed the employee employer. So now organization wanted to bring them back and that was a part of digital transformation program that I was joined a few months back. So newly formed teams that not familiar with Scrum, they used to work together, they used to work isolated from business,

[B]

like individually isolated or team isolated as

[C]

the development organization isolated.

[B]

Okay, so they were working together but outside the current organization.

[C]

Yes. So every communication was prohibited. No plans. Like even if something was demanded, like a new feature, no plans when it will be delivered. What's going on? It just happened that something delivered. Now customer need to check if it works or not and how it works. So all that needs to be changed. And what happened is actually teams were formed. Customer decided to go with consulting organization to introduce some changes including Agile transformation as well as sdlc as well as CI services.

[B]

So they were kind of moved into a new organization and then all kinds of rules put on them to follow, like sdlc, Scrum and all of that.

[C]

Yes, okay, yes, yes, that's correct. And here's the thing.

[B]

I bet it felt a bit confusing for the team. So many changes at the same time.

[C]

Yes, it is. And here actually the challenge that they faced. So imagine developers and QAs know each other very well, but they don't trust anybody else. They don't trust Scrum Master product owner bas like they don't trust anybody. They were going through agile trainings and were forced to for example, estimate backlog with story points and use plain.

[B]

They didn't do that, right?

[C]

Yes, that was a new experience for them. We end up with estimates like three or five story points. It's either three or either five for every single user story. And there were no conversations like why this happened, what was going on and why you estimated that way. I tried, but every time when I asked a question I've got an answer that they will discuss internally and bring answer back to me tomorrow or later in the day. I almost suspect that they had a separate daily Scrum without a Scrum Master. So they handled two during the day. My ideas was first of all for sure working on trust issue and be getting some results from that by for at least when we have discussions, they see that it might be productive. They don't need another meeting, they don't need to meet outside of this meeting and nobody blames them for this discussion. And actually that was helpful and it's not shared with the stakeholders or executives. So it's not a blaming game, it's actually helping them. Another idea was to try no estimates techniques where maybe to start with the confidence level if they can deliver that spring goal with that set of user stories. But that requires some organizational changes as well. But I'm wondering what maybe you can also suggest to try and experiment because that's.

[B]

I'm thinking there are like. There's as. As it usually goes, there are multiple layers here, right? Like there's this overwhelming change layer, like changing management, changing organization, changing process, changing expectations. Potentially the software is the same, right? They were still working on the same software. So okay, so that isn't changing. Everything else is teams normally reorganize, right? Like you already pointed to that, right? Like they were brought in and then they had a daily with the Scrum Master. And your intuition is they probably had another daily without the Scrum Master. What do you think was kind of governing, kind of motivating or limiting the team's evolution? Was it the change that had to do with the organization processes and ways of working or was it more the change that the stakeholders were now all visible to them so that they were not hidden as it were when they were outside the organization? You said there was no communication, no planning and so on, but now there was and it was visible. Like what do you think was affecting the team the most when they finally joined the organization?

[C]

I believe that transparency actually something that confused them the most.

[B]

In what sense?

[C]

In a sense that now they exposed process is exposed and progress on the features is also exposed. So they actually I've noticed that they are trying with for example those estimates, they trying to actually hide what's going on. So it's once again my thoughts that it's a trust issue and they don't know what would be the consequences if

[B]

they will only one product, do they have only one product owner or are there multiple stakeholders that are working with that team?

[C]

It was one product owner for these particular, let's say for the work that they had, they worked only with one product owner. So teams were formed in a way that product itself was developed in different streams, let's put it that way. And product owner was actually empowered to make decisions, work with set of teams, prioritized backlog and doing a very good job, to be honest.

[B]

So do you, do you from your observation, is the relationship between the team and the product owner, is it like, is it the productive relationship? Is it, is it stable? Does the team feel that they can trust the product owner?

[C]

I think my feeling that they were thinking that they can trust product owner, but product owner also was trying to expose themselves in this role, which is obviously new because process has been changed and there was kind of command and control aspect to this. While trying to protect the team and trying to protect the team by adding, to be honest, by adding stories for meetings estimated in user stories that what product owner actually did.

[A]

So.

[B]

So there was also kind of a learning curve here where the product owner wasn't really sure what their responsibility and focus should be and that was perhaps even influencing the team. Right? Like because when you see user stories for meetings you're going to start losing trust in the product owner. I think

[C]

that was well, because it's a new process. There were a lot of aspects and a lot of things to tackle and I definitely believe that for months that we had with this organization and with those teams, it's like almost nothing and there is a big journey Ahead of us having and coaching product owner in terms of what needs to be in the backlog and how backlog should look like it's a big part of it. And because product owner is one person, it's a bit easier for me and not that challenging. Rather than the team that used to work isolated and now they hide everything.

[B]

Let's take that further because I think that the product owner relationship might be key here. Does the product owner have a good relationship with at least one team member? Like good meaning, you know, collegial, friendly, positive, constructive relationship with at least one person in the development team?

[C]

Yes.

[B]

Could we then start a trio habit where all of the product owner conversations would be the scrum master, that one person and the product owner. So that not to replace the refinement, but for example, to prepare the refinement. Right. Let's say that you have, I don't know, maybe two one hour meetings for refinement in a sprint, if it's a two week sprint, and that the preparation for that refinement would be done by the trio. So it would be the scrum master as the coaching agent, the product owner and then that more friendly team member, could that maybe help kind of spread the connection between the product owner and the rest of the team by providing kind of a help to the product owner before the refinement? So before the exposure to the team by somebody from the team

[C]

that in place. It started not that long ago. But I'm wondering what is the idea behind in terms of having for example, those estimation practice?

[B]

Yeah. So if I think about, like if we think about the team as a relationship constellation, so there's many people that have a relationship with each other. Right. When it's the whole team and the product owner, the product owner will necessarily be the outsider. So it's going to be very hard for the product owner to quickly gel with the whole team. Of course it can happen, but it takes time to get there. But if we establish a closer relationship with one of the team members who's already an insider, so part of the team and has been for a long time, maybe we can move things forward. Like, hey, let's remove the estimation of meetings from the planning. Like that's not adding value. Right. Or hey, what if we just try this? You talked about no estimates. What if we just try this no estimates approach for the next couple of sprints and see if that works. Right. So kind of creating a collegial relationship between an insider, so a team member and the outsider, necessarily the product owner, so that Ideas and experiments spread faster and they learn how to work together in a pragmatic way. Do you see what I mean? Like, without anyone having to go there and doing official training and telling someone what to do and what not to do and so on.

[C]

Yeah, I really like it. Definitely. That's a great advice. Thank you for that. We're definitely going to try it.

[B]

Absolutely. Well, at least you got an idea out of this conversation. And one of the things that I would highlight from this conversation is exactly this natural dynamic that we have a critical role, the product owner. And sometimes it's the Scrum Master who just joined, like you talked about before, that is an outsider to the team. And before we can start improving the Scrum, we need to figure out ways to bring that outsider. So proctor or Scrum Master to be an insider.

[C]

Yes, yes, definitely that helps and make it making this process of building a team with a new member easier. So definitely great advice and I appreciate it, Vasco.

[B]

All right, well, let's see how it goes. Thank you for sharing that with us, Daniel.

[C]

Thank you for asking.

[A]

Alright, I hope you like 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 talk, 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 [e-mail] membership because listening is great, it's important. But doing it together, that's next level. I'll see you in the community.

[B]

Slack. We really hope you liked our show. And if you did, why not rate this podcast on Stitcher?

[A]

Or itunes.

[B]

Share this podcast and let other Scrum Masters know about this valuable resource for their work. Remember that sharing is caring.