在大型企业内，IT领导者正在开发一种新的运营模式，来应对数字化需求。该模型假定，如果团队以持续交付的方式支持数字产品和服务，则应用开发将需要规模化敏捷方法的使用。
在寻求规模化运行敏捷的过程中，许多企业对工具，培训和SAFT等框架进行了大量投资。 但这些投资本身是不够的。在实施和扩展敏捷时，大多数框架，培训和工具忽略或忽视了业务限制——最重要的一个事实就是敏捷团队必须互动的许多合作伙伴，并不理解敏捷。
CEB根据过去五年来从近300个敏捷团队收集的数据，发现敏捷要想在大型企业中取得成果，IT领导者需要解决敏捷团队与三个关键交付合作伙伴：产品负责人、财务主管和交付团队之间的协作性挑战。
挑战1：产品负责人需要培养
尽管业务期望全面数字化，实施数字化项目的实际工作比许多业务领导者想象的，要更加困难。敏捷的大多数解读可以让人以为，一位业务“产品负责人”唯一需要具备的品质是愿意参与，并具备IT项目经验。但这些都是表象，并不是有效产品职责的真正组成。为了规模化运行敏捷，IT领导者需要努力在产品负责人身上打造三个品质：能力、职责和承诺。
能力是指产品负责人能够提供敏捷项目所需的有效的业务领导能力：战略思维，强大的涉众管理和创业型领导力。前两者相对来说比较容易，但创业型领导力更难获得，因为它需要一个敏锐的客户关注度，并倾向于创新思维。领先的企业认识到，可以通过为产品负责人提供能力模型和培训，来构建创业型领导力。
产品负责人还需要明确他们需要执行的职责，以确保敏捷项目的成功。许多敏捷团队将他们业务伙伴对于数字化的热情和他们自身对于如何有效投身于敏捷项目的知识相混淆。领先的IT企业会创建清单，详细说明产品负责人履行职责所需的活动，项目干系人的投入和可交付成果，无论之前的经验如何，都确保结果。
最后，产品负责人必须承诺参与度，并交付业务价值。当IT领导者提供支持，企业的产品负责人可以借此交流最佳实践，提供同行指导和帮助的情况下，最容易构建这样的承诺。
挑战2：遗留融资流程会削弱敏捷目的
传统的IT融资流程在很大程度上被优化，以配合瀑布方法和以项目为中心的交付。规模化敏捷——本质上，迭代和敏捷，以数字产品的持续交付和增强为导向——需要更灵活，更动态的方法来获得资金和资源分配。
更多的IT企业正在尝试与敏捷方案相匹配的其他方案，比如价值流融资，基于团队能力的融资和风险投资融资模式。规模化运行敏捷的能力将要求IT领导者首先了解替代方案的优缺点，并且说服业务和财务领导者对这些替代方案的需求。
领先企业的经验表明，对“敏捷融资”的全面变更并不一定要在一夜之间完成。IT领导者可以尝试使用较旧的和较新的融资模式相组合的方案，以配合项目组合中不同的交付方式和数字化项目类型。这种实验的好处是为业务和财务合作伙伴提供更好的培训，随着企业意识到将风险投资方法应用于概念证明项目，或将价值流融资应用于数字化产品的优势。
挑战3：敏捷必须成为“松散耦合”流程生态系统的一部分
尽管一些企业试图使敏捷普及，但大多数企业将继续使用并从多种交付框架和方法中获益。关键是不要考虑“整体敏捷”，而是考虑如何将敏捷，瀑布，ITIL和其他框架构建成可互操作的“松散耦合”系统。
互操作性的责任从敏捷团队开始。虽然许多敏捷团队专注于“客户的声音”，而很少将重点放在与其他交付团队和IT团队(比如基础设施和安全性)的“协作”上。领先的IT企业将协作分配为一个明确的，团队层面的责任——无论是管理项目中的上游和下游依赖关系，还是描述项目中的“安全用户故事”。强调“协作”的领导者将注意力集中在敏捷与其他团队和框架之间所需要的转化上，这样即使该项目离开开发团队，敏捷的好处也不会丢失。
敏捷“大使”的重要性
当涉及到规模化运行敏捷时，IT领导者(出于好心)通常侧重于传播敏捷的好处，在开发团队中推广变更管理和获得拥护。与直觉相反，当在一个大型公司内规模化运行敏捷时，这些努力实际上可能导致风险，因为合作伙伴并不熟悉用户故事，产品责任方，kanban开发等语言。虽然刚开始进行宣传，也许是有必要的，但是规模化运行敏捷性更多地取决于协作——协作能够确保成果的成功交付。正如许多企业所学到的——虽然是痛苦的——但是成果才是最重要的，而不是严格地遵守方法。
本文转自d1net（转载）