Wednesday, June 1, 2011

Working remotely: a success story

I just finished a great project where the entire team was geographically distributed.  I'm going to jot down some retrospective thoughts about what made this project a success, while it's fresh in my mind.
  • Being all distributed probably worked better than having a centralized core team with remote members.  There were no second class citizens and we were all more aware of keeping everyone else connected to what we were doing.
  • The technology is there - just make sure you use it.  We did a daily group video stand-up and iteration planning and retrospectives with Skype and Mikogo, a screen-sharing tool.
  • Video is important. Occasionally, a team member would not have access to video and you could feel the collaboration start to slip almost immediately.
  • Distributed source control, like git or mercurial, is a must.
  • We had a small, highly competent team with diverse and complementary skills. The old rule about each new team member adding 'n' communication paths is amplified when those paths are remote.
  • There was a strong team culture of collaboration.  We had 3 developers, a product owner and an analyst/tester, but everyone pitched in wherever they were needed.
  • We used pair-programming from time to time to share knowledge and developers worked on tasks in different areas of the code base from iteration to iteration.  There was a team culture of learning that reinforced collective code ownership.
  • Automated unit tests and executable specifications are a must. (We used NUnit and FitNesse.)
Your mileage may vary, but I see the distributed team as an effective way to get the very best people assembled for your next project.