|
Facilitating communication brings teams closer together
September 26, 2007
URL:http://www.drdobbs.com/tools/tools-for-distributed-development/202101855
Jason is a project leader and Certified ScrumMaster at Macadamian Technologies. You can reach him at [email protected].
When it comes to working on distributed teams or one with global development partners spread around the world, you need to use every tool you can to make interaction easier. Here's my list of tools that can bring two points on the globe just a little closer.
Because a well-maintained wiki can take so much work off a project manager's plate, I have a secret fear that someday I'll be replaced by a wiki. At Macadamian Technologiges (where I work), we use Atlassian's Confluence wiki and have a wiki homepage for each project that we do. This grabs all the project documentation and puts it in the same place -- how to set up, how to contribute, issue tracking -- everything a team member needs to ramp up fast is right there. When I need to get new team members set up, I just send the link to the wiki page and tell them to come see me if they have any questions.
To be really useful, a wiki has to be crammed with documentation of the processes that work at your company, and by making it part of your corporate culture. We do this by creating standardized project dashboards, so that all team members know where to find information. We also document everything that is humanly possible and work hard to ensure it is always up-to-date.
For around 50 percent of the questions that people ask me, my answer is the same: "Did you look in the wiki?" After hearing that a couple of times, people start looking in the wiki before asking questions, which saves everyone time.
When the answer isn't in the wiki and I don't know it, I use the "teach a man to fish" technique. I tell the askers to find the answer themselves, and then send me a link to the wiki page they use to document the answer after they've found it.
A wiki is a key tool for success with distributed resources. Not only will it answer your global partners' questions while you're asleep, it also shows your partners how you go about doing things. A wiki spreads your corporate values in open and subtle ways, showing your partners how you work. This helps your partners incorporate the values of your company into their decision-making process.
For example, if your company values getting customer feedback at an early stage, your global partner keeps that in mind when it's the middle of the night Eastern Standard Time and they have to choose between developing the error-message logging system or the settings UI component. A wiki also shows the difference between how you say you work and how you really work. For example, if you say you value open communication, but half of the pages are locked and users need approval for editing them, you're sending a different message.
By nature, wikis reveal the truth about the day-to-day aspects of working at your company. Our wiki homepage currently shows all the contact and time zone information for each of our six offices (we value communication with our global partners), the presentations at our upcoming pizza lunches (we value continuous learning), a random lesson learned (making mistakes isn't fatal -- but show others how to avoid them), and a poll about whether the DJ (a Macadamian employee) at our 100th employee celebration rocked it out (we value social interaction as team-building). There's also a report on a recent tradeshow (we find out what our customers want), and yet another posting about how to make good coffee (without caffeine, we would grind to a halt). Seeing this helps our global partners know us. Because we don't just talk about our values, we put them into action; our values speak for us when we aren't there.
Because we show communication at work, our global partners communicate with us. Because we don't consider the slightest mistake to be fatal, they are open with us when things don't go exactly as planned. And speaking of tracking things....
With your team distributed around the globe instead of just down the hall, you need task-management or bug-tracking systems. (We use Atlassian's Jira). A good task management system shows all progress at all times. So, if a customer calls, you can check on progress even if your partners are asleep because it's the middle of the night in their time zone. This also makes each individual's responsibilities clear, so there's no confusion (and unnecessary work) because the left hand doesn't know what tasks are assigned to the right hand.
A version-control system is more than a version-control system_it's a way of life. We're religious about code review, and we don't put code into the source control until it's been reviewed. We encourage/insist that everyone -- not just global partners -- develop in small patches that are generated by our version-control system.
The patch-a-day rule helps in tracking the ramp-up process. You can nip mistakes in the bud, and you can encourage a common coding style (see my article Coding Conventions: Make Them Agile). It's far better to provide feedback at an early stage, and on small patches, than for global partners (or any team member) to guess how to best work with you. The goal is for global partners to be equal, integrated members of the team. So, giving them feedback as soon as possible lets them learn how the team works early in the process, letting them integrate faster.
And as the project goes along, everyone can see the daily progress. The North American section of a team can see what work the global team has done overnight; the global section can see what the North American part has done overnight. This also prevents team members from stepping on each other's toes, redoing work that's already been done.
The number one problem with having a distributed development team that's peppered around the globe is the lack of impromptu communication.
On a nonglobal project, you can chat with your lead developer over Starbucks in the lounge, and decide to add code to throttle the call manager to help prevent the server from going critical. After a quick foosball break, you can tell your designer to make the aqua UI a few shades closer to cerulean... Think about it. How many decisions on your team are made in informal settings? Even if it's 10 percent, that's a significant portion lost when you're working with a global team.
But great tools can help bridge the gap of space and time. We encourage Instant Messaging among team members. When global partners feel free to ask questions or get confirmation before proceeding, they spend less time blocked and can move ahead with the confidence that they're doing the right thing. By creating more formal means of communication, conference bridges can help deal with the problem of less informal communication.
In software development, we're used to scheduling the minimum possible number of meetings. But when you're working with a global team, you'll probably need more team meetings because the only time the whole team will be together is when you schedule it. For the team to get comfortable working together, they need to feel like they're in the same room once in a while (even when that isn't possible). You want the team to feel like a team, for people who have questions to contact the experts with answers. It's a forum for informal communication -- just one that you have to plan for in advance.
Skype can be a better phone than a phone. The voice quality can be better and the integrated chat lets you explain things in written format if there's a language issue.
Technology can't bridge space and time -- not yet, anyway. But when it comes to working with distributed development teams, anything that facilitates communication brings your team closer together.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.