Jayanthi Ganesan

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

If the current scrum ceremonies are unhelpful, I would ask the team in which way I can make them more helpful. The first thing is sprint planning. In sprint planning, make sure you come to the sprint planning with at least 10% knowledge about the features you are going to develop, and the user stories that are there. I would suggest having a backlog refinement in the scrum, so that the first planning doesn't feel unhelpful to the team. The next step is the daily scrum. It's really hard to explain within 15 minutes what you did and what the problems were. First, I would make sure the team is in sync with the timings, so we don't leave any team members behind. I will talk to the team to find the best location and time that suits them. The next one is the review, which is really very important for testing. The next one is the retrospective. I feel that the retrospective feels useless if you're not taking any changes or action items from it. But I will make sure the action items are taken in the next iteration, so the team believes the scrum is helpful. Other scenarios, I would suggest like if it's really necessary to have other agile methodologies like HANBAN or LEAN, I will tell them and ask the team if they want to switch to the next type of methodology. Anyway, I will give all the suggestions and ask the team to work on it and see which methodologies they want to follow. But I want to make sure that ceremonies are important; it's not that you can just leave the ceremonies unhelpful. The ceremonies are important, but how you make them 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 these 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 makes sure that what are the user stories that come up at the top and what are the stories that come down. So that's one methodology. The second one is having 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 Scrum. The product owner is the person who really wants to analyze what are the challenges of the customer. So from the team's point of view, the 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, such as the return on investment of this particular user story or the feature or the epic. So that 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 important that which stories should not be there in the sprint. So it is not possible to have two stories at the same priority, like you cannot say that, okay, I want priority number one, priority number two, priority number three. You cannot have like priority number one, with two tasks as like, oh, these two are the same priority. It is not possible. So make sure that if it is high, then make sure it is really high. And in the same way, if it is low, just do not hesitate to put 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 suggestions and as a product owner, he has, he is a decision maker for prioritizing the user stories.

Daily stand-up meetings are really cool ways to collaborate with the team. I will say that, like, lots of formal methodologies can help you effectively facilitate and informal discussions. Let's go with the formal techniques. If you have, like, 10 members and they are very mature, it's very easy. You can say, "What was done yesterday?" "What will I do today?" "For this task today, what are the hurdles I'm having or what are the hurdles I'm foreseeing?" So these three questions can be answered by each team member. When it's a very collaborative event, it's very easy for each and every team member to go in that round-robin method and then share their thoughts. You can also discuss some things about the task or the user story at the end of the session. It's very easy if it's a mature team. If it's going to be in a middle way, like a team that's collaborating but doesn't know each other very well, there will be a storming session. In that case, I'll add some things, like, if they're in a team environment, you can say, "Okay, for the first minute, we're going to do some kind of exercise." A very simple thing is to have them stand near the wall, facing it totally. So, in that case, they just have one minute to do something fun, and then they can come to the stand-up and start telling about their stories. This makes it an enjoyable moment. The last one is very informal. You can say, "Once you complete your daily call another person. It makes the team very attentive." Other than this, there are lots of informal methods, like, "Tell me a dish you like," "Tell me a fruit you like," and then start telling about the user stories. When they're having some issues, make sure to give a time-out if a person is going too much, and say, "Okay, park it, and we can talk about it later." That's one effective technique. I usually say, "Time-out," and we can stop there and then move on to other things. Make sure 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 has their voice in the daily stand-up. But that can be carried out by the team member or the scrum master, or the product owner, to the next level. But the daily stand-up is the place where the person attending should raise their voice, speak up their mind, and tell what are the problems they're having or tell what are the solutions they have. These are some of the basic things about communication, and all kinds of communication 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, check the velocity and say why this velocity is not delivered. Each and every person should be given the opportunity to explain, it's not just one person failing, it's a team 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 just the person assigned to it who is to blame, it's the whole team who is blameable because if other team members have completed, they should immediately jump in and help that particular user story or the teammate who is struggling with it and try to complete it. So make sure the team is collaborative. If they are not delivering, it's not just a single person's perspective or a particular group of team members, it's the whole team. In that way, make sure the team is committed. And the next thing is to check what planning mistakes we did. In the sprint planning, we decided on a commitment, but at the review, we know we have not delivered. So in the retrospective, we should start by asking, what are the things we missed in the planning? What are the things we would have known if we had this information? And in that way, we can talk about whether we should have spent more time or not failed. So these things we have to discuss. And in the middle, what changes happened that made this sprint not deliverable? So those changes have to be taken care of. With this in the retrospective, make sure the velocity is correct, or the changes in the middle of the sprint are taken care of. The planning has all the information, so we need to do 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 the definition of ready, definition of done, acceptance criteria, all these are checked. Are we doing it correctly? So these are the things that have to be done. So that in the next sprint, the team will be more committed and deliver well. First, we have to encourage the team because they have given their 100%, but still, they cannot complete. So first, we 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 do not happen again.

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

There are different methods of measurement of success. First, a 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 saying that my velocity is 60 story points and they are going to deliver 60 story points and more, 100 or more than that, like they can pull up stories in the middle and then deliver, that is the great way of measuring the success. It's not just in one sprint; you have to get a series of sprints, like at least a quarter. You have at least 4 or 5 sprints, 4 to if it is going to be a single week, it will be like 4, 16 data points you have, or you have one month sprints, you have 4 data points to check. Each and every sprint they are having, they are delivering good. Then that is the better method to say it is a success. The next methodology is in some sprints, you have IP sprints where they learn and then do other sprints. In some sprints, there is a necessity for some team members to work with junior members and give them time so that they learn from the seniors. The junior members have to learn from the seniors, so 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 16 data points, you cannot just take just one data point, which is very less. You have to get an average or a mean of this data and then check like, okay, is the team doing good. And the last part is it is not only 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 should also be considered. It is not only the customer's 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 that the wireframes were 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. We were working on that user story. It was in the refinement, in the backlog refinement, and it came into the planning, and then it came back to the sprint. By that time, we realized the login page itself was not yet deployed. In that case, there was no way we could add terms and conditions to that page. So, this basic principle of the definition of ready was not there because when we were doing the refinement, backlog refinement, and then we were doing the planning, we did not check if the pre-requisite for the investment method, the value was there, but the pre-requisite of at least the basic requirement was there, and we did not check that. So, after this, I told the team, we decided that before even taking it to the planning, not in the refinement, we cannot catch these things, but in the planning, we want to make sure that we open up a demo of a QA site or a UAT site or even the product production site and check what is there, and with that, you can add the terms and conditions. So, even if the page itself was not there, then it was not possible to add terms and conditions. So, it is basically we wasted time, picked it up into the sprint, and then we had to get it back to the backlog because the pre-requisite was not there. So, we made sure the definition of ready had to be changed, to make sure the pre-requisite page was available for this particular user story. So, that makes sure that we are not wasting more time when it comes to the planning, and then making the developers overthink about that, and then saying that it is not there, and then come back. So, I think this is the lesson we learned.

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

Burn down charts, burn up charts, velocity, you can check how these graphs are going in terms of how they're progressing, because in the middle of the sprint, you check your burn down chart, is it on the right track, or is there some kind of fluctuation? Some of the stories are completed at the end, or we're moving stories from one sprint to another sprint, so this can be taken care of 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 sprints and make sure if the cost we've spent on those particular velocities is correct. Budgeting will be easy with all this data, we can budget for the next quarter.

Scrum scaling frameworks is 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 six to nine team members in one particular Scrum team and split it to other teams like at least six teams, since I told you almost 30 means you can just make sure that each Scrum has three to nine members so that you will get 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 at least 30 minutes call every sprint so that it should not be daily but it can be 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 moved on to the next level in the Scrum of Scrum. 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 easy as well as very committed team can be, it is a kind of matured Scrum framework, the teams should be very much measured to ask what they need and communicate about what are the problems they have.