 Agile India 2017 is Asia's largest and premier conference on Agile and Lean methods. This year's conference will take place in Bangalore starting on Monday, March 6th, where experts and practitioners from around the world will share their experience. For more information, please visit our website, 2017.agileindia.org. Our guest today is Evan Laborn. Evan is an executive consultant at IBM based out of Singapore. He has over 10 years of business leadership experience specializing in Agile business management. He is the author of Directing the Agile Organization, a Lean approach to business management and speaks regularly at both local and international conferences. Evan, thanks for joining us today. Thank you very much. So it's good to see you again, Evan. We've met up with you at previous Agile India conferences and always good to see you in your three-piece suit. I think I've now been to five Agile India conferences and always with the three-piece suits and always having lots of fun. So you do have the opportunity to go around the world and see these different conferences and different Agile communities. Is there anything that stands out about the state of Agile and the Agile community in India? Oh, I think I've been lucky to see the growth of the community. Five years ago I would have described it as immature. There were pockets of, excellence there, pockets of organizations really being Agile. But the vast majority were just either getting started or hadn't gone beyond, the basics hadn't gone beyond shoe, hadn't gone beyond doing Agile. I think over the last five years we're seeing more and more organizations really start to adopt the Agile mindset, the mentality, and increase in their ability and their capability to be Agile. And so over the last five years, seeing that growth has been very interesting, especially compared to others. And a lot of the other countries where, I don't mean America, obviously, but a lot of the other countries are still sitting in a very immature state. What would you say is the catalyst? I think that's really interesting how you say that you've got a community that's a very vibrant growing community, but they've made that transition from just doing Agile into really internalizing it and the mindset and adopting the mindset. Is there certain catalysts that enabled that? And can other communities try time and success? Time and success. If Agile, an Agile delivery, and we are talking technical Agile here or Agile in software, if it wasn't successful then companies would abandon it. But with a little bit of success, there's an impetus, there's momentum to continue to improve. And a lot of what I talk about falls under the domain of business agility. And I talk about how organizations, there's a theory of Agile constraints. And organization can only be as Agile as its least Agile part. And in many cases, that's not IT. But with time and success, organizations realize this. And so they start to emerge, or business agility starts to emerge within different organizations. And when they're going and they're looking at how they can improve, they start to realize that being Agile is where they need to go, where they need to improve. Whereas the baseline of doing Agile, that's been done. They've succeeded at that. And so, of course, a lot of organizations don't improve beyond that point, but many more do. I find that interesting because I think a first step probably when people think about business agility is just agility outside of IT. But you're talking about it going a step further into changing. It's a fundamental shift in the way the business is run. And you can't just have little pockets of agility. But the whole business itself has to function differently. Is that what you've seen? Yes, absolutely. And companies in India are starting to come to that conclusion. In many ways, in the same way that companies in other countries in America or in Australia have been coming to that conclusion. If an organization can't think in an agile way, then you are fundamentally constrained in your agileness, your ability to adapt to market changes, your ability to innovate. Because take the budgeting process as an example. If you're being agile with an 18-month monolithic budget that is pre-selecting specific projects to be done, then whilst those projects may be agile and you may use scrum for that, you're not going to be able to actually capitalize on momentum and movements in the markets, in the economy, within your clients. So I'm seeing a lot of organizations in India start to realize that yes, agility in technology is one part of it, but it's got to go well beyond. So how do you tackle that problem? How do you bring whole-scale business agility? Businesses are complex systems. It's very difficult to go in and try and have an impact in one specific area when there's actually a number of different things that have to happen simultaneously. So what do you do about that? Oh, there's no single answer. I wish there were back in my life and much easier. In many regards, we've already solved this problem. Every time a large organization's IT division goes agile, they are thinking about a complex adaptive system. They're thinking about the interfaces and integration of multiple teams. Scaling that across an organization requires nuance. It requires understanding how finance works and how HR works. And it requires understanding the integration and interfaces between different divisions. But at the same time, that transformational activity can be self-directed. Organizations and given the right catalyst can actually move in that direction by themselves. Others will bring in coaches and transformational consultants. Others will do it slowly piecemeal where they'll pick agile outside IT. Others will do agile marketing next. And once they get a few more successes, once again, the equation of time plus success, and we start to see a little more organic growth. So there's no one size fits all solution. It depends on the appetite of change for the organization, the cultural aspects of that organization, and whether agile is part of their operating DNA or whether agile is something that is foreign to them that they're trying to learn. I hear a lot of interesting metaphors like their DNA, and Steve Denning talks about agile being a mindset, but these are kind of transient, hard to, you can't hold these things in your hand, you can't just go and purchase agile mindset off the shelf. So how does a company get there? How do we get from A to B? Well, okay, metaphor and stories help conceptualize a complex problem. So DNA and buying the mindset off the shelf, it helps us conceptualize something that's highly complex and impossible to sort of grok, impossible to hold in our head. It gives us the ability to think we understand it. Now, as an organization, we have to go beyond the metaphor. It's a good starting place because it gives us something that we talk about operating DNA, say, I know what that means, no you don't. You have an idea what an operating DNA might mean, but in your organization there are thousands of employees, there are tens of thousands of moving parts. When someone says the sum is greater than the parts of its whole, so 1 plus 1 equals 3. In an organization, 1 plus 1 plus 1 plus times a thousand equals, not 1,000, equals 100,000, a million. The number of connections and moving parts in an organization are so complex, so dynamic that these metaphors help us conceptualize it, we need to understand that the organization is not the metaphor. That's actually the problem that has happened in the project management space, for example. We create this operating metaphor of a project, we create this metaphor of a simple single process, and we use that, we apply that, we cook it. Every single time we apply the same pattern, the same metaphor, and that assumes that the work is the same. If I'm building a bridge after a bridge after a bridge, I can use a very similar pattern. But in most of the work that we're doing, in the knowledge workspace, applying those patterns, applying those metaphors without understanding the fundamental complexity and the nuance in the work that we do starts to break down. Now, not every single human can hold that in the head, and this is where agile organizations thrive, because if I have an organization where the leadership is not in the single CEO, but is divested into the organization, where individuals and teams take ownership and accountability for their work, as a CEO, I don't need to understand how 100,000 people or 1,000 people, 100,000 connections, I don't need to understand what they're doing. I just need to know that they're pointed in the right direction. The teams, the individuals, they take ownership and accountability for their work. They can decide what is the best way of working for them, and so we can move away from these platitudes and simplifications and actually go, you, your team, self-organizing, maybe even self-managing if you want to go that far, at least self-organizing, your team of 10, 15 people, five people, you know what you need to do. You know the connections, you know the nuance, you know the complexity. Do it. You have an outcome that you need to achieve. You need to know the opportunity and downstream teams that you need to connect with. You don't need to know what that team three countries away is doing because it has negligible impact on you, no more so than a separate company in some cases. And so we have this separation and it allows individuals to take, because they know the details, they can be very deep. And the CEO and the CIO and the CFO who sit at the top don't need to know what everyone's doing in a very specific sense. They just need to know that there's a common direction and some common principles and governance around that. So you mentioned something really interesting there. You mentioned that we take this concept of a project and it's really a metaphor and we reapply it over and over. And when it might not necessarily be the best place to do so, there might actually be other methods of working. And this is a lot of where your work has come in with the no projects and the no project space, which to me, and feel free to correct me, my explanation would be where mindset before has been that's projectized work and find work and build projects around it. Let's take that on its head and take what traditionally we would think of as these projects and operationalize them and find ways to just make them as part of the day-to-day operations of our companies and move away from trying to just turn everything to a project. Is that a decent description of no projects? I describe it as the alignment of activities to outcomes measured by value and constrained by working principles. And for me, that description sort of encapsulates the three elements. Value, activity, outcomes. We do work an activity that creates a value and that value improves a business outcome. Now that seems, once again, it's a metaphor, it's something very, very simple. But a project is a temporary endeavor to create a product service or result, that's the definition. So if we can structure our work so that it's not temporary because our work isn't temporary anymore. If I'm building a bridge, right, to cross a river, when that bridge is complete, I can't add more features. There's no upgrade to that bridge. I can maintain the bridge and I need to maintain the bridge, otherwise the value that has been created will degrade. But the maximum value, once that span is complete and the bridge is painted, the maximum value of that bridge has been created. It is realized every single time someone walks over the bridge or a car drives over the bridge, but I can't add features. Someone can't come up with an idea of, oh, hey, how about we do something else? I can, okay, it's a metaphor, so yes, we could build a second bridge and whatever else, but realistically, as a metaphor, it works fairly well. The work that we do is not the same. IT, marketing, HR, finance, there is no doneness of value. We can add more features, we can add more capability, we can improve the value of the product. And if we have a structure that has a continuous improvement of value rather than a temporary stop-start concept, that continuous improvement of value is going to, well, increase the outcome that we achieve. Now, if we align that with things like agile, inspect and adapt, so we're continuously looking at the work that we do and going, what is the work that we're doing continuously adding value? And there isn't, there's a natural end of life of a product, right? That software or marketing campaign is going to naturally end at a particular point. But when we talk about the duration and scale of a project versus a product, they are orders of magnitude different. I was thinking about this concept of a business outcome and I think there's a lot of the outcomes we think of are more or less become proxies for profit. But I think you're talking about something different than that. Different than just focusing on quarterly results and shareholder value and that kind of thing. So can you walk us through a bit more of what you mean? There's a great story by Frederick Lalu in his book and I'll paraphrase. Profit is like air. We need to breathe in order to live but we don't live to breathe and that's I think quite insightful. As an organization, we need to make profit. We need to survive. We need to be able to pay our bills, pay our staff and we need to have enough money in the bank, enough capacity to survive the trials and tribulations of business. So when business goes down, we don't have to start laying off staff all the time. There's enough money in the bank. So that means that profit is important but perhaps except for banks. No organization, they go into business and their business is profit. Their business is manufacturing something. Their business is creating a service or a product, mowing lawns or creating software or building bridges. These businesses have a rationale, something that they want to do, something that is their expertise, their passion and these are the outcomes we're talking about. Yes, everything needs to make a profit but that is not what we do. It is just what we need in order to survive. Does that make sense? It does and I think a part of what you're saying about differentiating between value and business outcome is the value is being created by the actions that we take in building a bridge is creating value but we need to understand how is that connected to some ultimate goal that we're trying to achieve which has all sorts of overlaps with leadership concepts and changing the way we lead outcomes are very hard. In the last Agile India, I gave a talk called if you need to start a project, you've already failed and in that I described what we call an outcome profile which is a very simple model to define a business outcome. What is the outcome? What is the measure? What are the targets? What's the baseline? Who owns it? What are the dependencies? It allows organizations to think about outcomes at an organizational level rather than focus on the thing that is being done and too often organizations when they start actually let me take a step back. I used to be a project manager. I used to write business cases and in every project business case there's a section on benefits and benefits are wonderful things and your finance division is going to give you money for your project based on the business benefits that you say that your project is going to create. Now there's two problems with this. Number one, actually there's three problems. Number one, the business, the money for that project was allocated 12 months ago in the annual planning cycle. They're going to give you the money you just need to convince them that they should. But they've already made the decision so the bar to actually convince them is very low. Number two, in a project definition a project is meant to do something but the actual realization of those benefits is not the responsibility of the project which means I can get away with anything. I can say this project will save 20 million dollars. I can deliver on time, on budget and on scope. I can deliver a successful project and yet completely fail at delivering the business benefits and yet I'm still successful because as a project manager I have achieved what it was that was defined for me. The organization has failed but I have succeeded so there's a dichotomy there. The third thing is actually about the benefits themselves. Because the bar is so low and because we already know what we want to do we invent these benefits to try and justify doing what we want to do. And so what happens is we go all right this application will save two minutes per person per day so therefore that's two million dollars a year in productivity say no it's not. No organization can realize two minutes per person per day. That is not actually a reasonable benefit that can be achieved. Likewise sometimes the benefits are very clear we can decommission something but more often they're not. They're just a line on a piece of paper that never gets actually tracked or never gets realized. The alternative is to actually put it around. Don't start with the what you want to do. Don't start with an idea of hey we should upgrade this system and it's going to have these benefits. We need to achieve these business outcomes. I'm going to fund a team a certain amount of money to achieve these business outcomes. I personally don't care how they do it or more accurately I don't care what they do in order to achieve those outcomes as long as they comply with certain principles they don't break the law they play nice with the other teams they collaborate whatever principles we as an organization hold dear constrain a team's ability to do anything but within those principles I'm not going to tell you what to do I'm just going to say that every month we're going to inspect and adapt we're going to say if the business outcome is to improve staff improve staff satisfaction we want happy staff this team happy stuff is worth to us a million dollars a year because of attrition rates and retraining and whatever it is. I'm going to pay $500,000 to this team that's what it's worth to me in order to achieve happy staff in that 100,000 dollars you're going to pay the salary of the team members there's some level of funds that are available to do something else if they need to hire somebody else they need to make decisions or buy products or whatever else but if it's worth a million I'm not going to spend a million because I could be wrong but I think it's worth a million I'm going to spend 10 to 20 to 30% of that that team is going to, every month we're going to look at the attrition rates the employee satisfaction surveys whatever measure we put against staff satisfaction and that team is going to inspect and adapt the work that we've done has created value that value has had a meaningful impact to the outcome if not, then we're doing the wrong work so let's take a moment to collect pivots and find what else could we do in order to achieve the business outcome that we're trying to achieve no project, no temporary endeavour no product first but building teams around outcomes and the business results I've been a project manager as well I've done the whole project manager body of knowledge thing and I understand the appeal of having well-defined parameters for what needs to be accomplished you've got scope time cost and you can build plans and track against those plans I like what you're saying at the end of the day those are just proxy variables they're starting out with the assumption that if we're on time and if we're on, if we hit the requirements and we are within the budget then therefore we'll be successful but that's not necessarily the case what I think maybe that because you can actually achieve the you can achieve those three things and not necessarily achieve the business outcome what's potentially challenging I see though is for people potentially high up people in the company to have the hubris to admit that their decisions of what they're planning to fund and what they're planning to invest in aren't necessarily correct aren't necessarily going to achieve the business outcomes they want it's just well clearly if I've made this decision this is worthwhile here's the time budget and scope if you hit that then therefore the business objectives will be achieved that's not the case so how do you shift the mindset of having the sense of fallibility of to get away from this great man theory that people feel like they need to show that their own brilliance and an idea right and admit that our ideas could be bad and we need to inspect and adapt like there's a political a major shift in the thinking of people yeah because it's a certain degree it's forcing me to open up the possibility I could be wrong about my decision right I might not get the business outcomes I'm looking for so what's your take on that Evan as opposed to two things one we're changing we're fundamentally changing the operating metaphor so where the operating metaphor is a project time cost and scope are our measures that's what's important to us because we're not to be honest we're not funding a benefit we're not funding an outcome we're funding a piece of work in the assumption in the assumption that it will achieve a benefit and so the measure of that benefit the measure of that outcome happens very late and usually too late to be effective now agile delivery is helpful in this regard because agile delivery allows an organization to incrementally deliver a product now the question here is is the product the right thing to do in the first place and as you say it's very hard to have an organization or senior leader an organization admits that they were wrong that it was the wrong product because people's self-worth identity as well as actual reasonable worth and their employment are often based on making these right decisions and so we incentivize appearing right over being right and that's just human nature so what we do is we just change the entire equation rather than having time cost scope as a constraint and obviously time cost cost is always a constraint it's always something that we have a limited a finite supply of as with time but we move that and we go this is one constraint our team we're going to fund a team continuously six people $100,000 a year for the rest of eternity or at least until such time as the outcome that this team is accountable for is no longer meaningful and so it stops being a matter of leaders making the wrong decision and when we're transitioning to this kind of model it's not about you've made a wrong decision it's about we're going to change the way that you work at a very fundamental level so we're not just changing we're not saying you're doing the wrong thing not saying you're doing it in the wrong way we're just saying that we're going to be outcome first not project first and once you change where you start from there's a cascading effect of everything else that follows behind now obviously we have to have the right people and this goes back to my constraining factors if IT wants to do this but finance is not on board then we're going to have trouble because we're going to then finance is going to want their projects and their project plans and so IT is going to have this push and pull of we want to do it this way finance wants to do it this way so we'll try and wrap no projects inside a project or we're going to try and wrap agile inside a waterfall project management plan the same sort of dichotomies always occur so we still need to make sure that there is a which constraining factor is most constraining right now and what can we do about it and if it's finance then we need to change the way the finance is thinking but as far as leadership is concerned if they recognize there's a problem we can give them a way of changing without losing face if they don't recognize there's a problem but other people around them do once again we can give them a mechanism to push improvement without making someone else a failure and we do want to we want to make it safe to fail but a 10 million dollar project is by definition not safe to fail you might fail a sprint you might fail a feature but you can't fail the project so we do make it safe to fail by there is no project there is a funding stream there is a value stream there is a flow of work and you could fail any given point of work and because we're always inspecting adapting not against a product not against a set of requirements but against a business outcome we have that ability to adapt to the business outcome Agile and IT is a fairly mature concept and is this still something that we're trying to figure out in the rest of the organization or are there companies that have are excelling at this and are leading the way oh there are definitely companies which are excelling at this and you might use a term no projects but a lot of these concepts are being used in other terminologies and other domains and have been for a decade or two there are elements of this this sort of value stream funding model coming out of beyond budgeting the concepts of and self management and teal organizations which have been around for 10 plus years look at the elements of teaming and the elements of accountability to outcome rather than to output so a lot of these in fact I would say all of these elements have been proven in different industries in different countries in different organizations and it's sad to say but there's almost nothing new under the sun we have so many we have tens of thousands of organizations around the world who are being agile at an organizational level they might call it business agility they might call it no projects they might call it something else entirely they may not even know what it is but it's just how they work and so these organizations are constantly pushing the bounds of operating models for organizations and startups, lean startups is another case in that I think is at this point in time in this juncture in history we have so many different and distinct ideas about business agility that I think we're now starting to get a consolidation we're starting to get these ideas start to come together look at each other and go oh that's a good idea and this is a good idea and I'll start to take some of them and sort of bring them together so we're never going to get one definition of business agility but we are going to see in the same way in the agile wars back 20 years ago we will see a consolidation of agile frameworks into a couple of major ones that when people think agile that's what they think I think we'll see the same emerge in the next five to ten years around business agility where there will be a couple of business agility processes and practices and frameworks that will come together and when people think business agility they'll think about those is that a desirable thing and I'll go back to the I suppose what really resonated to myself when I first got introduced to agile and agile ideas it was this coming from the project management background it was this democratization this idea that the way we work is not necessarily the realm of of experts and ivory tower methodologists but this is something that is tangible we can understand and we can it's not a solved problem we can innovate on this daily is part of doing our jobs and that was a very powerful message for me personally is that does it does this coalescing okay go ahead there's three sides to this there is in the first instance there is the implementation of an idea and the implementation of business agility in every organization is going to be unique no matter how much consolidation occurs the implementation of scrum in every organization is unique like if scrum was the answer we would never have a retrospective we would never need to improve because what would we change the whole point of agile and retrospectives and continuous improvements and kaizen is such that we recognize that the team and the implementation of agility is something that we work at week by week iteration by iteration so whilst when you think about agile most people will start by thinking scrum the implementation is unique second point when you're selling an idea to somebody who isn't in the community someone from the outside you want to bring into the community when you're selling the idea of agile you don't start by giving them the 100,000 options which are available to them you say go read the scrum guide or go read the wikipedia page on agile or have a look at the book on kanban we don't give them every option we give them narrow it down and say this is the synthesis of what it means to be agile by the way as you get more mature there are a lot more options open to you but if I'm talking to a CEO or a CIO from the organization saying you should consider adopting an agile approach and they go can you describe agile to me or how we would do that I don't describe agility in all its forms I will generally start with scrum or kanban because it is accessible it gives them something to anchor on to so that when they talk to their peers and their colleagues when they look online there is a common thread in what is being said and so part of agile success is the success of the consolidation of agility into a few very clear effective ways of working now not everyone likes scrum not everyone likes kanban but that's fine we have alternatives the the success of agile and its proliferation of organizations all around the world adopting agile mindsets and agile ways of working is in large part because of this consolidation and my third point is once you've sold an idea an organization matures it goes shu ha ri if you understand that model and at the level of shu when you're beginning you need something tangible you need something that is simple and that consolidation gives you that we don't have to give you a menu when you walk into a restaurant and you have 10,000 choices how long does it take you to pick what you want if you walk into a restaurant and you get three choices it's easy to pick the one that you're going to have it's the it's the there's a name for it it seems like choice theory I've got a simple solution to this problem I just order whatever Chris is ordering that's shard's theory of decision making he only has so many decisions he's allowed to make in a given lifetime I'm going to spend my decision making wisely there's let me take you to the Philippines and I'll order for you and you will regret making that decision well as you know Evan everything is context dependent no when we're in India we're going to go to a Filipino restaurant in India Evan's going to be ordering sorry but the third point once you get to the level of re or at least once you get to a level of maturity in your organization you are fully able to move away from that consolidation and pick and so agile organizations who are mature they will pick any combination of XP, FTD, TDD DSDM whatever you want they'll go we'll take a bit from here and a bit from here because they have the maturity to know the goal is agility not agile and likewise in the business agility context as organizations become more mature they're going to have the ability to pick because they know what is important rather than the method itself but when you're starting out that's very hard to do when if you go back to what you're saying about needing to be in the DNA and I think that's you've injected this the principles and mindset into the way you think and the way you work of course we've seen organizations just I guess adopt scrum into their work you know the agile coach comes in they come in a two day session here's how you do scrum you're a scrum master now you're a product owner and then they leave and then there's no deeper evolution of the ideas and is there that risk I guess still do we how do we how do we fundamentally change the DNA of organizations beyond just putting a new process in place now what I'm wondering is does the Shu Ha Re model which if we're using the metaphor that's appreciate where the metaphor came from from martial arts so it's a person on a personal journey of mastery over a craft and I wonder how applicable it is at an organization can you look at it as a whole organization in a state of Shu Ha Re when really you've got a collection of individuals at different levels and it's shifting over time and they're all in their own personal journeys does that effective model for describing an organization does it apply it's highly simplistic and organizations it's hard to measure an entire organization because there may be divisions which are Shu and divisions which are Re there may be cultural barriers and so forth but as a simplistic model it's a good simplistic model because it gives you not only a sense of where you are but a sense of where you can go and when we talk about maturity it's such a general term that it could mean anything but it could mean anything but individuals in an organization will it's something to be striven for something to aim for and so it gives you today and potentially the future is it the right model maybe is it the only model definitely not but it's a simple metaphor to describe a path an organization takes however having said that there is a journey that organizations and teams with organizations do go on however you describe that journey it does follow a path of I need to learn to I'm going to be doing versus being and when organizations don't think of it as a journey they think of it as a step where they go we're going to bring the training company in they're going to give us two days we're all going to be certified scrum masters because that's all it takes to become a master sorry cynicism apologies I'll have my two day course I'll have my certification we're agile full stop done now that's not a journey that's a single step and organizations that don't think beyond that single step they're the ones who are going to fail because once again it doesn't matter how agile one person is or in fact even one team is if the organization is not on that path you're always going to find yourself constrained and people talk about bimodal IT now I think bimodal IT and this is my personal opinion is the biggest cop out ever bimodal IT is an organization saying we do not have the guts or the ability to be agile alright so we're going to have an agile part which is the easy agile part the digital team let's say and we're going to have the non agile part the hard part the bit that will be agile but we're not going to even try we're going to give it a name bimodal IT or two speed IT and these guys can be as waterfall as they like now we've done agile in mainframe we've done agile in infrastructure we've done agile in every single traditional waterfall space and successfully it comes down to agile works where there is ambiguity and where there is a level of uncertainty and chaos you go down a waterfall path if something is highly predictable if you know with a high degree of certainty that what you plan and what you execute will not change but the minute you have users involved the minute you have customers involved something is going to change the case so the sin of bimodal IT or the curse of two speed IT is such that it gives people an out it allows them to give up half way through this journey I really don't like the idea of two speed IT putting that aside these journeys that organizations are on that is what important whether you call it Shuhari or whether you call it something else or whether you just have it as some sort of abstract continuous improvement a retrospective kaizen slow continuous improvement that is the journey that is important well thanks Evan I really appreciate you spending the time with us today I look forward to seeing you in India I hope to hunt down a Filipino restaurant with you in India and for some show on to experiment with some food I think the rule is that whoever picks the food has to go first eating the food do you have anything coming up that you want to talk about so I suppose two things are we doing two talks in Agile India both on business agility one on the outcome profile that I described before and one on just on business agility and how organizations can be more agile there is also the business agility conference in New York that we are putting on Chris you are helping me with this and many thanks for that that's going to be really exciting which you can check out at businessagility2017.com and you can see the great line of speakers we have there as well that's excellent I'm very interested to see how this space of business agility continues to evolve and to see how these ideas diverge and converge yeah absolutely I think this is the fast moving space and the one that needs to so I'm glad that these types of conferences business agility conferences are coming up as you say we need to start getting through these impedance mismatches and this is a whole organization thing so I'm glad we're having these conversations thanks for joining us today we hope to see you next time