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.

My day-to-day work as a Business Analyst

Posted by Peter Lefterov on September 1, 2008

Today our guest-author is Peter Lefterov - a business analyst at Bulgarian Telecommunication Company.

I notice when I talk about Business Analysis people often have a very fuzzy idea of what I’m talking about. And the deeper I go into defining the profession from a general perspective, the fuzzier it gets.

That’s why I decided to write down the things I personally do on a day-to-day basis, and I hope this will help build a better picture for the uninitiated. Other BAs might do different things, but usually there a level of similarity, otherwise there would not be a name for the profession.

1. Documentation – Most known and usually most tedious BA activity. The problem I’m trying to avoid with this is to have 5 team members and 3 major stakeholders and amongst them 15 different ideas what we are actually doing. The Business Requirements Specification is a tool for avoiding this, but not the only one and often falls short of achieving the objective.

2. Process Analysis – I don’t do enterprise analysis, at least not on my current position. What I do is more focused – when we change the systems people will change their work process. What I’m trying to describe is how things are done now (the AS-IS point of view) and how the work will be done after the change (the TO-BE process). The purpose here is to demonstrate to the team what the changes we are making will actually achieve. It also visualizes in front of stakeholders in detail what business result they have requested.

Read more