敏捷从2001年被首次提出到现在已经历经了17个年头，作为一种新的思潮和软件开发方法早已跨越了鸿沟（如图1所示），并团结了大部分实用主义者，陆续掀起了不可逆的全行业敏捷精益转型。
如果你的公司或者组织正在进行或者已经经历了敏捷转型，那么作为组织变革者的你，一定在转型初期，组建了类似于“变革委员会”（或者“敏捷工作组”、“敏捷小组”、“变革小组”、“敏捷组委会”等）的团队。而在这个行业中应运而生的关键角色之一 —— 敏捷顾问/敏捷教练，入驻客户现场以后，提的第一个建议很有可能也是成立这样的团队。
图1 技术采纳生命周期 – 跨越鸿沟 Geoffrey A.Moore《公司进化论》2006
其实这种类型的团队有一个专业的名词 —— ETC，全称为Enterprise Transition Community（企业转型社区）,是由 Mike Cohn首次提出，并在《SUCCEEDING WITH AGILE: SOFTWARE DEVELOPMENT USING SCRUM》中做了详细的介绍。
ETC的成员不超过12个，他们来自于参与Scrum转型的最高级别人员。
ETC的存在是为了营造一种文化、一个氛围 —— 那些对企业成功饱含热情的人尝试做出改变，而这些人的成功又会使更多的人产生更大的热情。ETC不是通过强行实施企业变革，而是通过指导实施变革的小组，为成功实施Scrum排除障碍，为变革创造活力与激情。
虽然ETC刚开始是Mike Cohn为Scrum设计的，但是在实际应用过程中早已不局限在Scrum转型了。同时，ETC也并不只是为企业级别所特有，也适用于更小的规模，比如说：一个BU，一个部门，或者一个产品团队（通常人数规模在100人以上或者人数少但是跨部门）。虽然每个咨询师或者每个组织有不同的称呼，但是几乎每个咨询师或者变革组织都会在转型前期成立这么一个团队，足见其重要性。为了统一语言，本文会使用ETC这个名称做进一步的深入分析。
先来说说我在咨询现场的做法。我一般会协同高层领导、组织变革者组建专门的改进跨职能团队，比如一个研发组织，包含业务、开发、测试、运维等部门负责人，成立ETC，选择改进的Product Owner和Scrum Master，人员控制在15人以内（有的组织非常大，波及人员范围较广，需要领导层酌情取舍）。
ETC按照Scrum方式运作，让变革者在战斗中学会战斗。团队有正式的启动仪式，迭代周期为一个月（或者两周，不建议更短，后续以一个月为例）。一个月一次改进计划会议，通过改进Workshop制定改进措施，并梳理优先级，责任到人，一周两次站会跟踪，每次半小时，针对改进项具体内容设置评审时间和形式，一个月一次回顾会议。
这是组织进行敏捷转型过程中一个非常重要的改进落地机制，是组织的改进引擎。令人欣喜的是，这几年下来，有很多客户，在咨询师撤场两三年后还能够继续按照当初的机制运作，“持续改进”已经植入了组织的DNA，始终有这么一支队伍持续不断地率领组织时刻反思勇往直前。
但是，更多的是运作不好的ETC。尤其是ETC运作初期变革者缺乏经验，非常容易陷入困境，接下来我们就深入了解一下ETC的六个陷阱和应对措施。
陷阱1：没有共同的目标，ETC名不副实
ETC的成员往往都是参与敏捷转型过程中的最高级别人员，是一个管理团队。而管理团队往往会有屁股思维；以研发场景为例，可能会有开发部门领导、测试部门领导，还有产品领导，项目经理等。
因为人员角色多，大家关注的内容就各有侧重，ETC的计划会、站会或者回顾会中如果偏向于部门或者项目，那么另外的人可能参与感就不是很强。更重要的是，分散的目标很有可能会造成互相推诿抱怨，效率低，改进不明显。
作为ETC的发起人或者变革者，第一个要解决的就是ETC成员目标不一致的问题，就像造船分配任务之前要唤起团队内心对广阔无限海洋的渴望一样，我们需要找到核心问题，让ETC成员意识到问题的严重性，树立紧迫感，渴望改变现状，然后引导大家共同制定改进目标。
这只是第一步，变革者需要不断的与ETC成员沟通问题和变革愿景，适当时候对目标升维或者降维，甚至通过求同存异的方式让大家达成共识。
陷阱2：知易行难，ETC成员没有以身作则导致转型也就是一阵风
有一次，开家长会的时候，幼儿园的老师让家长跟着做动作，老师一边把手放在眼睛上，一遍嘴里喊着“请把手放在下巴上”。很多家长不知所云，最后大部分家长都会比较纠结地把手从下巴转移到眼睛上，又有点犹豫，最终还是效仿老师把手放在了眼睛上。
这是一个很好的“知行合一”的小游戏，我们的孩子是这样，我们的团队也一样。他们并不会根据管理层说的调整自己的行为，而是根据管理层做的调整自己的行为。
变革过程中，有时候领导会觉得团队改进进展缓慢，很多情况下与领导的风格大有关系，“一句话需求”或者“说一套做一套”都是最直接的罪魁祸首。
举个简单的例子，如果作为部门经理或者项目经理的你，希望在研发团队运作中增加一个Story Kickoff的环节，就需要不愿其烦地与团队讲Kickoff怎么做，为什么要加这个环节，能解决我们什么问题，并且在实际运作过程中参与到具体的Kickoff活动并给予团队指导；当团队遇到问题的时候，帮助团队一起解决问题，并且鼓励团队。如果你只是吩咐了一句：“大家做吧”，然后就静待收割，99%的概率会失望。
再举个例子，敏捷理念中非常重要的一条是：管理者转身 —— 使用“使命式指挥”替代命令控制。一起参加培训的时候，你对“使命式指挥”赞不绝口，非常认同，并启发管理层全部要向“使命式指挥”看齐，但是培训过后的日常管理中，对管理层又是直接命令来控制去，这个时候，大多干部都会潜移默化地效仿并对他的团队也使用命令控制，而不是“使命式指挥”。
这个陷阱的应对措施最简单也最难：以身作则，知行合一，有的时候，有些根深蒂固的习惯非常难改，尤其是管理风格，但是要让团队知道你是意识到自己的问题并且在尝试改正的。
如果我们要改变，首先需要定义出我们期望的行为是什么，我们希望人与人之间有怎么样的行为方式，并教会员工这种方法。
陷阱3：事无巨细，ETC成员沦为微管理现行犯
如果原有领导班子是命令控制性风格，这几乎是ETC成员最容易犯的毛病之首，管理太细节，改进Backlog太细节。
三年前我就见过一个领导团队，7、8个部长就一个“测试场地到底有20平方还是40平方，能不能放下测试仪器”的事情吵了起来，而这样的领导者容易犯的第二个毛病就是：没有了解清楚就给方案。
关注的内容太过于细节，但是领导往往掌握不了所有的细节，这样的矛盾就会滋生出更多的矛盾，甚至造成给底层员工添乱的尴尬局面。
而ETC的一个重要职责是营造一种环境，在该环境中里，可以逐渐形成不 同的改进社区，这些改进社区在追求改善企业产品创建过程中，自发地形成和解散。
Mike Cohn《SUCCEEDING WITH AGILE: SOFTWARE DEVELOPMENT USING SCRUM》
ETC最大的目标是创造这么一个环境，让改进社区确认自己的目标，并自发地组织起来达成目标。
现在你是否发现，进入ETC其实并不意味着我们自己要做很多很多的任务，比ETC实际要完成的这些工作更重要的是，传递我们的转型愿景并激发别人的兴趣。
陷阱4：将信将疑，ETC成员期待他山之石可以攻玉
例如，作为事业群的最高领导者及ETC的PO，其实对整个转型过程呈观望状态，由于其他事业群的压力所迫，不得不跟风；虽然敏捷运作开始了，但是更多是谨慎前行，你希望团队要告诉你敏捷到底行不行。
这种场景，几乎都有一个同样的结局：失败。
经历过这种转型的咨询师或者变革者都会深有感触不堪回首。我在咨询现场，对领导层提的第一个要求就是：乐观并且坚定。管理层的乐观和坚定非常重要，强调多少遍都不为过。
因为，如果管理层将信将疑，团队会从各种互动中感觉到管理层的质疑，继而团队就会质疑，觉得转型没用，然后又会反过来影响管理层对转型的信心并加剧管理层的质疑，循环往复。最终以失败告终。
这里必须要提一下“文化变革的新旧途径”，约翰·舒克是丰田城的首位美籍员工，在经历了NUMMI公司的成功精益转型之后，他对沙因的文化变革模型进行了修改，他认为：
要改变文化，首先要去改变的不是人们的思考方式，而是行动方式，即他们怎么做事。
2015年，在沙因和约翰的模型基础上，为了让变革者能够更容易操作，我提出了如下观点： 对于管理层，我们要通过改变他们的思想改变他们的行为； 对于基层员工，我们要通过改变他们的行为来改变他们的思想。
随后的几年咨询生涯中，又经历了许多案例，何尝不明白“二分法”是最危险的思想，不管对于哪个群体，让其发生改变其实都需要思想和行为的相互佐证。但是，在大多数情况下，这样看似粗暴的划分其实并无大碍。尤其对于管理者而言，思维改变是前期最重要的一环，从古至今的无数变革案例几乎都昭示了一个不争的事实：领导者没有下定决心痛定思痛，变革的路就走不长远。
图2 文化变革的新旧途径
陷阱5：缺乏与基层团队的多渠道连接，ETC更像空中楼阁难以为继
就像陷阱3中提到的，ETC成员靠自己只能完成一点任务，取得一点成果，他们更需要依靠组织中的其他人完成实践落地而走向敏捷所需要的大部分工作。因此ETC如何发动群众，辐射群众，与更广大的团队形成一对多的继承和相互促进的关系就显得尤为重要。
改进社区、各角色技能CoP（Community of Practice，实践社区）都是不错的选择。切忌管理层在ETC各种指点江山发号指令，而忘记了团队疾苦，很多改进措施难以落地，团队叫苦连天，时间长了，不仅仅是变革像空中楼阁难以为继，更有甚者倒退回比之前都不如的境地。
场景一：某企业某事业部正在进行从上至下的敏捷转型，作为部门A的基层员工，根本不知道为什么要转型，每天的事情已经够多了，为什么还要多出这么多敏捷转型的讨论和会议？
场景二：经由一些天的头脑风暴和深思熟虑，在大领导的带领下，大家终于下定决心要对现状的短瀑布流程进行彻底变革，用敏捷核心实践来改善目前的产品质量。大家成立了ETC，并建立了改进Backlog，开始跟踪各种事项。作为中层管理干部，你很幸运参与了整个过程。不过你的团队经常对你飚出的一些新词以及那片花花绿绿的改进墙充满了疑惑和好奇，最开始你还解释一下，慢慢的时间长了，你也懒得一遍遍解释，他们也就熟视无睹了。
不管是Mike Cohn提到的ADAPT模型（如图3所示）还是Kotter教授在《 LEADING CHANGE》中提到的变革八部曲（如图4所示），都着重强调了一个“真理”：
每一个成功实施变革的组织都是在多个层次上进行这些活动
这个问题是：大部分变革项目都是由许多小项目组成的，这些小项目同样也需要经过从紧迫感到融入文化这8个步骤（如图4所示），缺一不可。而这是很多变革者最容易忽视的问题之一，他们往往蓄了足够的势，在最高层级用各种手段打开了突破口，找到了同盟军，让关键者动起来了，然而忘记了在下一个层级持续蓄势，或者忘记了教会他们的ETC用同样的方法鼓动底层员工跟着动起来，这也是敏捷转型非常容易失败的一个最关键的因素。
而另一问题是：整个变革项目行至中途，一些小项目完成了，而有的小项目才刚刚开始。不同项目不同团队的状况不一样，需要我们分别对待。
针对这两个问题核心应对措施就是：变革者要不断识别团队或项目处在变革过程中的哪个步骤，在多个层次和层级上反复进行变革措施，并培养更多的变革者，在不同的范围内和层次间不厌其烦地重复变革步骤。
图3 ADAPT模型 Mike Coh
图4 John Kotter’s Change Model-8 Steps 来源：staff.napier.ac.uk
陷阱6：忽视推广和传递，最终臣服于企业重力
最近几年，越来越多的企业管理者终于明白，敏捷转型是在不同的层级上进行的，敏捷变革所取得的成效也与其所能够影响的范围有直接的关联。就像上述陷阱5所讲，如果在IT组织内部不能够持续影响并顾及到多层级效应，就很难做出大的改变取得可观的效果，转型很有可能半路夭折。如果前五个陷阱完美应对过来了，基本可以说转型成功了一半。
为什么是成功了一半呢？其实对于进行敏捷转型的企业组织，只要踏过前五个陷阱，都能够取得不错的成绩，但是还差最后一关，那就是突破IT，向组织内更大范围推广和传播。
“企业重力”是一个很有意思的说法，不同的书籍均有提到相似的概念。这也是沙因对企业文化的解读：
文化 —— 是一个群体在解决外部适应和内容整合的问题时所学到的一套被普遍认可和不言而喻的假设。这些假设在过去运作得足够好，被视为有效的，因而被作为理解、思考和感知这类问题的正确方式传授给这个群体的新成员。 —沙因 《企业文化生存指南》
曾经让这个群体成功的那些思考、感受和看待这个世界的方式就是企业重力，因此敏捷转型的影响必须推得足够远足够广，才不至于使整个转型因为“企业重力”而被拉回到原点。
最经典的例子就是IT部门内部的敏捷转型，如果不连同业务部门，甚至HR、财务、物业等部门，用不了一两年，就会发现改进乏力，这也是《精益企业》中所提倡的，我们要在更大的组织和范围内进行彻底全方位的精益转型，才能让我们在不确定的市场环境中更具有适应性。
也有很多敏捷顾问/敏捷教练或者企业转型者认为只要ETC旗帜一树，正常运作起来，就成功了大半，殊不知这才是刚刚开始，组织转型本身就是九死一生的博弈，Kotter教授也在《LEADING CHANGE》中一开篇就介绍了导致组织转型失败的8种常见错误。
而本文用敏捷转型过程中的ETC作为引子帮大家鉴别领导班子的风格会严重影响组织转型的进展，希望正在做组织转型的你能够在面对ETC团队的各种问题见招拆招。
更多精彩洞见，请关注微信公众号：思特沃克
