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.
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.
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.
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.
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.
请参阅 Scott Hanselman 关于他在 Microsoft 远程工作第一年的文章 - 绝对有一些很好的建议。 一年后。
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.
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.
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.
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.
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.
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:
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).
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).
发布评论
评论（13）
即时消息确实有助于解决“眼不见心不烦”的问题，因为他们的“状态”（可用、忙碌、在线等）对所有人都是可见的。 此外，通过回复消息，他们强化了他们普遍可用的想法。
我不担心 Scrum 会议问题，通过电话会议参加会议通常比亲自参加更容易。
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.
预先设定基本规则。 不要对他们犹豫不决。
当他们在家（或卫星站点）工作时，您可能已经消除了“我遇到交通堵塞”错过会议或其他原因的借口，因此没有理由对他们抱有较低的期望。
利用技术：
如果您要召开每日会议，那么每个人都应该清楚您将提出以下问题：
自从我们召开以来您完成了什么
上次见面？
你打算做什么
今天？
需要采取什么措施
搬家了吗？
仅仅因为你在他的小隔间里看不到马特，并不意味着我就有权偷懒、效率低下、反应迟钝。 这就像对待我的孩子一样 - 让他们知道规则和期望，然后没有人可以声称无知。
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:
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.
我们成功地使用了以下工具：
我们是由 3 名开发人员组成的团队，分布在 6 个时区范围内。
We have success using this tools:
We are team of 3 developers, in 6 time zones range.
我花了一年时间作为敏捷团队中唯一的远程人员。 我拨通了每日例会以及计划/审查会议的会议热线。 我白天通过即时消息/电子邮件/电话保持联系。
我认为总体来说效果很好。 最大的持续缺点是无法看到我们用来跟踪 scrum 的物理白板。 我们讨论过使用某种在线工具来做到这一点，但它从未发生过。
我距离一个时区很远，我只是认为这是远程办公权衡的一部分，我将按照团队其他成员的工作时间进行工作。
至于对缺少 SCRUM 的惩罚——在某种程度上，你应该通过啤酒罐或其他方式宽松地执行这一点。 但如果有人总是缺席/迟到所需的会议，那么他们的经理就需要解决这个问题。
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.
您可以使用多种技术 - 请记住托管的目的是鼓励协作和沟通。 有几件事可以提供帮助。
祝你好运
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.
Good luck
SCRUM 和许多其他敏捷方法确实依赖于物理接近性 - 很难将远程办公人员集成到任何集成频繁发生的开发流程中，但这些特定流程对无形的开发人员尤其不利。
您必须根据当前情况调整流程。 使用网络摄像头进行视频会议实际上非常有用，事实上，您可能想尝试在自己的隔间/工作区域中始终打开网络摄像头，这样人们就可以像与任何其他同事一样走上前问问题。
但归根结底，您只需要期望他们的事情会有所不同 - 如果您是一家敏捷商店，他们将无法完全参与许多流程。
-亚当
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
确保他们通过网络摄像头参加每日站立会议； 正如你所说，这是走下滑坡的第一个错误。 我们尝试通过圆桌会议来完成所有会议，这确实很有帮助。
我已经这样做了两个月（在加拿大与都柏林的核心团队一起工作），到目前为止一切都进展顺利。
请参阅 Scott Hanselman 关于他在 Microsoft 远程工作第一年的文章 - 绝对有一些很好的建议。 一年后。
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.
在需要时，远程办公本身的特权可以代替啤酒罐，成为参与交易的一部分。 如果团队没有足够的责任感来正确地进行远程办公，那么他们可能就不应该这样做。 对偶尔迟到的更有趣的惩罚可能是使用一个有趣的头像来代表缺席会议的人。
保持人们紧密联系的其他方法是使用 Wiki 等协作工具和 Basecamp 或 FogBugz 等项目跟踪工具。
对于不同的时区，早期会议需要根据最西边的时区进行，除非位于世界的另一侧，这是一个更大的问题。 那么这可能取决于谁负责。
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.
即使是通过电话分散的团队，我们也能够在我们的环境中管理日常 scrums。
它有助于使用 Rally 和 Basecamp 等软件来管理流程。
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.
我工作的一个地方使用 Asterisk 而不是普通的电话系统。 它运作良好，因为当您在家工作时，您只需登录，人们就可以拨打您的直线号码，外人不需要知道。 尽管如今电话费用相对来说微不足道，但“始终在线”的连接可以鼓励更多的沟通。 音质也更好。
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.
对于远程办公人员/分布式团队，我建议购买一部像样的电话 - 大多数桌面电话都无法让另一端的人员在站立时听到距离电话几英尺远的人员的声音。
当您在迭代结束时为利益相关者进行工作代码演示时，请使用 webex 或 livemeeting 或其他工具来共享桌面和摄像头以向演讲者展示，以便分布式参与者可以看到正在发生的情况。 （更好的是要求您的远程办公人员在迭代边界期间亲自参加）。
我建议在项目开始/启动阶段让人们聚集在一起几周，这样人们就可以建立人际关系。 令人惊奇的是，预先面对面的互动对于为团队合作奠定基础有多么大的帮助。
使用分布式卡墙。 我喜欢 Mingle (http://mingle.thoughtworks.com)，但我没有使用过其他工具，所以无法对他们发表评论。
对于回顾，在房间里有一个代理使用 IM 与分散的团队成员进行交流是很有用的……这样分散的团队成员的任何评论都可以写在一张纸上（或张贴，或者无论你做什么）你的）。
至于你对“失控、失控”的恐惧，我对此类事情的偏好是不要为尚未实现的问题创建解决方案。 如果您发现您的团队变得脱节（回顾的主要讨论点），那么您可以促进团队讨论如何处理出现的任何问题。 再次强调——团队应该帮助识别问题和解决方案，而不是让经理或 scrum master 指定解决方案。 从信任的假设开始。
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.
分发 Scrum 需要充分的准备。 这不仅仅是工具的问题。
我们支持分布式环境中的许多部署，但有一个基本点——人。
最有效的方法是从一个地点的所有人开始。他们必须亲自会面，这样他们才能作为人来了解对方，而不仅仅是世界另一端的虚拟人。 正如我常说的——团队成员需要互相闻闻。
对于发布计划，如果可能的话，在一个地点会面。 改变地点，这样你就可以参观所有的地方，了解背景并了解文化、习惯和人物。 对于冲刺计划，请使用视频会议、屏幕共享等。没有必要出差（出差太频繁）。
必须建立明确的角色和团队组织。 你必须有产品负责人和 Scrum Master。 如果您不想获得 PO & 订单，您应该考虑一下。 SM尽可能贴近团队。 当然，你必须每天让他们参加两次面对面的会议（这是关于面子，而不是地点）。
完成的定义，如果团队同意，有助于对“完成”的含义有相同的理解。 在分布式环境中是必须的。
您将需要一个良好的沟通工具来日常站立会议。 我们发现可以使用 Skype 或 Office Communicator 进行日常工作。 我们使用音频和聊天。 尤其是在国际环境中聊天可以让你了解别人。 每天之后保持沟通渠道畅通，以便团队成员可以讨论每日报告之外的必要内容。
而且，最重要的是与所有地点的所有团队成员定期进行回顾。 不要忘记实施回顾中的想法。 其他地点的团队将需要当地的支持来帮助他们实施想法。
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.
我在一个 5 人团队中工作。为了促进我们的远程办公工作场所，我们使用：
客户端（我使用 Pidgin）
backup
即使使用这些工具，您的流程也很容易达不到要求，因此根据您的动态为您的团队建立一些最佳实践非常重要。 例如，我们有两个主要做法：
I work on a team of 5. We to facilitate our telecommute workplace we use:
client (I used Pidgin)
backup
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: