 Hello, good afternoon. My name is Sriram Narayan and I am currently serving as an IT management consultant with ThoughtWorks. Been in the industry for quite a while, over 16 years, in technical roles, managerial roles, product management, marketing sort of roles and in as agile coach consulting, organizational transformation, these kind of things. Lately I am more involved with what I call as IT organization design, which is more of looking at some of the organizational aspects. You know, we are all very familiar with some of the engineering aspects of agile software development, some of the process related aspects and so on. But in my experience, sometimes it is the organizational aspects, the surrounding environmental aspects that come in the way and that is my current area of focus. And that is what I am going to be talking about, which is organizational agility. What are some of the things about the organization itself that comes in the way of our attempts to scale agile? So, a while back I was consulting at this place where they had about 30 development teams and they had gone through a bit of agile adoption by themselves. They had brought in an agile coach, invested in a bit of training and they had chosen a single team among those 30 teams as a pilot and they had done a bit of test driven development, continuous integration, developing stories instead of use cases, stand-ups, retrospectives. They had done some of that and they had got some results. They had got some benefits out of it and it was mostly in the area of what I would call as improving software quality. And then they said, okay, we have done this with one team. Now how do we scale it to the 30 teams that we have here? And that is where I was brought in and this question was asked to me that how do we scale it? And I think this represents a common way of approaching this, where we think that we have achieved something with a single team. A single team has gained certain skills and now we want to replicate it across 30 teams and we consider that to be scaling agile. We consider that to be the problem statement of scaling agile. But I feel it is this sort of replication of some engineering practices and some process elements helps to some extent with scaling software quality. You are able to get better software quality across the board to some extent. But it does not help improve the reputation of IT in the eyes of the business overall. They still say, you say you are doing agile and all, but from where I see it is still taking as long as ever and we are still facing the same problems and so on. Because there are some other aspects to it. When we talk about scaling agility, software quality is one aspect of it, but it is also about overall speed. A single team might be able to do its work a little more quickly, but at a program level are you able to turn things around faster than before? So, time to market, are you able to bring about the improvements in time to market at scale? And it is also about value addition. And there is something that IT usually never takes responsibility for. We say, business tells us what to build and if that is not adding value then business needs to have thought out better what to build before they ask just what to build. And if it is not really our responsibility here because we are operating in a project mode where you know there is a business has made a business case for what to build. They have got some funding and out of that funding we have started off a project and the project basically says, you know this is the scope to be delivered with this budget by this time. And so and that itself is a challenge for IT. So, if it is not really helping with business outcomes, then IT often throws up at hands and says, you know, but we did not define the problem or you know the overall solution, we mostly just implementing it. And so I feel unless we address all of this we cannot really say we scaled agile we can say, but you know business is not going to be impressed by it. They will say, okay, if you say so, if you insist you scaled agile, but you know I do not see any real difference. And so this talk is more relevant to people who are directly serving their own businesses. Not so much IT services, if you are in IT services, this talk is more relevant to your clients and that might be a good reason to listen to it. But by what I mean by the target audience here is like internet businesses, if you're an e-commerce company or if you're like an or if it's like a taxi hailing company, these companies are hot these days. Or if you're an ISV SaaS product or some other kind of software product or if you're a global in-house center, your IT is serving your own business, right? And that's the real core intended audience for the rest of this. And what do I mean by organizational agility? Like I said earlier, IT agility is really supported on three pillars. Engineering agility, yes, is must, it's necessary. Process agility, it is a must, it is necessary. But these two by themselves are often not sufficient. We also need what I call as overall organizational agility. And the foundation for that is the right sort of agile organization design. And what I mean, I'll come, I'll share some examples of what I mean by that. But this organization design has several aspects. It has structural aspects. It has operational aspects, cultural aspects, and even political aspects. So to illustrate with an example, again, I was at this place where I was brought into help. The situation was that, you know, the client told me that we were adopted agile, but we are not really seeing a huge benefit because we are still getting a lot of defects very close to the release. And this is dangerous for the release, it can compromise the release. We seem to be doing TDD, continuous integration, user stories and so on. But somehow, we are not solving this problem. You know, there are a lot of defects at the very late stage. And so I looked at the situation and, you know, talked to several people and understood what's going on and made a few recommendations. And I want to talk about one particular recommendation and the resistance that I got for that recommendation. And so the situation was this. One thing that I observed was developers used to claim that a story is dev complete and move on to the next story by themselves, right? And there was no verification at that stage itself saying, okay, you're claiming your dev complete. Let me check whether you're really dev complete before you move on to the next story. There was no verification at that stage. What would happen is that on a periodic basis, the builds would get deployed to the test environment and testers would attempt to test. But what was happening in this case is the deployments themselves were brittle. So very often, the testers would not even be able to access that particular feature that the developer claimed to be complete. And in situations where they were able to get till there, they would find that there are several things incomplete about that feature. I mean, their understanding of that feature was different from the developers. And so it would, it used to come back and there used to be a lot of finger pointing about who said what about that story and so on. So one of the, you know, we talk about early feedback in agile. And this is an example of there was a scope for bringing feedback earlier in the process rather than a developer claiming that it's complete. And then after a couple of days, it get deployed into the test environment. And then the testers realizing that it's incomplete. Why not have some feedback right then? And we call this is a common practice among some agile development teams called dev box testing, where the moment I as a developer, if I think I'm done with something, I can't simply move on to the next story. I have to call the some tester or an analyst who knows that story and say, I think I'm done. Why don't you take a quick look? And this person will spend, say, 10 or 15 minutes going through some of the major scenarios, the happy path scenarios and say that, okay, yeah, you're good to go. Move on to the next story. Or they might point out that, hey, this particular acceptance criteria, you've covered this case, but not this case. This is missing something, something. And I'll just note it down on a sticky note or something. And I'm expected to finish it then and there, take a few more hours, or maybe a day, and only and again, I'm supposed to call them and say, hey, now take a look. And if they say, yeah, you're good to go. That's when I can call it dev complete and move on to the next stage, right? So I said, why don't you do this? This is one way of ensuring that you don't get this sort of, you know, bad news after three days, you can resolve it then and there. But strangely enough, I encountered a lot of resistance to this particular suggestion. And they were as follows. The first thing was a little bit about this will upset our plan for the day. We have planned our hours in a certain way. And how can a developer simply say, hey, I'm done, why don't you come over and test? I mean, I have, you know, I have planned some work to do. That was one. Second was, but this is a violation of the process. I cannot simply test sitting with a developer and point out bugs. I'm supposed to log the bugs into a bug defect tracking system. I'm supposed to recreate and provide the steps for recreating it and so on. And then it gets assigned to the developers. That is the process for that is the, you know, bug lifecycle, how can I just have this informal conversation and be done with it? And then the third thing was, you know, about regression and traceability. Like, how are you if you just say that you'll just have this conversation and fix it? How do we ensure that that same problem doesn't creep up in the future? And so they were kind of valid objections. But we had our I had my responses to that first thing regarding time, right, within a team, you're supposed to collaborate pretty much in a very ad hoc basis. You don't have to book time on somebody else's calendar if you're part of the same, same development team, right? And if you're requiring to requiring to do that, then there is some some issue there, that is one. Second is this whole thing about not following the process. He said, Okay, fine. Follow all that process about logging the bug, etc. When it formally comes into the test queue, this is more of a informal initial sort of testing just to give the developer clearance to proceed to the next story. And you can follow all that, you know, bug life cycle, everything, when it's formally deployed into the test environment. And if you find some issue there, do it for that. And as regards the third one regarding, you know, regression and traceability. I mean, it's a common, commonly accepted good practice, when you're doing test driven development, that if somebody points out something that is missing, when you're first expected to write a failing test to recreate that situation as a developer, a failing unit test, then write the code to fulfill that condition. And thereby, you will have a test that is now part of the test suite, and it's part of your regression as well, right? So they heard me out, but they were still not fully convinced. They said, you know what, we have a process quality group who determines the processes that we have to follow. And they will flag this as a non-confirmance if I say that I'm not going to log this bug. I know I'm only going to log it when it's finally in the test environment. So we'll have to get approval from them and we don't know if that's really going to happen. That was one. And the second thing regarding this whole test based regression thing, like, you know, they were more like, oh, this is going to be extra effort. We have not estimated for this effort as part of the developers thing, those sort of things. But again, my counter argument was, if you really think you're doing agile, one of the core principles is working software over comprehensive documentation, right? So this is where rubber meets the road. If you say that during Devbox testing, what I'm concerned about is working software. I'm more interested in fixing the bug rather than documenting the bug at this stage. So you should be able to trade off this documentation thing in favor of getting software working. That's what we mean by working software over comprehensive documentation. And there is no real need for a separate process quality group oversight as far as agile is concerned, you might have it for some legacy reasons. But you know, I as an external consultant can recommend that you don't have to if they are coming in the way of following this, you don't have to listen to them. But again, it was beyond their level of decisions, right, they can't they can't take these decisions. And that's what I mean by organizational agility. The surrounding organization is coming in the way of getting things, making things better. But it also turned out that there was a even deeper problem here, which they were not even, they were a little bit shy of telling me and I found it out later. And that was that it looked like one development team. But actually, the developers belong to an engineering department and the testers belong to one testing department. And the way things work was that they were departmental KPIs, right. And the test department's KPIs included metrics like how many defects were found. And so now if you don't log bugs, then that's going to affect that metric. And again, this was beyond that teams decision making capability to say that you know, we can't, we can't do this. So again, the again, what is the impediment here? It's a governance level impediment, the way metrics have been conceived and decided for departmental performance. And unless we address those things, we are not going to have overall agility. So yeah, like I just mentioned, the impediment they had nothing to do with engineering or scrum processes or anything, they were more the surrounding organization, the way things the teams were structured, the way the metrics and KPIs were designed at departmental levels, and the whole ideology of absolutely having to document everything, the and not really understanding what we mean by working software over comprehensive documentation. So this was an example where, you know, the parties where the development organization and the test organization. Next, I'll talk about another incident. And the parties here are the development organization and the IT operations organization. And this was an insurance company where the development team had just made a release of a claims processing application. And it was in it was put in production, it was tested functionality wise and performance wise for about 10, 20 users, it was tested. So now it was the ball was in the operations teams quote, and they were responsible for the availability of this application. But as usage grew, you know, they were the people who are processing claims, they are called the claims adjudicators. And the way they use this software, this application is that they would for every claim that comes in, they have to go through a workflow of five or six pages, okay. And they take maybe seven or eight minutes to process a single claim. And what they were finding is that they would go to three pages. And while they were filling information on the fourth page and they hit next, they found that the application had crashed, it would take them back to the login page. And this was happening frequently. They started logging tickets. And it then they escalated the issue. It went to the operations IT operations manager. He asked his engineers what's going on. And they said, yeah, this is a known issue. The application is unstable. We keep getting occasional tickets that it has crashed. And once we get the ticket, we manually restart it. I mean, what else can we do? And but they have but no, but that's not good enough. I mean, what else can we do really? What is the problem here? And they said, you know, if it's they tested it for about 10, 20 users, and it was working fine. But now it's 150 claim adjudicators are using this application. And it's crashing every now and then. It's really what's needed. Maybe there are memory leaks and issues like that. So what's really needed a development team has to take another look at it, do some profiling with greater load and on and give us a new build till then we all we can do is restart. So why don't you talk to the development team and ask them for fixing this. But the issue here is the development team had already moved on to other things. The funding for this particular release had run out, right? And the operations manager was not in a position to really reach across the organization. This was outside his jurisdiction, right? And so he couldn't like say he was not in his you know, power to make that another release happen quickly. But at the same time he was accountable for availability of the application, right? It was it has been delivered to operations and they are responsible for availability. So he said what can we do at our end and the solution they came up with was something like they would check this process every minute. And if it is if it is not running anymore, they would automatically restart it. And they also wired up a dashboard. So they had another job which a monitoring kind of job which would ping the first screen every five minutes. And so if you if you pull it say hundred times and 98 times you find that the page comes back, then approximately you have 98 percent availability, right? So they plotted this on a dashboard and put up an information radiator saying up time for the claims processing application and we were showing is 98 percent and you know they said yeah this is what we can do and we have made it available now. Now did it really solve the problem? Not really because if I if I as a claim adjudicator if I am on the third page now I go to the fourth page I fill some things. In the meantime it has died and it has been automatically restarted fine but it's not going to remember what I did on the fourth page. The moment I click next again I will be taken back to the login page. Again I have to do some amount of rework, right? And now this becomes a hard problem to surface because like even the claim adjudicators when they complain to that manager their manager saying that you know every now and then it's failing and I have to repeat some of the work that I did. When their manager logs in it would work fine because it's only when you use it for sustained for about 15-20 minutes and try to process the claim throughout that seven six or seven pages you would find that in the middle the server has died and it now it's taking you back to the login page. So what is the is this overall an example you know how can you say agility delivered in this case? No the development team will say yes we finished the release and the operations team will say we are responsible for availability and we are done what we can for availability but who is there is nobody responsible for the overall outcome here right because the outcome is not defined as IT is responsible for effective claims processing no it's like the development team is responsible for making a release and the operations team is responsible for availability. So again these are organizational things that come in the way of overall agility the way things are structured clearly DevOps is not in place here right development team is a totally different team and operations is another team structure is a problem and accountability the way accountability has been defined is not along lines of business outcome it's along the lines of making a release keeping the application running those kind of things. So talking about structure I want to talk about structure a little more because when we talk of continuous delivery why is continuous delivery important because it promises faster cycle times it promises faster time to market but for that to really happen you need to have small batch size what I what do I mean by small batch size see software development value stream is relatively small it's like maybe analysis design develop test that's it but the overall product development value stream is much bigger it starts from market research and ends with a paying customer right and when we talk about continuous delivery having a business impact this overall value stream has to have a short cycle time and there is a difference between making frequent releases and achieving short cycle times okay so for example if I have a huge backlog and every item in that backlog takes six months to complete my cycle time is six months right I might be making one release every month but that's just because I'm just turning through items in the backlog so I started something in Jan and I delivered it in July I started something else in Feb and delivered it in August so I'm making monthly releases but my cycle time is still six months to bring down cycle times even in it's a in queuing theory and it's generally acknowledged that you have to have smaller batch size what do we mean by smaller batch size you have this value stream work progressing from left to right if you progress try to progress one release worth of functionality across each of this that's large batch size and that's going to take much longer as opposed to that if you try to progress one story across all these verticals that's much smaller batch size right so smaller batch sizes will lead to shorter cycle times but it's hard to do small batch size if your organization structure does not cooperate if your organization structure is set up as an IT matrix for example where there are you know there is vertical for architecture work it to vertical for development testing and so on UX database whatever then your handoffs between these verticals are going to be very expensive and if handoffs are expensive you cannot have short batch size because when you reduce the batch size the handoffs multiply like if I'm a developer and there's a tester in front of me if I develop one use case completely and give it to the tester there is just one handoff but if I break down that use case into 20 stories and I develop story by story and hand it to the tester there are 20 handoffs right but that is what shorter cycle times require small batch size but you cannot afford small batch size if the cost of the handoff is high you need to reduce the cost of that and what is the way of reducing the cost of the handoff you have to break down the organizational boundaries that are demanding that are increasing the cost of the handoff when you have organizational boundaries your handoff will include documentation schedules dependencies and so on protocols and that's going to increase the cost of the handoff which is where we talk about a cross functional team a cross functional product team that's outcome oriented a more like how ISV product teams are set up and a lot of ISVs and even some internet businesses already get this they are not organized as a matrix in their IT they have these a product organization and they have a cross functional team that is serving that product and that team consists of different kinds of specialists UX people developers, testers, data scientists whoever is required in sales engineers everybody who together take ownership for that business outcome so what's stopping us what's stopping rest of enterprise IT from adopting this model of a cross functional team that is outcome oriented one thing that's stopping us is our whole fetish with utilization we feel that you know if you have these matrix sort of organization we feel I'll have a pool of specialists who I can allocate on demand to different teams four hours a year, two hours there that kind of thing and thereby maximize utilization of all the specialist people but this is a kind of premature optimization as we call it in English in engineering what you are achieving maximum utilization but on the flip side your overall IT responsiveness your time to market has gone up like my Twitter friend Paul Sutton he talks about this issue and says you know a fully utilized highway is a traffic jam and that's what we create inside IT when we focus too much on utilization the second issue is challenge of staffing a cross functional team for a project duration a project what is a project a project is a temporary organization lifetime of a project is usually six to eight months maybe one year for this short period it's very hard in today's times to staff a cross functional team it's hard as it is to staff just developers and testers but to staff a cross functional team for a project duration is very hard so we need to rethink I mean is project really the best vehicle of IT execution and why why have we stuck with projects last 20 years industry has been used to using projects for IT execution why because the project as a model promises predictability what is the project the project basically says I have this much approval of funds for building something and the project plan says yes by using this plan using for this much budget and this much time we will be delivering this much functionality it's promises predictability and it allows us to kind of constrain the problem that we are trying to solve put a frame around it and manage it in theory it promises all this but in practice what is the track record of project delivery and has project approach really served the business so there is this research and advisory group called the standish group and for the last 20 years they have been collecting industry data on project performance and they call they release a report called the chaos manifesto and a 2013 report talks about sub million dollar projects projects less than a million dollars since 2004 and what they found is that the average cost overrun is at least 40 percent and the average schedule overrun is at least 70 percent for sub million dollar projects and for bigger projects it's as they perform much worse so what we have here is clear data that apparently in theory this project model should work but in practice it has completely failed and on the other hand it is stopping us from moving towards things like a cross functionality which is really required for continuous delivery so people have started rethinking whether projects model is really the best model whether we should move to a more of a product centric approach where the focus is more on value addition and not on being on plan and this is a recent article from the wall street journal which talks about companies like GE capital Intel and Whole Foods where IT is no longer just signing up for IT level metrics that you know I delivered this within budget you know on time and therefore IT is successful no IT actually signs up for business outcomes for IT signs up for value addition and it is organized in such a way that it has all the people required to realize those outcomes right so value addition and outcome orientation are becoming more important than plan conformance but can we really make this change can we go to our places and shift from a project centric model to a product model or some other kind of model there are some things that are coming in the way of that so why are we what is stuck one thing is the funding model the way projects get funded somebody in business realizes that hey I need this new feature or set of features and if I have these features I am going to get so much more revenue right or something I am going to get some sort of business advantage and they make a business case for it a business case includes cost versus benefit right so cost is estimated they say okay let's estimate how long it's going to develop this how long it's going to take to develop this so they come up with some cost numbers and they do some other cost of capital borrowings IRR NPV some of those financial formulas and they also project the benefits that they will get out of it and that's how they make a business case and once the business case approved funds are allocated and a project can begin but the problem is the funds are allocated on the basis of this plan the business case is nothing but a plan saying I'm going to spend this much money over one year to build all these things and this is the benefit I'm going to get and somebody takes a look at says okay that being the case I'm sanctioning funds so funds are already tied to a plan right if it's already tied to a plan then all you pretty much have to do is spin up a project and try to execute that plan whereas in a product centric model and the value addition kind of model that we're talking about you don't start off with funds being tied to a plan instead you start off with funds being tied to some objectives so I'll say my objective is I want more effective claims processing for example right not like okay I'm going to build these two features and this is this you know size estimate and this is the time estimate and this is the plan once you do that and the funds are tied to the plan you pretty much know I have no option but to do it as a project but if funds are tied to objectives then whoever is accountable for realizing those objectives a product owner or somebody in IT can change course as they go and say I'm still staying true to the objectives but I can change course and I can because the nature of software development in product development is that we as we build things we realize what is really required you cannot do a lot of upfront analysis and hire some domain experts SMEs and so on and say this is what exactly needs to be built many people have tried that and it doesn't work it's not about market situation changing you know or change requests coming up in the minds of business from nowhere like changes that you should have thought of on day one they are suddenly coming up after two months it's not like that it's more like the nature of product development is that as you see what is getting built you begin to understand what you really want or what is really needed to solve the problem and so the process the execution model has to accommodate for this learning on the fly but if it's already funds are already tied to the plan then you cannot accommodate for learning on the fly you can do very minimal scope negotiation but that's about it so that's one reason that I feel we are stuck with projects and the other reason is our mental model of software development we think obviously projects ought to work and project what is the project plan project plan is basically a big prediction right it says we'll deliver this much scope add with this much money by this much time and we think obviously it ought to work because after all you know it works in many other domains it's a production process like any other thing because in ancient school textbooks we've been taught that there is you know analysis design construction testing right so we equate it's like it's a construction activity it's got to it's like a production activity and so it's got to be predictable but the truth about software development is it is not a production process the environment in which you develop software is called a development environment right the production environment is the environment in which software runs so that is the production process if you want to manage something as a production process you manage the production environment if you want to manage the development environment that's a design process and design is inherently easy has unknown unknowns subject to unpredictability you can only learn as you go and you can basically say give me the objectives and I'll give me the freedom to make course corrections along the way and I'll keep staying true to the objectives right but if you give me a plan then I cannot learn along the way and for this again the once we this is a bit of a you know big shift I mean for those of you who have not heard this before if you're not shocked by what I'm saying you have not understood it the realization that this is not a production process it's a design process sort of a game changer for governance because governance no longer looks at it as how do I control the process how do I predict the process governance looks at it and says how do I get value out of the process despite its inherent unpredictability right so let me set aside prediction let me deprioritize predictability and certainty but let me prioritize value addition so I explore all of what I said and more in a book that I wrote and it's going to be published in a couple of months called agile IT organization design it has chapters like team design accountability business IT alignment projects finance staffing tooling metrics and more so do check it out when it comes out and if you're able to relate to the incidents that are narrated and see I believe that in all of these things what is missing is organizational agility that it's not in the power of the development team or the scrum master or even the program manager to do much about this it is up to IT leadership IT governance executive sponsors to do something about this right and so if in the audience if there are such senior people and if you have done things to make a difference in this regard I'll be happy to hear from you send me your stories to sriram.norain.thoughtworks.com I'll go through your stories and the two stories that I like I'll send you a free copy of my book when it's published in June so yeah I'm open for comments and questions thank you what I do is typically if you take ISV a product development team they don't they have a roadmap overall product roadmap but when they do the budgeting for the year they don't go by okay what are the things we have is there in the roadmap for this year what is the size estimation and convert that into cost and that's how the budget no they don't go like that what they instead do is they say you know what we are going to maintain a 20 member development team on this project for this year we know that you know we are going to keeping on investing in this product we have had some sales so they do budgeting based on team capacity not based on and therefore if you once you do budgeting based on team capacity you don't have to have upfront estimates at the time of budgeting right so this is the approach that many of the product centric so the budget is allocated for the head count okay now it's up to the product manager somebody to decide the mix given the budget yeah that the product manager can decide that given the budget whether he wants to hire employees or contractors or outsource some of that work you know but the budget itself is sanctioned based on team capacity and that's a strategic allocation across because there will be you know different competing things and this is not just applicable to ISVs if you take the insurance example right you can conceive of even enterprise IT as different capability streams like if in insurance for example what are the if you break it down take a you know stab at it there is customer acquisition there is servicing of the policy and then there is claims processing right so you can think of it as internally I have three capabilities these three capabilities and each of these capabilities if I create a team like a product centric team for each of them they are going to own a bunch of applications and systems everything related to that business capability so I'll have one capability team for customer acquisition one for servicing policies and one for claim adjudi claim processing right and then you can decide at the time of budgeting that okay this year our focus is more on new products so customer acquisition gets a bigger team claims processing and policy servicing they are going to just maintain their team sizes this way bigger is a very adoptive you know how big sorry bigger is a very adoptive I can always say this is bigger or it will be two times other team how would you decide the size oh how you decide the actual size is based on like your sales forecasting right you ultimately you say this this year I sold this much next year these are my projections right I want to sell this much to sell this much what are the you know roughly do I need to yeah you kind of work backwards from the yeah team sizing not feature sizing against what sorry team size against against expected business outcomes and that outcome production can take only two come again sorry so I am saying the expected outcome and be driven by two people or 20 people depending on the innovation the team does because you don't know what the team will do what you no expected outcome I mean more like you know sales like if you have a you know if you have three lines of products right you know that this is these these are the the products are in different stages of maturity there is a H1, H2, H3 kind of model so H1 are products that are already making money they are standard H2 is more like emerging products and H3 is more very innovative when we don't know where it's going to go that kind of thing so based on that you do a strategic allocation saying okay I have I have this much money to invest my capital budget expenditure for this year this is what I have and I'm going to do relative allocation you're going to get 40% because your priority and the rest both have to share 30-30% and then you work backwards from that saying okay with 40% what kind of a team you can support do you want to use the mic sure yeah that's why I said so you're in IT services yeah okay yeah like I said before right this needs the true true so this is seen what I'm suggesting like I said before the target audience the first immediate target audience is not IT services because there there is a there are other complications that come into picture but if your clients get this first if your clients buy into this they will find a way in which you can work with them in this model right so but that's when outsourcing comes into the picture then you cannot as the vendor you cannot it's very difficult for you to initiate these changes I agree with you there is no chap but I do like in the chapters on team design and staffing I do cover some sections I devote some sections to outsourcing yes and speaking of outsourcing right in a product centric model see what's happening now is previously people when they used to outsource you outsource what is not strategic to you right you keep your core competencies with yourself and outsource the rest but increasingly IT is being perceived as strategic especially IT development and so some big companies have started in sourcing they've started reducing the amount of work they outsource and that because that gives them the ability to run this kind of a product centric IT organization right so yes I mean potentially the whole IT services industry might get disrupted in the next 15-20 years if this trend carries on yeah and we'll have to figure out new ways of engaging with our clients if there are no other questions thank you for your part yeah right so here is here is my you know proposal and I say as much in my book is that market needs come first right vendors need don't come first from the clients point of view and if the market is telling the clients IT has become strategic and the way to be really responsive is to go to a product centric model clients will go right whether outsourced vendors want it or not and when that happens they are going to give less and less project ownership to vendors they are going to say at best you can provide staff augmentation to us make make your people part of our product development teams right and then there is no like project plan to which you are held to deliver and that might be the future and you know whether we like it or not we might have to adopt to that situation alright thank you so much for your participation