 I guess, am I audible? There is no need to find. OK, good morning, everyone. My name is Pooja Vandele. I am from persistence systems, Pune. And my topic is to look at the challenges that the scrum masters face in their day to day life. How many of you are actually scrum masters? I have been in the role of scrum masters. OK, so I guess my story is probably not going to be very different than what your story is. So maybe it's a collective experience. Let's collect what I have seen in my role of a scrum master and gradually growing up into a agile coach and seeing other scrum masters doing the things which I was as a scrum master doing. But now as a coach, my role is changing, right? My head changes. And so it's about a collection of an experience over the last five years, I would say. Many of these things are very common. I and you have been facing every day. And maybe some of the things we have tried in our company might just work in your thing or something that you have tried might work for others as well. So it's just more of an interaction, I would say. I know scrum master experience cannot be covered in 15, 20 minutes. It's just a 20-minute session. So I would like to share as much as I know. And at the same time, we all should be learning from each other's experience. Is that fine? OK, good. OK, so whenever you take up a job, whenever you take up a role as a scrum master or a project manager, the first thing that you are told by your project manager or by your senior management is exceed customer satisfaction, right? But am I audible? OK, fine, OK, fine, no problem. OK, so the first KRE that is given to any scrum master is to exceed customer satisfaction. It doesn't matter whether you follow agile, non-agile. But the first thing is that you have to exceed customer satisfaction. Come whatever is needed to get that done, right? And agile is the in thing. Not just now it is, but it has been there for some time now, right? And what we have seen or what I have seen, yeah, everybody starts with a lot of enthusiasm. Everybody talks about a lot of things about agile. Everybody talks about agile values, agile principles. All these things are very fine when the project is new, when the enthusiasm is new. Everything is going very fine in the initial days. And as you start working on the projects, as you start working on the sprints, everything takes a back stage, right? Everything goes into dustbin, in fact, I would say. That's what I, in fact, I have seen. We have seen it's just the velocity, velocity defects, all that gets counted. Nobody talks about values. Nobody talks about agile. Well, everyone has actually forgotten about agile values and principles, right? We say that working software is the primary major of the progress. But as everybody clearly cares about, everybody is looking at the defects. Everybody is looking at the effort utilization. That's where the management is interested in. Am I utilizing my resources effectively? That's where even the customer is also interested. I'm paying so much money. And this is more from an offshore perspective, I'm saying, more from our service industry, where you are providing services to the customer. So the customer is also interested in knowing, I'm paying per dollar. Per dollar rate is there, ATAS is what I'm paying. Am I getting the output that I have? So all these other things actually starts taking more importance than what the agile, the reason why you chose to use agile. That actually takes back what we have seen, right? So, and look at the scrum masters. Look at the state of the scrum master. Now, from a classical thing, it is said that the scrum master is a servant leader, right? But do you really believe a scrum master just remains a servant leader? No, right? Actually, that person gets sandwiched between many things. There is a team, right? The team has certain expectations from the scrum master. There is management. Management has certain expectations from the scrum master. And there is a customer also, right? So actually, even if you are a servant leader, but do you really have those kind of support that you need to make that agile team really work, right? And we saw that there are so many challenges that the scrum master faces. You don't, especially from an Indian context, you see the kind of pyramid. You know, we say there should not be any hierarchy in an agile project. But does that really happen? At least we haven't seen in our company. We still have hierarchy in an agile team. We have, in fact, 50% of the team is composed of junior resources. Precious with one or two years of experience. A very couple of guys who have probably five to seven years of experience, maybe one. If you are lucky, you might get one of the person who is 10 plus years of experience. But typically you have to work with a lot of resources, a lot of people who are juniors, who are precious. And do you really think they are, you know, we talk about so many things. Self-organizing teams, self-managed team, taking, being able to take your own decisions. Does that really work with these juniors and not necessarily all the time? So what we have seen is that, on one side, the customer says that we want to go agile. You should understand what agile works, how it works, what agile means. But actually, does it really happen in real life? It doesn't really work. At the end of the day, everybody is interested how much has been delivered, you know? It doesn't really matter whether you have a fresher, whether you have somebody who is a couple of years of experience, whether that person is really capable enough to take decisions, especially on the design side. At least practically what we have seen that, it's really difficult to tell that person, to tell that team member to really take on those design decisions. It's always determined by somebody else, you know? So where is the self-organization, self-empowered teams? I have seen this empowered teams. This empowered is pretty much, you know, it's just in the books. At least on ground, I don't know where does that empowerment goes. But we have seen, on one side, the customer says, now we are working in agile, you should take your own decisions. Why should you wait on us? Why should you wait on our approval? You just take decisions and move on. And when you take actually the decisions and it doesn't work, then he will say, why you did not check with us? Now why you took such an important decision, you did not even bother to check with us, right? So you are actually on both the sides. So what do you do? These are very practical problems that you face. And then after looking at so many projects, so many problems that we, let's sit back and let's look at all the problems that our scrum masters are facing. And then we thought that many of these challenges are very common across many projects. And then that was the time we said that, no, it's very important. It's not just for the scrum teams, it's not just for the scrum master to understand the agile values and principles. It is for everyone. It is for the team members to understand it from the heart, in fact. You have to be passionate, you have to be committed, all these things are very fine. But do you really understand what each of these things means? Believe me, you have to go back to your basics. You have to understand, you have to know these principles are definitely needed. These principles are the foundation for building a great team. And if you have a great team, obviously there are high chances that you will break, we'll get great product as well. So we went back to the drawing board and we saw, okay, let's look at all these challenges and we thought that, okay. Basically we have left behind these agile principles in a long time back. Now they just does not exist in your day to day life. So it is important for the management, for the customer, for the scrum master as well. Not all scrum masters are necessarily well educated also on the scrum principles. Many of these scrum masters are just project managers who have naturally moved into the scrum master role. They still carry the baggage of project management and they don't understand. They are not able to motivate the team members. And we said, no, we have to know. Training awareness is fine. But making this organization, this management aware of all these things, time and again is very, very important. So that's where we went back to our basics and we saw, we have to learn some of the things and go back to the basics and look at these principles with a new view. So what we thought that everybody, everyone is aware of these values and principles. I'm not going to cover those things in details. But believe me, each and every principle of this is absolutely necessary and they do add value if you keep these things in mind. I understand in your day to day life it may not be possible, but these are very, very important. And when we bucketed these challenges into various agile principles, there were many. In fact, but these are the top three agile principles where we thought that we are actually lacking and we need to understand and adopt these principles in a better manner. So trust, we listen to Todd's talk, right? Trust and ownership. So trust is the foremost important thing and we found that on one side while the customer, while the customer or the management is saying that, you can take your own decisions, but in many cases actually we saw that many of these decisions or some of the things that should be done by the team are actually done by the customer. Somebody, some representative from the customer says, okay, who should do what? A very micro management thing. So where is the self-organizing self, self-managed team is? It's very difficult for a scrum master in that scenario to tell no boss, you are the people who can't take decisions, you are the people who have to make decisions, this doesn't work when you have a customer who actually dictates the amount of data that is there. He in fact can choose and pick, okay, this person works on this. It has become so human centric, you so person centric that this team collaboration actually does not exist. And these are the things actually we have seen. So it's pretty much micro management by customer. So this is all fine, you do this, you do that, but at the end of the day you check with me. So this is very, very common. So then on one side you are telling all these good things about agile to your team members as a scrum master and on the other side, these are the things that your customer is telling or even your management is telling, the team gets confused. They don't know what I'm supposed to do. And let's just look at a typical scrum, that team members, he said, no boss, let's, it's enough, I will do whatever is told to me. That's the safest option, right? Because if I do something and if that doesn't work, maybe somebody will scream at me, even my manager, not a scrum master, there are still managers that exist, right? My manager will say, why did you do all these things? Why you did not check before? And if I do them, so you are actually confused as a team member as scrum master also. So these are the harsh realities that still exist. These principles are very good in terms of book, when it comes to book, but when it comes to implementation, these are very difficult things to get done. So micro management, my customer, then customer changing priorities every now and then, which in fact many times results into fatigue and burnout. You spend hours, you are in the office until 11 o'clock until 12 o'clock, you raise the bill at 12 o'clock, send it for testing and all those things. Why? Because there are constant changing priorities, which are actually beyond your control. And all this obviously results into poor quality and many times into attrition also. This is, no, agile is just a cover approach. You just get this, do it and work out it, but it doesn't, where is the discipline? We say that agile is a very disciplined approach, but does it really work in all the situations? No, it is still, not that scrum, but I, just following a daily stand up meeting or having a two week sprint or iteration, does that mean that you have followed agile or scrum in true speed? That doesn't. We say, okay, I have a daily stand up meeting, hence I follow agile. That's a very common thing you can see. I do retrospections, but the principles, the foundation, the values are actually completely lost. So there were many challenges. In fact, these are not all the challenges that I have listed are, there are many challenges. So what we said that it's enough. The scrum muster has to be assertive. That person has to stand up. That person has to stand up for the team. That person has to stand up for the management, for the customer and remind these people again and again. Look, this is the team. Let the team work on it. Let them do. It's fine. They will fail. They will take the risk, but that is fine. But that's how it works. That is how agile works, right? You cannot micromanage them. You cannot question them all the time. Let them take decisions. Maybe sometimes they are right. Sometimes they are wrong. But that's how it works. If it is okay, then only go ahead and adopt it. Otherwise just let's fall back on their original way of doing things. Let's not say agile because then you're confusing people. On one side you say agile, do all these things. On the other side you are doing all the things which are micromanaged. Let's not do all these things, right? So the scrum master here plays a very important role. Either you do this way or we are not doing it. We are doing just the way we have been doing before. So that is one of the things. Expectations with the customer. So these are some of the things that you can do. So it's not just the setting up the expectations with the customer, but setting up the expectations with the team also. When you have team members, you have to tell them, look, you are working in an environment where you have to take your control, you know? You don't, you cannot afford to wait on somebody to tell you, okay, this is what you have to do. That's not going to work. You have to take the control. You have to move on. You say, okay, my work is done. I don't have anything else. That's not going to work. Cross visits, I think that's everybody accepts, right? Cross visits, there is no substitute for this. We have seen this, you know, having people coming, you know, to onsite or sending people to offshore. This really definitely goes a long way in building the trust. It makes a lot of difference when you have people talking face to face as against over a video or audio, in fact, you know? So it includes some bit of cost, but I think this cost is good enough in the long run, you know, it pays off in the long run. So cross visits is definitely one of the things that definitely work for us. The other thing was the attempt to quality technical excellence. You know, it's very difficult. You know, getting good people, having good technical knowledge, and you know, right, the technology changes so fast. We have big data, we have Hadoop, we have force, and it's very difficult to get people, you know? That's the reality, right? You don't get people who have good experience on these technologies and being able to develop those systems, right? So how do you make things work? So in most of the cases, what happens? You get a project, which is probably on Hadoop technology. You don't have any resources on Hadoop. What will you do? You just get, you know, whoever are available in the organization, who are great, you know, who you believe are good people, just, you know, take those, even if they are available. You know, really good people are never available. So they will never be on food, okay? So they will never be on the bench. That is very rare to happen, but let's assume that you still manage to get some people who you believe will be able to work on the technology. Many a times you just go and bid for the project, telling the customer, we have the, you know, we have the skills, we will be able to do, but what, just imagine the team, you know, they have never worked on Hadoop, and you tell them to work on Hadoop. They have no ABC office, but because there is a project, you have a, there is a customer. You just want to get on this, you know. Where is the time you have accommodated for training them, right? It's fine, you know, technology is going to change. You have to upgrade yourself. You cannot say, I will remain a Java developer forever, or I will remain a .NET developer forever. You have to learn the new things, but where do you account for the training? You know, you have to account for the training. How do you get that? Customer is not going to pay for the training. He is not going to give you the time also for the training. So you have to, you know, accommodate these things. The challenge is mostly software design. You know, you say in Agile's evolutionary design, but believe me, again for a team where you have so many junior resources, telling that the design is going to evolve, it's going to change, it's very difficult for them to, you know, digest. They just, it's just not possible. Many a times, in fact, I'm not saying all the time, but many a times it's just not possible for them. You give new requirement, the design changes, and sometimes it's just too much irritating or too much frustrating for the team also. Now what is this? This is a new requirement. Whatever designing I had done, I have to scrap that, or I have to rework on that. And again, a good amount of time is wasted. And this keeps on adding up pressure on the project developers, because the project developers generally does not change, right? The schedule does not change. So how do you accommodate that? Do you really get resources who understand what agile designing means? I have not seen, at least in our company, who have understood what agile design means and how it should be done. It's just that you get requirements, you design it for the timing. It's all about for the timing, you know? Though it's very easy to say that in agile, we don't do upfront planning, we don't do too much of, you know, future-looking things, but at some point of time, what about all these issues, right? These are the issues that you have to take into consideration where you are in the system, right? So that is where we have seen a lot of problems, technical debt, and all these results into high technical debt. So what we did, two things that definitely have been, two things that are working actually for us is the innovation day concept. So what we have done twice in a year, we have this innovation day. We call it the Rajnikan day. You know, Rajnikan is famous, right? For doing impossible things. So here is a chance for the teams to work on the cool ideas that they always wanted to work, but never got a chance, you know, as they were working on the projects, and they really, you know, fantastic, fabulous ideas have been presented by this bunch of people. Believe me, even these Frasiers, these junior people, they have a lot of skills, abilities. In fact, I always prefer them as against, you know, very experienced resource, because they just know how to give directions. They are never hardcore testers, right? Or even coders also. So Rajnikan day or innovation day has something that has really worked for us, and the second is the technology forums, the chapters. So we have set up chapters for all the specific technologies. So it's a time for people to get together and share their experiences, share their problems, and many times it has helped. So these are the two things that I definitely will recommend that has worked for us, and the third is the embrace change. You know, change. Being able to, you know, adopt changes is something I believe has been actually misused. Under the pretext of change, customer keeps on sending changes, and I know this is important. This has to go into this print. You know, my customer is waiting and all this stuff. Scrum bookstiles, no, you cannot have in-sprint changes. It has to wait for the next printer, but in reality, believe me, it does not work. If you have a one-week delivery, or if you have a couple of weeks delivery production, you just have to accommodate these changes, right? And that is where, again, quality suffers, burnout, frustration, everything, you know, that these are very common things for us. Just think about for a scrum master and for that team, you know, it's very easy for management. I'm not saying very easy, but maybe it is okay for that management to say, no, this has to get done, but just look at the team who is burning out. They are the ones who are getting it done, right? So, yeah, change is even inevitable, but how do you handle it is extremely important. We said we did put a very strict no-no guidelines, you know, change has to wait. However important, you know, and sometimes we were successful, sometimes we are not, but this is the message that we have given to the teams and the scrum masters, and we also educate the customer when we get them onboarded. That is one thing. And other things, you know, customer quality and all those things. Strict no ongoing pre-printing, this has definitely helped. You know, I think many of the companies actually now who does, I think this is very, very important. This helps you to reduce a lot of change requests that otherwise would have come, you know. You have to have a sprint backlog, which is two weeks spent, you know, at least two weeks spent, which will be there. And impact analysis, whether this is really needed. Sometimes it could be just a wish list or just to fill the gap. Sometimes we have also seen some of the customers who doesn't actually have requirements. They don't have product backlog. Just to keep the team busy, they keep on giving you something. So this is another thing, right? So yeah, a lot of things, you know, but, you know, retrospection is something that I believe definitely works, and that is what you have to do. Change in mindset is definitely important. Automation is important that we all know. CI CD is something that we are trying very hard to get on to this. So yeah, so to conclude, I would say it's very, you know, agile principles are really very simple, very straightforward, but the real challenge lies in putting this into practice. You know, we just forget in day-to-day life. And I think that is where the scrum masters have to play a big role. You have to keep on reminding about these things to your team members, to your management, and customer both. Look, you have to handle all these three stakeholders. And that is where if you do a good job, I think a lot of problems would be taken care of. Okay, so that's what I would like to, commitment, courage, innovative thinking. I think these are the things which are extremely important. That's where I would like to, I know it's very, just 20 minutes, very fast, but maybe we can always talk about more of it. Any questions you have? Can you elaborate, please? Sorry, can you please come on here? Impact analysis on the, yeah. So what do you say that when you get a change? So we have in many projects, right? A committee, steering, again, it's come from a PMO kind of, but we have a set of people who actually evaluate whether this change is really needed and this all happens in the pre-planning session. So you really have to see whether this is needed or not, or can it wait. So look at the change, look at the impact on the technical side, on the business. First of all, look at the form of business side. Does the business really need this change or not? Or is it really that critical that it cannot wait? And then you look at the technical side of it. Yeah. Yeah, so as I said, change was something that was bothering us very well. So we started monitoring the usability stability index. So how many change requests were originally decided at the start of sprint planning and how many we deleted or removed during the sprint, how many got added, and having a velocity, sorry, a index of 100% means there were no changes. The moment it goes beyond 100%, that means there is a fluctuation, there is still a volatility and you want to control that. A group, a group of people where business analyst, the business architects, they are majorly the stakeholders. So first of all, the business analyst has to explain why this business requirement is important. So we start the impact on it from a business perspective. Whether the business, this business workflow is actually this particular requirement is really needed or not. Yeah, yeah, yeah. In fact, believe me, there have been so many, one of the, it says that simplicity of art, right? Remove unwanted things. In fact, we have seen, if there were 10 things which were proposed, eight things definitely can wait. They are kind of in that category. So we just concentrated on the things which are needed now, which are going to be required now, okay? I think that's all we have. Maybe we can always talk offline. Thanks very much for your patience listening and have a nice day. Okay.