企业中对产品线或者项目组进行敏捷转型改进有多种方式。有一种通常的场景是某些企业中存在着横向职能组织，这种组织自身没有管理权力，但是却要负责对具体的产品线或者项目组进行敏捷转型改进。这种方式改进的特点是敏捷改进的主导方没有强制权力，敏捷改进的接受方不一定完全有意愿拥抱敏捷，但是组织对于改进的目标却有较明确的要求。在这里，我们下一个定义：在企业中，没有强制管理权力的组织，以咨询、培训、指导、教练等协作的方式对具体的产品线或者项目组进行的精益敏捷转型改进，我们姑且称之为服务式敏捷改进。
相信很多业界的敏捷教练或者过程改进人员都在这种场景下在“艰苦卓绝”奋战着。这种场景下一般会面临如下问题：敏捷教练没有强制权力，怎么能顺利推行改进进程？敏捷实践那么多，敏捷教练如何进行各项实践的选择推行呢？如何让团队成员接受并配合敏捷改进的推行呢？改进的时候涉及到各方，敏捷教练如何处理好各方关系？怎样让团队的改进效果可持续提升？针对这些问题，笔者梳理了几条工作中的经验和大家共同探讨交流。
服务式敏捷改进实践之一：问题驱动优于理论驱动。
首先，说右面理论驱动。众所周知，从敏捷宣言产生到现在，一些精益敏捷开发方法已经相当成熟，比如现在流行的SCRUM、精益Kanban、XP等。一些情况下，因为精益敏捷方法已经很成熟，可能很多组织在进行敏捷转型的开始会把整个敏捷方法一次性全量引入到团队，然后马上进行逐项改进，对产品线恨铁不成钢之心拳拳可见。但是这样的话可能存在一些问题，我们往往可能高估了团队对敏捷改进的接受程度。
我们引进敏捷的初衷是更好的提升团队的效率、产能、以价值为导向面向交付。但是团队里面的人经验能力参差不齐，大家对敏捷的理解和接受程度也不一样，如果你是纯粹理论驱动的把敏捷导入，一下子导入的内容较多，团队需要较长的时间来消化，这样团队成员一方面要用新的敏捷理念与过去的工作习惯做斗争，一方面新的敏捷式工作习惯的形成需要时间，再加上服务式改进本身对团队的强制性就较弱，这样可能敏捷方法还没起到成效，团队就会产生“敏捷方法也不那么神奇”，“敏捷方法是不是不适合我们团队”的想法，一旦这个想法产生，那么对于后续的改进工作就会产生较大的不良影响。所以，对于服务式的敏捷改进，理论驱动不太适合。
当然，在这里不是否定理论驱动的敏捷改进方式，很多公司在敏捷改进中会聘请外来的咨询公司，整体大容量导入敏捷方法，以摧枯拉朽之势闪电进行，组织架构、人员、流程制度所有都会大调整，当然执行好的也会立竿见影，但是这种公司自上而下的敏捷改进方式，不属于我们服务式敏捷改进的讨论范畴。（敏捷教练旁白：其实我们也希望敏捷改进都这么搞呀）
那么，对于客观因素限制较多的服务式敏捷改进要怎么入手？一句话，从团队成员的问题入手，要问题驱动，而不是理论驱动。
所谓问题驱动，就是我们在推行敏捷改进的过程中，应该以团队问题为牵引。团队在不同的改进阶段会有不同的问题。比如在一开始会有团队跨地区合作，沟通交流困难；迭代计划会没有估算，都靠拍脑袋等问题；等过了一阶段，可能会有产品版本没有规划等问题。这些问题，都是我们进行敏捷改进的切入点。我们循着问题切入进去以后，从敏捷实践中选取合适的实践对团队进行改进，等有了改进效果团队就会对敏捷改进从持怀疑迷茫的态度转换成支持态度，润物细无声，久而久之整个团队就会慢慢自组织起来。所以，抓住团队的问题是我们进行敏捷改进的前置关键要素。
服务式敏捷改进以解决问题为驱动，而解决问题之道则来源于精益敏捷的实践。简言之，对团队我们不声称推行敏捷，我们是帮助团队来解决问题，通过帮助团队解决了问题来唤起团队的支持和其他各方干系人的慢慢认同。
