Complexity of Multiple Development Locations

There are multiple reasons why companies spread research and development activities into multiple countries. In some smaller countries it might even be that the job market is not big enough to cover all the needs or that at least talent is really hard to find. That's why it is many times natural to spread activities to locations where the talent pools are bigger. Also the salary level can be a tempting factor especially in cost competitive countries, like India.

But there are certain challenges that are good to keep in mind before taking the step. I have no hidden agendas, my intention is to simply state some things that you might want to consider before starting activities in a new location.

Time-zone differences are good to take into account. Of course they can even be a positive thing if you are looking for 24/7 response times in services and you need to follow the sun. But if you are attempting to have distributed teams (members in more than one time-zone), they will have a limited number of common hours. There are some 'sharing the pain' approaches to this, but none the less it's a real challenge.

I think that if at all possible, people who work together should meet face to face at least in the beginning of their common journey. That helps to build trust and makes the team work easier. It's also easier to explain things and build understanding while being physically close. While this is nice, it will of course create some expenses when people need to travel. Again by far no show stopper but something to consider.

Having multiple development sites has an effect on the communication also. With one site you can rely mostly on physical boards and getting people together, but with multiple sites you need to have proper technology. Things like online backlog tools and communication software become a must. And I think many will find chat tools like Flowdock or Slack beneficial. Internet connection speed will also prove to be important. This depends also on your products, but if you need to transfer gigabytes of data there's a big performance penalty if moving files takes hours rather than minutes or seconds. Thus the local infrastructure also plays a large role.

Job rotation pace also varies between countries. Somewhere it might be possible to stay with one employer for the whole career (maybe not realistic nowadays anymore) whilst in some countries people tend to switch jobs every couple of years. If employee turnaround is really rapid, tens of percents annually, building silent knowledge might be difficult. I mean such information that slowly accumulates while you learn more and more about your field. I think rapid job rotation is also where bad for good team spirit. It's not easy to build trust between people who often change.

Cultural differences should be also taken into account. Countries differ in many things. For example Finland, USA and India are really different. To better understand one another it is good to study a bit what kind of things are valued in the other culture. One nice site to check the differences between nations is here. There you can check how the six pre-selected factors differ. It might explain why your colleagues behave as they do.

Inflation rates are also really different between nations. For example in Finland the tech salaries are high, but there's hardly any inflation. In India it's vice versa. Salaries are in general smaller, but they are raised in bigger chunks and more often. And one of my guidelines is that in the global economy talent is cheap nowhere.

Final thing that comes to my mind is the local laws and amount of bureaucracy. I guess many times the amount of bureaucracy can be bundled with the amount of hierarchy, but that's just my assumption. (What I mean is that if you always need to get bosses bosses boss's signature, you are probably in a hierarchical and bureaucratic setup.) Having a local representative who knows the culture while starting activities up is probably priceless.

Well that was my not so short list of things to consider. Topics are not in any specific or prioritized order. But hopefully they will be useful for people who are pondering about spreading activities to new locations. Make sure you understand the challenges. Some are just risks that may or may not realize, but some of these you will encounter for sure. But if your plan is clear and you are doing it for the right reasons, you have a good change to succeed.

By the way, if you are academically interested in the topic, you might want to check out DD-SCALE project.

Personal Communication and Decision Making

Individuals and interactions. Customer collaboration. I find it really hard to do that without meeting the other person. And if at all possible I prefer meeting them one on one. Or if that is not possible, I usually call using phone or voip. Why? Because it is so much more efficient than writing emails! ..or instant messages or anything else in writing.

I use such tools as JIRA, Lync and Flowdock quite a lot during my days. They are all great for asynchronous communication. And so is this blog post. But getting feedback for anything is a bit too slow to be really agile. Maybe one of the most frustrating features in instant messaging clients is to see that the other person is writing. Then you look at that and wait. If the other person has lot to say, you wait for a long time. But if you go and just have a quick chat it will all be done in no time. Simple and you get to do some nice human interaction also. I count it as a plus!

Well, you cannot always win. Sometimes the face to face conversations may not be pleasant. Sometimes you and the other person just disagree and there might be no getting past it. Or you need to give the other person some feedback that is not so easy to swallow. During those times I suggest just to focus on the facts. Don't get angry or frustrated, just deliver your message. Then you might want to let the other person to cool down before attempting anything mentally challenging. Because frustration simply blocks down our ability to think clearly.

Another interesting topic is the decision making. If I haven't totally misunderstood things, it's actually rather central topic in Agile. Empowering teams gives the teams (and individuals working there) power to make decisions. And thinking about it with some common sense, it does seem wise to do the decisions where the best knowledge is: in the teams. In Scrum the role of the Scrum Master is to remove impediments. A pending decision is an impediment. It's better to make a decision and move on than to waste time in pondering. So, Scrum Master can help facilitate decision making in order to keep team moving.

And I think the same principle applies when going "up in the food chain". Management should provide people with decisions. That's their job. Creating a better working environment through making decisions. Or empowering other people to make those decisions. But that's already a valid decision (and often a very good one.)

Finally I'd like to share this interesting link. Cult of Done. So simple yet so powerful! Starting things is easy. Anyone can do that. But what really counts is getting things Done! Finish starting and start finishing. Have working software as your only metric of progress. Done is the engine of more!

Increasing Internal Communication

After the vacation I've been absolutely on fire at work! Seems that everything I do or try just goes pretty much as well or better than I had expected.

I can't remember exactly where I heard the term, but I got interested in Coding Dojo. We have suffered from teams being in silos and I've been thinking about possible activities to gather developers from across the teams. So I decided to arrange a Dojo!

Coding Dojo is a sort of workshop where everyone participates. There's a driver and a copilot (like in pair programming) and audience. Every five minutes (or any other agreed interval) people change places. Copilot becomes driver, driver goes to audience and someone from the audience becomes the new copilot. There ought to be one sensei also, but we didn't have one.

The subject for the first ever Coding Dojo was Async. No-one knew the subject that well and the group was able to successfully implement a small demo program. One improvement suggestion was that a bit better preparation would have saved a couple of minutes from the start. Point taken, inspect and adapt. ;)

I'm not a big fan of email, since people tend to ignore those messages. Or at least it is very hard to know if your message has been received and understood. I wanted to create a blog. First blog post could be a short report about how the Coding Dojo went by one the participants. It would be nice to get a developers perspective on this.

Third form of internal communication that I've tried this week was video. In a multi site company where people are spread around the globe, it's not possible to get everyone into a meeting room and just give a short training. And as I already mentioned, I don't have too much faith in people reading their emails.

I tried something new. I made a short PowerPoint presentation and uploaded it into our intranet. Then I started recording and talked through my presentation. It took less than ten minutes. After finishing the video and uploading it to the intranet I sent an email with links to both the slides and the video. I can warmly recommend this approach; the feedback was very positive. Of course, if it is an option, stick with the face to face conversation.

This video by Henrik Kniberg about Agile Product Ownership is simply the greatest educational video about any Agile subject that I have ever seen! It's been of great inspiration to me in the way of describing very complex concept in such a clarifying way. Thanks Henrik!