 We're going to No Man's Land. And the No Man's Land is very uncomfortable. And it's not very welcoming, which is where Agile started. And I think we've gone 180 degrees back to what originally the problem Agile was trying to solve. Was anyone here in 2014 when we had Dave Thomas do his talk? Dave Thomas was one of the guys who wrote the Agile manifesto. Since he wrote the Agile manifesto, he never went to a single Agile conference because he said that was the end of Agile for him. And I played and I literally went and fell on his door steps. And I said, we really want to hear your perspective. And he had some very interesting insights into on similar lines. So I'm going to try and build up on that and some of my own thoughts. I'm going to make a statement, a very strong statement. And then I'm going to spend the rest 45 minutes trying to defend that statement. That's the statement I've already made. If you're using Agile in this day and age, I think you're really, really late to the game. We'll talk about what that means, but that's a statement I'm going to make, and I'm going to defend that for the next 45 minutes. Every single person here, I believe, has read the Agile manifesto, knows word to word what's in the Agile manifesto. That's a safe assumption to make. All right, perfect. If you were to summarize in one line what Agile is really all about, what would that be? I want you to think about for a minute, right? Manifesto is great. There are lots of different Agile methods that have come out. A lot of frameworks that have come out. There's a lot of interesting stuff that's happening out there, but what does Agile mean to you? If you were to think about it in a word, in a phrase, a line, just think to yourself. You don't need to tell anybody else. Just kind of go through this zen moment of self-realization. Everyone's got in their head what they think of Agile. Yeah? To me, Agile was and is about embracing uncertainty. How many people read Ken Beck's white book which came out about extreme programming? What was the subtitle of the book? Embrace Uncertainty. Yeah? Does that make any sense? The first time I read that book I was like, yeah, I mean like so what, right? And now when I revisit the book, I'm like, yeah, so what? It's obvious, right? But there's been a time when I went and I went crazy about extreme programming and a lot of other methods. And I kind of came to realize that the origins of Agile were very deeply rooted in antifragile thinking. I'll define these terms in a minute, but I think Agile was about embracing uncertainty and change via simplicity. Those things are important. And the roots were very antifragile. Over the period of time, I think Agile has just become extremely fragile. What are these terms I'm throwing at you? Antifragile, fragile, right? These terms come from Thalib's last book which is antifragile. He defines three terms in his book or I mean there are a lot of other things he does, but there are three terms that he defines in his book. One is fragile, robust and resilient, and then antifragile. If you were to ask anyone, what's the opposite of fragile? People would say robust or resilient, right? That's the opposite of fragile. It's actually not. And we'll look at what that means, right? Everyone understands what antifragile is. Sorry, what fragile is, before we jump to antifragile, right? Easily broken or damaged by applying stress. They're built for a particular use case. If you try and apply, if you try and use it in a different use case, they become really vulnerable to break down, right? That's when we say this is fragile. If you're shipping something with wine glasses is what he talks about in his book, then you would ask the person at the airport counter to put a tag on it saying fragile, right? Handle with care, because if the glass works beautifully as long as you're pouring wine in it or beer in it and drinking, but if you're gonna take and try and play drums with it, good luck, right? It's not meant for that. So that's basically fragile. Let's quickly look at the properties of what fragile is. Can anyone tell me what are the properties of fragile from what you've seen so far, what do you understand so far? I want this to be interactive, because I get bored talking to myself. Delicate, easy to break, highly constrained, difficult to put together back. Cool? Let's quickly run through. One of the main things about what defines a fragile system in general, something that's fragile, a fragile system, is it dislikes variability? It dislikes stress, right? This could be any form of variability or stress. It seeks to eliminate noise, variability, tension. That's what these systems try to do. Things that we say are fragile systems that try to seek to eliminate these things. They are kind of very driven by consistency and standardization. It works for a particular use case and it's standardized for that particular use case and it's very consistency and standardization driven. Overly optimized for a specific use case. Works beautifully for one use case, try to use it for something else, ain't gonna work, but very beautifully optimized for one, right? That's how you drive consistency by optimizing it for a specific use case. And the way you optimize is to optimize, you need to have some amount of prediction. You need to figure out what is the likely use of this, how people will use it. You need to plan things based on that and then you build something that's highly optimized, right? And that's where it is very prediction based. You have to predict how it's gonna be used. People didn't think people would use glasses for playing drums, right? Hence it's fragile. And typically they are large, right? Systems that are fragile are typically large. You can take any large governments, large companies, they are typically very fragile because they're optimized for a particular use case, they're optimized for a particular problem, they are highly prediction based and they seek to eliminate noise variability and stuff like that. That's very quick rundown of what fragile is. Does everyone agree with this definition of fragile? Yes, no? Cool. What's resilient then? Resilient is basically the ability to withstand or recover from a particular distortion or of a different form to come back to its original shape, right? An example that all of you might be very familiar and it's easy to explain is our whole infrastructure deployment is very resilient. How is it very resilient? For example, here in the slide, we've put a load balancer or a reverse proxy in front of a bunch of servers and any time a server goes down, it's okay because it's just gonna balance the thing and it's gonna come back up and the system is gonna be resilient, it's gonna stay up and keep running, right? So we say this system is very resilient, right? This is what we mean by resilient, coming back to its original shape, being able to withstand stress. Fragile systems, so a fragile version of this would have been just one server and server goes down and the service is down. So we say this is services fragile. You make it robust by putting a bunch of servers and some kind of a reverse proxy, some kind of a load balancer. What's anti-fragile then? So we understand fragile, we understand resilient, yeah? What's anti-fragile? Anti-fragile is basically systems that gain from disorder. They don't only just come back to their original shape, maybe they never come back to their original shape, but the important thing is they actually gain from stress, they gain from randomness, they gain from chaos, they gain from uncertainty. They thrive on complexity and ambiguity. Is anyone, can anyone give me an example of a system that's anti-fragile, that gains, that doesn't try to resist, but actually gains from uncertainty? Of a brain, beautiful, you jumped already, man. What happens if you start using a calculator to do simple maths? Then it becomes more and more difficult to do simple single digit multiplications as well. Anyone's experienced that? And the more you practice, the more you put stress on, the more the better your ability to actually do calculations. My previous startup, failed startup, was about helping kids get better at mental arithmetic. We had kids who could calculate faster than a calculator, 200 calculations per second, literally at that speed. And this is about putting a lot of stress on them and they're able to cope up with it. They get better with stress. If you go to a gym and work out, what are you doing? You're basically tearing your muscles. You're tearing your muscles so that your muscles build back much stronger than they were before. You're putting stress, you're damaging something so that it becomes stronger. So this is leveraging something that is actually causing damage to you. Of course, in certain thresholds, there are thresholds for all of these things. But within those thresholds, they actually leverage the stress. They leverage the pressure that is put on it. Imagine these buddies who are going on a one month tour. They've packed every single thing that they need on the tour. And they've planned exactly what the itinerary will look like. What do you think their holiday would look like? Very safe, as in the scaled agile safe or the actual safe. Compare this to these guys. Has anyone ever tried to plan a complete trip with exactly 15 minutes break between one activity to another activity, dot to dot plan, and then executed that? It's not a vacation. But some people think that's a vacation. Everything has to go as per the plan. But there are some people who believe that I wanna actually go with the flow. Let me get there, figure out what's happening. I'll take advantage of that and I will do the best I can with the given options I will have when I arrive there. And that's a different kind of, that's like a hitchhiking kind of a trip, right? And so to me, the first one is a very fragile example of planning something, while the second one is a very anti-fragile way of planning something. Let's kind of talk about something more realistic, right? Venture capitalist. Typical venture capitalist puts money in 10 startups, expecting that nine will make a loss. But one will give an exponential benefit, right? So there's a constant small loss. They make consistently for an exponential return on one of them, right? So venture capitalist in my opinion are a wonderful example of being anti-fragile. They leverage the uncertainty. They don't know which of these ideas will click. But let me put something in each of these, expecting that 90% of them will blow up in your face. But that one 10% that will actually work is gonna give me 200, 300 X return, which is well worth the other 90% gone for a toss, right? So this is an example of again, anti-fragile. I shouldn't be putting this slide up, but this is again another example of anti-fragile. You try and bring them down, they become more stronger. You try and talk a lot about them, they gain more publicity, they become more stronger, right? So this is again an example of something which is anti-fragile. They leverage you trying to destroy them. And they've come back in things that you never expected. They leverage that uncertainty that exists, right? So with these examples, let's talk about what are the properties of anti-fragile. I'm going a little theoretical to get the foundations put in place and then we'll switch to agile and we'll kind of deep dive into what it means in the agile context. So from what you've seen in the examples, what are the properties of an anti-fragile system? Adoptive situations, adoptive situations of be adaptive, benefits, being opportunistic, okay? You put stress and actually leverage stress. You use it as a stimulus to actually get better. Adversity makes them strong, right? This is very different from robust. This is very different from robust. This is very different from, this is kind of taking advantage of uncertainty. So if you were to actually look at it, they build layers of redundancy. They build layers of redundancy to create localized impact. This is basically achieved through decentralization and through building buffers and inventory, exact opposite of jit, just in time. This is about building inventory. This is about having layers of fact built in so that when you have a black swan moment, when you have something unexpected happen, you actually take advantage of it. They dislike consistency and standardization because consistency and standardization are prediction-based and this model does not work in a prediction-based system. They believe in less is more, as small is beautiful. That's kind of the mantra. So something that's very small is ideally more anti-fragile than something that's large, right? Encourages optionality. This is a very important point. It encourages optionality by differing things to the last responsible moment. By differing things to the last responsible moment, you can be more opportunistic. You can take advantage of something that you had not planned before, right? So this is about encouraging optionality, disliking prediction, and finally it's about safe fail experimentation. It's about fail frequently. Failing is important here, unlike what we think, right? Failing is actually important. Failing is an important part of an anti-fragile system. If you're not failing, then you don't know what state you are in, right? So you fail frequently, you fail safely, and you fail diversely, which means every time you fail, you fail for a different reason. These are kind of in a nutshell what I believe are the core properties of anti-fragile. If you were to actually take this and think about the original motivations behind agile, what do you think? The sense, and the resilient things go, because they just kind of bounce around. But even resilient things need to sense, because if a server is down, they need to monitor that, they need to figure that out and bring it up again. Actually, anti-fragile, in my opinion, you don't need to sense. This is where I think action precedes clarity. You do something and you figure out what happened later, right? This fits into the more of the complex adaptive systems thinking, where you probe the system, you sense what's happened, and then you respond, right? If you were to take each point by point, I'll guarantee you agile will score 100 on 100. Agile, what it originally meant, not the bastardization of agile today, right? If you talk about the layers of redundancy, how do we achieve layers of redundancy? The whole concept of cross-functional teams, right? You have all the roles repeated in every team. That's a way of creating a localized impact. That's a way of building that redundancy, so they are kind of self-managed, self-controlled, right? If you talk about dislike consistency and standardization, we say, we talk about each group figuring out what works for them, and basically having an overall alignment, but within that, they can do whatever they want to do, right, so it's a very anti-standardization or consistency kind of an approach. That was the original intent. If you read the first line of the manifesto, it says, people and interaction over processes and tools. Let people and the groups figure out what works for them, and let's not try and standardize something that works for everyone, because there is no such thing that works for everyone, right? If we talk about less is more, there's a lot of philosophy of, so if you've read the manifesto, there is a simplicity thing which talks about maximizing the amount of work not done. It's about doing less. It's about less is more. Optionality, how do we encourage optionality? Do we commit to the entire release right at the beginning? Ideally we don't, because we work on small iterations. When we get there, we figure out what is the new information we have, what do we decide, what do we do next from there, right? So you are building in optionality at every small cycle that you do. In fact, you're building optionality at a daily level. You're building optionality at every small task level. So there's a lot of optionality that's been built. Dislikes prediction, so the whole idea around story points and moving away from velocity-based systems was, or the whole no estimation approach, was all about disliking prediction. And safe fail experimentation. If you did an iteration, you blew up. It's absolutely fine. It's a safe fail experiment. You do another iteration. Hopefully you will go in the right direction, right? That's correct. What original statement I made is the origins, the roots, where from an antifragile thinking, right? And next I want to dedicate a lot of time talking about why this is not true anymore, where we are kind of going in a wrong direction in my opinion, right? So quick commercial break. My name is Nareesh Jain. I live in Mumbai. Don't act yet in Bollywood someday. I was a partner at a company called Industrial Logic. We built eLearning. After that I started another company called Adventure Labs where we built games for kids to learn mental arithmetic. Did a bunch of other random stuff. I started the agile movement here. Been running a bunch of other conferences. My latest startup is ConfinGen. We're building a platform or a marketplace for conferences. As we speak, I'm actually a consultant at Hike. I'm a messenger. I'm helping them with the product engineering. Basically kind of figuring out some of the antifragile thinking how we can bring into Hike messenger. That's kind of what I do in my daytime job. And that brings us back to the original topic. Over the years, in my opinion, agile has become very fragile. We're gonna talk about 10 points specifically. It's a long list. I can rant for the rest of the evening, but I'm gonna focus on 10 top most important points in my opinion that's making agile very fragile. And I'll talk about what is the antifragile way of thinking about it, right? So you'll have some takeaways at the end of it. I want you to take a minute and write down, in your opinion, what's the biggest problem with agile today? Agile has no problems, is a perfectly acceptable answer. But I'm hoping that you would actually have figured out some things that are actually not working very well. And anytime someone says it's not the agile's problem, it's people's problem, ask them to please go read the manifesto. This is no such thing like people's problem. That was the point about agile. I want you to write down the points so that as we go through my list of 10, I want to see how many people have experienced one of those, right? So it'll be a good way to kind of check for me. Am I completely off track, living in my own world under the rock, or are there actually many people who have the same thing? Is like that slide, right? Reassuring life, life. All right, I have 20 minutes to go, so I'm gonna jump ahead. My first stop it, stop doing this, is this whole nonsense with story points and velocity. Total fucking disaster. Fundamentally flawed. The guy who came up with it discarded it, the rest of the community seems to be going running crazy with it, right? It's fundamentally flawed. Why do I make the statement that it's fundamentally flawed? Total silence. I've touched someone's nerves over there. It's not just about prediction. It's fundamentally flawed. Let me talk about the story of why this is fundamentally flawed. How do we, what was the thinking behind story points? The thinking behind story points is effort estimation is very hard, it's very people dependent, and we can't do effort estimation. So what are we gonna do instead is we're gonna do relative size estimate, right? That's the whole idea behind story point. So we are good as humans. If I were to ask you which one is longer, without a second thought, every single person who's seen in this room would say this is longer. If I asked you how many centimeters, you'd take a guess. But you're not taking a guess here, right? So we're good at relative estimates. We're really bad at absolute sizing, right? That was the thought process behind story points, right? And the reason we chose Fibonacci series are a non-linear sequence for story points was because you cannot apply arithmetic on it. The reason we chose a non-linear scale is because you cannot apply arithmetic on it. Something that's a two point story does not mean it's two times more effort than one, right? Clear? And then how do we calculate velocity? At the number of story points, oops, wait, add, is there arithmetic? You just said story points, the whole point was a non-linear scale, you can't apply arithmetic, and then you just turned around and said velocity is the total of all the story points delivered in one sprint. Something seems to be fundamentally wrong over here. No one seems to agree with me, I'm gonna go on, but it's a total disaster. And story points and velocity are so much focused around output, they don't care about outcomes. Why do I care about output? You deliver 20 story points, what does it mean? Means nothing. What was the original sinking behind agile, right? Customer value. Is story points customer value? I'm saying story points is fundamentally flawed. I don't think so. Story points are calculated at the end of the sprint or end of the iteration, not when you actually push something into production and when you get real feedback from users. They're two completely different things. So story points are calculated when the team says I am done and it's verified and we are saying it's ready. It's potentially shippable increment, but it's not shipped in the hands of users and they're loving it. There's a big difference between the two. I've worked on enough agile teams from 2001 to tell you how many times we thought this is potentially a shippable increment that will delight customers and it did not, right? There's a big difference between the two. So let's not fool ourselves saying something that is story points complete is agile business value, it's not. Axial business value is when people use it, they realize it, right? One of the typical challenges as a product company a lot of us face is 87% of the features that we build are rarely or never used. Sure, your company can decide that what is valuable and to whom it's valuable. All I'm saying is value has to be looked at when actual it's consumed, not when a team says it's done. That's absolutely. Up to your team, what it makes sense to them, but all I'm saying is that you, I mean as a team you decide what value is for you guys and measure value when actual people are using it, not when the team says we are done, right? There's a big difference between the two. That's all I'm saying, okay? I'm gonna, sorry, cut off because I have 10 points to make. I know this is the most uncomfortable topic to bring up but I have nine other equally uncomfortable topics to bring up. If you've not read Velocity's Killing Agility, please go read that. It's a beautiful article. It's by Jim Heismith. He's one of the person who wrote the Agile Manifesto and he will explain a lot of viewpoints on why he thinks velocity is killing agility. The way I think you need to deal with this, which is more of an anti-fragile way of thinking about it, is forget your estimations, forget what the team feels, ship it to the customers. Get the customers to use it and then say whether it actually added value or not, right? Now, for different companies, this could mean different things. I'm not trying to generalize saying every single company should be shipping to production every single hour. That's up to your context but you need to figure out what works in terms of what should be your feedback cycle. What's your market cadence? How quickly you need to get. At hike, we cannot push something into production every two days even if it's ready because it'll burn the data packs of the users that are using the apps. So we can't do that. So for us, a market cadence is slightly different. We've figured out ways to work around that but what we are focusing on is let's get it to 0.5% of the users in the 100 million users that we have. Let's measure what was our hypothesis and whether our hypothesis is met or not, right? And that's when we will say value is delivered and we will decide that, okay, from 0.5, we're gonna roll it out to 1%, 5%, 20%, 100% of the users. That's what I mean by this thing and we've completely done the companies. About eight years, I've not done any estimates and I've actually been successfully delivering products. So I think this is something we can kind of focus on. The next point, I'm gonna try and move little quickly. The next point I had here which was kind of an interesting visual, it was the definition of done. There it is, at least on my monitor. Definition of done, definition of done. Blank, it's given up on me. I have seen definition of done on Scrum Alliance website on a bunch of other websites and I was like, really? Like wow, this is amazing. A developer needs to be told that they need to write code for definition of done and a developer needs to be told that they need to check in code. Only then it's done. I am afraid we are hiring people off the street. Like who are we building this definition of done for? Definition of done is not when the team says I am done and I have this checklist and I've checked off all of these things. Definition of done, again, as I was saying earlier, is when you actually put it in hands of customers and you see them use it. That's definition of done, right? You can have a fancy elaborate checklist of things that are done. It means nothing. So stop focusing on that. Instead build, have built pipelines and have safe rollout strategies and that's the antifragile way of thinking. Like let's just get this as quickly as possible to people, to get it into hands of people. Let's not waste our time thinking about what is definition of done. If we have to do that, I think we have a fundamental problem we've hired monkeys off street and we're not gonna build awesome products with that. This comes from another famous website. This talks about all the ceremonies and the process you need to be successful with Scrum. How many people here had written down in the problems that they get hardly any time to actually do real work now? Few people. Where is all the time going? Ceremonies. It's all the beautiful how they chose the word ceremonies. And I love it. Throw away practices. I keep telling people, challenge yourself. Throw away training wheels. Training wheels are only meant for a two-day class. Once you're done with the two-day class, throw away the training wheels. They are not meant for real life, right? Throwing away things, reducing your downside is actually the most antifragile way of thinking about it. I stopped doing test-driven development. I don't write tests. If you've used Confingene, we've done over three crores of transaction. Not a single penny is lost, but that entire system has zero automated tests. It was a challenge I took to myself saying, what happens if I throw away test-driven development? I've been teaching people how to do test-driven development for 10 years. And I took a challenge saying, what happens if I stop writing automated tests? And to my surprise, I found that when I stopped writing tests, suddenly I felt I have lost the safety net. I had off-test around me. So what do I do? No, I try to simplify things. I don't try to complicate things. With test-driven development, I could get away with complexity. Now I can't afford to. So it really made me think of how to simplify things. It really made me, oops, throw away code. It really made me do certain things that otherwise I wouldn't do. Fourth thing, collaboration amplified. I actually have a whole talk tomorrow. Tomorrow's keynote I'm gonna be doing on this topic. I'm gonna talk about why one of the biggest problems in agile today to me is the amplification of collaboration. And what do we even mean by collaboration? I think we've kind of lost account because everything has to be collaborative. People have to go to bathrooms collaboratively. Everything has to be collaboratively. I think this is a total disaster because solo deep thinking and autonomy is so much more important than collaboration. And I'm gonna go into details of this, but just to give you a trailer, let's quickly look at this. I want each of you to think about your work-related best idea you've ever had. Think about the best work-related idea you've ever had. Everyone's had one, hopefully. Yes, absolutely. Where did you come up with that idea? Were you collaborating with people when you came up with that? Maybe, right? But most often, right? In my opinion, I come up with ideas when I'm taking a shower, when I'm taking my dog to a walk, when I'm going for a swim, or when I'm going off, you know, walking to the water cooler. I rarely get ideas when a bunch of us are sitting in room and doing brainstorming. Doesn't work that way. I don't think you should collaborate, is the point I'm trying to make. I don't think it should become muscle memory. I think we are losing a lot of... One of the biggest challenge, and you can look across survey that's done across the industry, is companies which have adopted agile are complaining that they have lost innovation. This is one of the biggest complaints. You can look out the surveys out there. It's quite out glaring. And that's one of the biggest complaints. And you ask why? Because if you're so velocity driven, if you're always constantly being micromanaged, if all you're gonna focus is in group think, then you're not gonna go too far. And there are enough case studies of failed companies trying to do this over and over again. So my talk is just, don't take everything I'm saying. Think of this as food for thought, and take one or two points and ponder upon them. And you can discard everything saying, this guy knows nothing what he's talking about. That's perfectly fine. But this is where I think. Let's talk about another thing. How many people wrote the agile manifesto again? 17 white men got into a room in a skiing resort, drank some beer and wrote the agile manifesto is the story we heard in childhood. Reality, two people wrote the manifesto. 17 people argued, left, two people wrote the manifesto. Since that day, the 17 people have never come back together in a single room. That's collaboration amplified. Stop it. What we have been doing, which has worked really well for us, is what we call a set-based development. We take the same problem. We have three individuals, three teams go and solve the same problem. They have a fixed time, fixed budget, and they operate within that. At the end of that, they all come together and we pick the best solution out of the three. And this is actually worked really well because this gives people the autonomy they need. This gives people the time and space that they can work creatively and do their solo deep thinking. And there's a lot of power in doing parallel, say, fail experimentation that I can spend the whole evening talking about. I have four minutes and I have six points to cover. Technical debt, I don't think I need to talk too much about this. What's the antifragile way of dealing with technical debt? How many people have technical debt? Are you guys doing agile? No, you're not doing agile. If you were doing agile, you wouldn't have technical debt. I have heard this argument many times that if you were doing agile, you wouldn't have technical debt. And that's just bullshit. I don't think that's true. The way we think about technical debt and we've completely misplaced the metaphor in the first place. Who came up with the technical debt metaphor? What can I have? How many WOD one here? How many people have programmed with WOD? Just me, okay. And I have worked with WOD and when we came up with the metaphor, the idea was that debt is good. Small, low-interest debt is good. That's how you run business. Long-term, high-interest debt is bad. But short-term, low-interest debt is actually good. And we've completely misplaced the metaphor, in my opinion. We think now technical debt is a bad thing, but actually taking technical debt, small technical debt is actually a good thing. It gives you the advantage that you need. So an antifragile way of thinking about this is throw away code frequently. Use full-stack programmers and build microservices. Like, I'm being very prescriptive, but that's one thing that I have seen that's helped us immensely in a lot of companies. We've been throwing away code very rapidly. When you throw away code, and one thing if someone asked me what I wish was there in code is self-destructing code. Every two weeks, the code disappears. And then the way you approach the problem is very different. You take technical debt more rigorously, but then you replace it very quickly, right? And that's an antifragile way. Be more opportunistic, take advantage of this rather than trying to resist it. I'm gonna skip this slide. It's pretty obvious. I'm gonna talk about this. This is one of my other favorite things. How many people like the Scrum Master and Product Owner role? I think it's one of the most badly conceived idea in my opinion. I have seen serious problems of ownership and accountability because of this. And you might say I don't understand the roles and I have not done it correctly. Absolutely, all credit goes to you guys, but I have seen serious problems caused because of this. I think the whole notion of having one product owner who's static, who will have the vision throughout, is just fundamentally flawed in my opinion. The way you think about this is think about how startups run. Startups run where you don't have a product owner and a Scrum Master. That's not how startups run. Startups have what we call as power centers emerging. If someone had a great idea, they become the product owner for that idea. And someone else had a new idea and they become the product owner for that. And then they form these small tribes and they go solve the problem. That's how people solve this. And I think that's a scalable model. This is actually what we are trying at Hike and a bunch of other companies. And it's actually worked really well. We've completely done away with the product owner as Scrum Master role. And I don't think we are missing anything. In fact, the Scrum Master role is very dicey because on one hand you're saying that this person facilitates and enables the team. On other hand, you're basically saying, okay, this is a servant leadership and then it's like there's so many things and just even the name seems totally retarded to me. Scrum Master. I mean, in India, the connotation obviously means that, okay, this is the person I'm reporting to. Right, it just doesn't work. I am almost out of time. All right, there were a bunch of things that I had. I kind of skimmed through some of these things. That's okay, I'm bad at estimation. I told you upfront. The list goes on, the slides are up. You can see them in more detail. I don't have time left, but I'm gonna sneak in a couple of quick questions and then I'm gonna be outside for more questions. All right? So a couple of quick questions before they throw me off the stage. It's not a human being. It can't say anything. It's people, it's snake oil salesmen who are saying all kinds of crap. People who've never actually shipped real products in production. These are the people who are telling you, agile says this, what does that mean? Who said this? Absolutely. Be opportunistic, take the things. What makes sense to you? But be careful not to get dogmatic because there's a very thin line. Very soon, something becomes very dogmatic. Some soon you become standardization centric. Soon you want everyone in your company to do things in a certain way. That is a very slippery slope. I have been there enough number of times. I can tell you it's just very hard to know when you've crossed that line, right? So when you're starting off, you want the training wheels. But when do you take off the training wheels? When I'm learning a bicycle because I'm an individual, I can decide. But if there were thousand people that were all learning bicycles and we put training wheels for them, how do you decide when you're gonna take off the training wheels? I think you should attend, listen to people and ask them questions. You're getting confused, which is a good thing. I'm making you think. If you walk out of this session saying, this guy confused the heck out of me, I think mission accomplished. Meet me offline. I'll talk about 10 stories of real organizations blown up millions of dollars, failed because of agile. All right, I'll tell you in detail. Actually, see, once again, before I jump off, let me close that. Agile is a placebo, something somewhere in the slide I should have put that. Agile is a placebo. How many people know the concept of placebo? Most people know the concept of placebo. Agile is a placebo. Any new tool or technique is a placebo. It is a tool meant to get you to think, right? Don't get too dogmatic about it because then you'll be stuck with the training wheels for the rest of your life. Sorry. See, the confusion is not only to me now, so I think I'm afraid I'll carry this confusion to the team. From 2008, I've been talking about Agile is dead. You need to, it's getting too dogmatic. Guys, watch out, guys, watch out. I've been trying to invite people from different places every year to try and bring that message that, hey, are we getting too dogmatic with this? Are we just going too much with on the process side of things and we're forgetting the original meaning of it? And what we want is certainty. What we want is all of that stuff. But the point was that this was, you know, trying to solve the problem of embracing uncertainty, right? And a lot of times we want answers, but honestly answers are within yourself. You need to go back to your organizations and figure out. The place to start is start questioning. Why are we doing something? Is it actually helping us? Look at it critically, look at it as a scientist, right? Get the data in front of you and actually look at it, is this helping you? What happens if I stop doing the stand-ups today? For example, try those experiments at your organization, right? And see what happens. I don't think that's true. And if that's the case, life is too short to waste time on such organizations. Yeah, I mean, if you're gonna challenge someone that this is pointless and we should think about it, they're gonna throw you out. So why do you want to work for such place? That's your issue. Agile is not gonna solve that problem unfortunately. All right, I'm gonna get off the stage, sorry about all the ranting, but this is what it is.