敏捷转型是一场变革，充满挑战。这场变革是全方位的，不仅是流程，开发方法，还是思想上的。如何让敏捷转型过程变得更容易成功？在这场变革中有哪些关键因素呢？这里我结合自己的一点实践谈一点感想。
1，敏捷领导力培养很关键。人的重要性不言而喻，在敏捷变革这样有挑战的工作中更是如此。变革的成功与否取决于变革关键角色的能力。John. Kotter 的变革加速模型8步法第二步是建立强有力的变革指导联盟。另外在他的八步法中第四步招募志愿团队（见《John Kotter的变革加速模型与敏捷转型实践》）。这些都充分说明了人在变革的关键作用。
由于变革没有先例可循，充满风险和未知挑战，所以敏捷变革中更需要领导力。John.Kotter在论述他的新变革八步法时也谈到过领导力的作用。他说，In order to capitalize on windows opportunity, leadership must be paramount - and not just from one executive. It's about vision. action. innovation and celebration, as well as essential managerial processes (为了充分利用可能的机会窗口，领导力（对任何人）都是至关重要的，它不仅仅是针对某一位高管而言。它也是关于愿景，行动，创新和庆祝变革胜利等等，以及所有基础的管理流程)。
很多公司把敏捷仅仅看作是流程，开发方法的改变，而没有意识到这场变革对于思想的改变，低估了转变的难度。他们大多看重各种敏捷方法，流程，工具的培训，比如Scrum,XP，Lean。但是相对缺乏对于能力，特别是领导力的培养。虽然Scrum中也提到服务型领导力（有兴趣可以参看《看了这个，你就知道什么是领导力了》和《服务型领导力模型》），SAFe把领导力作为基础，但是基本上都是一笔带过，语焉不详。导致在实际执行过程中，很多团队发现Agile/Scrum流程看上去很美，很容易，可是实施过程困难重重。我在学习ACP（Agile Certificate Practitioner）的时候，老师说，你们学习的都是理想状态，理想团队假设下的Agile。但是现实团队，项目，公司环境的种种不完美和限制很多。如果Scrum master缺乏足够的领导力和必要的权威，达成一次sprint目标都很难，更不要说整体敏捷转型了。
我个人在最初领导一个敏捷改进项目的时候，在给团队培训完Scrum的3355之后，就让Scrum master回去做。发现过了一段时间之后，基本没有什么进展。后来我参加了一次团队的回顾会议，死气沉沉，所有人都漫不经心，Scrum master根本无法有效引导大家产生有价值的回顾信息。我才意识到根本原因可能在于Scrum master缺乏会议引导和有效沟通，反馈的技能。有些Scrum master私下向我反映，大家都不怎么听他的话，带团队太费劲了。我想部分原因也是Scrum master既缺乏传统Lead和manager的权威，也不具备Agile所提倡的服务型领导力。所以我后来针对关键角色（Scrum master，PO）增加了相关培训内容，比如情景式领导力，有效沟通和反馈，团队冲突处理等。帮助他们更好地带领团队。
2，关注敏捷能否带来真正价值。敏捷转型的成败取决于是否得到团队和管理层的支持。而能否得到支持的根本在于是否能给团队带来价值。为了敏捷而敏捷，结果只能是失败。
曾经看到过一种论调，只要采用Scrum 3355，把团队变成交叉职能团队（Cross-Function Team），经过一段时间的磨合，团队就变成“自组织”团队了。团队在采用敏捷的过程中间必然会经过一段混乱和生产率下降的阶段，很正常，请大家给予团队耐心和宽容。等以后走上正轨，生产率就自然会提高。但现实情况是，管理层和团队的耐心是有限的！所以必须要尽快让团队看到价值！就像John.Kotter在变革8步法中讲到的，必须有short-term win！
理论上讲，Kubler-Ross的改变曲线揭示了人在改变中必然经历生产力下降的过程。但是作为变革的领导者有责任让这个改变过程更加顺畅，更加短，对生产率的影响减少到最少。因此，我觉得在敏捷转型中，不能只看重速度，和各种形式上的活动，而是要找准团队的薄弱点在哪里，然后分析应该在哪方面引入敏捷的方法加以改进，提高，待取得short-term win后，在团队接受的基础上再慢慢扩大应用范围。逐步达到团队的全面转型。
我在项目开始时就发现大家对于敏捷不是欢迎，而是有点抵触。后来了解到团队其实已经有了一些敏捷的知识和实践，但是效果不佳。所以大家没什么热情。Scrum master也忧心忡忡，担心我会不会又来一轮运动，加重他们的负担。后来我就和Scrum master商量了一条原则：敏捷改进活动绝不能增加团队负担，并且一定要产生价值。所以我们一起分析团队的问题，然后有针对性的引入敏捷实践。所以在基本没有公司高层支持的情况下，能够得到团队配合，一点点向前推进。虽然慢一点，但是这样才能持续把敏捷变革进行下去。
3，建立广泛的联盟对成功很关键。敏捷流程涉及开发，测试，发布等各个团队，需要不同团队，人员的配合，单靠一个人是很难推动完成的。必须建立一个强大的同盟，建立一个强有力的领导团队才能促成。要争取联合所有的stakeholder一起参与。其中得到上层领导的支持非常关键。
我很早就有在团队中搞敏捷改进的想法，虽然找过几个Scrum 团队，做过一些介绍，但是大家没有什么行动。后来我听说公司上层正在推行新的流程，提升工作效率。我就顺势说服部门领导说，敏捷可以帮助提升工作效率。从而获得部门领导的支持，得以同意在部门中由一位manager配合寻找一个试点团队进行。我把这位Manager一起加入变革领导小组。当团队看到有manager加入以后，感到部门很重视，所以团队的积极性也比以前大有提高，试点工作才得以顺利进行。
4，采用渐进地适应性方法。敏捷是一种变革。变革不可能一步到位。曾经有人主张，敏捷在实施时一定要全部采用敏捷的流程，搞大而全。有人提出先僵化，后消化。就像所谓的休克疗法。但这种做法可能真的会导致组织休克。比如，有的团队僵化地直接把以前地开发团队变为自组织团队。但是由于团队（中国的很多开发团队都是如此）没有很好地自我领导和管理能力，自组织变成了无组织。团队一团糟，严重打击了大家的热情。
敏捷的精髓是不断改进和适应。敏捷只提供了一套价值观和基本框架，所谓地一些最佳实践也是别人地实践。一定要根据团队的实际情况进行适应性调整，摸索，才能找到适合本团队的方法。只有经过逐步改进，同时注意培养团队的能力，特别是关键角色（PO, Scrum master）的能力，才能渐进的实现敏捷的转型。
比如Scrum在进行工作分解时，虽然推荐任务的颗粒度为4小时或者8小时。但是在执行过程中，大家反映软件比较复杂，任务比较模糊，一时达不到，所以我们开始就以2天或者3天为最小单位，设置大家可以达到得目标，从而得到了试点团队的认可。以后可以逐步改进嘛。
敏捷转型没有放之四海而皆准的什么最佳实践，也不是各种方法理论的生搬硬套。必须根据本部门，团队的情况进行。总之，如果我们能够坚持以提高人的领导力，敏捷能力为根本，以改善团队的绩效为衡量标准，注意建立广泛的同盟并采用适应性的方法。相信敏捷转型一定可以取得成功！
-------------------
王老西 敏捷实践者，关注敏捷转型和敏捷领导力的研究。欢迎留言一起探讨
网友评论