 Good morning, having good time so far, how is it going so far? Awesome, how many of you were there yesterday? Quick check, how many of you from IT services here? Few of them, IT service companies, ok, alright, sorry. So, you essentially do services in as long as, ok, alright, ok. So, evolutionary approach for maturing agile adoption IT in IT services, I mean, I was not sure what title I am going to do, I mean, I am still not convinced with the title, but this whole maturing thing I am not really convinced about that fact, because maturing without context might lead to dangerous results. So, I really do not know, but then it might resonate in IT services, because just the other day I was talking to somebody or somebody actually hinted, we have to now start looking at high maturity agile practices, because in CMMI world, how many of you come from CMMI world, high maturity practices and all that, suddenly this high maturity somewhere is resonating. So, if you were in the previous stock and the Smith Busters, I do not know where this is heading to. So, alongside this agile myths, there are many more things we are taking on. So, I am not sure on this thing, but then the intent is, how do we try to connect the dots in terms of when we try to apply lean or even agile for that matter from a servicing point of view or working as a vendor to many of the customers, the challenges that you have and how an evolutionary approach would help. So, in an evolutionary approach, does maturing really mean maturing in that sense as a fixed maturing stage gate sort of a thing, definitely will not, but then we will take it further from there. All right. So, my name is Ravi Kumar, I work for HCL Technologies, been with agile for some time, about six, seven years now. So, today's agenda is somewhere on these lines. We will look at what organization, culture, change and IT service landscape is. We will try to ponder upon what this agility is, agility in the sense of revolutionary approaches where for me revolutionary approach, when I say I talk about scrum and XP or revolutionary approach in that way, it requires lot more things and evolutionary approach. So, does it solve some of the issues that we talk about and does really agile mean for the same way of implementation across the board, across different project types etcetera. So, to give that perspective, the IT service landscape might help us. And then I briefly touch upon declaration of interdependence because it also connects with what I want to talk about from a culture perspective. And then we will dwell into a lot more detailing on, on taking on few of the aspects of the lean or the agile world. In how do you actually go about implementing an evolutionary approach? What are the few things that you necessarily need? What are some of the things that we should not look at and things like that? And finally, this is something that which was bothering me and I wanted to put it out. It is IT services manifesto, again lot of cliche, but then I think it would probably resonate around some of the things what people would connotate as necessary evil or really an evil or whatever, it still manifests in the inner kind of industry where. So, we will look at that. And during the presentation, feel free to ask any questions. So, depending on how much of time we have, we will take it. So, how many of you have come across this? This is Snyder model, this is the organization culture. So, basically talks about collaboration, cultivation, control and competence, right. So, I won't go to the details of it. There is a lot of material on the web and you know books and things like that you could see. But more often than not, when you look at IT services, what do we do? There is a lot of management aspect, there is a lot of hierarchy and they all fall into somewhere in the control order, predictability, stability, standardization, etc. These are not new things to us. That's where our type or the IT service type of organizations lie. I mean, I'm not saying IT services, you have to kind of formulate that as a, as its own space and IT service can apply even into your captive or into a product development company or even into a business establishment where IT is a conduit for doing their business or helping business, right. So, you still, many of the management apply that, right. Lot of our thing comes here. Now, when you look at agile from a true sense and from the manifesto, when you read, lot of the aspects of agile is in collaboration and cultivation, right. So, when you look at how do you do, how do you get the teams involved? What are the growth aspect? What are the values? How do you go about doing this? It's all about people collaboration, people aspect of it. So, there is a vast difference when you look at it, when you step up, step back and see lean and agile when you see, there is like lean fundamentally comes from that control and those aspects of it to bring a certain new order and think that there's nothing wrong about it. But, where lean and agile would also connect is on the people aspect of it, right. So, while they are philosophically different in terms of this, but they emphasize still on the people aspect of it. When you look at organization structures, if you look at this and that where the next slide is, you talk about change. This is the status model of change. Any change that has to go through, it goes through this kind of a curve and there is always chaos. You'll have to get over that chaos and somewhere once you cross that, you will find that space and people come around and start resonating. And there you go to a newer order, newer status quo and things like that, then you start building on. So, all those things take time. I mean, change in itself is not very, very comfortable for any human being. We ourselves find it very difficult to change. There are certain things that we come up with. It's very difficult. While we read about change and things like that, we inherently cannot change ourselves. And how can an organization change when it is constituted about people? Ultimately, end of the day, they all have to come together and they all have difference of opinions. So, how do you steer the masses to this change? And it takes an order. And at least for me, initially, when I was trying to look at, when you have to go through the agile curve and I got this, yes, organization culture change is important. You have to do otherwise it doesn't do. But then, lot of these efforts are being put up by organization trying to get there. But the point is, organization culture change in itself will become an initiative. Projects, business has to go on. There are certain things. Somewhere they have to connect. And both of these will work in parallel or in different ways, in tangents or whatever it is. But they all have, especially this problem will even magnify if you are a larger organization. I work for an organization which has close to 100,000 people. Now, what organization change will you put out? We are in 33 different countries. How do you resonate people into saying that this is our philosophy and I work for a organization where we talk about employee first, customer second, which is even more provocative, which will hit hard. But then, we will come to that topic little later if at all the time permits. But the point is, every organization has this thing, but to make that change and try to unify around a common point in terms of service and delivery, it's all two different things. There are a lot of things that has to happen. A lot of things has to come together, right. So, when you look at the landscape, these are all the things that we do. We have different types of verticals, different types of service landscape, different types of projects which we work with. It's not just one side, it's all. I mean product, many people would say it's a lot easier for Agile as opposed to a service. It is debatable depending on which side you see and how you want to do it. In my opinion, in a service kind of an infrastructure, I think Agile would play a better role and you could do it, provided you have the intent to thinking about it. It's easily said and done, but then it's more relevant. Agile probably will suit more of the service unless you go on gold plating many of this thing, then it will become difficult. But this is just to give an idea as to what the landscape is, the kind of geo-spread, the kind of different verticals, the problems and things like that. One size fits all. Even one Agile adoption strategy will not work. So, that's where I'm kind of skeptical on the idea of this maturing whole thing itself because what applies to one will not apply to the inherent in the context. That's important. And here, you have multitude of contexts. And now you try to bring it up at the management level and see everybody seems to complain that I don't see any Agile project doing in one way. There's no standardization at all in Agile, which is precisely the problem. I mean, if you say this, if you have identified this, then I think we are doing good. But the thing what they want to hear is, it has standardized approach of doing Agile and they are happy. The point is they are the decision makers who want to be happy. So, there's a perception gap in what it is, what it inherently is, because if you take away contact, it missed the point. So, I was looking around what could be a better definition for Agile, Agility as such and services is all about delivering things. This is what I looked up on Wikipedia, which is decent at least for this kind of talk. It talks about Agility or Nimbleness is the ability to change the body's position efficiently and requires the integration of isolated movement skills using a combination of balance, coordination, speed, reflexes, strength and endurance. And this is all IT services. Context vary, projects vary, types vary, people come in, come out. I mean, where would you standardize anything? I mean, it's in the day in the life of an organization. See, you can only see chaos. You cannot see anything standard, but then we stick on to the word called standardization. No. And it's a reality if you are working in offshore distribute, offshore kind of an environment like where we are, attrition is like super high, 10, 12 percent, 14 percent. If you are doing actually 10 percent or single digits, you are super good. But even 9 percent, 10 percent, attrition, consider that in an Agile environment, you are cranking code out every two weeks, one person goes, then how are you going to manage that? Very, very difficult, right? So, anyway, there's a fairly good definition of it. Then it, how many of you have come across this declaration of interdependence? In fact, Dieter talked this morning and he is the author of, co-author of this declaration of interdependence. The reason I bring out is because when we look at our organization constructs, there's a lot of control, there's a lot of leadership. Somewhere, Agile manifesto also, I think probably they did not involve the management and the leadership aspect of delivering projects and it is inherent to any organization. In smaller groups, you may not need so much of it, but the moment you expand, you become a business entity. There is always going to be that management leadership need to drive. Even now we talk about so much of culture change for Agile to succeed. Who is going to drive that culture change? Teams are not going to do it. Some leadership has to take that and do it. So, where does that come from? So, there's a lot of, I mean, there's a lot of things written on it, but more importantly, I want to emphasize this. We improve effectiveness and reliability through situationally specific strategies, processes and practices. Very, very important. This is at a leadership level is what they are not at a programmer developer level. Leadership is committed to a fact that saying, I want to bring, improve effectiveness and reliability through situationally specific strategies, processes and practices. So, what does it mean in a service context? Is it not applicable there? Anything you service, I mean, as a service provider should involve, improve, I mean, effective reliability. That is what customers are looking forward from us. So, and how can you do it without the context? It is very important. So, that is where you need to. So, which means that they also have to apply. It's not just one size fits all solution, but I just want to lay it out on the table so that it will be there because that those are the things which agile manifest or some of the theories that we don't connect well and then try to apply it and then these things go wrong, right? So, when we look at agile, what are the challenges? What challenges do you see in agile in your respective spheres of life where you are applying? Any challenges that you see in agile? I know it's easily said then done. What challenges? You want to have, you want to set it there or exactly? How do you maintain agility when the organization goes, ah, well, though, you've transformed the agile now. Right. That's the way we do things. And you just set in that phase again. Right. So, the point is, again, coming back to what Nareesh was saying or the anti-hunt thing, agile is not about being comfortable. You want to do agile because you are uncomfortable. You are always at the edge of chaos. The point is, when you reach a status quo, it tells you that you have come to a comfort zone. Maybe something is wrong here. So, agile is about, you know, fast failing, right? So, you fail fast and you learn from it. You want to implement faster. You hit a status quo means there is something. So, it's a non-none territory now. How does this organization say it's okay to be uncomfortable? So, that is where leadership and vision comes. Without that element, you will never be able to prosper there because vision, when you look at it long gone and vision also tames in time period, right? So, you have achieved something that goals are met. Now, what is it that I'm going to do the next? So, how do you steer into that? Right? Okay. All right. So, it's easily said and done because it's like when you go there and exactly the same problem. So, most of the people will be or organize will be happy to say, I want to reach at this level and then I'm happy. I mean, at least coming from in the IT service as well, CMMI 1, 2, 3, 4 levels I've achieved, I'm there. I've reached. But the whole point of agile is if you have reached, then introspect. Okay, there's something wrong. So, you may have to change something. So, don't be in this norm, right? Now, we are looking at an evolutionary approach. We'll look at some of the changes or at least what I think could be the approach but you want to implement. But is it any easier? Yes, no. Will we have the same difficulties? Anything? Sorry? No? Yeah, so that's the point because evolutionary doesn't mean that you stick on to the existing problems you move on with the baggage. The idea is evolutionary will give the path of, yes, you understand that, respect the current process. When you have read about, how many of you have read about Kanban, Lean? How many of you are using Kanban, Lean? Yeah, so it talks about respect the existing process. Fine, fair enough, but to what point? At some point, you have to let go of it. If you're still there and you will say that, you know, I'm agile because I'm following Kanban and things like that and it really says respect the existing process, then you're still in waterfall. So, how does that really work? I mean, can you know, we should still go back to the next step. Challenge ourselves and say, okay, this respects it, but what is the time? How much time I'm going to give for me so that I can change to what is really the agile thing? Right, so we'll look at some of those implementations. So one of the things about evolutionary approaches coming from at least waterfall, yes, given you can't adapt to scrum or XP day one, respect the existing process steps, et cetera, all those things, fine, it's nice and easy way to do it. Kanban says that, Lean says that, fine, I do that. But one of the things that is, it's all about eliminating ways, how do you do that? There are many factors to it. Reducing back size is one of them, reducing, you know, variability is one of them because you get into fast, it effectively gives you fast feedback cycles and things like that. But there's also a problem. So when you reduce back size, what happens? First of all, reducing the back size is not going to be that easy. Agree or disagree? Right, so what causes you the problem of reducing back size? Sorry, customer needs, interdependencies, that probably will be addressed through variability, but okay. Yes, so which is why you get into that integration and what is meaningful at the end of the day. So how do we optimize around that because we want to get something meaningful out, so which means that you hold it for some time and what happens when you hold it? You don't get feedback. The longer you hold, you avoid getting feedback, precisely. So you run the risk of, into a waterfall trap of holding onto something and not getting feedback on it. The quicker way to get there will give you feedback and you can act on it, that's the idea for it. But there are economic costs. So the whole talk, I'm trying to bring a perspective of economic equation into this because when you deal in an organization perspective, it's all those, it's theory, but then there is an economic value associated to it. I reduce the back size, fine. So every two weeks or every one day, every two days I want to give something, working. Fair enough, even if, let's say, I have the skill to do it. Now what does it mean from an organization consumption point of view? How do, when you roll it out into production, is the business even ready to accept it? Why? Too small doesn't mean no value. In the sense, say I have application, they have at least seven or eight working out of five. That probably we can, it's more of an education drive to change the mindset to accept this and go on. But then there is much more other cost to it, more than the accepting of it. What is that cost? There's a cost associated to any change, right? I mean, you can't just move, especially if you're working in an enterprise world, moving anything from your development into a production is a very costly affair. Those things are fine. So the point I'm coming to is from the competitive advantage perspective, you also have to balance it out from a ROI perspective. How much is that going to induce the cost on me to change? Because operational cost, you may be sometimes a KPEC cost and do you really want to do it? Sometimes if it is an internal facing application, there's nothing market oriented in it. Now, why do I want to care for it? I mean, there is a reason for it, you can go. But then the point I'm trying to highlight is if you want to reduce on the transaction curve, you will get onto the whole cost of making those things. Smaller chunks will get you the transaction part of it. It's a smaller thing. You get quick feedback on it. You can act on it. And you probably the risk of getting a bad requirement or not understanding the requirement you will overcome. But the point is making that effective change into production is going to hit. Which means that there has to be an investment provision into it. So as an organization management vision, they are centered around that. They have rallied up the respective departments as such to say that I'm okay to do this. And that is where context will apply. So certain times when production down, nobody thinks twice, whatever is the cost. Production is down, I would want to do it. But do I want to apply the similar rigor of production down to a business as usual? I want to get this application, but then I'm there. So that's a perspective I'm trying to. So there is an economic value for anything that we do. So ignoring that aspect of it will not make business sense. Of trying to be agile, you could just spin it off as an iterative thing. The whole aspect of emergency is because I do not know where it is going. Let me see how effectively I can get and do you really need it? Lot of software we put it as well. But if you still just make for the sake of making it, you put out a product backlog, you lose that. And this slide, I mean, these pictures actually show this is from this book called Emergent Design. Actually it talks about, Scott Bain talks about this curve. You have a product backlog and you are trying to write somewhere. Somewhere you get to a point that, okay, this requirement is not complete what I wanted. I want something else. You get into this change controls or CRs as we call, change requests. More often than not, when you try to apply change requests on an existing thing, you are hacking something into it. Lots of hacks get into it. At some point, it will go down to a level that I don't require any more CRs because it's point of unbearable. I have to stop this software, redo this entire thing. Because I cannot accommodate that cost anymore. So the whole aspect of looking at it from a software decay and managing itself is fundamentally wrong. When you are trying to do from an agile perspective, agile is talking about emergent. Can you really avoid software decay? Yeah, in a long haul maybe it will still trickle in. But for the most part of it, you can still be on that emergent mode. When you are in an emergent mode, starting from a first iteration, the way you want to take it through, alongside you are not seeing decay. You could debate this point. There's a cost associated to this. The cost that is associated here is when I look at that, it's a retrospective cost as an aftermath. Initially I have predictability, I have given something. There is a cost associated and I want a CR and it decays. Here there is an investment cost. Means that I have to always keep on investing into something and there is new things that is happening. So, you can debate about these points, whether investment cost or the end of the day sustainance part of it. But the point is somewhere you have to find the rhythm and balance between the two. So, getting locked down to a product backlog and saying I'm always there and I will get it will not meet the point. So, from an evolutionary approach again, talking about centralized strategy which is lean and coupled with decentralized execution. What do I mean by this? How many of you were in Arlo Belchi stock this morning? Anybody? Yeah, so he was also talking about first thing if you want to adapt or go to Agile is about or you want to transform into this decentralized. And a lot of Agile talks about empowerment to the team level which is decentralization. But when you look at it in an enterprise context, you also need certain aspects of it which the organization has to take responsibility. So, where does the organization take responsibility on and where it is at the team level that you want to leave it to them to perform. So, here I'm talking about certain things which is at a project level whatever needs to be done and when you have rolled it out from a centralized engineering quality perspective because your output or outcome what you would deliver to the customer is looked upon by the quality that you deliver. So, that would be costly for an organization. Now, I would want to have a layer on that which is my centralized aspect. But how you go about doing things is the nature of the teams in the context of it let them do whatever they want. That loose coupling has to be there. Now, you might get into a trap saying so which means to say do I need to have a centralized tool for everything so that every project will adhere to that tool not necessarily. You could still do interactions and things like that at a project level whatever you can do you can do it at that level. Those delta you can actually take it to a central aspect of it and see whether it is adhering to the overall quality now that I want to deliver from a customer point of view measure my outcomes and things like that that I can still centralize. Because more often than not what get escalated at the management or at a from a central perspective is something is really horribly going wrong in a long haul. How do you want to bring those levers in place so that I don't do especially in large engagements? But at project project level it doesn't get bombard into it at a very high level where you need an organizational structure to be in place. Lot of it is in the context of the project you should be able to do it and projects can make those decisions for you. When you go to the customer environment it might still pose an issue because you would replicate some things here because whatever is available say for example your CI you will have it in a customer location or CM is there in a customer location can you replicate from their CM environment to my CM environment so that I will adhere to whatever is required from my norm and then push it back into their CM. Those are the challenges we need to face. How do we bring about that? And in that you will also be constrained by the fact that what is the transparency now I want to build because let's face it we as an IT service organization when you look at it we work in a pyramid structures. We have lower skilled people at the bottom who will go up and probably there would be one tech lead, et cetera. Then how do you manage all these things? Somewhere you need to exercise control to give your deliverables. Now on day one of moving into an agile world I cannot say you have to be a rockstar agile then only this will work that will take time being a rockstar agile will take you time. You and that requires investment. So when you are taking an evolutionary approach you should have that in mind you have cognizance of that fact but then you are educating people and building the skill set to reach that. But in that you have to make some intermediary steps and that is where evolutionary approaches will help. So put these and those are necessary ways according to me and then you can scale it well or you can go at that level. But of course then you will be bombarded with another challenge will the investment I make in the people what if they don't stay with me? Attrition is very high. But it's better to have a wrong person whom you have not given the knowledge and skill retained than losing a person whom you have seen because the idea is at least by doing you will not lose everybody somebody will be there. So organizations are in a dilemma how much investment I make into skill upgrades because people will leave sooner than I mean very in very quick, rapid successions. Then all the investment that I have made is a waste but then I think that's the call they have to take and they have to stand that ground of making that investment. I think there's no choice in that because hopefully I mean when we make the right investments and give the advantage to the programmers that I'm working in a very exciting environment I'm building up the skill that's an assurance and they will stay. One of the biggest problems of people living is leaving the companies is because now they do not know what my future is going to be because I'm not getting that kind of opportunity I'm not building my skill. If we answer that I think most of them will stay on. We don't and hence they're trying to leave. So how much is where do we want to do that? So not investing is not an option we have to invest and there is that thing agile would take and even evolutionary approach would take that. So it's about balancing centralization and decentralization again. So when you look at from a lean cycle this again Donald Reinerstein in his book actually has stated that observe, orient, decide and act this is a loop that you constantly engage in. So all this happens in the context of it there's a lot of learning that you get in project context. That has to surface at the higher level of the organization which probably will form lots of things in that they run in their own cycles of improvement and things like that. Now how much of balance and how much between centralization decentralization the trick is if something which is very chaotic leave it to the project teams to handle. Somewhere there is economies of scale involved where there is cost implication involved get the management. Because more often than not what happens is management gets into the day-to-day activities of it. How many of you are in ASM world or support maintenance kind of a thing, ticket worlds? Anybody here in this room? Yeah. So in those kind of environments if you see lot of your change requests come in there is an associated time duration to it and you have to fix something to it and managements and get involved to prioritize, deprioritize, et cetera. So why should they get involved there? If you empower the team to say that this is a deliverable it is rightly coming so and you have to act upon it they should be able to. If it means that it is a significant cost I mean you would have to have from your goal perspective what is that cost? It could be different for different organization different projects. If I make a decision as a team and that is going to impact less than $500 I will probably give the empowerment to the team. If it is over $500 of that whatever is the cost associated then I will associate the management layer. So then what will happen is at least you are giving the empowerment there is some transparency and trust builds. So I am getting that value associated work I take a decision is much more empowering to the people rather than saying I have done it and you give them a feedback saying that you did an excellent job. That will not probably along with this with an economic value equation set will probably you know post a much better evolutionary in that way in a transition way. Visualize the entire cycle the whole aspect of lean or Kanban is about visualization right. So from visualization perspective what it is establishing a delivery cadence to manage uncertainty and control of flow that is the reason why we want to visualize. When you look at scrum or in an XP world or whatever you have certain things in a backlog you start working on a backlog it's still a batch but when you work in a certain way where I would delineate between an input cadence and a delivery cadence there is a certain amount of accountability also you are emphasizing. So I would not take anything into a batch or to execute into a scrum or in a sprint execution unless otherwise I have absolute clarity. If you are working as a vendor team this makes even more sense to have this clarity. We have said it but in a lean world we would actually decouple this. The reason why even in agile when it says it but it's not crystallized enough from an execution point of view the challenge is that business often doesn't get involved. At least in the world that I come from business doesn't get involved at all. Their job ends with giving that Excel sheet and after that IT would run around cranking up code or whatever it is. Now and there are certain clarification that we have to go back for nobody is there and there is a lot of wait time. Now that wait time hits me that's a cost. So when you are in an IT service vendor perspective where how do you accommodate your lead times? What's your lead time or what's your cycle time? Because at the end of the day you are measured against your throughputs and things like that and if you go back to your log and see most of the times your throughputs are bad because of the point of waiting time and waiting time is because the business is yet to come back on a clarification and if you are working in an on-site offshore distributed model sort of a thing and when they are sleeping when you are there you are perpetually in a wait time and you have to wait and every CR you will definitely have that because it is not upfront given enough detail to it and that's the reality in an agile cycle. So every CR can you afford to take a hit on that? So one of the things the techniques is you probably want to block it at an engineering cycle time and have a overall cycle, a lead time. So at least from a vendor perspective you can cover your back and saying that you know from an engineering cycle time we have done good when we have got to a clarification on that whatever you wanted to do. So that's where input cadence helps. So if you and it also gives the opportunity to the business to be more accountable and they can go and start working on it in their own because business also why they cannot contribute to the IT is because they are challenged it's also a part time job for them. Business doesn't sit as a full time role in this because when they sit in as a full time role they are not full time business. When they are not full time business they cannot see the market what is happening they have to be there and here as well and in large enterprises this compounds. That's the challenge. Now if you have a cadence set they know what cadence they have to work we know what delivery cadence we need to work so you are deep coupling them in that way you are also bringing centralization decentralization in a lot of aspects and you also drive accountability to a major aspect of it. So I had something here. So when you work in this fashion there is long term planning when they are short turning radius. So the whole idea is you work long term with long term plans because you cannot turn that but if your turning radius is really small I don't need so much of plans. I can work with only a portion of it and that could fit into what is really nicely called as a product backlog. Not necessarily a backlog which is sitting like hundred requirements in one set. What kind of project is this? Is it like support enhancement sort of a thing or is it more like a green field brand new project? What it is? Brand new projects. Enhancement. Right, so if you have to balance between these two you need to take a call what is the new enhancement versus an existing enhancement or a fixed to enhancement. So you need to bring parity into that. You will have to fix that. How much of a risk you want to balance between these two? That's a decision you have not to do. Yeah, so then you can drive that behavior. So the reason I said you have to balance between how much is the enhancement and how much is it because there will be priority set, there will be costs associated to that. So you need to drive based on that and then what the next level of behavior is if it is going beyond your WIP limits and things like that then obviously it will settle. So your WIP limits is saying this is the only capacity that I have. Why do I want to even look at it? Now the point being from a delivery perspective it doesn't matter how big is your backlog. They don't have to see it. I only look at it based on my WIP capacity. So from an input cadence perspective or from a business perspective, sooner or later they will see a point I have given ahead of time and I have to do my reprioritization. So if they have to do continuously on a perpetual trap of reprioritization then their behavior will automatically because that's an elimination of waste in the step of the process. Because one of the things that we do learning in AI cycles from a retrospective perspective you also come back and do a product grooming, backlog grooming. So if you get into this you are perpetually in a mode of doing product backlog grooming for a reason even if it is not being pulled into work. Because this emergent behavior has led you to deprioritize something and on and off if you are trying to do this you don't even put it on a backlog. So that would change that. But if you, but that should come with a clear thing so set the expectations right. Make it very vocal and say that this is what I'm going to take this is my capacity I'm going to take so whatever is there it will lie there that's fine. But the point is we will again go back on the day when we have to pull if that is a priority I'm going to pull and that's the neat thing about Kanban things like you whatever is there as a high priority you take that. So which means that they are also to be accountable on a day in and day out basis. So automatically this you will see it reducing. Right, so it's all about faster feedbacks. Ultimately at the end of the day why would you need this kind of a feedback? Why would we need this kind of a feedback? Yeah, so improvements all that aside. Yeah, reducing the risk of failure you had something. Absolutely, so that is fundamental. Now here is an aspect that you know when we are on a trading on this path I've taken feedback but do I need to act on all the feedback? It's always a challenge because it's never stated I mean feedback is fine but then there is certain decision that you need to take what feedback I can act on and what doesn't make sense to act on. And there is a there are associated cost to that so it has to be kept in mind. So certain times blindly accepting a feedback and just because I want to please a business today and there is a long-term cost associated we will be in trouble. So we need to balance that. We need to take that but then also make it vocal to them this is what would happen. So when you design this ultimately whatever you do like I said there's an economic equation to it. Right, how do you design a control system? What should be that control system? Effective when you look at it from a services perspective foremost from a customer point of view is what value you delivered. It's the outcomes not the outputs. Forget your story points, everything is stupid. Those story points doesn't mean anything at the end of the day because even business today are not able to tabulate. You just blindly go back I've delivered you thousand story points. What does it mean? You just cannot validate it. It's only the outcomes that would validate that. It could be a 1,001 million doesn't care. So it's the value delivered. So that is features accepted. When you have to when they have to accept a feature they also have to be accountable in giving a feature. There's a give and take. There's a collaboration aspect to it. Fine, that is there. But I think somewhere the boundary will be crossed. This will be a customer domain invariably and then you act on it. I mean, there is a dotted line sort of thing. There is from a delivery perspective how much of predictability can you give? How much of effectiveness is there? There are two aspects to it. So predictability is based on Q aging. So this is the point about what you mentioned. So product backlog, how long is it aging there? So that's a very good metric to say that you are putting too much there and nobody is there to act on it. Why are you even putting there? So that will drive our behavior change because even to put there that's a cost associated to the business because somebody has collaborated, they have wasted, they have spent some time in putting it there. So there's a cost associated to that. I mean, if you put an economic equation to that aging factor, it will trickle in the behavior change, right? Cost of the Q. I mean, in the Q I have to make certain decisions. In the, when you say work in progress limits there is a cost of that. How much is that? And when you talk about variability sometimes think about it in certain way that you are doing a high-end engineering work and there is a maintenance support, production down. There are two different end, it's a simple kind of work variability that you are talking about. One would involve a high-end skill. Now, if your product backlog constitutes about more complexity and then you then obviously you need to go to a formation of high-end skills. You obviously cannot do with lesser amount of skilled into that. There is a cost associated to it. If you're trying to do a certain medium to small kind of a requirement where even junior people can work on it and the transactions are much faster like your production down and you have to work in ticket, ticket kind of a mode then you can actually work with one expert with multiple people. So you can actually balance the, so what is the balance between that set of, that kind of a team versus a high-end, high-skill team? So if you look at, again, 80-20 principle will apply if you just want to do it blind, this thing but taking the context of your product and what your problems you are trying to solve should give you a good idea as to what is the team composition I'm looking at for what types of work and that is where you have to make an investment. If you have to constitute a full scrum kind of a cross-functional team, yes, even in an evolutionary approach you still because the nature of work is that but if you try to do this because I respect the process and I have this as a challenge and you try to do this in a matrix style of those kind of aspects of it, it doesn't fire, it will actually backfire. So engineering quality is another aspect of it that has to be there because when you look at software DK this is the major culprit there because at point it will say you cannot do anything, it's not because the cost of change is simply so huge. So I will make a business decision now what to do. So IT is the culprit. I mean, they are actually culpable in that because they did not take the necessary steps. So this has to be better than mine. I mean, we have to have it in mind when we try to go on to the evolutionary path as well. Yeah. How do you measure feedback speed? Feedback speed. I mean, so if you are talking about, say first response in production down, you need to measure first response time, which means to say I have to, so that there is a feedback saying that I acted on something, I have worked on that or a clarification there is there. But in a certain cycle related back to Q aging, your Q aging is correlated to, I mean somewhere you will apply some correlation between this to that. Aging of the Q and this is not there. You have not pulled it up for work because you are missing something. It is sticking there, but you have not got a sufficient feedback. So you may have to correlate. And that is one other thing. It's a interesting question because unless you correlate these matrices, you will not get the big picture. In itself, a single metric would show nice or bad or something, but in correlation, it might give you a different meaning. But sometimes you will not pick up because you have done something, but you do not know where to move. Nobody has given you any feedback on what that content is, what you have delivered. So it is still sitting because as far as you are concerned, it's still in the queue. So that is cost of your queue. It is still sitting there. Nobody has picked it up. Right? I mean, so you will have to, I mean the whole feedback speed aspect, you have to judge it again in the context. If you require a high end kind of a thing and that there's a business domain involved, there's no way you will be sitting on your back without the feedback cycle. Two moments, I'm almost done. Yeah? It could be in the service rate or also the feedback. Yes, it would, but then it's part of the whole thing anyways. You will, your delivery rate will also, so that's your throughput anyway. So I think I have somewhere throughput. Throughput actually will come down, all right? So the idea is when you go to an evolutionary approach, it's the, again, so it's not the maturity and you look at it, it's what problem you are trying to solve. It's the attitude towards the problem solving. The rest of the things are all garb around that, right? This is one aspect to be kept in mind. There is always a constraint. If you have read this book by Goldratt, it's like excellent in that way. It tells you it's constraints are there, but don't make the mistake of misconstruing that as sacrifices, no. It's about putting a placeholder as to how am I going to overcome and what's the time it takes to overcome, but not saying to the, resign to the fact that I will always have to live in this world and there's no change possible. Then be in waterfall forever, because that's a constraint. We have to work towards it. We'll have to make amends for that. And there is an investment to it. There is a cost associated, but at least you have a lever to it. This has to be kept in mind. Without understanding constraints, I don't think we can agile or lean or anything will not work at all. So it has to be this. This idea also has to be kept in mind. And embrace making mistakes. So in an evolutionary cycle, it's more important to embrace mistakes. You cannot get evolutionary. You can't say evolutionary and also first time, right? Because that is somewhere an oxymoron thing. I'm evolving. I'm also trying to understand when you say first time right you have to get your evolving means that doesn't happen. Unless you make a mistake, you are not going to evolve. You are not getting a feedback from that failure. So failure is about feedback. So I need that. So tried and tested means may not be the best strategy at all. So one side fits all, organization scale. This has worked for them. I will want to do it. Those kinds of things may not work. So I want to leave with this probably one more slide. Emergent evolution. What is it? I started with agility and what the meaning or definition as Wikipedia. So I was lucky enough to get us a definition again on Wikipedia on emergent evolution. What does it say? Emergent evolution is the hypothesis that in the course of evolution, some entirely new properties such as mind and consciousness appear at certain critical points, usually because of an unpredictable rearrangement of the already existing entities. The concept has influenced the development of systems theory and complexity theory. Emergentism is a corresponding belief in emergence. So the point is unless you are in that mode, evolution will not be a success. So it's hard, but then that's the reality. As human beings, as animals, we have all evolved, but then it has taken time. There has a certain investment costs. You cannot say this over that and try to get from somebody else and their evolution is not my evolution at all today. So these are pretty good books to refer to and especially the flow one. It's a hard read though, but very, very good perspective from product engineering, but I'm sure we can apply to a lot of IT services as well. I want to leave. I mean, if any questions, one or two minutes we can take, but this is the agile IT services manifesto I was talking about, because I still see a lot of challenge in the IT services world, especially in the way of application of agile, like high maturity agile practices. What does it mean? Seriously, I mean there is something going wrong. People are gungo about certifications for the sake of showing up certification. End of the day, it is not relating to outcomes. How does it matter? So partnering over economics of scale, a lot of customers come to us only for economics of scale. They need bodies. They don't need anything else. Yeah, so there is a deficiency on both sides, both customers and us. I'm not saying that we are great and they are only bad, both sides. So unless we engage ourselves as a partnering each other, it is not going to work. Capability and skills over certifications. Yeah, great certifications are fine, but end of the day what matters is skill. The capability that we bring to the table. How do we make that decisive shift, strategic shifts or situational aspects of it? How can we do unless we have this? So the third one is solutions over RFPs. I work with a lot of RFPs and I think RFPs are brutal. It should be removed out of the entire system. It's atrocious to be doing it because that's the starting step of saying I don't trust you. Give me everything, then only I would. So last, outcomes and values over estimates and productivity, we are still caught up in this. Our control mechanism, want it or not, it's still on estimates and productivity, et cetera. Everything else, the whole organization runs behind that and put those numbers, but no, that's not the thing, right? So thank you, that was my talk. Any questions, I'll be around through the day and next two days, so feel free to ask questions, right? Thank you.