在敏捷的初期，往往敏捷開發是在小範圍內進行且專案管理相對簡單。小型的且集中的敏捷團隊管理思想仍然可以在這些情況指導我們完成任務。而如今，因為機遇和環境已經顯著改變，我們希望敏捷開發應用於更廣泛的專案，我們需要更龐大的團隊，為了降低地區經濟和市場領域的風險，同時在全球各個地區展開業務，CEO們希望利用分散式方式組織龐大的敏捷開發團隊；同時，他們還想與其他組織的成為合作伙伴。因此，他們需要遵守法規和行業標準，他們有著顯著的技術或文化環境問題需要克服，他們需要超越單系統的思維方式，真正有效地考慮跨系統的因子 - 團隊規模，地理分佈，合規性，領域的複雜性，技術的複雜性，組織分佈和企業規範。

圖表 XXVI：ASM是DAD模型基礎上面向八個維度拓展

不是每個專案團隊面臨所有這些可變維度帶來的新問題，也沒有任何兩個團隊面臨同一個問題具有相同的嚴重性，但所有這些問題增加了敏捷交付的複雜性。以你的情況，你的DAD敏捷交付過程需要適應新環境，而你必須找到策略來克服這些獨特的挑戰。

團隊規模 –核心敏捷方法能夠很好的工作於十到十五人的團隊，但如果團隊要大得多呢？有五十人，百人，或者一千人？隨著你團隊規模的增長，團隊溝通和協調的會更加困難。書面溝通反而比核心敏捷所提倡的面對面溝通更加有效，或者書面溝通以及面對面的溝通都顯得無力。

地理分佈 – 如果我們的團隊分開來，他們不存在同一間會議室中，他們或許在同一建築物內的不同樓層，或許在同一個城市的不同位置，甚至在不同的國家，這會發生什麼有趣的事情呢？或者你讓你的一些工程師在家工作會又會發生什麼呢？又或當你的團隊成員在不同的時區，又會發生什麼？突然，我們發現有效的協作變得更加具有挑戰性，團隊的聯結被斷開將更有可能發生。

合規性 - 如果行業或地方監管法案出臺，所有的移動裝置均需送檢過關後方能投入運營網路，又或者企業要求所有流程必須合規企業ISO9000認證，請問這些將帶給產品互動過程何程度的影響呢？其實，往往是我們從外部強加的，除了客戶驅動的產品要求外的許多規則、需求增加了團隊的工作流程環節、工作內容。

領域的複雜性 - 有些專案團隊發現自己解決一個非常簡單的問題，如開發資料錄入、查詢應用程式或以資訊公開為主的網站。有時候，問題領域是比較複雜的，如需要監控醫療藥品用品的生物化學工藝或大資料採集、儲存和分析以輔助交通管制決策等。或者，也許情況正在發生迅速變化，如金融系統從前臺轉向後臺，端到端的服務走上電子平臺，需要較高的安全保障和兼顧易用性。有人認為，變化領域內的速度，系統的臨界性，以及商業模式是影響軟體過程中的關鍵因素。更復雜的領域需要更加註重探索和實驗，以降低風險，這其中的活動包括原型驗證，建模和模擬等。

組織分佈 - 有時候，一個專案團隊包括來自不同部門的成員，不同的合作伙伴，或由外部服務公司僱傭、委派的成員。更多的組織上分散的團隊，越有可能的關係將是合同聯結的方式，而不是協作。例如，在一些專案的人雖然在要求，架構，設計，甚至是程式碼上產出，但實際上因為處於安全原因，他們不得訪問原始碼所屬空間，不得獲得資源執行測試，對真正的產品的理解有極大的偏移，且缺乏組織凝聚力，這將大大增加您專案實施的風險。由於缺乏彼此的信任，從而減少合作意願，甚至可能會增加與智慧財產權（IP）鬥爭的風險。因此，許多組織都在努力重新調整他們的人力資源採購流程和與合作伙伴的新合同，以便更好地構建分散式環境中成功的交付產品、解決方案的信任。

技術的複雜性 - 有些應用程式從頭開始，易於提升整體的質量和滿足客戶需求；但如果你的工作與現有的遺留系統和遺留資料來源存在極大的耦合需求，你的產品就有可能變得不完美了。同理，使用一個單一的平臺來建立一個系統，會相對容易；如果你正在構建一個執行時系統又需要在多種平臺上被使用，或兼用幾個不同的技術來構建。這個時候，你一定感到有難度。另一方面，技術複雜度還是相對主觀的因素，例如在敏捷計劃中，每個人針對工作項的複雜度的理解會因為個人經驗和技術水平的不同而不同。換句話說，不同的團隊成員評估同一工作項會有不同的結果，所以針對技術複雜度，我們在思考交付過程時需要一個複雜的解決方案。

組織的複雜性 - 你現有的組織結構和文化可能直接反映了瀑布式交付的價值理念；在組織內採用和推廣敏捷策略的因此增加了難度。更糟的是，你的組織內的不同團隊可能有不同的看法，因為他們認為應該如何工作需要考慮更多其自身的需求。而差異性策略即使是相當有效的，但作為一個整體，因為他們並不是向一個方向努力，因而可能大大增加了您專案的風險，也可能閉門造車般地重複投入資源開發著同一個輪子。

企業規範 - 大多數企業希望利用共同的基礎架構平臺，以降低生產成本，縮短產品上市時間，提高一致性，並促進可持續發展的步伐。如果你的專案團隊只專注於他們的迫切需要，理念和實際就要脫離了。為了充分利用公共平臺和資源，專案團隊需要採取有效的企業架構，企業業務建模，戰略性重用和資源組合。這些學科必須同心協力和更好的提升你的紀律敏捷交付流程。但是，這不是免費的，你的敏捷開發團隊需要招募企業的專業人士– 例如企業架構師和企業資產重用工程師 - 如果不是自己權力範圍內可以調動的資源。該企業的專業人士也需要學習紀律性敏捷交付的方式工作，因為，未來的工作相比於他們在傳統的團隊工作方式非常的不同。

需要指出的是，每個比例因子代表的範圍內的複雜度才是關鍵，而每個專案團隊都將面臨這些複雜性的不同組合。言下之意是，他們將需要調整。實際操作中我們發現前四個比例因子 - 團隊規模，地理分佈，合規性，以及組織分佈 - 是相對簡單的，能夠通過工具，採用適當的技術來解決。而其他四個縮放因子– 領域的複雜性，技術的複雜性，組織複雜性和企業規範 – 則更難解決。許多企業正努力實現（儘管期望如此）。