案例：规模化敏捷下实现完全自组织

文章来源：Agile Alliance

原文作者：Ron Quartel

译者：Judy-朱迪

关于本文

2016年，我所在的部门（在一家高度传统的健康保险公司内部）决定尝试一些非传统的东西：一项以前没有人做过的规模化敏捷实验。把工作布置下去，让一个50人左右的群体自行组织成团队，每两天重复一次这样的实验！在将近两年的时间里，我们持续改进这个系统，它运行得非常好。实验一直持续到一些关键环境因素发生变化导致其终止。本文概述了我们所做的尝试、学到的知识以及我会向有兴趣创建一个规模化、自组织、复杂自适应系统的人们推荐的内容。

1. 简介

2014年5月，新奥尔良，在一场约有800人参加的敏捷会议出现了一个意想不到的灵感乍现的时刻！这次为期三天的活动的最后一天是一次非常规性活动，即开放空间活动。在20分钟内，我目睹了800人自我组织并制定议程，然后完美地完成了一天的会议。让我震惊的是，这个简单的系统是多么强大、优雅和能干，它完全依赖于自组织并可扩展！也许正因为会议的主题是规模化敏捷，我在概念上实现了一个飞跃—为什么我们不使用开放空间技术（OST）来解决规模化敏捷？到目前为止，我觉得所有的努力都过于强制，而我不喜欢，但“开放空间”揭示了一种更符合敏捷价值观的方法，而且似乎充满了潜力。

快进两年到2016年春天，美国太平洋西北，一家健康保险公司回归了这一令人兴奋的理念。我发现自己面临着一个规模化挑战，随即提出了团队使用OST的想法。这个想法很受欢迎，我们同意将其作为一个实验，这个实验进行了将近两年。关于企业文化和人性的一系列令人惊讶的事实反映了他们自己。同时还有一些令人振奋的新工具和前沿敏捷方法以及规模化敏捷，值得与社会分享。我们是真正的开拓者。一种新的语言、新的工具和新的过程形成了。（我用粗体强调了新的语言术语。）它改变了我，让我了解了新的人类运动，并改变了我对许多现在常见的敏捷假设和最佳实践的看法。

2. 背景

因为以前在这家保险公司做过顾问，我对那里的文化很熟悉。我无法想象自己会再去那里工作。因此，2016年，当一位朋友联系我，建议我加入他在上述公司的团队，我认为这听起来像是个坏主意。他向我保证，这个群体是不同的。它有一个强大的领导者，自主权，对一些令人兴奋的产品的开发，对极限编程（XP）的承诺，并将更像一个初创公司或公司内部的研发部门。相信这一切都是真的，我作为一名软件开发人员，加入了一个6人小团队。

3. 故事开始了——如何 规模化 才算公平 ?

我们招聘速度很快，需要一位scrum master。我在敏捷领域有多年作为开发人员、经理、教练、培训师、讲师和顾问的经验。我的经验告诉我，如果我们在scrum master的选择上出了问题，工作不会顺利。所以，在我们继续寻找合适人选的时候，我自愿填补了这个空缺。寻找scrum master最终花了一些时间，所以我没有继续寻找，而是留在了这个职位上，并将头衔改为敏捷教练。

从一开始，我们就知道我们的数字平台部门将拥有两种产品，以期在以后添加更多产品。一个产品正在迅速成为遗留系统，而我们还没有在另一个移动平台上启动。移动是我们新的、最吸引人的平台，它将给开发者一个学习新技能的机会。这就是我面临的困境：如果我们分开团队，谁在移动平台工作，谁负责老产品?

怎样做才算公平?为什么最了解遗留系统的人要被束缚在它上面?这感觉特别不对，因为其中一些开发者是长期雇员。如果他们想要改变的话，他们应该为自己付出的时间获得奖励，并获得学习新技能的机会。这时我突然想到了一个主意——如果我们像一个有凝聚力的整体一样团结在一起呢?一个可以动态组成团队以应对变化和易变的优先事项的群体?多年前使用OST（开发空间技术）规模化敏捷的想法作为一个可能的解决方案回来了。如果团队同意这个想法，我们就可以组合在一起，而不必分开!

我把所有人都召集起来，征求他们的意见。为什么我们没有一个让个人自主选择工作项到自己团队的集市?这个系统将允许人们在不同的产品之间流动，并赋予组织在需要的产品之间灵活工作的能力!这是双赢。如果所有需要做的事情都完成了，是谁做的又有什么关系呢?群体将从用户故事地图中提取工作并组成团队(而不是将工作推入静态的团队)。编舞比编曲更重要!请参见下面的图1。

这个想法最终胜出，因为我们知道，如果两个月后它还没有成功，我们可以很容易地回到敏捷方法和流程。如果需要的话，我可以闭着眼睛实现它，就像我以前经常做的那样。

4.1 积压工作的管理——功能映射&功能管理员

当谈到如何管理待办事项时，用户故事地图的想法很有吸引力。它将赋予群体一种能力，可以看到整个工作内容，并理解不同工作项之间的关联。但在实践中，我们很快就发现维护一个用户故事地图是很棘手的，因为随着群体的壮大，工作的分裂是迅速而大量的。(我们尝试了实体格式和电子格式。)

当我们决定在用户故事地图上只显示高级特性时，解决方案就出现了。我们将用户故事地图（重命名为发布图。我们在各自的板子上跟踪更细致的工作项，为每个功能分配一块板。根据工作项从根节点递归分解的分支性质，这些板被称为特性图或特性树。有趣的是，用户故事地图的概念并不总是适合子节点，我们最终将所有东西都称为工作项。我们把这个待定项管理的新系统称为特性地图。

与此相关的是，我们还提出了一个特性负责人的角色，这解决了业务人员不知道在群体中向谁提问的问题(由于动态重新组队的原因)。

我们正在我们的群体中开发一种新的敏捷术语、过程和角色。这是一个激动人心的时刻!

 发布图的例子

特性树实例

4.2 在非静态团队中预测和估算——群体的智慧

下一个挑战是预测和估算。敏捷推荐进行工作的团队去对工作进行评估。但是在我们团队动态重组的环境中，谁也不会提前知道自己会处理哪个工作项。

在思考这个问题的时候，我碰巧读到了J. Surowiecki的《群体的智慧:为什么多数人比少数人更聪明以及集体智慧如何塑造企业、经济、社会和国家》。太令人兴奋了!让我们试试群体评估的智慧。群体预测的智慧是通过从大量人中收集评估结果，以其平均值作为最终估计值。我后来了解到，Cynefin框架之父Dave Snowden建议，对于复杂领域的问题(如软件交付)，最好的评估方法是使用群体的智慧。我的预感是对的!

使用群体的智慧，我们可以估计完成用户故事地图上的每个功能所需的工作量!把这些预测值加起来，你就可以计算出目标发布日期。为了简化这个过程，我们创建了一个便捷的网络工具。只需几分钟(与传统敏捷评估方法的几小时或几天相比)，我们就可以预测一个功能或整个版本!

4.3 大规模持续改进：开放空间回顾和过程改进协会

“每隔一段时间，团队就会反思如何提高效率，然后相应地调整其行为。”

------敏捷宣言背后的原则

下一个挑战:在动态团队环境中，如何进行反思?因为我们的团队组成是动态的，所以团队回顾没有多大用处。我们在Hunter Industries（亨特工业）听说过一个“发现优点”的做法，并决定试一试。我们将在每个迭代之间的会议开始时强调上个迭代中哪些实践进行得很好，以及为什么。虽然这种做法有一定的价值，但仍需要做得更多。

接下来的实践是组建一个流程改进协会。事实证明，建立协会是个好主意。在协会会议上，任何人都可以来分享观察结果并提出实践建议。所有的实践都经过了整个群体的准许，我们的认识在这些过程中循序渐进(不是一下子改变所有的事情)。但我们还是觉得少了点什么。有听不见的声音和不满。

最终，我们尝试用一整天做群体反思活动，利用开放空间来促其进行。这个活动终于解决了缺失的问题，我计划有规律地来进行这个活动，比如一个月一次。开放空间活动的主题是“反思和改善”。

在开放空间活动中，任何对某个话题有强烈感受的人都可以与其他感兴趣的人一起讨论，共同提出行动项目或实践。或者反之，有时只是一次对话就足够了。这种方法与我们的自组织核心价值是非常一致的。

4.4 大量在制品（WIPs）：群体编程和在制品限制

一开始，有一种趋势是，一个团队把极限编程理解为两个人一起做一个用户数。这个问题的部分原因是我的错误，当我们决定迭代长度时，我分享了一个XP团队能够在两天内完成一个故事的类比，结果是有太多的工作项在进行中。迭代看板变得越来越宽，并且进度感觉缓慢且难以跟进。令人惊讶的是，这一修复是我们持续致力于精通(我们的编程技术)的副作用。我们决定进行群体编程(Mob Pragramming: 群体编程是一种软件开发方式，是结对编程的扩展，整个团队从事同一段代码编程。

)培训，并邀请了伍迪·祖伊尔(Woody Zuill)(作为发明者和专家)参与。群体编程(Mob Pragramming)成为了热门，从那时起大多数团队都是由3-6名开发者组成。一个团队现在已经超过了两人(尽管两人组队仍然是允许的)，工作范围更大了，同时进行中的工作也减少了。

5. 发现

5.1 极限计划(XP)支持动态团队形成

动态团队组建成功的一个有利因素是，在我们的部落协议中，我们指定使用XP（极限编程）的纪律完成所有编码工作(结对编程、无情的重构、测试驱动开发等)。

XP（极限编程）是动态重组团队的成功因素，原因如下:

l  结对编程——XP开发人员习惯于经常切换结对伙伴和工作环境。他们可快速同步并交付价值。

l  集体代码所有权——使得在需要的时候进入代码的任何/所有领域成为一种惯例。

l  编码标准——随着代码的风格和语法在整个代码库中变得一致，开发人员能够非常快速地阅读和理解整个代码。

在Heidi Helfand的《动态重组团队:改变团队的艺术和智慧》一书中，作者专门用了一章来介绍(动态重组团队的)约束和促进因素。Helfand在这里同样指出了XP实践与动态重组团队之间的支持关系。

5.2 短迭代优于长迭代——两天迭代，并摆脱Scrum的束缚

当我们开始思考迭代长度时，我想看看我们能在多短的时间内完成。我回想起我的XP时代，那时一对搭档通常在两天内完成一个故事。所以，为什么不试试两天呢?

我们开始进行为期两天的迭代，但过了一段时间后，出现了抱怨。我把它归结为人们仍然在用scrum思维, 因为scrum典型的迭代周期是两周或一个月。因此，我们尝试规定一周为迭代期，在运行了几个月之后，我惊讶地发现，大家一致认为两天的迭代更可取，于是我们又切换回来了!

我们必须摒弃scum的思维方式，一旦我们这样做了，敏捷的前景就会变得非常不同。它现在是开放的，充满了潜力。

5.3 我们不是迭代——无意中创造了基于工作流的系统

我们在每个迭代期临近的会议将遵循以下步骤:

l  在最后一次迭代结束时，每个团队都要做一个“show and tell（演示和告知）”，突出强调对部落的其他成员来说系统重要的更新有哪些。

l  清除迭代看板

l  产品总监告诉大家什么是重要的，以及自上次会议以来发生的变化

l  利用开放空间技术，围绕工作自组织成团队

迭代边界会议(我称之为FAST会议)是该过程中唯一的会议，起到部落同步的作用。(一般时长为15-30分钟。)这个会议没有完成一组预先确定的工作的概念。相反，重点是持续交付价值，并在系统发生变化时保持群体与系统当前状态的同步。通过这种方式，如果你将我们的过程与敏捷进行比较，这个同步会议更接近于一个碰头会而不是冲刺的交替。我们一开始打算创建一个迭代系统，但出乎意料的是，结果我们更接近于看板或基于工作流的系统。

5.4 自组织并不适合每个人：需要准备好有人离职

令我惊讶和悲伤的是，事实证明并不是每个人都渴望自治。一想到我们的学校教育、社会和组织以非自主管理的方式摧毁了人们的精神，我就感到心碎。从那一刻起，“在工作场所释放人类精神”就成了我的人生目标。我不建议强迫任何人自治。这和相反的情况一样残忍。我意识到，有必要优雅地让那些想离职或没有准备好在自我管理的环境中工作的人离职。

6. 我们的大规模自组织实验如何结束

由于一些内部和外部因素，实验最终结束。

l  外部因素。我们的部门向CTO汇报（CTO给予我们自主权，并保护我们不受更大范围的公司文化和工作方式的影响）。从一开始，这就制造了一种紧张感，感觉我们就像是在被持续的审视。当首席技术官离开后，没过多久，公司就开始要求员工以和公司其他人一样的方式做事。我们的研发部门和创业环境都消失了。

l  内部因素。随着团队的壮大，有了招聘中层经理的预算，个人员工与经理的比例为8:1。我们雇佣的一些中层管理人员似乎仍然囿于一种命令和控制的思维模式。这些人的行动很快影响了士气，并开始侵蚀我们的自组织原则。例如，这些中层管理者支持静态团队和团队领导。与我们的自然领导和动态团队形成的自组织系统相比，在这个系统中，个人自愿领导一个群体(我们对团队的称呼)，其他人自愿加入。

大约在同一时间，当我们的一个产品落后于他们的时候，我们从更大的组织中吸收了一个团队。这个团队中的许多人在自组织和极限编程方面遇到了困难，一种瓦解体制的借口出现了。我们开始看到未经测试的代码和存在质量隐患的项目。

这些因素结合在一起，导致我失去了继续下去的影响力和兴趣。我变得灰心丧气，决定离开公司，因为自主权的障碍变得不可逾越。输掉的战役已经足够让人知道整个运动很快也会输掉。我离开的时候和公司关系还比较融洽。

我的理解是，这个部落在那之后的一段时间里一直留在那里，只保留了系统的一部分。从那时起，他们就受到了企业敏捷转型活动的影响，以及这种活动所带来的一致性。

7. 经验教训

7.1 胜利——为什么我会再做一次

l  坚韧——不管员工休假、生病和变动，团队都能持续进步。

l  适应性——我们能够将工作转移到最需要的地方。

l  员工敬业度——“我从来不想用其他方式工作”，“这是我最喜欢的前进的敏捷方法”是我在实验中听到的一些评论。我把这归结为来自工作自主性的内在动机。根据丹尼尔·平克在他的书《驱动力:激励我们的惊人真相》中所说，自主性是人们工作的关键动机之一。

l  它起到了作用!--我们提供了持续的价值。

l  作为先驱--当地的企业来参观我们的过程，因为消息传开了。

l  简短性——我决定保持过程简短性。只有一次会议，我们把时间控制在30分钟以内。(对敏捷的一个常见抱怨是会议太多。)

l  天生的领导能力——这个系统允许任何人来培养他们自己的领导能力。

l  成本低——我们不需要scrum master，整个群体只有一个敏捷教练

l  (我的规则是，一个群体的规模上限是邓巴的数字——150人。)

l  基于编曲的编舞——由于依赖关系管理，拥有固定的团队需要一种编排方法来工作。通过拥有流动的团队，我们迁移到这样一种模式，即依赖性消失，因为当阻塞或合并团队以消除依赖性时，团队将转移到其他工作上。动态的团队也允许团队成员分享少数人具备的技能，如用户体验和设计。

l  常识胜于明确的规则——例如，我们不需要“完成”的定义。

l  解放人类的精神——自主和自组织系统是在工作场所对待成年人的更好方式，尤其是对待有知识的工作者。

7.2 一个新的规模化敏捷框架诞生了：流动性拓展技术(FAST)

在过程中，我试图将这个系统编纂，我们将这个系统命名为流动性拓展技术(Fluid Scaling Technology)，缩写为FAST。

7.3 开创新时代——再造工作/人性化工作/青色组织

这个实验十分令人激动。它让我开始了敏捷之外的下一个冒险，也是我的激情所在。这个运动有很多名字:

◎青色组织

◎人性化的工作

◎人类运动

◎自我管理运动

◎下一代的组织

◎工作重塑

◎响应型组织

也许有一天，一群先驱者会在一个滑雪旅馆会面，提出一份宣言，并为这个运动商定一个名字!

FAST的自我管理的方面，让我发现FAST既是一个敏捷扩展框架，也是一个青色组织框架。