- 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.)
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.
Subscribe to:
Posts (Atom)