 Come to that, I have 15 minutes, seven minutes of presentation, seven minutes of demo. Directly I'm going to show you guys. So let's look at our agile journey so far. Here, 2000, agile manifesto was defined, fantastic. Agile journey, 14 years on, right? 14 years still on, fantastic. Results, great success so far, yeah? Everything good about agile, but looks like we still have problems. Recent survey, right, 2012. Still 9% of the projects of agile are failure, and 49% of the agile are still being challenged. 14 years of great minds of industry working together, still we have 2012 statistics like this. What's going on? What's going wrong that we still, after 14 years, are struggling? I'll tell you, I don't think so in software industry. Anything has survived for 14 years, but agile, consulting, servicing, coaching, everything. Still you meet people around and says, how is agile going? Oh, you know what, we are trying to learn. We are trying to get some coaches. We are trying to do this. We are trying to do that. 14 years is such a small time to really make something successful. Anyway, one part of it. More interesting, let's look at it, right? It's really, really fantastic in a negative way to look at it, that 70% of the organizations still have at least one project failure, big project I'm talking about. Big up to the level of that, the 17% of such projects actually threaten the existence of the company itself. Where we have WhatsApp kind of a company being sold for $19 billion, we have 17% of the projects still threatening the existence of the company itself. Wow, good about agile. 45% of the projects run over a budget. These are facts. This is a survey done by these guys. I have not taken it from anywhere. I'm not that at Valtek we do any of those surveys. We haven't. But this is industry fact. What's going on? What's going wrong? It's only agile projects. Yes. Yes, no waterfall projects including that. And I have just got the presentation. I have really taken the top three statistics. There is a lot more. Really if we bring it up, I mean it's alarming sometimes, mind boggling that why? Why after 14 years we still are there? Question still remains the same. The question is, to be honest with you, right? All the customers, enterprise customers, small customer, mid-size customers that we meet, the real problem that we see, the problem is, can we remove subjectiveness from agile manipulation? What I look at story point, what you look at it? The specification is so open, and the teams empower to do what they want to do, which is definitely the right way of doing it, but then open specifications. There is a lot of subjectiveness in the agile system right now. Two years back, I was here, and I asked one of the CTOs of the big company, not that I'm not taking name for any good or wrong reason, but I asked her, saying that why is agile 2.0? I mean, what's going? If anything goes wrong, the market, we will get screwed. That's not true. There are possible, there are ways to do it, just that we're all not taking the right way of right steps. Anyway, no problem. Fantastic. So you know what, this is the same thing I have heard in last two years, so many times, so many times. But the point is, subjectiveness is not templatizing something. Please, that's not what subjectiveness is. Subjectiveness, OK, give me two minutes. You will get the answer. But thank you so much for bringing it up, because this is the same thing I've heard at least 1,000 times so far from all my customers, right? OK, so now, forget your software industry for two minutes, all of you. Let's try to find a innovative solution, and very less ladies here, but still, even guys cook these days. So let's go to our kitchen. Just to make it a little interesting, let's go to our kitchen. So waterfall, we have depicted like a pure black box, whether some people think it's an oven, some people even thought this is a TV. But the point is, there is some input going in, there is some output coming out. Input, what goes in, output, God only knows. But with all humbleness, you have to eat, you have to taste, and you have to tell your family, fantastic, it was good, even the salt was less. But that's how waterfall was, because you were never allowed to collaborate, do anything in between. Input, output, two years, four years, five years, fine. We broke that. We broke that very effectively. And if you just try to depict the way we have depicted is that we broke the closed kitchen to an open specification kitchen. You have a view from the frying pan itself, from the smallest piece of it, right? So from day one, you are collaborating and you are seeing the dish being cooked collaboratively. Sprint cycle, with every sprint, it evolving and becoming a fine product. That's the thing which we have done. What did it do? It enabled collaboration, right? People are collaborating, promoted transparency. Everything is open, nothing is closed in a box now. Fostered openness, right? So anybody can touch, feel, give feedback. Anybody can do anything with it, right? So nobody is getting involved with only at the latest stage. Everybody is involving at every stage, right? That's how the open cooking is. That's how the agile era is. It guarantees success. When you have open, when you have transparency, when you have collaboration, all those good principles, it guarantees success. Anybody says agile, it is guaranteed success, right? Come on, do the agile coaching. After that, it will be successful coach or it will be successful project manager, project everything, fantastic. By no mean, I mean to say of any one of my statement would mean that agile is not required. Agile is the basic hygiene. Only thing what I'm trying to bring it out here is that we have spent enough time with agile. Still, why our hand is not reaching the top? Why you are still somewhere here, right? We need to do something around it, right? So same kitchen theory, right? Break the waterfall into an open kitchen. Everybody is involved from the day one of the cooking when you actually put those mushroom seeds or any ingredients and things like that. I started boiling, boiling and everybody's part of it, right? That's how it is, right? What it means, what it brought? It said, collaborate. So somebody said low salt, medium spicy, very little oil, okay? And then somebody said wonderful dish and somebody still said yuck. When you said subjectiveness, I'm talking about subjectiveness from this perspective. What is medium spicy? The way I look at as medium spicy is very different from what you would look at medium spicy. The way you say little oil or you might say two spoons of oil, the spoon that you use might be smaller one, the spoon that I use might be almost equivalent to 10 liters, just for the sake of it. So there is subjectiveness in terms of what we talk. There is not subjectiveness in terms of templatization, but can I remove this? Can I say what is very little oil and how do I quantify what is little oil? That means there is really something missing. What's missing? Something is missing. Let's add another indigredient A toward agile cooking. A analytics. So for me, the agile has a problem of analytics. Now you look at agile right now as a solution of big data. Everything would get simplified. How? Let's go back to our kitchen. Let's look at this way, okay? Imagine said, you know, when we are doing this, so as a group we are sitting together, collaborating even to prep this presentation. So one of the girls, we said, okay, we'll come to your house, we'll have food and we'll say medium spicy, less oil, and what will you do? I mean she said some depiction. But then still when I go and eat that, or let's say, forget me, let's say I take one of my customers and say, come on eat, I have told her, less spicy, less oil and all. But when it still goes eats, it still has some upset. That's where the agile world is. So what we are saying is build analytics around it. How do you bring built analytics around? It is something less. And look at this. You are taking the raw materials, you put rather than, and you know what? We are not saying that this is a product. You take this product and you know nothing. No product, no license, nothing of that sort, okay? This is only a framework with that we have built on the existing infrastructure. One of the important element that we have, we are not saying you to buy this X, Y, Z, pay this much cost, take three years for transfer, none of that. We are saying use common sense. Whatever you have, have data, don't have reporting. Have data available to you in a one second info rule which will enable you to take a right decision at the right time. And I will show you what that means. So let's take this one, okay? So when I wash my vegetables in a vessel, I put them, I wash them and you know it's all done. I take it off, put in the pressure cooker. But can my hands tell me that the vegetables wash properly? It has not lost any vitamin and the tomatoes are not, they're not three days old and they're really bad. Can it, can my hands tell me? Definitely not. That is subjectiveness. Now imagine you put in some kind of a container, you put those raw materials, it applies some aqua pressure and things like this and then it highlights something green, red, and all says, you know, your vegetables are good for cooking. Vegetable is fine. Let's say the water that I used for cooking is really bad, polluted. What happens? That's exactly your problem. Multiple places I have seen in customer places, they give best of their resources. That is raw vegetables, but they put polluted water. That's the bad scrum master for some reason and that bad scrum master actually spoils the entire vegetables and then there is nobody to tell me that you know what, you are red here. I discover it six months later, eight months later and say, oh come on, get him out of the team. Team will decide scrum master should go out. Let team go out, but after six months, come on. That's not something which can help us to make Agile project successful. Okay, get them here. Okay, and then once you get them here, you configure, you let me configure what is your dinner menu? Seven chapatis, 200 grams of vegetable curry, one roast chicken for non-veterians and some serving of salads, right? Now when that happens, when the processing is happening, right? Here raw vegetables are being validated, marinated, deep cooking is happening at one stage. Again, validation is happening at stage. Then you have qualities and things like that in place. If you imagine you have a frying pan or cooking pan like this, I'm sure the food that you will get is the most healthiest food that you could ever think because subjectiveness is removed. My hands cannot do that. My hands cannot look at it. Even if I put in my mouth and taste, I can only say good or bad. I can never say whether it has that vitamins. Can I say, when I put one spoon in my mouth, can I say that it has nutrition's good? I mean, it has retained this many nutrition's or it has lot nutrition, no. Can I say that while cooking, I have spoiled 500 calories, no. Can I say that I have 30% of gas right now? No. Can I say that cooking that I have done is healthy? Right now, no. Why? Because I don't have the environment, the scientific way of looking at this. I don't have a cooking vessel like that right now. Cooking vessel, yes, we can leave that innovation to them, but for us software guys, can we not build solutions? We can, and that's exactly, that's exactly what we have done. A square, that's adding A to the agile which makes it a square. How does it look? It looks like this. I'm a release manager. I really don't want to go through the sprint, sprint, the reports and all of those things and have scrum and scrum meetings, so meetings and meetings, meetings and meetings. I don't know what any of that. I simply want to see that, is there a problem in the release that I have promised either to my top management or to the market? Okay, so I'm a sales head and I have promised in six months or three months I'm going to make this release. Can I do that? In one second info, please keep in mind one second info is the rule. We don't deal with anything which will take more than one second. In one second, can I answer this question is the question because sales guy can spend more time in market rather than having meetings to figure out what exactly is happening, right? So come back and see this, okay? This is your exact capacity. This is the release view. This is your epic stories, you know how they have been fine breaking. This is your development cycle, how it is happening. This is your environments. Let me show you how we read it, okay? Moment something changes, suddenly Bharat Banth, five days, closed, BGP has a problem. Closed, what happens? That much of capacity gone. What happens? When that happens, I enter the data through leaves and nothing. You don't enter personally. Your pipeline shrinks, you see this? This is the red indicates pipeline. It says this was your initial planning but you have already shrunk your capacity for some reason. Okay? And look at this viability shrinking here more. That means your release cycle, your release of product, product is choking. Mainly here. Most of the times you go and see developers have done, they have done sprint demos, everything is done. But it is spending in an environment for six months. Six months. It has not even gone to the market. So it's not gone to the market. Why is it lying? Nobody has a view and they start discovering, oh yeah, it's spending here, it's spending here. Let's do something about it. And when they take it up, that time they realize, oh, market requirement itself has changed. Dump it. Come on. How wastage can we afford even in today's world? I think not acceptable. So look at this pipeline view, which is called capacity pipeline view. It shrinks or grows based upon the environment that you change. What we do is we listen to all of your data. Anything, everything data. Whether it's build, fire, anything like this. And then get that abstracted info to the required person, not for any controlling, not for any monitoring. And to your question, we don't tell any developer, any manager or anything to say create a template. We say tell us what you're doing. We are just going to listen to that. Don't change anything. Absolutely nothing. If you're using Excel sheet, no problem. Tell us how format in which you are using. From that, we'll derive this data and we'll show the view. So no change, absolutely from any perspective, okay? And then it will have all this. So 100 open blockers, 35 hours wasted, 500 points and things like this. More than anything, you have one simple diagram to say from planning perspective, you're green now. But one hour later, if you look at it, you might have suddenly become red or any other color. Quality perspective, progress perspective, all of them behind of this good mathematical models running on your data, real time, real time, and then giving this kind of status. Progress, so that's release. This is progress as a release manager, not release manager. So release manager, I showed you. Let's say scrum of scrum or scrum managers or somebody, right? I'm interested only looking at when did my, that part of release started, when did it become in the start stage, when did it become development stage and which week aware I am? Anything turning red, I get a immediate attention. You get immediate data. What to do with the data is completely left to you. It's not that we kind of, you know, force you to look at anything. But you get data, you get what is done, what is not done in a snapshot view. Imagine you have a TV in front of you. You're watching, I mean just in front of you. Suddenly you just look at it and your eye filled red. Hey, what is happening? Why is my, this particular sprint in red? Okay, whether you call that person, speak to him, there's a different thing. But we are bringing data closer to you to take a decision. That's the most important piece what we are doing. I will show you this everything in quick demo only. This is what we have done at Tesco in a much more higher manner. We're still working with them to do further. Let me show you a quick demo, considering that we have a lot of, so if you have multiple sprints as a person, so you will have to choose one. Anyway, so let me look at me as a person. This is only, you know, this is not real data from anywhere. We have just created specifically, but this is almost real. So let me look at this, okay? I as a person, okay? So my view, that's me as a developer or whoever it could be as a part of the team, right? Look at this. It will be so interesting and believe me, go back and see in your projects, you would find 90% of the similar situation. I'm not saying everybody, but you will find. Look at this. 16 out of 24 tasks already done. 64 hours out of 68 planned already consumed. Still two days left for accomplishing, finishing with sprint. It's good, right? It's not bad. I mean not bad at all, right? Still my sprint indicator for me, it is showing red that to extreme zone of red, okay? Why is this tool behaving like this? I don't know. But let me go back. But let's keep the context same. He's a good guy. He has already finished 16 tasks, out of 24 tasks. He's already consumed 64 hours out of 68. And two days is still left. It's a good guy. But let me look at him. So initial five days, he has not done any work till here. And sixth day, he has burned 64 hours in one day. One day, 64 hours. It's extremely impossible. But you know what happens when you are working? You don't update things stuff and stuff, right? So it's not generally the case, so let's not. I mean, he's still a good guy. Maybe he has forgotten to update things. He has been working throughout. He didn't update the task in the JIRA or wherever it could be. So he has not updated, but he's still a good guy. All right, no problem. Good guy, he still has two more days left. And only problem looks like he doesn't update daily. It is okay. But why then, up till 25th, he has not fired even a single build. What was he doing till 25th? He was working. He was not updating JIRAs and other things. That's okay. But why he has not fired even a single build to test his code till 25th? And why between 26th and the first March, he has fired almost 40 builds. 40 builds which has failed, not even success. That means he has almost fired 80 builds. 40 of builds has failed. Why is that? Okay, he chose not to test his things. He wrote code throughout the week. And one day he chose to test the code and things like that. Still good, but maybe a little bad now, okay? No problem. Let's look at what he has done to the technical debt. Oh, now you see. Same time zone when his builds have been going high, that's the time complete code quality has come down. That means the initial perspective that we had about this guy that he has been done extremely good. He still has two days on his sprint for him. He can still continue working. And he has no problem, just that he has not updating his giras and other things. It looked that way. But if you connect the dots, there's a completely different story. And what is the different story? The different story is simple. That exactly on that particular day 26th, that 6th day of his sprint, he started working very hard. Somehow he did something. Fired so many builds, the build failed. And then when finally he made it work somehow, code got in, but the technical debt got very high because code quality went down. Look at his design quality. Data cut. He doesn't want to show his design quality at all. Okay, if it comes up, it's coming up. So whatever he has headed, he has spoiled two modules and made them red. So if I only want to see his one, what he has done, if I have a team member like this, I would have preferred him spending two weeks of vacation rather than adding little bit of functionality and spoiling my technical debt to this level. That's where the industry is coming up. Why is the problem? The problem is in their connectivity. I know I'm running out of time, but I want to show you very quickly something more. So this is me, my view, which means what we initially thought this extreme thing of red is bad. Actually it's not bad. It's actually showing the right thing. Anyway, let me look at team view very quickly. Some things for the short of time. Very quickly I'll show you something. Everybody blames task burned down. Task burned down is not proper. How it can be proper when your task creation itself is not right? Task burned down is not proper. Click on the show task creation. More than 50% of the task have been created only after 50% of the sprint was even over. If that is the way, what was the first year of sprint planning being done for? So keeping my lungs, okay, I think this is something I should definitely show you. Look at this average utilization of the team. Team in general is underutilized. Throughout the week these are underutilized. That's the best thing. But look at this space. Team is generally underutilized but there are two guys who are overutilized throughout the week. Poor two guys. And this is what happens in software industry. I have a team. Two people are working slogging very hard making the project look success. When I look at the team, everything's fine. But when I look at the individual, six people are underutilized and only two people are overutilized. What does it mean? It does not mean people are bad. It only means we have not formed the right scrum team. Maybe there are, this is a UI project and I have only Java API developers in that and only two are UI guys. That's typically where you struggle. And we don't have time to look at each one of them. We don't have time to really retrospect so much to get at this thing. Instant, why doesn't use a framework which gives you such data at fingertips? What you do with it is completely up to you. Nobody from this framework prescribes to do it this way or that way. You take a call, just that to make that call, data is brought closer to you. And that's all. I will open for any questions if you have because I'm already shot by five minutes. Thank you guys. Any questions or any feedback? I'll be more than happy to. Absolutely. So anything existing, no changes whatsoever. That's what I'm saying. Small company using Excel sheet, absolutely fine. No problem. Still get everything as it is. So that's no change. No change in the process. But one thing, see, there are certain companies where they may not be following the basics of AGL also, right? So two will cannot do anything to that, right? Two will show complete wrong data. That's a different ball game all together. You have to coach them, mentor them. All that still remains the same. But after that, there should be something which will enable or achieve that. That's what this tool will do. And again, I'm saying this is not tool or product. This is a framework which will enable you to do that. It is, but we haven't opened it up yet. There is something called as free premium, which means that you get to use it for some users. You install it and stay. And let's say you don't have the basic hygiene also. You install it on the live and do things without our help, non-friction based. But there are different models which definitely, our members are outside. They can connect you and give you a lot more details and things like that. Any more questions, please? It is purely historical, yeah? As long as you want. As long as you want. And not only that. See, if it is not historical, I cannot predict my release in the product view. Everything is there. So that's what I'm saying. We have solved it from a perspective of big data. So HIL can definitely make closer all this subjectiveness, all these things which we talk can be simplified. And as I said, we have done it at Tesco. They have seen huge, huge, I'm not open to share numbers, but they have seen huge success from this. And we are continuously working with them to the next levels and things like this. Yes, sorry, one. I'll come to that, sorry. Just are you hosting the data? Not data. We don't host the data. We only host the processing power. Data, we don't host. Data, we let the organization keep it then because we don't want to get into any of that. But processing power. So we take the data, encrypt it, process it, give it back to them so no data is with us at all. Sorry, what's that question? Yes, fantastic. So there is another view. I don't know whether it's in my PPT. One thing, let me quickly see. Thank you for bringing it up. Let me see if I have it here. Sorry, I don't have it here. So there is another view called as the organization view, which will show you from quality perspective, progress perspective, and everything that, where were you three months back? And where are you today? That can have a productivity, individual base, people base. So now we have not kept it in individual base because we don't want to get in that phase. But as an aspect, quality, are you growing up? Yes. Progress, are you making progress? Or even after this, are you still coming down to make it? So that's there, which is not implemented yet. We are kind of working towards, that's in our roadmap actually. Thank you. Which one? This one, this one is, there are two views, my view and team view. My view is for me as a person. That view, the managers don't get to see at all. Team view is only the team can see when the individual also can see. And the overall program view can be seen only with the top management things like this. So there are different slices which different people are seeing. My, absolutely. So the point is, if manager does not get to see my view, right? But if you'd have seen what I said, I'll show you. See this manager gets to see this one, team view. And they still get to see my team is in red. You know, very interesting. If for example, let's click on this line, okay? My sprint has been closed, okay? Still 98 files are not even checked in back to the process. Moment manager gets to see that, let him follow the same thing he's following. Call his scrum master, call people and talk about it, right? So then if he wants to get individual access, he can get. But as a tool, we are not enabling that because we don't want to make it as a monitoring aspect. So nobody's monitoring it, it's only facilitating. That's the idea behind it. Thank you so much, because of the short time, I think it's a little less, but any feedback, please, we are from Valtek. Our stall is, our booth is down. If you want to see a detailed demo, please come down. We have people there, they will show you the thing. We have some write ups, you can take it up. And you can also contact us and see demo in detail, which at least takes about two hours really to get the proper value up. Thank you so much. Thanks, sir.