 So, like my favorite cricketer Dhoni says, you get the toss, sometimes you win the toss, sometimes you lose the toss, we got the last talk of the day. So, I appreciate you all being here. When we, when I realized that we had the last talk of the day, we were like, what can we talk about that hasn't been covered in the last four days? What could be left? Right? And then, you know, it wasn't very difficult to arrive at something, which was, we can talk about our experience. That is something that's, none of you have, right? You have not been in a situation where me or KK have been. So, mostly what we're going to cover today is through our experience. We'll talk about some of our experiences that we have had. And since it's the last talk of the day, I will exaggerate my stance a little bit. I will say, no, this is wrong. Or I might say, this is bad. I don't really mean it. So, don't get mad at me. I don't mean all of it. I mean some of it. I know the truth lies somewhere in between. But I will tell you that these things are probably wrong and you shouldn't do it. Okay? We can talk about that. You can ask me about it. If the question, if the answers don't satisfy you, we can talk offline afterwards as well. Okay? So, I'm not going to explain what my talk is about. We're going to talk about, we'll see it as we go along. My name is Krishnan. I'm the founder of a startup called GeekTrust. I help developers find, good developers find, good opportunities. That's what we do. Before GeekTrust, I was with ThoughtWorks for close to 10 years. I worked as an agile consultant, project manager, delivery manager in the US, UK, Australia, and mostly in India. Over the last few months, I've been unlearning a lot of things that I've learned as to what agile means. When it's my own money, I'm very, very lean about it. I've unlearned a bunch of things. I'll share some of those as well today. Cool. I think few of you might already know me. I presented talk on Wednesday on the other room. My name is KK. Yeah, so that's how I entered the room. My name is KK. I've been with ThoughtWorks for the last six years. I've been with the IT industry for the last 11 years. My agile journey began when I joined a startup nine years ago. I haven't heard anything about agile until then. Even when we were doing the startup, we didn't know anything about agile. Think about it in retrospective. I thought that was the most agile team I've ever worked with. That's when I realized all these terms and all these practices and processes that we talk about, you could do without really learning if you really know what business value you want to add. That's me. In the last six years with ThoughtWorks, I've been working in multiple roles, primarily as a consultant, as a coach, as a business analyst and project manager lately. That's me. Can I just add something more? Sure. One thing I forgot to mention, our talk has three parts to it. The first part, we'll talk about the problem. The second part, we'll talk about why the problem exists. The third part, we won't offer you any solutions. Those are the three parts to our talk. Do you want to start? Cool. I want to start with a story. This is a real story. Something that happened when I was consulting with one of the organizations in South Africa. This is a large enterprise. They were dealing in financial instruments. They were building applications. The project I was on, they were building a shared trading application. If you ask the business, they had a lot of competitors in the market around the same time. One of their primary goal was to release as fast as they could and do incremental releases after that as frequently as possible. Kind of continuous delivery, again. That was a goal. This organization had deployed other agile teams in the other departments. These guys had an IT wing and they were running a few projects from their organization. They had recent experience with agile. They thought this would be a nice idea for them to put a team together and make this happen. They pulled in a bunch of developers from their IT team. They hired a brand new scrum master. He had certifications from a couple of certifications which did prove that he was a scrum master. A team was set up. When it came to processes, this was the team doing stand-ups. Over a period of time, eventually they understood a great deal about stand-ups. You have to do effective stand-ups. What kind of updates do help their team members? Again, during the sign-ups, they would make sure that the pair rotation happens and all of that. They were pretty sorted on the stand-up part. When it came to iterations, they would have a two-week iteration. They would spend around four hours every two weeks just planning for the iteration, throwing estimates, planning what they could do in the coming two iterations. They were sorted on that front too. The scrum master had experienced do all of this, and he facilitated this really well. That was a definite positive there. Come to the technical practices. They did understand a little bit about extreme programming, so they thought, okay, pairing is a nice idea. You get a real-time code review at any point in time. So pairing and refactoring, again, one thing that they took care of, again, something that really went well. Continuous integration, so they had a TDD unit test, functional test. And they thought, okay, continuous integration for feedback, quick feedback would help them. So they had this in place. So all the elements of agile showcases, they would showcase their software every two weeks to the business owner, and they would get sign-up. So all happy so far. To course correct themselves, they would do retrospectives again every month and figure out what went well, what didn't go well, how can we improve. All of that really happened. So all the elements, all the practices often agile project, right? So what was the outcome for business though, right? So if you see, they did everything they knew about agile. All the practices were followed right. But did the business really get what they want? So remember the earlier goal, they wanted to go live as soon as they can, right? But none of the team members really had focus on that. What they were focused on is getting TDD right, getting the stand-ups right, getting everything, all the practices and day-to-day routines and rituals right. And they got it right. But what did the business get out of it? So that got us thinking. Is this just one story? Probably not. So Krishnan is going to share another story, another experience that he had. So KK story far away Africa, you know, maybe when he went there it was a wrong time. So let's look at a story in India. I worked with a large US based MNC. They were doing showcases, check. Continuous integration, check. Stand-ups, check. Par-programming, check. It ticked all boxes. But if you ask them what was the goal, why were they doing this? Ask yourself. People who have been in part of agile teams are forced to be in part of agile teams. Why? Why was agile introduced in your organization? Why did your teams adopt agile? To whom did it matter? This is a real question I'm asking you guys. In your teams, why did you pick agile? Why did you choose to do agile? Client was asking, I've heard that before. What else? Time to market, very good. But the thing was, in my experience, ten years I've worked as mostly a consultant working with multiple teams. If you ask people in the team, why? They don't have an answer. Most teams didn't know why. Why were they trying to do agile? Now the question is, is that important? So we came to realize one thing. We came to realize that agility, the word itself, has lost the meaning that was intended. Agility and agile became about adopting certain practices and processes. That became the goal in itself. It was not about why we wanted to achieve something. What was the business goal there? How were we impacting the customer's business? It was about adopting something. Again, when I think about it, there was another company that I worked with, this time a French company. I spent three hours with them understanding their challenges. They called me in to see how we can adopt agile. Same question that I asked them, why do you want to be agile? Because we've got an order from a French HQ that we need to be agile. That was the reason. Like you were saying, the client asked us to be agile. That was the reason. So I came to realize that we are getting very, very good at implementing certain processes and practices. How many of you have been part of stand-ups? Showcases? Being part of sprint planning meetings? We are very good at it now. This wasn't the case six years ago when I started talking about agile. A lot of people didn't know how to do stand-ups well. Didn't know how to do showcases, didn't see the value in showcases. So the point, the problem that we are starting to introduce here is we are getting good at something. And what we are getting good at is the ability to implement agile practices. I think we have reached a point where we are fairly decent at it. And our talk today, what we are challenging you is that's not good enough. Nobody gives a damn. We are so used to this model of let's somehow implement agile, that we have forgotten what it means to be really agile. If you can do stand-ups, you can do showcases, you can pair program. Unless there is value to your customers or your client or their business, it really does not matter. And this slide which talks about our successes or failure. When we talk about agile, a lot of the principles, values that I think are important are building quality in your software or having transparency in your processes. Why does that matter? Why does quality, why does discipline, why does transparency, why does that matter? So that we can deliver better value to our customers. That is why discipline matters, that is why getting the processes right matters. But we have forgotten that. What the my takers, our takers, the industry as a whole have come to a point, and I'm talking specifically about the Indian industry because that's what I've worked mostly in, we value these processes in itself. That is the end goal. Being process agile has become the end goal for us. Anybody agrees? Anybody disagrees? So there is value in process agility. That is absolutely value in process agility. I'll talk about that later. But my challenge and my question is, we can do a lot more. By being process agile, are we allowing our software developers, our software engineers to be creative? Are we allowing them to be really fulfilled their potential? Are we doing that by being really process agile? So that is the question that we wanted to answer, that we wanted to tackle today. Process agility, definitely, we have been there, done that. We have tried out different things and it works and we have got it. Don't stop here. Just checking if I've missed something. So it's got to a point where the problem statement that we have is, hey, Krishnan, can you help me out? I need to get CI implemented. That's what we want to do. I want to write good stories. That's absolutely not a goal in itself. I don't think so. But I know I can understand where some of you can feel that these big, big, big IT shops, this is important. That IT firms, big, big enterprises having process agility. If that brings discipline, that is important for me. Can I ask you why you disagree? Exactly. Great point. So partly I agree with you, but my challenge again is don't stop there. This is the most tangible part of agile. That is why it is easy. It is not easy to do. That is why it is possible to do. But my challenge is don't stop there. Process agility is touchy. You can really touch it. You can hold it. You need to do this. You need 85% test coverage, but we need to go beyond. And if you think that process agility is enough in an enterprise, I tell you it's not. I have worked with a lot of large enterprises in my time at ThoughtWorks and I know that even large enterprises, large IT shops, multi-billion-dollar US firms who have their IT centers in India, they can do more. Absolutely they can do more. And two, this is a problem, not just in startups. And I'll hand over to KK to talk about the next. Sure. So we're coming to the last part of the first part of the question. So like Krishna mentioned, this is not just in enterprises, right? Might be surprised. I was surprised when I first dealt with one of the startups who came to us with their problem statement. So I'll talk about this really quickly. So there was this startup who were in the market for almost a year. And you could say that they were sustaining by something that we would call a cowboy approach. So they were doing all the practices right. So they would have a stand-up, this kind of status update to the stakeholders. They would have a CI which would be mostly red and no one would care about. Or functional test automation, which would not run on a continuous basis, but run once in two days. So again, all the elements of Achilles would be there. But when these guys had to scale, and scale really big, right? They came to us and said, how are we going to scale? Because we see that there are these practices. There is a perception of being Achilles, but we're worried that this might not work. And we share the same worry. And when we went and analyzed, right, this is what we found that all the practices, though are very bookish and does sound very Achilles, is not solving any real problem. The other thing is, when these guys wanted to scale, is concentrating on bettering their process, was that important or was it important for us to focus on the end business goal? And see, this is the end business goal. How do we achieve it? Maybe all that they were doing, we might, we could have crashed that and said that, hey, this is not the way you should go. Maybe we should rethink our strategy here. So the bottom line is this problem, right? There are different flavors to this problem. Don't happen only with enterprises. This can happen with startups too, right? And then there is a whole segment of other industries between startup and enterprises like mid-level and smaller teams or medium teams, right? And it can happen with those people too. It's a common problem in our experience, right? So think about this. Is agile adding enough value? Can someone remind me of the first principle of agile? Anyone? So not from the manifesto, but one of the 12 principles of agile. So the top, absolutely. Right, so highest priority is to satisfy customers through continuous and valuable delivery of software. Are we really living up to that principle? So that's the question. Are we really living up to that? Or we are always inward looking and say, we have done this process and this process and this process and this process. We are agile. Okay, what did the business get out of it? And that's the question that we're trying to address. So this is the second part that we want to talk about. Yeah. So to be a bit more specific, I worked with one of the Indian startups, one of the larger ones, and the problem was scale. Now, how does agile help them? Any suggestions? They want to scale, right? They're in Bangalore now. They want to scale to 12 other cities in India. And they come to us and say, okay, we want you guys to help us out. What do you do? How do we fit agile? What do we do with agile and this problem statement? Does agile even have a part to play there? Put yourself in the shoes of a consultant who's gone there and say, hey guys, we are an Indian startup. We have done coding so far. We've got some things here. This won't scale. We know this won't scale. This has been held together by glue and faith so far. I know this won't scale. When I go to Jaipur, this won't scale. When I go to Chennai, this won't scale. So as an agile consultant, as an agile coach, as an agile team member, what do you do? How do you solve this problem? Can you solve this problem? Is there anything in agile that helps you solve this problem? So let's worry about the software a bit. Let's worry about being able to... But you need to handle the volume, okay? Right. Yep, fair enough. It depends on the what? Sorry? Okay, can I ask a simple question then? We have talked about... Sorry, you have a point to make? How can agile help this company scale? How can you as an agile consultant go into the situation and say, hey, this is what we should do? What would you do? Tell me one thing. Anybody? Yes. Okay? Okay, so tell me one agile principle practice technique that you say, hey, this team should probably think about it. Did I not be right or wrong? Just tell me what you would start with. So, yeah. Okay. Great point. So you're saying empowered teams, autonomous teams, which have a clear goal, like individuals and interactions, value that. That is something that this... Anything else? What else? Yes. You can validate the growth hypothesis by doing small experiments, having smaller stories, testing it out, getting it out to production, et cetera. Awesome. So this is what I mean. These are the sort of challenges I think we are not taking head on. We would much rather get CI implemented, get our developers to write more unit tests, get, you know, do more stand-ups, put a VC in place. Whereas these are the challenges I think we have a place to play to solve this. And as the Indian startup industry grows, as we tackle more business problems, move to products, move away from services, these are the sort of things I think we as agile practitioners can impart, can do. So my ask to all of you is, I don't know how to fix this, okay, we have no idea. So KK and I are just making most things up after these slides. This was the problem statement. I want to ensure that you all agree with us that there is a problem and that we can do more. And all of you at some point in time will be in a situation where you will be able to influence it. If not today, tomorrow. At that time, do be bold. Do think, can I do more with this? It is not about, is my QA writing in a functional test. That probably has value, but we need to step back. And I think, how do we fix this? Some of you have already covered bits of it, but I'll come to, I'll look at it. This is what we thought we should do. So KK and I, I'm going to tell the story KK. So KK and I were working on this yesterday evening. So in the morning, we didn't have any pictures. There were no pictures here at all. In the morning, I wake up and I go through the slides and I see a hen on my Y agile slide. Any idea why this, I'm going to call it a hen. Any idea why this hen is here? Okay, why is this chicken here? Yes, cross the road. So KK thought, why did the chicken cross the road and Y agile had some links? So he put the chicken up there. Anyway, so what we are suggesting in terms of how do we fix this is going back to what I said first. Why do you want to be agile? Why does your team want to be agile? So any of you, any of you in this room, have you been part of an agile transformation? That is, you were working in a non agile mode. And then you guys, your team decided that you want to be agile. Yeah, why? Why did your team decide to do that? Decision from senior management. Yeah, agile will increase my productivity, reduce my inefficiency. And we'll get some people fired. My operational costs will come down. Sure, great. Yeah, yep. So you decided to be agile for, okay, we wanted to make an improvement to how things are. Who else has been part of an agile transformation? Yes, why did your team late night calls? Speed to market. Okay. Okay. And maybe low attrition at some point. Okay. So our suggestion is step one, be clear why you are being agile, why you want to be agile. And it is not enough that the senior management is clear why you want to be agile. For teams to be really agile, I think it is important that we concentrate on building strong teams. We don't do enough of that period. I've worked with too many companies, large and small, that they don't worry about building strong teams. And in my opinion, this is just my opinion, how do I go about building strong teams? Teams need context, teams need vision. And if I were to be in charge of an agile transformation program, I'll make it clear to the team why we are being agile. And based on KKS and my interpretation, there are three reasons why people want to be agile, are teams want to be agile or companies want to be agile. There might be more, but we could find only three. Thank you. Number one and the most popular one is engineering rigor, which is to say I've got a screwed up code base. I don't have any unit tests. My teams, I have 5,000 bugs when I go to production. I want to bring it down to 25. It's a very common problem statement. The 5,025 is not a joke. I heard that from a client that I worked with. I did, actually. Not 25, but much less than 5,000. But engineering rigor. Everybody, I'm reasonably certain most of you agree with this, that this is something that you have also seen. We want to build more discipline. I want to be able to push to production without breaking all other features. Right? And, sorry, was that a question? Yeah, so engineering rigor is definitely one of the reasons why people want to be agile. In my ratings, I would say this is the lowest rating. Because yeah, you should probably be agile for this. Great. But yeah, this is not my top preferred reason of why you should be agile. Because the impact your end customer may not be as much. I've heard business telling IT that don't worry about impact to business. You guys just get your processes right. I can watch you better when you're doing agile. It's easier to track what you guys are doing. And they push agile. And they were supposed to release, they go live once a year. Let's do agile and let's push to production every month. So we consulted with them. We worked with them. We put all these practices in place. And they said, no, it's okay. We'll still go live after one year. So we did all of that engineering rigor for, there was no end impact to that, to their business or to their customers. Second reason is speed. Can anybody take a stab at explaining this? Why does, what's the link between agile and speed? I think this gentleman here already touched upon it. You want to validate something quickly. I'm running a startup. For me, this is important. I want to validate my idea quickly. It's about being able to put something out there. What's the next one? Quick feedback. Okay. So, sorry. I'm going to come back to quick feedback. When I meant speed, it is not what I said earlier. Ignore what I said earlier. Just rub that out. When I meant speed, it is you have a validated idea and you want to take it to market extremely quickly. The example I quoted earlier of that particular startup, they know it's working in Bangalore, right? They want to try it out. And they want to now quickly go to other markets, right? And to be honest with you, we struggled with it. We don't know how to help them. They came to us and said, we want to take it to so many different markets, so many different areas. Our code base sucks. Let's start from scratch. We'll do this. We'll do that. We're not sure how we could help them do this. Because what they wanted to do was speed. And all our processes are tuned towards building value one, which is engineering rigor. We know how to do engineering rigor agile. But when we say we want to build speed, we are not very sure how to do it. Can I just look at my notes quickly? Sorry. The third one is quick feedback, which is I want to test out this idea. I want to get it to market quickly and I want to change. These are the three reasons why we think agile matters. Engineering rigor, speed, and quick feedback. Any other ideas? Any other thoughts? You think we have missed something? Anything else that you guys can think of? Yes. Sure. Well, I think what you need to say is, you can fail as long as you fail fast and learn from it and fix and course correct. So I think one of the principles if you say, again, all this quick feedback and all the CI we have, it's okay if your CI goes red in a broader context. It's okay if you fail, but as long as you learn from it and you fix, as long as you don't lose the focus on the business value, I think you're good. Absolutely. And my next slide. So step one was why agile? Be clear why you're being agile. And there are three reasons why you should be agile. Step two is what agile? What are you going to pick? Here is where I think your point also comes in. What are the practices, principles, principles, values that I need to inculcate in my team? What are the things that we need to try out? There are a plethora of things out there. I can't possibly pick all of them. It's not possible. It's not even worth it. So what will I pick? And in my humble opinion, this is where the role of a agile coach or a scrum master comes in. And believe me, you cannot, I don't mean to offend anybody, you cannot do this without having expertise. You cannot understand what the problem is, what the business goal is, and then choose the tools to say, okay, let's do this as an agile team. Let's try out these three processes, these three practices. I don't care about these two. That to my mind is a role of an agile coach and a scrum master. It cannot be somebody who's, you know, just dabbling in this part time and then say, okay, let me do this. It could be, but then it'll be a long learning curve. This is where your scrum expertise, the agile coaches should step in and say, this is what the team is trying to do. This is the reason why they're being agile. This is my strength of the team. These are the weaknesses, and this is how we will approach it. Because people still need some sort of a mental model as to how we will deliver software. So this is what the agile coach or the scrum master should be doing. Select from all of this, understand the current situation, the current business goal, understand the weaknesses and strengths of the team, select the processes. So you've got your step one, why you want to be agile. Step two, what are the agile practices that you want to do? And step three, agile, agile. It's kind of a recursion. So how many of you have heard of this term called BDUF? Can you explain what that is? So bingo. Sorry, you was going to say something. Absolutely, right? So we all understand and we value emergent design over big design up front, right? And we know that if we do big design up front, it's not going to work at a technical level. Also, right? And there'll be a lot of changes that you need to know. How about applying the same principle to agile? Don't build your agile up front. Day one, let's say you have had experience on one of the agile projects and say, today I'm going to a new project. I'm going to copy paste the entire processes, practices, all the rituals on this project and say, hey, I'm agile now. You can't do that. How about empowering your team and let the agile evolve? I think that's the primary key to this, right? That's the key to this. The other thing is, right, one of the principles that we again believe in when it comes to, let's say, as simple as in the agile manifesto, we say that we know we value individuals and interactions over processes and tools, right? And if we let ourselves stick to the same agile throughout and we are just stuck to the same processes, then we are mooting this very point wherein we are just stuck to the processes. And the entire purpose of agile is defeated. So that's our three-step approach. You understand why you want to be agile and empower your teams. And every team member should know why we are being agile and what is our end business goal. You pick based on your context and based on the situation and based on what makes sense at that point in time and be agile with your agile. Bring in agility to your agility and make sure that you course correct your agile when you figure that something is going wrong. That brings us to the end. This might as well be one of the last frames from 70 Hindi movies, but this is cliched stuff. But anyways, to summarize, right, I think we have outlived process agility. We have done process agility. We have succeeded in most of the projects. But I think it's time for us to really get our heads up and see what is beyond, what is more, what is the real business problem that we are solving, and we should focus on that. So I think that's where we end today. Thanks. Any questions?