views:

554

answers:

11

I'm sure that all of us have had to deal with telecommuters at some point in time, and I'm facing a situation now where my new project will have a "core" group of office workers and some off-site telecommuters. Not wanting to repeat past mistakes, I'd really like to know what ways people have tried in the past to effectively integrate telecommuters in an agile process, namely scrum.

My first fear is that the telecommuters will be the first ones to break the "daily scrum" routine. And, as human nature often goes, once that gets broken, it's hard to resume and get people back on track. Scrum recommends enforcing small, fun "penalties" for people missing or being late to the daily scrum, like donating a few bucks to a jar which would later be used to buy a case of beers for the end-project party or something. This is obviously something that would be difficult to enforce online.

The other big problem with telecommuters is the "out of sight, out of mind" problem. Aside from using webcams/skype/teleconferencing, what other tips do people have for keeping the team as closely knit as possible?

Also, what about dealing with telecommuters from different timezones? At the moment, we're lucky enough not to have this problem, but it's definitely a possibility at some point in the future. How have other teams dealt with this problem?

+6  A: 

Instant messaging really helps with the "out of sight, out of mind" issue as their 'Status' (Available, busy, on the bog, etc) is visible to all. Also, by responding to messages they reinforce the idea that they're generally available.

I wouldn't worry about the Scrum meeting issue, joining a meeting via teleconf is often easier than attending in person.

theaxe
A: 

We have been able to manage daily scrums in our environment even with distributed teams over the phone.

It helps to use software such as Rally and Basecamp to manage the process.

Vaibhav
A: 

SCRUM and many other agile methods really do depend on physical proximity - it is hard to integrate telecommuters into any development process where integration happens frequently, but these particular processes are especially hostile to disembodied developers.

You will have to adapt the processes to the situation at hand. Video conferencing using webcams is actually very usable, and in fact yo might want to experiment with having their webcam on all the time in their cubicle/work area so people can just walk up and ask a question as they would with any other coworker.

But at the end of the day, you simply have to expect things to go differently for them - they aren't going to be able to fully participate in many processes if you are an agile shop.

Adam Davis
This is true, but sometimes reality doesn't allow this. In my field, it's hard to find experts who really know what they're doing, and often times, when we do, we can't easily relocate them. So as much as I hate telecommuters, it is sometimes a fact of life.
Nik Reiman
+1  A: 

Make sure they attend the daily standup via webcam; as you said that's the first mis-step down a slippery slope. We try to have all meetings done with a RoundTable as well which really helps.

I've been doing this for two months (working in Canada with the core team in Dublin) and so far everything has been going really well.

See Scott Hanselman's writeup on his first year working remotely at Microsoft - definitely some good tips there. One Year Later.

Jedidja
+1  A: 

Instead of a beer jar, the privilege of telecommuting itself could be part of the bargain for participation when required. If the team is not responsible enough to telecommute properly than they probably shouldn't be. More fun penalties for occasional tardiness could be to use a funny avatar to represent the person that is missing from the meeting.

Other methods of keeping people closely knit is using collaboration tools such as Wikis and project tracking tools such as Basecamp or FogBugz.

For differing timezones, early meetings will need to occur based on the furthest west time zone, unless one is on the opposite side of the world, which is a bigger problem. Then it will probably be based on who is in charge.

Turnkey
+3  A: 

We have success using this tools:

We are team of 3 developers, in 6 time zones range.

zendar
+5  A: 

Set the ground rules upfront. Don't be wishy-washy about them.

You've probably eliminated the "I got stuck in traffic" excuse for missing the meeting or whatever when they're working from home (or a satellite site) and so there's no reason to expect less out of them.

Take advantage of technology:

  • Use IM. We use it here and it is great for 'reaching out and touching' the guy four states away. Make it a requirement to be available via IM.
  • Use other tools to help break down the barriers. It'll depend on your situation.

If you're having the daily meeting, it should be clear to everyone that you're going to be asking the questions:

  • What did you accomplish since we last met?

  • What are you going to be doing today?

  • What's in the way that needs to be moved?

Just because you can't see Matt in his cube doesn't give me a right to be lazy or unproductive and unresponsive. It's like dealing with my kids - let them know the rules and what is expected, then nobody can claim ignorance.

itsmatt
A: 

One place I worked used Asterisk instead of a normal phone system. It worked well because when you are working from home, you simply log on, people can call your direct line number, outsiders don't need to know. Even though phone call cost are relativity trivial these days, having a 'always on' connection encourages more communication. The sound quality is better too.

Chris Huang-Leaver
+3  A: 

I spent a year as the only remote guy on an Agile team. I called into a conference line for the daily scrum, as well as the planning/review meetings. I kept in contact during the day via IM/e-mail/phone.

I think it worked pretty well overall. The biggest constant drawback was not being able to see the physical whiteboard we used to track the scrum. We discussed moving to some sort of online tool to do this, but it never happened.

I was one timezone away, and I just considered it part of the telecommute tradeoff that I would work the hours that the rest of team kept.

As far as penalties for missing SCRUM - to a certain degree you should enforce this loosely, via the beer jar or whatever. But if someone is consistently missing/late required meetings, then their manager needs to address that.

Jason
A: 

For telecommuters/distributed teams, I recommend getting a decent phone - most desk phones lose the ability for folks on the other end to hear folks who are multiple feet away from the phone during a standup.

When you do your demos of working code for stakeholders at the end of the iteration, use webex or livemeeting or something to share the desktop and a camera to show the speaker so that your distributed participants can see what's going on. (Even better would be to ask your telecommuters to attend during iteration boundaries to participate in person).

I recommend getting folks together for a few weeks at the beginning of the project during the inception/kickoff phase so folks can build interpersonal relationships. It's amazing how helpful the face-to-face interaction up front can be to build a foundation for teamwork.

Use a distributed card wall. I like Mingle (http://mingle.thoughtworks.com), but I haven't used other tools, so can't comment on them.

For retrospectives, it's useful to have a proxy in the room using IM to communicate with your distributed team members... so that any comments the distributed folks have can be written onto a piece of paper (or post-it, or however you do yours).

As for your fears of "out of site, out of mind", my preference for things like this is to not create solutions for problems that have not yet materialized. If you find that your team is becoming disconnected (prime discussion points for retrospectives), then you can facilitate a team discussion on how to deal with any issues that arise. Again - the team should help identify the problem and the solution rather than having a manager or scrum master dictate solutions. Start with an assumption of trust.

Adrian Wible
+3  A: 

The are a number of techniques that you can use - remember the purpose of colocation is to encourage collaboration and communication. A few things can help out.

  • If your team is all nearby - think about having core days of when everybody can come into the office. My current team allows working from home on Mondays and Fridays - and everybody comes in the office Tuesday through Thursday
  • For distributed teams, I have had good success with using Wikis instead of giant sheets of paper on the wall. The nice thing about wikis is that they encorage the team to edit the forms to meet the needs of the team as opposed to adapting to a more formal tool.
  • Another advantage of having a Wiki is each person can have their own page to share pictures about their vacations and hobbies - this makes remote people more real.
  • When you have a distributed team, I want to second the use of Instant Messaging that includes a status (Available, Away (grabbing a cub of coffee), Busy (in a meeting)) - these can include notes if people switch between working at home and at the office.
  • Webcams are inexpensive and valuable tool
  • Invest in a decent speaker phone (we like Polycom phones) for your group conference calls
  • Use tools like LiveMeeting to promote remote pair programming
  • A technique for doing stand ups over the phone is to have the person talking say the name of someone else in the group who has not gone yet - this keeps everyone paying attention.
  • For iteration (sprint) planning meetings - follow up with meeting minutes or a communication plan to make sure that everyone is on the same page. Not being colocated means a tad more documentation and intentionality on communicating.

Good luck

Ralph Miner