Follow The Sun – Tips For Offshore Development

Posted by Mike Ramm on September 17, 2008

Bas de Baar pointed me to this great advise for offshore distribution of the work process – Follow the sun:

Build in Asia
Design/Review in Europe
Test in South-America
Every day.
Every 24hrs.

Well, I am starting to believe that this is a great way to speed up the process but a small devil in me asks this stupid question:

What if at some point you need to talk with the people from the previous time zone?

Suppose you found something that you don’t understand in their specification or in their code, or it seems to be wrong. You want to discuss the issue with your offshore colleagues but their working day is over and they went home. Now you have to wait until tomorrow.

I think that the time difference is a huge problem in communication and although following the sun seems to be a good idea it is not a panacea and you have to develop a strong process to ensure communication abilities without disturbing the personal life of your staff.

There is one more great article Bas wrote on offshore software development that I highly recommend: 25 Rock Solid Tips to Supervise Offshore Development. Read it and follow those tips – they are really helpful.

If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email.

Share and Enjoy:
  • Reddit
  • Digg
  • del.icio.us
  • StumbleUpon
  • Technorati
  • Slashdot
  • YahooMyWeb
Tags: , , ,
Filed Under Project Management, Software Development 

Comments

7 Responses to “Follow The Sun – Tips For Offshore Development”

  1. Pawel Brodzinski on September 17th, 2008 8:44 PM

    For me “follow the sun” principle always brings more issues than benefits. Productivity losses brought by geographically distributed teams are huge exactly for the reason you’ve brought: communication issues.

    You can work 24h a day and be able to produce less than in standard workday. That’s the same situation as sometimes happen with experienced specialist who can’t be replaced with 3 newbies.

  2. Craig Brown on September 18th, 2008 4:00 AM

    The reason for distributed teams is usually cost, not speed.

    Pawell and you both highlight the problem of degraded communcaotins within the team. you’ll get faster and better results if you put the whole team in one room.

    Everything that moves away from this principle must be weighed against an expected diminshing speed and quality.

    I recommend readon some of Graham Durant-Law’s blog on networks of people and how layers and network nodes increase complexity – which we all know is a killer to software prjects.

    We should instead be looking at what we can do to maximise communcation and minismise interruptions nad mis-interprestations.

    Step 1: Team in the same room.
    Step 2: Team working at the customer’s site

  3. Mike Ramm on September 18th, 2008 11:21 AM

    I believe that sometimes a dispersed team can be effecive but they should not be spread too far from each other. Outsourcing to another country always brings cultural and communication problems and the time difference is a serious obstacle to the comunication process.

  4. Cornelius Fichtner on October 3rd, 2008 2:07 PM

    I have worked in a number of companies that decided to offshore their software development. The primary reason in all cases was (as Craig has already pointed out) cost.

    However, what I have learned is that saving on cost comes at a cost:

    - Your on-shore project managers will work longer hours because of the need for increased project coordination and project communication. This will increase your cost.
    - Your business analysts have to be more detailed in their analysis because the developers cannot just walk over to them and ask “What exactly did you mean on page 20?”. This will increase your cost.
    - In every case of sw development offshoring that I have witnessed the quality of the returned code was below expectations. This lead to the increased need of on-site code reviews, more communications and and additional rework. This will again increase your cost.

    So based on my experience, I would have to say that following the sun to save cost doesn’t work.

    Until Next Time,
    Cornelius Fichtner, PMP
    The Project Management Podcast

  5. Mike Ramm on October 3rd, 2008 3:43 PM

    Cornelius, thank you for your comment. Your arguments are true and I believe that saving money is not a good reason to offshore the development.

    If you want to be closer to your new market, to understand the customer better and to serve them better, then you may want to offshore some part of the work. But hoping that you can save on the development cost is not safe because you are going to increase the cost in communication and in quality as you correctly pointed out.

  6. Bas on October 4th, 2008 9:11 AM

    Hi Guys,

    Thanks for the great discussion…

    The main point I want to make is in the title: you can make use of globalization and virtualization to create resilience in the process, to make it more adaptable to changes in the environment.

    Cost is not a element in my argument. (of course it is for a lot of companies). But I agree with all of you: “if you pay peanuts, you get monkeys”. But this is valid in any country.

    Yes, the process creates challenges, but also opportunities. It can be done. And in some cases, it has to be. I live in a small country and we will be running out of IT people in a couple of years. We need the additional workforce for example, but we cannot support everyone living here.

    A long way to go, for sure :)

    Cheers
    Bas

  7. im.grammer at yahoo.com on October 26th, 2009 2:43 AM

    Keeping programmers in your room is expensive.

    http://video.yahoo.com/watch/6157291/15991610

    i invite you to watch that video.

Leave a Reply