SHRIKANT VASHISHTHA is the cofounder and Agile coach at Malonus Consulting. He specializes in technology strategy and implementation, distributed Agile, and Agile transformation.
Subscribe to the Collaboration Superpowers Podcast on iTunes or Stitcher.
His tips for working remotely:
- Create team norms to define how you’re going to work together.
- Get yourself trained.
- Don’t work in isolation.
- Give people context on the work they are doing.
- Face-to-face interaction is worthwhile. You get to know the person. It’s more human.
- Share your knowledge.
- Don’t be afraid to try things and fail.
Podcast production by Podcast Monster
Graphic design by Alfred Boland
Original transcript
Lisette: Great. And we’re live. Welcome everybody to this Hangout on Air. My name is Lisette and I’m interviewing people and companies doing great things remotely. And today on the line, I have ShriKant Vashishtha. You’re the Director of Engineering at GlobalLogic. And when I look at your profile, it says your specialties are technology strategy and implementation, distributed Agile, which is what caught my attention, of course, and Agile transformation. You’ve also sent me a list of your publications, and it’s huge. You’ve done a lot of writing. So I’m really looking forward to talking with you. It looks like you also do a lot of public speaking. So let’s get started. Tell us a little bit about yourself.
ShriKant: I have been into the IT industry for the last 16 years. Initially, I started with the normal IT services company. But at the same time, it is one of the largest IT service company in India. The focus was working with many of the biggest, largest IT companies, or Fortune 50 companies. And the projects were also quite huge. So I was talking about certain projects which we were having around 120 people or more than that around, and many of them were distributed. So that was the time I was working in a waterfall fashion. At that time, while working there, I realized that there were a lot of problems which could be sorted out, but the way or methodology we are using was not suitable for that. And that was the time I thought that let’s see whether there are other ways of doing the same thing in a better way. And I moved to another company called Xebia. At that time, I started learning about what Agile software development is all about. There I got introduced to a lot of good things, especially about distributed Agile. And the good thing was we started doing experimentation to make sure how we can improve the way we are working. I’m talking about the time 2008 or before that. At that time we started doing distributed pairing, remote pairing. At that time that was quite new. Considering the kind of Internet bandwidth then, the video communication, those kinds of tools were not available that time. But at the same time, the experiences we were having were really encouraging. We started publishing certain stories of that. And at the same time, we basically started to see what are the other new things which are different while working in a distributed fashion, because there was a lot of literature on working with co-located Agile. But people were still struggling how to do this distributed Agile, so we were coming up with new thoughts and ideas on that. And we started publishing some of that stuff at that time. After working in those projects, I moved to Agile coaching and worked with one of the largest banks in Western Australia as an Agile coach. And there I was part of a team which was responsible for the Enterprise Agile Transformation. Basically there I learned certain things around Scaled Agile. So that was a very good experience. And then I came back to India and started working at GlobalLogic. It’s a long introduction but I hope I gave some certain insights what I went through in between.
Lisette: No, it’s always good to get the background of somebody’s journey. So starting in Agile and then moving to distributed teams and then experimenting with the different things. I’m curious about your experiments. Are there any that you can share with us? Things that you started with, maybe things that totally failed, or things that worked, of course.
ShriKant: I think what I felt is there are certain things which fail, and from the failures you learn a lot. I feel I’m fortunate that I worked with that project which was a complete failure from my point of view, but just because of that I learned a lot. So that was the first project ever working in Agile and that was distributed Agile. And there were a lot of problems. We were pushed to Netherlands and then we had to be part of a new team. We were given only two days of knowledge transfer of a big project which was already working for the last one year. And then we had to start working in that project when we came back to India. So after coming back, the whole project got changed. So the thing is that we were kind of the people who were shooting arrows in the dark because we were not having any idea like what is the foundation of that project. So we were learning from the code. We started doing certain sessions on distributed pairing as well. But at the time, it didn’t work that well again because the thing is that, and I realized a little bit later why it didn’t work. It was because if you think about a big elephant and you are just scratching his tail or you’re scratching one of his feet, then you don’t know what the elephant is all about. So unless you really know or understand what the elephant is all about, it gets very difficult to see or make sure that you’re doing the right things. So I felt that the pairing exercise works well only when you know what component you’re working on. You have the understanding of the entirety of the holistic view of the entire picture. And then you’re drilling down, so pairing really works when you are drilling down. But unless you know what the entire picture is all about, it doesn’t bring you a lot of good advantages. So that was one of the great learning at the time. We started experimenting with distributed knowledge sharing as well. So basically what we did was at the end of each sprint, we used to have a session of one hour in which we used to explain what everybody has done in terms of the coding. And I used to explain on the computers. And that was very helpful. But as I’m saying, these are the experiments as individuals which didn’t work, but I think they are really helpful if you start using them in a new team which is not struggling with what we were struggling with. So it didn’t help in that situation but those were the things which are really useful if you start working in a distributed team anyway.
Lisette: Not every team gets the chance to start fresh. It’s probably more likely that you’re going to get thrown in on a project like you guys did. You had two days for the knowledge sharing and then you’ve got to make it happen.
ShriKant: Yeah, what I have been talking about so far is all about the failures, the things which didn’t work. Later I felt that it is very important to give a good amount of focus on the knowledge sharing as well, and that’s what happened afterwards – that the person who was having a good amount of knowledge, he came to India. He stayed with us for about two to four weeks. And then we really got to know what the elephant was all about. And then all the remote pairing and all the stuff we were doing started making sense to us. And then we were able to provide the productivity which the customer was looking for. But it all came only after learning with all those experiments. Why it is not working? What can we do in this kind of situation? And of course it didn’t work but at the same time they gave us new insights which we could implement in the new projects.
Lisette: Do you think that you learned so much because that person came there in person and was there with you? Was that the right solution? Or was it just that you took the time to really get the holistic view of the project? It was probably a little bit of both.
ShriKant: I think it’s both things. I feel that the face-to-face interaction is really worthwhile. You get to know the person. It’s more human. You can explain on the whiteboard just right away and then see what’s happening. You can take more time, whatever you want. So I feel that co-location is a very important part if you’re working in the distributed fashion. For example, half the team is part of India and the other half is part of, for example Netherlands. So having some kind of co-location is a good idea because then the team jells with each other. At the same time, there are certain things which cannot be exchanged just over the wire and that helps in doing that. So I think that’s a mix of both in this particular case.
Lisette: Interesting. We’re saying we’re going to solve the humanization problem of virtual teams by bringing people together face-to-face, so of course I’m having some reaction. I know face-to-face is the best, but there are so many situations where we can’t see each other. Whatever logistics, whatever the reason is, we’re just not getting together, so it’s an interesting solution.
ShriKant: Actually, I feel that co-location is an important part of the whole thing. If you are making sure that there is a team which is working together, this is customer and vendor relationship, it’s not just a technicality; it’s more about the human aspect. And their getting to know each other and those things helps a lot in bringing the sense of the team.
Lisette: I’d like to talk a little bit more about this humanizing the high-tech aspect of it because what I heard you say was that there are enough tools. We have the tools. It’s usually not the tools that are the problem on this distributed team. It’s the humanizing connection aspect of it. So it brings up a couple of questions. One is how have you gone to humanize your remote team a little bit? What are the kinds of things that you’ve done? And I’m curious about the pair programming. Can you describe to me what that looks like? Are you using video when you’re pair programming? How are you doing that?
ShriKant: There are two parts of the questions. One is how do you do the pair programming, and another part is how do you take care of the humanization part? Is that right?
Lisette: That’s correct. These are two separate questions that I’ve put into one because I got excited.
ShriKant: So I think as far as the humanization part is concerned, we did a lot of things. So what I’ve seen is that even if you do the co-location – and there is a good amount of trust within the team – after a period of time, you lose the human interaction. I’m talking about two or three months, for example. Right now, you can see me and we are interacting. We are going for the lunch. I can feel you. But as you go to onshore, then after a period of two or three months, that whole vacuum is filled by other things in your life. And then the human interaction is gone. So basically the problem with the remote communication is that whatever you’re talking is all about technicalities. You come and you do the work. But the human connection is really gone. You don’t really do that chit-chat which is really important to jell with each other. And that’s why I generally say if you are doing the remote collaboration as well, it’s really important to do the initial chit-chat to see what is going on in your life, to be in your comfort zone and all that because otherwise you are just machine which is focused to make sure that work is getting done. And if that is the case, then because of the distributed nature of the communication, certain misunderstanding emerges and then it becomes very difficult to fill that particular gap. So what we did was apart from making sure that we do all these regular chit-chat, we also came up with the idea that apart from the actual Scrum master on-site, we’ll be having a person called a local Scrum master who is working for the remote team, who can make sure that whatever the problems are there at the local team, he can focus on them. So that is the first part. The second thing is these two remote ends the local Scrum master uses to communicate with each other on a regular basis – not about the project, but how the whole collaboration is going on. And in case there are any problems, any of the concerns which any in the team is making, then how do we solve with each other? So that is a very, very important part. Before, some of the problems, before some human issue used to come, we as Scrum masters used to know early and then used to think what can we do about solving those things. And that particular aspect worked really well.
Lisette: They are the sort of team facilitator. That’s sort of the Scrum master role. But they are facilitating team members.
ShriKant: The facilitation is one part. But at the same time, there was another part. The other thing is that apart from the distributed retrospective, we start doing the local retrospective. So what used to happen was because there was a client and vendor relationship, there were a lot of local things which the local team didn’t want to raise in front of the customer, for example, within the local infrastructure. So it is very difficult to say in front of the customer that there are problems in our infrastructure, or the team spirit within the local team is not working. That gives a little bit negativity in front of the customer. So those issues were important, but people didn’t raise them because of obvious reasons. So what we thought is these are important issues. What can we do about them? And then we started thinking about the idea of the local retrospective. So apart from the distributed retrospective, we start having a local retrospective. So before we go to the distributed retrospective, we did the local retrospective. Certain things which are local to the team, we used to resolve them ourselves. And certain things which are for the entire team, we used to raise them in the distributed retrospective. And that really helped a lot. For example, we used to face issues like this: The whole team is working well, but one person is, because he is very talkative, he talks a lot in the visible retrospective, it looks like he is doing the whole work. So he used to take the credit and other people used to cry. So what do we do about it?
Lisette: Yeah, it’s a real issue. I would think that this would come up a lot. I’ve been in plenty of meetings and one person just takes over. They’re just the star. That’s what they do. But it’s a problem.
ShriKant: So this is a problem, but that kind of issues we could not raise in the distributed retrospective. So that’s where we started having these meetings where local issues could be raised, we could solve them ourselves, and that started helping a lot. That was one part of your question which is focused on the humanizing things. The other part was about how do you do the distributed…
Lisette: Before we move on to that, I want to ask one thing. I read in one of your blog posts that you’ve also created something called the Virtual One Room. And I thought that that was a very interesting idea. So maybe you could tell us more about what that Virtual One Room is.
ShriKant: Distributed communication is all about a lot of confusions around…confusion and misunderstandings within the people. So because of that, we used to face a lot of problems.
Lisette: I’ll just say for people watching, if you have any questions, you can tweet them to #remoteinterview and we’ll get them answered now or in the future. And we’ll soon end this commercial break.
ShriKant: Can you repeat your question, please.
Lisette: The question is I wanted you to describe the Virtual One Room because it sounded like that was one of your ways of humanizing your office.
ShriKant: Actually the problem was that communication through the distributed way brings a lot of misunderstandings. I’ll give you some examples. You send a chat message and you immediately need that person. That person doesn’t respond to you at all. Then you send another message, and again there is no response. And this happens quite often, and then you don’t know what to do. It brings some kind of misunderstanding in your mind. Maybe that guy doesn’t want to talk to me. It’s pretty normal basically.
Lisette: I’m assuming their instant message status says that they’re available. And so you instant message somebody but they’re actually not responding. So you don’t know. They’ve left their status as available, but maybe they went to the bathroom or maybe you went to the…you don’t know.
ShriKant: Yeah. I’m just telling some of the reasons. That creates some of the misunderstandings and the actual issues could be something else. So the actual issue is very simple, that I’m focused on what I’m trying to do, so I’m keeping all my messages away, and I don’t know whether those messages are even coming to me or not. So basically that person is not doing this intentionally, but to the other person it looks like something else. Isn’t it?
Lisette: Oh sure. This happens all the time.
ShriKant: So that is one case. Another case may be, as you mentioned that the person has gone to the bathroom. He has gone to another seat and he is just having a discussion kind of thing. So basically, again you don’t know. So we try to create a kind of Virtual One Room where we could see and feel each other on distributed locations. So what we did was we put a Skype camera for each of the teams, and that Skype camera was active all the time. So we could see who is coming, who is going. We used to greet each other whenever we used to come in as part of the team. We used to greet again when we used to go to our home or having a lunch, those kind of things. First of all it created certain good things in the team that we were able to see each other and the same time certain common gestures or things started happening in the team. But at the same time we could also see, like for example, if a guy has left his seat to do some chit-chat and he is not available right now. So it really helped. It gave a wanting feeling. Those misunderstandings also started going away. It really helped in that sense.
Lisette: When I saw the picture of it on the blog, I thought now this is a great idea. You basically have two co-located teams working in different places seeing each other on video – brilliant solution, actually. It seems really simple to set up when we have Skype or Hangouts or other video conferencing tools. There are tons. And you’re humanizing. The video really helps humanize the office.
ShriKant: Yes. And I truly believe that apart from putting a lot of focus on the tools and practices in the distributed or remote way of working, the humanizing aspect is very, very important – but most of the times, it goes missing. Not many people really focus on that. But from my experience, I have seen that this is one of the most important parts which need to be focused when we are talking about remote collaboration.
Lisette: Do you do any things for your team? This question comes to mind because I get this image of you guys being thrown together with this team in the Netherlands, you have two days to do knowledge sharing, and yet you’re supposed to work together in an effective way. And one thing that I’ve been hearing a lot about is teams who come together and do some sort of virtual team tuning before they start working together on a project – where you write down, you outline here’s how we’re going to communicate. This is what our core hours are going to be. We’re going to speak in this time zone language all the time. Everything is going to be IST. Were the things that you did like that? Do you set up team agreements like that with each other?
ShriKant: We used to call them team norms. And irrespective of whether it’s a distributed team or a local team, we used to do them anyway. So team norms help a lot to define certain group decisions, how we’re going to work together. They come from the team based on their experiences. For example, what we say to the team is let’s come together and think about we’re going to work in the best project of the world. What are the things you would like to have in that project team? And what are the things which you don’t want to have in that team? Based on that, you come up with team norms, and that is a group decision. Certain things which people really don’t like, those things come up front and are discussed; otherwise, you find them afterwards. Those are troubles and you are dealing with them. So I find that it is very, very important to have team norms to make sure that teams start jelling with each other and there are certain team agreements which help the team to work together. So it doesn’t really matter whether it’s a distributed team or a co-located team; team norms really work with each team.
Lisette: And how do you guys document it? Do you use a wiki or a document? Or is there a fancy programming tool you guys all have?
ShriKant: Actually, whenever we are working in a distributed manner, whatever things are there, they are shared. So we have shared wikis, shared code base, video communication – all these things are documented in the wiki, for example.
Lisette: Okay. I was curious. I know that for some people, wikis are a bit unusual. They are a bit hi-tech for some of the listeners. So some people just use word documents or Google Drive or something – whatever works for the team, I’m assuming is what you’re saying.
ShriKant: The whole point is that it is shared. It is available at any point of time. It is not hidden behind the fridge. I call all these things like Version Control System as a fridge. You need to open the fridge door and then see what is there inside. Other thing is which is visible all the time to you. So I prefer those things which are visible to you all the time. So instead of keeping a document in a Version Control System, it should be something which is live, which can be changed at any point of time, which is available at any point of time. It is just there in front of you. That’s where things work in a distributed team.
Lisette: What do you personally like about working on a distributed team?
ShriKant: Actually there are two things. I mean if you think about the Agile manifesto earlier, the idea was that people used to hate changes, and then they started embracing change. Similarly, earlier people used to hate distributed teams because of a lot of problems and communication and this and that. But these days, distributed teams are the norms. This is the reality of the whole world right now that the world is becoming a small village. All the problems which you were having earlier because of communication gap and all these things, they are subsiding because of a lot of technology tools and other things. And now I feel that distributed teams should be the norm. We need to embrace the distributed teams. So I feel that that is the kind of changed atmosphere or environment now compared to some years ago. Now, nobody really feels a pain like why we are having distributed team. The only thing is that we are still evolving the ways to work in a better way. I feel that as far as distributed team is concerned, first of all, they need to have some co-located hours. It really doesn’t work that you are having two separate teams working in the United States and in India. They have 12 hours of time difference but they are working on the same code base. It is very difficult because then you don’t have any co-located hours where you can communicate with each other. Otherwise, you will be talking in the night time or early mornings, and that kind of stuff. So my first preference is that if you are truly in this fashion, then you should be having two separate teams. One is working in the United States, one is working in India, and they are self-sufficient teams doing end-to-end things. And then the team leaders or the Scrum master join each other and discuss about where they have dependencies, and that’s how things work better. I have seen a lot of issues when both teams are working together on the same thing. Then they really work late-night, early mornings, and that doesn’t work well with their social lives.
Lisette: Someone is going to suffer. Somebody staying up too late or somebody is waking up too early. Somebody suffering, and it’s not what they want to be doing, I’m sure, at six in the morning or something.
ShriKant: So that was happening in one of the teams I was coaching with. The first thing I thought, first of all is it really necessary to do distributed nature of work in this team. Then they find, no, we can work as a self-sufficient team as well. So that was immediate solution. Why don’t we work as self-sufficient teams? Distributed nature comes with some problems. You can still have problems when you’re having much more advantages because of the distributed nature. But in this case, it’s very simple. If you are self-sufficient teams and you can work on your own, why have the distributed nature? It’s a waste. We just remove the waste. Distributed way of working works a little bit better when you are having co-located hours. You can communicate with each other. You can share. You can do the pair programming and stuff like that. There I have seen much better results.
Lisette: So basically splitting the team into the time zone areas and then having Scrum master meld them together when needed, and having some co-located hours whenever possible.
ShriKant: Yeah, instead of all the team members coming on the distributed Scrum in the night at 9 o’clock or 10 o’clock and doing the Scrum. It is much better if they are already working in a self-sufficient team. And when there are some kind of dependencies, those Scrum masters talk to each other, and if required, some of the team members also talk to each other and collaborate, but not the entire team.
Lisette: Okay, that’s interesting; interesting solution wherever that’s possible. One thing that this brings up for me is the culture, and it’s a rare opportunity to talk about culture in this case because culture is different everywhere. But the further away you get in time zones, the further apart the cultures can be. So have you had any cultural issues on the team? Have there been any cultural things that have come up for you guys? Because it sounds like you’re working with people in the U.S. and in the Netherlands, and of course in India.
ShriKant: Cultural differences are there, to begin with. For example, people from the Dutch side can be very straightforward.
Lisette: Very blunt, yes.
ShriKant: Very, very blunt, which you may not like as an Indian person. If we talk from the cultural perspective, I feel that Indians come from the hierarchical culture and they still focus on the family structure, joint family structure. So there is a lot of bonding. So having a team is very easy when I think about Indians because there is not much individualism. There is a lot more groupism. So it’s easy to have a set of people make a team and they really jell with each other. So that is very normal. But at the same time, because of the hierarchical culture, there are problems as well. Many times it happens that people don’t have that kind of understanding or training sometimes where they can talk to anybody in the world. So it happens many times that only the team leader is talking to the representative on the customer side and that kind of stuff. So that comes from the hierarchical cultural background. But this is changing very rapidly in India as well. The new generation is very straightforward as well because of the whole set of changes which are happening around the globe. When I talk about distributed collaboration, then the cultural aspect also creates some of the issues, and that’s where I said that having a person at the onsite and at the local team, basically they communicate and facilitate the team – is a very good idea because certain cultural aspect, both these people may not understand in isolation. So when they communicate, then they understand, oh, this was because of that reason and I will handle this situation. You don’t have to worry about it. In that sense, I’ve seen that particular model really works well.
Lisette: So basically leaving it up to the local Scrum master to help facilitate those cultural things that come up, just like any other issue amongst the team, and basically just talking about it. And I’m assuming that working in the Agile way, that you have plenty of opportunities for retrospectives and feedback so that things don’t go too long without coming up as an issue.
ShriKant: It depends on the kind of comfort these two teams are having. Even certain individual may feel but they don’t… It may be part of the culture that you are not putting the issues at the forefront and you still keep on taking it until it is really out of your control [laughs].
Lisette: Wow! I have experience of this too [laughs]. Yeah, sometimes there’s not much feedback or there’s such little things. You think of them as little things. So you want to be nagging and giving feedback all the time and these little things add up over time. And after a while, it goes to a point where it’s no longer in your control. You’re totally irritated and something weird happens.
ShriKant: Yeah. That’s what I was talking about. Some people try to avoid certain things to put into the retrospective, which becomes very related to a certain team or certain team members. I’m facing this problem. It becomes really evident. This problem is because of that team or team member. So generally, people try to avoid that kind of situation. But as I said, when you have a certain facilitator who understands the setting of each team, then handling those kinds of situations becomes much easier because then you can also say that based on your understanding. I’m not saying that you don’t have to put those things in the retrospective. Only thing is that they are tricky situations and not all tricky situations we can handle in the retrospective.
Lisette: Right. Some things are very delicate or very personal in nature. Yes, weird things come up. Everybody has been on a team where something weird has happened. I think I can imagine everybody has happened. I like the idea of having a local facilitator, somebody that is outside the conversation, that helps to heal wounds, maybe, somebody who can at least provide a framework for the conversation to happen. I really like this idea.
ShriKant: Yeah, because otherwise, if you think about the whole idea of Scrum or Agile, we talk in terms of the ceremonies. We have the planning meeting. We have retrospective. We have this and that. And the whole team really works in that fashion. This becomes really mechanical, in my personal opinion. You need to have certain space where it’s normal. It’s very informal. We are talking about the teams. We are talking about how things are working. How are you? You are fine, and these kinds of things, and these ceremonies don’t have space for them. So that’s where this humanizing aspect is very important, where those two people are talking to each other and making sure that things are working fine on each side.
Lisette: Right. Funny that it’s really the human aspect that we struggle with on the remote working. There’s an app for that somewhere. So with the tools, there’s always a solution, it seems. It’s maybe annoying to find a new tool and it’s hard to learn and get them implemented, but there is a technical solution for most issues now. And now we’re really dealing with how do we bring the human back. So I think it’s an interesting development in the whole aspect.
ShriKant: Yeah, and you cannot avoid the human aspect anymore.
Lisette: Right. We’re not robots, which is the best part. We’re human. It has to be addressed. Indeed.
ShriKant: Many times, it happens that that is not the thing which we really discuss. We discuss about the aspects of teams and team members and ceremonies and tools and all that. But many times, I’ve seen that this aspect gets missing. For example, I did a session for one team which was focused just about how to be a fun team.
Lisette: Wow! I like that.
ShriKant: Yeah, how to be a fun team. It was not about things like how to do the pair programming and stuff like that, but more about how to respect each other. How a person feels when you criticize him all the time and then you are putting his back on the wall. How to deal with those kinds of situations? Can you show those situations in front of the team and make sure that people know that these are the situations, they need to handle each other because I think we need to understand it very clearly now that when we are working in Agile teams, we are talking about the collaborations. We are talking about a lot of collaboration and human connection. Not everybody is very good in dealing with humans, and that’s where you need some kind of training. You need to have some kind of understanding how a human think and behave. So apart from the technical aspect of all these things, I feel there needs to be a bit more focus on the human aspect of the collaboration.
Lisette: And training people on how to interact with each other. It sounds like that’s where the team norms could really come in handy as you’ve got this basic…
ShriKant: But I’m talking about a situation where there were no team norms. This was already a working team. They never discuss about how they are going to work with each other. And it was an out of control situation. Then you need to have some kind of firefighting tools to see what you can do in this kind of situation. So I’m talking about that kind of aspect.
Lisette: Yeah, I think it’s been really interesting hearing your stories and some of the things that you’ve struggled with because I think that almost every team is going to be able to relate to this. It’s very curios. I know we’re nearing the end of the time here. So is there anything that I didn’t ask about that you would like to tell? I have a whole list of things that I didn’t get to, but we can maybe do a follow-up interview or ask you some follow-up questions via email. But is there anything that I didn’t ask?
ShriKant: I think most of the things have already been discussed. The only thing is I may want to talk a little bit about the distributed pair programming, how it was for us. We started experimenting with it in 2008. Initially, it was with our customer who was based in Netherlands. But at the same time, after a certain time, we started doing it ourselves. Ourselves means that I’m working from home and so let’s do this distributed pair programming. So we started doing in that fashion. Then we started doing the distributed stand-up also with that person that way. So he was working at home, but at the same time he’s still available for all those things. So those things became very evident to us. One thing that I found with distributed pair programming is that you find much more at ease when you’re working in remote fashion because then you can see your own screen. You are not looking like this on other screen. And you are much more comfortable. Because of your headset you are really listening what the other person is trying to say. Remote pairing will not work if you don’t communicate. So you have to communicate. So the basic things which we talk about, the normal pair programming practice, and sometimes it is not that you have to really do it as part of the remote pairing. So you need to speak. You need to see what you’re trying to do. And there is a lot more communication, a lot more collaboration. And the pairing is much more focused. So initially, I was having a lot of apprehensions how this whole thing is going to work; but after a period of time, I found that doing remote pairing is much easier, much more comfortable, and gives a lot more output.
Lisette: I can imagine that actually being side-by-side physically with somebody day in and day out could be very uncomfortable in a number of ways. So maybe it’s just you’re not in your home setting, or there are a million reasons why I could be uncomfortable. But actually pairing online could be very comfortable because you’re in your own setting. I have my favorite mug and the temperature is exactly the way that I like it. It’s less intense while still being very connective. When I talk to programmers, I’ve heard a lot of people talking about pair programming. But I think it can also work in various other aspects. For instance, I work with a woman in California. She and I work on Skype every evening for a couple of hours together, working on our own stuff. We have the video off and we just talk as if we’re in the same room together.
ShriKant: Yeah. So for example, I sometimes do a pair blogging also with my friend. It’s nothing about programming; it’s more about exchanging ideas. You have some idea about the blog, but let’s talk about it. Let’s structure it. Let’s hear your feedback. You’re thinking that I might want to do this particular as heading, and what do you think about it? It didn’t look so nice. Maybe we can change it this way or that way. So a lot of exchange of the ideas really happens. And sometimes I’ve seen that with that exchange of ideas, the blog which you could finish in one or two days because you need a lot of thoughts is finished within half an hour. So it’s much more productive session in that way.
Lisette: Right. You’re getting feedback like hey, what do you think of this title? Or I’m not sure about the graphic. Could you take a quick look?
ShriKant: Yeah, or even the whole idea itself. You say that I want to write about this topic. And I say, based on my inputs, this idea won’t work at all. Why do you think it’s a good idea? And then I give a lot of reasons. Then he says, yeah, you’re saying right. So those things which you find later based on the feedback of others, you can get to know about them immediately and can work on the refined way of your language and the structure of your blog.
Lisette: Right. So the advice then is pair up with somebody while you’re working remotely. Even if you’re not working on the same project, just pair up and work together.
ShriKant: Yeah, if you are collaborating, I would say you should pair up. Working in isolation really doesn’t work. It’s not so much productive as pairing is.
Lisette: Right. There are certain tasks like in Agile that if you’re deep in the code, you really want to be deep in the code. You want no interruptions. But then for other things, when you’re not deep in the code, you want open collaboration, idea generation, and brainstorming.
ShriKant: Yes. One other thing which people say about Agile way of working is evolution of design because we don’t have design phase already, which we used to have for one month or two. And then we start the coding. Now it’s all part of the whole sprint. Now, where does the evolution of design come into picture if you’re working on your own in a solitude? That evolution of design comes into picture when you exchange your ideas, when this guy says that this is what we need to implement. And then he says that there is a better idea in doing the same thing. What about this? What about that? That’s where the evolution of design comes into picture. So pairing is really essential for the evolution of design from the Agile perspective as well.
Lisette: I really like that phrase: pairing is essential for the evolution of design. Brilliant, that will be used in your interview for sure because I agree with you. I think that there’s a time for working in isolation and there’s really a time where you need to ping ideas and get things from totally different people. And in a remote setting, that’s difficult to do, but it’s necessary for the evolution of ideas. We have to mix and generate new things. So you’re right. I really like that the focus is on this. And we’ll need to find another name besides pair programming. Maybe it’s just pairing. You’re pairing with people.
ShriKant: I start saying it now, pairing. That’s it. I don’t say it as pair programming anymore, because it’s pairing. Anybody can do the pairing. One other thing, as part of pairing, what I’ve seen in the Agile team is I don’t see the islands of the knowledge anymore, which was very common sighting earlier. So a particular person can only change this particular piece of code. If somebody else will change, then something will happen, and we don’t know what will happen. So that used to be a common sight earlier. Now, because everybody is doing the pairing with each other, everybody knows what is going inside the code. It is very normal in the teams where the pairing really happens. Anybody can touch any piece of code at any point of time. So for example, you and me are pairing and you have some problems and you go for some leave immediately. Then it doesn’t mean that your work is stuck. Another person comes and he just starts working on your work. It’s pretty normal in this kind of setup. Earlier, it used to happen that this person will come and then she will start working on this piece of code. So that is no more the case.
Lisette: Right. And when they leave, it’s gone. Sometimes the work, the knowledge, the information is just gone – which is crazy.
ShriKant: That also happens because everything was in his or her head. So now she is gone, so the whole knowledge is also gone. People generally say that pairing may be two people working on the same code. But it is not just two pairs of typing; it is much more than that. It is knowledge sharing. It is collaboration. It is evolution of design. So many other things come into picture which people generally don’t think. So that’s where I feel that pairing is much more than just pair of typing.
Lisette: I agree. I think that it seems to be one of the essential things for humanizing the office also and making things really work on remote distributed teams.
ShriKant: Yup.
Lisette: So one final question for you, which is if people want to learn more about you, if they want to read your extensive blog, if you’re in Agile and you are doing any sort of remote work, or even if you’re just in Agile doing Agile transformation, you’ve got to read this blog. So where can people find you online? How do they connect?
ShriKant: I think they can connect with me on agilebuddha.com. They can connect with me on Twitter as well. So these are the two things where I’m available at any point of time. Definitely, it is also easier to connect on LinkedIn as well.
Lisette: Okay, so LinkedIn, Twitter, and the blog. And I’ll put your contact information in the liner notes so that people have it at their fingertips.
ShriKant: Yup.
Lisette: Thank you so much. I feel like I learned a lot today. There are some really great nuggets of information that I look forward to writing up and expanding on. So thanks very much for this.
ShriKant: Thank you. Thanks a lot. It was a very good setting, talking in the remote setting. It was a pretty good interview, I think.
Lisette: Great, thanks. All right, everybody, until next time, be powerful.
