Archive for November 2014
This is part 3 of my travel blog on my current business trip to Bangalore, India. The two previous parts are here and here. In this article I want to talk about the various communications challenges we have in working with globally dispersed teams and in particular with the one here in Bangalore.
The main purpose of my visit to Bangalore has been to enhance communications. To meet all the people I regularly talk to on the phone or exchange e-mails with. I’ve met several team members you have spent time in Vancouver already, so this has been my turn. Meeting face to face certainly provides the best medium for communications. Face to face is the most reliable mechanism, especially when you can discuss things over a period of time (in this case I had two weeks). But the trip to India is quite grueling and it’s a long way from home. So practically speaking we need other ways to enhance communications for the rest of the time. A key part of face to face visits is to learn who knows what, so in the future people know who to talk to.
One of the big reasons for this trip was to solve a number of lingering problems that just didn’t seem to be getting solved. We would think decisions were made and then a few status calls down the road they would resurface as open again. Generally it appeared communications between the various teams on this project were facing some serious challenges. Most of the discussion in this posting isn’t specific to these particular teams or to teams in India. They could equally apply to teams in different cities in North America, or even sometimes teams on different floors of the same building. But since I’m writing this in Hong Kong airport on my return from Bangalore, some of the items might have an Indian flavor to them. I talked about some of these issues in my blog posting on the umbrella ceiling which was to do with working remotely, but I think this topic deserves more discussion.
Roots of the Problem
I think the biggest root of this problem is that either people are trained that its best to be self-sufficient and try far too hard to solve things themselves rather than ask for help or people just don’t realize that there is someone else who knows the answer that they can ask.
Another cause might be politics between different companies when the teams work for different companies and there is some higher level interference because management wants things to look better than they really are. The paradox here is that if the team did ask for help, then things would be able to get better. By not asking for help, maybe you can create a short term perception of super-human ability, but this then just falls apart when the first milestone is missed.
Similar to the last paragraph, project time pressure also leads to a certain amount of bad decision making in this regard. Programmers under the gun will just work on their short term deliverables with all their effort and ignore e-mails, not read Wikis, etc. Doing this saves a bit of time in the day, but costs dearly if a key piece of information was communicated but not received.
Technology is Not the Answer
There are all sorts of great technologies to enhance communications. Video phones like Skype, all sorts of IM clients, very fancy telepresence setups, Wikis, blogs, etc. People are almost always connected these days to the Internet, so even with terrible time zone differences like between North America and India, communication can still be fairly immediate. But this all depends on people actually using the tools. A lot of times people see all these tools as a distraction and tend to avoid them.
The really hard problem here is how to disseminate important information that people will pay attention to. If there is too much information, then it’s just treated as spam and ignored. If there is too little then there are communication problems or people don’t bother checking for it. Add to this the problem that usually a new piece of information needs to be communicated three times in order to be absorbed.
Most Programmers are Introverts
Independent of where a programmer lives or works, whether it’s Canada, South America, India, Asia or where ever, there is a pretty good chance that programmer is an introvert. This usually means that the programmer almost has a physical repulsion to picking up a phone and calling someone. This usually means that the programmer is not going to arrange a telepresence session on their own initiative. This usually means the programmer won’t arrange a remote desktop session to work with someone to solve a problem.
Using e-Mail to Delay Communicating
E-Mail is often used as a way of delaying communications, especially when different time zones are involved. A good way to put off communications is to just send an e-mail. Often you won’t have to deal with the answer until tomorrow. It’s common to see a question e-mailed one day, then the next get a response asking for clarifications, then send the clarifications, then the next day get back an answer to the wrong question, then send further clarifications, etc, so that a simple question takes a week to get answered even though people are being fairly prompt with responding to e-mails.
E-mail is also a continuous interruption. Managing how you answer and manage your e-mails can be a big productivity booster. Certainly turn off audible alerts when you receive e-mails and don’t let them ruin your concentration on your real job. Perhaps set aside specific time slots for answering e-mails.
Special Problems to India
People often list language as a problem when speaking to India. One thing to keep in mind is that India actually has 1,652 languages. Even in Bangalore where the common local language is Kannada, many people working in the high tech industry have migrated from other regions of India. This means that often the only language in common between team members in India is, in fact, English.
Development groups in India tend to be quite large. Often communication problems aren’t limited to overseas. Often you get worse problems communicating things just to the whole team at the India location or just connecting the right people together who in reality sit quite close together.
Of course there is the 13½ hour time zone difference, and then the fact that it’s such a long flight to get to India. Visiting has gotten easier over the years, but it can still be challenging for westerners.
Communications is always a challenge on any large project. As a project increases in size, the number of communication channels increases exponentially. Enabling effective communications on a large project can be helped by technology, but is really a people problem and has to be continuously managed.
And so concludes my blogs while on my Bangalore trip. Perhaps not a true travel blog, but I like to blog on the issues I’m dealing with and this trip provided some good topics. Anyway I’m back in Vancouver now and life returns to normal.
This is part 2 of my travel blog on this trip to Bangalore, India. Part 1 is located here. In the first part I mostly covered the logistics of getting here. Now for this part I’ll continue with some of my impressions and learnings from being here. I was hosted on a very interesting day trip to Mysore and I’ve gotten quite a bit of exposure to living with the time zone difference and dealing with Indian traffic.
I’m from Vancouver, Canada which is in the Pacific (PST) time zone. Bangalore, India is on India Standard Time (IST). Basically IST is currently 13½ hours ahead of PST (in the summer during daylight savings time it’s only 12½ hours ahead). The reason for the ½ hour is that they didn’t want India to have two time zones so they took the average instead of dividing the country into two zones. This time zone difference is a big headache when working with Indian teams.
When in Vancouver my complaint is that during the winter I have to get to the office at 7:00am for various conference calls. Here I have the reverse problem. Now I have to get back to my hotel room for an 8:30pm conference call with Vancouver. Restaurants all open for dinner at 7pm here, so sometimes this can be tight.
I think it’s generally less disruptive to life, getting up earlier for these calls. I find it more disruptive having a big block of my evening consumed with them. Right now it doesn’t matter too much since I’m travelling and away from my family. But I’m pretty sure I would get some objections being on conference calls each evening between 8:30 and 10pm. So I really appreciate my Indian colleagues taking the evening side so I can take the morning side and I won’t complain so much in the future.
Agile Development and Indian Traffic
Traffic in India is very different from traffic in North America. Beyond the general busy-ness, a key difference is the variety of traffic on the road. It isn’t just cars and motorbikes (which can all maintain the same speed). In North America we get annoyed if a backhoe or cyclist is slowing down the flow of traffic. Here in India there are oxen towing carts, people pushing carts, horses, bicycles, tuk-tuks, overloaded slow moving trucks, vehicles that aren’t running properly, etc. Add to that cows and dogs deciding to randomly cross the street and lots of pedestrians crossing through the traffic. Generally it appears very chaotic where each vehicle moves ahead where it can, taking advantage of any open space there is. Everyone tries to flow around slow moving vehicles. Honking is very frequent to let people know you are there.
Out of all this apparent chaos, traffic does move and you do get to where you want to go. To some degree there are un-written rules and the behavior of other drivers is quite expected to the locals. But the locals still shake their heads at drivers going the wrong way down divided roads or suddenly changing direction.
Agile development in India has a tendency to operate a bit like Indian traffic. You generally have more people on a project, so things are a lot busier. All the teams are jostling ahead, moving into open spots where they can (perhaps taking an easier backlog item to move ahead on).
This tends to mean that teams are very good at removing obstacles and making progress. Generally making any progress is considered good. Where this runs into trouble is when things need to be synchronized. Getting a good stable build for integration testing is very difficult because each team keeps nudging ahead and when you fix one problem, another is introduced.
The way this is all controlled in traffic is via the strategic placement of speed humps. For instance if the road is divided, there are specific breaks in the divider where you are allowed to make a U-turn. But how do you do that into a continuous stream of oncoming traffic? Here they place a speed bump in the way of the oncoming traffic to slow it down and space it out, so that the people can merge in without having a head on collision. There aren’t many traffic lights here, but the strategic placement of obstacles seems to do the trick. The main downside of the speed humps is that they are rather severe and hard both on the people’s backs and on the car’s suspension.
Within the software development process you need to introduce the same sort of speed humps to control the flow of the project. This includes code review checkpoints, UI reviews, functional quality reviews and various other measures. Unless these measures have some teeth (like a fairly big triple speed hump), they will be ignored, but if they are enforced they do provide a good way to keep things synchronized. Indian project management is very focused on project metrics, so speed humps that affect the metrics get a lot of attention.
The most immediately noticeable difference between driving in India versus North America is all the honking. In North America honking is only used in extreme circumstances and people get irate (often leading to road rage) if they feel like they’ve been honked at unfairly. In India honking is a form of communication. There are subtle nuances as a quick tap of the horn is to let someone know you are there, a longer honk to say “watch out”. There are other forms of communication like flashing your lights (usually to mean move over so I can pass).
Similarly Indian development teams tend to be larger and there tends to be much more communications. Most of this is in the form of spirited discussions in the team areas. All this communication is good and I think we need more of this in North America. But beware like the communications between cars in traffic there are many local cues that non-Indians will not pick up on. One common reason for miscommunication is the Indian head nodding which is explained here. Remember that when you are having a conference call from North America you can’t pick up on all the body language that is going on and you could be missing and important aspect of the communications. For this reason having in person communications works better or consider using telepresence so you can pick up on these aspects.
This concludes part 2 of my coverage of my trip to Bangalore. Certainly it’s been an interesting trip so far and I’m picking up lots of insights in how things work.
I’m currently travelling to Bangalore, India to visit a large number of off-shore team members we work with on our projects. So for something different, I thought I’d try travel-blogging. I’ll be writing this blog as I go along and then periodically post my progress. This is my second trip to India, I visited Chennai back in 2008 for ten days.
Sage is partnered with several Indian companies to provide extra capacity for our projects. For this trip I’m visiting Sonata which has teams participating in several important Sage projects. I blogged previously on accelerating projects, which was really talking about our adding capacity through additional teams at Sonata. It’s great to have extra capacity and the ability to get more done, but it’s also a big challenge keeping all the teams moving in the same direction and continuously removing roadblocks and bottlenecks. Our goal is to treat the Sonata teams as if they were regular Sage agile teams with full access to all Sage resources like source control and other internal systems. To make this process work many Sonata folk visit our Richmond office and we have several staff visiting Bangalore. This is my turn.
Indian Visa Process
To back up a bit, travelling to India is a bit more difficult than other places due to the Visa process. To do this I needed letters from Sage and from Sonata giving my reasons for travel and that I’m still being paid by a Canadian company. Then you need to fill out and extremely long on-line visa application that includes detailed questions on yourself, your spouse and your parents. Gathering all the data for this form took several days, and when you save this form, it is quite buggy retrieving what you had before, so you need to check it closely. You also need a US sized passport photo and a Canadian passport with 1 year left (since I wanted a 1 year multi-entry visa). With all this you make an appointment with the company (BLS) that processes the visas. The earliest I could book was 1 week later. Then you show up for your appointment and they double check all your papers and take the rather large fee ($200). They take all this as well as your passport and promise to process it in 7 business days. Basically at this point they give it all to the Indian consulate for processing. Fortunately this all went fine and 5 days later their website said my passport was ready for pickup. Generally of all the countries I’ve visited, this is by far the hardest visa process.
If you don’t travel much, you should go to a travel clinic to get the right shots when visiting India. I travel quite a bit and all my shots are up to date. The first time I went to India, I needed to get 5 injections. I do recommend taking something like Dukoral since I’ve never had any tummy troubles when I’ve taken this ahead of a trip. Malaria pills may or may not be required depending on where you are going.
It’s a Long Way
I travelled to Bangalore via Hong Kong. It’s a 14 hour flight to Hong Kong and then a 6 hour flight on to Bangalore. Generally the best way to endure a long flight is to sleep through it. The Hong Kong flight left at 2:30pm, so I wasn’t sleepy until near end. By the time I was on the Bangalore flight I was so tired I slept through most of the flight. For some reason all international flights in and out of Bangalore arrive and leave between midnight and 4am. When you arrive you don’t really care what time it is just want to get to the hotel and sleep, so make sure you book for a day earlier, so you don’t need to then wait till 2pm to check in.
Managing in Bangalore
Some Indian cities can be quite hard to navigate. But Bangalore is fairly easy. You do need know how to cross the streets (i.e. make eye contact and walk slowly across the traffic, which will flow around you). If you are worried about having to eat lots of extremely hot Indian food, then don’t worry there are many good restaurants from other cultures like Italian or Mexican. Plus generally I don’t find the Indian food that hot here (perhaps it’s toned down for the tourists). I find the level of English was quite good and haven’t had any problems communicating.
Getting directions and finding your way around isn’t that hard and the area around my hotel (in the downtown old part of the city) seems quite safe. There are quite a few parks around and you can see quite a bit just walking around.
The office is 10km away and parts of the journey can be quite congested, but I find the traffic here to be better than in Chennai, Bangkok or Ho Chi Minh City. They are building a new elevated metro system which is causing quite a bit of road disruption along the way, but they seem to keep traffic flowing.
The office building is located in the Global Village Tech Park outside the city. There are quite a few tech companies located here including Sonata, MindTree, Accenture, HP and Texas Instruments. The office environment I’m at is quite nice. The building is modern and the work environment is quite pleasant. It uses an open office concept and provides a nice productive team environment.
Since this is India the company parking is quite different than what you would expect in North America. To maneuver quickly through traffic, two wheels is the way to go. If everyone using motorbikes was to switch to cars it would be total grid lock here.
This ends part 1 of my travel to India. I’m now here and settled in. Getting here is half the battle, now it’s time to get some productive work done.