For us remote is just the way we work. The deviantART hq is in Los Angeles, and no developers live close enough to visit casually. I think the closest developer is in San Francisco. The nearest developer to me is about 250 miles away. Excepting the search team (who are based in Vancouver), to the best of my knowledge no two developers even live in the same city.
Now, this does come at some cost to us! We have to make an effort to keep our intra-team communication working, whereas a company with all their employees sitting next to each other gets a certain baseline for free.
How do we work?
We use Skype. A lot. The entire company communicates through a number of Skype chat rooms. Each team gets a chat, some topics get a chat, and all projects wind up with one. There's a trac install in use for issue tracking and wiki. Some teams prefer using Basecamp or other tools instead of trac, and they're free to do so.
As an earlier article mentioned all our scattered developers get a virtual machine running a functioning copy of deviantART to develop on, so they're not tied to development servers in a central office.
Agile development
We have a modified agile system in use, which has evolved over time to meet our needs, and works reasonably well for us. We tried standard agile methodologies, and found they were a bit awkward with a remote team. Pair programming or a scrum, for instance, just aren't the same without colocation.
Our system revolves around weekly iterations, of which we are on our 174th since starting this system.
Each week on Monday our teams demo their progress to each other and to their internal customers on one big demo call that everyone attends. The demos are short-and-sweet; 3-6 minutes is standard. The general format is "our expectations for this week were to do X; we did that / didn't do that; here's supporting information".
After the big demo we break off into team-specific calls where the lead developers and their customers work out the next iteration's expectations. Some teams will decide to iterate at a different rate for one reason or another; it's not uncommon to discover that you need to make a quick prototype or view the analytics on a quick change to decide what to do next.
Throughout the iteration it's up to the developers on a given project to decide how they communicate. Some projects wind up doing daily check-in Skype calls, others work entirely in text chats. Since we have developers in widely disparate time zones it's again up to the developers on a project to work out amongst themselves times when they're all available to exchange information; there's no standard "office hours" required by the company. (Though people do gravitate towards Pacific time, it seems...)
Project teams
A normal project consists of a customer, a lead developer, and 0-2 other developers. If it involves changing the site's UI then a member of the UI team is assigned to work with the project, because UI is hard. Similarly if it involves changes to our infrastructure then a member of the Tech Ops team may be attached.
"Lead developer" is a term which can mean almost anything in this industry. To us it means the developer whose job is to coordinate the work of other developers on the team, and to work out with the customer what the project's expectations are. The lead is still an active coder on the project; we've yet to have a project with enough overhead that a pure manager is required.
The "customer" can be almost anyone. We pick someone in the company who we think can represent the needs of the project. So on a purely technical project it might be someone in dt, for a new feature it might be the product lead who championed the feature, for changes to our print store it'd be someone in retail, etc.
Team size is flexible, and depends on the project. Some teams do wind up with just a lead developer, if the expected workload is low. However, we prefer to put more than that on a team to make sure that several people will go over the code produced.
Reactor
We do have one long-running project team called Reactor. Its role is to fix bugs that aren't related to other active projects, and to implement features that aren't large enough to warrant spinning up a separate project. It's also where we assign all new hires initially, so its lead developer gets to mentor them and introduce them to our codebase. Reactor makes a good training ground since it's guaranteed to drag developers through disparate areas of deviantART.
Face time
Working remotely works well for us, but we like to supplement it with occasional face-to-face meetings to help make sure that everyone knows everyone else. When collaborating over Skype it's easy to just never interact with someone whose work isn't related to your area, after all.
Thus every year for the holidays deviantART flies everyone in to hq for our holiday party. We spend a week working a little and socializing a lot, to cement our sense of "team".
Particularly complicated projects may also involve getting everyone involved together in one place while the general shape of the project-to-come is hammered out. For instance, before the groups project launched in late 2008, the whole team spent a week in Canada debating what groups should be, and wrote the first prototype of the new profile page widget system while they were up there.
Better ways
A pseudo-regular activity in our off-topic developer chat is trying to find a better alternative to Skype for the text-chat portions of our communications. (Skype chat is great if you like the Skype client; if you don't then you're stuck with it anyway.) We've run through a number of options, but it's tough finding one which is:
- non-technical enough for our non-developers
- enough better than Skype to make it worth the hassle of switching everyone over
IRC is a common contender, but tends to fail on the latter point.
How have similar systems worked for you? Do you have a better pure-remote development methodology that we've not heard of?
