Transcription
Hello everyone, welcome to our channel Career Talk. My name is Sun Sharma. I'm an agile consultant based in the Netherlands. And at Career Talk, we invite industry experts from around the world to share their real-world experience with all of us. And today, we are going to discuss Scrum Master interview questions shared by a member of our USA WhatsApp group who recently attended an interview at one of the Big Four firms in, um, in, in April recently. And to help us, we are delighted to welcome Deepa Shiri Ja, joining us from USA. Uh, she's an agile program manager, project manager, coach with over 18 plus years of IT experience. And, uh, we also had the pleasure of doing a couple of great sessions with her three years ago. Please don't do that again. Please come a little bit more often. So, time really flies. And friends, to avoid missing any of our future sessions, please subscribe to our channel. And if you appreciate our quality content, which I'm sure you will, smash that like button and share your thoughts in the comment section. So, without further delay, let's get started. Hello Deepa, and thank you for joining us today. Over to you, Deepa.
Hey. Hi Sununan. Thank you very much for having me again at Career Talk and, uh, to all the viewers, uh, thank you for watching this, and, uh, we can get started soon.
Wonderful. Okay. So, let's start. So, the very first question is, um, tell me about a situation where stakeholders or your team members wanted to bypass some Scrum processes. So, how did you uphold the framework without damaging the relationship?
Yeah, Deepa. Okay. So, when somebody gets asked this question, basically they want to see, because, see, uh, nobody likes change, right? Like, when we, we ourselves as human, forget agile, uh, nobody likes change. And, uh, because, uh, the biggest thing is, when we ask people to change, there is a fear of losing control. We've got to understand that. So, this is the first, uh, basics that you have to understand. And as a change agent, as a Scrum Master, as a coach, or any transformation consultant, uh, role that you are playing, you are bound to bring in changes, and there will be resistance. And this is what they want to check: how do you go about bringing a change, right? So, just to answer your question, uh, I'll share my, uh, experience soon, whether it is directly I have been involved or how I have been requested by my fellow colleagues in the industry to, you know, we always do that. We always, uh, reach out to people and ask their opinion, and that is what we call the third-party inspection kind of thing, right? Hey, help me. I'm in a, I'm in a situation. Can you think it from an unbiased view? All right? So, that's what I'll try to do to answer, uh, your, uh, question, uh, here. So, whenever, uh, there is a situation, so, one of the biggest, uh, I, I think most of the Scrum Masters will relate, that when your team is in a high-performing zone, right, there is a tendency, or, and it's a, or it's a very technically efficient team, there's a tendency they will start skipping stand-ups, the first and the basic, uh, you know, miss people start. And, uh, as a Scrum Master, let me also put it this way, that if you use your power, your authority, and say, "Hey, you have to come." All right? You, you try to bring in control that, "No, you can't miss." Uh, your team will still, will comply, they will come, but what would be very evident is, there will be a visible resentment, sarcasm, and disengagement. And if you, if you feel this, that yes, this happens, people just revolt, it is true because you are using control. Okay.
So, it's important that whenever, anywhere, like in this case, I'm taking the example, whether the team was, is skipping stand-ups, it could be anybody in the org, right, or, or, or in your team who is challenging some kind of, or, or saying, "Hey, this is not needed." As a change agent, uh, you've got to understand that it's a signal. It's not defiance. They, they are not going against you or going against the process. It's just that they are not seeing value in it. Okay. So, if you use your, uh, you know, what do I say, your power, your control, uh, the purpose of the event is lost, right? So, you are not going to, you will just have people coming in, doing a checkbox, and you can say it's a watermelon metrics: everybody's attending stand-ups, uh, wherein it's all red from inside and all green from outside. So, what do we do? So, the first things first, right? Rather than handling it from a place of authority or compliance or control, try to lead from a place of inquiry and autonomy. And what do I mean by that? You have to first understand the "why" behind why they don't want to, uh, you know, why, why behind their withdrawal, why they don't want to attend it. Is it not getting value out of it? So, use your curiosity and not your control. Okay.
Uh, uh, I would have, I actually, I did that. I, because they're all very accomplished developers, seasoned, they, there's no problem in, uh, delivery. So, I just wanted to know why are, what is the why, right? Why you don't want to do it, or how can we make this particular event helpful for you, valuable for you all, right? And, and, you know, the, the reasons could be different. Like, in my case, it was that they were all distributed. I had teams from, um, China and US, so obviously that, that overlapping was not there. The timing of the event was not that suitable. And so, it happens, uh, that it's, it's, it's not a very convenient time. It could be because it's not generating enough value, because not everybody is participating. You know, there could be any number of reasons. So, the, so, the understanding of the "why" is very important. And, um, I take Scrum or Agile, right, like, or any other, uh, like, for example, Scrum, Scrum is a framework, right? It's not a formula. So, adaptation is agility. So, if at all, through all my discovery, through all my sessions with the team, I get to know that it is that, uh, yeah, something is not working for them. I will try to introduce options for them, not just mandates, right? Like, it could be check-ins through Slack. It could be, you know, uh, walking stand-ups. It could be, you know, change, change and adapt so that it suits the team. But, uh, remember one thing: you've got to reframe the purpose, not just the process. So, uh, always uphold alignment, collaboration, and commitment. That, that is very, very important. And, uh, try to, uh, figure these things, or, or, uh, pitch in these things in the team working agreements, right? And, and have periodic reviews of your team working agreements so that it's, it's, uh, helpful. And as a Scrum Master, I think also try and, uh, show the team it's important that these alignments are helpful. How do you do that? By probably chalking out the metrics that how many blockers got cleared, how many bugs got reduced, how many things we are, uh, you know, how we are accelerating. And that, that is up to you. The data is with you. How do you want to show it to the team to feel that, "Yes, this, there is a value when alignment improves," is something in your hand. So, I think that's all, uh, Sun. I, I would do.
Wonderful, Deepa, for that elaborated answer. So, really great how you have covered all the points. Wonderful. Okay. Uh, let's move on to our next question. So, next question is about retrospectives. So, can you describe any challenging retrospective which you facilitated, and like, what went wrong, and what you learned from it? That's very important.
Mhm. So, this one is very special because this was in my first engagement as a Scrum Master, right? So, always when you are doing the first, failures are always very special because you feel that, "I'm so prepared. I am doing it all right. Why did I fail?" Right? And we can't accept failures ourselves. We forget others fail. So, this was a retrospective I was facilitating, not my first retrospective, but my first failure as a retrospective. So, I had recently, uh, started my role as a Scrum Master. It was a banking, uh, engagement. And, uh, uh, we had a failed, uh, release, right? We had to roll back the release over the weekend. And, uh, post that, this was the first, uh, you know, uh, uh, retrospective. I went with the usual, my specific format which I had prepared and have been running all my, I, I think I had run around five retrospectives already, and I use the same format, right? And trust me, the situation escalated so bad because the emotions were really high in the team. Uh, it went into a blame game that it was not, it was, you know, it was you versus me, and kind of thing where people went on, uh, blaming each other. "You missed this." So, it was a lot of personal attacks happening. And, uh, there was sarcasm, there was defensiveness. And what happened was, I could see it in front of my eyes, the team safety eroded, right? And the retro failed to yield the insight it should have been. Okay. So, it was, it was, uh, in fact, uh, I, I felt at that moment when I was there, uh, I could not, uh, you know, pitch in. Maybe I was too, uh, inexperienced in handling these kind of conflict situations. And, of course, uh, like, uh, when I was looking, and when I look back now, it, the format was too mechanical, right, for, for considering the emotional state of the team. So, yeah, it did not go very well. And, uh, I did not think before running it, right? What could be? So, one basic, biggest learning is that retrospectives are the most powerful events for a Scrum Master, and you, as a Scrum Master, need to know how and which format to be used, knowing the situation of your team. So, in my case, what happened was, my, see, in, in this particular case, how would I, would have done it differently today if I have to say, is my team was high on emotions, right? And, uh, just think about it. U, I am married and I have a husband. I am frustrated, let's say, for with work, and I go back home, uh, undoubtedly, I'm going to give my husband a huge, uh, share of my frustration, I'm sure, right? So, similarly, when a team who has just completed their, they had a fa failure, right? Nobody likes failure. And then when you come back to the, uh, team, uh, like for a retro, they are high on emotions. They have not vented it out yet. So, as a Scrum Master, I, I today would ensure that I, I design my retrospective in a way that the emotions should first come out, and they feel, uh, okay before we start talking about facts, right? And improvements. So, it's very, very important. So, there are a lot of, um, you know, utilities today available. Um, one thing which is very, very, uh, common is, I'm sure you, you guys might be must be knowing about "Mad Sad Glad" kind of retro, right? It, it helps you to surface your emotions first, right? And then you shift to the solution. So, that's very important. Or we could, uh, I could have done something like, um, check-in circle, right? "How are you feeling?" kind of thing. Because once you vent it out, then you are sane. That, then, then you will start thinking, "Okay, so," there are various kinds of, uh, tools and utilities available today. Um, one is "Core Quadrants," "Emotions Wheel," there is "Team Mood Canvas." I'm just calling out these things that you can just, uh, you, you know, your, uh, viewers can actually check and see how to use them. But it's important to bring in that kind of, uh, you know, take the, let the team take out their emotions first before they come and talk. Um, this is also there. There are some other, um, uh, you know, uh, tools which are available. Uh, we call it, uh, "Heard, Seen, Respected" kind of check-ins. You can use the Liberating Structures like, "What? So What? Now What?" You know, or the "Trace for deeper insights." Those are something that can be leveraged. And, uh, always remember that, uh, safety cannot be an agenda item. It is the basic foundation. If your team doesn't feel safe, uh, they don't have psychological safety, they, you know, it's not a healthy, uh, situation to, uh, happen. And, uh, retrospectives to me are not just for process improvement. They are also healing rituals for the team, right? So, when the emotions run high, and it will happen, uh, no matter how mature the team is, the real leadership test is, "Can you slow down enough to listen before you start fixing it?" Right? Uh, so, this is my biggest learning, Sun, I will say.
Wonderful, Deepa. Great. All these techniques which you have mentioned, I'm sure like all of our viewers will love them. They will Google it or they will go to ChatGPT for sure. Okay, wonderful. Uh, let's move on. So, now this one is interesting. So, let's say, uh, in your past experience, has it ever happened that you dealt with a team that was like technically cross-functional on paper, but not in practice? So, what were the struggles and the challenges which you faced, and more importantly, like, how did you build true cross-functionality among those team members?
Yeah. Now, this is so important because we always talk about, if you want to build an agile team, they have to be cross-functional, right? And, uh, what do we, what do we mean by cross-functional? We mean that everybody should be, you know, all the skills should be there in the team to solve a particular backlog item which is there, uh, to be solved or to be completed. So, one very important thing, uh, and again, this comes with practice and, you know, uh, and of course, I, in general, in the industry, the agility, the agile, uh, expertise has also improved. We all know today. So, one of the things which I saw somewhere about three years back, right, when, when I was in one of the engagement, um, uh, we had a, we had a cross-functional team on paper, right? And I mentioned this explicitly because we had all the key roles and, uh, present, right? But within the team also, so when we say a team is cross-functional, right, on paper, okay, all the roles are present, but, what really the cross-functional element talks about is when you have coll, when your collaboration is fluent, right? And, uh, we had a situation where I had a data services team, right? You understand, uh, we had a BA, we had a Dev, we had a QA, and, uh, what happened was, all these roles were there, uh, but they were not working together, right? When I say together, means you have to ensure that we are leveraging each other's strength, and that was not happening. Uh, the Devs, uh, the developers used to code, coded the specs, and then, uh, the QA would write the test cases too late, I would say. And the BAs, uh, we did, they didn't attend the refinement sessions. Now, some of your, uh, you know, followers might say, "Hey, agile teams do not have QA and BA and things like that." So, okay, right? They don't. But, uh, in my team, they were present, right? These roles were present. We had a BA, we had a QA, and, but they were not, so they are also part of the dev team, right, technically, then, but, uh, they were not, uh, they were not in sync. You, you can make that out. So, obviously, I cannot just go ahead and say, "Hey, why you are not doing it like this?" and "Why you see that's a very, if you like, um, I always say, if you, uh, pick up a stick and start hitting people, people will do, but that will be half-hearted, and you will not get what you really want, right?" But, uh, so, what I did was, I did one, and I, I don't know if, if this is an agile practice or not, what I did actually was, I did a role on a post-it, which means I called all of them. I said, "Hey, just define and write down what do you think is actually your role, you know, and, so, what is it that you think is your role?" So, they wrote, and then I coached them, "Okay, you know what? In Agile, this is what is expected." Okay? And I did not see what they had written, and I asked them, "Based on what I'm telling you now, in Agile, what you are expected to do, can you tell me what is the gap that you foresee?" And it was not driven by me that I am finding out the gaps. It was the team, these people, these roles, who identified what is, what's the gap. And we came up with something called as "Role Clarification Canvas," right? Post this, we, we, I explained to them, I, I coached them on the 3M "Go Refinement" model, right? Where they all collaboratively come together, groom a story before it gets estimated, right? Before the refinement, you get the clarification along with the PO. So, when you do a joint kind of, uh, like, you know, uh, when you have shared goals, right? You break silos much faster than shared tools. So, so this is how we started. Then, uh, also, uh, uh, in this particular team, the, the Jira board and all were segregated that based on assignees, right? Based on roles, you would, the, the swim lanes were such, configured that it is based on people who, like, which role is doing, and what are the stories. I said, "No, let's not do it this way. Let's do it epic-wise, right?" Like, when you create the, uh, Jira swim lanes based on epic, so you get to know what are the user stories we are doing, and all of them are co-owning and jointly doing the same. So, this was very important. I also did one thing once I saw there was some maturity in, in them grasping the concept. I facilitated a "Skill Inventory Mapping," which, uh, which also helped them to, like, when you have, uh, leveraging the swarming techniques, the mob programming, you know, promoting pairing, because that ways, what happened that, "Okay, this is my primary skill. I don't have the other skill. You don't have to be an expert, but just be together so that we are moving in a way that we are achieving our end goal better." Yeah. So, this is what I did.
Wonderful, Deepa, and sharing that real experience. So, I'm sure like a lot of people will get benefit out of it. Wonderful. Okay. Uh, let's move on. So, next question is again a little tricky. So, let's say, uh, your leadership demanded some detailed upfront estimate for, let's say, an upcoming project. So, how are you going to manage these kinds of expectations with your, you know, uh, delivery managers and some senior partners while staying agile? So, it's a tricky situation. People want some sort of, you know, milestones or the estimation that, "Okay, how much time it's going to take or how much resource is going to take?" So, how are you going to manage these kinds of expectations?
You know, ah, tricky question. And, and, and so, and I think everybody faces this, no? I mean, I'm sure if we are in a leadership position in future, where we have to run these multi-million dollar, uh, engagements, right? So, we also would need to know. So, I have actually gone through these situations so often that it feels like I don't know if it is the right answer or not, right? But, Um, I always use empathy to first understand why my leadership needs it, right? Um, this is very, very important. Uh, so, there, there, there was this, uh, recent, uh, engagement I was involved in, where, you know, leadership needed this information for budget approvals, for, uh, you know, because they, they were also being pushed to provide some estimates upfront, so that, you know, they can at least provide some commitment to somebody, right? Now, it's important, of course, we have been talking with the leadership and all that, "Hey, it should be the forecast. It, it helps you with decision-making. Commitments will limit your discovery," etc., but they were looking for some commitment, okay? So, honestly speaking, it's very, very important to understand that to educate your leaders that estimates are not promises, they are conversation starters, right? Because that tells you that, "Today, at this moment, whatever I know, based on what is known, based on my experience, this is what I think." It's not a commitment. It's not a promise, right? And, uh, then, it's the job of an agile leader to now turn these conversations that we have started on estimation into informed bets. And I use the word "bet" and not "rigid contracts," right? So, how do you do that? How, how do you coach your leaders? Correct.
So, in one of my engagements, like I was talking, we used, uh, the "Cone of Uncertainty" to educate them, right? Like, "Hey, the, as, as we will progress, right, uh, my estimates will get more reliable over time." Okay. I also, uh, propose that, "Fine, I understand you're looking for some kind of numbers, you are looking for, uh, some kind of, uh, you know, uh, tangible thing that by when I will be." So, let's do one thing. Let's, let's, uh, propose. I proposed the "Dual Track Approach," right? So, do a discovery track, try and validate the complexity, and identify the unknowns, determine the, uh, the technical spikes that would be needed, and, uh, then we would be following it with a rolling wave estimation model, right? Using story point ranges and confidence levels. That, that is a concept which, I learned in SAFe, all right? So, when we started doing this, um, I also, uh, recommended the use of "Lean Portfolio Management" because that would, uh, you know, help, uh, to focus on capacity-based funding versus versus scope-based planning, right? So, that was also done. Then I also introduced, uh, "Value Stream Budgeting" and OKRs to shift the focus from "When it will be done?" to "What are we achieving?" And that's a very good mind shift, uh, change that you can recommend. Yeah. So, also, uh, there are, um, uh, uh, you know, you have to understand, and my, my experience with my leadership has always told me that the leadership is always anxious about commitment, visibility, and not necessarily fake states, all right? So, I also learned that into that, that, uh, you have to stand as a good partner to your leader, that, "Hey, we are into it together. You are not alone. We'll do it together." And if you can, throughout, throughout your journey, build that relationship with your leadership, that, "Hey, I will keep giving you that, uh, transparency after every quarter or every, you know, leaders don't want it on a weekly basis, they need it quarterly. How we are progressing towards our goal, what value are we generating, what are our detractors that we are getting?" I think they, they will support you in the implement, mentation because they also understand that, today, with the diverse technology changes, etc., this is, this is the most feasible way of progressing.
Wonderful. Uh, Deepa, thank you for sharing all these different techniques which you have used. Uh, I just take two minutes of the time. Uh, I just want to also mention, uh, a couple of things which I am doing with a lot of different projects because I was also the part of a lot of different bits and, you know, so, of course, we need to give some sort of estimation when we are getting some large and big projects. So, there, I'm using, uh, you might be heard about it, "Function Point Analysis." So, that's FPA, we call it. And, uh, it used to be popular, it is in Europe, it's popular, somehow. But then, this is something which you can also use, and this is independent of the technology, this estimation. So, it's just based on the functionality which you are going to deliver to the user, and it's not line of code or specific technology. But then, it's a complete project in itself. It's the easy thing, but I'm just telling because we are talking about estimation, so I just want to tell the audience if they want, they can Google it. What is Function Point Analysis or PAS Function Point Analysis, D-E-I-D. And a lot of big companies used to do that. So, I'm also using it now from the last couple of years. I would say, last two years. That's something also if you are doing estimation, if you want some early forecast. And again, as you mentioned, the word is "forecast," not like, you know, "promise." And then there is also something called "Monolo Analysis." You can also use that, some of the probability. Yeah. Yes. Just based on your past data and all, if you have done some sort of project in the past, which I'm sure nowadays everyone has those kind of data. So, just additional information, nothing else. Fantastic. Great. Let's move on to our next question.
Uh, so, it's regarding your sprint goal. So, let's say you are working on a sprint, and then you realize that the sprint goal is irrelevant midway through the sprint. So, um, like, what sort of decisions were made, and who was involved, if you can share, like, if something has happened similar with you into the past, if you can recall and tell us some of the past incidents that will happen, that will be great.
Okay. Um, um, this is very rare, actually, to be very honest, because I come from the service industry. So, I have just had one experience where my sprint goal actually got, you know, defunct, I would say. Okay. Uh, and imagine, I have been in, in this for quite long. So, it re, it, I will say, it's a rare occurrence. And, um, in, in, in my case, it was because of a regulatory change. All right. I'm not calling out the, because I have people will otherwise guess, but, yeah, I, we were midway through one of the iteration in a mobile banking, uh, project, and there was a new compliance regulation that was announced, which invalidated the core features that were, that we were building in that particular, uh, sprint. Right? So, obviously, this, the sprint goal can never be met if we take off that particular, uh, story. So, what we did was, we had a immediately, we called for a triage call, uh, with, with the PO, with our architect, with the SME, and also my, uh, business owner, right? Because it's, it was superb. And we also had our RT in the call. And, uh, we did a quick impact analysis, uh, captured what are the affected, uh, stories from the ongoing iteration that is impacted by this. Not all the stories were impacted, but these were a few of them. Uh, there were a, a significant chunk, I would say. All right. So, what we also did was, um, uh, the PO immediately took it to the Scrum of Scrums, discussed that, "Hey, this is unfortunate, but it's important that we pivot at this point because these won't go through with the current regulatory changes." All right. The key decisions that we made, uh, was, PO officially, uh, you know, cancelled the sprint goal, uh, and, uh, we've worked on getting our backlog again reprioritized based on the new regulation. But, uh, there were three stories, I believe, that were not impacted, and we used the remaining capacity, like, like, you know, the, it's, it's, it was ongoing. So, we completed the user stories which were not impacted, and we spent the rest of the time, uh, in exploratory, uh, the technical debt, the spikes for some new stories that we could advance now, all right? Because it, it was planned, and we initiated few refactors, etc., uh, that, uh, that we could help, right? Uh, a few things I, I will, uh, call out is that, um, uh, we did a lot of impact mapping, uh, when we did the triage call. We, uh, also, uh, did one retrospective, right? Because it was im, it was important because my team was felt, you know, you don't like it when somebody says, "Hey, your features are no longer needed." It's, there's an emotional impact, right? Because people are so, that's very important. So, the, the, so, we handle the team's frustration and uncertainty with transparency and empathy. That's very, very important. You have to acknowledge, "Hey, this has happened, and this is how it looks." Because, uh, you cannot let your team be demoralized. Uh, also, uh, what, uh, we learned from that, though I have not used it ever so far, but we did also create a, a "Sprint Exit Criteria Playbook." All right? That if at all there is a situation in future, these are the things you should do. So, that helps. So, maybe if at all it comes. And, uh, also, uh, very, very important, uh, pivoting mid-sprint is not a failure, right? It's agility in action. And you are able to do it only because, uh, we are agile, right? It's intentional, it's transparent, and it's co-owned. So, as long as it is that, it is not a failure. That, that was a clear message I gave to my team. It's not that you have failed. It's agility in action. It's going to happen. So, pivot without guilt, right? And, uh, also, uh, sprint, uh, goals are not sacred, right? It's not something, "Oh, we should not." But business agility is the real test, isn't how well you follow the plan, but how quickly you realign without burning the trust. That is very, very important, and that is something that should always be held, upheld, I would say.
Wonderful. And quickly, I'm just able to recall one of my, uh, experience. So, I was working for one of the telecom giants in Europe, and we are working on a sprint. So, in that sprint, we are like, we are supposed to download the itemized bill from the new portal. That was our sprint goal. And we are into the middle of the sprint, and suddenly that legacy billing system went offline, uh, due to vendor outage, and, uh, API dependencies to fetch the bills were unavailable for us, and there is no workaround existed at that time. So, then we thought, okay, uh, PO and then delivery manager and the tech lead and the architect, they agreed to shift the focus to other backlog items from the upcoming sprint. So, we just, you know, come up with a new goal, new goal to improve the UI and UX for the, uh, account overview, and, you know, few, few things like that. And then we kept the front-end team focused, uh, by mocking the build API. And, uh, meanwhile, the back-end team picked up the technical debt factor, as you also mentioned, right? Something which we could have done in that short duration of time. So, uh, yeah, I mean, the portal launch was not delayed. But again, once that billing API came back online, we have done all those integration efforts. We, we could have made it. But, yeah, that was the incident which happened. So, I just thought to just add on quickly. Yeah, it happens, right? Like, I mean, that's true. Great. Awesome. So, uh, friends, we are halfway through our session, and I would like to remind you that we are, I'm sure like, I'm finding the session very valuable. So, do you. So, please take a pause to like the video, subscribe to our channel, and share your thoughts in the comment, like, what do you think about this session, uh, the way we are, you know, having all these answers and things like that. So, when you like it, it really helps the YouTube algo to suggest this kind of content to others who may benefit. Uh, we often see all these cheap comedy videos and entertaining videos going viral, but this kind of in, like, significant content which really needs, which really deserves that kind of viewership is not there. No. So, even if you, if you just simply share on LinkedIn or in your agile or Scrum communities, that will make a big difference. So, please, let's also share meaningful content that helps our professional community grow. So, let's support each other, grow together. And with this appeal, let's move on.
So, Deepa, the next question is, uh, can you provide an example where your coaching efforts failed to change the behavior of your team member? And, my goodness, what did you reflect on that afterwards?
See, we are talking about failures because those are the most difficult things to understand. And, I, I understand like why these kind of questions are coming because they really want to dig into that, you know, individual like, "Okay, if someone can celebrate, I would not use the word salute, but then if someone can talk about comfortably for their failures, I think then that guy can do anything." So, sorry, over to you, Deepa.
Uh, okay. Actually, I, I was saying like, okay, oh my goodness, there are so many failures. We are talking about, and trust me, as we progress through this, I, I realize yes, how my viewpoint and my thought process has changed over time, right? Like, so, yes, um, just to let you know, uh, there is a subtle, not a subtle, like a significant difference between being an agile coach and a, and a coach, right? So, I have, uh, spent a significant, uh, time of my career in IBM, and so I was also a Blue Core Coach. It's, it's a very, uh, niche, uh, you know, coaching, uh, platform, and there we talked about coaching only, not being an agile coach or so. So, so this question, uh, is related to coaching, or is it related to agile coaching? Whatever you feel comfortable. Let's go with the coaching first.
Okay. So, if you ask me, uh, about coaching, right? It, it is very simple, very basic. You cannot coach someone who does not want to be coached. And it is so, so important to, it's not your failure. It's not the other person's failure. It's just not meant to be. You, you can only coach someone who is coachable, who wants to be coached, right? That's the first and the basic. And second, for me, is the coaching that you do is for the other person. It's not for you. It is not about how good, great coach is. It's about my coach, right? How great or good is my coach, right? How, how it's not about also how great he is or she is. It's about how is it benefiting him. So, it's all about the coaching, all right? So, this is very important. So, whether I am a failure or a success doesn't matter when it comes to coaching, right? So, whether I have failed or not, it's not about me. It's about the coachee. Has he or she gained that value from the session or not, right? So, uh, very important. Now, now coming to agile coaching. So, agile coaching is different than coaching. So, like I said, you can't coach, uh, someone out of fear unless the system supports their courage. Also, agile coaching is not about converting every individual. No, it's about aligning the ecosystem so change is possible and safe. So, why I say this is, now, as an agile coach, it is important that I work towards bringing that alignment in the ecosystem. If, if somebody is not able to, you know, adapt the ways of working, I should be able to coach him, whether he's interested or not interested, doesn't matter. He has to be aligned because that's how we are going to. So, and, and there's a famous saying, right, in agile, we say, "We, we are as fast as the slowest point in the entire system." So, if we look at it, so even if you have one single problem in your system, it will derail you from the accepted acceleration that you are expecting. So, what I do, uh, so, if it comes to coaching, very important, somebody has to look up to me to be his or her coach. We go ahead with a contract because, you know, it's very important to let them know they are in safe hands, their, uh, data, their, nothing would be shared outside, right? So, that, that, that contracting needs to be there. And of course, then you have to leverage and, uh, talk to the person and understand what is his goal, so that you can define a model. And, and typically, I, I use GROW model when it comes to coaching, that's the basic, effective, simple, and I like it, yeah. So, that's, that's about it, right? But when it comes to agile coaching, I also, uh, use "Immunity to Change" framework to surface the hidden commitments, right? That is behind the resistant behaviors. So, I leverage these kind of frameworks. I leverage, uh, uh, a formal agreement between the team members on what each role would mean in, in this context of, uh, of the transformation that we are in. Uh, also, uh, very important, as an agile coach, to measure behavioral metrics, right? Not just delivery metrics. Delivery metrics will be there, it's important, that's where you, but also how my behaviors are happening, team maturity assessments, etc. Those are very, very important. So, uh, you talked about the failure, right? So, these are where my learnings actually. Initially, when I started my role, I tried to coach people. I want to know, everybody should be fit into that frame, right, of a perfect agile developer. No, it's not needed. That's not what my goal is. I, I'll go bonkers if I start managing 100 plus, you know, team members to fit into that. Perfect. All we have to ensure as an agile coach is, we are all aligning the ecosystem to access, to achieve the value delivery that we are right. So, yes, I used to take things, uh, very personally. I used to have attachment to the results, right? That I need to fix XYZ person. No, I, I, I shifted my focus to protecting the psychological safety of the team, and, which helped them to reestablish the boundaries respectfully. And, uh, of course, and that's what is important, right? Like, you safeguard the team and not just individual and trafficking them. That's, that's not the purpose. Yeah.
Wonderful. I hope I answered your question. Yes. Yes. Yes. Wonderful. Wonderful. Absolutely great. Okay. Uh, let's move on. So, next question is, um, so what, what is your, like, toughest cultural barrier which you have faced while implementing all these, you know, Scrum and Agile? And also, what you have done to overcome that? That's also important because you mentioned like you worked with China, USA, India, their mindset is totally different, right? You know?
And, uh, you actually asked, again, a very tricky and very interesting question because this is what we face, right? Like, for example, like when we come, it, when it comes to culture, Indians just don't, don't know how to say no, right? Don't you agree? I mean, I have, I, myself at times, even after I'm giving all this, I don't agree. No. So, I'm not Indian. No, you're not Indian. You're in, you are in Netherlands. No, I've learned it now, how to say no, honestly. I learned it, honestly. It's difficult, but then feel so great, empowering. They've got the power to say no. So, very important, right? And I, I think, uh, there are, I will not name, but, uh, there are organizations that spend millions to produce content to understand the culture if you are about to visit a country, right? Like, if you are going on a business visit, the companies actually provide you a dump of what are the cultural things that you should be aware of when you go there. Uh, I know a lot of companies do that. So, coming back to your question, right? So, so we've got to understand when, again, and it's, it's all interrelated. Soon, and I don't know if I'm being repetitive here, but whenever you try to bring about change, nobody likes it because you are, you are taking away the control that they had. And, obviously, and, and, uh, when we talk about no, we have to bring, bring cultural change. You have to understand that that company or that, uh, that team or that, uh, that organization has been there for years, and they have their own culture. You just cannot come as, you know, a new hire agile coach or Scrum Master and bring about that cultural change. It's not possible. So, what do we do differently, right? And if a company or an organization has been there for so long, that means they also have a rich culture. You just cannot go and say, "Hey, I don't agree with your cultural stance." Think about it. If, if you have a new, uh, daughter-in-law entering a family, and, "Hey, your culture is not like mine, and I don't like your culture." She's going to be shown out the next day. Okay? You go back to your home. And this is an Indian context, right? Because we, we married into families, etc. So, similarly, right? So, uh, so there, there, there was this, uh, very, um, I will again not try to quote other example like the company and all, but just giving you context, it was a rigid hierarchical culture in the organization. Reason, it was from Southeast Asia. Uh, obviously, they did not like Agile or anything like that because they always thought, "Hey, my, my kind of ways of working is good." So, instead, right? And, I, and I told this in your very first interview, like, you know, session that we had, that whenever you go, whatever it happens, until and unless you are not part of the system yet, don't try to bring about any change. Never, never do that. You'll be seen as an alien. Never bring about any change. So, I, instead of starting with Scrum, uh, mechanics, I would say, because, uh, I first conducted a "Cultural Agility Assessment." Yeah. And this is based on the Leadership Circle data. And this helped me recognize power distance, collectivism, and face-saving behaviors. And this happens, right? So, now, what I did based on this assessment, I tried to align the agile values with the local values. For example, they focused a lot on discipline. They valued that. So, instead of saying "self-organized team," that said, "No way, we got to be disciplined, right?" So, when you start saying the words that they understand, or they, that has been part of their culture, they feel more, they feel related, right? They feel heard, they feel as if, "Okay, you are speaking their language." So, so I did, I worked a lot on adapting these languages, metaphors, right? Like, for example, uh, I did not, uh, say "empowerment," "fail fast." No, because, uh, because they did not like that. They know, they don't like failing. Okay. So, if I say "fail fast," they'll not get the essence, but go by the word, and they say, "Hey, why you are talking about failures?" So, rather, we, we, I started using, uh, terms like, um, "mastery through practice," "protecting team's honor." You see the subtle difference I used. So, it's not about, see, as a, as a coach, I need to ensure my, whosoever is hiring me is able to focus on value delivery. So, whatever it takes to get there, right? So, that, that's what I did, right? So, as long as they don't see you as a threat, that, "Okay, you're going to change their control span," and all this helped, right? Also, because it was very, like I said, hierarchical, so people were very fearful about giving feedbacks, okay? So, very easy, go for these anonymous retrospectives, so that they can just feed in the data, you don't have to take that data, show it to the world, blah, blah, blah, no. But try to gauge in what they are feeding. Healing. Okay. So, these are, these are few things I did, and trust me, these small little things only make the big difference. And, uh, yeah, and they did that. They had a very, uh, successful, uh, stuff. And, uh, very important, right? The, I, I, I, I always keep saying, right, the greatest agile blocker isn't a tool, it's identity threat. So, it's not the framework. Everybody feels, though Agile is not, "I'll lose my identity. Who, who will be my project managers? Won't be there. This won't be there. My role will be taken." Now, with AI, the same thing is happening, right? That identity threat. So, real transformation will always begin, or will happen, when we meet the culture where it is, and we walk together towards where it can go, not the other way, that challenging and letting them know, "Oh, you are doing it all wrong." No, you respect their culture. They'll, you know, you have to, it has to be more inclusive, is what I would say.
Wonderful, Deepa. Uh, thoroughly enjoying the session. Uh, but friends, uh, we still have a lot of questions pending, but Deepa, I think we have reached today's, uh, time limit. So, let's continue this series with part two, part three, and so many parts that, no problem at all. It's, I think almost like 40, 50 minutes for this. Oh my goodness. So, that's, I'm thoroughly enjoying, like, time flies like anything. So, but then, I think, let's, let's, this is the right time to, uh, end this session, and let's come up with part two and a lot of other parts later on. So, sure. Thank you, friend, uh, for joining us today's session, and we hope you found it helpful and informative. And if you enjoyed the session, please don't forget to like and subscribe to our channel. And we hope to see you in our next session very soon. Until then, take care. This is Sur Sharma signing off along with Deepa. Thank you everyone, and bye. Bye-bye. Thank you, Deepa. Bye-bye.