敏捷开发一千零一问系列之二十一：外部教练还是外部教练？（敏捷开发改进的主体问题）

这是敏捷开发一千零一问系列的第二十一篇。（在这里提问，之一，之二，之三，问题总目录）

问题

这个不是培训课上的问题，而是最近一些电话和微博上的问题。
起源是有客户打来电话，希望不只是听听培训（包括内训），而是希望能有长达十天二十天的现场指导活动，指导企业完成敏捷的部署。虽然这的确是一个很好的商业机会，整体上却不太可行；或者说即使可行，也不是企业想象中的“行”法。最近微博上面关于华为敏捷推广的讨论也间接地揭示了这一点。（华为的讨论是由现在或过去的华为员工发起的，可参考@曾小萌HW 及其微博过程中所涉及的其他人）除了简单的“应该由敏捷开发的主体也就是企业来主导”的直觉外，也说说具体的现实问题。

分析

1. 信息不对称
有两重，一重是外部教练对企业的信息了解甚少，二重是企业对敏捷了解甚少。本人不太认同“互补”的概念，或者说，仅仅由互补，解决不了问题。正像敏捷开发中提倡跨职能团队，教练和企业也应该是个跨职能团队，而不是强分工团队。所以，必须两者合为一体才能解决问题。当然下一个问题，是教练应该去了解企业，还是企业去了解敏捷？这里我们先否定“都要”这个答案，过年的时候如果你问小孩子：“你要苹果还是橘子？”他们都会给出这个答案，我们需要一些更加理性和现实的答案。2. 动机不对称抛开各种高尚的或理想化的思路，必须意识到教练了解企业的动力，远远小于企业了解敏捷的动力。原因何在？因为敏捷毕竟是一种知识，资料公开，体系完整，了解它的难度相对较小，而掌握好它的收益却很大；而“企业的情况”虽然是咨询师必须掌握的，但一则模糊不公开，二则真的“不太值得”掌握（相对敏捷知识而言）。企业其实也潜移默化地理解和支持这一点，比如如果有10天的咨询工作，企业一定不会选择前9天做“调查和分析”，最后1天给出“解决方案”，而是相反。所以主观和客观地分析，都令咨询师其实很难有机会真正深入了解企业。借用敏捷宣言中的语法，一个敏捷咨询师必须客观地承认这一点，并有以下宣言：我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观：
企业学习和理解敏捷 高于 咨询师了解和具体指导企业也就是说，尽管右项有其价值，我们更重视左项的价值。然后在客户惊讶的目光下（“这家伙居然说他不愿意多了解我们的企业现状！”），思考最负责任的做法。

方案

方案1

无论是否有人进行指导，一线人员必须认识到自己才是改进的主体，既是主要的责任人，也是主要的受益人。因此，不能简单被动地按照教练的指令去做，而是要从实际出发，切身融入敏捷改进。具体做法，包括但不限于以下几点：1. 请教练解决实际问题，而不是教授“敏捷实践”比如“请不要教我故事点估算，而是教我如何用故事点估算来度量生产率的提升（这个也是老师您的职责哦）”“请不要教我结对编程，而是教我如何降低测试中发现的缺陷率和整体缺陷成本（你说的结对编程有这个好处的这个）”“请不要教我持续集成，请教我持续交付（我们要的是一个真的放在线上能用的产品，而不是“能通过冒烟测试的”）”……等等。2. 勇敢质疑和挑战教练的实践，并大胆提出自己的设想，发起讨论很多一线人员会“主动处于被动状态”，也就是主动进入不思考，不承担责任的状态，在敏捷开发中需要避免。但从教练的角度，也要认识到自己不是来“维护敏捷权威的”，而是来帮助团队的。在冬吴相对论的其中一期（大约是1年前的，讨论儿童教育的一期）就提到过：“爱要去感受，而不是去控制”，因此教练要去感受队员们正在想什么，为什么这样想，而不是“不，敏捷是这么说的，所以我要控制他们走向敏捷”，这样才可能真正帮助到团队。3. 学习教练的思维方式，而不是实践很多敏捷教练的工作年限并不长，之所以能成为教练多半只是曾经在敏捷开发的外企中工作过而已。所以不能期待其实践能简单移植过来，也不要太期待教练能“根据实际情况灵活变通”（不但当前只有10天的教练时间，而且10天之后地球还要旋转至少十几年），那怎么办呢？要去了解和理解实践背后的思维方式。任何实践，都是成型或不成型的思维方式的产物，向教练询问当时为何要这样做，为何不能那样做，这样做实际收益如何，还见过别的什么做法，曾经否定过什么做法，曾经想尝试什么做法……虽然不能穷其场景而找到一个符合自己当下情况的，但逐渐就能了解前因后果，理解解决这个问题应该怎样思考，从而真正让思想而非实践为我所用，日后就不怕敏捷“水土不服”。这些做法对教练的要求很高，而且并非教练一人的工作，必须是整个团队主动配合才能完成的。
方案2中高层必须认识到自身改进的重要性，而不要简单寄希望于外部力量。最近几次参加培训课的读者一定还能记得解决一个“从来没有听到也搜索不到的敏捷开发问题”所需思考的三个层面（未来有文详细解释），比如“我们的站立会议沉闷散漫，各说各的，开不起来，怎么办？”，答案包括三层：1. 找到一个直接方法，比如国外流行的“迟到罚款箱”之类的东西，有的企业还考核按时结束率之类的。2. 找到生态系统方法，比如先共同估算再开立会，计划会上先估算后分配之类的，确保人们互相了解别人的工作，才有值得交流的内容。3. 找到组织级的方法，比如139团队（师傅为成败负责，所以会主动帮助别人），破除强分工，面向团队进行绩效考核等等，都能打破个体的沉默。前两层基本上一线人员或者最多动用部门经理，问题都可以解决。而第三层组织级方法，泛指那些关于组织架构、绩效考核、部门划分、角色定义相关的方法，都需要上层介入。拥有多年工作经验的软件研发管理者应该都能感觉到：大型软件企业的根本问题，不是研发技术问题，也不是市场销售问题，而是企业组织架构的问题（国家亦然！）。组织级不做改进，仅仅靠敏捷开发自身的实践，很难成功。所以企业的中高层，不能安排好下面的“敏捷开发推进工作”就一走了之，而是要不断倾听来自下层的“组织级要求”，从组织架构到绩效考核，都要倾听。不过，不是机械地盲从敏捷的要求，而是要去理解其背后的管理理念，从更高的层次让整个企业敏捷起来。关于敏捷的一个可怕的事实是：敏捷开发的创立者、培训者、教练者、实践者，几乎都没有大型企业或部门的管理经验！（这不是说“敏捷开发层次低”，而是说“敏捷开发本来就是关于一线工作的”）所以，在组织级推广敏捷的时候，高层领导必须去学习、理解、主导，才能确保敏捷开发能帮助达成企业的商业目标，而不是敏捷做好了，企业倒退了。

方案1+2

综合一下，大致有这么几条应该是必需的1. 无论内外的教练，企业内部都要有人来主导敏捷开发的推广2. 这些人应该上可达企业高层，下可达一线人员，成为利用整个公司力量解决问题的部门。3. 除了人员要内部具备之外，敏捷开发最后不能“文”在企业内部，而是要“化”在企业内部，这需要上下各层对敏捷开发的真正理解。
附1：方案2中的例子问题比较复杂而答案写得很简略，可参考以下内容：1. 敏捷生态系统中关于此问题的讨论：/article/1361547.html2. 松结对编程中关于共同估算的讨论：/article/1362790.html 这是之三，要完全理清头绪，恐怕之一～之四都得看。附2：关于“企业整体敏捷”前面提到了“敏捷开发是关于一线工作的”，其实不然，日后会有一个子系列，关于整体敏捷的，会综合性地描述企业组织级的敏捷思想和方法，预计会发布在“敏捷开发团队管理”系列里边，敬请关注。