 Today, as part of this talk, we are going to discuss an awesome pairing technique that is promiscuous pairing. We will get into the detail about what exactly the promiscuous pairing is, how it is different from our traditional pairing practices that we have been using as an agile practice or sorry XP practices for a long. Along with that, we will get into the details of what is the beginner's mind, how we can leverage it. While getting into the details of that, we will also walk through that how exactly we were able to adopt it, what are the challenges that we have faced and what was the final outcome that we have gained out of it. So, before I do that, let me just quickly brief you about myself. I am Ankur. I am working with the JPMorgan as an agile developer and I have spent like 12 years into the industry on two various product developments into the financial as well as into the telecom. In my current role, I am an agile developer working with a cross-functional feature team. Now, what does the cross-function feature team means is the team is able to hold all the various flavor that is needed, so beta, QA, beta, development, B, your requirements, everything is handled by the same team and it is end-to-end feature team. That means it takes care of implementing the feature end-to-end, whatever it takes, cutting cross across multiple components, products, layers, everything. It's not that we were not agile before and this is something with which we tried to get into the agile mode. We have been agile for a pretty decent time and it's been over a one-and-a-half year and this background is necessary to understand when we will get into the details about how the promise case pairing effectively works, why you need to have that well-geld team where you can actually trust and you can that comfortably pair with them. As part of our experiments, we keep on doing various XP practices, experiment some work, some doesn't. We picked up that this promise case pairing is one of our experiments. I think I have already covered that, but just to give you more just around it, so though we are cross-functional and feature team, we work into the banking domain, so the domain itself is pretty complex. That's a very interesting jigsaw. We are talking about the bank, so certainly it's a highly regulated environment. It's not like whatever you want to do, you can do. Again, now it's a cross-functional feature team and building feature end-to-end and doing that throughout every time. By the way, before I get into the promise case pairing, how many of you have actually practiced the pair programming ever before? For the benefit of the larger audience, let me just quickly spend a minute on this what the pair programming is about. Pair programming is when two programmers work together on the same workstation to solve a single problem. And that is the key. It's not that those two programmers are working on a different problem. They both work on the same workstation and they keep rotating the rules. So one will start looking into the problem and one will start basically actually typing the code. At the same time, the other person is reviewing what is getting typed. So it's not that we are having a review something later on. We're trying to leverage that two brains should be used to work or find out the various solution on a given problem. It has immense benefit. And we have seen that, so I think if we go back into the history, somewhere in late 90s, even when Kenback has his references, Alistair has his references, they all have used the pair programming. Again, if I go back into the history of bed, where exactly this has come from? Any one of you have ever heard of rubber ducking? It's a very interesting concept. So what they used to do, there were programmers and they used to carry a rubber duck to their workstation. And the purpose of this poor rubber duck was whenever you used to face some challenging problem, you used to speak out the problem to the rubber duck. As part of this exercise, when you speak out to that problem to the rubber duck and what is expected, most of the time people were able to identify that what the problem is that they were able to themselves find out the solution. It happens. Sometimes you might have, at least I have a couple of times experience with my wife, she is not from the IT, but if I explain her something and while explaining I say, okay, I got it. So certainly it must have raised the demand for the rubber ducks, but that's a past. So they thought about, okay, when the rubber duck, the poor rubber duck can do so much magic. What if you replace it with a brain? Because anyway, the rubber duck is never going to ask you a cross question or give you some suggestion. It's only about, again, if you go into the science, the science behind that says that when you speak out, when your vocal cords and the diaphragm and all those things work, there are a lot of the nervous activity that goes and that triggers and simulates your mind. That's the reason why you are able to concentrate more. It's not only just the visual part when you try to see the dry run. Exactly the same thing happens when I try to listen someone. So when I'm speaking out, I'm also listening to myself. So that's a bit of a pair programming. So they thought, okay, let's replace the poor rubber duck with a human. And they started having a pair. Now, no one wants to be treated like a rubber duck, right? So you were having a rubber duck, now you asked me to sit with you. But every time you will just speak out to me and I'll not contribute. What is the point? They say, okay, I'll also play our role. And anyways, we are humans, right? So what they say, let's switch the rules. Half of the time you do this thing and you treat me as a duck, but half of the time I'll also treat you as a duck. So the first person start behaving as a driver and the second one start behaving as a navigator. And after some time, they keep on rotating this rule. That is the zist of pair programming. This is all about the pair programming. Now, when we do the pair programming, what we do, we basically do this pairing for a long time. So people find it comfortable to do a pairing with someone for a day, a week, month, projects. So there are various flavors to it. They used to say, okay, we want to leverage the pair programming. I'll do that. I'm comfortable, this gentleman. I'll continue pairing with him for a lot many days. It had a lot of its inherent challenges. What happens with that, as and when you start working with the same person for a long duration, after a certain point in time, you become so comfortable to one another that your brain stops challenging each other. This is not what we wanted to basically leverage through pair programming. What we wanted, two brain should always be active and should keep challenging the problem so that they can always find a better solution. That is not, that was not working out. Though we say that, okay, we are pair programming. There are a lot of research around it which suggests that beyond couple of hours, there is a dramatic decrease under the drop in the productivity. That is whole about pair programming. Now, why we move to the promise case pairing? Again, as I mentioned earlier, we were also agile. We were doing the pair programming for a pretty long time and we were not like a born genius. We were also using in the very same old fashion. We used to pair based on here that I'll pair for the whole task. We were still a bit more, we used to think so that we were intelligent. We are not doing for weeks or months but we are doing it for, say, whole task, okay? The second conventional wisdom. The conventional wisdom says who should be working on the task or who should be pairing with the task? Someone who is most qualified to do that, right? So if I'm changing a stored procedure or a database tuning distributed, who would do that? Someone who has a good hands in database. Okay, that's a conventional wisdom. But honestly speaking, that doesn't work out. If you go by the various research that has been done by Microsoft, Ata University and everywhere, it doesn't work that way. The reason for that is when someone experts go and start trying to find a solution to a problem, he will always go with that baggage. The baggage that I know that how it works. He will never try to go outside and think out of the box. And that was the major drawback with the normal paper. In one of our retrospectives, we had gone through this wonderful paper by Arlo Balshee. I think it was published somewhere in 2008. We had recently gone through it. And we thought, wow, it's amazing, it sounds great. And as an experiment, let's give it a try. Anyways, we are agile if this doesn't work out. The next print or the two sprints later, we can always turn back and we can say, okay, this is not working out for us. Let's try something different. So with that, we brought in an idea, okay, let's do the peer programming. So this is all about the programming. And now let's get into what exactly this peer program, how is it different from the peer program? It's very simple. So we got to know the system of that, what the peer programming is. Now the only difference that promiscuous pairing brings into it, changing the pairs very frequently. That was the main challenge, right? I was getting too much attuned with my partner over the period of time so that I stopped challenging or my brain stopped challenging the other person's idea. And that's why I was not able to produce a lot of different ideas. Okay, we'll keep switching the pairs frequently. How this happens, so there are say, there is a pair who picks up the task initially and they will start working on it, right? After a particular fixed duration which is known as the pair split period, the pairs which happens. Now there are two options when that happens. Either both the partners of this pair can move on to two different tasks, the way this has happened in this, right? They both have moved on. And a completely new pair will come and they will start working on this task, good? The other alternative is that I can have one person, I can retain one person while I let the other person move on, right? I let this person move on into the task. Now what happens with this? At least the new person who will come on board, there will be some kind of hand holding. He would be able, he or she would be able to leverage the work done by the previous pair. So usually what happens as soon as they get into it, they start working on it, they find out of, they look at the problem, find out some solution, they keep working on it and they keep rotating the roles as we do into the normal pair programming, the driver navigator role. After some time, someone will move on, this gentleman comes in, now the interesting part starts, he has come with a completely blank mind. He has not looked into the solution before, he will come with a plain slate, doesn't carry any baggage and he will start lot many questions because his mind is unstable at that point in time, he doesn't, he is just trying to grasp what is there in this problem and what exactly you have tried. Now if you look at it, what this the person who has been retained from the previous pair swap, what will he go through? He will try to download whole of this information that what they have tried to the new person. If you compare it with, it's pretty much close to what the rubber ducking was happening, right? That for the first five to 10 minutes, I'll explain everything to the new person who is coming on board. So I'll be explaining and at that point in time I'm revalifying and validating what I have implemented. At the same point in time because this is a new guy, he will play a devil's advocate and he will ask lot many questions. He is not having any background, he will ask lot many questions. First 10 to 15 minutes go in that, inherently there is a lot of knowledge on how that has happened. Now after that, once they have attained to that stage, he will suggest lot many things which they might have not tried or they might have tried, which will improve the solution. They will keep on now for next 45 or next XR based on what the pair switch period is, they will keep working on it. And again, there would be a pair rotation. Now, the next time when the pair rotation happens, the person who has spent most time up until now wanted the task that has to move on. Why that? Again, we don't want to build an expertise or carry the baggage that okay, I have been working on this task for say two or three or four hours, I know the most. No, we don't want someone who know the most. We want new fresh ideas to come onto the table so that we can take more better solutions we can be accepted. So if you look at it, it has an inherent behavior of learning and knowledge because that 15 minutes that initially that the new guy is coming in and trying to understand and the existing guy is providing that knowledge. There is a lot of knowledge transfer that has happened. So it has that inherent behavior of the knowledge transfer. You don't need a separate TT sessions or white boardings to have this happen. And this is what we are practicing. So that means those two pair are not just discussing out there actually coding and they are implementing, contributing. It prevents the state of flow. What was happening before? Because it's not that okay, the same pair is going to work for couple of hours or couple of weeks. So they will get into the flow state or with the tunnel vision. New guy come, challenges. They both take a collective decision. Okay, this is a better approach. Okay, let's give it a try. Move on. Third guy comes in, solution is getting better and better. This is exactly what is beginner's mind. Can I just part of this question for some time? Maybe those questions might get uncertain. Thank you. So this is exactly what is beginner's mind. The mind, when the mind is in a complete blank state is the state of instability and mind tries to come back to the state. So imagine you are walking into a conference or a party where you don't know anyone. What exactly happens? As soon as you step into it, you try to gaze through the people around and try to figure out is there any known phase? If there is any known phase, you try to quickly go and communicate or start conversation with that person so that you get comfortable. So again, your brain is working that way. You walk into a room or conference room like this. You don't know anyone. You don't know that venue before as well. You again gaze through it. You try to figure out which table you can grab in. You go and grab a chair. Sit over there in next 15, 20 seconds. You'll turn your left and right, exchange the pleasantries and try to make yourself comfortable with the fellow sharing the same table. What happened? Again, instability state. I'm trying to get into the stable state. And then maybe for next couple of hours, you might not even get up from that chair. But during this instability period, when you have walked in and by the time you get settled down, your brain did lot many things. This is what the whole idea about the beginner's mind. State of instability. So we got it that, okay, this state of instability is good. Can we leverage it? Because we don't need to be good. I can keep my brain always in instability state so that I can leverage this understanding of the hyperactivity that my brain goes through. Yes, we can. How? By quickly and frequently changing the environment. So the challenges or the task at hand that my brain is doing, as soon as it gets accustomed, I'll push in a new challenge to it. I'll let it move to the new task. With that, again, it will get into the instability state and again, it will try to figure out what is that it needs to attain so that it can again get back to the stable part. That was all about the promiscuous bearing, right? It's very much, pretty much into the Arlo Balci research paper as well. What worked for us? It's thought that something that is already published and it goes and work very fractally for each and every environment. You had to have some tweaks and twist it. We also had gone through a lot of pain. What worked for us was we as a team agreed upon initially that while we are going to try this experiment, we'll retain our best practices what we have learned over the years regarding the XP part. We always used to do the scrumming. By scrumming, I mean, I think most of the people in the room must be doing the scrumming. Scrumming, just to recap, we pick up one story at a time, right? And the whole team works on it. That's what the scrumming is. Good. We always do a bite-size taskplits, right? We don't want a bigger chunk to be picked up by someone and again, it hurts both the task at hand as well as the pair who's working on it. Why? Because again, the same problem will occur, right? If it's a bigger task, the same pair will keep working. It will not be looked after by the multiple people. So we continue with the fine granular task, but how fine granular? We kept it simple, not more than three hours. No task, none of my tasks in my story should be more than three hours, okay? We retained that. Good practice. Task will be pulled by whom? And every day morning, when I, as a team, we go up to our wall, someone needs to do the assignments, right? We always go and we'll assign or pick up the task for ourselves. Who will be picking up now the task? The pair. So there were multiple options. Most qualified pair, least qualified pair, random pair, or mixed pair. So based on our conventional wisdom, the most qualified pair can always go and pick up the task. If this is a database change, I'm a database expert, I can pick it up. This is something to do with the Unix. I know the scripting very well. I can do that in designing. So on and so forth. Least qualified. Someone who has not worked on this before, who is not, again, when we talk about the qualified, we are talking about the skills, not about the competency. There is a vast difference across that. Random pair. Anyone can walk on to the wall and say, okay, I want to do this task today. And the mixed pair, one least, one most. What work for us is mixed pair, most and least. This is the variation that we have experienced against Arlo Balci's paper. If someone has gone through my previous talk in Pune six months back, over there my outcomes were different. We were also with the least qualified. That's what the paper suggests. We, again, give it a try. We didn't want it to just go ahead with what is there. We wanted to give it multiple tries. We tried. Least qualified is good. But what we were finding it out is, after certain rotation, it starts with the least qualified. And after few rotations, certainly the guy who is most qualified would also come into that. And at that point in time, we were able to identify a lot of problems or a lot of the scenarios that if we could have leveraged it before, we would have saved a lot of time. Okay, does it mean that we should go with the most qualified? Not really. Again, it will have the same problem. What to do? We picked up least qualified and most qualified. Least qualified guy will keep a check on the most qualified guy that he doesn't keep throwing his baggage onto the solution. He doesn't come with that blinker that, I know this, how it works. I have implemented it couple of times in last 10 years. This is the only way to do it. No. The least qualified guy will keep asking questions. So this mix, sorry, this mix works perfect for us as of now. In couple of months and next few months, it might change. God knows, right? Again, we keep experimenting and tweaking. Next thing, what should be the pair splitting period? We talked about the task should be three hours. Now, within the three hours, we need to have multiple task rotation. What should be that? We tried again various things. If it's a three hour, I can every 30 minutes. I know I only have to leverage the beginner's mind. Every 30 hours, I can challenge my brain and I can just keep throwing the new ideas. That doesn't work. We had gone even to the other extreme where two hours. But again, with the two hours, the problem is that after certain point in time, we were not able to find out the productivity that we used to see in the initial hour as soon as the person comes on board while pairing. What worked for us is 60 minutes. Two reasons. One, this is the most optimum time for after till which we were able to leverage the productivity benefit of a beginner's mind. Again, this is a bit deviation from Arlo's experiment. In his paper, it's 90 minutes that is working out. Second benefit out of this is our task are three hours. So if I pick up one hour rotation, I'm able to have three rotation. In a six member team, four guys are able to contribute onto a given task. What more do I need? So each task is going through four pairs of five. Think about the quality, the practices that we will share across the team. It's working wonderful. Now, pair rotation. Now, I have started pairing with someone. I'm going to pair with someone for an hour. What are the rotation of the navigator and a driver role? Can it be 12 minutes, five minutes, 30 minutes? Again, we kept it 12 minutes. Some signs behind it. We strictly follow Pomodoro. How many of you are aware of Pomodoro technique? Great. If not, please go and check out. It's wonderful. It's a time test in late 80s. It was introduced. It's a time management technique which talks about how a person should work or take up a task in a bite size and completely with a focus, without any distraction, complete it and then take a break. So Pomodoro talks about 25 minutes and taking a break of five minutes. What it says for 25 minutes, cut off yourself from everything else. Focus on one task and just complete that one task. Then take a break for five minutes, whatever you want to do, completely away from the task. That will unwind you. What we did, we picked up, okay, this is what we want to do, right? So in one hour, I am able to do two Pomodoros. 12 minute, 12 minute rotation plus six minutes. So internally, what the rule that we follow is always 12, 12, six. 12 minute, I will play a driver. 12 minute, then next 12 minute, I will play the navigator and then six minutes, me and my pair will take a break. Again, we'll come back. Again, we will do this rotation, navigator driver for 12 minute, six minutes break. Two Pomodoros, more than efficient, more than sufficient. After that, let's play it. Again, those who will have tried that out, it's really taxing. It may sound like they go only 25 minutes, but if you are complete destruction, you are not checking your meals, you are not checking your mobile phones or anything, you are just completely concentrating on the task. It's very effective. Code check-ins, another good thing. We are agile practitioner. We always know that, okay, CI is something, continuous integration is something that I should always leverage. Now, continuous integration doesn't mean that I need to put up my server on Jenkins, Hudson, or Bamboo, and I am continuous integration. No, it's a practice. Continuous integration means I should be continuously integrating with the trunk so that my fellow developers who are sitting across wherever and they should be able to pick up the same code. We all should be contributing. Right now, we contribute every 12 minutes. So before we make a role switch between a driver and a navigator, we ensure the previous person will check in the code whatever he is typing and then we will do. Again, there is a lot of room for improvement. Ideally, it should be bring down to five minutes. A lot of theories suggest and a lot of the research suggests that ideally every five minutes you should be checking in and everyone should be into the practice. Five minutes check-in, five minutes update. That is the real continuous integration. It's certainly not about Jenkins or Hudson. Jenkins cannot do, right? If you are not checking in the code, what can it do? It cannot pull it in from your system. So all looks go down on slides. Was it that simple? Certainly not. We, too, faced a lot of challenges around it. It wasn't a cakewalk. Team composition. Let me quickly brief you about the team. It's a six-member team where one gentleman is completely fresh graduate out of the college. Lot of enthusiasm but raw energy. Somewhere you need to channelize that. Other gentleman who is with a 15-plus years of experience who has never worked into the agile before and he's also part of the team, right? So again, there is some baggage that he comes with. Another gentleman who comes with a database background, he thinks he's a database expert. Another guy who is purely from QA. He thinks only that QA is something that he's good at. But this is what the composition of team is. And now, again, as I mentioned before, it's a cross-functional team. There is no distinction of the task that this is the person who will be doing the task. We need to keep rotating. So that's one of the biggest challenges that we have faced. Sooner or later we realized, as soon as we are talking about this least qualified person picking up the task, very soon you are developing your secondary skills, the T-shaped developer. I will maintain my primary skill but at the same point and I will keep developing my secondary skill, it worked out very well. And again, we are talking about the brains. We are not talking about the skills. Even if it's a fresh graduate, doesn't mean that he is not able to contribute. He has a brain, right? He's a human. Who is least qualified? The biggest challenge. The problem is that this word itself, least qualified, right? If I ask you who is least qualified in this room as in on the agile, I'm sure nobody will raise a hand, right? That's an inherent problem with us, right? But I give you some background that we have worked on this for this same team with for more than last quarter to two years. We know each other very well. And again, we are talking about the least qualified from the skill part, not the competency. I might be least qualified on C-Sharp, right? But I'm a good developer. I have quoted for last 12 years. And I would not mind because this is certainly going to help me grow my skills, my secondary skills. Sooner and later we quickly realized we are learning, right? And initially there were a lot of problems around this. Every day in the morning, think about it. To the wall, you go and say, guys, I'm in 15 years of experience, but I feel I'm least qualified for the database part. I'll pick it up. It's not easy to accept that fact. But quickly we realize, okay, if it's not going to work, we'll roll it back. In two sprints, everyone on the same page, guys, we are learning something new. Let's continue doing that. We continue. Not switching pair at logical point. So when we talked about this pair switching, the key idea over there is that as soon as there is the pair swap period or the pair switch period expire, you have to switch. You have to switch. So if it's one hour for us, one hour we will leave and we'll go. Anyways, we are having two Pomodoro, so certainly there is no point we can extend it any further. We'll move on. So people just think, oh, there is a logical, I was about to reach to a logical point, but that's what we want to address it. There is no logical point. You can't think of a logical point. Let the solution evolve to a logical point. So that was another challenge, but later on we realized, okay, whatever it is, let's continue. And certainly in one or two or three rotation, whatever was the optimal solution, it used to come to a logical point. Rampant period, yes. Every time I join a new task pair, there is a bit of a rampant period, but don't you think that's also a knowledge transfer? And again, we are scrumming. I'm talking about the same story very related task, so what? How hard would it be for me to have a ramp up? Certainly not a big challenge. Initially we thought, but very quickly with one or rotations, it worked very effectively. Compromising expertise. Now we are talking about only, sorry, we are talking about the least qualified should start picking it up, they should start developing the second risk. What will happen to my primary skill? We are not challenging that. We are also giving an opportunity to go and work on the task where you can leverage your primary skill. So expertise is again with the agile, it's not like that we don't want experts to be there. We want natural leaders. We want expertise to grow, but not at the expense of becoming only proficient in one skill and more behave like an ID or a compiler in a human body. Come on. No one owns it. So now what we talked about, no one owns a task. Anyways, in our time, I'll be moving on, someone else will come. You are a team. You are a team. Anyways, the team owns the task. There is no, so the smallest unit that anyone sees outside of the outside world is just the team. There are no individuals. There are no individual signups for the task, right? The team owns it. Either team will succeed or other teams team will fail. All number of team members, we all work in the very dynamic, at industry where it's really tough to retain the mid-level developer. We also lost one of the guy. It wasn't that we had any dependency on him. Certainly we missed him, but the inherent problem was that out of a six member for certain duration, we came to an odd number of five. What to do? And no one wanted to work alone after going through the promise case for so long. What we tried out, we started figuring out the individual task. A lot of the tasks, like we work in the regulated environment, we cannot do a deployment like that. So there is some paperwork needed. Someone can pick that up, some setups. Lot of money is still in the development we have, which can be individual tasks. So what kind of individual task can we do? Should we keep it for one day? We tried various experiments. We tried keeping like two pairs we'll keep rotating by one guy would be for the whole day we'll work on the individual task. Doesn't work. Another thing, maybe three-hour tasks. Again, doesn't work. Someone wants to work into the three-hour thing. So what we finally worked out for us? One hour individual task. So that as soon as I'm, let's say, I'm doing the individual task for one hour. After the rotation, again, I'll look back into the pairing mode. Effective, very effective. Again, we discussed about this in detail why the optimum frequency, we picked it up as a 60 minutes. The rotation of roles for us, it's 12 minutes. And what we have achieved with this, the key items. Quick knowledge sharing across the team. Yeah, I think from the last 15, 20 minutes that's what we are trying to emphasize. The whole team is working on all the related tasks. Everyone is on the pretty much same page. There are no experts or there are no Mr. bottlenecks in the team. As soon as you start talking about the expert, there certainly also becomes your bottleneck of the team. Think about it. There is only one person in your team who understand a given logic. There is a production issue in that guy's offside. What will you do? We start playing the same old game. We are on top of it while replying back to the management or the end user. But internally, we are just praying that the gentleman should come back to office tomorrow, right? And we will enjoy, certainly, if for any reason, we are that Mr. bottleneck. Yes, we will enjoy that because without you, things will not move even an inch. It rots the culture. We should be completely out of it. But are quality deliverables, yes? Everyone is working on the task. So again, I told you in a six-member team, each task is being worked by four members. What more do I need? Again, if you look at the coding practices are getting spread across and would be very similar across the teams, right? They are again looking into the corner conditions, new ideas are coming into it. Quality of deliverables, definitely wonderful. No local optimization. Just how I told you why Mr. bottleneck should be avoided. We do avoid that. Improve throughput. Now, there is not a single person who knows something. The whole team knows everything. So tomorrow, if there are chances where my business deliverable bond, this is the highest priority item that I want to look for. Imagine you have only one database guy. Understand database very well. Now, my production release is only, say, three months now and the business spawns couple of the things that needs to be pushed into the next sprint which are all database related. What will I do otherwise? My Java guys or my other resources who will say that, okay, we are expert into that. They will say we will do something else. We cannot do database. That's the only guy who can do. But now in this case, everyone is doing everything. So certainly, your throughput can be increased because everyone can just jump on it and can finish it in no time. Shorter ramp up time for the new hire. It works like a charm for a new hire. And we have seen this cycle couple of times. Imagine in a day, I'm able to work. So we have a five-hour, five effective work a day. So what we say, so let's say I'm spending nine to 10 hours a day, only five hours I'll consider as an effective work that I'll contribute into the project. Where I will start pairing. So 10 Pomodoro's I can do. Remaining four hours, we spend into the whatever, the things checking me, emails, and most importantly, self-learning. Once that is done. So in this 10 Pomodoro's that I'm doing, I'm able to at least have two rounds of pairing with all my team members. At least three tasks that I'll be touching this on the same day. Wow, what more do I need when I step into a new team? Do I need to have more whiteboard sessions with my teammates? I don't think so, right? I'm actually contributing to that. It works like a charm. Better design of the laborables. Certainly, lot many new ideas are getting challenged. Lot many people are contributing. It's not that only we are discussing on it. They are contributing to it. So design of the laborables will be much better. Improved skills at the T-shaped developers are building up. Primary skills are primary skills. Secondary skills are getting developed because somewhere you are most qualified, somewhere you are least qualified. So but you will keep a balance on that and you will always maintain a balance and you will keep building your second risk. Team maturing to be the technology agnostic. Yes, I no more consider myself and only a job developer. Whatever is the need of an art, I'll go and pick it up and I will keep building the technology. Again, I should be utilized more as a brain rather than as a Java compiler or an ID, right? Less spillover, that's what we have seen. There are very less spillover. The whole team is always on top of it. It's not that we have a dependency or a black box on one particular pair who keeps working on it and suddenly one fine day we figure out. No, it's not going to go into the release. So there are no spillover. The whole team is pretty much on the same page throughout. Boosted morale of each individual. Yes, everyone knows everything. There is no, there is not someone like, he is the only guy on which we have a dependency for the success of the project or the product. Everyone is learning something or the other new day. We have seen a dramatic difference into the work from homes, absentees and everything and even the attrition for that matter and team was like a reality. With that, our journey with the promiscuous pairing keep going on. We'll keep tweaking around it. We'll keep finding until and unless we have a better solution. The day I'll have it, I'll come back and share it with you. Till then, let's keep pairing. Thank you. So yes, sorry. You had, it's covered, okay. Any questions? That's where we have started. So the point is that from the day one, they will not be at stage. We took quarter to two years to reach to that stage. But the team has to be at the edge that they keep need to working together as a team and they will be there. So in our case, it was a six member team, right? After every one hour, we are rotating the pairs, right? So initially two people will start. Each task is three hours. So two will start and then I'll have two more rotations. So in that case, by the time my task is completed, I have four pair of eyes who have already contributed to the task. Sorry. How do they know where the other team is? Because one person, we have it any from the latest, we are sorry. Only one person moving on. That's how they transfer the knowledge as well. So we don't want like the completely new two guys and come and just crap everything about the previous guy. They can challenge it. They can, yeah. The next time. The very next time. Yes, please. So you don't have any UI in the middle of the water. Sorry? You have any UI in the middle of the water. It doesn't matter. We do have, we do that. So if you design, you don't need to have. In the sense? It's if you're designing something. So if you look at it, it's not only just the UI designing part as well. So even like the application designing itself, sometimes we say, okay, if I'm designing same as new schema or I'm doing a logical data modeling or something. Again over there, everyone can contribute. Yes, please. Yeah. Yeah. Yeah. Yeah. Yeah. Right? I got your assist. I'm sorry, but I think you have missed out the initial point. I think, so we had discussed that at length. It's not about it that what exactly you are talking about. You will face that challenge. If you are doing a shadowing, if you are trying to train the other person, if you try to treat and leverage it as a brain, that will never happen. So we talked about a bit on to the rubber ducking, even the rubber ducking itself was working out. Now we have replaced that with a human. So it's never the case. That's what I have explained that in our team, there is a guy who is more than 15 year and a guy who is just passed out from a college and it's working perfectly fine. Okay, I'll be available outside if you have more questions, but I'll start.