 My name is my name is Vijay and I'm from Hyderabad. I have been learning agile since last six years and I have recently been part of an agile transformation, large scale agile transformation where around 60 teams are transformed into agile. So I have contributed to around 10 teams in terms of training for two days, agile values, fundamentals and Scrum Framework, Lean and Kanban and followed by 6 to 8 sprints of coaching for those teams. So I'm going to talk about some of the observations and challenges and anti-patterns and some suggestions, best practices based on my coaching to those teams. And what is the take away of the session? Is there any take away from a 20 minute session? Okay, there is. So if you feel some of these observations are challenges found in your teams also, feel happy because they are not unique for you, they are universal problems. Or if you are planning to transform some teams to agile, this information will be helpful for you so that it can be done little better. So how many of you agree a Scrum Master is a team spirit guardian? Why? Why is a team spirit guardian? He is the one guru, he is the one friend and he is the coach, he takes care of the teams. So he works for the team to make his team great, high performance teams, right? Okay, so when I started working with these teams, what I understand was it was very natural that these teams are undergoing through the, what is that? Tuckman ladder, right? Forming, storming, norming, performing and adjoining. Where you have the forming stage, a lot of team members will have different skill sets, different mindsets, different religious backgrounds, right? But the observation what I had was we conducted for some of the teams a self-forming exercise where the team members come together, they form their own teams based on the guidelines that we give generally like, okay, this team needs three developers and two testers and they should have this background domain expertise and they should have these technical skills. So those teams, the duration of forming to performing is actually less than somebody else's form the teams based on their requirements, their demand. The reason is when you let the team choose themselves to form a team, the initial buy-in and the accountability and the commitment will be more high, right? Another point I observed is if the scrum master or the coach is, he has more agile perspective and agile knowledge and implementing the agile values and principles from the value point of view, the duration can be shortened, right? These are the five dysfunctions of the team as described by Patrick Lencioni. So the first one is absence of trust. So that means if the team members do not trust each other, they obviously cannot be honest with each other. That could lead to the next one, fear of conflict, meaning when you have no trust with each other, the decisions made by the team is not consensus based. When the decision is not consensus based, that means somebody will agree, somebody does not agree. So that will lead to the lack of commitment. So people who do not agree with the decision naturally will have less or zero commitment. So the next level of that is have avoidance of accountability. Those who did not have the buy-in to the decision made, they naturally have no, no, I did not agree. So I am not committed. I am not accountable. Somebody else is accountable. The last and most critical one is inattention to results because of all these problems it will lead to a situation where individual focus will come in rather than team-based focus. They do not trust in team-based delivery rather than they fight for the individual delivery, right? According to State of Agile 2013 report, they say that 43 percent of the Agile projects fail because of what problem? People problem, people and cultural problem. Individuals may behave well, behave well, but when you put them into a team, they do not behave well because of the ego problem or something else, right? So what is agility? Yeah, could be more. So what is the reason? It is all about, agility is all about mindset, right? It all depends on people, shared value and collaboration among those people, which is that makes Agile success. So some of these observations when I worked with those teams, the first one is tacit knowledge. Team members who have domain knowledge and technical knowledge, they do not want to share it with others because of the insecure feeling or lack of trust or if I share the knowledge, he will become more knowledgeable than me, he will take more story, something like that, right? Even though they are called themselves as Agile team, the developers feel they are a subset of the team. The testers feel they are another subset of the team. There is no collaboration happening. So what happens naturally it will lead to one of the ways is waiting or silo-based working, right? Individual focus rather than team-based focus. I want to do more work. I want to prove myself. Disconnected delivery, another pattern. What is disconnected delivery? Some of the team members, they say, okay, I am taking this story. It is my own. Don't come in between. I take care of end-to-end. What could be the problem because of that? Yes, nobody knows what is happening there. If the person is absent for two days, three days, you are gone, right? Lack of openness, transparency is one of the three legs of the empirical model. If you don't have transparency, obviously you cannot have better inspect and adapt, right? That remaining two legs will not work properly. Last one is lack of courage. Till then, before they start their agile journey, there used to be somebody like a manager or a leader or somebody else who used to guide them, who used to make decisions for them, who had to help them for their planning so everything is push-based. Now all of a sudden the moment you say, okay, now onwards you are agile. You have to self-organize. You have to plan your work. You have to do on your own. You have to live on your own. They don't like, right? Scrum Master's role is very key in making the teams great, especially when the progressing phase, when the teams are maturing, maturing stage. So you need to understand one thing. The roots must be strong and healthy. That means the agile values, principles and scrum values, focus, openness, respect, courage and commitment, they should understand or understood by the team from the value point of view rather than a practice point of view. Okay, scrum says have a daily stand-up. Scrum says have a review meeting. That is not value-based. They need to understand value-based implementation of these ceremonies, right? So some of the things that I observed is effective management of the seven ways you can use value stream mapping. For example, one time what I observed was there was a problem in one team. So team members started communicating through an email. So the email started around 11 o'clock in the morning and by the time where the issue got fixed, it was 5.45. So there were so many mail chains. What I found was I took a value stream mapping when the email started and what is the wait time when the other person responded. So I took the data and called the team. Okay, now we have to solve the problem, same problem sitting across the table. How much time it would take? This is 45 minutes. So they themselves understand, okay, that means sometimes we need to understand some things like face-to-face communication, right? Avoid or eliminate waste. Some team members they feel that if we have to deliver the stories at the end of the sprint, I need to start working on all stories starting from day one. Not really. You start value-based delivery, limit work in progress, right? Put work in progress limit. What is the problem because of that? If I start, as a team, I start working on all stories. Probably they end up reaching a stage. All stories are 80 to 90 percent complete. No story is 100 percent complete, right? Time-boxing. The moment they started working in agile, some team members came to me and say that, you know what? The moment we have started working in agile, we are spending more time in meetings rather than creating working software. Is this what is agile? No. So really making time-boxing for the teams to be successful, two things are very, very important at this stage. Inspect and adapt and effective time-boxing. These are the two important aspects that Scrum Master has to educate or let them understand. Next thing, effective retrospectives. First two to three sprints. Everybody comes on time. They participate well. They give their opinions, a lot of contribution to the meetings. But slowly, after fifth sprint or sixth sprint, you don't see attendance or people start coming late or they come with laptops, right? So this leads to a poor inspect and adapt. There is no learning happening, right? So yesterday, Madhavi was covering about some of the innovation techniques to conduct retrospectives. So as Scrum Master, what I suggest is, I started implementing different techniques of retrospectives. The team members do not know what retrospective style we are going to follow in the next retrospective meeting. So they will be, okay, we will see what is that we are going to use this time, right? So participation is more enthusiasm. They come with, especially they don't come with preparedness. What happens if you use what went well, what went wrong? Where do we improve? If you use the same technique again and again and again, it will be printed in their brains, okay? These are the things went well. These are the things went wrong, right? Another important thing from the retrospective I want to touch base here is, look for patterns. What are the patterns? Collaboration between the team is happening, working well. It is on good side. So how many people writing that? And how many retrospectives is going on? That means it is really working well. Collaboration is really, really working well. Our estimation is not working fine. Okay, take some action items, improve them in the upcoming sprints, right? That is what about effective retrospective. Whose responsibility is the quality? No, QA team, they say that. Developers, we build the code. Testers, you have to test the code. There is an understanding gap, right? It is a feature team. You as a team responsible to deliver, what is principle number one? Our highest priority is to satisfy the customer with early and valuable software, right? Working software. And truly cross-functional teams, encourage the teams to learn the secondary skills. Developers will not be developers forever. Let them do some kind of testing. Testers will have to do some kind of development, or UA interface, or something else. Definition of ready and definition of done. Very important for the scrum teams. Most of the times what I observed was they create their definition of ready, they create their definition of done, and they do not even look at them. Periodically you have to go back and review your DOR and DOD. Should I add some more thing extra? Or is it not working, right? Another thing, say no. You have to practice telling no in front of the mirror. If the story is not meeting my definition of ready, I should be courageous enough to say no to my product owner. Am I doing that? We have to do that. At the same time, if the definition of done is not met, I do not want to demonstrate to the product owner, right? That will again help to reach the quality of the product. Quality is not an add-on of the product. It is an intrinsic characteristic of the product, right? Last one, productive sprint planning meetings. Ensuring that product owner will come up with a prioritized list of items. They are meeting the definition of ready and all the clarifications are clear, no assumptions, if wireframes are required. So, whatever my definition of ready says, is it there or not? Ensuring that product owner is available for any clarifications. Ensuring all team members contribute to the discussions, right? These are very important. And soft skills. We are servant leaders. Scrum master is a servant leader. So, understanding who is Theory X guys, who is Theory Y in your team. So, Theory X guys, there are two problems, right? If something is not done means, there's a skill problem and there's a will problem. I can't do it. It's a skill problem. If I train you, I can do it. I don't want to do it. It's a will problem. So, Theory X. You need to understand Theory X. You can spend more time, convert them into Theory Y. Situational leadership. There's one guy who was asking, he was a manager and he was made as a scrum master. Why can't we call it as a scrum manager? Why scrum master, right? So, what happens next? The daily stand-up meeting starts happening from the glass room, right? Team is not talking about the three things. He is talking about, okay, why is it not done? What did you do yesterday? What are you doing today? That is not a jail, right? Decision making. Very important. Another important thing. Don't jump into the decisions. Instead, help the teams to find the direction towards decision making. Especially when you come up with a domain knowledge or you are technical expertise, we generally tend to jump into that and we provide the, rather than that, principle number 11 again. The best architectures, designs and requirements emerge from the self-organizing teams. So, they are doing, though, they know better than us. So, facilitate, encourage, help them understand and then come up with the suitable decisions. Helping the teams, let them understand the importance of being flexible and being adaptable by managing their personal management and discipline, responsibility and teamwork related, academic skills like if there is any training required for them, attending the trainings and keep some bandwidth to become cross-functional. And encourage them, fixing the problem before they look for who has broken it or who should fix it, it's not my problem. So, collective code ownership, one of the XP principles. There are some activities I plan for the team to play around with that. And let the team be progressively elaborate. Let them take baby steps. Don't worry about velocity. Let them understand the agile values and principles on the scrum framework and let them feel. And importance here is learning. Validated learning is very, very important for the teams. And take feedback, entering feedback whenever it is required. Learners need endless feedback more than they need endless teaching. Team building is another area where scrum master have to concentrate more. For example, I once they are comfortable with the scrum framework, understand the agile values and principles, then I introduce pair programming where the developers understand what is happening in the code and they get a good rapport between the developers and they kind of working together as a team. And the team members have created their own identity team names and they printed the logo t-shirts, come to the retrospectives, wearing the t-shirt so that they can feel as a unity united and instead of getting into a blame game, retrospectives will work effectively arranging potluck lunches sometimes and creating the team outings maybe at the end of every release the team will have an outing, one day outing going out, doing some activities. So all these things will help to create a results only work environment. I don't care how much effort we have spent rather than how much value we generated is very, very important. That should be understood from the team. So that is why these team building activities will be helpful. And collaboration one plus one is more than two definitely when they are working as a team. And face to face communication principle number six, the most effective and efficient way of communication is face to face communication. I appreciate the team when they have done some good job and let them understand the vision as a common team instead of having an individual vision, we are going to achieve something by end of release. So the product owner should communicate the whole and the team should see the whole and knowledge sharing and learning, maybe a 10% of the bandwidth can be utilized to become, to increase the secondary skills. I'm a star in Java, maybe I want to learn some skill server or I want to do some UI related things or I want to learn JavaScript. But don't force them by when you will develop your secondary skills, maybe they can come up. So we call it as a T shaped skills. This is my primary skill. This is my secondary skill one, secondary skill two. So I give, okay, at the end of three months I will learn these two things. I let them feel the shared accountability instead of having individual accountability. An important thing, keep everything open, visible, transparency, especially when you have daily stand up. Agile and Scrum helps you to expose the mess very, very quickly. So it will help you to address that mess, right? And doing a SWAT analysis, what is my strength as a team, where I am weak, what are my opportunities and what are my threats to address and move people around another XP practice. The developer will do some kind of testing and the tester will start his developer career by fixing some bugs slowly so that they understand the pain in the other role so that the collaboration will happen. And most importantly another point is I know when I see it. So what the team is doing, how they are progressing. You should have the information radiator visible next to the team's place where you can keep your task boards and you can keep your impairment boards. All these things will help the team to understand what is our piece, how we are progressing, where are we blocking, right? Learning is another important area where learning is a continuous thing. Agile is a journey, not a destination. Similarly learning is also important. So the moment you ask how do I learn or what should I do to learn that itself is the starting step to become agility. So this pyramid explains that practice-based learning or activity-based learning will have more impact than other things. So when you are doing something let them team participate in that and let them feel the practice-based learning that is more important. And ego is a blocker and curiosity is the first step. Sometimes there may be a guy who is a fresh engineering graduate who is a genius in JavaScript and the technical need may have to learn from him. It's very common because we are team, we are together trying to deliver working software at the end of the spring. Right? And Scrum Master's backlog for making the team stronger and together what I proposed is I created this kind of backlog. As a Scrum Master, I want my team to be cross-functional, high-performance, self-organized and motivated. I created some stories around that encourage team to create secondary skills, introduce pair programming, start TDD, manage their own impediments, arrange trainings and time boxing, all these things and I discussed with the product owner and the team members and I got there by in. Slowly I have introduced them, sprint after the sprint so that they become more high-performance and more mature teams. How I perform is directly related to how I feel, emotional intelligence, right? Very, very important. The team's emotional balance is also to be managed effectively. So what should we do for that? Protect the team from the external impediments or external disturbances so that they can focus on their sprint goal and pride, my team's success is my success. I don't have a separate success, right? And empower the team to make their own decisions, self-organized, optimize the whole rather than trying for a local optimization and celebrate the success, team outings which will improve the morality of the team and motivate them, create happiness, happiness index, how my team is, how happy is my team. Some people may be happy, some people may not be happy so have one-on-one meetings and speak to them, understand their problems, pain points, discuss with the team what can be done for them. All this is important. So finally, agile is built on responsibility at all levels of the organization. It's not just the development team or the scrum master or the product owner or the management. If you ask me that the development team is like water. If you put in a glass, they get a glass shape. If you put in a bottle, they get a bottle shape. So more problematic areas are behind that, may be management or the product. They will have different expectations, different level of conflict. So deal with them. Work with them very closely and one important thing is the team is a power-packed unit. So you need to channelize their efforts in a right direction. What does it mean? That means this. Just one second. You don't need to listen to the audio, but you can figure out what is happening there. There's a Jeep upside down. They're trying to get it right. That's where the team is focusing on the current sprint goal. He should have the scrum master should help them what might happen. Long beam, long beam and short beam. Finished the race, emerging as the undisputed champ, the rabbit woke up and realized that he'd lost the race. The moral of the story is that slow and steady wins the race. This is the version of the story that we've all grown up with. But our version of the story continues. The rabbit was disappointed at losing the race and he did some thinking. He realized that he lost the race only because he had been overconfident, careless and lax. If he had not taken things for granted there's no way the turtle could have beaten him. So, he challenged the turtle to another race. The turtle agreed. This time the rabbit went all out and ran without stopping from start to finish. He won by several miles. The moral of the story? Fast and consistent will always beat the slow and steady. It's good to be slow and steady but it's better to be fast and reliable. The story doesn't end here. The turtle did some thinking this time and realized that there's no way he can beat the rabbit in a race the way it was currently formatted. He thought for a while and then challenged the rabbit to another race but on a slightly different route. The rabbit agreed. The turtle and rabbit started off. In keeping with his self-made commitment to be consistently fast, the rabbit took off and ran at top speed until he came to a broad river. The finishing line was a couple of kilometers on the other side of the river. The rabbit sat there wondering what to do. In the meantime, the turtle trundled along, got into the river, swam to the opposite bank, continued walking and finished the race. The moral of the story first identify your core competency and then change the playing field to suit your core competency. The story still hasn't ended. The turtle and rabbit by this time had become pretty good friends and they did some thinking together. Both realized that the last race could have been run much better. So the turtle and rabbit decided to do the last race again but to run as a team this time. They started off and this time the rabbit carried the turtle till the river bank. There the turtle took over and swam across with the rabbit on his back. On the opposite bank the rabbit again carried the turtle and they reached the finishing line together. Both the turtle and rabbit felt a greater sense of satisfaction than they felt earlier. The moral of the story it's good to be individually brilliant and to have strong core competencies but unless you're able to work in a team and harness each other's core competencies you'll always perform below par because there will always be situations at which you'll do poorly and someone else does well. Teamwork is mainly about situational leadership letting the person with the relevant core competency for a situation take leadership and that is the end of the story. I think that's it for today. Thank you so much for attending this.