Like it or not, it is a globalized world today and has been so for the software industry for at least two or three decades. Software creative professionals along with professionals of many other industries find themselves working with distributed cross functional teams. Rather than going into our shells, this situation can be a great opportunity to work with people from differing cultural, geographical, and professional backgrounds.
And while diversity is a gift and must be celebrated, it does bring along new challenges that cannot be swept under the carpet and need to be addressed. One does need to enforce certain practices that transcend cultural differences and make distributed software development practical and productive.
You are supposed to work with people half way across the world. They don't speak your language, they don't share your work culture, and neither do they share your time zone. To put it mildly, this can be quite a challenge.
Yet if done correctly, it has proven itself to be of great benefit to the business. The key here is, if done "correctly".
So how does one do it correctly? I suggest keep it simple.
First, speak a common language. Without this, one can't proceed.
Second, have honest communication with positive intent. Human beings, especially those who speak differing languages, have this great ability to judge the moods of each other. It is not a secret that over 90 percent of human communication in non-verbal.
If you are negative, that will be the first thing your distributed peers will pick up. This needs to be stressed, as it is extremely important. Off shoring / outsourcing can be a controversial subject, but if you are going to work with a distributed team, your intent should be to do your best, regardless of your political stance on this subject.
While the practices described in other recipes of this chapter are suitable for any team, they especially resonate and make most sense if implemented for distributed teams.
- Start with setting up:
- Remote source code repository / revision control system
- Continuous integration server
- Issue tracking systems
- Mailing list systems
- Configure them correctly and make sure everything has been tried and tested by you or someone suitable in your local team. Note that all these systems need to work off the Internet or on private company networks access, whichever is available to your distributed teammates.
- Once this is ready, create the requisite accounts and access controls for your distributed partners. Share this information with them either on the wiki, on the mailing list, or even through the Apache Maven Project POM file / Maven Project Site.
- A good way to get started with less experienced team members, whether distributed or local, is through pair programming. In a team of developers with mixed experience levels, it is strongly recommended that developers start pairing up with more experienced team members. The quickest learning happens by example and experienced team members get an opportunity to motivate and mentor a beginner by showing them how it's done.
- A developer pair can set up the project on the developer box, make their first code change, their first build, and first commit. This will be a tremendous learning experience for the young developer. Rotate pairs often and soon you should have achieved cohesiveness in your distributed team. Screen and voice sharing tools such as Skype can be effectively employed for pair programming. Pair programming has clear benefits and is more effective than day long trainings and sessions.
Eventually, everyone in your distributed team should be comfortable executing the following:
- Updating the local code base from the revision control system
- Picking up a task from the issue / task management system
- Writing the tests for the tasks that they are implementing
- Writing the code to implement the tasks
- Running a local build, and checking that code compiles, and all existing and new tests execute successfully
- Updating and merging changes in case multiple commits have been made while the programmer was coding
- Committing the code
Once your team is here, you know you have done a good job developing not only software, but also shaping individuals and building teams. This, for the senior developers, can be an extremely rewarding experience.