[Music] Hello friends and Welcome to our Channel career stock friends today's guest despite ongoing recession and the closure of many job opportunities Our Guest today defies the odd by receiving the five job offers from various mncs with 100 increase in salary so friends in this series we will discuss all the interview question she faced and it may be divided into two three parts so if you haven't subscribed to our Channel please do so to receive the notification for future sessions and Friends it takes a lot of time and efforts to create all these sessions for you so we would greatly appreciate if you could hit like button and show your support So for our viewers who are scrum Masters or aspiring scrum Masters we encourage you to not just watch these sessions but also come up with your own answers so what works for others may not work for you so always personalize your approach so with this thought let me introduce Our Guest for today apurva she has 11 years of total ID experience and has worked as a scrum master in TCS in the past so welcome to Career stock apoorva we are excited to learn from your experience today apurva hi hi sunam thank you thank you for giving me an opportunity to be here today uh I'm really uh very happy and excited to be a part of your Channel today great apurva so why don't you tell me about yourself in a brief yeah sure so I'm apoorva Kesha uh I am from Bangalore I have been working with TCS for the last 11 years I've been in the scrum Master role for the last five years I decided to move on because I wanted to explore uh New Opportunities different types of teams outside my comfort zone of TCS okay great so before we start the actual q a session uh I was curious and a lot of people like me are curious can you tell us what's the contribution of career stock in your success like people ask me a lot of time that there are more than 500 videos so what videos you have watched what process you follow to get this success apoorva I should tell you A big thank you because the career stock has uh played a very big role in my prepression for the interviews and the clearing all of them which I attempted so thank you a lot for that but as you mentioned it's a big ocean it's a humanly not possible to go through all the 500 plus videos which is out there so actually initially I did know where to start when I started off thinking it just uh dominated in my mind that I could try for a change so I didn't know how to start where to start all I did was first I went through all the PSM guides again and whatever I had done I had brushed up then just to know like what kind of questions they might ask the various companies and just Google few uh companies like um what might be their question uh I didn't get proper answers then I just thought I'll give it the chance in YouTube and I hit upon career stock and it opened a huge pan or a box of so so many questions so many things that it's humanly not possible to digest everything at all so I just started off with couple of videos like um especially those who had multiple offers so their experience would be very rich so that's how I just started off initially the first few videos were like the latest ones I went through them then those which had lot of likes or comments on them and few of them you had captioned that uh trickies come Master questions or things like that uh scenario based questions so that way went on exploring and in couple of the interviews if I was not so very confident about the answers which they had told in that video I started researching more on that particular question and somebody who would have spoken more about it so that's how I started digging almost I can say two two and a half months I've always continuously listened to your videos and uh mainly I have made uh notes of almost all the questions I've gone through this whole book is completely full of your questions and answers which I've got great so I can tell you once this video will be published you will get lot of requests to share these notes but I am telling you say no the reason is the reason is the the same reason which I just told you in the beginning itself that everyone has to spend some time clearing interview is just a beginning friends just a beginning you have no idea what is coming for you in the future okay so enough can thank you apurva for sharing your uh yeah this background with respect to Career stock I'm sure like a lot of people will get some input from your experience as well so let's begin okay so if you allow shall we start with our q a session sure sure definitely great okay so friends what we have done uh I think it's more than 40 to 50 different uh interview questions so we will take easy questions first in the beginning and then we will take it like first part second part third part like that in future so here's the very first question according to you what are the key components of a well written user story and why are they important in Agile development project okay so a user story is basically uh what comes to the developers table to start off with the development uh basically it is written from the end user's perspective like an example like as an administrator for some particular uh uh for a particular portal uh I want to be able to uh reactivate a particular user's profile so that you can start using our code again simple example something like that so it gives you from the end user's perspective apart from that you the from the developers perspective if you see it should it should be I mean able to uh inculcate the invest criteria invest what we uh that's the acronym uh I uh means individual so there shouldn't be a lot of dependent stories on this particular story sales so if you all a start off with lot of dependencies more chances that you will get because if those dependencies don't get resolved on time then i n n stands for negotiable so when you are grooming this story the business uh that is the ba or the product owner will be giving their business perspective and the technical lead or the senior developers will be giving their technical perspective so you they should be the story should be in a flexible format where it can inculcate all the business requirement and also take into consideration the technical limitations if any then V it is valuable how valuable it is from the end user's perspective and also is it going to help us to attain the Sprint goal and the product goal in the long term is it valuable that is the third thing and E stands for estimatable so when you are grooming this story is it uh estimatable is it a small enough to estimate it and give it story points or t-shirt sizing or in number of hours whichever way you are estimating it are you able to do that you will be able to do that only if the developers have complete idea like what they're expected to do what are the dependencies are all the wireframes ready all these criteria comes into picture then s stands for small as I already said it should be smart enough to complete in the Sprint if it is huge then complexity increases lot of unknowns may come in so it's not advisable at all better to keep it less than eight story points or maximum of about 20 hours of work uh possibly then last is testable is it a testable uh scenario what we are talking about or is it something like it is dependent on some other system and only once that is developed and this is consumed you can start testing it then it becomes a huge uh a big question mark so you would have only unit tested it with some uh stumped up data and things like that it's not really useful so that is also becomes a big constraint to that so apart from this invest criteria in our project what we do is we uh we have clearly defined the DOR and DOD criteria that is the definition of radio and definition of that and every story rigorously we follow to uh and ask the developers to complete both the checklists the DOR checklist really helps you in getting to know if the story is really ready for the developer to pick up so mainly the points in the DOR will be um does it have an acceptance criteria are the technical documentations or wireframes whatever is required attached and if any automation from testing perspective is required are the scripts ready or what now uh hello Sunan I think we got stuck yeah I just lost you for a minute no problem I just heard the script lasting from you okay yeah so the testing scripts uh are they ready or are we planning to build them during the course of the Sprint along with development whatever the plan is so these and has the walkthrough been given from both the business perspective and the technical perspective so these are the various points which we come up with the DOR checklist and any dependencies are there with other teams like any uh msas have to be returned which has to be consumed by your team is it ready or when is it going to be ready so those kind of things will be the DOR only if if all of them are checked and ready for pickup then only you pick up that story then again coming back to the end towards the end of the story um as a scrum master I should be uh sure that the team is giving a delivering a quality product and they are not skipping any quality Gates or anything in between so um I ensure that the dod checklist is maintained and filled by every developer um story on story so the dod checklist basically consists of hip development and unit testing is complete and normally unit testing in our team is also automated so how much percentage of the code is the unit test uh scripts uh consisting of it should be more than 85 then if you are using any static code analysis like sqa um or sonar Cube uh is it passing that no code smells that they have to be ticking off and in sit is the manual testing done and wearable feasible have they completed the automation testing that is also a criteria and once it's in uat have we shown a demo to the business users have you got to sign off from them and also performance testing normally it's a load testing or penetration testing to check on those uh performance test results and the customers should be okay with it so all these criteria we ensure it is met before we decide to take it to production in the next release so basically these are the points I wanted to cover as part of a user story great uh brilliant thank you okay so next question is uh interesting it's one estimation so when estimating a project task what are the most effective methods for new teams versus the experienced one that's the first question and the follow-up question is how can these methods be adapted to fit the specific need of each stem each of those particular teams so that's the question okay so uh as you rightly mentioned like one estimation technique will not fit all themes so you as a scrum master I need to be aware of the maturity of the team is it new or uh and the application also is it from scratch is it newly getting developed or team is quite comfortable with the technology the application business side So based on those criterias we'll have to pick it up so to start with if I am a scrum Master for a new scrum team who is just starting to pick up development starting to build something from scratch or rewrite or whatever then it means the maturity of the team is pretty low they don't have a historical data to back upon so it's quite natural that their estimations may go here and there they may not be able to meet what they say so in those times maybe they are not very comfortable story pointing or things like that the numbers itself doesn't make sense for them so I would just start with doing hours just put in hours like what whatever you feel you need to complete this particular stories give those number of hours to us for us eight hours whatever it is so once you start doing that up after three or four Sprints you see the stability of the team if they're able to complete this story within the estimated time most of the times it means they're kind of comfortable then you can probably introduce them to something per t-shirt sizing it's not as matured as story pointing but better than ours so I'll give them a analogy or a matching criteria like if you are using two to one to three hours you can say the story is small three to eight hours it's a medium story or more than eight hours it's probably a large or an Excel that way you if you if they come up with a matrix like that and instead of just giving one or two hours in exact terms they can give it as a medium large or Excel that kind of uh estimating in terms of t-shirt sizing then you see again for three four Sprints if it's working fine they're able to finish in that time Gap then you refine it a little more and introduce them to the concept of story points what we did all this far was estimating in terms of hours now uh that is effort estimation then you can introduce the concept of size estimation which is exactly what story points do so you can tell them like uh uh experienced developer he may take probably two hours for that particular story a new guy who comes in may take four of us uh the complexity of the program hasn't changed it's just that this person is more experienced with this setup than the other one so you shouldn't be totally only again on uh top of the efforts alone so in times in terms of sizing uh instead of just giving the number of hours we give one or two or three story points uh in terms of um you give it a bandwidth like say if it is one story point you say it is about uh two to four hours or you don't even give an hours you just say this is the simplest story which you are picking up is one story point so either it is a experienced guy or a fresher it doesn't matter the size is Still Remains one story point for everybody So based on that simple story you estimate the remaining stories like to uh as we know it is normally in the state of Fibonacci series one two three five eight that way you go ahead and go ahead with your estimation you can use planning poker um most we have digital uh tools also now where the cards can be displayed online whoever is estimating the least and whoever is telling most they get to discuss with each other and come up with a middle ground like why they are giving that less or that more and they come up with a story Point uh estimate which is applicable for all so probably these are the basic uh estimation techniques which I have seen other than those I've just read about something called dot voting where depending on the complexity people put dots on a particular paper and show it across and if the more number of dots the more complex it means it's a very vague it doesn't give you a very value ad I guess but I'm not sure I'm not actually practiced it anywhere the other one normally what we use is kind of analogy estimation by analogy you have done a particular functionality in another screen a similar functionality then you take the estimate from that one and say that we will be required similar kind of effort for this one also so that is estimation by an object or last one is estimation by experience your team lead or architect he knows what how it goes the world goes and he estimates for all of you that's how it happens normally in the waterfall projects so yeah these are the basic types okay good there are many as well but that's okay I think you've done a fabulous job by explaining all this now sequence so great okay so let's move on and this question is again my favorite ask in so many interviews so far and the question is what is the rational behind using the Fibonacci series in story pointing and uh how does this practice help teams to estimate us more accurately and more efficiently so okay so as we see in the Fibonacci series you add first the last two numbers to get the next number so it's one two three five eight and goes on so if you see the trend of those initially the smaller the story is uh the more it has details the more granular it is so any minor change you do in the story also the effort for it will change so when a story is pointed as one story and some little addition is added also you may have to change it to two or three but the same way if it is already a big story say five story points and you add a small chain of validation change or something like that it's not going to make a very big difference for the person who is developing it when he's already taking say about 16 hours if he's taking 16 and a half hours it doesn't make a big change so what Fibonacci series tries to tell you or is it tries to force your hand when you are doing an estimate it uh tries to tell you that don't focus on too many minor uh minor things or the Minor Details of a story if the story is already big it also tells you that if the story is with more than eight story points uh it suggests that you should actually break it down it's not a granular enough for the team to pick up for development so that way it gives you a trend um on telling you like how to use the Fibonacci series how to story point it and what is the complexity you are actually looking at so that's my take on that okay great thanks for that okay so next one is again little bit twisted uh so so of all the events in the scrum process which is your favorite and which do you find most challenging that's the question and the follow-up is how do you address any difficulties you encountered in these events okay so one of my favorite events is the Sprint review meeting the reason being like uh you are showcasing what you have developed in the Sprint as a team you're showcasing what we have done to the end user the stakeholders the product owner so you feel proud when you're when you have met the Sprint goal it's a proud moment for the team and when they do the demo and the customers are happy with it and they say you guys have done a fabulous job we'll take it to the next release and things like that it's like a motivation factor for the team it is a time to reflect upon the hard work you have done and how it pays off and things like that so that is one thing and normally in the review calls the product owner also highlights on what is coming up the next couple of Sprints so you get to know the pipeline more clearly and they may also discuss with the stakeholders on hello you're able to hear me I was stuck again okay okay uh so normally the product owner discusses with the stakeholders on what is the market uh trend is there any change in our approach or our priorities so the team gets an idea of where we are going from the business perspective what we need to be mentally prepared for in the next upcoming Sprints so that it gives you a very good uh view into what we are working and what's coming up so that's why I like this print review a lot um as a follow-up question since you asked like uh if you faced any difficulty in that particular event the event comes up when you have not met the Sprint call that is a difficult thing to say that you committed for so many number of stories you couldn't make up to all of it but even in those cases uh as one of our principles of being transparent if you have a product owner onboarded and he is informed about all the issues and why you couldn't complete some of the stories I think we are still good enough we will be able to convince the other stakeholders or tell them why we were not able to do certain things maybe it's not in our hand there may be a downtime or the third party didn't give you their piece of work on time that some things you can't really do anything about so I think even in those cases it were transparent and you have everybody uh updated about the current status I think you can still pull it through it's okay so that's about the uh my favorite uh event the other one most challenging one I feel is the Sprint planning more so if your product backlog is not very healthy if it doesn't have a lot of items for you especially once the major goal lives have happened and you don't have much work in your product only some CRS or continuous improvements only other you're really digging to bring out that much value from that Sprint that is when you find it little more uh challenging or in in certain cases you have a lot of items in product backlog they're not groomed enough your product owner has changed or there's no particular person who is taking up that role from your customer side so there's nobody to prioritize it for you or any dependencies there's nobody to help you out to clear them that's when it becomes very challenging so you know it's just a 15-day Sprint and before you see you're already there at the next print and you need to be um on top of it to bring something to the table to your developers to start the next print so that's where the scrum master has to run behind the product owner or the da or whoever has to prioritize work for you so otherwise the team will become uh if they don't have enough work for the Sprint either they start doing something else not required or they will lose or else and that interest to work starts reducing if they feel that they're not adding value so that's the most difficult part I think true so before we move on I just remember one thing apurva that we have created one complete scrum Master course where we have jotted down not even jotted down we have given the live demo of all these events uh planning retrospective review everything just combine together it's for everyone who is watching this video till now so if you are new to our Channel I will highly suggest to go and watch that complete four to five hour session we are where we have given you the theoretical plus actual session we have taken you to the jira board actual user stories things like that what the role of scrum Master Po developers everyone in are there in those sessions so just go and watch those sessions that will be really helpful if you are a new scrum Masters or not have that kind of exposure in your uh you know uh in your organization so just a note okay so let's move on thanks approva for that yeah this question is again my favorite so if you are giving five interviews four times this question will be there and it's on conflict so the question is uh have you ever resolved a conflict within your team so if you are scrum master your answer has to be have to be yes only you cannot say no so have you ever resolved a conflict within your team of course yes now the follow-up question is what was the nature of the conflict and how did you go about addressing it so that will show the depth of a scrum master so yeah over to you apurva yeah so yeah conflicts are part of the part and parcel of the process so when all of us as a team a set of human beings are working together for long duration more than a year or six months or whatever it is bound to happen that you get into friction you get into conflicts every time it can't be honeymooning so it is has about to happen and uh it's normally the scrum Master's responsibility to ensure that they don't get escalated you need to resolve it soon and ensure that the team is moving uh pretty smoothly again uh yeah so there are couple of types of conflicts which I have faced one is within the team members or with the product owner or there's a new technical uh strong guy from the customer team who enters the developer team and he starts doing a lot of things which we were not doing before so those are the kind of things I want to talk about first one is within the team members so as I said as part of the quality process we have this peer review process in place so most of the developers are of a similar caliber similar experience also so they suddenly got a competitive feeling probably because it was appraisal time or something they wanted to show that they are better off than the other person suddenly so what they started doing in the peer review was unhealthily they started reviewing the code and started raising so many issues which is okay good to have but in view of the project timelines and if you see the quality it's not exactly essential for them to have that particular comment Incorporated at that particular time maybe you can add it as a good to have in your backlog and use do it whenever you have time but they were very reluctant to endorse that code and move it forward uh through bitbucket and all that so that's when I thought like once one person does it the other one also does the same to him so that way it started becoming little of attention in the team uh so whoever were the mentees of the this guy also started getting the repercussions of that so it started forming two teams within the same scrum teams so then what we thought of is uh first before before telling them that this is happening we thought we will rationalize this process and come up with a checklist even for the peer reviews so if it is a very important story is what is the first set of critical criteria you need to consider if you have time what is the next set and what are the good to have So based on the checklist you please do the review and don't be too high flash on the team if it's not going well if they have not done the good to have parts of it and apart from that I just spoke to each of them individually and asked them like do they have an issue like even personally I'm okay like I like to build a rapper with the team individual from an individual perspective that's when they open up to you and tell if they have any issues right so well I understood that one of them were actually waiting for the promotions and the other guy is just like that right because that fellow started even he was doing the same so then I had to assure them that they will get whatever they deserve and it's not like it's either you or him and anyway the company is going to fit everybody into a welcome where everybody is actually competing with another person whom you don't even know so why do you want to complete within your team itself so uh with the checklist and the mentoring that kind of uh unhealthy competitive attitude kind of reduced in the team that was was one and second one was with product owner she was new to the team uh like she had no idea about our project what they were what we were doing uh so once she came in she was very unsure of herself so she didn't know one how to prioritize stuffs and when we give a demo she was very reluctant to sign off anything because she says I don't know what it contains why you have done this I can't sign this off so if everything starts getting piled up and she's not signing off anything how will you go live it becomes very difficult no so then and this is a difficult thing because they are from the customer side you can't say you're not doing your job well it's a difficult situation to handle um so here I felt just by doing everything myself will not work we have a few of our counterparts on site who work with them on the ground who sit with them on the ground uh so we identified a ba from our side who had good knowledge about the application and we gave her confidence that she can actually ask him for help whenever she requires any consultation like thing whether this is good to go or not until she becomes oppressed with whatever we are doing right now she was a little more confident then and after working with the ba and he gave a lot of sessions to her she was she also started writing stories grooming the stories and all and it started becoming more stable that was one and the third one what I was speaking about is a nice tech savvy guy from customer side who got into the development team uh he was really good he had a lot of technical knowledge no doubt but the problem is this particular application was built almost for three four years he didn't know that all the workflows all the layers which we had if he touches what what else will happen that kind of knowledge he didn't have and unfortunately he was given direct production access because he was senior and he was from the production side anything happens from production he'll directly fix it in production and we were not tell us also about it so when our release goes next it would rewrite his code and next time again the same bug comes up and he's like I had fixed it already in production how did it come up again so then we had to make him understand the process it has to go in from the developer box into all the higher environments she can't do something directly on the production side that way so yeah without hurting his ego and also trying to make him understand the process he was like every all this is so much bulky we don't need all this uh so much process why can't we just do it on the make a hot fix in the production environment and things like that so our tech leads had a little of a tough time to tell him what would happen and we had to tell him that we had such a process before and why we brought in all these other criteria to help him out yeah then I think he got some traction from his counterparts from the customer side also and things kind of settle down some really nice scenarios for you great good good for our viewers they are getting so much different kind of uh examples for conflict okay great so next one is again I would say I'm for me at least I am saying it first time that someone has asked you this question and I think this is a very brilliant question to ask that can you describe a scenario where you applied your knowledge of whatever certification let's say psm1 psm2 or any other certification which you have to assist your team in overcoming any challenging challenges or any scenarios like that or achieving their goals things like that yeah but I at least for me I was fortunate I had the opportunity to do that I think in most many places when things are settled and going well they want you to go with the process they will not allow you to just change everything uh upside down on day one you come but uh I had the opportunity to do that I can say uh initially when I started off as a scrum master I was handling a middleware team where they were writing the Microsoft Services which was being consumed by other UI teams so initially how it was planned was this particular middleware team used to write the MSS for multiple uits so they started using the kanban mode uh so that the tickets from different UI teams come in and they keep closing it and moving forward maybe at that point of time it worked for them but after couple of years each of the team had a separate MSA team for themselves so the team which I was this from Master for was dedicated to one particular urd they were not uh assisting any other teams so what the requirement was you need to write this services for which you the UI developers will be developing the next trip so it's just that logically you're working in N plus one mode than the UI teams so you exactly know at the starting of the spread what all are the services you need to create by the end of the next 15 days so that's when when I thought it's not making sense they're not using a ticketing format there's no SLA has nothing like that why are they using kanban so though I was a new scrum master I just went back to ask the my seniors and Leadership like why they are using kanban don't you think scrum is a better model so thankfully they took it nicely and they said yes if you feel you can do it you are the star must now you can try and do the scrum for them and start with those processes it worked out beautifully for them so and even the UI team started appreciating it because they know what is there in that Sprint which we are going to come up with they could go through our Sprint backlog and see if their requirements are there in that particular Sprint and in our demos they could come and participate and see that the results of that particular service is what they were expecting as a to consume so it was really well taken and appreciated that was long back and the other one which we did is towards the end like uh last six months or so most of the goal I've had happened and we were left with only some CIS and a few technical debts not much of a backlog and we were forced down to ramp down the team because we didn't have much work the UI was written in Salesforce and as you know it's kind of a niche technology you don't get those developers often if you release them uh and also the customers were like whenever we want we'll let you know you please hire again it's not as easy as it seems right so we as a servicing team we had to come up with innovative ideas to retain the talent as well as make them buildable so what we thought is uh at that point since everything had gone live we needed an operations team also ticket started coming up the developers only ever doing the ticketing work also bringing it in as CRS and all so I said I think at this point we need a devops team not a development team alone will whatever developers we have we'll just split them into few developers few Ops engineers and few testers so the developers and Ops people they will keep rotating in a cyclic way so that they get an experience on handling tickets with the end users talking with end users and also doing the CR work as a development team so that's how I brought in a devops team together and the devops kind of culture the metrics everything started getting reported that was also actually appreciated by the customers great great uh thanks for that okay so next one is uh how do you know if your team respect you as their scrum master and uh what actions or qualities on your part which you can you know which you can do to earn that respect so yeah it's very behavioral kind of question but yeah it's good to know the answer yeah right so what I feel is personally we should be able to connect with them you should feel empathetic towards each of them and slightly know them a little personally to be able to connect with them easily so then uh if they start treating you as a pal or as a buddy instead of a manager kind of thing they stop hiding things from you if they need a leave they will say they need a leave for this reason only this personal reason only they won't say my network was down power went in these kind of reasons they'll not give you need to give them the confidence that they won't be penalized for coming up with a truthful answer so that is one thing and the other one is impediments they normally look at you as an impediment uh removal facilitator so I will ensure that if there's an impediment in the team or any help they need with an external team I will make sure that with the minimum of uh required time I try to assist them either I'll get it remote or that particular story is blocked with somebody else or they get the immediate resolution by following a multiple times with them to ensure that their functioning is smooth so that's when they feel you are a value add to them because development wise somebody is doing a business procurement why somebody else is doing so what else this guy is doing sitting here and taking all the ceremonies and writing reports then it becomes kind of clerical right so instead of just doing that job I feel uh the impediment removal and coaching is a really good thing and when it is their appraisal times and all or even the other ways if the team is slightly having capacity if you feel I try to coach them on their lnd perspective also how they can improve in their career or how they can gain knowledge from something I try to organize some hackathon kind of games or sessions from Seniors or mainly the dependent teams whom we are dependent one if they get a view of how the third party teams are working and what is stopping them from giving them something why is something getting delayed they'll be able to appreciate it better so these kind of uh basically I try to interview the teams and make them feel better so that's when I feel you'll be more uh respected great great thanks a lot of purva so you just uh talked about impediment so have you ever helped your team to overcome an impediment to their progress if you want to share some examples and what was the nature of the obstacle and how do you work with the team to find a solution so that's the next question for you poorva okay uh I would like to bring about two kinds of impairments one was from their personal side and uh two others from the customer side uh one from the customer side and the other from the third party side the personal impediment was like a few of these guys three four developers they were uh they were good technically they were good but somehow they had a little inhibition when they were talking to customers basically because of the accent of the customers their UK based or us-based they are either not understanding what they are telling or very hesitant to put across their accent of English to them thinking it is kind of inferior so even if they have very value-adding suggestions or real issues they want to come up with they used to hold back or just write names not talking to them on the call not switching on their videos and things like that so what I try to tell them is it's okay like you see Russians Germans they're very comfortable with their own languages it's not necessary that you have to be very good at English to be good technically you have been taken as a good technical resource basic if you are able to communicate that's enough nobody is going to question you or judge you based on the way you talk so it's okay with that so you have to start opening I mandated them to switch on their videos so daily if you're seeing the product owner or ba or somebody from the other side you feel more connected with them so that helped a lot and also in teams we have the transcript feature uh I think initially it was not enabled for all of us so I got the ticket raised for all of us to have the transcripts on so some of them talk a bit fast we may not be able to follow them fully then responding them back to them meaningfully is not even possible so I asked all of them to switch on transcripts and I openly told the customer each of us have a different accent many of our people may not be comfortable for a more valuable conversation will please have this transfer they were totally okay with it so after that it really helped the communications and the calls became more valuable that is from a personal front and uh from the third party front there was one team who was based out of South Africa culturally they are so much different than us and the way they handle things the pace at which they handle is so much different it's not that they want to really deliberately they are delaying things for us but everything is slow there it's not like they're doing it deliberately for us so what I uh I had to do is we I mean we had to eat a lot of bitter cake and not getting their response on time people getting frustrated and all so then I had to talk to their lead and try to understand why this is happening he didn't even see it as a problem what is your problem we are doing our job kind of so then I tried to tell him this is the this is the Sprint timelines we have we have to give our deliveries on time but this is not the pace at which we work at all you can't ask us to do it in 10 days and things like that he was saying so then we thought of coming up with the calls every alternate day or twice a week where you discuss your impediments or whatever dependencies we have with the team and what is the severity how soon they can give it to us so based on that you can groom your product cost print backlog and know when they are going to give your items on time so that that impediment was far more better handled than before so that was the one and uh one last one was from the customer side they brought in lot of new guys uh they wanted to also be part of the technical team initially everybody was from TCS they wanted one or two guys also from customer side to know what we are doing or be part of it to have that inclusion but the problem is they were not at all aware of how many environments we have how we are going to do the deployments the process was totally missing so as I said earlier they either do something directly in production or if that is giving a problem you push everything to our developers let's say take this forward it became a real huge burden for our team to again unit test the court see the sanity see the sqa see everything is coming together without blocking anything and push it so it for uh almost you say equal amount of items you have to do what you have not developed also see what code they have written and all so then we went back to the customer saying that this is becoming a little heavy for us and we thought of coming up with a workshop for all the new guys for a week or 10 days as we did a workshop and told them all the basics of how things work and we recorded those sessions created some presentations for them with all this screenshots and things if all of these doesn't work then only please come to this this person in terms of escalation kind of modes so if this person is not able to help only then you meet this only then you meet next so that way it really helped initially it took some time we had to put in more effort to create those materials give them the trainings but in the long run it actually helped our pain points I really enjoying this conversation but looks like uh you have I think 30 40 minutes into this session so I think it's best to stop the session over here only and we will again going to do more sessions with you of course so friends uh yeah we hope you found this session helpful and uh don't forget to leave a comment and like this video to show your support and your feedback your feedback help us to create more valuable content for you and if you're new here please subscribe and become a part of our career Stock family so friends with this thought see you in the next session and thank you purva one more time thank you thanks all