I work in the Bay Area at a company based out of the Washington, DC area. I lead a development team with the manpower roughly divided between both offices. On top of that, we have certain stakeholders that work in other cities out of a home office. This isn't unusual these days in tech. However, it puts a lot of strain on traditional methods of project management and release management. I've used it as an opportunity to implement some nifty methods that some might call agile to keep pushing our product forward in a rapid but guided manner.

The challenge of coordinating productivity between locations up to three hours apart can be rough at times -- particularly when it comes to the days approaching the creation of a release candidate from the development branch, or when a "should have been done yesterday" hotfix floats to the top of the ticket pile. However, there are some great perks. You get to show up to work in the morning with more work collectively done than when you left.  For clients on the East Coast, we can work further into the night to get them what they need when they get in the door first thing the next morning. My favorite part of having a distributed dev team, though, is the technologies we have implemented in order to keep communication active and instant. Here are a few guidelines that I have found really enable a development team to get a lot done and stay in the know.

Get on IRC

At least for my use case, there's no need to pay money for something like BaseCamp or HipChat when you've got a little spare server space. It should take you maybe a few hours to set up an IRC channel for your developers. Require that they stay on this channel any time they're working. I have a bot I call Hal (cliched, I know) in the channel that keeps the channel open and logs all conversations. Bots are generally easy to extend, and come in most languages you should be comfortable in working. For instance, I added a module to Hal so that he will poll our Git repository to report when code has been pushed to a branch, and announces it. We use Jira for version control, and any time a ticket is mentioned by its key, he will give a link to the ticket's page as well as its title. If we're worried about our various servers, I can have it poll them for load average and CPU usage. IRC is great productivity tool, because it's a simple protocol with plenty of extendable, open-source bots. You can tailor your communication experience to make sure everyone can stay abreast of what's going on throughout the day with a minimum of distraction.

Ditch the Standup and Do Your Daily Scrum in IRC

Even if you're all in the same office, what are you doing making people get out of their seats, stand up, and provide their uninterrupted attention to something that they're only half listening to and will likely forget anyway? Get what people are up to in the logs. Let them keep working on what they're working on. Meetings kill developer concentration. I hold a 9:15am Pacific scrum meeting every day. That's 12:15pm on the East Coast. If my developers are busy working on something important over there, I'm not going to make them get out of their seats, walk into a conference room, and dial into a GoToMeeting call just to chat about their day. By digitizing the daily scrum, you keep all the value of a constant contact point at a steady interval without breaking anyone's stride. You also get the benefit of logging as well as the additional value of customizing the scrum experience with an IRC bot. And of course, the best benefit of all: it doesn't really feel like a meeting, and we developers loathe meetings, don't we?

Continuous Integration on the QA Instance

Since we're all distributed, I think it's a much better idea to cut out the risk of multiple people attempting to deploy development code on the QA server at the same time. This is, of course, where all the code for the next release is going, and we want to make sure that it can build by itself at all times. I use Hudson to poll the development branch of our Git repository, which will then update the code and automatically build everything -- rolling back and running new database migrations, clearing the cache, etc. I prefer to keep an eye on Hudson's builds via RSS, since Hal is already announcing pushes to the development branch. However, it's your IRC channel; do what you want with it! You can easily consume Hudson's RSS feed to create a bot module that announces whether a build was successful or not. Most continuous integration solutions accommodate some way of automatically gleaning build data, so don't feel like you have to use Hudson to get this level of value.

Code Reviews and Release Notes

Because everyone should be aware of the direction of the product and have a stake in its level of quality, we encourage code reviews for all code submitted. Another developer has to pass your code before it can go into a release candidate -- present company included. I also keep other developers updated on the details of the release notes so that they can skim functional changes and recent fixes in the product. Internal release notes are available as a plaintext file in the code base, but I also send an email out both for the release candidate and the final internal release. This has helped catch snafus or missed must-have items on more than one occasion.

Daily Summaries

In a perfect world, you could go into Jira and get an hourly breakdown of what everyone did that day. The reality is that most developers are not consistent time recorders, even when it's important, and even when you hammer it into them -- again, present company included. The reality is also that sometimes developers work on things that do not have or require a ticket. Encourage your developers to record what they worked on in a short summary via some kind of internal publishing tool. In our case, each developer has an internal blog they will record a daily summary into, detailing what tickets were worked on. This is useful for splitting out whether a developer worked on maintenance release items, or maybe a major functional item that will be worked on in parallel with multiple sprints. They may have even had all their time diverted to a hotfix. It's hard to know -- especially when you're filtering things by fix version -- without the "executive summary".

Leverage The Time Difference; Don't Bemoan It

With developers a few time zones ahead of you, sometimes it's hard to make sure everything is going to get done. It's not cool to require people to ask permission to head home at a reasonable time, and they shouldn't have to. If something you wanted to get done by the end of the day Eastern Time doesn't get done, don't expect someone to stay late just because it's only 2:00 or 3:00 Pacific. Set goals that are reasonable for the time zone of the person working on it. Make sure you're utilizing your resources with the time difference in mind. If a developer is working on something that they know should be completed that day, make sure that they're in contact about its status at the end of the day. If it's not completed, and it's part of a release that has to get shipped out ASAP, have a set protocol, or at least a contingency in place to coordinate a hand-off. A good guideline here is to make sure that all in-progress branches get pushed at the end of the day, and that tickets get commented with details on the work done thus far so that anyone else can pick it up.

Conclusion

For my team, these guidelines have done a lot in terms of improving the quality of our code and the quality of our product. It has also improved the opinion our users have not only of the product, but the people behind it. You can use most of this information without having more than one office. If you have staggered shifts or people on different schedules, you can even use the last guideline. The most important part here is that we're actually improving how we manage developers' priorities and output while reducing the amount of time they're not working. We're not breaking anybody's stride, and we're actually encouraging active communication without ever having to leave your desk. The payoff is clear: developers are happy because their meeting load is minimized; you can actually have a higher frequency of meetings since you don't have to coordinate a bi-coastal call; everyone knows the immediate status of a release, so anyone can work on it at any time -- shortening development time and increasing client responsiveness.

If you're stuck slogging through call after call trying to coordinate developers in more than one place, or if you're just sick of having to get out of your chair for your daily standup meeting, give these methodologies a shot, and see if it works for you.