Scenario Based Scrum Master Interview Questions - iZenBridge

hello everyone and today we are again talking about scrum master interviews and questions which usually comes into scrum master uh interview but this one is little special because i saw the questions in advance i got an email and i can see it's more like uh conversation rather than there is a particular concept which needs to be uh answered so maybe you just give a quick background about your interview experience and we get started with your first question yeah yeah sure suck it uh interview experience in the sense like this is my first interview that i had faced and luckily what happened was like whatever the questions i had faced during this interview all was uh it was not no nothing was direct question it's like like what could be the thing that thing and all i have expected a different kind of interview but it was always it was like it just went like a conversation as you said and i feel like if only if you are there in that situation then only will be able to answer that i try to answer whatever i am aware like as per my knowledge and my experience but i need your expertise to understand like how actually a scrum master should approach or should act in such situations perfectly perfect and you see see the interview is a little specific case it is not only about an ideal situation and responding to it it also depends upon what kind of a culture what kind of a scrum that host company is following so there could be some time where they may ask scrum question but they might be thinking a project management answer or they might be expecting a project management behavior where they are interviewing a scrum master uh for for a role so let's see let's explore and because that that part also need to be considered you cannot replicate the same answer in a different interview because little bit you need to sense what this guy is is looking for yeah let's get started maybe we pick up a first question and then we explore yes yeah sure suck it uh my first question what what what was been asked was like being a scrub master um you have a team and what if your team what if you observe like your team is continuously failing to whatever they have been committed to for example your team is committing 40 story points to deliver in your sprint or 50 story points but never ever they were able to achieve that but don't say that like i will try to understand like i'll go back and try to understand what were the issues uh what were the blockers that they are making them to uh were not able to achieve it or i will coach my team something like that apart from these answers as a scrum master what innovatively you do what differently you do that's what they asked me okay okay so let's see again there was a question and then it also depends how do we answer it now as a scrum master if if i am i am uh answering this particular question i will ask what is my role am i joining this team as a new scrum master or i have been working with them for multiple sprints so that's the first question reason being is if i am joining this team as a new scrum master then my approach is yes they have a history of doing something and how do we take it forward if i have been working with them then what was happening in previous retrospective so it's like that we are saying that it has been four sprints that the team is missing the screen goal so what happened during those four retrospective and what were the actions which we decided and which worked and which didn't work because hypothetically uh giving answer might be difficult so i need to strengthen primarily i need to strengthen my retrospective if it was not happening in the in a particular way because the whole idea of as a scrum way of working is that i need to make this awareness in my team that they are unable to meet their commitment and the stakeholder expectations are not matching with their with their uh kind of a commitment adherence and how can they improve it it better and in scrum word all these answers should be discovered during retrospective meeting rather than i as a scrum master tell them that guys from tomorrow onwards uh why don't you make uh something like like that so that could be one particular thought we will explore a few more thoughts related to this but what do you think about it so what in that instance what i told them is like i didn't actually i would have thought about the retrospective things like that but i felt like all my options were closed at that time they said they specifically said that don't don't say like you will coach your team you'll understand the issue you will discuss the things you will come up with the solution things like that but tell uh tell us like what individually you will do that that time what i told them is like okay in this print what i will do is like uh i will ask make my team to commit less than what they have been continuously committing less velocity so i will see whether they are able to achieve it i am thinking in this prospective i'm thinking like they might be over committing to what they can do so that's that's how i told then immediately uh they asked me like do you uh did do you ask your team to reduce your velocity is that the right way to do that i don't have an answer for that i told them like because my team is failing i want to put them in a place where they can be successful instead of failing yeah so especially in an interview context and i think in general also as a scrum master even as a project manager whoever is a leader i would say that refrain giving solutions especially specifically refrain giving specific solutions so rather than saying that solution a will work solution b we work solution c will work you may bring a situation around it so first is that you are saying it all depends upon the retrospective because it's very difficult to hypothetically give an answer i don't know how many members they are what are their impedement what what are their blockers because if they are unable to achieve something i need to first see the as an agile practitioner what i usually say is not meeting commitments and not getting delivery on time is not a problem it's a result of a problem or i would say it's a symptom of a bigger problem so i need to find out and they said that don't do an analysis but i need to find out what has been the blockers before now again the if if the person stress on it then i can share some of the things which happened in my team before and they it was not like multiple time we missed the spring commitment but we had some instances and you can bring a story where you say i joined a new team where they have been missing this this uh uh commitment for a while and we did a detailed retrospective with them and one of the the in that particular team one of the thing which we visualized was that people were uh like we had an aggressive product owner and in front of them they were very like they they these guys were usually committing whatever he he asked for and during the sprint planning meeting the the product owner was driving them to commit usually more than they can do and because of that commitment they try to do so many things and and that creates a lot of issues during the screen and at the end we don't need even 50 percent of it so in that particular case what we did we had a conversation with the product owner and we we had an agreement that we need to limit work in progress so that we start producing something at the end so we want to produce more it is not like we we are going to produce less but we want to produce lot more but we can only produce more when we commit less and in that particular situation we decided to manage our work in progress in such a way so that we can finish our work uh frequently so you can give a particular example like this there could be many things which might have worked there could be an impedement so you might say that in another team it was always a dependency management issue so we were unable to meet our sprint commitment in a given team because we were always dependent on some of the apis some of the things which were coming from different team and because of that we were always struggling so we had going forward we had some kind of a commitment and some kind of an agreement with product owner about the the readiness of the items which we can take in a given sprint and we ensured the items which we are picking up in a given sprint has dependency resolved in a previous stream itself uh sprint itself so we kind of in that particular space we started working more aggressively on definition of ready and then we we figured it out uh to improve our velocity so my okay what do you think about these two things uh yes actually these things are making sense yeah yeah i agree with that so sometime what happened is that the interview might be pushing you yeah that just to see that how much much you can show a restraint and how can you you can like how can you manage the somebody is driving to a particular behavior whereas you need to put your point so there is a possibility this interviewer might be doing that that's one possibility the another possibility is this introvert might be looking for how much project management attitude you bring in so where you say i will do this i will make them work hard i will monitor their work on a daily basis and and i will assign the work very carefully then this they they also kind of sense that person is too much micromanagement oriented so i don't know what was the goal of this particular question maybe they just wanted to understand uh how you would approach when such kind of situation is put in front of you so if you have to like if anyone who is is watching this video i would say make some situations and try to do it in your current scrum team as well so whenever you have a failure in your sprint goals and all focus on on that particular retrospective try to find out what was not working and then make a clear case around it that yes this was the the thing this is how we changed and this is how possibly the some amount of improvement happened and in some cases even if there is no improvement you had a learning so create so usually you know interdependencies estimation errors uh uh in between uh uh uh work allocation like changes during the spring uh uh changes in priority changes in work item can drive the the poor goal achievement unclarity of user story poor backlog refinement all these things are and there could be many such there could be many reasons for for it so what we need to show is in in an interview that yes i am aware that there could be 10 such possible reasons which can drive this kind of a behavior but i don't know what is happening here since i don't know what is happening here i cannot prescribe the solution here i can only say that this has these these were the things which has happened in the past okay yeah that makes sense okay next yeah uh next question is around almost that only so what will you do as a scrum master if a product owner is directly assigning the work to one of your one of the team members either it could be during discipline planning or in middle of the sprint yeah so see what you see here yeah now they they might be facing this problem actually and and uh uh that might be making the the thing drive or reach to a situation where spring goals are not achieved yeah it may be so if if this question comes as a second question you may say yeah this can also drive a behavior where sprint goals will not get met yeah so okay now let's come to a particular question so we are saying here is what do you do when you see a product owner directly intervening in teams ways of working he assigns the task during the spring planning or even after that is this the right thing to say yes yes okay what do you think you should do here let's start in the conversation space what will you answer yeah i answered them saying like being a scrum master if it is happening at the middle of the sprint definitely i'll go back to the product owner and i'll check with him what was the thing that made him to assign that work add that work to the sprint goal right now because in we are in the middle of the sprint and it affects the goal sprint goal so i'll check with him and if anything that we have taken as part of the goal that can be prioritized and this can be this needs to be added i will take care of that because adding this additional work to the team might increase the whatever they might not be might not let my team to work in the pace right so that's what i told them and i also like directly as i'm assigning in the sense even i could not like i i never faced a situation i could not even imagine like what how it happens directly he is signing someone uh work to someone it's like i could not answer it properly if uh if you ask me honestly okay okay so see it it could be any any uh uh stakeholders behavior that a particular stakeholder intervening very frequently in your team's ways of working within your team environment so that could be a situation and in this case a product owner is there it is there again giving a direct answer would be difficult so we need to go back into the situation so saying that okay i will not let the change happen again it may show that you have a very rigid attitude so i if i am answering again and there could be multiple views of ways of answering it but if one of the way which i i see is that i need to empathize what makes product owner do this yeah so uh is it a repetitive behavior is it a one time something and what are the reasons which are driving these behavior there could be multiple reasons one reason is the product owner is not aware of of scrum way of working and he feels he's doing and help by way of identifying right person for the right job so that could be a behavior and if that is the reason then i have a conversation and clarify the person that do no this is not the case let these guys figure out because ultimately they need to self-organize so maybe my product owner is not yet aware of how self-organizing way of working produce better results so that could be a just understanding gap the another possibility could be that product owner might be not sure of what these guys will do yeah and he might be facing multiple sprints where the sprint goals and commitments were not met and he sees something coming urgently and he may feel at least this guy can deliver it so even the whole team might not be delivered if i work with this particular person or this particular thing at least this thing will get done so if that is a behavior then we need to solve a bigger problem where where we say that we make the team reliable we make the team which can commit and deliver rather than and always there is a firefighting so whenever this is this we can see as a firefighting it's always a crisis you know and and somebody is is putting you in the crisis all the time now there could be two ways of looking at it one one is the person might be creating crisis the product owner in this particular case because he believes until unless i create crisis these guys will not move yeah so i need to again understand i need to create a stable space so that this movement of crisis stops happening that could be a second situation the third situation could be that it's a one of the case and and something has really got changed and the product owner really wants to have some opinion about about a part of work and and if that is the case we can identify how to deal with those situations rather than product or not directly jump into and talk to the team we can have a conversation between product owner and scrum master and maybe a team to find out how do we deal with maybe possibly there could be a situation maybe just after daily scrum we can have a quick 10 minutes meeting where we can explore what are the way we can handle at this particular specific need which has arrived in this particular sprint alone which might result into adjusting the sprint goal which is not as per the scrum guide and all those things but again it might result into something which might be agreeable to all the the stakeholders all the the scrum team members so that could be a third a possibility yeah okay saket i have a follow-up question on this so i know the team should be self-organized always and the product owner is from the business side and the scrum master should be always playing a role in between them is it like that he should be always protecting because ultimately whomever whether it is a product owner other scrum team everybody is i mean so the development team everybody is working towards one goal everybody is one i have one objective one product to deliver or whatever so uh why we are having these things why the scrum master should be always uh should play on behalf of development team only role why can't he come to the product owner understanding his requirements his business priorities and why can't he put some push over the development team i i think uh that this is this is something my personal opinion is that many times the scrum has been taught and scrum has been read as if that product owner is a character who is trying to attack the team and then scrub master is the only savior who can come in between and save it yeah so many time we we we have that kind of of of kind of a view uh i think in in practical purpose we need to empathize with all the stakeholders so we need to understand what is happening and in a product owners space as a scrum master i need to empathize with product owner in time i also need to empathize with the the development team it is not about a over b and a is good and b is not good and a is agile and b is not agile it's all about how the development team creates a confidence in deliveries in product so that product owner and other stakeholders trust them and at the same time how product owner gives the development team space to plan space to execute space to decide uh the how part of a work so that they can they can feel autonomous they have a sense of autonomy which can let them deliver better results so i as as a person i am playing a coach role here so i coach this the product owner i coach my development team and i think the the the thought process of i need to protect the development team uh uh i'm not sure i don't think many organizations appreciate that i think most of the organization appreciate a collaborative working and and focusing on overall goal achievement rather than creating a silo inside the scrum team so i think organization will not appreciate that in general i i guess that okay okay thank you and shall we look at next question yeah yeah yeah yes yeah so next question was around the conflicts uh conflict management so what they said was like we all uh because of this pandemic situation we all are almost every company is working has offered work from home only for its employees and all the teams are working from home during these times like how how you are managing the conflicts at that conflict also they have mentioned very clearly saying like if at all if the conflict is around the availability of the team members for example we all are at home and everybody will have some personal things to take care of for if somebody is like some critical member in the team saying like okay i have some emergency this emergency that emergency and all if people are missing like that from the team and ultimately definitely it will affect the goal sprint goal and whatever they have committed to deliver they may not be able to deliver so if at all i uh they did not ask me like whether you are falling into that situation or not they say like okay if at all if you are falling into that situation how do you handle what do you think uh so what i told them is uh okay uh because uh whatever the emergencies the personal things because it's everybody's situation now we have to manage our work and personal life also it's like they both are on side by side right now so uh every uh what if somebody is saying like i have some personal worker personal emergency we cannot even question back saying like whether it is a true or that retrospections we cannot do definitely but apart from that what i did was like my goal is as it as a master and even as a team we have to complete whatever we have committed so i will encourage my team i will bring up some policy saying like okay uh you if at all if you are not able to work during this time so you can work at any time in a day and also what i'll introduce is like for example from this time to this time if at all if you are working i will give you additional benefits so that it will encourage the team to deliver my goal will be completed my goal will be achieved whatever i have been committed and if somebody is not available during the normal office hours they will they will be able to do that and tell you okay perfect perfect so what do you think what weakness might be there in your answer if you reflect again yeah because everybody likes to get additional benefits so there is a chance that people might tend to work during that time only rather than this time prefer to do that so that they will get additional benefits as well okay so that's the one weakness you see what else i'm not sure perfect so what i see is just remove the eye from the answer you don't have to do all this now from i is you need to facilitate only so i put this question so thing is like this assuming you have a development team they are working and you because of this current situation you find that some of the development team members work times are becoming unpredictable their next schedule is becoming also unpredictable yeah and that is creating a pain in the other guys that you know i want to work on something and this guy is not available i want to get that information but this guy is not available and that's that's becoming a issue so now how as a scrum master or a coach i should handle it now i don't have to create a policy yeah i need to remove myself from there i need to make them have a conversation so that they can revise their working agreements so they might had their working agreement when they were they were working in in a one room in a one space in an official environment but now since that office environment is not there it's a new environment what should be our working agreement and how should we deal with the situation when someone is taking an emergency off how should we deal with that so i will primarily ask this question in that particular interaction which will help us in creating it and i can bring some example of my current you can say from your current phase of working he says we don't have that much problem but we have revisited our working agreement we agreed to a common working window during that we are available on our say messenger or slack whatever you have so people can just ping each other and they know at this point in time everybody is there and beyond that particular window we have an agreement of if you drop us and when to send an email when to send a message when to send a whatsapp message and once when to call the person we have identified that particular thing and we are using our electronic tools to ensure that all those dependencies are well taken care when the person takes some some emergency leave so if the person goes for an emergency lives but he ensures that he has communicated all the desired things to someone who should be knowing so that work never stops and they have their own agreement on what they do once they take an emergency leave and how they make up for it so it's it's little asynchronous way of working rather than a synchronous way of working and the revised working agreements are helping us to resolve this conflict conflict and we do have you can put a thing a frequent our video based calls where we talk about we do our daily scrum or we do few things so that at least one level of connection is always there so i insist on keeping their videos on and we we have some policies to to encourage and appreciate the good behavior where people keep their videos on and have a conversation so that keep them little connected with each other so something like this what do you think yeah saket i agree yeah i think i had this uh a wrong person like wrong habit of using i i more often i shouldn't be doing that i understood that i got it yeah yeah so it's like that don't own the whole problem on yourself so what but as a one solution for all scrum master and even if you put in today's world even a project manager uh role also the the leadership role be it a project manager or a scrum master or any is becoming more like a facilitation role now so rather than i get into it and i create a policy for them and i let them follow that so it that that answer make people feel that that this leader may have a controlling attitude he solves his problem himself or herself so we need to take it that okay if especially when it's a people issue so when there are individuals and they can talk to each other and resolve it he says okay i just put the issue on on the table and i make everybody talk about the table not to run away from that conversation and once they talk about it i just make them agree on something and my role is bringing the topic on the table making people agree and discuss it in detail and and reaching to an agreement and later on i ensure that they adhere to it so i have some mechanism to reinforce that behavior yeah so that's it that's what that's what my role is yes i get got it and the next one is again around the team members only like the question was like this what if if one of your development team member uh he's saying like okay there is a task that takes actually two to three hours only but he said like he spent about eight hours on that simply like he didn't nobody knows whether he spent it or not but he for example for this instance we just assume that he is lying that he spend all the eight hours on that particular task so how do you as a scrub master will love what you call uh identify these kind of issues and to solve these kind of issues so i think the overall interview questions either they are really for focusing on the traditional project manager doing a scrum master job either or they might they might want to validate that is this person is thinking as a project manager or as a scrum master so maybe i don't know which one is is the case but that seems to be the indicator based on this question as well so okay so it can happen and and there could be a someone especially in the in the current environment here someone says oh this is an hr work only work for two hours and then disappear after that now how can i solve that and and can i give him a call every three minutes four minutes and every three hours four hours and says uh uh is it done or can i say that why takes eight hours why don't it takes three hours why don't it takes one hour and i i challenge the person all the time and if i'm challenging it how many people i have to challenge to is this a one person or i need to challenge the complete scrum team all the time so it could be a little tricky thing what i would say here is that as a scrum master i again focus on using transparency as a mean so if the one particular team member is taking eight hours for a given work is it clearly visible to rest of the team members that this work item is coming as an eight hours work item and what if if this work item can be done by someone else we can we can have a conversation can someone do it in at a faster pace so it is not like that isolatedly you are taking an estimate because that can happen in our old project management space where you ask a developer you know you need to do these three things and he's an isolated guy how much time will you take and the developer gives you some estimate you you cut that estimate by 50 and says do it in this much time yeah and he already has anticipate that you are going to cut that estimate so he already buffered that estimates to you and now you are happy that you are getting enough 50 of the time but he's also happy because he is he got his own comfort and then then this problem may come in that how do you know it was right or wrong and you don't know but in a scrum way of working in an agile way of working we are not letting individual to find out how much time a given task will take we are making a discussion in a common at a common platform so that's the first difference you know so the spring planning meeting has happened daily scrum is getting discussed and everybody is aware what is taking how much time i as a scrum master might be least aware because i may not know the technology but others are more aware and they i i create an environment in the team where people can challenge each other so if that is happening people will challenge and they will ask why it is this particular thing is is happening so that's a one level of difference the another thing is if the situation goes in as a particular case there's a problem with a one particular team member and everybody is is kind of pointing that out you know so all the developers other team members are always aware that this guy always take eight hours for two hours work yeah then i need to have a conversation with that person is he lying is he unable to do it and there is a i'm not living in an ideal world where i say that person will not be lying so if the person is lying we also need to find out what do we do with it because uh uh we need to get rid of that lying habit rather than getting work from that person we may decide not to work too much too much with this person because uh monitoring and going after a guy will take a lot of energy for you as well as for the whole development team and we are working in a knowledge industry where we can't force people to think and engage the people should think and engage on their own so it is not like that micromanagement can ensure me to increase productivity if someone is lying and taking an advantage and not working for six hours i need to get rid of that lying and advantage taking habit rather than fixing this particular problem and if i can't get rid of that particular habit i may not get my result from this guy because i might be spending my four hours to get four hours work from him by way of doing micro management so i also share my experience that okay there has been some situation where such kind of situation comes in and we try to get rid of a lying habit rather than the habit of of estimating for a given task and micro management there because micro managing individual task is is very difficult to to handle in a long run so i work i coach and i i apply multiple technique i pair with with someone else so that person goes little high and and make it visible that okay this is what is happening and do you want to do it or not do it so that's the transparency and trust we need to bring in something around that yes i get even i told them the last point like whatever you told like pairing the developer and understand maybe i as uh i told them like i might not be a technical person to judge whether that task is really a to our task rate or task why is taking control so what uh we have the techniques to pair up with other developers and all within the team so obviously if he is lying or if he is not able to deliver obviously the other developer will be able to find it out i don't think entire team will stand on same thing and will do the same i mean same flying right yeah that's what i told them yeah only thing i want to i add here is in such situation be clear that you don't have to solve this temporary problem of of of eight hour uh not getting used only two hours getting used you need to bring the change in the attitude because how much policing you will do for this guy if this guy keeps doing like that so we need to see the systematic issues what is making these things happen maybe we are lacking our daily scrum maybe we have poor challenge poor estimation during spring planning meeting there there must be something wrong yeah and and there could be something wrong with the attitude of the person as well which also needs to be talked about and discussed so those things need to be discussed rather than particular problem of of a task yeah yeah sure second and one more thing i i forgot to mention that in the email it was around the velocity um so i have seen this in one of your videos and the thing was the question was asked in this way it was a big long question uh so uh every scrum team is expected to improve its velocity during the initial time there will be team conflicts and they have to settle as a team there there will be some uh these things uh so uh it will definitely the velocity might be less during the initial sprints and when or during the fourth sprint or fifth sprint one after few sprints at least the team should settle and they should be able to deliver well and there should be an increase in the velocity as in general and their question was uh okay they have reached you to a certain point and you are finding like okay they are constantly delivering at this velocity for example they started with that delivering 35 points in a sprint and eventually gradually they increase their velocity to 42 at sprint seven now as a scrum master what will you do and they're constantly performing at 42 only they are not able to deliver beyond 42. this master what will you do to increase the velocity of your t that was a question so what i told them is like what i will do as a scrum master in this i will not force my team i don't like to force my team to increase the velocity i don't want them to commit more than what they can what they can deliver that is one thing and if i really put more much more force on them saying like oh no you have to estimate take up these many story points this our graph should go up this third and all they might ending up estimating more story points for the for example a two two story point story they can take up three or five in that way they can deliver more velocity they can increase their velocity right so i don't want my team to get into that situation i told them like okay i did a scrum master uh i can ask my team or i can empower my team to to check for any opportunities for automation to simplify any things in the process that they have been doing so that they can save some time and utilize that time to sprint something else or take up some other story which which is of two or three story points whichever which they can accommodate like that i told them but i'm not sure whether my approach is correct or not i just wanted to check with you i think i i liked your answers and and the whole idea is that velocity is an observation rather than a target so it like you may observe one thing is that you should observe some time going up and sometime going down if if it's the stability is coming in then there could be a two reason one is that you have too much buffering in in in in the planning so you always make sure that 42 will get achieved because you always take say only 70 of your capacity you know so you know you can do 30 more but you don't want to take a risk that's why the 42 always get achieved so if there is a stability there might be something either there is a buffering or the work has become too predictable that people can estimate it very well they know what is going to come they know how the story points are going to work and and that may looks like that there is no variability left yeah so i need to see what is the reason of this stable velocity also is there is a lack of variability in the work or the the too much contingencies has been planned during your spring planning meeting which is producing a consistent velocity and if the contingencies are planned then we also need to see what is the reason of those contingency if in in some environment where stakeholders are too much focused on always deliver what you committed even if you commit less in those environments contingency might be a good idea because stakeholders are more looking for predictability and in order to give that predictability the team might be adding some contingency in their planning so that could be the the thing i think there is no direct answer to it we can just have a have thought sharing in in the interview as well and it's not unnatural and i have seen many time the velocity is going down after a time so it's like that velocity may be may improve and then may decrease over a period of time and and many times that decrease happens when the when the teams are unable to take care of their technical depths well because over a period of time the definition of done also expected to become more and more and more stringent which puts a kind of more work for a given story than than the previous one and and as the system also becomes complex uh and and many uh the technical depths and integration and validation related challenges starts popping up because initially you only had two three pages and you are adding stories it's kind of an independent story but when you have already a good system built and now you are adding the incremental story and assuming that you have not changed your story pointing rule which which remains as if it was in the in the beginning then there is a probability also you go slow because of the the complexity so there is there is a improvement happening because you have an experience you can reuse the content there is an improvement there could be a decrease can happen because of technical depth or that the complexity of the overall system and and maybe a kind of a defects or things which might be coming because of the large uh build up which you have right now so there is like we can't say that if you go in a one uh direction only until unless somebody is monitoring it if you are focusing on that number then it will go in one direction and people will manage it people will start estimating more they will start estimating more effort for integration related work because which was not there before they will start estimating more uh thing for for the increasing definition of done so the same requirement which was one pointer before may become two pointer because they see the definition of then has become more and more uh stringent so it's very difficult to say because there is no benchmark of estimation so if i like if i have a clarity that this was the benchmark on iteration one and this is the benchmark in iteration 10 and this was the definition of done in iteration one and this was the definition of done in iteration ten then i see a change in velocity then i might get some idea that okay what we are are doing yeah so yeah i think i i agree with with overall uh understanding so now not to focus on velocity but yes look for how can we improve our ways of working how can we do how can we get rid of repetitive work how can we uh uh get rid of repetitive steps also and and and some amount of automation and especially when you have a more and more work uh involved then there is will be always an opportunity to do things differently so in a retrospective we need to explore doing things differently not for the purpose of just increasing velocity but also for the purpose of increasing the quality of product increasing the customer satisfaction increasing the engagement in the team making fun during the the the sprint so it's like overall improvement rather than just one number based improvement so i think that is how i probably answer uh this particular conversation yeah okay so saket one more question here so we can uh based on the sprint and the sprint goal the definition of done will keep on changing right we can change it it's not a constant set of rules or checklist that we should be following for the entire all sprints right yeah so it is expected to gradually become more and more stringent so when i say gradually uh so not necessary changes changing in each spring so you are in a first sprint yeah and in your first sprint you want to make something there is a small user story which you are want to make it but uh uh ultimately your application is expected to work in multiple browser and with multiple performance criterias and you also need to update the user manual yeah but initially in the first sprint all these three things were not part of your definition of done for a given user story but once you have reached to say later sprint then you add a small another user story to it but you need to make sure that it works well with multiple browser and it also meets your performance guideline and you also make sure that user documentation get updated for that part of the work then only this story will get marked done so over a period of time once the way you are reaching more and more towards deliverable your definition of turn will become near to definition of release definition to customer use so when can customers start using it so that is your goal that your definition of done should be more and more near to that but initial sprints it might not be because a customer may need multiple things and you just got started you want to have some sense of the the system so initially you may have some gaps in your definition of done which you are expected to feel as you go forward okay okay thank you good yeah and yeah it's a good conversation seriously and there were two simple i think these are these uh these both things i should be answering according to my experience or whatever the exp uh the thing i have the one was like with scrum event you think is more important and uh one versus like uh another one is like which uh what are the things that you don't like in scrum i i felt like okay yeah i told them like it's not like everything anything this particular event is important or anything but everything is important everything has its own importance has its own value that it can bring to the team but uh during while i was facilitating these events different events in the scrum master uh with the daily stand up under retrospective i faced big challenges and i told them what were the challenges i faced and i how i had come up come out of that what i have done as a coach that's what i told them perfect perfect and and that's the scrums uh like i would say the formal statement all also so like if you look at a state of agile survey reports and all so if you ask which scrum practice is more prominent and more popular you will find daily scrum as the most popular practice whoever probably uses scrum end up using daily scrum so that is something happens across the world so if you just want to talk about little bit of statistic in an interview whereas the the scrum also tells that in order to make the whole framework work all events has their role so it is not possible that you can say that okay we are not doing a sprint review we do rest of it or we don't do a sprint retrospective we do rest of it so if you do rest of it you will not get the desired impact because the scrum has been built in such a way so that that inspect and adapt and planning both are both are expected to go so the sprint planning is a planning and rest of those three events are more like inspect and adapt event where we are seeing that okay how things are going at a daily level at a product level at a process and people level so this is how possibly we can explain i think this is more about convincing and selling the idea uh they are looking for answer only rather than a particular thing yeah and uh about uh to your next question that what you don't like about scrum you may need to share what you think about it yeah yeah so the only thing i actually i like this the way that the teams work more collab collaboratively and all the only thing in my view my personal view what i don't like in scrum is what i feel still challenging in scrum is though we are a team though we say like we have to work collaboratively we all we all have the same objective ultimately we all as a team have to achieve that and all how much we how much ever we encourage the team or how much ever we work as a team at the end of the week all our individual people we all have our own careers and in a team if there are five developers if my every time if my goal is reaching i cannot when it comes to a promotion general term i'm generally i'm talking about when it comes to a promotion kind of thing i cannot promote all my five developers right there will be definitely i will pick only one or two people who are extremely performing welcome in between those five people and i will be able to promote and i'll be able to appreciation actually uh that happens in general we are not able to change that in the current organizational scenario but uh actually what i have seen is like though we are encouraging the people because of that the inbuilt competition or whatever is there inside uh always i could see the challenge always uh the conflict the that that we i always that plays a major role in creating the conflicts among the team members that's what i really i don't know what to do in that scenario because it's all individuals career that's a thing which i don't like i don't know whether i say i don't like it or not but i see definitely a challenge over there yeah i think it has less to do with scrum so scrum has nothing to do because it's more about the type of environment we have in our organization the type of people we select and all those things now agile uh you know build people around self-motivated individuals so and then give them space and work and they will do wonder so that's kind of one of the principle which is i would say that's a one of the assumptions you know when we apply scrum but many times that assumption is not true people are not self-organized people are are not self-motivated and they they are they have they have their own interest and there is a competition yeah so in building their individual nature and in some cultures it's more in some cultures is less in some organization it is more because the way organization looks at it so that's a reality and and that reality may put some challenges related to how do we facilitate various scrum events how much percentage of self-organizing can come and what intervention will be always needed from the leadership because of of the the culture or the the type of environment we have which has some imbibes of computation yeah yeah so i said you need to argument your scrum there is no uh uh thing that yeah you need to add your things and then find out how do you deal with it yeah if somebody asks you this question saket what will you answer like something that you don't like instagram my view is i i won't say that i don't like but i see the way scrum get perceived and and especially with the product owner role so i i feel a little uncomfortable with the product owner role and the way uh the boundaries scrum master product owner and and kind of things uh it is it is more about the way it is perceived than it is uh really written so considering one product owner many times as an external guy doesn't make much much use yeah that's the one thing the another dysfunction i see is considering product owner can make all the decisions and we rely on product owner for for all the requirement related stuff the way it gets perceived is also little risky thing so i see usually the product owner is not alone he's working with these stakeholders and many of the stakeholders are very key contributor in the in the product development you know there will be few individuals who might be doing a lot of research related to the product so not recognizing them and they are not part of your development or a scrum team they are contributor so not having a kind of a way of working with them is sometime put a risk that scrum team may neglect that but again scrum tells that do an inspect and adapt do your retrospective and if you see that you need to recognize some individuals and have their clarity on what they will do with our scrum team identify that it's a retrospective thing but many times since it is not clearly spoken uh the teams may end up missing that so i would say that product management space product requirement elicitation space and working with the business that part is not well understood or well defined in scrum and maybe as a team we need to work in that space so that much i would put there yeah okay okay yeah good yeah good place to conclude our conversation then yeah yes okay thanks a lot thank you so much you're welcome and do these things and in case you get some follow-up things and based on some other intro experience we can have another set of conversation again there is no right and wrong answers it is all depends upon who is listening to you and also how you are presenting and there could be a multiple ways of presenting same information or there could be a different way of solving the same problem as well so adapt yeah don't just go with the one path and we'll discuss if it requires yeah sure circuit that really helps thanks a lot thank you so much for your idea thank you bye [Music] you

Channel: iZenBridge Consultancy Pvt Ltd

Views: 53,623

Rating: 4.8773236 out of 5

Keywords: scrummaster, scruminterviewquestion, scrummethodology, agile, projectmanagement, interviewquestionscrum, scruminterview, projectmanagment, sprintinscrum, sprint, velocity, sprintplanningmeeting

Id: DBm7orWSGFw

Length: 51min 11sec (3071 seconds)

Published: Mon Nov 16 2020