更高的目标: 自我管理(Self-Managing)团队的下一步

没吃过猪肉，也要见过猪跑。

今天，我们就来见识一下“自我管理”团队的下一步长啥样？

2017年我在辅导各种团队的过程中, 发现组建Scrum team有几个困扰经理们的典型问题：

1. 到底按照feature还是component？

2. Scrum Master还必须要coding行不？

3. Product Owner没有权利验收用户故事，优先级也不是TA说了算啊！

4. SM和PO就一个人做呗！

……

这些问题有标准答案吗？如果有标准答案，经理们愿意照着做吗？现实情况允许按照标准答案执行吗？我们只能采取循序渐进的策略，但是愿景是不变的：

Every feature team should be able to work on their own on every backlog item independent from the requestor.

即：每个特性团队应该能够工作在每一项backlog上并与需求方无关。

对于没有任何Scrum理念的团队，从零起步，第一步就是要做到“自我管理”。什么是“自我管理”？“Self-Managing”这个词源于已故哈佛教授 Richard Hackman 2002年的著作《Leading teams: Setting the stage for great performances》，定义如下:

The team is responsible for executing the tasks and monitoring and managing process and progress.

即：自我管理团队负责执行任务并监管过程和进度。

Hackman定义了一个团队进阶模型，看下图紫色区域，就像四个台阶。

从严格管控模式起步，团队要成长为自我管理团队，必须自己担当起下面这些责任：

1. 团队自我检查Sprint执行状态，是否可以按照迭代计划达成目标？

2. 如果进度落后，团队要自我采取行动，比如主动加班

3. 团队自我决定如何完成工作

4. 团队自我解决冲突及团队中的问题

当团队逐步成长为自我管理团队时，经理不再负责

• 检查Sprint状态

• 组织任何“状态会议”

• 告诉团队要做什么，或者加班

• 决定派哪个团队成员解决生产问题

• 在“敏捷项目管理工具”中监视团队

• ……

这时的团队必须保证完全透明，经理去看 (Go see) 就好了！而不是通过他们掌握的信息 (信息不对称) 来控制团队，也不会通过加点东西来跟踪团队。

请仔细看清楚，上面所述的自我管理团队的责任是需要很多能力支撑的。你是不是看到了项目经理、架构师、甚至管理者的身影？是的，自我管理团队绝不一般！核心角色和骨干成员共同担负起了管理和跟踪的职责，而且还要透明、轻量级、有效率、促进团队幸福指数～～ 不容易但是可以做到，多久可以做到？稳定的团队半年之内应该可以了。但还需要经理负责这些事情：

• 设计团队及其组织环境

• 设定全局方向

当一个Scrum initial team在项目经理、架构师、经理、教练等外部力量的帮助下，付出很大努力上了一个台阶，到达自我管理团队的状态后，下一步怎么走？

我还没有亲眼见过 Hackman所描述的下一个台阶上的自我设计“Self-Designing”团队，下面先用一个非常有趣的BMW案例纸上谈兵吧！期待未来可以亲眼看到或者亲手做到一个活生生的案例。

BMW请敏捷顾问Mark Bregenzer辅导了一个“Self-Designing”团队工作坊，即ReOrg工作坊！让我感受到了自治的力量！首先制定了如下议题：管理者一开始要讲清楚愿景 (即本文开头的愿景) 以及这个ReOrg工作坊的目标, 即：

1. 更灵活地处理不同的backlog工作项

2. 推动项目的有效性

3. 再造团队精神

4. 增加每个人的动力

开这个ReOrg工作坊之前，这个百人团队的阵型已经被诟病为前进的障碍, 不能灵活应对需求和优先级频繁变化, 不好扩展, feature cycle time太长，等等:

• 有两个需求方: A, B

• 约100名项目成员

• 4～5个跨学科领域/组件开发团队

• 4个横切crosscutting团队，即非开发团队

1. 持续集成CI团队

2. 缺陷与测试管理团队

3. Build治理团队 (BMW架构，BMW标准…)

4. 设计治理团队 (业务澄清，发布计划…)

• 一个项目管理团队和敏捷教练们

• 每两个团队有一个Scrum Master

ReOrg工作坊是为了调整阵型，把组件团队重组成特性团队。游戏规则如下:

1. 新项目团队应该尽可能地匹配愿景 (即本文开头的愿景)

2. 因合同问题，横切团队仍保持其结构/大小，但可能交换单个团队成员

3. 组建5个特性团队，每个团队包括：1 PO，2 PO支持，6-7开发人员

4. 每个特性团队必须至少有一名来自分包商的内部开发人员

5. 团队任命自己的首席开发 (主要对接Build治理团队) 和Scrum Master

6. PO、PO支持和开发人员自己去发现自己的团队

7. 只要符合这些规则，项目管理就会接受每一个组织

每个人填写一张技能卡，这样在团队创建阶段可以很容易地看到可用的技能:

每个特性团队有一个团队容器板：

ReOrg行动通过三个迭代进行，第一个迭代35分钟主题为“找团队”，每个参与者都要做这些事情：

• …面试同事

• …要求新成员

• …用大头针把技能卡别在团队容器板上面

然后所有人进行评审，也有三件事情：

• …能从一个队移到另一个队

• …检查团队是否符合愿景

• …如果需要的话，可以在团队容器板上发布缺陷

迭代一结束时，新团队初步形成，可是有一个组件团队 (叫它Black队吧) 没怎么动。第二个迭代30分钟主题为“完善团队”，大家做了这些事情：

• 团队尝试解决他们的缺陷，并要求Black队的支持

• 接下来Black队的团队成员有离开的，也有少量加入的

• Black队还不完整

• 其他队想尽量保留他们的队员

• 不知何故，改革进程停滞不前

然后所有人离开会议室，休息10分钟。再回来做第三个迭代25分钟主题为“完善团队”，大家又取得了新成果：

• 参与者休息完，获得了新能量

• 所有团队都帮助解决最后的缺陷，特别是帮助Black队

• 当解决完最后的缺陷时，整个队伍欢呼起来！

ReOrg行动结束时，又完成了这四件事情：

• 发现一个团队名称

• 发现一个团队工作区

• 投票选出首席开发

• 投票选出Scrum Master

最后向所有人解释下一个迭代的运作规则：

• 未完成的用户故事由开发负责人并入新团队

• PO和PO支持刚开始仍保持他们的责任/接口

• 各个领域专家不再只专注于一个团队

• 工作中的缺陷仍然伴随着他们的开发人员，并进入新的团队。

• 正在解决的缺陷由开发负责人并入新团队

• 未开始的缺陷仍然分配给老队，由新队拉入自己团队

• “测试管理”团队会升级没及时解决的缺陷问题

大家最后以一个词反馈来结束这个ReOrg活动：

这次ReOrg即“Self-Designing”团队工作坊非常成功，会后发生了很多积极变化，每个新团队被奖励一次团建活动：

1. 非常积极的心态，正能量和激励效果

2. 每个人都对他的新团队感到满意，甚至连没参加工作坊的成员都对他们的新团队感到满意

3. One-team精神超出了管理层的预期

4. 所有特性团队都能够工作在每一项backlog上并与请求者无关

5. Social问题貌似得到了解决

上面这个案例讲述了如何从自我管理(Self-Managing)团队走向自我设计“Self-Designing”团队，这也意味着管理者就不再负责设计团队及其组织环境了，ReOrg不再是管理层自己的事情，而是所有人参与选择和完善的过程，组织环境由此而变。