 Welcome everyone to this session. We have Sunil Mundur with us today. You're going to be speaking on embracing complexity, a case study of leveraging agent interactions. So we're looking forward to hearing what you have to tell us about that. Without any further ado, Sunil, it's over to you. Thank you very much, John. First of all, let me express my heartfelt gratitude to the organizers of Agile India for giving me this opportunity. It's my privilege and pleasure to be a part of this conference and to be sharing the content with you today. Before I begin, let me just say a line or two about myself. I am a principal consultant advisory at ThoughtWorks. Been with ThoughtWorks for about 11 years, working with organizations and leaders across the world to help them embrace agility. The author of the book, Enterprise Agility, Being Agile in a Changing World, which was the best summer on Amazon. And I'm very passionate about speaking at conferences, spoken at 30 plus physical conferences across all the six continents. This conference, Agile India, was the last on my wish list in terms of the conferences I wanted to speak about. So this is a very big day for me. Okay, so let's get straight onto the talk. Now, before we understand complexity, I want to present two scenarios to you. Just to get a better feel of what complexity is. I was told that the audience of this talk will be quite mature in terms of knowing what complexity is, but let me just take a stab at understanding complexity from a layman's perspective. You see two images here. On the left-hand side is somebody fixing a tire and on the right-hand side, there's a surgery happening. Let's imagine a scenario on the left-hand side. You have a flat tire. You go to a petrol station, gas station, you find a mechanic and you say, there's a problem with my tire, can you fix it? The mechanic takes out the tire, looks up what the problem is, maybe it's a flat tire because of a puncture, fixes that, puts the tire back on and you're ready to go. Yes, it needs a skill, which the mechanic has. When the tire is taken out, nothing else on the car is impacted, right? The steering, the gears, everything remains the same. So you could isolate a part for which you have a problem and you can fix that and put it back on and everything works fine, okay? So that's one scenario. The other scenario is a surgery happening. Like let's say you have some stomach pain, the doctor will do a lot of investigation to find out what's exactly wrong, yeah? And it's not just about the stomach, but if you are to get ready for surgery, they will check your blood pressure, they will check your bleeding time, clotting time, those kind of parameters as well. And then you are certified as being ready for surgery. Now when the surgery is happening, like just like it would be for a car, the doctor takes a different approach actually, not like that of a car. So while the doctor is operating on the stomach, there are several parameters of the body which are being monitored, right? Your breath, your blood pressure, your temperature and many other things. And you can see that there are a lot of always monitors in the surgical room. And the point is that anything can happen during surgery and the doctors have to be ready for it, okay? So I hope this gives you a feel of these two scenarios which are very, very different. And the difference basically is this. The scenario about the car and the tire is a complicated scenario. And the scenario about the surgery is a complex scenario, all right? So I drew inspiration to understand the difference between these two terms from the Kenevan framework. Again, I presume many of you would be familiar with this framework, but if you're not, I think it's an extremely insightful framework which I have found to be very useful. And I'm just beginning to scratch the surface. It looks very, very simple. But the more you get into it, the more you will discover some meaningful insights coming out of it. In fact, I used to use the words complicated and complex as synonyms until I came across this particular framework. So today we are going to talk of complexity and I won't spend too much time on talking about the differences between complicated and complex. I think that might be a reason to do a separate talk on that one. So what we are looking at now is something called as a complex adaptive system. And this is what my book is all about. My book is that organizations are complex adaptive systems. They are complex entities. We have unfortunately modeled them like complicated system or like machines, but we need to remodel them like gas. And this is a very high level model of what a gas is. And what you see in a gas is that there are agents within the system. So in an organization, the agents are essentially people, but there could be functions, departments, groups, communities, even those are agents. And the agents, as you can see, constantly take inputs from the external environment. They interact with each other, which produces emergent behaviors. And that emergent behavior again is influenced and it goes out into the external environment as well. So there is a lot of connectedness which a gas has with its environment. But the important point that I wanna highlight and there are several features of gas which can become a separate topic in themselves for a talk. But I just wanna focus on one main characteristic of gas today, which is that the interactions between agents produces value and that value is usually greater than the value which is produced by agents working in isolation, right? So with that premise, let's move on to understanding what is this agent behavior that we're talking about? So agents are those entities which bring the gas to life, all right? So a car does not have a life because it doesn't have anything living within it. But an organization does, it has people and that's how you bring it to life, okay? So what are the four key characteristics of agents? What is that they are self-organizing? This is an important characteristic. So even if you look at a human body, we have cells, we have nerves, we have so many organs and there's a lot's happening inside even without me knowing it, but everything is self-organizing. You look at a stock market. The buyers and the sellers self-organize, nobody's telling them what to do. You look at a traffic system. Most of it is self-organizing. Yes, you have rules, but people organize according to how they wanna drive. The second is their agents cohere around a purpose. Yeah, so when there is a purpose, that's what agent comes together for. So for example, again, going back to the stock market example, people come together in a stock market to create wealth. Yeah, people travel because they have to reach a destination. So there is something around a purpose which bring agents together. Look at this stock that's happening. You're interested in topic and that is the purpose for which you are attending this talk or we want to learn. So we are all attending this conference. So there is coherence around this, which is voluntary. The next one is that there's continuous learning and adapting as we saw in the CAS model. Agents are always taking feedback from the external environment and they're adjusting their behaviors appropriately. You look at the human body. For example, when you inject a vaccine into the body, which has the replica of the virus or the virus in small quantities, the anti-immune system kicks in to fight it out and creates antibodies. So they are always adapting, they're always learning, they're always responding to the external environment. And that's how evolution happens in complex adaptive systems. And the last but not the least, which is what we are gonna cover today is that the agent interactions create greater value than the value that they would create just by working by themselves, okay? Now let's get to the case study part of it. So this is an organization where I consulted a few years ago, which is in the UK. They are a large online retailer of apparel, women's apparel specifically in the UK. So I'm just gonna leave it at that because that is not as important in terms of looking at what are some of the initiatives that they took to enable agent interactions. The first one, the first initiative they did was to bring in business and IT stakeholders in meetings together. Now, many of us know that this is a perennial problem in many, many enterprises and organizations that business and IT do not see eye to eye. There are many reasons for this. One of the primary reasons is that their success criteria is different. They don't appreciate each other's priorities. Their outcomes are linked to two different goals. So those are the kind of challenges which these two functions have and they don't see eye to eye. But what the CEO did in this organization was that he made sure that he brought the relevant stakeholders together in what they created as an ObeyA room. Again, some of you might be familiar with what an ObeyA room is. It's a very large room with a lot of visual indicators. In layman's terms, you can imagine it to be like a war room where there's lots of indicators happening based on the data which is coming up. People make decisions. So this ObeyA room was radiating a lot of information which was kept updated. And the stakeholders would meet in this meeting at regular cadence to look at how do you validate ideas? How do you prioritize them? How do you plan your capacity? Which ones are the most important ones to be done? And how do you allocate your resources? And resources, I'm not talking of people here but talking more of money and other constraints which the organization has. How do you enable them to focus on your highest priorities? And this they did very well. Of course, one of the things which they did to enable this was to align the success criteria of business on IT to make sure that they're all working towards a common goal. But the interaction that the ObeyA room was there to enable, I think that created a lot of value. And here's the impact which was seen. One is that there was alignment on milestones and outcomes. So there was no confusion about that. Everybody was aligned about the constraints on both sides and the priorities on both sides. If you put a line on that, then there was significant reduction in the idea to cash cycle time. So earlier the idea to cash cycle time for this organization was something like 21 months. Because of this initiative, they were able to bring down the idea to cycle time. And the idea means not just an idea that came in but idea that got validated and committed to. Once that was done, it was brought down to closely to about seven months or so. So that was the kind of drastic reduction that was seen there. And obviously there was an increasing in the effectiveness of the capacity utilization because you could then focus on doing what is the most important thing for that moment based on the priorities at that point in time. So that was the first interaction. The second one is the cross-functional communities of practice. Many of us are familiar with this community of practice thing in the Spotify model, it's called a chapter. But normally communities of practice are limited to one specific skill. So you can have a community for business analysts, a community for developers and so on. But what this organization did was to create communities which cut across at least two functions. So for example, they created a community of product design and marketing. They created a community for digital and IT. And these were separate silos, separate functions but they incentivized and they enabled people to join these communities in terms of learning and enhancing their skills. And I think this was an experiment which worked out very, very well for them. And the impact created was that there was a knowledge sharing that happened the organic way that it was not forced. I mean, people were keen to learn and they came voluntarily of course with the right enablement and support which they got but it was organic. Second was about capability development. So people learned a lot about the other function as well. So it was more about developing something like a T-skill if you may say that. And because of the communities and the relationships that got built and people appreciated each other's worlds these silos became very, very porous if not broken down fully. So people were more amenable to collaborating across these functions. For example, product and design obviously have to collaborate a lot. IT and digital, it's debatable whether these should be two separate functions but they were and obviously they needed to collaborate a lot. And I think creating these cross functional communities of practice enabled that to happen. The next one is about having producers in the senior leadership team. And by producers I mean people who are foot soldiers people who are on the ground actually working. They are not leadership people. So for example, this could be somebody who is actually doing the design work for a product. It could be a developer in an IT team. It could be a salesperson. It could be a web designer. It could be anybody like that who's actually doing the work on the ground. And what they did was they included two people from the pool of these people who are there on the ground as members of the senior leadership team on an annually rotating basis. Of course they applied some selection criteria for that but the point was that they actually brought our people from the ground and gave them exposure to be a part of the senior leadership team and decision making which happened at the senior leadership level. So you've got four minutes left. Sure, sure. So the point was that they got a lot of out of the box ideas and they got leadership development happening as well because of that. Next one was about customer panels. They engaged a lot of customer panels throughout the life cycle not just towards the end or just towards the requirement phase but during different phases of the life cycle which included inception, which included product design and which included UAT and post release as well. And the impact was that there was focus on customer value as well as increase in customer satisfaction. And the last one is that they included college students in the hackathons which they organize. So they invited final year students from say for example design degrees when they did the hackathons for product design or for IT as well. And because of this, they were able to create a pool of people who are potential hires as well as they got better creative ideas. Now just to conclude, what is the implication for leaders to enable this to happen? First is that you need to empower the teams. We spoke that autonomy is very important for the agents and therefore empowerment is very, very important. The second is how can you link work to purpose? I think this is something which, the why of what the work that people do is important for people to understand. And when that happens, you enable the intrinsic motivation as we all know Daniel Pink said, autonomy, mastery and purpose. So that's the purpose part of it. The third one is that you have to set simple rules in a complex system. So again, look at the example of traffic. You know that there are few rules there. Yeah, when there's a red light, you stop, you drive on a particular side of the road. When it comes to turning left, you give your order right whenever you wanna make a turn, you flash your light to know that you indicate to the person behind you that you wanna take a turn. And there are these few rules. But other than that, everything is self-organizing. So I think this is again important in terms of when you give autonomy to the teams you set guardrails. But those guardrails have to be in form of simple rules. And those rules have to be absolutely non-negotiable and non-breakable because imagine in a traffic thing, right? You break a rule and the consequences can be disastrous. The next one is about embracing diversity. And this is again a very important part of complex adaptive systems. They are more resilient depending on how diverse they are. The more diverse they are in terms of the agents, the more resilient they become. And that actually builds in antifragility in the system. So both in terms of people as well as thinking, I think leaders need to encourage diversity. The next one is about encouraging experimentation and learning. This again is about helping the system to evolve. And if you have to move towards continuous improvement, you have to experiment, otherwise you will be in status quo. And learning is again very important for the agents to help the system to evolve and keep pace with the changes in the environment. And the last but not the least is all decisions are probably not made by the agent. Some decisions are made by somebody else. So if decisions which are not made by the agents, how can you reduce the decision latency? I think that is important for agents to function effectively. So with that, I just wanna conclude by saying that complexity is a reality. And it's time to accept complexity and it's time to leverage it. That's it from me. Thank you very much. Thank you, Sunil. That was great. Lots of things to ponder there and consider and a nice breakdown of complexity there. I love the comment there. You need simple rules and complex systems. So yeah, nice little takeaway there. But Sunil, it's been a pleasure having you with us here today. Thank you for joining us from Singapore. Thank you very much for this opportunity. It was a pleasure and a privilege for me to speak at this conference. Thanks a lot.