Outsourcing in startups: How I work with my remote developer

In the previous blog post, I explained why I outsource the development of my startup and this post I would like to explain how we work together.

Task management

I started with using podio.com to manage the work to do with my team. Podio is an impressive (and free) web application that has in-app applications for almost everything you may need for your business: invoices, timesheets, todo-list, etc…

After using it for maybe three weeks, I found a few limitations that may not apply to your needs: for example at the time I tried it, there were no way to prioritize the tasks or to tag them. The user interface felt awkward sometimes, without being able to pin point why, but I think the fact that they have such a generic framework where in-app applications can integrate constrains them in terms of user interface choices.

The need I had for a task management were:

– can prioritize
– can comment on a task
– can see latest changes (recently completed, new comments)
– can assign work to someone
– can see all the tasks in one page
– not too expensive
– can attach files

I also tried http://freedcamp.com and http://teambox.com but they still didn’t fit all my needs. I then decided to go back to basics.

I created a simple Google Speadsheet:

image

I share the file with all my remote contractors, giving them access to a specific tab only (Marketing, Development or Accounting).

Having everything in one file make it really easy to get an overview of the progress.

Another great feature from Google Docs is the built-in chat sidebar:

image

It makes it really easy to discuss a specific task or discuss the objectives for the incoming week.

Communication

I use Skype + Emails (associated with TaskArmy messaging system) + Google Docs chat + Gyazo (this one is probably new to you). Gyazo will take a screenshot of part of my screen and upload it straight away online. I just need to take the link and share it with my remote contractor.

Anton is great at keeping me up to date with what he is working on and what he plans to work next. He sends the updates by email but using my TaskArmy email address, so his messages appear also in TaskArmy:

image

Daily email

I always ask the remote contractors I work with to send me a daily email with the following structure:

1. Things I have worked on today
2. Things I will work on tomorrow
3. Questions and things that are slowing me down

By receiving this email every day, it gives me the opportunity to re-prioritize the tasks, clarify some requirements and answer his questions.

Developers are generally aware of the daily SCRUM meetings and this email is simply a replacement for it (although I should be sending it too in the true spirit of a SCRUM team but there are three days in the week where I am gone for some consulting, unrelated to TaskArmy).

Weekly Skype call

I usually organize a Skype video call every Monday morning to chit-chat and discuss about the week’s objectives. It is really important to get some live time together because informal topics might come up and it helps me detect any untold concerns.

It is a bit harder to organize the weekly call with Anton because he is still in week end when I start my week so I must admit I haven’t had the discipline to organize any call at all with him (but it works great with Jessica who has only 2 hours difference with me).

Source control

We use git and github to manage the sources of Task Army.

We have two main branches, master (that reflects what is on production) and development (that represents what is production ready but hasn’t been deployed yet.

For each task he works on, Anton creates a separate feature branch out ofdevelopment (for example feature-rss-feed). When a feature is ready to deploy, he merges the feature branch into the development branch.

I am the one responsible for reviewing what is in development and merging it into master and deploy it onto production.

This is a simplified version of what is described on this post: successful git branching model. Because we deploy often we don’t have this concept of releases.

We use Heroku for hosting by the way, which means we are one git command away from deployment.

Conclusion

There are many valid ways to collaborate online with your remote contractors. The one I presented is in no way the only one that you must absolutely follow. I described the way we work to give some ideas on how to tweak yours.

What else would you like to know?