The Scrum Master's Art of Saying "No" with Suruchi Patki

Join us in this episode as Suruchi Patke, an experienced Agile practitioner and Scrum team coach, shares her wisdom on mastering the nuanced skill of saying "no". Discover how protecting your team’s autonomy and keeping focus can prevent scope creep and enhance self-management. Suruchi offers practical tips and compelling examples on how to say "no "in a way that builds trust and nurtures a healthy team dynamic.

Ever faced the dilemma of balancing urgent tasks with essential team retrospectives? We have the perfect solution for you. Suruchi recounts a real-life scenario where a developer wanted to skip the retrospective to meet pressing deadlines. Instead of simply dismissing the idea, she facilitated a productive 35-minute session by proposing alternative solutions. This segment highlights the importance of flexibility and open communication in maintaining team agility and delivering quality outcomes without sacrificing opportunities for improvement.

Managing stakeholder expectations can be tricky, especially when new tasks emerge mid-sprint. In this episode, we explore a scenario where additional data migration tasks threatened to overload the sprint backlog. Suruchi emphasizes the necessity of setting boundaries and conducting technical feasibility analyses to negotiate realistic sprint goals. Learn strategies to protect your team’s capacity while ensuring stakeholder satisfaction. Join us as we empower Scrum Masters to lead their teams with clarity, confidence, and assertiveness.

Connect with Suruchi on LinkedIn:
https://www.linkedin.com/in/suruchi-patki-b0710b195

Visit the Great American Ballpark and Purple People Bridge in Cincinnati, Ohio:
https://en.wikipedia.org/wiki/Great_American_Ball_Park
https://purplepeoplebridge.com/

Join the Alliance! 👇

Transcript

Mark: 0:06

Welcome to the Agile Within. I am your host, Mark Metze. My mission for this podcast is to provide Agile insights into human values and behaviors through genuine connections.

Suruchi: 0:20

My guests and I will share real-life stories from our Agile journeys, triumphs, blunders and everything in between, as well as the lessons that we have learned. So get pumped, get rocking. The Agile Within starts now. Before we get started with our episode, I'd like to share a short message with you. If you're a Scrum Master, agile Coach or just into Agile, I've got something you absolutely don't want to miss. It's the Online Scrum Master Summit happening June 25th to June 27th. If you're a Scrum Master, agile Coach or just into Agile, I've got something you absolutely don't want to miss. It's the Online Scrum Master Summit happening June 25th to 27th and, best of all, it's totally free. This virtual summit is perfect for anyone wanting to level up their skills, whether you're a newbie or a seasoned pro. You'll hear from some top-notch speakers like Bob Galen, Gitte Klitgaard, Ma arten Dalmijn and Sandy Mamoli. They'll be joined by many other great speakers sharing their best tips, tricks and techniques to help you grow in your role. Trust me, this is a great chance to get inspired and empowered in your Agile journey. So go ahead and sign up at onlinescrummastersummit. com.

Mark: 2:00

And now on with the show. Well, hey, welcome back everybody. It's the Agile Within, with your host, mark Metz. Our guest today is Suruchi Patke Suruchi. Welcome to the Agile Within.

Suruchi: 2:15

Hi Mark, how are you?

Mark: 2:16

Doing great. Thank you so much for being our guest here. Suruchi Patke is a passionate servant leader, an Agile practitioner, a scrum team coach and she's also a change agent. She's known as Scrum Mom based on her commitment to guiding teams and applying scrum and protecting them from distractions and burnout, and her interests include equity, inclusion and belonging. Unbiased servant leadership, integrity working out and contra dancing leadership integrity working out and contra dancing. She loves spending time with her daughter cooking, painting and bouncing on a trampoline, but not all at once. So that's pretty interesting, saruchi, all right. Well, you're from Cincinnati, ohio, here in the States. So, saruchi, if I were coming to Cincinnati for a day, what's one thing that you would say that I absolutely could not miss doing?

Suruchi: 3:07

First of all, thank you so much for thinking about visiting Cincinnati. I would love to have you and I would love to take you to Great American Ballpark, which is a very good baseball stadium in Cincinnati, ohio. It is located in the downtown of Cincinnati. It is amazing. A lot of baseball matches happen there. It's a major league baseball Cincinnati Reds and it has been open long time, back in 2003. I was in different companies, different groups. I used to organize some of the networking activities at this ballpark stadium. We used to go there as a group. We used to have drinks, some snack, watch match, had a lot of good stuff in talking and chatting. Once the game is over, it doesn't matter who wins. We used to come out. There is a pretty good area around to walk. It is in downtown, so there is a purple bridge also. On that bridge there is a pretty good space to walk on. Look at water. So it's a pretty good area. I mean we can easily spend a day over there. I'm looking forward to have you.

Mark: 4:19

That sounds fun. Well, today's episode is titled the Scrum Master's Art of Saying no. Why is it important for a Scrum Master to be able to say no?

Suruchi: 4:31

There are multiple reasons we want to say no. A few important reasons that I would like to call out are, first of all, protecting the autonomy of the team, making sure if they are comfortable in handling anything that has been requested. The other few reasons that I would like to call out are saying no helps in maintaining the focus on the current priorities. It helps in overall preventing the scope creep. At the same time, it encourages the empowerment and self-management. Now a lot about giving reasons for saying no. Right, but then again we can't just keep saying no, I can't do this, no, we can't do that.

Suruchi: 5:17

That again falls back on us as negativity. It shows, maybe, lack of respect towards requests that has been raised. It also shows rudeness at some point. So how to say no is very important, even if you know that saying no is the right thing to do at this point. How you are saying no is very important. How tactfully you handle the situation is very important. What is the logic behind saying that no is very important? There are enough number of reasons, mark, I have to say no, which will protect the overall autonomy of the team, maintain the focus, protect the team's capacity and avoid the scope creep. Empowerment and self-management. These are key areas I focus on before I say no.

Mark: 6:07

If we're always saying yes, then people are going to continue to come to us because they're always going to get their wishes granted, at least in the short term. Because if you're always saying yes, at some point you're not going to be able to deliver on everything you promised. If you always say no, then people will stop talking with you, they'll stop coming to you and they'll just see you as inflexible. So we don't always want to say yes and we don't always want to say no. So there's some sweet spot in the middle that we want to hit. And, saruchi, we've talked about some real world examples of how you have learned how to say no effectively, not to alienate people, but to have a conversation and be able to be open with others and really create that trust that others have in you. So I think you had an example that we talked about. To lead things off here If a stakeholder comes to you and asks you to add work, just random work in the middle of a sprint, so talk to us about that scenario.

Mark: 7:18

Give us the background. Who asked you to do this work? How did it unfold? Share the story with us.

Suruchi: 7:26

Yeah, sure. So I do remember that I was working for employee engagement program for marketing team. It was the sixth day of my spring and I received a call. My name is from Eric. He's one of the key stakeholder. He just said hey, good morning, what's going on? So, rochi, can we consider implementing donation page as well in the current scope of work for this trip? I said okay. I mean, I didn't say okay. I said okay in my mind because I wanted to actually take a pause and say no immediately, but I did not because that would not be a right way to say no and, as you know, as a scrum master, definitely I would want to say no because that would definitely disrupt the overall flow of the current sprint goal. That may enhance the burnout for the developers because of adding new work. Then what I did is I told him that I need to get in touch with the product owner and see how it goes and I will get back with him.

Suruchi: 8:33

I got in touch with my product owner, adam, I called Adam and I went over the scenario that Eric is saying that can we just implement donation page as well along with this contact us page that we are going to deploy at the end of this spring. Then he said that let's just ask team. If team is okay, let's do it. I said, okay, if team says okay, let's do it. But what about the current sprint goal? We have specific sprint goal to achieve and then that needs to be accomplished, right? I mean we have not received any negotiation or anything like. Can we do this donation page and can we skip contact us page works, nothing like that. But then he said PO said that directly talk with the developers and say see what they say, if they can do it, let them do it.

Suruchi: 9:30

Unfortunately I couldn't agree with him at that spot and I didn't show that disagreement. Also at that time, from Scrum Master's standpoint, I identified the opportunity to say no tactfully. I just told Adam that okay, I'll see what the developers will say and think about it and as I was sitting around closer to developers, I can do that. That is what I told to po. Then I had my quick thought process, I made up my mind and I called eric. I asked him a question eric, is there any specific new value that we are going to receive by creating donation page along with the contact us page? Do we have any specific profitability by implementing and publishing both the pages at the same time. Eric was kind of fumbles on my call. He. He was expecting me to give a call like or email like. Oh yes, the team said yes, and we are going to do this, this or we understood the plan.

Suruchi: 10:31

He was expecting that actually and then, when he listened to this question, he took maybe a 20 seconds pause. He said nothing. And then I said okay, do we have any numbers or anything like that which will give us an idea why to implement both these pages at the same time? He said Sriracha, do you know I need to get these details and I need to get back with time? He said, sriracha, do you know I need to get these details and I need to get back with you? I said not a problem, take your own time. Unless you come back to us, the team will continue working on the current Spring Vault, which is contact us page, and as soon as you will get some business criticality behind it, we will definitely see how we can have that conversation with the developers. If they can see, technically it is feasible, they have enough capacity and we will go from there and I completely respect that you have some different plan for our team. So this is how I navigated that conversation.

Suruchi: 11:28

After some time, adam came to my desk and asked Suruchi, did we talk to developers? I said, unfortunately not. I asked this question to Eric and he said that he will get back with us with this information. Adam said, okay, that's fine, that's a good way actually to handle it, because even he was not sure about proposing that question to developers. So this is how I indirectly added this maybe a path which navigated that request and pause it for some time. And do you know, we were on the sixth day Till ninth day morning. We did not hear back from Eric on the explanation and typically we don't add anything on the ninth day. This is too late. Team cannot accommodate anything new. It is too late to add anything at a at this point in the sprint. So we decided not to consider that in that sprint. However, we were still planning to discuss that topic at the end of sprint review, when the team will present the contact us with.

Suruchi: 12:34

So this was the situation which I can definitely remember when me being a scrum master, I was having different options of making that thing work, but there were two, three different reasons. I didn't take that option because I didn't receive any logical reasons from stakeholders. I don't want to burn out my team. I don't want to burn out my team and I don't want to first of all distract, because that conversation with developers will definitely distract them from the current sprint goal. My experience if we are going to give that sword in PO's hand, they may ask it to them and that creates a little bit pressure on developers Like, oh, po is asking for something we are going to say no. It will not look good and overall it will create a chaos. So indirectly I tried to apply this approach and tactfully was able to say no.

Mark: 13:25

I find it interesting that you went to the product owner about this request. That came from Eric, I believe it was, and the product owner's response was to ask the team. More times than not, when the request comes outside of the team and outside of the product manager or the product owner they can be very protective of. Well, no, this is what our goal is for this sprint and I don't want to jeopardize what we're doing in this sprint for some other work going. So that was interesting to me that the product owner was more amenable to that option. I've used another option. So I really liked the way that you said no without saying no. You really, in a sense, you asked them to just pause for a minute and make sure that this was something that was worth pivoting for or pulling into the sprint. Another way that I've done it is, I've just said is this more important than the sprint goal that we currently have? And if it is, and the product owner or the product manager agrees with that, then maybe we do pivot at that point, but more times than not. That then maybe we do pivot at that point, but more times than not.

Mark: 14:35

If you ask the question, can you just give us till the end of the sprint. So you were five days into the sprint, right? You said you're on the sixth day. Yes, so if you just ask, can you just give us a week to finish out this sprint? If it's important, can we start it in the next sprint? You're not saying no, you're just saying not right now. I really like that situation, love the way that you handled it. You weren't very abrupt. So give us an update. How did things end up with you and Eric?

Suruchi: 15:10

So have you observed Eric approach to me and not to the product owner? That shows that Eric finds me more approachable than product owner because he knows that Suruchi is empathic servant leader. Suruchi mostly tries to consider the request, she can handle the situation, she can actually coordinate with all the team members and she can actually help in creating the user story if needed. That's why he thought that I am the right person to get everything done. But unfortunately that was not the fact, because before an empathic person or maybe a kind person, before an empathic person or maybe a kind person, I am a servant leader also, and I will not let my kindness come in the way of my team's capacity or overall team's healthy mental health. First I am a servant leader and then my other characteristics come in picture. After that.

Suruchi: 16:09

Also, me and Eric, we stayed in good connection because I asked him questions. As soon as you would provide me those details, I would be happy to have additional conversation with developers and unfortunately he was not having data. So it ended up at some logical point where he couldn't do anything and he felt like, yes, next time I would ask anything to Suruchi, I should have a logical reason behind saying anything or asking it. So this is how it ended up. Right now also, I'm in great relationship with him. I respect him. Basically, if he is just asking something in the middle of the stream, it doesn't mean that he's a bad person or he's in a bad spot.

Mark: 16:49

So that was our first story. I understand you've got a second story here.

Suruchi: 17:02

It's about a team that wanted to skip a retrospective, or maybe multiple retrospectives. So talk to us about that, surjit, meeting each sprint goal and very much techy. One of the deity member, jim, came to my desk on the last day of SIG and said Suruchi, some of the work is still pending to achieve the sprint goal. Can we skip the retrospective because we can use that one hour to complete that work? Can we just skip it and maybe we can have it for the next sprint directly? Then, of course, as a scrum master, I don't want to say yes and it's difficult to say no. I don't want to say yes or cancelling or skipping at all, but that's, that's another tricky situation and I have to say no. But I I didn't say no and this is how I tried to overall provide the other options. I asked a few options, such as is this okay or is it possible for the Dev Team members to share their improvement areas? Maybe in a WebEx chat box? Like this is from me, I would like to see improvement. Maybe in coordination piece. Like this is from me, I would like to see improvement. Maybe in coordination piece. Or maybe I would like to enhance the overall engagement of team members in sprint review, or let's use this to what kind of? Can you share your improvement area and what went well, or some of the accomplishments in the chat, or can you update our retro board first and socialize those and maybe we can have a discussion at some later convenient point? That could be one of the option. When I mean to say later, it could be either before our sprint planning, which typically occurs on the first day of sprint, or maybe later in the day, maybe around 5 pm or so, because the board is already ready. We can come together, we can go over with that. Then we will actually finish the entire work. So we will not be taking some time during the day on the last day. You will just keep it at the last activity. He just said oh, who is going to keep typing all that? We don't have that much time to type, right. Instead of that, we can just type, we can just code right. We can spend our energy in typing our code rather than just typing those retro items. Because typically me as a scrum master, I take ownership of facilitation, of retrospective typing, all those items, improvement areas, everything and facilitating. So he said that then that will be more time consuming. It will take more energy and you never know if everyone will agree to that because there was he was the only one at my desk. Then there is another coordination piece which you need to run that get buy-in from everyone that instead of having meeting, we are going to first do this and meet later, so that will be more work. Then there is another coordination piece which you need to run that get buy-in from everyone that instead of having meeting, we are going to first do this and meet later, so that will be more work. Then I said then there is a second option. Can we just meet before sprint planning? That's what we will do. We will just spend a few minutes extra 30 minutes, 45 minutes extra and then go over with our retro items, because if we don't meet at all, how we will understand the overall opportunity for improvement for upcoming sprints and also how we can cheer each other about the accomplishment? Then we said oh, if we have to add a few minutes before sprint planning, that will be too long. Sprint event. It will be too long. Sprint event. It will be too long. We get bored and then if we want to keep it at five, it will be too late. It's the last day of print, we all are tired. Then instead of that, he proposed me instead of that, can we just have a quick 15-20 minutes retrospective? I said first of I am not emphasizing on how much time we are going to have during retrospective. The goal of retrospective is to come together and share if there are any improvement ideas, any challenges associated with tools, interactions, processes that team is facing. How much time does it take is not important. As long as we get the outcome of our retro in our hand, you're good to leave. I mean time boxes are for references. If we are achieving the outcome of that event, we are good. The focus is not on sitting in that meeting and talking and feeling in that time. And then he said okay, let's have it, because I did not emphasize on oh no, we have to have one hour retrospective, we have to have everything, no. And then he said yes, and he was one of the key and very active developer who always wants to address everything. If he comes with like, oh, this is a problem. He is very open, which is good. I, from agility standpoint, being open is really good. But then if you're not trying to be open about your challenges and trying to steal that opportunity from everyone. That is difficult. So somehow, by providing the negotiations or say option, I was able to get the retrospective on the same day. We were able to have the retrospective, team was able to share and we were able to finish it up in 35 minutes and everyone was okay. I did not push it to have it for a full one hour. This was my experience where I didn't say no, I just gave option and try to try to navigate that through different lanes and came to the same conclusion.

Mark: 22:41

So giving options, that's a very nice way to refrain from saying no, because it gives the other party a sense of control, a sense that they matter. It gives them a sense that they really do have a say how things are going to play out. So I like that you presented some options and that you said it's not based on just filling a time box. How many times do we decide, make decisions on meetings and all we're trying to do is fill time boxes, when our customers really don't care how much time we spend in certain events or certain meetings? They're looking for outcomes, exactly Like you mentioned.

Suruchi: 23:22

Yeah, exactly that's why I think that's the point he liked the most, because I did not emphasize on 60 minutes time block. I said if you guys wrap up in 20, you can. I don't want to hold you guys. And then it all went well. Not only that, after retrospective they were able to continue with the remaining part of the sprint work. They were able to crack the sprint goal also. So that was a tricky situation on the last day, but we were able to come out with flying colors.

Mark: 24:00

Another anti-pattern that I've observed is when I've seen teams struggle to make time for sprint retrospectives is they always have work they need to finish at the end of the sprint and it's we need to sacrifice the time for the sprint retrospective and we need to focus to finish up the work that we committed to in the sprint, and it makes for a nice conversation. I wonder why that is. Why is it that we've had this pattern of whatever it might be?

Mark: 24:21

One two, three sprints where we feel like we're being rushed at the end. Are we taking on too much? Are people asking us to do things that we feel like we can't realistically do in the first place? Should we be saying no when people are asking us to do things? Because I have that pleaser mentality that's built into my DNA as well, and it's easy to say yes and to see someone happy and you're pleasing them, you're making them happy. But yeah, you have to think I think you mentioned this too is that you have to think well, what's the right thing? You could say that and you could make people happy, but you're probably going to make them happy in the short term. You're not going to make them happy in the long term.

Suruchi: 25:08

Absolutely. That is very well said. Just for pleasing some people. If you want to say yes, yes, it is not going to be long lasting. The other thing is that I observed why some of the developers they hesitate to say no while accepting the work is they are under the pressure if, if we say no, we will come across as lazy people or maybe we don't want to work, and that is not the mindset any any organization should have or any organizational culture should have, because when they are saying no, of course there is something prioritized going on on their plate. It's not that they are sitting, and I think scrum muscle plays vital role in this in the working agreement itself.

Suruchi: 25:58

If developers express that, such is, sometimes a lot of work comes in the middle of the sprint and it is difficult for us to say no because if we say no, they just put it on us oh, this team is lazy, they don't want to work. Then a lot of allegations instead of that. Can someone logically speak on our behalf to show that? Yes, we are, my team is working on this. They don't have right now capacity. Can you wait for this much time and come back to us? We will definitely help you. So the team is willing to help you, but after finishing something. So that is something a good thing to do, like shielding team, but only if they are comfortable. If they say that oh, we are comfortable in saying no, we are just going to say that no on face, don't interfere. So I think, as a scrum master, I would try to understand if they want you to interfere in saying no, they want someone else to cover them, or no.

Mark: 26:56

So I think that gives us a nice little transition as we bleed into our third situation that you were going to explain about overloading the sprint backlog. So is there a different scenario here that you have in mind for us, where you had a team that continued to overload the sprint backlog beyond what the data said that they were able to complete?

Suruchi: 27:20

Yes, absolutely.

Suruchi: 27:21

That situation occurred quite a few times. You know, right, mark, many, many times. Stakeholders they have their meetings at their level. They continue to meet with executives, leadership. They have a lot of fancy conversations going around the technical changes that are happening, how their product is competing in market and, based on that, all these conversations are evolving. Once they get to know that, oh, we are running behind, we are not on top in the market, all of a sudden they understand, oh, this is something new, we need to bring it. All of a sudden they understand, oh, this is something new, we need to bring it. All of a sudden they start requesting new work and at the team level we, like developers, architects, data analysts, we have no idea. Sometimes there is a gap between those two conversations. We have no idea what's going on and then the stakeholders start keeping high expectations and start adding the work, overloading sprint backlog. That typically flow comes from stakeholders to product owner, product owner to team. That is the flow and then the product owner expresses that typically in the sprint planning.

Suruchi: 28:30

So for one of my team, there were a lot of items related to data cleanup. So the sprint goal was to clean up the data for OmniPIM database, which was a really important critical database. Team agreed and team was already actively working on achieving that sprint goal. All of a sudden, stakeholders also thought that it would be a good idea if, in addition to data cleanup, can we have data migration also to a new, smaller database. And that's a big effort because whenever there is a migration, there are going to be two, three different teams involved. Okay, so data migration is not going to be straightforward when there is another server or database involved. Now there is a point again opportunity to say no, right, because you already said yes. In the last sprint review we already confirmed that database cleanup is going to be the next sprint goal. We are going to finish that successfully. We got all consensus on that migration. This is big piece. This will at least increase the overall capacity by 50 percent.

Suruchi: 29:43

Dave's started feeling I heard that po already expressed that, but then I I felt some of the some of the complaints coming from developers like they felt like sushi. Do you know? We have. We have committed to that sprint goal of cleaning the database and now this is coming up. So even if we will achieve database cleanup, we will feel like we have we are not good enough. We are not satisfying stakeholders.

Suruchi: 30:11

So consistently overloading the sprint goal gives the sense of demoralization to the team. They will never feel that we are good enough, even if they are experts. From my standpoint in that situation, this is what we did. As a scrum master, I always encourage the more conversation around whenever the sprint backlog becomes overloaded in the sprint planning. So I started asking the questions. We did speak in the sprint review that data cleanup is reasonable work based on the capacity. Is there a specific reason we are adding migration work? Also Because that work came in a meeting which occurred after review. Then product owner said that of course there were some reasons to add that work, but it is more around having more work done rather than more quality.

Mark: 31:07

More work over more quality.

Suruchi: 31:10

Yes, more work. So quantity over quality. So cleaning up is definitely critical has been identified. Prioritized migration was not critical because for migration the other database readiness is also important. Developers said that we don't know if the, the new database where they want the data to be migrated, is that ready. That all readiness will put us at a spot where we won't be able to complete that newly added work and then again we will have a level of oh, they couldn't achieve the goal because you are trying to set some unrealistic goal. So from my standpoint, rather than piling up the new work, it is extremely critical to have reasonable springboard. Based on my experience, it is difficult for POs also to say no to stakeholders.

Mark: 32:02

Did data come into play, with being able to evaluate whether this was a realistic goal to undertake to get both migration and cleanup done?

Suruchi: 32:27

As far as the data is concerned, we considered that in two weeks time box a lot of processes and activities need to be done which are more than enough for only cleanup and for these migration stuff which I mentioned now, readiness of the other database, availability of that environment all those pieces were not considered. And all of a sudden those pieces were not considered and all of a sudden those items were filed. So in that case we recommended I mean specifically developers, they recommended to analyze that additional work. Basically we ran technical feasibility analysis and which didn't take much time because one of the key developers he got immediately the list of items that should be done on the new new database. Like sruchi, the new database should be ready this way, that team should be available while migration it's a, it is going to happen in batch process. So there is, there are a lot of resource engagement, technical component engagement and other things that need to be updated before that new database gets ready to accept this data. At the same time, database owners, we need to get approvals and all. So it will take time. So this feasibility analysis was done and then, based on that, within next next couple hours itself, we were able to prove that this is not acceptable. I mean, we cannot add this pile right now. What we can do is we will do all those items first as a prep and then have this as a next spring goal, or maybe after a few things, and we we decided to have a separate meeting with stakeholders so that we will not push that too much. If they want to, if they find that this migration is critical, we can have a quick meeting later, but then having this as a part of this sprint goal.

Suruchi: 34:10

Saying yes randomly would not be a good approach. And also, product owner agreed to that, because as soon as he saw the entire list of items, he said that yes, this seems to be reasonable. We already decided in the working agreement when such situation happens or occurs, developers want me to ask powerful questions to product owner to guard them. And then they were able to present that list. So this is how I supported the team. That saved them from burnout. That saved them from getting insulted and having the tag of lazy, lazy people. That is really important, because when I get assigned to my team, I protect them, I get attached to them. That's why I got the title of Scrum Mom. And then I don't want someone else to say against them like oh, your team is not working, no, they are working on this. So this is how we logically said no to them and in the next sprint we were able to get that as a next sprint goal.

Mark: 35:09

So in these three scenarios, I observed that you used the tactic of asking for the data to see do we really need this now or can it wait. So that was a way that you said no. The second scenario you provided options and you negotiated with the other development team member instead of just saying no. And the third you use some powerful questions, along with some data, to be able to persuade and not just say no, but to make people pause and think before continuing with the requests that they were making.

Suruchi: 35:48

Absolutely In all these scenarios explicitly, I never used the word no, but I did say no. My intention was to say no. I didn't use that word. The first word that came in my mind is no, but I didn't say that. And I was able to successfully say that no to my action, or I made it possible.

Mark: 36:11

Very good. Well, Suruchi, as we're closing in on this episode today, I know our listeners out there will likely want to get in touch with you and maybe ask you some follow-up questions or just connect with you. What's the best way for them to do that?

Suruchi: 36:24

The best way to connect with me is LinkedIn. I'm very active on LinkedIn and I can respond back to their DMs pretty active to my post also, so they're most welcome to join me on LinkedIn.

Mark: 36:37

All right, great, we'll put a link to your profile in the show notes and people get in touch with you that way.

Suruchi: 36:44

All right.

Mark: 36:45

We're going to come to a close for another episode here today with Suruchi Patke talking about the art of saying no for a scrum master. All right, so this is Mark Metze. It's been a great episode. We'll see everybody later.

Suruchi: 37:03

Thanks for joining us for another episode of the Agile Within. If you haven't already, please join our LinkedIn page to stay in touch. Just search for the Agile Within and please spread the word with your friends and colleagues Until next time. This has been your host, mark Metze.