The long-distance shifted-time model

Many people laugh at me when I say that our team is distributed among San Francisco, Barcelona, Rome and Abu Dhabi. It sounds funny and they do not understand how we can develop applications being located in different place of the world. I think we work together very well and create great products together. Even if new people are joining and will join the team, this “long-distance shifted-time” model works very well for us.

If you carefully think of it, during the 24 hours of the day, there is always somebody working on the project with a great advantage for our customers which get their product then much faster.

This model is not new and, indeed, we found out that other companies (especially startups) are successfully using it with a great benefit in costs and work comfort. The cost benefit comes from the fact that we don’t really need to worry about expenses like office rental, furniture, appliances and so on. So the overhead is reduced. The work comfort comes from the fact that each of us has her or his working time and the work can be done from home, from a cafe or from a co-working space.

So, I am sure you want to know how we work together to the same project and how we organize the work. Well, if you carefully think of the classic model (a company with different buildings with different offices and meeting rooms), we do not do anything much different. We “only” make everything more efficiently. In fact, in a large organization with different departments, when you want to organize a meeting, you need to do it some days in advance writing emails to everybody. Then, you need to book a room wherever you find a place. Then, trying to match the availability of everybody with the meeting room. Then, the day of the meeting you and the rest of the people need to move to the selected place with a waste of time, money and, why not, with less respect of the environment.

In our case, the meeting room is “the cloud”… much greener than driving a car to a meeting room. We are physically located in different places, but virtually in the same room. Technologies like iChat or Skype allow us to connect from any place and have a meeting while having, for example, breakfast (Jose knows something about this) or taking care of the kids. For me it is shocking seeing companies like Apple or Cisco or Microsoft doing meetings still seating the people in the same room. It looks really oldish and inefficient. Additionally, nowadays devices like the iPad or the iPhone (and obviously each of us has one) make things for us much easier.

So, what’s our “traditional” workflow. Well, first of all, we use a small server (a Mac Mini Server running Mac OS X 10.6 Snow Leopard) to which everybody of the team can have access through a VPN. The server provides a Wiki, a shared disk space and a shared calendar (besides other services not relevant at the moment).

We use the Wiki to share information relative to the projects, documentation, small files, technical hints, small tools, and whatever we think can be important to share with the rest of the team. We can read the Wiki from any browser and from our iPads or iPhones when we are on the road. We can immediately if there is an updated and if the update is relevant in that moment for us.

We then use a common disk space to share large files. For example, we upload on this common space the Photoshop files of the UIs or application data or some useful videos. In the past, we used Dropbox with the same scope, but then we decided to remove it from our workflow, because each time a large file was uploaded, our Macs were overloaded of something that maybe was not useful at the moment.

The shared calendar is something very important for us. There, each of us reports her or his busy time. In this way, each of us knows when the other member would be available for a chat. And if the person is not online, we use an iPhone application (PingChat) to send a push notification to the colleague iPhone.

When we start a new project, we use Unfuddle (unfuddle.com) as a collaborative tool. We share the source code and files and for the tickets. We are currently using subversion as source version control, but we are going to switch pretty soon to GIT. A distributed version control system is more suitable for our work model. Once the application goes in production, we make a copy of unfuddle project to our Mac Mini Server, just to freeze a milestone of the project.

The way we use the tickets is peculiar. Beside the classical way of reporting a bug, we use the tickets to track a task of any kind. For example, to write an offer to a potential client or to make some adjustment on the website or to review a contract and so on. In this way, everybody can see the task and can participate in some way, helping to complete the task.

I assume this is not the perfect model of working together, but it works for us and makes things much easy and, more important, much funny.

Geppy