 I'm Vinod. I'm an application developer working with ThoughtWorks for the past six years. Also, I developed as an agile coach and help with lots of teams to build their teams from scratch. And my day-to-day work involves coding, as well as coaching new people coming onto the team. So that's how it is. What am I here for is to just share some of the experience I've learned, coaching some large teams and also building some teams from scratch. So let's start with this imaginary story. Let's say a new government takes over some country and they have a charismatic leader. And the leader wants to make this country very successful like any other developed nation. And he looks at various developed nations profile and then he says, OK, maybe we should be good enough in sports then people will start noticing us. So he calls his office and then says, find what should we do on which sport we should excel. And his office says, what if we win a football World Cup? You see, FIFA Cup is one of the most widely watched and we need all the teams to win that one. So let's go win it. But he says, like, our country doesn't have any football culture and how can we actually make it win this one? It's very difficult. It's like no football, nothing. And what people say is like, OK, let's hire the best coaches in town or in the world. Go anywhere. Pay them all the money that they can't refuse. And then bring them to coach our people. So they go to the likes of Pelé, Maradona, these guys. And one of their managers looks at this and says, hey, these guys are giving us a pretty good money. You shouldn't refuse. It looks like a short training. Just go and do it. So yes, fine. They convince a coach and then the coach joins in. And the coach is given a very two-week intensive training regimen, like you have to train our people in these two weeks. And the coach says, OK, it's very difficult. I'm not able to do it. And he discusses with the manager and the manager says, forget it, man, two weeks, good million dollars of money. Get it done and keep coming back so that we can consider it on our football. So this guy says, OK, hire the football field. Get them all the training gear, good shoes. And let's start at 6 AM from the coming day. Immediately the prime minister's office steps in and say, we already spent too much money on you guys. We'll get you 10 foosball tables. All we want is we want your knowledge. Share your knowledge and your experience with our team. Our team should get inspired from you. But it's OK, they learn football on their own. And OK, this training was done two weeks later. What the prime minister feels is like there's a FIFA conference going and send all our team to the football conference. And they'll meet a lot of great footballers, share all the ideas from them. All that is done, everything was prepared. The team looks all fine, very, very much prepped up. So the office gives a quote saying that we are enabled, or we are transformed, or we adopted football. And with that, it's a check mark done. And before the qualifier round starts, the prime minister himself personally comes, gives a very good pep talk, prepares and motivates people, and then puts them onto the field. They do go in with a lot of motivation and try to win the cup, but they end up coming knocked out. And they will not fare well at all. And it is like, it did not go anywhere. And why I'm sharing this story is this is the typical agile adoption story, which the first few experiences I had when I had to go and talk to the clients. I'll be given, I'll be called in to come and help the team, but will be given a very standard regimen, like please do so-and-so-and-things. And you have two weeks things to do. And then we want results at the end of the two weeks. So that's how it gets started. So my talk is more centered around, because I started with the football analogy. Let's say if a country wants to succeed in football, it's not going to be in a very short frame of time and not going to be in this kind of way, right? Similar to building any good agile teams, or I will say not even agile teams, any software development teams, I would say. So what was missing in the first thing was vision itself. And nobody wanted to know why this transformation was running. And it was more likely that agile enablement was their key goal at the end of this transformation. It was not something like, they'll not be able to tell you what do they want, what are the end goals. It's not something like, okay, from the concept level, I wanted to send it to production within three weeks. I want to get a revenue out of it in three weeks. Instead, what we will usually get is, can you help and come to my team, teach them how to write stories, teach them how to write in stand-ups, or can you train some scrummasters for me? Do you know how to cut down my release plan into sprints? And I don't know why all of these starts with S, but that's why I think it relates very much to success so people have all these S words to come and tell us what do they want to. And many of them, what happens is after they give us, they also try to influence the plan so much and then give a measure of success in terms of the metrics, like the unit test code should be 100%, those kind of metrics comes in. But you look at football games, right? The measure of success is nothing but, you win the game or you don't win. It's not something like this guy passed a really good long pass. So this guy, this goalkeeper kept on defending it, but it's not the end of it, right? It's more likely whether you won or not and that's how it is for the software teams. Are you able to send it to production on the time you thought you can go? That is what it is all about. In terms of facilities, facilities is very touchy subject in many places, especially in large enterprises, what happens is people don't get the right hardware. Most of the hardware we actually encounter to get into is pretty old, like two, three years, at least old. And hardware, sometimes it happens to be that ask any developer, the hardware actually matters to them. So in hardware terms, evolution is about like two to three years, every two to three years you get a new generation of hardware and if your replacement policy, it's three to four years, you're already out of that game and good hardware is not a luxury at all. It's as good as a good quality shoes for a footballer. It's the same as for a software developer. Next, degree of autonomy in allowing the coaches or the experts to handle the issues. Most of them like to try to bring in their own ideas. This is more like Advanced Beginner which I read in one of the blogs where somebody learns to do bowling. They try to do just throw the ball into the lane or do it all their own way. They'll have a really actually good progress from 20s to 30s to 160s they'll hit. But the maximum score you can hit in bowling is 300 but people will max out around 160, 150 and that illusion is called Advanced Beginner. People think that they know lots of things very well. They do it by their own knowledge and personal research but won't do it the right way from professionals. So what happens is people try to bring in their own standardizations and customizations way too soon. They'll get into the way of saying like, okay, okay, the kind of stories you try to bring in is way too granular. Our guys will not understand this one. Or when you bring in unit testing, come on, don't bog the developers down. They don't like to unit test, leave them alone. So this is the things which will start hurting us really very bad when doing it. Somebody told me that if you don't have anything in Japanese, people won't actually adopt it. That's the only reason we have this one. But on other note, it's more likely that if you wanted to do something, this is the martial arts term used to learn something new. You first have to imitate somebody doing it because if you want to learn, then try to introduce a small variation and learn from it. After you've done that variation and notice something about it, then introduce your own methods to it. That's Shu, Ha, Ri. And the Ri is the master. Most of the places where you do is we introduce the Shu part and ask them to do it. They want to jump to the master in this very next day. That's how it happens. Trainings. Trainings, typical trainings we had always seen is mostly certifications. And certifications are not training and they're not actually solving the purpose. It's more likely that certified football defender, certified midfielder, certified lineman, something of that sort it is. It's not going to solve any of the purpose. What is the real training you want to do is called bicycle skills. What if I have a bicycle and I have to go to the store every day and I have a very limited amount of time to pick up something and come back? I'm every day faced with the choice of either learning to bicycle and quickly finish this task in one minute or two minutes from the next day onwards or every day use the 10 minutes only to buy these things. You keep postponing these bicycle skills. You'll have to identify these things and bring them as part of training to bring it as an investment from next day onwards, you're going to reduce it. But certifications are more likely to give you how to ride a bicycle, all videos and all in books, but it's not going to teach you how to learn that bicycle. That's how it is. Team composition, where lots of teams we see the experience mix is not so very good when you bring in developers. Lots of developers actually get, you have different stages of brain evolution as well I think. From 20s to 30s, you learn a lot and from 30 onwards, that maturity also creeps in and by that time, lots of people become non-coding architects and they move on. What happens is lots of rookies or the new people who come in, they're not able to learn from them because the architects are no longer coding. This is very much like, will you actually have your own if you take it in the India cricket team? You don't have just Mahendra Singdoni and 10 new people coming into the team playing a match, right? It'll be a mix of people and that's how we want to structure it and that diversity and expertise mixture should always be there and this will be the most key component to all. And when I said that architects should code, what will happen is there will be some kind of a resistance when people had moved on beyond some certain level, they wanted to come back and see coding as a different kind of an activity or not for their kind of people. So there relies a challenge where we need to identify people who want to stay technical and who are actually having that aptitude also to remain in that field to promote that as also as a career path to them in the company. So after a point it should not stop as, after six years or so, we should not stop having a technical path itself. That's what it is. This is the only thing I differ from a sports team is I am the one who believes there should be no man of the match awards. The reason is in a team setup, it's always because of the team effort, somebody else's effort would actually look very big. And if you try to reward someone's output or because it seemingly comes from someone else, two things will happen. One person receiving the award will surely get motivated but the ones who think it was because of their job, they'll never ever feel that it will motivate and then it's like on a downward spiral. And next thing is, the biggest thing is the time scale. Anything we see, we are not changing some process out here like you change these knobs and it starts working, it's not the way it works. We are asking for people to look at cultural change, right? And cultural change involves people. People change is not so easy. It's going to take a long time. But people looking for results, metrics in terms of financial numbers with so-called 90 day dash, every quarter you need to present something. I would say this will not be so very easy to present unless there is already an established team and you do some minor variations and you want to see, you can see it. But if you are setting it for the first time, there is no way you can actually get to know something very soon. What I'm saying is it is something of in the order of months and years, not in days and weeks. In case you want to build your team really well and you want to keep it going on, you should always things in months and years so that, and you also need to persist because first time you try it, it actually shows that it's about to go down because of all the new things we are introducing, but it will stabilize after only a while. And that chasm people have to learn to cross. If they don't do, most of them quit just at the right time when they are going about to harvest the benefits they've invested. So that is the persistence part of it. Recap, we talked about vision and ownership. There should be somebody thinking of what the end goal is and that person has to be there throughout. Understand that it's not very easy nowadays to retain talent for such a long time. There has to be ways to actually track it and as an office or as a company that should be propagated across individuals, a new person should not come and start everything from the beginning. Facilities are not luxury. If you think that hardware is needed, the policy should change and policy should accept new hardware should come in. Trainings, again certifications are not training. We are not able to gain anything out of training. Shuhari, imitate if any, if you're bringing in a coach, try to imitate what the coach tries to do. Introduce your variations after you've learned to imitate it and then bring in your own innovations. Give some bit of an autonomy to the coach. There would be some resistance to change from senior members. Use guided mastery to let them adapt to the new changes and make them feel safer and also create a technical path for people for the beyond six or seven years. Timescale, yes, definitely it's going to take a lot of time. It's not going to be a quick win. You'll have to persist and also make sure that you're not having any superstars in the team or at least just treat everyone as superstars in the team. That's it. Thanks. I blog at vinodkumar at wordpress.com and many of my blog entries are related to these kind of topics and looking forward to meet you out. Any questions you have? So what is, how do you divide your time? So I don't divide my, so the question is, how do I do both development and coach? There are assignments I keep switching back between development as well as coaching and there are some of my friends here who I work with them as coaches and right now I'm a developer.