Subscribe in iTunes
30Aug2010
Wide Teams Podcast Episode 11: Interview with John McCaffrey
In this episode I talk to John McCaffrey, a software consultant who specializes in ironing out performance problems in Ruby on Rails applications. In the course of his consulting he works with dispersed teams, and in this interview he delivers a detailed rundown of the tools and workflow involved in doing Agile software development in a distributed team.
Podcast: Play in new window | Download
Show notes:
This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.
In addition to those tools, I also use screencasting tools like jing, screenflow, and iShowU to document steps that take too long to write up with traditional documentation methods, or that are more ‘how-to’ in nature.
I also make heavy use of basic wikis, google docs, and design tools like http://www.gliffy.com and http://creately.com.
There is a great online collaborative outlining tool called thinklinkr.com, which allows me to whip through a meeting agenda, and build up a plan of attack in the ‘nested list’ format my brain tends to work in. (the same 2 man team built a great site workflow and prototyping tool http://mocklinkr.com)
I was part of an iPhone development team, working remotely and part-time on multiple apps, and we had good success with assembla.com to organize our code, tasks, research, bugs, and project resources.
And for the hard core command line tasks, I absolutely love gnu screen, not only for the tabbed terminals, and persistent session, but also for the ability to connect to a shell and collaborate on a task together.
The final tool I’ll mention is my crappy windows mobile phone. When I purchased it, the main deciding factor was it ability to tether to my laptop, providing internet connectivity from anywhere, at no additional charge (beyond the basic data plan I had). This allows me to provide a higher level of service than my ‘onsite’ counterparts, because I can be more responsive to issues that pop up at any time. On several occasions, I had already read, researched and responded to most issues before the rest of the team made it in to the office. Or when a problem popped up over a holiday weekend, and the rest of the team was all out on vacation, and even I myself was 2hrs into a 4hr car trip up to WI, I was still able to tether my phone to my laptop, hop on the vpn, call the customer (on the same phone), read the prod logs, pull the latest code, resolve the issue, push up the fix (and tests), check hudson, and deploy to production. Providing that level of service creates a strong impression, builds a long-lasting relationship with a very satisfied customer, and wouldn’t be possible without having the right toolset.
Now is a great time to be a remote developer, there are so many tools available!