I know there are a lot of other sessions going on equally or better interesting so thanks for being here and hopefully I can add some value to your next one over here. My name is Tathagat, I work with Yahoo R&D center that we have in Bangalore here in India and just a short intro about what I do over there. So we have more than 2000 people R&D center here and this is a product center that we have been having for about 10 years now. I lead the business operations at Yahoo India and I also lead the agile transformation program. So this is actually my own experiences of how we have been doing the agile transformation at Yahoo for the last two, two and half years that I'm giving you, I'm telling you one story of what really we went through, what have been the learnings, might or might not be 100% relevant in all the situations but take your pick and really decide what is really relevant for you. I thought I'll call it as managing large scale agile transformations and as we know the transformation is a very heavy, very heavily loaded word actually, it's one of the most difficult things, easier to talk about, little difficult to do and much more difficult to sustain that. One of the biggest, one of the most profound and everlasting transformations ever designed by people is what is known as the Alcoholics Anonymous actually, which is a self-help group actually because that's a transformation that we are talking about at an individual level. How can you really make sure that somebody who is in love with the bottle can actually kick the bottle? So that's really a transformation. How do you really go from state A to state B? We also talk about when we think of transformation, one of the things that come to our mind is metamorphosis. So a pupa turning into a butterfly for example, that's a transformation but in many of those biological metaphors, there is no control that is available within the system for them to do. So a pupa does not really or a larva does not have, thank you, so it's what you can call as an in-situ control actually. So they do not really have, being within the system, they don't have a lot of control over what they can do. They cannot really change their destiny whereas the transformations that you and I are more familiar with in an organizational context is not something that you are sitting in a bandwagon or you are sitting on a rail wagon and somebody is taking you somewhere else. We are talking about a transformation where the participants are stakeholders. They have an equal stake in it. They have an opportunity to question things. They have an opportunity to influence the end result of that. So that's a kind of a transformation just to set the context there. When I talk about large scale, I'm sure there are many more examples in your own companies which might be even larger than that. My definition of large scale is not from a team size perspective here. We are still looking at within Yahoo! context, a team size is still what we are looking at an agile team size actually. So large scale is more in terms of, we are a very highly matrixed organization. We probably have more than 100 cost centers operating out of Bangalore alone. So there is no solid line reporting happening to many of the teams. So they are really operating within the context of small teams and there is a big need for collaboration. On an average a product release could be happening by interacting from five or six different teams and all of them have their different cost centers, different priorities, different road map for example. So program management has traditionally been extremely strong in Yahoo! because they have been able to coordinate and pull it all together, it's been an orchestrating function so to say to bring all the moving parts together and to go towards it. So I'm talking in the context of that large scale where there are multiple groups each autonomous by themselves, each are empowered to make their own call about their destiny and how do you really orchestrate them together. I hope this clicker is going to work here. So just to set the context about Yahoo and so what we are really all about is creating those deeply personalized experiences for the users and make it as a daily habit. So that's the whole idea. If you go to everything.yahoo.com you will see we have more than 1000 odd products. You have news.yahoo.com, finance.yahoo.com which are really the market leaders there. And this is an industry, so we are actually in a very funny business, we are in the business of selling free software and I don't think there can be anything more difficult than selling something free because as a consumer you have an option. If you have taken a paid service you are more likely to go there and use that service. But what if it's a free service? What if it is down for let's say 30 seconds what do you expect to do?  You don't do that. You just go on to the next site. So if cricket.yahoo.com is down and you are not seeing any response from there. You don't go to yahoo customer helpline and say hey you know what this is down. Can you do something about it? You just move on to ESPN star or Cricket 4 whichever is a better option for you. So that's a brutal world that we live in actually. How do you make sure that when you are in the selling of free user experience you can grab the iBoss. You can really make sure that people are coming and sticking to you. And just to set the context we are dramatically different in that sense. So if you see Google, if you see Facebook, if you see yahoo, Google is in the business of selling. So when you go to Google.com you actually go for less than 2, 3, 5, 7 seconds actually because you want to get those 10 blue links. Click on the right blue link for you and then step out of Google.com. So that's what Google is really all about. If you look at Facebook it is all user generated content. So you and I are all creating those user generated content. Neither Google creates content nor Facebook creates content. They both are getting it curated. So while Google is doing it from the search engines, the crawler that it is doing, Facebook, you and I are writing that. That information that we have on Facebook is not of business relevance. That's a lot of things that my friends, I mean like my dog was sick or I got a new dog collar or I got a new car or something. I'm going to put some photographs there. So that's just to set the context. Whereas in case of yahoo, what we do is we actually are more like a Times of India or an NDTV on the online avatar of that. Because we have editors on our roles. And these guys are actually creating editorial content. So they are writing it and we want you to consume it. So we want it to be sticky. Be there for 5 minutes, 10 minutes, 20 minutes and consume the content. So that is just to set the high level context of what it is different. We do have a search business. But then the core of that is really as being a premier digital media destination. And that's where it becomes difficult because there are a lot of people who provide content. I mean the whole blogging has the whole internet is really all about democratizing the creation and consumption of information. In the print world where before when the Gutenberg press came, it really created the biggest revolution because before that time it was only a word of mouth before the print media was available. When the printing press came, the spoken word could be put down on a piece of paper and it could be sent out more than 50 miles. Because the verbal word only had a power to go to probably 20, 30, 40 miles because you have to go there. There was no automobile also that time. But with the written word there, it became easier for us to do. And with the internet what we have seen is it can go anywhere. So that is the level of democratization. So that's a kind of a world that we operate in just to set the context here. And just a little bit more on that. So we are really coming from the consumer internet world where like I said, entry barriers are rock bottom actually. Even today two people can sit in a proverbial garage and create the new Yahoo, new Google, new Facebook, new LinkedIn, new name it. Anything could be done by, and that's being done there. So that's one of the biggest demarkers of our industry. And the critical success factors, if I look at them, the first thing is innovation. And when I talk about innovation, it really assumes very different meaning. There are companies, for example, Flickr which is a Yahoo company since 2005. They have been pushing the code into production multiple times a day, for example. So they are not doing continuous integration. They are not doing continuous delivery. They are doing continuous deployment. And when I say continuous deployment, Flickr is doing it. Facebook is doing since last August twice a day, for example. Chrome is doing it. A lot of companies in the consumer internet domain are doing. In a traditional waterfall world, the biggest challenge has been that. I mean, suppose, I'll just do it. It's a little afternoon, so let's have a little wake up quiz there. If you, in your process, if some bright engineer comes up with an idea today, how fast can you release it to the market? Can you do it under three months? Raise the hand. I don't see a single hand here. But that's the brutal industry that we operate in. For example, Atlassian, which has a going on there, they have this notion of FedEx days that they call it. Daniel Pink has in a straight talk talked about that. Why do they call it FedEx days? Because FedEx is known for something being delivered overnight, right? So they deliver something in 24 hours. In Yahoo, we have been having for multiple years, we have these concepts known as hackathons. A lot of consumer internet companies have that. Where what people do is the hackers come and sit there for 24 hours. They sit through the whole night. They take up an idea. They form teams there. There is no guidance. People come from their own ad hoc group. They start coding there. And next day, within 24 hours, they have to show a working software. They cannot show PowerPoint. They cannot show Microsoft Word document. They have to show working software. As we speak, we actually had one recently, just last week, actually, we had there. So that is the kind of thing. Can you, if you have one bright idea, can you turn it fast in the market? We have heard, since today morning, also a lot of conversations about lean startup. We have heard about creating an MVP. We have heard about really the whole lean startup loop there. But the key thing is how fast are you really able to iterate through that cycle there and get a validated learning from that? So that's the kind of a context in innovation. Speed, no doubt about it. Like I talked about it. So if 24 hours, I mean wordpress.com, I'm sure many of you are blogging here. Wordpress.com as a platform has been doing continuous delivery for last four and a half years. They have done 25,000 releases in last four and a half years. And that translates to 19 releases of their software every day. For last four and a half years, how do you compete with somebody who has that kind of a process like a well oil machine there? So that's where speed becomes important for everybody in this game. And finally, user experience. In terms of functionality, I was seeing one of the graphics on the internet actually where it said, up until like five, seven years back, you could make out the cell phones. See, this was a Motorola cell phone, a Nokia cell phone or something else. Today, if you look at smartphones, they all look alike. I mean, rounded corners might be patented by one company, but everybody has very similar. You cannot make out. Functionally, they look the same. Visually, they look the same. It is a user experience that's going to make you decide that I want A phone or B phone or C phone there. So that's exactly the same thing for us. Even more so, because there is no buying cycle in a free software. It has a very different notion of buying cycle. The cost of switching from one website to other is like few microseconds. So that makes it even more challenging. And finally, when we look at the whole notion of agility in this business, given this context here, we believe that we are really not hung up on the beliefs, labels, and rituals. We believe agility is really all about results. We believe agile for that matter is not an end value. It's actually an intermittent value created for the sole mean of creating business value to the stakeholders, to our founders, to our shareholders, to the customers. So it's really all about results rather than belief, labels, or rituals. The journey really started for Yahoo many, many years back in Sunnyvale when they called Jeff Sutherland to come and talk about that there. And then in the last couple of years, we have seen multiple attempts there. And there have been quite a few waves in which we at Yahoo have done that thing. The key thing that I have taken away from this is basically if something is really working for me, I don't need any more proof points. If the scaffolds are taken off, I'm going to continue doing it. That's how I look at the whole motivation to do something. So if I'm getting the results there, so I would like to believe that these people in all their fairness, they tried that. And they probably didn't get the results that they were looking for. So they went back to doing something which was more efficient than what agile was promising them. So that's the context that I started out with when we rolled out the program. So we created this program about two years back at Bangalore. And just to give a flavor of the sense of urgency that we wanted to create with this change transformation program, we called it ASAP. And ASAP was really Agile and Scrum adoption program. And we created three cornerstones of this starting from facilitation, focus, and framework. So just to give you an idea, we are like 2000 plus center here. We have five or six major views. We have 150 projects running at any point in time. Each of these projects are highly empowered entities there. There is no way I can go there as the agile lead there and say, you know what, from tomorrow we are going to do this. They'll kick me out of the room there if I ever tried that. So how do you really make sure that you are able to support that kind of an organizational change program? So our approach was really facilitation. We said we are not going to be preachers. We are not going to sell there. We are just going to facilitate the entire journey. And then what are we going to focus on and what's the framework there? So when we said facilitation, we said we are going to talk about center wide agile adoption. When we took that call, it was basically known that we are not really getting into nuts and bolts of every single of those 150 teams. Because we actually have a one-person team there. So right now, Proful is a part of my team and he really program manages that for me. And it's a one-person team. So our transformation is really all about one full-time person and my shared bandwidth for all these 150 projects. That's the model that we work in. And the whole idea is really to make sure that we are able to support all these 150 project teams in basically doing a more effective agile adoption. The focus, like I said, was on results. So we said we are really going to really focus on be agile rather than do agile. I don't care if it's a stand up or not. I don't care if it's a sit down or not. I'm not really going to be hung up on those labels and rituals. All I care is do you as a business believe that you are agile enough in your behaviors, actions, and results that is commensurate to the needs and asks of your business. And that's really the key thing that we want to understand here. And finally the framework there, which we said it's going to be. So I remember 25 years back when I started studying computer science, we had this fantastic book on networking from Tenenbaum. And I think that book is still used in the colleges today also. He said one very funny thing. He said, the beauty of protocols is that there are so many to choose from. And I think that is very much true in agile methodologies also there. So it is like you have 15 standards. So the problem is being discussed. And then you say, how do we deal with these 15 standards? Let's create a global standard. What is the situation now? We have 16 standards. So we didn't want to create that 16th standard in the company. We said, no, we are not going to have our own Yahoo agile methodology. We said, no, that's not what we want to do. We said, we are going to be label agnostic. We are going to deal with the fact that these 150 projects could be doing waterfall. They could be doing scrum. They could be doing DSDM. They could be doing Kanban. And we couldn't care less. And the whole aim was to create a program in which we could really run it in a way that people are empowered to choose. Here is the deal. If you trust your team to be self-organizing. And I was sitting in the David West presentation where he really, really created good enough controversy for the next couple of weeks, I'm sure. When he said, what is self-organizing? I mean, I took a lot of things home from that conversation. But so here's the thing. If you think, if you trust your team to be self-organizing, mature enough, honest enough that they can handle, we want to deal with them as grown-up adults there, then why do you even go and prescribe that you should do a stand-up? Allow them to choose their own destiny. Allow them to figure out what works for them. Allow them to choose their tweak the process and see what works for them and what does not work for them. Throughout the Scrum Master, I mean, the point is the team should really be, if we can trust them to develop the software, why we cannot trust them to decide the process that's going to develop the software? That's the point I'm saying here. So as a framework, we said we are not going to. That's not our business. We are not really going to talk about the labels and rituals here. So this is afternoon time. The coffee might be wearing off, so let me just pose a small question. Those who have been in one of my previous presentations can skip that one, but I just have a small question for you. What is the most important part in these two machines? Wheels, driver, wheels, drivers, energy? Come again? The end goal. Well, all are right answers, but this was the right answer I was looking for. And why are the brakes most important? Any thoughts on that? Well, I'm getting good answers this time. Normally, people say so that I can stop, but then it actually is just they let you go faster. Think about it. Close your eyes for a few microseconds and think about you are riding a bicycle that has no brakes. How fast can you go on that bicycle? And now think yourself that you are actually riding a bicycle that has very well tested brakes. Not really saying there is the only one flavor of brakes that thou shall do that. And this is how we let people really figure out what is the brakes that they are looking for. So with that in mind, we created the ASAP program. And then this is the journey. So we said, so this was actually a three-step model that we created here. And it's very different from many other transformational programs or models that you will see. Because the first step is really all about establishing credibility. And I'll talk about a bit why it's important for us. The second was scaling up in the third is self-sustaining. So as you can see from the timelines, we really started this about two years back. And it went on for quite some time because it's a question of dialogue. It's a question of listening to the people. It's about being there in the trenches with the people and really understand what is working for them and what is not working for them. As opposed to saying, you know what? This new shiny book, it talks about this thing. Why don't you go and do that? That's been the thing. Second has been the scaling up. And the scaling up, like I said, the scaling up, many a times scaling up is assumed to be, OK, now I have a 10 people team. I have to scale it up to 20 people team. How do I scale it up? Or I have 100 people team suddenly in five distributed locations. Our notion of scaling up or our task of scaling up was we have certain things that have worked there. How can we take it across the entire business unit? We have done it at one business unit. How do we take it to there? We have platforms on one side. We have what we call as the properties on one side. The media properties, for example, like we have a Hollywood celebrity gossip site, OMG, which is really all about the gossip site. In one of the presentations, I had used that slide, but I don't know if anyone remembers last month we had the Super Bowl. And during the Super Bowl, a very funny thing happened there. Anyone remembers that? The lights went out. There was a power outage. 630 Eastern time, the kickoff. And 838, the lights went out. For almost 45 minutes, half the stadium was in darkness there. If you are in that position, what are you going to do there? Six minutes into that time, six minutes into darkness, the first tweet came out from Walgreens. We also carry candles. 10 minutes from that power outage, there was a tweet from Oreo. And I'm not making this up. You can go and look it up on Twitter. That said, you can still dunk it in the darkness. 13 minutes into that, 10 minutes into that, Kelvin Klein came up with a video ad, which showed a muscular guy doing a workout actually and said, you can do workout even when the lights are out. And 13 minutes from there, the tide, the detergent guys, they came up with this tweet, again, tweet ad, basically that said, we cannot take away our blackout, but we can take the stains out. Something like that. The point I'm making is, that was an opportunity. And I have more statistics on that. The minimum ticket price was $2,000. 13,000 was the maximum price. 70,000 seats, $160 million was the ticket sales. 1 billion people are watching it live on television there. That's the kind of an audience you have. And you have an opportunity that has just, Gate of Heavens have opened and it has opened up right in your lap. What are you going to do there? So that's the kind of a context we wanted to make sure with that we are operating here. So coming back to this, establishing credibility, scaling it up and self-sustaining. So this is something, scaling up is something which is going on and self-sustaining is again going on there. And I'll talk about that. So establishing credibility is important because culturally, Yahoo has had a very strong microculture. We have a very democratic culture. Sometimes it works a lot. Sometimes it works in such a way that if one engineer on the team says, no, that's not going to work and vetoes it down, then nothing can happen there. So an engineer can veto down some process change, for example. And people respect that.  If one engineer has a problem with that and can convince rest of the team, then you should live with that, right? So that's been the challenge there. So it could be well-established model that has worked in ABCDE companies, but then people are really looking for, okay, does it work in my context? Can I see what's going to do that? Oh yeah, we are different there. Is it going to work for us or not? We always have those kind of challenges there. So the way we worked on the establishing credibility part was we said we are not going to sell agile. That's the last thing people want. In fact, as we speak right now, if I speak about, if I say, hey, you know what agile can do that, I'm sure to get kicked out of my office. That's almost sure because people have gone to the point, okay, fine, fair enough, we understand that. Show us the proof point. When you look at a popular literature, you see a lot of literature that says this team got 800% productivity improvement. This team got 500% productivity improvement. In fact, one of the presentation from Jeff Sutherland talks about 11,000% improvement in productivity. Now I have one question to everybody here. Standards and poor 500 index, S&P 500, 500 US, top US companies there. What do you think is the profit margin of those companies? Is it 500%? I mean, if those companies have really teams that are getting 500% productivity gains, I'm sure it must be somewhere, order of magnitude closer to that, right? 15%, the most mature companies anywhere in the world operate with the profit margin of 15%. So why is it that when we have these fantastic claims coming from the trenches that talk about 500% productivity gains by doing XYZ brand of agile, we are not able to scale that level. We end up with that 15%. Why is there such an impedance mismatch between what the engineers are doing and what the businesses are able to get out of that? So that's been the thing. So we said we are not really going to sell agile. We are going to solve specific problems. There is a problem. We want this particular thing. We want this release. We want this feature to be validated. We want to do that. Let's see what is the best process for that. It's a toolbox. Some processes will, some problems require a hammer. Some problems require a screwdriver. Some problems require a plier. Let me be a carpenter here. Some problems can best be solved by waterfall. Some problems can best be solved by lean. Some can be solved by agile, Kanban and lean Kanban. Let me recognize the variety of that. Let me celebrate the diversity that I have from these toolbox. So that's been our approach here. The second has been don't boil the ocean. Create beach heads. One of the things, many times we make a mistake when we are the change agents, is we think everybody should behave in the same way. Everybody should wear the same color of uniform. Everybody should have the same vocabulary. Everybody should have the same tool. Everybody should have the same way of looking at the world. We said you know what? We cannot boil the ocean. Recognize the fact everybody is different. Everybody is in a unique situation there. And let's create beach heads there. Let's make sure, okay, this is a kind of a problem that I'm, this is a class of problem I'm looking at. Can I establish a beach head? To me, that's the most powerful way of selling agile to a particular BU and say, hey, you know what? This is in our context. We had this particular problem. This is how we really solve that thing. And we are not even talking more than that. You pick your own lessons out of that story there. But this is a story that I have instead of really talking about boiling the ocean here. Don't make wild promises show real results. So in line with what we said, we said we don't really want to go and say 500% productivity improvement is guaranteed or your money back. We are saying, let's show the real results. And my, if my real result is 6% improvement in my time to market, so be it. Let's talk about the real results that we are getting from the implementation. And finally, the approach was when many a times we talk about ROI and we say, you know what ROI is efficiency. But ROI is not efficiency. ROI is not really dollars saved. Because what happens when you say that I'm able to, my productivity went up by 30%. And my profit margin is still at the same place. But my profit, so what is happening is you are sprinting faster. You are probably churning features faster out, but you are actually being very anti-lean because you are piling up a lot of inventory. Because at the end of the day, your cash flow is not showing that you are actually able to, your customers are recognizing the fact that your improved agility or improved ability to churn the code out is resulting into a better cash flow.  You're basically piling up a lot of inventory there. And even though at a developer level that inventory is not visible, but at a business level that inventory is very much visible there. Because that's not really moving up. So what we are saying is ROI is not really dollars saved. It is dollars earned. That is the return and investment that we should be looking at. So this was really all about establishing the credibility. When I talk about scaling up, there were four major themes that we created and I'll talk about them. And that was really, one was the community. Because we said agile is really all about creating communities. And if we do not have the community involvement there, it's really going to fall flat on our faces. And in a large organization, if you really need to have an existing organization that's already running there, you are saying, you know what? We are going to turn everybody and go in this direction now. You need organization structures. I thought we, I think we had some session today morning from Mary. I think she talked about that. That it has to be or was it from Craig yesterday that has to be accompanied with organizational structure changes. The change has to be done in a way that, so that's from the org structure part of it. You need people to be trained in that. If people don't understand what it's all about, then they're not going to be effective. And then finally look at the processes part of that. So, sorry, the older ones, yes. So what we did was when we, in the previous implementations that we had, it was really more of bottom subs. A couple of developers, they say, okay, let me try something here. Let me see if it works or not. But unless you really take it from the top, it probably is not going to stick around because like you will see the laundry list of things that we really looked at.  So let me just come to that and if you can hold your question for now. So when we looked at the community part, we said there has to be a recognition of the fact that there will be a need to have internal community of practitioners, enthusiasts, gurus, people who can really lean back upon each other and learn from each other there. They can celebrate their success stories. They can, without embarrassment, without intimidation, share their failure stories, for example. They can reach out to their trust circle within the organization and say, hey, you know what, we tried that. Hey, how are you guys doing it? I saw, I heard about some big stories about how you guys are doing stand up there. Can I learn something more about that? That kind of a thing. If I send that mail, most of the people will put it in the junk box. But if they hear it from a peer, it probably is going to be more effective because they can relate to that much better. So that's the whole idea of creating internal community. Expert Talk series, what we did was, we have been doing a lot of talks. I'm sure all companies do that talk. So we created a new talk series and Profil actually created that, which was basically, we said, we are only going to focus on, in this talk series, on people who have done something there. So these are really from the trenches. People have rolled up their sleeves. They have been in the trenches and they are talking about their experiences. Nothing can be more powerful than the story of somebody who has actually been there, done that within the same context. So that people don't have, you know what? Yeah, maybe it works in that company, but we are Yahoo, it doesn't work there. That big, big question we were able to eliminate in that process there. We've been doing for about, I think, seven or eight talks we have done there. And these are all the people who are actually people who are day in and day out, they are doing it. They are not even selling it. They are just saying, hey, this is what was the problem. This is what we did there and these are the results that we have. So that's been a big way in really talking about. External community connect events like these, for example, where we're able to learn from people from each other and say, hey, you know what? This is what Linda Reising had this beautiful idea about agile mindset. Why don't we look at that? Can we do something about that? So basically you're learning, osmotic kind of a connect there. On-conferencing lean-graph is a multiple such kind of events that we looked at. When we looked at the org structure and we realized that one has to holistically look at roles and responsibilities, goal-setting, performance management, compensation and rewards and professional development.  A lot of these issues may not be even relevant at that stage of that startup there. Once the growth picks up and once you become bigger to manage than those functions, then you probably have to start looking at them agile or no agile. And what happens is when you have an established company with 10,000 plus employees and you are saying, you know what? We are going to move this way. People will come back and ask, you know what? I have heard that Scrum doesn't have the role of a manager. I have done a lot of search on the net and that says manager is not needed there. Does my job go away? Is that how it is there? So are you going to turn me into an IC, an individual contributor? In that case, why should I stay here? You, we know it. I mean, in the Indian context, many of these models have bigger challenge than in the western context there because we are a society where accomplishment driven, the rising of the career ladder has been a very, very societal recognition kind of a thing there. I have literally had people, my team members come and say, hey, you know what? TV, if I don't get promotion to a manager, I won't get married. And I'm sure many of us have heard of those anecdotes as well. Because that's a big deal in our society. That's the way we are. 1.2 billion people cannot be wrong, but that's the way we are. We have to recognize that. If your model, if your biblical model does not talk about that, you need to question that. Apply the same filter of inspect and adapt before you accept it. If that model is asking you to accept, inspect and adapt every single thing, the first question you should be, I remember 15 years back when I was big into CMM and all that, when I used to work at Philips, Ron Redus, who was the director of SEI, Software Engineering Institute, I was talking to him, after Watson, he was director. And he said, before he took up the job, he took the entire CMM level five model and he said, they asked him to come and be the director of SEI. And he said, I said, I'll come only on one condition. I will take the entire CMM model everywhere there is a project team written. I will do a cut and paste and put SEI, Software Engineering Institute, Carnegie Mellon University. And I will see whether that entire five step model works or you guys being CMM to begin with. And his view was they were being there. So that's where we joined them. So that's the whole idea. I think everybody should be, nobody should be below scrutiny. Everybody should be able to be scrutinized and be accountable for that. So that's what we are looking at. We looked at multiple things there. In some cases, we looked at what will be the role of a people manager. The project management and as it is, is getting democratized in an agile environment because the entire team is responsible for that. So the three major activities for any manager, people management, technical management, project management, project management has gone away. People management has gone away in that sense but there is still an organizational requirement there. I mean, end of the day, we are not there only to make software, are we? We are here to make money. End of the day, the effort that you are putting is going to put food on the table for your family. In a society that we come from, whether we like it or not, there are people to make serious careers out of it. End of the day, you need that question and say, okay, you know what? If I had worked in that industry, if I had been in that company, you know what? I would have got a better career progression, for example. So we have to recognize the fact. I'm not saying that it is this or that, it is this and that and that's where the context is important. That's where the intercultural issues become important for us. So one cannot just easily blindly shy away from that and say, you know what? These career progression issues do not really count for us. So we grapple with them when we did that. Goal setting, for example, how do you look at the goal setting? Is it an individual goal setting or a team goal setting? If team is going to be answerable for the results, how do we look at the individual appraisals then? Are we going to look at team appraisals? Does everyone get the same? If my budget is 5% or 20% or 8% or whatever percentage, do I do a peanut butter spread of that budget every year or do I give flat percentage to everyone? How do I recognize the fact that there will still be a bell curve, whether I like it or not? It reminds me of a saying that my previous HR manager in Phillips used to say, there is a bell curve even at Bell Labs. I mean Bell Labs has seven Nobel laureates, right? And very, very talented people, but there is a bell curve there. So the point is, there is a distribution of performance because we are a sample. We are, I mean, it's randomly connected, collected people will always have, it's like the height difference, the age difference, there will be performance difference. So how do you make compensation and rewards? We haven't come to that completely, but that's an issue that's going on there and we are trying to look at, well, how do you deal with that? Are you going to put the pot of honey there and say, you know what, just pick your own thing in a democratic manner or are we going to say that everybody gets this much? So these are some of the questions there. I don't think there is anything right or wrong per se. You really have to see what is your cultural context? Does your cultural context allow you to take one over the other and why? And I think there should be, it should be able to stand up to an open debate. If people are going to talk about in your message boards, so be it because any test that cannot pass that kind of an open scrutiny is I think there is something wrong in that. So that's how I would look at that. And then finally about the professional development. For example, okay, I've been a scrum master for two years. What do I do next? Do I become a senior scrum master? We are a country which unfortunately we have had this legacy to deal with and 200 years of British Raj can do it to us that we have got so much fallen in love with the whole idea of hierarchy. It's going to take time for us to do that. Can it be overnight removed there? We probably might not be able to remove it, but look at the whole thing. If tomorrow Yahoo says, you know what? You're going to be scrum master. We don't really believe in that. I mean networking, it's been common. I know when even in semiconductors, my brother works for a semiconductor company. For the last 20 years, he has only one title, member of technical staff. That's the way it works in a semiconductor company. In many networking companies that works like that. Member of technical staff, 20 years people are working with only that title. But many cases, it doesn't work. Many cases, it works there. We have to see what is really going to work for us. The key thing is if we are going to be the only, like Chetan Bhagat wrote in that book, What Young India Wants. He said, all the Indians want change. None of us is shying away from the change, but I don't want to be the only person to change if rest of the world is not changing. And that is the biggest challenge for us really. That if I am the only one who's going to abolish the entire people hierarchy there and people are only going to be responsible as, well you have a choice if you are really a product guy, train yourself, get into a product owner role. If you are a good facilitator, get into a scrum master role, figure something out.  There are 200 companies, MNCs in Bangalore, which are offering the senior manager role.  So how are you going to address these issues? If you all remember Maslow's hierarchy, let's not forget that's the innate human behavior there. If we don't have the sense of security there, there's nothing that we can do to self actualize people there. So unless we really address those rock, bedrock of those concerns there, there's no way people are going to really rise up to that. So those were some of the things here. Then, sorry, many of these have been structurally done. So whatever structurally changes we had to do in terms of defining people's giving there their roles has been done. Some of the internal change behaviors are always going to be there, right? So if you look at the entire change cycle like the Kubler-Ross change cycle, people are taking their own time and doing it. Structurally, it's all done. We have gone through that process. But internalizing it and really believing in that change is something that I think people will take their own time to do that. The trainings we did, intact team training, role specific, specialized, exact briefings, et cetera. And then finally on the process part, and again we said, like I said, label agnostic, let people choose their own destiny. We trust them to figure out what they want to do. So we have projects actually, as we speak, some are, there are some very cool kind of work where they are doing lean startup. Some of the ones that we have released recently, there are people who are doing Kanban, there are people who are using Scrum. There are people who are doing a hybrid model. We are fine with that. We don't really go and be the process pull is there. We have team members. We have Scrum masters. And then we have taken it to the next level where we have said these are tech lead managers there. So the first line manager is not really the Scrum master there. And we have tech lead managers who are responsible for the career progression, hiring, mentoring, coaching, and also they are responsible at a product level. But these are the people, their span of control is bigger than what it used to be earlier, because we realize another problem with that when we went into scalability. Theoretically, if I abolish all the people managers, at some level, I will need something. Let's say director is the next guy. We are in director level on an average in your organizations, how many people responsibility he or she has? 40, 50 people. You are creating, there is a nice saying that says, today's solutions are tomorrow's problems. Now try to put that hat and think about it. We create a model, there is no first line manager, there is no second line manager. We solve today's problem. Everything is fine. We go home, open champagne. What happens after six months, one year? We are not creating enough bench within the organization, a leadership funnel. So what happens is we are creating, come to a point where suddenly now somebody who has to be a director, there is no opportunity for that person to become an apprentice. Solve smaller problems, learn from the trenches. You are suddenly creating a thing that you were an individual contributor and now suddenly without any training, without any formal experience, you suddenly are responsible for managing an entire department there. I think it's going to be a disaster there. So one has to really look from that perspective and say, okay, how do we really deal with that problem? Is taking baby steps a better way rather than completely going the other way? So these have been some of the thought process there. So as a part of the organization program, we created a metric strategy and I think this has been really, so you might say, okay, what kind of a program is this? People can choose their own process. People can figure out their own way of doing things. So what is really common about doing things? So this is really where it comes, it's joint at the hip and what we said was, we said we are really going to measure each of these 150 projects in a way that they are going to do a self-reporting. Now, don't get me wrong here. I'm very skeptic of tools like the Nokia Scrum tool, checklist and all that thing. I don't want it to be reduced to the fact that we are looking at checklisting and doing it. But we did create a checklist and the whole idea of checklist was that people who are working in the trenches, they fill up a certain level of assessment about their understanding of what they are doing. You can say people are going to fudge the data. If you can trust them to develop the software for you, I think you can put little more trust that they will be honest about writing those because we are not putting them on the MBOs. So we created this program where we said, the bottom level is people who have not started their agile journey and they feel that they would like to get started are the people who are ready there for that. So that is the red band here that we looked at. The people who have put some of these practices in place and they have started to talk about that as really getting into the adoption game here. The people who have started to do things like, I really know how much time it's going to take. I know about my velocity. I know about my code defect density or whatever measure you are looking at it. That is the efficiency part of that. And then finally, when you are able to show the results there which are commensurate to what the business is getting out of it from what you are doing. Those were the effectiveness part of that. So, and we said, it's not done. I mean, this is a journey basically. Are you going to be effective on day one? I don't think so. How many projects we can talk about that say, you know what, because of doing these things my revenue has gone up by 10%. And that's what we are really looking at when we talk about effectiveness. Whatever is the measure of success that you would like to work with? No, this is for each of the projects that are a part of the ASAP program. So I'll just show a sample of that as well. So let me just show you two more slides so that you will get an idea. So basically the stages were really all about. So when we said readiness, the team is interested to adopt some form of agile development and shows the commitment by taking first few steps towards it. Basic building blocks are in place. They have probably identified some scrum master. They've identified some notion of what sprints they want to do. Some of the basic steps are in place there. The next step was when they said, you know what, we have the basic PDC cycle in place. I mean, what is scrum at the heart of it? As a process, it is same that Deming gave 50, 70 years back and before Deming, he took it from Shuhar. We are talking about the PDC cycle and the same PDC cycle is coming from the basic quality and statistics and then it came into the waterfall but that PDC was too big and then agile was able to reduce that. Kanban doesn't have a PDC of that nature but scrum is really more in that and lean startup actually shrinks it even further. So the basic PDC is still the same thing, a closed loop management that we are talking about. So what we said was in an adoption, what we are doing is the basic PDC loop is in place. People are able to inspect from their work products and they are able to take the feedback, take corrective actions as early as possible. Moving on to the next one, we said, you know what, efficiency is where people start measuring quantitative data to plan the goals, track the progress, improve the process efficiency. For example, something like velocity. So just to your question, if I go to these teams and say what is your velocity, they will think as if I have landed from Mars. They'll say what is velocity? I mean, we are here, we are down in the trenches, we are struggling with putting some of the basic stuff in place here. What are you talking about here? So we said it is going to be a horses for courses strategy. It's not going to be one size fit all. We are not going to have metrics which are going to be painted for everybody in the block. People will figure out at the level of maturity and they are deciding what state of maturity they are in. We are not deciding that. We are only facilitating their journey if they want to move from here to here. And finally the effectiveness part where we said they are basically able to, they are a highly effective closed loop process with the ability to make quick course correction and must now align their performance more clearly to the goals by constantly reviewing the current performance against the planned performance of the product against customers external definition of performance. Please understand. I can here get away by saying definition of done from my team standard is this. But this is where we are clearly putting the customer filter and saying, you know what? Your definition of done is not determined by the team. Your definition of done is determined by your customer. If your customer rejects the work product, that means it is not done. And that is where we are bringing the difference from an efficiency. And that level, so my question will be at a team at this level, they will say velocity. Velocity is a useless thing for me. I am much beyond that. For me velocity is just one of the things that is there. I am actually looking at, okay, if I did that, can I do? So my objective for this quarter is take my website traffic up from 20 million to 21 million. That's what I have. My objective is clear. I have to take my traffic up to 1 million. Do we have a high level expectations of what, what does it take for me to take that to 1 million? Okay, let's look at it. Some of the stories will emerge out of that collaboration discussion between the product owner and the team there. Let's do some hypothesis. Let's do some lean startup kind of a thinking and say, okay, can I do a AB testing there? Can I do what we call as bucket testing in Yau? Can I do something? Let me, I have a feeling that if I put this feature here, we might be able to get some more traffic here. Well, let's try that. We don't have a market data available to back that up. So why don't we do this way? Let's push it out and let's push it out to the, to the users in Koramangala and see whether the, whether the Yahoo users in Koramangala, do we see an uptake in the traffic? If I see an uptake in the traffic, is it statistically different or is it a seasonal variation that I'm seeing? If I'm able to establish a statistical uptake there, maybe that's a good thing. Why don't we look at the next bucket from 1% I go to a 5% bucket. Do I see the same pattern holding up there? If I see that, maybe I have a winner here and let me start working on it. So that's the way we are really looking at the effectiveness part of it. So what is the difference between moving from efficiency to effectiveness? Because I think that's, that's where we really are trying to lock it down.  And double loop learning comes from, from organization behavior basically, where we say in a single loop learning, we are basically looking at a cause and effect relationship in a very different way and say if I have the technique's goals, values and then the results and if there is a variation, I again come back and alter the technique and take the corrective action there. That is a single loop learning. In a double loop learning, I'm actually going and questioning my underlying assumptions and say, why do we do what we do? Here I'm only questioning what we do. Can we alter that and get some different results wherein in a double loop learning, I'm actually changing my filter. I'm changing my mental model and saying, hey, you know what? Why are we doing it this way? How about maybe the performance is not up to the expectation, but let's question the method. Why are we doing it this way? Maybe there is a better way of doing it. Who says this is the best way, right? So you are actually going. So this is basically Chris Arger's idea of double loop learning has been around for about 40, 50 years, but this is how I see really the teams can move from being simply efficient to effective because they are actually going back and questioning why are we really doing it in the first place? This is a sample names are raised, but this is how typically the ASAP dashboard comes and we have a monthly update on that, peripheral in my team. So he's basically, so basically what you see here is like every month we have this and then these are the various projects there and you see that some of the projects might start from being a red zone to, and purple is the color that we love and that's why purple is the pinnacle of that metrics thing there. So some of the teams might start from a red and go to yellow and then go to green and in some cases you might actually find that they have actually slipped back as well. Like in this, many of these cases they went down and the reason it happened was we realized that there were a lot of people in the green and purple zone and we said, you know what? It's getting too easy. Let's question that, let's apply double loop learning. Double loop learning does not mean that it has to be only for a fault analysis. A double loop learning should also happen when everything is going fine there. And you say, you know what? People are getting used to that. Let's raise the bar a little bit. So we actually went back and looked at our, we said our yard stick has to now go up because a lot of people are able to do those things. So what was too difficult to do at some point in time is too easy to do now. So let's take it. So that's how we, so you see some of them have fallen back from purple to green. It's not their fault but we are asking them to raise the bar. No, it's purely internal. So and then finally talking about the self sustaining piece of that. I'm almost coming to the end of it. Starting up is easy, sustaining is tough, continuous improvement is toughest. We believe purple zone is actually the starting point for continuous improvement. Purple zone is not the end for us. Purple zone is actually a signal that you know what? As people, as process, as feedback, mechanisms at multiple levels, we are ready to continuously improve now. We have everything that it takes. We have instrumentation in our software that allows us to look at the data points. We have instrumentation from a customer field perspective that we are able to get the data back and we have mechanism to flow that data back into our process and make those changes fast enough. So that is what purple zone means to us and that is why we look at it from a self sustaining phase. The strength of the process is only tested when you are operating in the real world. Now your definition of real world could be different from my definition but for my definition of real world is it is not a lab condition. It is not a synthetic condition. It is basically people will come and leave. People will, the reality of life for us is people, I mean we deal in a world where people will join. There will be attrition, there will be resignations. There will be people moving out there. There will be change in priorities. There will be change in organization direction. How are you still going to deal with all that while you are at 40,000 feet and cruising at 900 kilometers an hour? So that's really the whole deal here. Practices that bring results are likely to be sustainable over the prescription models. I think we forget that at times. We believe that if some guru or some thought leader or consultant coach and comes and does train the team and say you know what this is the way to go there. Now guess what? If end of the day the teams figure out a better way of getting the results, that's likely to be more acceptable within the team. And that's what we have to recognize that this is more self sustaining in nature. And finally it is really reaching that late stage of effectiveness because as you saw from the color coding there unless you really go to the point where team is able to demonstrate business results at that level do you think it's going to be sustainable because nothing succeeds like success. So if the team is able to say you know what we have come to a model where I can demonstrate success with every iteration or with every release or with every fourth iteration or whatever I'm releasing to the field that is going to be more self sustaining. So we believe that we don't have to incentivize people or put any scaffolds there. We are facilitating their own journey. It is their journey. They are the prime actors in that. We are playing a role in really helping them here. So let me just sum it up here. What are we learning from these things here? The first thing is credibility is extremely important. Today every bit of knowledge about agile, scrum, lean, Kanban, everything is available on the net. You read the same mails and blogs as I read. What makes me so special to really come and stand in front of you, take a high moral ground and say hey you know what do it this way. It's not going to work. If I am going to be a change leader who is going to change the organization by influence and not by authority there is no way it can work. So credibility is extremely important for me if I have to make any, if I have to bring any lasting change in the organization. Many people think that when we talk about scaling up the agile adoption, I am talking about bringing it across the organization 100% there. We don't look at it that way. Like you would have seen there, so what we did in the first year was when we started doing I said 150 projects. We said 50 projects are the one. We said it's okay. We don't really want to go 100% and do a shallow job at all 100% of that. We would rather take five of them, do a world class job and then go and sell that story to rest of the organization. So scalability to us does not mean that there has to be a parallel with 100% adoption in the teams. And like I said, results talk louder than the intent. So I could have anything I can come and talk about. It's the results that really are going to talk about that. So finally, what is it all about there? I think it's important for us to understand what is this really all about. So I just want to leave you with a short story. I hope that will be more entertaining than what my presentation was. So there's a famous, it's a nice anecdote that says a photographer went to a socialite party in New York. As he entered the front door, the host said, I simply love your pictures. They are wonderful. You must have a fantastic camera. Don't we all do that? We ask picture and say, hey, do you have a cannon? Do you have any, unlike your favorite camera, right? We all ask that. He said nothing until the dinner was finished and then said, what a wonderful dinner. You must have a terrific stove. Can you ever insult somebody more than that? I think we need to understand. And this is from Sam Haskins. Sam Haskins is a famous photographer. And so I think the key thing that's important is it's not about the method. What we need to recognize is the fact that agile is not a process change. It's a sociological change. It's a change that entails multiple, multiple teams and groups there. We are not talking about software as a process change. We are talking about the change from Taylor's way of doing management, what was there in scientific management 100 years back to what we want to do now. And that has to pick up all the moving parts and change them actually. So it's about the people end of the day. It's about the eye behind the camera. It's about the fingers that really operate the camera because there is a saying that says, the best thing between the photographer and a good picture is the camera. So I think that's the main thing there. What we need to acknowledge is how best we are really able to look at them. With that, I'm done with the presentation here. I am actually, if there are quick questions, I can take it. But if there is an immediate one, then we can probably go offline as well. Thank you.