 And it's more about our experience sharing that how exactly this particular adoption of the Thomas case training has worked for us. So while we'll talk about this, we'll also touch base around that how we were able to successfully leverage the business mindset, which is the key sys of successful Thomas case training. We'll also go through and find out how it actually works for us. It was not the plain vanilla solution that worked for us. We made the tweets and tweets around it. Like any other XQ practice, certainly you can. You can make it work the way it works for you. What are the challenges that we face? It was not a cakewalk for us as well. And finally, the key business thing, what exactly, how exactly we have benefited out of it. So before we get into any further detail, let me quickly brief you about myself. I am Ankur. I am an agile developer working with JP Morgan. I'm a technologist, and today's discussion by the way is purely my personal view. It has nothing to do with the JP Morgan. But it's more about the experience that I have gained over the last 11 plus years while working on the product development of the telecom domain, financial domain, research, e-commerce platforms, filing pretends, a failed startup. So in my current role, I am part of a cross-functional feature team, which is self-managed. We developed the banking application for the complex business scenarios of settling and positioning of the trade. Good decent domain to go for. So first thing first, anyways, we were agile. So what was that one thing, and why actually we have moved or we started hunting for a better pair programming technique? So it was not that we were not doing a pair programming before. We were always having a pair programming. But it was much in a conventional way. But a conventional way, I mean two things. First, always two people work on the same task at a given point in time. So two things are working on a given computer. The second thing, who will be working on that? And the conventional wisdom says someone who has the most expertise should be getting up the task. But over the period of time, we ourselves have realized that when the people who are most qualified to work on it, they work, it creates a kind of a bottleneck. And in today's talk, we will discuss about that and how we eliminated them. So we knew the problem and how the problem was growing for us. In one of our retrospectives, we came across this pretty famous paper by Arula Balashi. Thanks, Linda, for pointing it today in her morning keynote session. It's a wonderful paper. It's not because I'm having a talk today, but I encourage everyone to go through this and give it a try. And certainly not take it with the way it's presented, but maybe you can try it in your own way, the way we did it. So the face of it, we liked it very much and we thought, OK, let's give it a try. As a part of a continuous improvement, we can experiment. They didn't see. Now, let me do the detail. What exactly is a promiscuous training? In simple words, promiscuous training means switching pairs frequently. Now, when I say frequently, it's not weeks or days. It's hours. So in hours, we are switching the pairs. So we are getting to work with different people from the team. So a task is picked up by a pair to start work. And they start working on it. After a specific period of time, which is your pair switch period, the pair splits. Now, once the pair splits happen, there could be two scenarios. One, in which the existing pair just move on. Both the member of the existing pair moves on to a completely separate new task. And a fresh new pair comes on. Another thing is, when one of the members on the previous pair get retained back, and only one member moves on to another one. We suddenly preferred the second one. The reason being, there was much better hand-holding in the transfer of the knowledge. So that the new guy who's coming on board to pick it up was able to leverage the work done by the previous pair. Now, we ourselves can see and acknowledge that, because there are more people coming and contributing to the same task every hour, so certainly the knowledge is spreading. So inherently in this, there is an auto-transfer of knowledge. So first 10 to 15 minutes, what happens? So let's say me and the gentleman is pairing. We will work together for some time. Then I'll move on. But when the new guy will come and start pairing with you, first 10 to 15 minutes, he will try to transfer or let him understand what exactly we have achieved in the last one hour. Now the best part is that when the new person comes on board, he's coming with a very fresh perspective without any bias far away from any blinkers. So what he does, he starts asking a lot of questions, because he's also building up that knowledge. So it works in two ways. First, because now he has to transfer that knowledge to the other person, he will detail out the whole of the finding or the progress that we have made in the last one hour. The second more significant importance is the second guy, because he's with a fresh perspective, he will be kind of a daily subject. And he will ask a lot of questions which will surface a lot of corner scenarios, new solution approaches. And then further, with this new information that has surfaced now, you can again take a collective decision, and this pair will start working on there. So another 45 minutes, they will do a productive output and take it to the next day. And this keeps on repeating. So after the next pair of threads, because he has now paired with two guys, he'll move on, and now the other guy will retain, and the new guy will come out. Another key benefit, preventing the state of flow. So what is state of flow? If two guys keep working together for a long period of time, their brains stop challenging each other. And why is it so? Because they get into the comfort zone. With the promise of staring, you don't ever get to a stage where your brain has tuned to the other person so much that you stop challenging that. And that's the key idea. And this is what is a beginner's mind state. The state of fine, where mind is fully receptive of the new ideas. So it's something very simple. You can correlate it to, let's say you are walking into a conference or going to a party where you don't know anyone. You walk inside. You don't even the venue. You try to make yourself comfortable very quickly. You just gaze around the environment. You try to figure out which table I would be sitting in. You find out a chair and go and occupy that. In the next couple of seconds, you just look to your left and right. And try to just make yourself comfortable with the two persons sitting next to you. So in a very short span of time, you get into a comfortable state. And maybe after that, for the next couple of hours, you might be just sitting in that simple chair. Then you will not do a lot of activity. And that's how our human brains are wired. Now, as we know, because it's a, we are trying to leverage the state of our mind when the mind is a bit unstable. And it tries to quickly move into the stable state. That's what even when the new person starts pairing, that's what he's going to do. He's going to ask you a lot many questions so that he himself can get to a level where he says, OK, now I have a decent understanding of the problem. And these are the solutions which we'll work upon for the next 45 minutes. So won't it be great to leverage it to a next level where we keep our mind always in an unstable state? Yes, certainly, yes. It will be beneficial because we know if we can leverage this unstable state of mind, or the beginner's mind state, we can get benefit. So how to do it? Simple. Keep getting the task in hand frequently. Keep challenging your brain by then. And that's how the promiscuous training works. Again, when we are talking about the task, let's not get confused ourselves by saying, OK, there will be a lot of context switching. No, guys, we are doing a scrum. We are scrumming. Scrumming means the whole team will work on a single user story at a time. So all the tasks are somehow there, integrated. But still, it's not that only a single brain is finding a solution. A lot of new ideas will come up. It will incubate to the innovative thinking. Now let's get into the journey of what works for us. First thing first, we all agreed upon. So as soon as we decided in the retrospective that we are going to give it a try, we all agreed upon that we are not going to compromise with any of the existing scrum practices or the actual practices that we are doing. And one of the key items for us, so that no task can be more than three yards. So we agreed to that. Now, why are these three yards per se? The reason being because it still keeps the task very small and specific. And at the same point in time, it also gives us some time to have multiple pair rotations or the pair switches. Because if I keep a task so long that my only one pair can contribute anyways, I'm not going to leverage anything out of the homework system. So I need to have that pair switches possible, few pair pitches possible to be specific. At the same point in time, again, I don't want to have a big monolithic task to be performed. So a small task is the key. Now, another very interesting aspect, we talked about the beginner's mindset and everything, who should be picking up the task first? Who would be the person who will start or who would be that pair who will start first? There are various options. So we tried out with the most qualified person with our conventional system. There was another thing which is just a positive, least qualified person. Yeah, we are a future team, so we have everyone in the team. And by the way, by the least qualified, we don't mean the least qualified by competency, least qualified in spirit set. There is a vast difference. Or could it be like a random picking? So anyone can go on to the task board and say, yeah, this is the task that I want to do. Or this is the task that I want to do tomorrow. What works for us is the least qualified team and we're picking up the task. And this is the best result in the long term. Why is it so? Again, if you go to the basics, if a least qualified person or pair starts working or picking up the task and starts working on it, we are able to leverage the business with mindset optimally. Now, if instead of that, if an expert starts with that task, what happens? Again, he comes with a bias. He always comes with a baggage of being an expert and he will always try to impose that knowledge. So we are inherently killing the innovation of the element of thinking. Right at the point in time when we say that the most expert guy should start picking up. Again, at this point in time, we are not discounting or we are not specifying in any way that experts should be killed. No. If you need to leverage someone's expertise, there are always a breakout discussion that you can have. But what we are saying is, let the least qualified person should start the task. Another key step, what should the pair switching here? We tried various things. We tried from 30 minutes to two hours. What we found out is if it's too small, like if it's just 30 minutes, so what was happening, there is an initial auto download of the knowledge transfer. That used to take time to 15 minutes. So that used to outweigh the productive output period which is now only left at 15 minutes. So we are not gaining much out of it. Another thing because we, I should say, yeah, because of the developer mindset, we try to cut the conversation. What we say, okay, then I'll not transfer everything. Guys, we only are left with 30 minutes. Let me quickly tell you something and let's get started. Which was killing the whole essence of the developer master's training. So what worked for us? 60 minutes. 60 minutes. Now I correlated back to my three-yard task. Now I get a three-pair rotation, right? So in a six-tember future team, if four members are working, are getting the opportunity to work on a task and are able to contribute to it. It's not just working, but contributing to it. It's wonderful, right? Four brains are able to provide various solutions. What's up with the peer rotation period? So yeah, two guys have started pairing. Now we all know as part of the peer programming, we have driver navigator. So how does driver navigator will work and how frequently they should change? Again, we tried various options and what worked for us is 12 minutes. There is a reason why 12 minutes. It's not just some random number that we picked it up. But why 12 minutes? Because we follow a 12-12-6 rule within a given peer rotation. Now what's the 12-12-6 rules? 12 minutes, a person will play a role of a driver, fine, sorry. And for next 12 minutes, he will play the role of a navigator and then next six minutes, he will take a break. It's purely based on a promoter technique. You guys are aware of the promoter rule? If not, just give it a try. It's a wonderful time-tested time management tool which talks about working in a very short, bite-sized task without any interaction. So you work for that time and then you take a break which is completely out of that task. So that's how this 12-12-6 works for us. Similarly, code check-ins. We too are very sorry about having the continuous integration and the key thing about the continuous integration is not about just setting up a Hudson or a bamboo. It's more about how frequently I can contribute or collaborate my code with the five developments happening simultaneously across the globe, right? So we check-in right now every 12 minutes. Certainly there is an area of improvement over here. It should be brought down to five to six minutes. Challenges we face, interesting one. Team composition. The key thing over there is just to quickly be sure about how our team looks like. We have one fresh graduate out of the college. Lot of enthusiasm, but a bit raw. We all have gone through that same. On the other hand, we have 15 years of experience of a person who has never worked into the agile. So certainly he comes with some bad guys. Then there is a QA guy who's coming purely from a QA background, another guy who's coming from a BA background, and yet another guy who thinks that he's a job expert. So pretty diverse he finds. It adds to its own challenges. Not everyone is comfortable on working every task and so frequently to create rotations. Similarly, the biggest question comes then, why is it qualified? Why are you asking me to always work in an unstable state of mind? I want to feel comfortable. Then you smile back and say, come on, that's what the whole idea, that's why we wanted to move out of this previous year programming thing. We wanted to move out of that comfort zone. Least qualified, the bigger problem is that every day in the morning you go up to the task board and say, you know guys, I'm having 15 years of experience, but I feel I'm least qualified to work on the SQL team, so I'm going to work on it. It's a human nature. It's not easy to accept that fact that I'm least qualified. So we all agreed upon the various discussion that let's give it a try for two sprints. If it works, it works. If it doesn't work, we can always go back and we can try something different. In two sprints, we all found enormous benefit out of it because every day we were having a lot of jobs satisfactory, we are learning something or we are learning. It worked very well. Our number of team members, another key challenge with the IT set up in India, it's really tough to retain the mid-level developers. We also lost one. It was not that we had any kind of a dependency on him, but it was like if he pushed us from a six number team to five number team. So now what we are left, only two pairs can work simultaneously, but one guy would have to work as an individual. We tried various options. Finally, what we found out and we waited work is we again started identifying individual task of only one hour so that every, after every hour, there will be a guy who will get into the individual mode, but again, no one wanted to work for long into the individual mode. Again, I think we had discussed this in about why 60 minutes and why 12 minutes rotation of the rules. Finally, what we have achieved with it. Again, as we discussed a couple of times, it has an inherent behavior of the knowledge transfer. The whole team is working on the task. We are no more dependent on Mr. bottlenecks in the team because as soon as we talk about the experts, they are nothing more than a bottleneck. There is no local optimization now, right? We have, everyone in the team is a task natural. What task natural is? Any person can work on any task. And trust me, it has enormous benefit. When any person can work on any task, it gives that kind of, it increases the boost and the throughput to the team. So yeah, it killed out the philosophy of having a local optimization and the so-called experts and the bottlenecks. The throughput of the team has gone up and it has worked as a magic wand for the new hire. If you think about it, a new person joins your team. He gets to work on a five different task in a given day with five different, with all the other members in the team. What more do you need? He get to see the whole piece end to end throughout the day. As well, he also get a chance to gel him with the whole team. So certainly it worked very well. So that's all that I had to share with you today. With this, our journey with the promise is carrying continues and we'll keep tweaking and experimenting till we find a better solution. Till then, yeah. I hope you'll also get better and you'll also get better. Thank you everyone. I'm sorry, we are out of time for the questions but if there are one question by the time the gentleman sets up the numbers in the sense. Do you, are you talking about the numbers for the peer programming person? Yeah, so better quality deliverables and this five. I'll just disconnect from this. So when I talk about the better quality deliverables, it's like five brains are working on a given task. Okay, for the three hour task, three, four brains are contributing to it. Four pair of hires are rolling over it. So suddenly it's a cleaner design. It's a cleaner code and above all, it's the same coding style that we are falling across the team. Right? As far as the improvement numbers, if you want to talk about, I would suggest if there are very famous research done by the Microsoft into the, from the professional industry, at the same time there is a great detail research done by the University of Ota. And the numbers are astonishing when it's saved. So the conventional wisdom always talks about that if I'm doing a peer programming, then effort goes by two x, certainly not, it's only a 15% increment. But the benefit that you get because of the reduction in the production, your bulk, it's much higher. It's at least 15 to 20 times better. Okay, with that I close off. Thank you very much. I'll be around if you want to have any discussion.