【51CTO.com快译】如今，敏捷与精益的业务开发方法已经广泛被业界所接受。然而，在大型企业环境中，由于业务的持续增长和整体的复杂性，此类方法的落地与实践远比想象的要麻烦得多。
一份根据1500份反馈资料所得出的《2018年敏捷实践现状》报告显示：只有12%的受访者认为其组织具有较高的敏捷实践能力;其中4%的人认为敏捷实践提高了企业对于市场环境的适应能力；而其他受访者则经历了各种“敏捷转型”的失败与迷茫。
本文将列举组织在敏捷转型过程中，常见的错误与影响。同时，我也会给出一些避免出错的建议，以帮助您最终取得成功。
1. 不关注业务协作和价值
对于那些能够开展敏捷实践的团队而言，他们一般具有高效的沟通与协作能力。为了提供出色的客户体验、产品与服务，组织内各个小组应当根据共同的目标协同工作。而对于那些需要跨职能团队合作的项目，协作无疑会带来不同的专业视角与经验。相比之下，大多数传统企业里的职能团队经常处于孤立工作的状态，这给项目带来了各种潜在的风险。
实施建议
理解和定义价值流
请花一些时间来梳理本企业的客户价值流。您可以问自己如下问题：
- 在客户的心目中，有哪些方式可以提高对于本品牌或产品的认识度?
- 哪些步骤能够顺利促成订单或签署合同?
- 如何能够让客户乐意使用本产品与服务?
因此，我们应当基于上述价值流来组建团队，而不是围绕着那些闭门造车的业务功能不放。
创建跨职能部门的敏捷团队
要想通过敏捷的方式来创造价值，我们就需要在保证各职能部门的专家顺畅沟通的同时，将他们聚集到一个团队里，以获得同样、及时、且全面的信息。在具体实践中，我们重点要将各个业务和技术领域的专业人员组合到产品团队之中，及时解决组织在技术方面遇到的各个常见问题。
为每个团队定义清晰的愿景和目标
根据上述整理的价值流，产品所有者应当为自己所在的团队制定清晰的愿景、以及可以衡量与实现的“小目标”。在实现方式上，我们可以引入一个简单的框架，并采用OKR(Objectives and Key Results，目标与关键成果)方法。另外，项目团队除了将注意力集中在有形的价值交付上之外，还可以把目标设置为确保团队成员之间协调性，以及能够更快、更好地做出决策。相反，不适当地采用敏捷实践，则可能导致大家过度地关注迭代的次数，而无法交付出真正的业务价值。下图列举了各种清晰的愿景与目标。
2. 使用不变的供应商、并以不变的方式与之签约
许多组织并不具备交付出全部服务的技能与能力。因此，它们往往需要与外部供应商建立协作伙伴关系。在传统方式上，供应商是根据招标及报价而遴选出来的。这样保证了他们在固定的时间与预算范围内，能够交付出可预期且固定的成果。
现如今，我们时常会遇到比预期更为复杂且多变的业务需求，这些直接导致了变更需求的频发。与此同时，供应商也随之通过提高报价与加强合同管理等方式，来保护自己免受不可预见性所带来的影响。此时，交付成果不再是他们所重点关注且把控的目标了。可见，我们需要改变与供应商的合作、以及签约方式。
如下图所示，敏捷模型灵活地将传统模型“倒”了过来，它通过评估目标的范围，不断修正成本和时间，从而降低了各种固定因素的束缚。在此基础上所选出的供应商更适合开展协作;与之签署的合同也更具有灵活性。
实施建议
创造信任和谐的目标环境
通过签署开放式合同，双方不再纠结固定的条款，而是能够共同面对意料之外的新情况，通过发挥主观能动性，根据新产生的数据与信息，灵活地进行调整。
在固定的时间和预算范围内保持灵活
在上述时间、预算和范围三个维度上，敏捷的交付方法体现在灵活地就迭代次数、上线时间等达成一致。这使得供应商能够对交付目标排定优先级，根据既定的时间与预算，灵活地进行规划，按需扩展产品团队的人数。
为相同的Backlog分配专属团队
可能您的团队中数据科学家来自某个专门的供应商，Salesforce开发人员是个自由职业者，而后端开发人员是本组织内部人员。当他们处于同一个Backlog时，应保证该团队的专注性，以便他们都能够保持快速且顺畅的沟通、协调的整改节奏、以减少集成中的不确定性和问题的风险。
面对面办公，促进跨职能协作
为了进行有效的跨职能协作与沟通，整个产品团队应该聚到一起办公，或者至少保证每周有几天能够面对面地开展工作。当然，如果您采用的是“分布式敏捷”模式和虚拟化团队合作的话，则应该保证提供良好的通信工具与协作约定。
3. 过度专注敏捷的过程
许多组织花了太多的时间，去规划和谈论他们该采用哪一种敏捷转型方式、使用哪些工具来实现协作、以及该如何构建价值流?对于敏捷转型这样复杂的重大变革而言，虽然我们值得去谨慎对待，但是也不可浪费大量的前期时间。
敏捷方式的初衷就是要把复杂的问题变成一个个小的、可管理的元素，并且以增量的方式实现交付。因此，请不要倒退回传统的瀑布式，逐步交付那些切分后的小元素。
实施建议
做好高层次的定义，但不要拘泥细节
要想实现大规模的敏捷转型，需要采取一些重要的初始化步骤，其中包括：划清范围、愿景、预期成果、及其如何实现价值流，让整个团队在开始阶段就保持一致性的认同。同时，不要奢望能够在项目的一开始就预见到所有的细节、试图解决所有的问题。只要事先做好高层次的定义，就不怕打“遭遇战”。
实践、实践、再实践
抓住一切机会进行敏捷实践。例如：如果您遵循的是Scrum方法，那么每一到两周就需要开展一次例会，并完成一个迭代周期。整个团队可以借此分享经验，评审当前方法的优劣，并着手进行改进。
持续进行回顾
回顾(Retrospectives)对于让您的团队进行持续改进与学习是非常重要的。这是您在团队中进行坦诚讨论的机会。刚开始的时候，大家可能会不太适应，但是只要持之以恒，它将有利于增加敏捷转型所需的透明度与协作文化。
4. 延用传统的领导力方式
对于企业环境中的大多数转型的成败，往往取决于领导力和企业文化。而敏捷则是一种新的理念，它需要不同的管理方法和行为组合。因此，领导者不能仅靠他们在旧技术上的丰富经验，来实现敏捷转型。
通常情况下，领导者需要花费时间去理解和参与到敏捷转型中，而不应该抱有“这只是另一套项目管理方式”的想法。因此，项目的领导者应当认识到自己与整个团队都处于一个共同学习的过程中，通过改变自己的领导风格，自上而下地倡导敏捷文化，才能培养不断试错与迭代的氛围。
实施建议
丢弃传统管理方式
敏捷实践的领导者应当放弃传统的管理方式，从指挥与控制，转变为真正可接受的服务型领导模式。为了减小转变过程所带来的影响，并赢得整个团队的信任，领导者应当成为冷静的问题解决者，并在为团队提供便利的同时，不断消除各种沟通的障碍。
积极支持新的工作方式
在敏捷转型中，另一个重要模式是交付工作中的敏捷性。如果您仍然以项目输出为导向、追求多种备选方案、以及里程碑式的节奏的话，那么这样只会导致传统的“瀑布式”推进过程。而不是真正的敏捷方式。
在游泳中学会游泳
为了保持转型过程处于“健康”态势，敏捷实践的领导者应当不断学习与敏捷相关的理论和资料。同时，他应当在良好的氛围中与团队成员“边干边学”，建立默契。
5. 未执行正确的的转型方式
强拧的瓜不甜，成功的转变也不应当源自强迫。敏捷理论的一项原则是：激发人员的积极性去构建项目，并为他们提供所需的环境和支持，进而信任他们能够完成工作。因此，在项目中，领导者和团队成员需要相互鼓励并建立双向信任。
实施建议
讲述一个让人们理解和信服的故事
贵组织着手开展敏捷转型总是有原因的。也许是新的竞争对手前来“搅局”，您需要通过加快交付实现赶超;也许您有一个令人兴奋的新产品或商业模式，需要快速进行推广;也许您收到了糟糕的客户反馈，需要立即做出反应。不管是上述哪种原因，您都需要自己的团队能够表示理解与认同。
不要低估讲故事的价值，因为它比事实更容易产生情绪上的反馈，更能够帮助个体获得预期的结果。因此，通过故事，您需要能够传递出：转型有什么重要性?个人将如何为成功做出贡献?通过反复讲述，将这些植入并渗透到团队成员的整体意识中。下图列举了各种采取敏捷转型的常见原因。
善用成功的敏捷案例
您可以借用Google、Netflix和Spotify，这些世界一流企业在敏捷实践中的成功商业案例。这些令人信服的案例不但能够促进您的员工予以效仿，而且能够让人从中吸取值得借鉴的经验。
庆祝成功
敏捷转型是一个漫长的过程。而在现实中，可能永远都不会有真正意义上的结束。而且，您的组织可能会持续通过不同的项目来不断寻求改进和优化。毕竟，敏捷迭代的本质就是让团队通过不断的集成，以交付出下一个成果。因此作为领导者，请注意不要错过任何机会，来纪念甚至强调当前转型所体现的价值，同时奖励表现突出的个人或团队。籍此，您既可以识别重要的交付里程碑，又能够给团队带来阶段性的仪式感，以便他们进一步精进相关的领域，就像黑客马拉松(Hackathons)那样。
6. 个人责任和任务的固化
完成敏捷实践的组织普遍具有高效的决策能力。有时候“一线”人员往往会比后台管理层更了解项目当前所处的状态。而冗长的请求审批流程、以及官僚的委员会制度，时常会拖慢项目的进展速度。
实施建议
确保每个人都知道产品所有者的角色及其任务
在完成敏捷实践的组织中，产品所有者通常发挥着重要的作用。他们充当着利益相关者与产品团队之间的缓冲区。组织越大、环境越复杂，他们就越难以平衡、甚至让各方满意。通常情况下，组织应赋予产品所有者相应的特权，让他们协调不同职能、市场和产品部门在转型过程中的优先级，以避免因为冲突而拖延进程，甚至给转型带来严重损害。
降低组织决策者的身份
在传统组织中，组织决策权被掌握在少数管理者的手中。这就造成了各种人员瓶颈、决策耗时、以及团队限权等问题。在敏捷转型中，组织应避免层级结构的约束，允许团队在尊重成员的专业知识和拥有具体信息的前提下，迅速做出各种局部决策。
愿意承担的风险
具有敏捷决策能力的组织通常也能够接受冒险的文化。团队成员只有感到“安全”，才愿意承担自行决策的风险。管理学常说：“真正需要请求的是对于决策后果的宽恕，而不是要请求允许进行决策。”当然，团队成员也必须记下自己当时进行决策的原因，以备事后审查。
原文标题：6 Common Mistakes to Avoid When Implementing Agile at Scale，作者：Andre Azadehdel
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
