Working at a distance is hard. There is a reason all the Agile methodologies recommend co-location.
You miss:
- A sense of presence
- Hallway conversations
- Rich shared environment (whiteboards, flipcharts, …)
- Personal cues – you can’t tell when someone is focused or would welcome interruption.
- It’s very difficult to build trust.
- You don’t share the same hours
In short, don’t do it. The best anyone can offer is mitigation strategies.
Tools we use
- Plane tickets – this is the most important – you can’t build trust with people you don’t know.
- Instant Messaging – requirements: support for multi-user chat with History. History is important so that you can see what was said while you were away from work. We use Jabber with the Spark as our client.
- Conference calls
- Webex (NetMeeting, et al) – it can be slow and only person can contribute at a time. Works well for demos but poorly for collaboration. Instead we look at the same web page.
- Real VNC – we’ve adopted it as our pair programming tool. It allows the remote developer to access and use the local machine at the same time as the owner. Weaknesses: needs to punched through your firewall when working from home, and your still transmitting pixels. Tight VNC also has a good reputation.
Other tools
- GoogleDocs Spreadsheet – everyone can see and edit the same spreadsheet at the same time over the web.
- Mind Meister – collaborative mind mapping over the web. The free edition allows you to maintain 4 mindmaps at a time.
- Card Meeting (free for up to four users) – collaborative Index cards for the web. In theory this should great for retrospectives and planning meetings. In fact this never gelled for my team. The cards aren’t resizable and we found far too big for what we wanted to write. As a result we had to zoom out to see the all the cards – but then we couldn’t see the writing.
- Open Meeting (free) Demo Portal: https://inno02.fh-pforzheim.de:8080/xmlcrm/
- GotoMeeting, Yugma – effectively replacements for Webex. I’ve not tried them as we already have webex accounts.
- Agile Planner (free) I’ve only see a short demo – but it looks like a very promising tool.
- XPlanner – some teams love it and others (mine included) don’t.
- Campfire (a chat room with support for history. We tried and didn’t like it because it was stuck inside a web page. As a result it didn’t get used).
- PlanningPoker.com – supports planning poker (aka wide band Delphi) estimates for distributed teams. Thanks to Mike Cohn and co at Mountain Goat
- TracWiki (insert your other favorite wiki)
Techniques
- Post Ground Rules (for Meetings et al) at each location. Check for revisions each sprint.
- Starting and ending iterations mid week:
- Not just for teams working at a distance: Friday afternoons – everyone wants to be home; Monday mornings are very low energy. As a result it’s better to avoid both.
- Teams spread across countries also face the problem that each country has different holidays – which for the most part fall on a Monday or Friday.
- Team ambassadors who move between teams
- Coach/Facilitator per meeting location – if each location has more than a few meetings then additional facilitators in each location can help the meetings run more smoothly.
- During Daily Scrum even remote team members should standup – helps keep everyone focused.
These tools and techniques are just a starting point. Please help by adding to the list in the comments. You’re also welcome to suggest improvements in grouping etc.
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
The link for AgilePlanner is invalid, maybe you meant https://agileplanner.jot.com ?
Nice short list. BTW I used to use webex, until our CEO said it was costing us too much. That’s when I came across yugma. Been using it for 6 months. It’s great. Highly recommend to others. It’s fast and easy, and has everything I need. Also, their price is impossible to beat.
I recently left an agile/Scrum team I was on for two-and-one-half years where I was the ‘remote guy.’ I completely agree that the best you can hope for is mitigation because it is hard to work as quickly and efficiently as agile processes allow when some of your resources aren’t around. That being said, the team was very successful and I believe that was due to a few simple strategies (success == consistent delivery of what we said we would do, when we said we would be done, all without compromising quality):
1. If you are remote then it is your burden to make the rest of the team not notice. Simple things like picking up the phone and talking to team members on a daily basis, and not just in the daily standup, worked great for me and the team. Being on both sides of the situation, nothing is more frustrating than not being able to get in touch with the ‘remote guy.’ The worst thing you can do is go dark when you are remote.
2. Keep the team small. Our project had three developers, a Scrum Master and a Product Owner making communication much simpler. This wasn’t necessarily by design but in hindsight, and compared to larger teams with more remote employees, this was a contributor to our success.
3. Travel on a regular basis. We worked with four-week sprints for awhile and I would travel once a month to be at planning sessions in person. When we decided to go with two-week sprints we would do as much planning as made sense and made adjustments over the phone if I was not there for the next iteration.
Great post, Mark, and hello from a fellow Ontarian (I live in Sault Ste. Marie). I’ve been working as a remote project manager for two companies for just a few months, both doing attempting to do agile, without having studied it in depth. I’m now doing that, and in our case everyone works from home in multiple countries, about as remote and distributed as you can get.
Tools we are currently using / evaluating that I like:
1. IRC for real-time chat. Most IRC clients keep a history of conversations. Skype.com and FreeConference.com used for voice chats.
2. Just started evaluating Rally (www.rallydev.com) and am quite impressed with it so far, the first agile tool that has me excited. The free version allows up to 10 users on one project.
3. Google docs, great for accessing / sharing and collaborating on.
4. Project mailing lists for easier email conversations and archiving.
I’m looking forward to trying out Mind Meister and Planning Poker. 🙂
Each time I see people saying that working at a distance is hard it strikes me. Isn’t all the open source developed at a distance? If that really were so difficult and people saying “don’t do it” were right, then all that what is now the foundation for many, many big projects would not exist – would it? Look at any decent size open source project and you will find lots of people from different countries working very well together. And many of them don’t even speak the same language but have to communicate in a language foreign to them. I believe that its basically the skill level of the developers that makes the difference.
Very good developers perform well on their own. Less skilled people need others around in order to request their help. If you have a team of rock stars then you can let them work anywhere they want to and it will turn out well. But if you have junior or medium level people, you need much more guidance, a team room, pairing and all the other helpful tools and techniques. An experienced trainer/consultant some days of the week would be great help as well. The available tools for software development can be overwhelming at times and having a guide makes a huge difference.
Re: VNC
VNC’s security is terrible unless it is tunneled through SSH, at which point the performance drops to ugly. FreeNX/NoMachineNX has better compression algorithm support and a better security profile than VNC.
@ Stephan
> Isn’t all the open source developed at a distance?
Not all; more to the point, there are lots of great open source projects out there that have wonderful functionality and really ugly code. The open source projects that really are flagship operations are apache and firefox, and they may be open source projects but they’re not exactly open communities.
> the skill level of developers makes the difference
Change “skill” to “discipline” and I’ll agree with this statement. There are lots of coders out there that are brilliant but undisciplined – having a bunch of really talented but ad-hoc programmers trying to operate while in a distance environment is going to give you a cruddy final product. I’ve met more than a few people who have had the “rock star” label hung on them, and while they may be able to tear apart and rebuild code amazingly fast and remarkably bug-free, there is a very small percentage of them that can do so while producing code that anyone can read. I’m not a programmer myself, admittedly, but in the systems administration business “what happens if Joe gets hit by a truck” is one of the first questions a good sysadmin asks. That should hold true in programming projects as well.
Amen re: multi-user chat. Great post. It begs the question, however, of how to integrate between developer productivity/collaboration suites, and chat/IM.
What’s your view on integrating the formal collaboration and workflow of software development, vs. the messy stuff like idea generation, brainstorming, finding historical bug knowledge ”stuck in somebody’s head”, etc?
Like folks here, I’m personally a big proponent of real-time, group-based chat. Not IM, but chat. One-to-one IMs are lousy for group collaboration, and the collective learning that should result. With group chat, you can pose questions to a whole group of folks at once (and everyone learns the answer the same time as you!).
How do others view that? (truth in advertising – I just blogged on this very subject)
Cheers,
Eric, https://blog.imroadmap.com
just thinking….
Four other tools / tricks to add to your list:
* Mimio (https://www.mimio.com). It’s basically a $500-$1000 gadget you attach to any existing whiteboard. It tracks the whiteboard markers in real-time, drawing on the whiteboard on your screen. Use this in combination with VNC or Webex and you can “broadcast” your whiteboarding session to anyone you want. It’s uni-directional, but better than nothing. I suggest finding one on eBay. The old serial ones (work just as well as the new USB ones, and are alot cheaper used.
* Digital camera. Snap pictures of whiteboard doodles, upload them to your wiki or email them to other folks remotely. Nobody likes taking down the notes, and this lets you cheat. Great poor-man’s alternative to mimio, or good if you forgot to turn on the mimio.
* Digital voice recorders. Use this instead of or addition to below. Record your meetings, and agree an audio marker/annotation format, so that you can share the voice notes with folks via mp3 and quickly zoom to a given recording section that you care about (“…. the argument over JDK versions half-way through the meeting…”)
* Hire/use a minutes-taker. Great for formal meetings and will save you LOADS of time, confusion and debate down the road.
Thanks to Jeremy, Gerry and Eric for some great comments.
In reply to Eric’s question on chat integrated into the IDE. I would do whatever my team wants. If they ask for it, I will find a way to provide it. However from a personal point of view I’m not sure what benefit it would provide – I’ve not even found the benefit in Eclipse’s new task tab. So I wouldn’t be inclined to take away precious IDE pixels from my code.
My group chat client resides on my second monitor with my email and browser.
Cheers
Mark