本文要点

介绍分布式敏捷框架

了解如何在分布式团队中管理文化

了解如何在企业中组织分布式工作

分布式敏捷组织的实际案例

实现更好的分布式组织的问题、品德和实践

现如今许多组织都有分布式团队。由于公司是全球性的，现代化的通信手段可以让人们不拘泥于在“办公室”工作，许多新的劳动力选择游民化工作。分布式团队成为高绩效的团队是非常可能的，只是需要付出更多努力来克服距离带来的内在挑战。

这篇文章是系列文章《分布式敏捷：如何与分布在全球的团队合作》的第一篇，这一系列的文章对文化差异给分布式团队带来的影响进行了探讨。你可以通过订阅RSS接收通知。

在过去的十年内，我一直在学习如何以一种有成效的方法管理分布式团队。2004年我去了印度，并深深爱上了这个国家。我决定创办自己的公司，我想要为荷兰公司提供外包服务（我来自于荷兰）。二十一世纪早期的主流业务是美国公司外包业务给印度。但是在欧洲，只有少数先驱在尝试提供外包服务。我在印度拜访的时候，IT产业在印度的巨大能量让我感到很惊讶。我也发现，作为荷兰人想要和来自文化差异如此巨大的地方的人一起工作会是很大的挑战。从简单的开始，我决定先和乌克兰的团队进行合作。但我的梦想一直以来没有改变：我想回到印度创办我自己的公司，让它运作起来。

寻梦之路艰辛，我为自己所做的错误决定付出了昂贵的代价。在2005年的时候还没有scrum和敏捷（虽然已经出现了scrum和敏捷方法，但还没有很多公司开始使用，我那个时候也不知道这个方法）。我们遵循于固定的日期、固定的价格、传统的项目管理和基于瀑布模型的开发的方式。我觉得如果能请阿姆斯特丹的项目经理和当地的客户合作并管理乌克兰的团队，那一切都会更好，当然我当时没有这么做。之后看来，我的经验法则是基于瀑布模型的项目有80%的概率是项目一切正常（可能会有小的延迟），而有10%的概率是虽然完成了项目，但付出了很多额外的工作。让人头痛的是剩下的10%概率，要顺利完成项目，必须把所有技术高超的人员集中在一起才能成功。所有事情都和预期有偏离（不仅仅是针对你，也针对你的客户）。

在之后的阶段，我开始尝试让专门的团队负责产品工作，而不是项目工作。由于你可以创建跨地点、跨组织的“一个团队”，一切变得更好。你可以使用敏捷和scrum来管理合作。根据我过去几年的积极经验，我写了一系列有关管理远程团队的书籍。书是由全球的从业者一起撰写的，他们把自己的实际经历写进了书里，但我觉得我们产业需要更多的例子。

现在有很多敏捷框架，显然最受欢迎的是scrum，规模化框架也受到了更多的关注。许多框架告诉我们在同一个地点工作是最好的，我也非常认同。但是不幸的是，很多公司不能这样运作。为了填补这个空缺，给人们提供能管理分布式团队的框架，我和其他三个人一起开始开发分布式敏捷框架，他们分别是：John Okoro、Savita Pahuja和Arjan Franzen。

我们还在初始阶段。我们认为把这个框架的大部分内容开源出来是有必要的，所以我们四个臭皮匠希望早期阶段的成果能够得到社区的反馈。我们开发的框架包括八个“板块”：

1.文化

2.组织

3.产品

4.团队

5.架构

6.工程实践

7.沟通

8.工具

每个板块都有三个元素：

A、问题：组织可以用来评估当前状态的一系列问题

B、品德：促进分布式合作的行为

C、实践：已经完成的工作，由从业者进行分享的内容

根据我们的经验，这八个板块是可以推动分布式工作更加流畅的助燃剂。这是持续改进的循环。根据公司的规模和复杂性以及分布式组织的成熟度的不同，每个板块产生的影响也不同。如果想要确定痛点，确定需要关注哪个板块，我们的框架提供了一系列扩展的问题。然后我们定义了每个板块能实现的品德，这些品德帮助创建“分布式敏捷文化”，即一系列行为准则。许多人就会问“那我们之后该怎么办？”。我们的实践帮助回答了这个问题，每个环境都是独一无二的，能从帮助到别人的实践中学习是解决特定的分布式挑战的最佳方案。

我们框架的共同贡献者John Okoro和我将详细介绍两个板块：文化和组织。在文章之后的内容中，我们也会更详细地描述其他的板块。文章将作为InfoQ迷你书发布。

我们也期待得到读者的意见和反馈。如上所述，开源模型是分布式敏捷框架的根本。框架是以精益和敏捷原则为基础的。

文化

拥有来自不同文化背景的成员的分布式团队不可避免地面临着合作的挑战。文化有不同层次（国家、地区、公司、团队）。在我们的模型中，文化指的是国家层面的文化。组织和团队会在单独的板块中讨论。要理解文化差异的影响并找到组织它们的方法，可以使用以下的一系列问题：

我们是否经历着文化差异的影响？

我们有“我们和他们的差异”这样的规范吗？

我们如何处理差异？

我们要如何让差异显现？

如果文化开放，人们心意相通，那将多么舒适！

在同一地点工作和分布式工作文化差异的影响是什么？

我们的组织中有多少阶层？

各个文化是如何看待阶层差异的？

我们期望能做到哪种程度的“自组织”？

要怎么做才能实现每个人都达到相同“自组织”的水平？

语言的不同会造成多大的影响？

每个人对说“不”都有相同的理解吗？

一些例子。大多数国家在管理家庭、社会、公司的方面等级阶层都各不相同。在一些亚洲国家，等级阶层非常重要。人们习惯于“听命”于父亲、老师和老板，因此“积极性”水平普遍比较低，没有人提出对权威的质疑和对上司的质疑。而在美国和欧洲，大多数国家崇尚“平等”的文化。比如说在荷兰，我们鼓励人们质疑假设，并提出自己的想法，想法来自于组织中哪个阶层的人并不重要。Hofstede的模型称其为“权力距离”，某种复杂的度量系统对国家进行分级。从这个简单的描述，你可以看出印度（77）和印度尼西亚（78）分数很高，而荷兰（37）和美国（40）分数较低。

另一个例子是开放程度。作为荷兰人，如果我对你的行为有疑问，我会直接告诉你我的想法。我相信通过分享我的想法，我们可以一起找方法来解决。但是在亚洲社会里，人们并不习惯这样。他们更愿意编造故事，迂回地讨论他们的担忧，但不直截了当地解决问题。作为荷兰人，我可能不会理解亚洲人给我的信息，因为我已经习惯了没有经过加工的、最真实的信息。这样做会造成关系的紧张与合作的压力。

上周，Hugo在印度尼西亚的日惹组织了会面。我们讨论的主题之一就是开放程度，因为它是scrum的价值之一。Hugo也和约二十五名印度尼西亚人进行小组会谈讨论。就和其他小组一样，也有些人很善谈。讨论开放程度话题的人各有不同：有的很害羞，不喜欢说话（不这么开放）；有的很习惯说英语，而有的不是（所以他们看起来不这么开放，但如果他们用自己的语言，他们就可能会表现得“比较开放”）；有些人在团队中角色比较微妙，所以他们觉得自己不方便很随心所欲地发言。Hugo已经非常习惯了（在印度的时候他也有相同的经历，他和来自不同文化的人一起工作了超过十年）。但是当没有经验的荷兰人（非常善谈，非常直接的人）要和印度尼西亚的工程师一起合作，这就会带来挑战。

我们定义了五种有助于缩小文化差异的品德：

同理心：接受差异，“充满”同理心

开放程度：讨论文化差异的影响

认知度：认识到差异

对人的信任比过程更重要

透明度

有同理心的人更喜欢设身处地为他人着想。他们可以完全代入他人的生活，理解他或她的信念、理论和参考标准。他们也更喜欢接受人与人之间的差异，他们喜欢多样性，他们笑纳多样性，他们从不拒绝多样性的存在。有同理心的人可以促进分布式合作。这就是说如果团队中有一些有同理心的人是非常有帮助的。举个例子，团队中需要有同理心的角色是scrum master。

开放程度受到担忧、缺乏信息、延迟、被“困住”的影响。组织文化越开放，人们合作起来越简单，人们对文化差异、团队“状态”和工作进展的意识也越强。大多数的知识工作都是需要创造力的，并不适合按部就班的过程。成功也取决于参与其中的人，如果有相互信任的人，管理文化差异也会变得更简单。工具可以帮助他们自组织差异，但过程并不能。

透明度能帮助人们检查并适应。当把项目的信息和进展与所有人分享，那误解就会减少。当我知道承诺的进展时，我就不需要寻求特定某人的意见（这是文化上主观的）。有了工具的支持，针对特定的用户故事展开讨论，及时获得准确的信息也变得更容易。

在上面小组讨论的例子中，我觉得自己是有同理心的。作为促进者，我了解小组中每个人开放程度不同，我尊重每个人。这很好。我想要变得开放，而不是迟钝。我也相信每个人都尽力做到最好，一些人虽然没有说话，但吸收了讨论内容，有些人很开放地分享自己观点，主导着讨论。我尽力让每个人参与到谈话中来，但我也发现自己需要学习印度尼西亚语才能更有效地主导这样的讨论。这个组是临时成立的，如果我要和他们在真实项目中合作，我就要花费更多时间安排好小组内方方面面的问题。

组织

随着技术推动着全球化合作的发展，企业也变得越来越分布。人们开始在家工作，项目团队也分布在不同地点。要跨地点协调工作，敏捷原则起到了帮助的作用。团队成员和利益相关者的互动很频繁，并基于模式互动。利益相关者、用户或客户和开发团队紧密合作。组织根据scrum框架创造角色、事件和工件。但决定要在什么位置放什么角色，协调不同时区的人完成工作并不容易。不在同一个办公室工作给保持工作一致性带来了挑战，也不一定能看到每个团队（成员）的表现。以下是在组织层次可以提出的问题：

问题

我们采用什么开发框架？（scrum、LeSS、Kanban、SAFe等等）

怎么调整框架，适应我们的分布式团队设置？

角色：把什么角色放在哪里？（比如说代理产品负责人）

事件：我们组织的事件有什么不同？（比如说，如果时区不一样，可以使用视频进行记录）

工具：什么工具可以支持分布式框架？（选择JIRA还是sticky board）

我们创造分布的团队（每个人都是远程或是分布的团队）还是在同一地点工作的团队？

我们如何衡量成功？我们的kpi是什么？

如何在所有团队成员之间有效地分享知识？

我们如何分享产品视角、路线图和用户反馈？

如果我们要合作，怎么在战略、战术和运作层面保持一致？

对于分布的敏捷团队来说，最主要的挑战之一是如何利用好产品负责人和利益相关者。团队常常茫然无措，因为他们不知道做什么。负责产品的人是每个组织里最忙碌的一批人。他们需要均衡用于开发团队、利益相关者和管理之间的时间。他们通常会属于多个产品团队。与产品负责人一起工作的团队有更多的机会可以和他们互动，但是远程团队就没有这个机会了。此外，远程团队几乎不能与他们的软件产品的用户对话。他们不能了解产品视角、路线图和相关的计划。因此，他们与自己创造的产品之间没有“情感联系”，这也会影响动力和质量。组织需要思考关键角色的分布，以及开发团队与用户和利益相关者联系的方法。我们还要思考如何在分布式组织中分享知识和产品信息。

要创建有成效的分布式组织，以下列出的品德可以有所帮助。

品德

敏捷性：对模型抱着开放的态度，避免官僚主义

自组织：让团队自己发现问题

在同一地点工作的团队更方便

和利益相关者直接联系：避免中间人（产品负责人应该促进团队和用户之间的交流，而不是当两者之间的传话筒，不要团队领导，不要等级阶层）

维基是关键，选择正确的工具分享知识、视角和反馈

在不同地点的跨职能团队

在不同地点调整敏捷转换视角

Kaizen（持续改善）代替Kaikaku（突破性改善）

将这些品德用于上面提到的“茫然无措”的例子：我们可以使用敏捷原则来组织。我们将权力交给团队，而不是建立严格的规则和报告系统。通过回顾，团队可以发现阻碍他们的问题。授权的、自组织的团队可以公开地将这些阻塞与产品负责人和利益相关者沟通。有了优秀的产品负责人和迭代改进，团队可以找到分享产品信息、路线图和用户反馈的方法。

业务团队的人和开发者每天合作，这可以避免产品负责人成为中间人的问题。使用视频会议软件或在同一地点工作，开发人员可以和用户以及利益相关者沟通。如果组织鼓励团队使用像维基一样的工具是有所帮助的。免费提供这些产品，分享产品视角、路线图和相关文件就变得更容易。

另外一个值得关注的分布式敏捷组织领域是不要做得太多太快。用日语来说就是Kaikaku，突破性改变。这就是说彻底改变你的团队，改变团队职务和角色，以适应敏捷框架。这会导致你的团队感觉到改变起来很疲惫，团队也不能有效工作，他们陷入“形成”和“动荡”的循环之中（团队通常会经历形成、动荡、规范和运行的循环阶段，建议尽可能实现规范和运行状态）。

举个最近的案例，John熟悉的一家大银行尝试采纳敏捷方法，在各个地方使用Kaikaku方法。给所有的经理赋予敏捷教练的职位（尽管他们对敏捷没什么了解），并一下子做出巨大的改变。尽管银行一开始觉得用Scrum方法工作取得了很大的进展，但大概18个月之前，组织和团队突然前进不动了，陷入了改变疲惫期。之后改变的进展越来越少，阻力越来越大，迫使银行停下激进改变的脚步。此后银行采用了更加健康的Kaizen方式。根据John所知，对于这家银行来说，这个方法更加可行，并持续到了现在。

推荐使用kaizen（持续改进）方式进行改变，而不是改变组织中每个人的角色和职位，做出小的增量改变，改善你的分布式敏捷团队。你的团队也会喜欢这种方式，这种方式对人很尊重（这也是“Lean Thinking House”两大支柱之一）。作为普遍的经验法则，Kaikaku方法和革命性变更在新的组织和初创公司中更能发挥效用，因为这些组织或公司不存在或仅有少量的“包袱”需要处理。

总结

当所有人在一起工作时，分布式组织面临的挑战就不会出现。可能在一起工作时也会碰到一些挑战，但影响力大大缩小。我们的框架将主要挑战分为八个板块。我们讨论了当人们和团队远程工作的时候，“文化”和“组织”中发生了什么。为了帮助人们评估他们的组织，我们在每个板块中也设置了一系列问题。在之后的文章中，我们将分享其他六个板块。我们非常愿意收到你对框架、问题和品德的反馈。