Jayanthi Ganesan

Hi, my name is Jayanthi Ganesan. I have completed my Master in Computer Applications. I do have six years in the field of education and training and ten years plus in IT. I have been following Agile methodology for almost past eight years. I have my Professional Scrum Master Certification 1. I am interested to be a coach, facilitator, team collaborator and I want to have an environment where the team learns continuously and build great features for the program. In Agile methodology, I have seen different methodologies like SAFE, Kanban, Scrum. In Scrum, I really like the way because we do small changes and then reiterate so that we fail fast and retrieve it from that failure as a success in the next iteration. Agile methodologies are really great to work. I also have worked in waterfall model in almost like 20 years back. So, I really like the Agile methodology and I want to continue to learn more on that as a Scrum Master.

If the current scrum ceremonies are unhelpful, I would ask the team in which way I can make it more helpful. The first thing is sprint planning, in sprint planning make sure you come to the sprint planning with at least having a 10 percentage of knowledge about what is the features we are going to develop, what are the user stories are there. So I would suggest to have a backlog refinement in the scrum, so that the first planning it's the team should not feel like it's unhelpful. The next step is daily scrum, of course it's really hard within 15 minutes you have to explain like what you did and what are the problems. But first thing I will make sure the team are in sync with the timings, because we do not want to leave any team members, so I will talk to the team, so that what is the location and what is the time best suitable for them. The next is review, which is really really very important thing for testing. Next one is retrospective, I feel like retrospective feel you if you are not taking any changes, if you are not doing anything action items from the retrospective, then it feels like it is unhelpful. But I will make sure the action items are taken in the next iteration, so in that case we can make the team to believe that the scrum is helpful. Other scenarios like I would suggest like if it is really necessary to have like other agile methodologies like HANBAN or LEAN or other methodologies, I will be telling them and I would ask the team if they want to switch to the next type of methodologies. Anyway, I will give all the suggestions and I will ask the team to work on it and check which methodologies they want to follow and but I want to make sure that ceremonies are important, it is not that you cannot just leave the ceremonies unhelpful, the ceremonies are important but how you are going to make it helpful is more important.

To prioritize user stories, the product owner is the one and only person who can prioritize and I would suggest the product owner should know the value of the user story. So you have different methodologies like Moscow, which is like must have, should have, can have, won't have. So with this terminologies, each and every story can be prioritized like, okay, what are the must have, which means that mandatory and what are the other things like should have, could have and last one is won't have, this make sure that what are the user stories that comes at the bubble up and what are the students that comes bubble down. So that's one methodology. The second one is have a matrix saying that what are the high value, high risk, high value, low risk, low value, high risk and low value, low risk. As we know that low value, low risk will be at the last, but high value, low risk will be at the top because it gives lots of value, but the risk is very less. So that will be at the top. So in that way, we can prioritize. These are some of the methodologies we can follow in the scrum. Product owner is the person who really wants to analyze what are the challenges of the customer. So from the team point of view, product owner should be considered as a customer and his way of prioritizing is the final call. But before this prioritizing, as a scrum master, I would give lots of input as same like I will be giving lots of methodologies. So what is the return of investment of this particular user story or the feature or the epic? So those information I will be giving to the product owner so that the product owner can ensure which story should be at the top prioritized and which stories, in the same way it is very also important that which stories should not be there in the sprint. So it is not possible to have two stories at the same, like you cannot say that, okay, I want priority number one, priority number two, priority number three. You cannot have like priority number one, having like two tasks as like, oh, these two are same priority. It is not possible. So make sure that if it is high, then make sure that is really, really high. And in the same way, if it is low, just do not hesitate to throw the user story at the bottom of the list. We are not going to delete it, but just put it at the bottom of the list. So give lots of suggestion and as a product owner, he has, he is a decision maker for prioritizing the user stories.

Daily stand-up meetings are really really very cool way how you can collaborate with the team. I will say like lots of formal methodologies, how you can effectively facilitate and informal things which you can effectively facilitate. Let us go with the formal techniques, very very formal techniques if you have like 10 members and they are very very matured enough about the team then it is very easy you can say like okay what is done yesterday, what I am going to do it today. For doing this task today what are the hurdles I am having or what are the hurdles I am foreseeing. So these three questions can be answered by each team member. So when it is a very collaborative event then it is very easy that each and every team member can go in that round robin method and then get you can part you can part like some of the things which you have to talk about the task or the user story at the at the last of the session. So it is very easy if it is a matured one. If it is going to be in a middle way like a team is collaborating actually there will be a storming session because the team is trying to collaborate, they do not know each other very well but they want to understand much better. So in that case I will be adding some kind of things like you know if they are in the team environment you can say that okay for first one minute we are going to do some kind of like exercise. Very simple thing is like you have to stand near the wall like facing totally facing the wall. So in that case you have just one minute like a kind of exercise that they can have fun and then they can come to the stand up and then start telling about their stories. This makes like the enjoyable moment. The last one is very very informal. You can say like okay you call you once you complete your your daily call another person. It makes like the team should be very very attentive. Other than this there are lots of informal methods like okay tell me a dish which you like, tell me a fruit which you like and then start telling about the user stories. When they are having some issues make sure that the complete the you have to give a time out if a person is going too much and say that okay park it and then you can talk it later. So that's one effective technique. I usually say like time out and we can stop there and then move on with the other things. Make sure the junior team members are speaking up. No team member should leave the daily stand up without telling anything because it's very important that each and every team member should have their voice in the daily stand up. But that can be carried out by the team member to or the scrum as for the product owner to the next level. But daily stand up is the place where the person who are attending should raise their voice, speak up their mind and tell what are the problems they are having or tell like what are the solutions they have. So these are some of the basic thing is the communication, the communication do all kind of communications tricks to make sure everyone talks in the daily stand up.

Yeah, the team if they are not delivering as per the sprint commitment, in the retrospective, it's a right time to talk about it. First thing is check the velocity and say that why this velocity is not delivered. Each and every person should be given like, it's not like if one person even fails the sprint, it's not that just that person is failing, it's a team itself is failing. That kind of commitment should be there. We are not going to say that if a particular user story is not done, it's not that just the person who is assigned to that is to be blameable, it's a whole team is blameable because if the other team members have completed, they should be right away jump in and help that particular user story or the teammate who is struggling with that user story and try to complete it. So make sure the team is collaborative. If the if if they are not delivering, it's not just a single person perspective, or a particular group of team members, it's a whole team. In that way, make sure the team is committed. And the next thing is, we want to just say or check what are what are the planning mistakes we did. In the sprint planning, we decided that this is the commitment, but at the review, we know that we have not delivered. So in the retrospective, we should start with, okay, in the planning, what are the things we missed? What are the things would be better if we know these information? And in that way, we can talk or we should not have spent more time or we have not failed. So these things we have to talk. And in the middle, what are the changes that happen that makes this sprint not deliverable. So those changes has to be taken care. With this in the retrospective, make sure is the velocity correct? Or the changes in the middle of the sprint is taken care? The planning has all the information, do the action items like, okay, for in the planning, we missed this. So add that. And in the same way, we have to make sure that definition of ready, definition of done, acceptance criteria, all these has to be checked. Are we doing it correctly? So these are the things that has to be done. So that in the next sprint, the team will be more committed and then delivering good. First thing is we have to encourage the team because they have given their 100% but still they cannot complete. So first thing is you have to encourage the team. Yeah, you did good in the sprint, but what makes the failure? Those are the things we have to make sure it does not happen again.

A change in the workflow to improve team efficiency, a change, it's really hard, even a person who is doing a scrum, they want to move on to another framework like Kanban or very traditional waterfall model they are following, now you have to come to say that, hey, we are going to use scrum methodology. So you'll take a first scenario like there is a traditional waterfall model, like you get to know the feedback only like six months after it has been deployed and then you get the feedback from the customer. Now we have to move on to the scrum. The first thing is, prepare the team's mindset that we are going to do better, we are going for the betterment of the organization, betterment of the employees and betterment of the productivity. When we are starting the scrum, we should train them what is agile and just give a 30 minute session of what is agile, how it can, what are the additional benefits of scrum, benefits of agile methodologies in general, so that the team should be also looking forward for that change, not like, oh, that is something new, then how the team has to arrange that. I think the first step is the training, like 30 minutes of training of giving explanation of what are the benefits, what are the problems the previous thing has and what are the current benefits you can get. The next thing is the implementation of the process, it's not just when you communicate, but the action items are necessary. So we will say like, okay, we are going to start the sprint by next month, the next month is going to be the start of the sprint. And with that, we are going to have like, at least like two weeks sprint, we'll try with two weeks sprint and then we will start with the changes if we needed. And the tools necessary for the sprint, like JIRA or Trello, any tools, even if you, if the company is not having those tools, Excel sheet, like, what are the tools are available, so that tools has to be given to the teams, so that they are aware of those tools. And at the end, the measurement is very important, like, you have to be saying the team like, this is the way we are going to measure the quality and the quantity, so that the team will be focusing and they will be driving through that particular process. And after the implementation, we should say like, hey, we did this great, great job. So those kind of encouragement should be also given to the team.

There are different methods of measurement of success, first a very, very basic thing is like if a team is giving 100% of its velocity, it means that yeah, it is a great success for the agile principle that is adopted because if a team is telling that hey, my velocity is 60 story points and they are going to deliver 60 story points and more, 100 or like more than that, like 150, like they can pull up stories in the middle and then they can deliver, that is the great way of measuring the success, it is not just in one sprint, you have to get the series of sprint like at least a quarter, you have like at least 4 or 5, 4 to if it is going to be a single week, it will be like 4, 16 data you have or you have like one month sprint, you have 4 data to check, each and every sprint they are having, they are delivering good, then that is the better method to say like it is a success. And the next methodology is in some of the sprints, you have like IP sprints where they learn and then they do other sprint. In some sprints, there is necessity that some of the team members may have to work with junior members and give their time so that they learn from, they, they, the junior members has to learn from the seniors, so the time has been allocated for them, but that sprint they may have a little less, but the next sprint with the junior member also the sprint velocity will be high, so that can be also considered because in a 16 data, you cannot just take just one data, which is very less, you have to get an average or a mean of this data and then check like okay, is the team is doing good. And the last part is it is not only quality, quality, but also quality as well as quantity, sometimes the sprint does not deliver any product, but they have story points, which is related to the technical depth of that particular product, so that is also should be considered, it is not only the customer point of view, but also from the technical depth from the development point of view, that should be also taken into consideration.

One particular time, what happened is the wireframes are there and the team was story pointing with the wireframes like okay, there will be a login page and the basic thing is you are going to add some terms and conditions, the checkbox and we were like working on that user story. It was in the refinement, it was in the backlog refinement and it comes in the planning and then it comes back to the sprint but by that time, we realized the page, the login page itself is not yet deployed. In that case, there is no way that we are going to add terms and conditions in that page. So, this basic principle of definition of ready is not there because when we are doing the refinement, backlog refinement and then we are doing the planning, we did not check that the pre-request of like in the invest method, the value is there but the pre-request of at least the basic requirement is there, that we did not check. So, after this, I told as a team, we decided that before even taking that to the planning not in the refinement, we cannot catch these things but in the planning, we want to make sure that open up a demo of a QA site or a UAT site or even the product production site and check is what is there and with that, you can add the terms and condition. So, even if the page itself is not there, then it is not possible to add terms and condition, right. So, it is basically we wasted the time, we pick it up into the scrum and then we have to get it back to the backlog because the pre-request is not there. So, we make sure definition of ready has to be changed, make sure the pre-request page is available for this particular user story. So, that make sure that we are not wasting more time when it comes to the planning and then making the developers to overthink about that and then saying that it is not there and then come back. So, I think this is the lesson we learnt.

When prioritizing the backlog, product backlog, for sure, there will be lots of conflicts because as a stakeholders, they would have like three or four important prioritized information. So, from the product owner, I would be expecting, okay, these are the four things which you want to do. Let us work on return on investment for this feature one, what is the return of investment? So I will be categorizing with that cost because stakeholders, we know they have very much in-depth idea about the value, but from the team member, I would ask the team lead to come and check like what will be the time frame for completing this feature one, completing the feature two, feature three, and the feature four. So the time and the cost, these two has to be taken as a data, okay, what will be the time and what will be the cost of return for that. So with this data, we can make sure like whichever is having less time, but cost, the return of investment is more. In that case, we can take that as the first priority because this is a win-win situation for both stakeholders as well as the team, the stakeholders will be happy if they have like the cost is good, in the team members would be good if they are very confident about like, okay, within this time frame, we can complete that particular feature. So in that way, I would suggest like product owner, as well as the team lead has to talk and with data, we can for sure handle the conflicts. It's not just the conflicts can be just start with communication and work on those things, it's not going to help, data, facts, and what are the artifacts from the previous sprint, we have to check like what are the information we have and with those data, we can handle the conflicts.

Burn down charts, burn up charts, velocity, you can check like how this graphs are going in the way, because in the middle of the sprint check your burn down chart, is it in a right way, or there is an kind of fluctuation, some of the stories are completed at the end or we are moving stories from one sprint to another sprint, so this can be taken care by this burn down chart, so this will be having a very good monitoring of how the team is achieving and after a particular quarter, we can find all the velocities from different sprint and make sure like is the cost what you have spent on this particular velocities are correct, the budgeting like it will be easy with all these data, we can budget for the next quarter.

Scrum scaling frameworks is very, very necessary because when the team grows, it is not necessary that you should have almost like 30 people in the same team, it's not the right way of Scrum. So we should make like six to nine team members in one particular Scrum team and split it to other team like at least six teams, since I told you like almost like 30 means you can just make sure that each and every Scrum has like three to nine members so that you will get like at least seven teams. Also make sure there is a Scrum of Scrums available, Scrum of Scrums are nothing but the Scrum masters from each team, product owners and the team leads of that particular teams can communicate with each other about their team success, team problems and team dependencies that can be done in the Scrum of Scrums. Basically you can have like at least 30 minutes call every sprint so that it should not be like daily but it can be like Scrum to sprint to sprint so that the team will scale and they know who to approach. If a team member has a problem, he or she can tell it to the team lead or the Scrum master and this will be moving on to the next level in the Scrum of Scrum and then the Scrum master should talk to other team Scrum masters or the product owners of them, they can decide if it is necessary to do those changes and from there it will be moved to the next other teams. So, it is a very very easy as well as very very committed team can be it is it is a kind of like a matured Scrum framework, the teams should be very much measured to ask what they need and communicate like what are the problems they have.