Comments on: Distributed Software Teams

By: magwa

magwa — Wed, 11 Nov 2009 23:40:45 +0000

On tools I’d say: Google docs, asterisk for phone conferencing, a bug tracking system (ghetto like bugzilla is sufficient), email and a company chat server and you’re pretty much done.

By: Curious Cat Management Improvement Blog » Management Improvement Carnival #81

Tue, 10 Nov 2009 14:38:57 +0000

[...] Distributed Software Teams by John J. Peebles – “it forced us extremely early on to invest in systems, processes, and a way of working that brought everything we did online. Project management, change control, bug tracking, issue tracking, source control, testing, collaboration, documentation, document management, communication, all of these things needed to be ubiquitous and consistently used by the entire staff.” [...]

By: Ben Friedberg

Ben Friedberg — Sun, 08 Nov 2009 03:06:04 +0000

Hey John! Caught this off of your facebook post. Very good thoughts. Much like Stan, I would love to see how you put stuff together to make a coherent whole in terms of collab. So often there are tools that tie in 85% of what you need and it’s tough to overcome some of the hurdles… For instance, we’re on a pretty consistent Google docs + Jabber + Trac situation but we get a lot of fragmentation with all of the different source repositories we end up on since we use SVN and GIT almost 50/50. We have a nice jabber server, but it would be great if we had a watchdog system cataloging all of our communication together and flagging things that came up along with way with a searchable framework. I guess you have something of a leg up since you can dictate your technologies but hearing what the end (and workable) result of your effort is would be great!

Looking at your breakdown (implementation, customer support, infrastructure, development, and QA) I could rattle off a bunch of nice collaboration suites, but getting those to all work together could be a real whopper of a task even ignoring the high overhead of buying / implementing / customizing that sort of tech to fit your individual work flow…

By: PEEBS

PEEBS — Sat, 07 Nov 2009 19:29:10 +0000

We’ve got roughly 60 people on the various technology teams, divided into implementation, customer support, infrastructure, development, and QA. The development teams are generally 1-4 people per product or product segment, and so most collaboration is in groups of no more than 3-4 other devs. I should probably do a separate post on all the different software and processes we use to manage the entire effort, as it’s a long list. Thanks for the comments!

By: Stan

Stan — Sat, 07 Nov 2009 19:15:55 +0000

What software or processes do you use to keep project management, team communication and sync-ing working with a large distributed team? Also, how large is he development team and do they all collaborate on the same project?

By: disbelief

disbelief — Sat, 07 Nov 2009 18:22:36 +0000

I agree with all of this up until your One Timezone point. I suppose it depends on the nature of your product and your development methods.

I personally work with a distributed team, however we have a global scope so we’re talking more than just the 3 hours between EST and PST. Regardless I wouldn’t want to force anyone living in a different timezone to have to get up at an ungodly hour just to be in sync with the arbitrary timezone that head office is in. Isn’t the point of working remotely having the flexibility to work where and *when* you like? Maybe its just that I personally wouldn’t be a “happier” or “more productive” software developer if I had to wake up at 5am just to be in sync with a few guys on the other side of the country.

Of course my case is probably fairly different from yours. Our developers tend to work fairly independently or loosely coupled. As long as there is a 2 or 3 hour window of overlap between everyone’s work days, where developers and managers can communicate and exchange with each other, I don’t care when the actual development work actually happens.

The benefits of having a staggered-work hour day is that you actually can get more out of every day. As one developer is signing off, another one is coming online. I currently live in Europe, so I wake up in the morning with an inbox full of the past day’s progress while I was asleep, and I can get started and have plenty of progress of my own to report by the time EST is waking up. This also gives further incentive to our employees who can feel free to live literally *wherever* they want, as long as they are productive and properly reachable.

Again, this structure probably isn’t for everyone. But its worked extremely well for us.

Disclaimer: we aren’t off-shoring developers, everyone on the team is from the same two countries (US and Canada in our case), but we just happen to be somewhat scattered across the globe.

Thanks for the great post!