Sunday, July 25, 2010

Being part of a geographically dispersed self-organizing team

Let's imagine that you are assigned to work in a team geographically dispersed across the globe - let's say North America, South America and Eastern Europe. To begin with - those are three different time zones. Effective business time overlap between Central Daylight Time (CDT) and Eastern European Time (EET) is only two hours if both sides work from 8 AM - 5 PM! It is much better for South America (UTC/GMT -3 hours) and Europe - there we have four hours overlap. And it is almost perfect for North and South America - there we have 6 hours overlap.

Next thing to consider - you don't really know your new teammates. Are they as good developers as you? Are they better than you? That is a question you'll have answered two or three weeks after the project kick-off and if the planned duration of the project is only nine weeks… the answer might come too late!

You are Agile at hart and you want to work in a Scrum self-organizing team. You also know that in order to have a self-organizing team first we have to have a Team!

So the main question is - how to team up with strangers living across the globe?
You should try behaving the Goodwill way! That would mean you should care about your teammates and hope they will care for you. That is an abstract idea so in order to comprehend it let's look at some fictitious and extreme situations:

  • If you commit to the repository code that is not compiling what you are showing is you don't really care about your teammates! You don't really care if your teammates will spend 2 hours fixing the build instead of spending two hours developing new features. If you don't care about developing new features for your project - do you care about the project at all?
  • If you, without discussing it with your teammates, decide to take a day off on July 5th because it is a national holiday for the Client even though you are located in South America and by accident it is the very week the team is about to be asked to work overtime because the project is behind schedule - you don't really care about your teammates!
  • If you, without discussing it with your teammates, decide to refactor the project codebase and by accident that is to happen 5 days before the scheduled production release - you don't really care about your teammates!
  • If you don't care about your teammates in effect mentally you are not part of the team! If half of the team doesn't care about the other half - do we have a team at all?
Of course all of the above is something you will never do. You know how to be a good teammate!
On the other hand you might suffer some of the above. You would be frustrated and would think - is it that difficult for some people to think before act? In moments like that recall the last time you were responsible for a production bug and remind yourself that everyone can make a mistake. Believe that you and your teammates are all working toward а common goal - to ship the product!

It would be good when you are in doubt if you have somebody to ask questions like - should you use a kind of formal process for communicating what functionality you have implemented while your European teammates were sleeping? When to use words like "Excellent", "Very good" or "Good" because different cultures might understand different things? Should you have an open discussion with all your teammates about the features each one of you would like to work on during the sprint? Should the team have a retrospective meeting after each sprint as an opportunity to adjust the team’s Scrum approach as necessary to fit the realities of the current situation and to improve?

You do have such a person at hand - your Scrum Master! That person should have an understanding of the dynamics of team development and how teams work and should be your mentor and coach you how to communicate, learn, grow and perform.


Anonymous said...

Genial fill someone in on and this fill someone in on helped me alot in my college assignement. Gratefulness you for your information.

Anonymous said...

I think it is best to address the good practices and to address people and
problems in a positive way.

Developers do not break code intentionally and when the code is broken
they always put their best efforts to repait it.

Whenever somebody asks for a vacation he/she has a good reason to do so.
At end we are all people and we have families and other obligations.
We have to find the work-life balace in order to perform well our job.
Vacations, holidays, 40 working hours per week and regular lunch breaks are part of this balance.
If you break the balance you will end with unhappy people that will eventually lose their high morale.

Agile is about people. You have to build gradually agile mindset not chasing people that their not team players.