Bangalore Travel Blog Part 2

Introduction

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.

Time Zone

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.

Speed Humps

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.

Honking

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.

Conclusion

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.