- Khung agile mở rộng SAFe · Scaled Agile Framework (SAFe)
- Bộ tri thức và khung làm việc do Scaled Agile, Inc. phát triển, giúp tổ chức lớn áp dụng Lean, Agile và DevOps ở cấp đội, cấp chuyến tàu (nhiều đội), cấp giải pháp và cấp danh mục. SAFe đưa ra vai trò, sự kiện và tạo phẩm cụ thể (Agile Release Train, PI Planning, WSJF, Lean Portfolio Management…) để đồng bộ hàng chục đến hàng trăm đội theo cùng nhịp. Điểm mạnh là tính "đóng gói sẵn", dễ triển khai trong doanh nghiệp truyền thống; điểm bị phê bình là khá nặng về cấu trúc, dễ bị áp dụng máy móc nếu thiếu tư duy Lean-Agile.
- Chuyến tàu phát hành agile · Agile Release Train (ART)
- Một "đội của các đội" agile, thường khoảng 50–125 người, tồn tại lâu dài và tổ chức quanh một dòng giá trị (value stream). Các đội trong ART liên chức năng, cùng nhau có đủ năng lực để định nghĩa, xây dựng, kiểm định, phát hành và vận hành giải pháp. ART chạy theo cùng nhịp lặp và cùng Khoảng lập kế hoạch (PI), có chung tầm nhìn, chung backlog cấp ART và các vai trò hỗ trợ: Product Management, System Architect, Release Train Engineer và Business Owners. Câu nói quen thuộc: "đồng thuận càng nhiều thì càng trao được nhiều tự chủ".
- Lập kế hoạch PI · PI Planning
- Sự kiện theo nhịp, thường kéo dài 2 ngày, có mặt toàn bộ ART (lý tưởng là trực tiếp cùng một phòng), do RTE điều phối. Ngày 1: bối cảnh kinh doanh, tầm nhìn sản phẩm, định hướng kiến trúc, rồi các đội lập kế hoạch nháp và trình bày; quản lý xem xét và điều chỉnh phạm vi, nguồn lực trong buổi rà soát quản lý tối. Ngày 2: điều chỉnh kế hoạch, trình bày kế hoạch cuối, xử lý rủi ro theo ROAM, biểu quyết độ tin cậy, có thể lập lại kế hoạch nếu độ tin cậy thấp, rồi cải tiến sự kiện. Đầu ra: mục tiêu PI đã cam kết của các đội và bảng kế hoạch ART.
- Scrum quy mô lớn LeSS · Large-Scale Scrum (LeSS)
- Khung mở rộng do Craig Larman và Bas Vodde phát triển, với quan điểm "LeSS là Scrum" – áp dụng nguyên vẹn Scrum cho nhiều đội cùng làm một sản phẩm, thêm càng ít vai trò, tạo phẩm và quy trình càng tốt ("more with LeSS"). LeSS cơ bản dành cho 2–8 đội (tối đa khoảng vài chục người): một Product Owner, một Product Backlog, một Định nghĩa Hoàn thành (DoD), một Sprint chung và một Increment tích hợp duy nhất mỗi Sprint. LeSS thường đòi hỏi thay đổi cơ cấu tổ chức (đội tính năng, bỏ bớt tầng quản lý trung gian) hơn là thêm quy trình.
- Khung Nexus · Nexus Framework
- Khung mở rộng Scrum do Ken Schwaber và Scrum.org phát triển, dành cho khoảng 3–9 đội Scrum cùng làm một sản phẩm từ một Product Backlog và một Product Owner. Nexus tập trung giải quyết vấn đề lớn nhất khi mở rộng: phụ thuộc và tích hợp giữa các đội. Nó bổ sung một vai trò (Đội tích hợp Nexus), một số sự kiện ở cấp Nexus và các tạo phẩm như Nexus Sprint Backlog, Gia tăng tích hợp (Integrated Increment), nhưng giữ nguyên Scrum ở cấp đội.
- Scrum của các Scrum · Scrum of Scrums (SoS)
- Cấu trúc phối hợp trong đó các đội Scrum (theo Scrum@Scale, tối ưu khoảng 4–5 đội) cử đại diện họp định kỳ để đồng bộ tiến độ, nêu trở ngại liên đội, xử lý phụ thuộc và cùng tạo ra một Increment tích hợp. Trong Scrum@Scale, SoS có Scrum of Scrums Master chịu trách nhiệm về việc phát hành chung và cải tiến hiệu suất của nhóm đội; buổi họp hằng ngày gọi là Scaled Daily Scrum, giới hạn 15 phút. Nhiều SoS có thể hợp thành Scrum of Scrums of Scrums.
- Disciplined Agile · Disciplined Agile (DA)
- Bộ công cụ (toolkit) hỗ trợ ra quyết định về quy trình, do Scott Ambler và Mark Lines phát triển, PMI mua lại năm 2019. DA không áp một quy trình duy nhất mà hướng dẫn đội "chọn cách làm việc" (Choose your WoW) phù hợp ngữ cảnh, dựa trên các mục tiêu quy trình và phương án đi kèm ưu/nhược điểm. DA kết hợp thực hành từ Scrum, Kanban, XP, SAFe, Lean…, có nhiều vòng đời để chọn (agile, lean, giao liên tục, khám phá, chương trình) và các nguyên tắc như "ngữ cảnh quan trọng", "lựa chọn là điều tốt", "tối ưu dòng chảy", "nhận thức doanh nghiệp".
- Phụ thuộc giữa các đội · Cross-Team Dependencies
- Tình huống công việc của một đội không thể xong nếu đội khác chưa giao một phần (API, dữ liệu, môi trường, quyết định…). Phụ thuộc là nguồn chậm trễ và rủi ro lớn nhất khi mở rộng agile. Cách xử lý theo thứ tự ưu tiên: loại bỏ (tái tổ chức thành đội tính năng/đội theo dòng, tách kiến trúc), giảm (giao diện rõ, X-như-một-dịch-vụ), và cuối cùng mới là quản lý (lập bản đồ trên bảng kế hoạch, Scrum of Scrums, Nexus Daily Scrum). Tương ứng với việc xác định quan hệ phụ thuộc bên ngoài khi xác lập trình tự hoạt động trong lập lịch truyền thống.