 But it so happens that this is not as effective as as I had imagined because of so many constraints which you would see So this particular Experience report is just going to be about what did I do with some of my teams and I'm going to share it with you guys I'm going to quickly tell what I have done I'm just going to open it for questions if you have any questions We can just ask me those questions specific ones and then we can wrap it up. So that is going to be the agenda for the day So let's start with the first one So as the title goes to pair or not to pair So if you see one of that few challenges that most of the non-technical coaches face in their agile journey is of course We all start with scram. Of course We all start with Kanban and so many ceremonies so many things to talk about I'm sure most of you would have understood by now that most of the teams are very quick at getting these jargons You know, but they have become very fluent in their jargons very quickly It doesn't take them so much time to understand what a DSM means what a respect respect of us But of course effectiveness is questionable But nevertheless most of the teams what they do is they just start with something and then they finally feel that okay They've done something and they just stop there But we also know that in the process in the process if the teams have to get to a state That's why I've used the word commendable agile fluency by which what I mean is if they have to reach a stage Where they are actually agile where they reach their back I mean go beyond their barriers and boundaries management practices alone is not enough So you guys agree with me all of you all right So the next one is if you see technical practices are definitely very important But we also know that it's the most difficult thing to implement because of some of the constraints that we have in the Organization and one of the biggest constraints we have is most organizations have a lot of budget Reductions in terms of how many coaches they can actually have because when it comes to technical coaching There are a lot of hands-on Experience is required by the coach and they have to practically sit with the Agilist and the team members to get it done So this is also a challenge and what is the last challenge? I mean, this is something which I've noticed I just feel that the practices are the most toughest thing to change just because I think the engineers are very personal about it You know unlike your management practices when you talk about a meeting when you just tell them Okay, you can change this meeting this way do this do that They just go ahead and do it but when you talk about practices, it's almost like the bread and butter It's like when I've always seen team members being very sentimental about it because that's the way they know coding and that's the way They know testing and anyone who comes in questions it It's like not happening because that is like challenging their status quo Which obviously means that the pain factor is also going to be more So these are the challenges that I have personally faced when I have to coach my teams So I'm sure some of you would relate to it as well So quick show of hands. Do you have the same problems or you have a different set of issues? All right, cool then some of you have the same problem. So what do you think of the metaphor? Why do you think I've chosen wine and cheese? Why do you think it's wine and cheese? They pair well, okay? All right, so what happens if I'm gonna pair differently if I'm gonna have a different cheese And a different wine will that not work well? It won't taste better. All right, okay, let's see So now well, where do we start? So where do we start so one of the things that I'm going to propose or what I have been doing with my teams I just call it as non-homogeneous pairing by which what I mean is I'm not necessarily looking at Pairing between members who are technically, you know, like say the ones who are writing code or the ones who writes All right, so test cases or ones who is involved in the product development But also involve people other than these guys in the team like meaning the other stakeholders in this team So in my case, I started pairing with my team members meaning I start pairing with my developers I start pairing with my testers. We'll see how I was going about it But the whole idea is non-homogeneous pairing So if I have to elaborate a bit about what non-homogeneous pairing is like say obviously as the name goes It's gonna be non-homogeneous which means I'm gonna bring in people with two different sets And I'm two different skill sets. I'm gonna put them together. I'm gonna ask them Okay, how it's gonna work for you now So now this is your task and what are the things that you're noticing? So the second one is it's gonna be very strategic because it's not going to be like a very goal-oriented meaning It is not like you have one single goal and you guys work towards it You guys strategize it in such a way that this experiment is successful and that goes with the next word which is Experimental by which what I mean is it's okay to have wrong cheese with a different wine meaning what I'm trying to say is don't be very Synical or don't be very get it don't get into the smell which is analysis paralysis Don't be very specific about matching the right components because you never know because agile is all about doing just giving give it a Short and then see how it goes it might work or it may not work no harm in it So that's why I'm going to call it as experimental As always it's gonna be time box because you don't have the luxury of time You cannot do things forever you have to time box it and see have some specific idea and mind and see What are you going to derive out of it? Haven't said that when I say idea the idea here is to see what the team members are going You know so don't have any preconceived notions about this is how it has to be be a little bit open to what is happening with the team members and The fourth one promise course as with any pairing technique It's always advisable to be promise course at least when it comes to pairing I'm not endorsing this for real life, but in pairing. Yes, it's fine So in the last one what is very important is Executed with awareness any idea what it means. What do I what do I have to say with this? What do I mean by executed with awareness? Anybody anyone Very conscious about it. You know when you are especially when you are a coach I'm assuming that most of you have an ability to understand what the other person is thinking or rather I'm not I'm not saying you're going to judge the person But you're a little bit empathetic towards what is happening in the situation So do things with awareness don't get carried away by what is happening in decisions So I'll share some of my experiences like how team members might react to such a proposal at the end But as of now you can just remember be a little bit aware, you know Just be aware of yourself see what is happening understand your process and see what is happening to you internally so that you can Actually be with a team member and then start this exercise So why are we doing this? You know like I said one of the challenges that I've gone some few of the challenges that I've already mentioned But one of the biggest biggest starting block that I had was a lot of inhibitions about starting something new So instead of letting a team member figure it out themselves. I started doing it myself, you know I started getting into the floor, you know started embodying myself with the team Of course, I'm not developing the product with them But I start becoming part of their process which means if I'm going to work with the team if I'm going to coach With the team it means that I'm going to be with them throughout the day It's not like I just attend their meetings and then I just walk out so day in and day out the entire day I'll be with the team with different people and then it's a very good experience. I really really enjoyed it I'll be just talking about the benefits. So this is what I'm going to talk about So the whole idea is about non-homogeneous pairing. So I was just going to quickly elaborate about What all things that you have to remember when you are getting in engagement like this and what are the benefits? I'm going to tell you a few tools that I use as an intervention also for some of the other practices That is up to you guys to go and research on that All right, so any questions on that any questions on non-homogeneous pairing or until now or as I just move on Nothing all right cool. So I thought I'll just quickly give a intro about myself So I just call myself as a greedy soul because I'm very very greedy So my name is Karthik Amal Balasubramaniam and I work for agile FAQs as one of the consulting coaches And my name is really really long. It's like very long. So people call me KK So you can just call me KK and it's very easy for everyone So the whole journey for agile has been like very Self-driven and have been a developer and I've also been practicing psychotherapy for some time now So I hope I just get better at it eventually. So this is my quick background So now talking about what is this right approach to pairing although I was not very sure about using this word right because I just believe that There's nothing called as the right approach You guys have to just go ahead just do it and see how it works for you quickly get a feedback recalibrate You know that that's exactly what it is But since I have to say something and just using right approach as a word But there's nothing called as a right approach. So a few things that I do with my team is so the first point Which is like make a contract. So this is something I do with all my teams irrespective of whatever I'm doing So you understand what a contract is any idea? someone You know what a contract is set off Set of agreements. Okay, cool. Okay. What kind of agreements like say We had agreed to meet for this session at 230 and then I said this is the topic These are the slides. This is the speaker and you have all the logistics set. What are the other kind of agreements that you guys have here? Sorry Violations like that will be also that's more like a working agreement, right? Okay, cool. All that all that is true But what I'm what I would like to really emphasize here is so contracts has been a very Favorite topic for me because I've seen that being as a solution for most of the problems that I've had with my agile teams I think I've presented about contracts and multiple other sessions as well to give you a quick intro about what each of these means like the admin contract professional contract and the psychological contract So admin contract is generally all the logistics. So when I go and decide to pair with a team member I just talk to the team member on the team asking. Okay, this is what I'm proposing So can I come at so-and-so time? What will you be doing at that time? But is it okay if I just come and pair with you and see what is happening? So that is my administrative contract. All right, so meaning I'm just fixing the time I'm just fixing the location what we're going to do and now comes a professional contract So what I mean by a professional contract is so in this particular room There is a contract that we already have meaning For instance when I started the session, I just asked you guys So this is what I'm planning to propose. Do you guys have any disagreements, right? I'm just making a contract with you guys just to make sure, okay We are all on the same page So you guys have an option to walk out if this is not something that you're signed up for Right, so that is a professional contract. So and the last one is psychological contract meaning profession to give it very shortly Professional contracts are very role-related So there are always role-specific things that you have to do because you are a manager You have to ensure the employee doesn't leave the organization, right? So that is almost always understood that attrition is always because of the manager things like that And what is psychological contract? So often I see that the admin and the professional contracts are very well carried out in most organizations I would say in most of the teams but psychological contract not really So when we say a particular person has to do it and if it's a compulsion then there is a problem there So psychological contract is where I asked them, you know, are you really okay to do this? If you're not okay, what are the problems you have so basically I engage in a conversation So that kind of brings out the ulterior out in open So it's a lot more easier for me to carry on with the session So I'm not forcing anyone to do this because if you see the problem with most practice Adoptions is most of the team members are being forced to do something because that's an organization norm Especially in services industry, it's because the customer wants it. They almost always go ahead with it But even in such circumstances, I would strongly recommend contract not just in this pairing situation Be it anything apply it and I think it will make wonders to your team All right, so that's gonna be the very first step So what I'm gonna do is I'm gonna make a contract with the team at all three levels Basically, I get a consensus from them saying hey guys, this is what I'm planning to do Are you okay with it? Right now comes a second point. So like with the other pairing I mean I'm gonna take up the navigator role alone, which means I'm not gonna write code I'm not gonna do the actual work itself, but I'm gonna observe what they're gonna do So here it is very very important. So just imagine me sitting next to you and watching you all the while how it's gonna be Will you will you be comfortable with it? No, all right. Why? Absolutely, so so why why does that happen and why does that happen? Because you're afraid of making mistakes, which means there is some fear There is some fear of punishment and also there is a fear of being judged in order to see okay What am I doing? Am I good bad or like especially when it comes to programming people do have a lot of things about that So especially when you're doing this be very very careful. That's where I have some more Sensitive items as well, which we'll come back But as of now, you know if you have to be a navigator just observe what the team members are doing and then make notes You know meaning don't threaten them But make notes make a mental note in terms of okay. This is what is happening. Basically be open Don't have any preconceived notions about this is how it has to be You know, maybe one we can take some simple philosophy That's what I mean by focus on the big picture just focus on the high-level principles But never get into the nitty gritties of how it has to be done just understand that okay It has to let's say for example if you understand that a code smell should not be there Don't tell them this is how it has to be there if someone is writing a piece of code See what they are doing and give them a chance to explain that goes a long way so first three points contract and then be a navigator and ask ask is also very important because sometimes Ask coaches when they say why I want to emphasize on this ask partners when I say asking it means a conversation as well It is not always about yes What I'm saying is like basically observe, you know collect as many things as possible and be watchful of what is happening. Don't lose some Tiny details. I'll be just giving you some examples on that. Maybe that would help So ask what I mean by ask is have a conversation, you know Try to engage in a conversation so that there is a lot more give and take and it's not like one sided Be very very careful. Don't make it as an audit exercise Okay, this is something people have to be very watchful of because some of most of them are like very scared of such instances So don't make that so the third one is like I said focus on the big picture It's going to be lean experience systems thinking or whatever principles apply to you And the fourth one is be confident and don't be overconfident or cocky because it's going to really put them off And the last one is be inclusive sensitive and non-scary So I think the non-scary part is very important You know just try to be inclusive and you have to experiment it you have to see Start pairing with your team members and you will understand what I exactly mean But as of now few basic approaches for pairing would be this so any questions on this Anyway, I'll come back to making notes part again, but any other questions or I'll just move on to the next slide You guys are clear All right now talking about So since I said it's going to be a wine and cheese example We have been talking about pairing the right kind of wine with the right kind of cheese So it also means that you're going to pair with different kind of people and all the cheeses are not the same So if you want the best taste One of the things that you guys could do I'm just assuming that since you are coaches You have some experience in life coaching and you have some experience with people handling people and all that since you're doing It with awareness. I'm just putting it with some caution and just saying that be the right wine for your cheese You know try to modify certain attributes about yourself That's what I meant when I when I mean what I mean by Executed with awareness because see what is happening see what the other person's requirements are don't jump into conclusion with the template Because that is going to sabotage the exercise All right, and why this is very important any idea why because the whole reason for doing this is to start something Right, we want the technical practices to start and I'm starting with pairing But what will happen if you're going to sabotage this with these notions It's going to be very difficult to start these technical practices again in the team because the teams are already scared It's almost like once bitten twice shy So be very very watchful. So in the process of getting somewhere don't ruin it for yourself Just be a little careful about what you're doing because it's really really threatening to sit next to a team member and see what They are doing so make sure you're friendly make sure you really understand what they are doing and be non-judgmental I think that would really go a long way other aspect is so this is also something I've realized in the journey because initially when I started I just paired one way with the developers, you know because I was just thinking okay This is what I have to do. So let's see what they are doing because the primary Goal or the objective was to see how how are they coding? You know what is happening with the code? What are the code smells we have what kind of issues they have? I mean obviously if you see you see multiple issues like say the number of copy paste in the code that you see is like Unimaginable and I've seen people and I'll be sitting next to them whenever there is a bug most of the time at least 50 60 per 80 percentage of the times I would say most of the developers they do copy paste and we all know that the moment you copy paste something It's a smell it's a repeatability smell, but very rarely people do refactor So things like this has happened, but be very watchful of that and see how you can correct them very positively with very positive feedback But eventually what I've realized is not pairing with developers alone is useful. You might have to just start pairing with different people Because in the entire value stream it is not just the developers who is going to be involved in the product development There are other stakeholders as well like your technical writers sometimes your architects and even managers if you could pair with pair with Them for some of the practices. I think it goes a long way Just sit with them and see what what is happening and then do it as a team and you'll have a lot of insights So any questions on this? All right, so I kind of covered what known homogenous pairing is and what are the approaches What are things that I recommend and I also covered What all kind of pairing that you can do so now coming back to a few examples that have that I have seen So recently I was I was doing this exercise with one of the testers. I'm just giving an example that comes to my mind So I was just doing this exercise with one of the testers. I was just sitting next to him I was just developing a piece of code I mean he was just testing and I was just watching what they were doing So what I've realized is there were some of the cases see I'm a layman So I would I would assume that my understanding of the product was only limited because I've just started working with the team for a month And they would know better, but when I started looking at certain things There are certain expectations that the end users will have right so when I started asking those questions to the tester I just realized that all the while they have been looking at what the developers have given and they've hardly thought through it Meaning they've thought beyond it So there was a limitation and when I asked those questions then that initiated the conversation then when we when we just went When we did understand, okay, where it went wrong It all went back to the requirement gathering part wherein how did they even did the user story splitting? So the testers were not even involved in the user story splitting So if I had ideally asked them in a very common room if you just pull them in and I ask okay What are the problems in your team often? I will not get these details But when you actually sit with them and see what is happening you will notice that there are so many Organizational impediments like this which is really really very high. So coming back to making notes part So there are certain common repetitive items that you will notice usually some tool related or some external team related So especially if you're doing an assessment for the first time if you're just being with the team for the first couple of weeks If you're gonna start pairing with them, you will start noticing a lot of similarities You know make notes of it because it is very crucial for you to get the big picture and give it back to them Because these are things even if you do a value stream exercise with the teams I've noticed that these items never come up in the issues Because they always talk about symptoms and very rarely do people get into the real problems and start discussing about it So that's what I mean by make notes meaning it really helps because Sometimes what I do is I may not even tell the developer or the test it about what I have observed But when I start pairing with different people I get some collective idea about what is happening right So now coming to what are the advantages? What are the tangible the very first tangible here is you know I feel it kind of removes the inhibition about pairing and pair programming if it is done, right? Especially if you are being supported if you're friendly people kind of get away with inhibitions and they really don't mind pairing with you I had this problem when I was working with the Chinese team because they had a lot of issues with Working with their peer meaning they were not very okel about it They're comfortable to work in their own cubicle and then just do whatever they have to do So I started with pairing started working with developer sitting with them and sometimes have some friendly chats It doesn't matter. It's not like you have to always ask about work and what they are doing Have some friendly banters and it really really goes a long way So it's a first part and the second one is it sets the stage for the other practices because success is going to breed success And like I said, it's going to help you visualize the value stream Many things the team members don't even specify but when you start pairing with them You start noticing so many symptoms and helps the coach understand individual concerns I have always had this experience every time I have a one-on-one or every time I sit with a team member I hear more than what they would tell me otherwise in a team meeting So interestingly, so I have to share something here So I do some interventions and one-on-ones with the team members to understand what their concerns are and if the team is Disfunctional, you know meaning what I mean is if they are not very close in the team if they are not working as a team to begin with They have a lot of you'll see a lot of patterns So once I was pairing with the teams and interestingly every team member gave me something about their team They said this is not okay. This team member is not okay It was just a very casual chat and also what was very interesting is every team single team member told me don't tell anyone You know, I have given you this input, but don't tell anyone and this is a very easy situation for me So this is where I'm talking about awareness. There are two ways for me to handle it. One way is I can just say Okay, I will not tell anyone and I just move out of the room. So in the process I might assume that I'm building trust, but if you say it is actually not the case So what I usually do is If that is I mean usually what I do is I generally I intervene I just put them on a spot but try to be friendly about it humor is about it But I do tell them exactly what I have to say In fact in all the instances with every team member I told them if that is the case What is the point in this conversation? So what I will do is I just tell them, okay I will ask you to come into a room. I will not put on you put you on the spot But please do discuss about this issue. So be very very watchful of what you are doing That's what I mean by awareness because in these kind of arrangements and engagements team members do tell you a lot of things Which they wouldn't tell otherwise Yeah Creates a positive synergy. Yes and helps the coach see the real problem So what I mean by real problems is you're not going to scratch the surface. It's not going to just look at the symptoms You're going to look beyond that All right, so I think I'm largely done So finally I just want to quickly talk about few tools that I use which really helps me in the process as well One of them is contracts which I've said of course group discussions and value stream maps and Two chair techniques is something that I use when I have to resolve some conflicts and team members Let's say if there are unspoken conflicts because of which if certain things are not happening, you can just Google for it I'm not going to talk about this in this particular presentation So that's that's two chair technique for you. So these are very handy for me, but you guys can try an experiment All right, so I think I'm done. So please don't judge me. I'm not endorsing drinking here Just want to say wine doesn't judge me neither should you It's just just a metaphor to say how it can be different and just just be free You know, just be very playful about it. Just toy around with the whole idea. I had great fun doing this I think I've done this for the past eight to nine months with like about nine teams and I had a really really great time So thank you so much. So we have any questions. I'll just take them up now. Yes Yes, hasn't okay. Why do I have to have a name? Okay, I mean I'll say what my role was maybe that could be the answer But I wouldn't say it is very role-specific. It need not be a coach as well I would think it can be anyone in the team who can carry on with this But since I was a coach, I was doing it as a coach There was a there was a role specification what was expected out of me and there was a challenge as well So it went on with this why just started pairing with different people meaning what I do This is actually a very crucial point that you made How will they trust me if I'm gonna start pairing with different stakeholders, right? That is a dysfunction and you got a point already there So if it is not happening that is a dysfunction and the first thing that you have to fix is that and not really about your technical Practices just fix the trust part first and eventually things will fall in place There might be another problem that you might serve it. So did I answer your question? So any other questions? Yes No, actually, I didn't I didn't measure the productivity at all because unfortunately all the engagements Have been like for like because it had various different geographical location It was for a short span and the intent was also not bad The intent was mostly to see how well they take a pairing You know, how well they start pairing with each other because if you see I don't know if you guys have this Challenge but even though we say we are doing agile even though we say we are working as a team and all that often I've noticed that team members work on individual tasks. You know, they really don't go beyond that. So productivity. I have not measured No, I think I'm also getting late. I guess maybe one question And then So you're asking me if I can pair over phone So I have tried doing with few teams in the US But what I've realized it is not very effective because here what I'm really looking at is the actual problems and the real problems and the Conversation which doesn't happen through any of this virtual mediums But nevertheless, if you don't have an option, probably you could try that I have tried it as well But I felt this is a lot more effective than this virtual means Sure. So so thank you very much. Thanks for your patience