Letting Teams Own Their Process Through Working Agreements | Prabhleen Kaur

Summary

Scrum Master Toolbox Podcast: Letting Teams Own Their Process Through Working Agreements

Guest: Prabhleen Kaur
Host: Vasco Duarte
Release Date: February 9, 2026

---

Main Theme

This episode centers on empowering Agile teams to take ownership of their processes, particularly by fostering working agreements collaboratively rather than imposing best practices. Prabhleen Kaur (Certified Scrum Master and Agile Coach) shares personal stories and advice rooted in practical experience, focusing on how Scrum Masters can facilitate team-driven improvement and genuine engagement.

---

Key Discussion Points & Insights

1. Prabhleen’s Journey to Becoming a Scrum Master

[02:10]

• Prabhleen began her career at a startup, unexpectedly stepping into a PM role due to good communication skills after the previous PM left.
• Grew into Agile through self-learning, on-the-job experimentation, and a deepening appreciation for the people-centric nature of the role.
• Background in psychology (Master’s degree) influences her work, particularly in understanding team dynamics.

Quote:
"I absolutely understand that this is a people's job and how good of an impact it can have when you see people around you happy and, most importantly, motivated because they are doing a great job. So it's a very fulfilling role."
— Prabhleen Kaur, [02:50]

---

2. Initial Failure: Imposing Best Practices

[04:11] Fail Monday Segment

• Prabhleen shared a formative mistake: joining a new team and immediately prescribing “best practices” without context or team buy-in.
• Result: The team felt burdened, disengaged, and reduced Agile practice to “just following the rules.”
• Realized through one-on-ones and retrospectives that her approach stifled team ownership and understanding.

Quote:
"I ended up giving the best practices to a forming team without realizing that they are not understanding where am I coming from. [...] It was more of following the rules and the help broke loose."
— Prabhleen Kaur, [04:15]

---

3. Shift in Approach: Coaching, Not Teaching

[06:37]

• Now invests time in understanding how teams have functioned before intervening.
• When working with new or forming teams, starts by identifying challenges together.
• Facilitates collaborative discussions on process, inviting team perspectives and ideas.
• Frames issues as shared challenges to solve, not directives to follow.

Quote:
"I make sure that I sit down to explain them what the situation is... I voice it out so that I can understand how the team wants to take that up. So when that becomes a conversation, you get the best practices, of course, but then also you get the team members who are willing to do it because they voiced it out."
— Prabhleen Kaur, [06:51]

---

4. Creating Working Agreement Sessions for Team Ownership

[09:09]

• Emphasizes that people shape the process—they must create the rules, not just follow them.
• Formal working agreement sessions are opportunities for the team to design their process, including:
  • Rules for communication channels
  • Definitions of “Ready” and “Done”
  • Scheduling, time zones, and daily routines
• Encourages question-based facilitation rather than instruction, allowing diverse perspectives to surface and fostering psychological safety.

Quote:
"Everybody comes from a different space of mind. They have different experiences [...] So, when we sit down for conversation, half of the problem is solved."
— Prabhleen Kaur, [09:25]

---

5. Scrum Master's Role: Facilitator, Not Enforcer

[11:32]

• When joining a pre-existing team, making immediate changes can create unnecessary conflict.
• Instead, position oneself as a collaborator, asking: "What do you want to solve? What do you want to improve?"
• The difference between teaching and coaching: Coaching is about guiding teams to their own solutions.

Quote:
"If we go there and start challenging, we are creating conflict immediately. But if we go there and ask them, what do you want to solve, what do you want to improve? Then we are creating collaboration."
— Vasco Duarte, [11:38]

Memorable Moment:
"There's always difference between teaching somebody and coaching them. So our part is to coach them."
— Prabhleen Kaur, [12:03]

---

Notable Quotes & Memorable Moments

• On Empowering Teams:
  "It's about coaching the team, not teaching them."
  — Prabhleen Kaur, [05:44]

• On Process Ownership:
  "People make the process. [...] if I'm going to sit down where I want them to follow a certain process because that's how the team is formed, it's never going to work because it brings resentment."
  — Prabhleen Kaur, [09:10]

---

Important Timestamps

• [02:10] — Prabhleen’s unique entry into Scrum Mastery and her people-centric approach
• [04:11] — Failure story: Imposing process and its repercussions
• [06:37] — How she shifted to inviting team input
• [09:09] — The philosophy and practice of team-owned working agreements
• [11:32] — Framing the Scrum Master’s role to create collaboration over conflict
• [12:03] — Distinction between teaching and coaching in Agile

---

Conclusion

This episode underscores the importance of allowing Agile teams to own their processes through participatory working agreements and collaborative problem-solving. Prabhleen’s journey exemplifies the paradigm shift from enforcing best practices to coaching teams, inviting dialogue, and enabling real ownership—a mindset that builds not only stronger teams but also more resilient and adaptable Agile organizations.

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 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.

[B]

Hello everybody. Welcome to one more week of the Scrum Master Toolbox podcast. And this week joining us from India is Prableen Kaur. Hey Prabhleen, welcome to the show.

[C]

Hi Vasku, thank you so much for welcoming me. I'm really glad that I'm here in a conversation with you.

[B]

So let me tell you a little bit about Prableen before we get started with the question. She's a certified Scrum Master with more than 7 years experience helping teams succeed with safe Scrum and Kanban. She's passionate about clean backlogs, powerful metrics and dashboards that actually mean something. She's also known for making Jira behave and we all know how hard that is, driving agile transformations and helping teams ship value consistently and confidently. So Prabhlin, that was a short intro. Tell us a little bit more about yourself and how did you end up becoming a Scrum Master?

[C]

All right, so my journey to being a Scrum Master is really interesting. I was the fresh graduate engineering graduate and I chose not to take the engineer's job and I joined a startup there. I had an absolutely different role to start with but I think the fate had it and the PM in the organization chose to step out because she had some commitments and suddenly the role came to me on the grounds of me having good communication skills. So that was my crazy start point and from that I started to self learn and I explored my job on the practical grounds. Basically I learned things while I was doing them. So that's a little bit of how I got into it. And honestly I have started to love what I do because I absolutely understand that this is a people's job and how good of an impact it can have when you see people around you happy and most importantly, motivated because they are doing the great job. So it's a very fulfilling role. Apart from that, a little bit about myself. I am actually a very poignant person, to be very honest, but I read a lot. And I also have a book published on Amazon that's absolutely unrelated. That's poetry. And I've lately finished my master's degree in psychology and I do use it at work. So that's a little bit about myself.

[B]

Yeah, absolutely. And that degree in psychology, I bet, is incredibly helpful in understanding many of the dynamics that we face at work.

[C]

That's true.

[B]

So on Monday, because today is Fail Monday, here on the podcast, we like to explore stories of failure. Not because we like to dwell on failure, but rather because the they all present some very interesting lessons learned. So Prablin, share that story with us, that moment that as a Scrum Master you tried your best and as so often happens, the best just wasn't good enough at the time. But tell us that story first. We'll dive into the takeaways later. So tell us the story.

[C]

Sure. So I think that especially when we are new to the team and when the team is forming, we all want to start doing the right things right away. And I ended up giving the best practices to a forming team without realizing that they are not understanding where am I coming from. And of course I have not let them be in the practical situation to understand how it is going to help them. So that resulted in the team feeling a little burdened. It was more of following the rules and the help broke loose, actually. And then I understood the situation because I was in one on one. The team members and I at that point understood that the sense of the process they have is just following the rules and it is not sitting very right with them. So I gradually brought that up in the retrospective and we unlearned the things we learned. So that is the filler story I wanted to bring in. Because that's one thing which Scrum Masters often end up doing. As we come with a lot of experience and when we get a new team with us, we want them to do everything rightly. But that's not the point. It's about failing and learning. So we have to let them at a point where they understand that they are forming and they need to bring up their rules themselves. And that's why we also have these working agreement Sessions and the point where teams sit down to understand that how do they want to function? And are these best practices any best practices for them? So that's the story I wanted to share. And it actually gets down to asking the right questions. It's about coaching the team, not teaching them.

[B]

So when you think about this kind of, let's call it, process, right, like we're entering a team, we have a lot of experience and energy that we want to express through the knowledge and helping the teams. But we can be sometimes a little bit directive. I guess that's perhaps one word you would use for that process. What do you do these days? Probably having this experience that you've had and having lived through that story, what do you do today to express that willingness to help differently from your side? Right? Because one way to express that willingness to help is to tell the teams what they need to do. But there are other ways. So today, when you approach a new team, how do you get that engagement started? And what kind of attitude and approaches do you bring when starting to work with a new team?

[C]

So when I join a new team, I make sure that AI spend good amount of time understanding that how the team has been functioning. If they were a team before, I were a scrum master to them. But if that's not the case and they weren't a team, then probably we are learning things together. So there are major problems when it comes to the things we want to manage like a team, maybe our schedule or how we are going to pick up the work for ourselves. So in such situations, I make sure that I sit down to explain them that what the situation is, it could be a problem, it could be a challenge, and I voice it out so that I can understand that how team wants to take that up. So when that becomes a conversation, you get the best practices, of course, but then also you get the team members who are willing to do it because they voiced it out. So. So my way of doing things now is that I ask them that, okay, this is the situation I see and how do you want to take that up? And it could be a situation like people are not participating in retrospective, for example, maybe they're not liking how it is conducted, that has to do with ceremonies, or maybe the practices we have in terms of how we are delivering things, how we are interacting with stakeholders. So I try to understand that, hey, this is the problem and this is how we like to solve it. What are your views about it? And this is how, because I'm getting input from them, they also Follow the rules. So it, it becomes a practice. It's not just set of things we have to do. That that has really helped me.

[B]

So if I hear you right, it's also about first synchronizing that we are trying to solve the same problem, then having a conversation. And I guess you, you would probably even say inviting them to come up with ideas. Okay, on how do we solve the problem. Sharing out ideas, of course, but then inviting them to share their ideas and then getting to an agreement of how we are going to solve that specific problem. And then of course, then doing the follow up as we would usually do. Is that how you would describe it?

[C]

Yes, that's absolutely correct.

[B]

Yeah. And I guess that the context here, or perhaps the objective here is to allow the team to own how they work rather than us being the owners of the process. The team can bring their own ideas and they can feel that commitment, that ownership, that how they work is really up to them. Right?

[C]

That's true. Because I firmly believe that people make the process. And if I'm going to sit down where I want them to follow a certain process because that's how the team is formed, it's never going to work because it brings resentment. Everybody comes from a different space of mind. They have different experiences and also they have worked differently. Not necessarily. We all have the same context of the framework we are in or probably how we want to take things up. So when we sit down for conversation, half of the problem is solved. So that's how I look at any of the problems or things which we want to solve. And here is the space where you can sit down to have formal working agreement sessions and it can have conversations about definitions of ready done. That's one part of it. You can also talk about the channels you want to communicate on, what kind of communication should go on which channel, what are the rules we want to follow as a team? In fact, when do we want to start our day as a team for that matter? Because it also matters when we are in different time zones. So when do we want that same space to come in, how the schedule should look like? So rather telling them everything can come up as a question, as a situation, and we can seek the input that hey, here is where we are. How do you want to take that up? And because we have like six, seven people in the team, there are six, seven perspectives and then counter questions. So I get the space where, because I am being asked that, okay, what if this do not works out? Or if we have a better idea, should we follow that in that space. Whenever we are taking that up, I am making sure that my space of failure is reduced because of course I've taken up the conversation already and people are thinking about that what ifs, right? So it has really helped me. And that's true for even the new teams. And also if you have joined the team newly, that's another part of it because generally all the repos are set if the teams are old and they have their own way of doing work. So this also helps there because you are the new one, you need to learn their ways. And if you think that something is not working out, then it should not come as a challenge to them that hey, okay, you're doing it wrongly. It should be a conversation that I see that there's scope. Do you people agree? And then if you don't get the agreement, maybe try, try other time, try other way. But then it's all about letting them understand that they need to drive things.

[B]

Yeah, absolutely. What you said is also important because when we're joining a new team, if we go there and we start challenging, we are creating conflict immediately. But if we go there and ask them, what do you want to solve, what do you want to improve? Then we are creating collaboration. So it's also about how we frame our role. Right? Like are we there to help them or are we there to tell them? And those are totally different perspectives.

[C]

That's true. There's always difference between teaching somebody and coaching them. So our part is to coach them.

[B]

Absolutely. Well said. Thank you very much for sharing that story with us, Prablin.

[C]

Thank you.

[A]

Alright, 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. 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 scrummaster toolbox.org membership and join the community 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 or itunes? Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.