How to integrate telecommuters in an agile process? [closed]

Question

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?

Mainstay

@VadimKotov sure, go ahead, if you notice the date the question was asked, it was in 2008. This was long before there was a StackExchange site for programmers or other software engineering topics. – Mainstay

This question is off-topic because it's not within the scope for this site, as defined in What topics can I ask about here? Also see: What types of questions should I avoid asking? You may be able to ask on another Stack Exchange site, for example Project Management or Software Engineering. Be sure to read the on-topic page in the help center for any site on which you intend to post a question. – Julie

Answer 1

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.

Gipson

Answer 2

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.

Bernt

Answer 3

We have success using this tools:

• Assembla for project management (source control, wiki, scrum tool)
• Skype for voice communication
• Google talk for im

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

Anglaangle

Answer 4

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.

Insupportable

Answer 5

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

Jola

Answer 6

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

Mctyre

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. – Mainstay

Answer 7

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.

Keene

Answer 8

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.

Schramm

Answer 9

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.

Parris

Answer 10

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.

Diploid

Answer 11

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.

Amaral

Answer 12

Distribute Scrum requires good preparation. It is not just about the tool.

We supported many rollouts in distributed environment and there was one fundamental point - people.

The most efficient is to start with ALL people in one location. They have to meet in person so they can know each other as persons, not just someone virtual on the other side of the world. As I used to say - team members need to smell each other.

For release planning meet at one location, if possible. Change locations so you visit all of them, to have a context and understanding of culture, habits, persons. For sprint planning use video meetings, screen sharing etc. It is not necessary to travel (it would be too often).

Clear roles and team(s) organization must be established. You have to have Product Owner and Scrum Masters. You should consider if you do not want to get PO & SM as close to the team as possible. Definitely you have to get them into face 2 face meetings (it is about face, not a location) every day.

Definition of done, if agreed by the team, helps to have the same understanding what Done means. In distributed environment is a must.

You will need a good communication tools for daily stand-ups . We found usable to use Skype or Office communicator for dailies. We use audio AND chat. Especially in international environment chat allows you to understand people. Keep communication channel open after daily so team members can discuss what is necessary outside of daily report.

And, the most important, is to do regular retrospectives with all team members in all locations. Do not forget to implement ideas coming from retrospective. Teams in other locations will need a local support who will help them to implement ideas.

Vivyanne

Answer 13

I work on a team of 5. We to facilitate our telecommute workplace we use:

• Asana - Project and Task management
• Google Talk + Your favorite IM client (I used Pidgin)
• RingCentral - VOIP Telephone
• Gmail - asynchronous communication (i.e. email)
• Dropbox - file transfer and backup
• Team Viewer - Screen Sharing, Training, and Presentations

Even with these tools it is easy to fall short on your process so it is important to establish some best practices for your team based on your dynamic. For example, we have two chief practices:

1. Communicate Often - because we are not in the same location when communicating it is easy to forget that you are working on a team. For our team, we update our tasks in Asana with comments describing ideas, obstacles, and task completeness. When immediate assistance or feedback is needed, don't wait, seek assistance via IM or email if (the person is offline).
2. Lean on the side of over communication - This pertains more to Asana comments and emails. However, in general we found it is better to give more information than is needed (within bounds).

Shenashenan