在大型企業內，IT領導者正在開發一種新的運營模式，來應對數字化需求。該模型假定，如果團隊以持續交付的方式支持數字產品和服務，則應用開發將需要規模化敏捷方法的使用。
在尋求規模化運行敏捷的過程中，許多企業對工具，培訓和SAFT等框架進行了大量投資。 但這些投資本身是不夠的。在實施和擴展敏捷時，大多數框架，培訓和工具忽略或忽視了業務限制——最重要的一個事實就是敏捷團隊必須互動的許多合作伙伴，并不理解敏捷。
CEB根據過去五年來從近300個敏捷團隊收集的數據，發現敏捷要想在大型企業中取得成果，IT領導者需要解決敏捷團隊與三個關鍵交付合作伙伴：產品負責人、財務主管和交付團隊之間的協作性挑戰。
挑戰1：產品負責人需要培養
盡管業務期望全面數字化，實施數字化項目的實際工作比許多業務領導者想象的，要更加困難。敏捷的大多數解讀可以讓人以為，一位業務“產品負責人”唯一需要具備的品質是愿意參與，并具備IT項目經驗。但這些都是表象，并不是有效產品職責的真正組成。為了規模化運行敏捷，IT領導者需要努力在產品負責人身上打造三個品質：能力、職責和承諾。
能力是指產品負責人能夠提供敏捷項目所需的有效的業務領導能力：戰略思維，強大的涉眾管理和創業型領導力。前兩者相對來說比較容易，但創業型領導力更難獲得，因為它需要一個敏銳的客戶關注度，并傾向于創新思維。領先的企業認識到，可以通過為產品負責人提供能力模型和培訓，來構建創業型領導力。
產品負責人還需要明確他們需要執行的職責，以確保敏捷項目的成功。許多敏捷團隊將他們業務伙伴對于數字化的熱情和他們自身對于如何有效投身于敏捷項目的知識相混淆。領先的IT企業會創建清單，詳細說明產品負責人履行職責所需的活動，項目干系人的投入和可交付成果，無論之前的經驗如何，都確保結果。
最后，產品負責人必須承諾參與度，并交付業務價值。當IT領導者提供支持，企業的產品負責人可以借此交流最佳實踐，提供同行指導和幫助的情況下，最容易構建這樣的承諾。
挑戰2：遺留融資流程會削弱敏捷目的
傳統的IT融資流程在很大程度上被優化，以配合瀑布方法和以項目為中心的交付。規模化敏捷——本質上，迭代和敏捷，以數字產品的持續交付和增強為導向——需要更靈活，更動態的方法來獲得資金和資源分配。
更多的IT企業正在嘗試與敏捷方案相匹配的其他方案，比如價值流融資，基于團隊能力的融資和風險投資融資模式。規模化運行敏捷的能力將要求IT領導者首先了解替代方案的優缺點，并且說服業務和財務領導者對這些替代方案的需求。
領先企業的經驗表明，對“敏捷融資”的全面變更并不一定要在一夜之間完成。IT領導者可以嘗試使用較舊的和較新的融資模式相組合的方案，以配合項目組合中不同的交付方式和數字化項目類型。這種實驗的好處是為業務和財務合作伙伴提供更好的培訓，隨著企業意識到將風險投資方法應用于概念證明項目，或將價值流融資應用于數字化產品的優勢。
挑戰3：敏捷必須成為“松散耦合”流程生態系統的一部分
盡管一些企業試圖使敏捷普及，但大多數企業將繼續使用并從多種交付框架和方法中獲益。關鍵是不要考慮“整體敏捷”，而是考慮如何將敏捷，瀑布，ITIL和其他框架構建成可互操作的“松散耦合”系統。
互操作性的責任從敏捷團隊開始。雖然許多敏捷團隊專注于“客戶的聲音”，而很少將重點放在與其他交付團隊和IT團隊(比如基礎設施和安全性)的“協作”上。領先的IT企業將協作分配為一個明確的，團隊層面的責任——無論是管理項目中的上游和下游依賴關系，還是描述項目中的“安全用戶故事”。強調“協作”的領導者將注意力集中在敏捷與其他團隊和框架之間所需要的轉化上，這樣即使該項目離開開發團隊，敏捷的好處也不會丟失。
敏捷“大使”的重要性
當涉及到規模化運行敏捷時，IT領導者(出于好心)通常側重于傳播敏捷的好處，在開發團隊中推廣變更管理和獲得擁護。與直覺相反，當在一個大型公司內規模化運行敏捷時，這些努力實際上可能導致風險，因為合作伙伴并不熟悉用戶故事，產品責任方，kanban開發等語言。雖然剛開始進行宣傳，也許是有必要的，但是規模化運行敏捷性更多地取決于協作——協作能夠確保成果的成功交付。正如許多企業所學到的——雖然是痛苦的——但是成果才是最重要的，而不是嚴格地遵守方法。
京公網安備 11010502049343號