Scrum of Scrums là một phương pháp mở rộng rất tự nhiên của Scrum. Thay vì mở rộng nhóm Scrum thành một nhóm lớn hơn; tổ chức duy trì nhóm Scrum vật lý như một thành phần đơn vị và tạo ra sự liên kết giữa những thành phần này thông qua một nhóm Scrum logic.
Hình minh hoạ cho thấy quy mô dự án với 243 nhân sự. Thay vì mở rộng nhóm Scrum thành 243 thành viên (scale out); những nhân sự được tổ chức thành nhiều nhóm Scrum với 9 thành viên mỗi nhóm. Mỗi nhóm Scrum A có 1 thành viên tham gia vào nhóm Scrum ở mức cao hơn để kết nối, đồng bộ, cộng tác công việc giữa các nhóm và hình thành Scrum of Scrums A là Scrum B; mỗi thành viên trong nhóm Scrum B có 1 thành viên tham gia vào nhóm Scrum C ở mức cao hơn để kết nối, đồng bộ, cộng tác công việc giữa các nhóm.
Những nhóm Scrum A chính là một nhóm Scrum tiêu chuẩn với những thành viên luôn làm việc cùng nhau và gắn kết với nhau; tôi gọi là nhóm Scrum vật lý.
Những nhóm Scrum B, Scrum C bao gồm những thành viên không cố định; tôi gọi là nhóm Scrum logic.
Nhóm Scrum vật lý được tổ chức là một nhóm Scrum tiêu chuẩn, tuân theo những vai trò, sự kiện, artifact được định nghĩa trong Scrum guide. Nhóm Scrum logic thì khác và cần một chút lưu ý.
Thứ nhất, nhóm Scrum logic chỉ xác định số thành viên, không xác định thành viên cụ thể. Bởi trong nhóm Scrum tiêu chuẩn, mọi thành viên trong nhóm đều biết điều gì đang xảy ra trong nhóm, những gì đang được thực hiện, những khó khăn gặp phải và tiến độ hiện tại. Do đó, bất kỳ thành viên nào trong nhóm Scrum vật lý đều có thể tham gia nhóm Scrum logic và cung cấp những thông tin như nhau. Nhóm Scrum A thường sẽ không chỉ định An hay Bình sẽ là người tham gia nhóm Scrum B; bởi bất kỳ ai cũng có thể giam gia với hiệu quả như nhau; chế độ quay vòng là một ví dụ. Ngược lại, việc này cũng giúp mọi thành viên trong nhóm có trách nhiệm trong việc quản lý chung công việc của nhóm Scrum A. Tương tự như vậy với nhóm Scrum B.
Thứ hai, nhóm Scrum logic không có nhiều lý do để thực hiện mọi vai trò, sự kiện như nhóm Scrum tiêu chuẩn. Nhóm sẽ chỉ thực hiện nhanh Sprint Planning cũng như Daily Scrum để đồng bộ công việc với nhau, cũng như tìm ra những công việc đang bị block (tắc) khiến lộ trình có thể bị thay đổi. Việc xử lý những khó khăn gặp phải nói chung vẫn là trách nhiệm của nhóm Scrum vật lý.
Để Scrum of Scrums hoạt động hiệu quả, việc giảm sự ràng buộc giữa các nhóm rất quan trọng. Scrum of Scrums không giới hạn việc cộng tác, trao đổi trực tiếp giữa những thành viên khác nhóm; song nếu việc này xảy ra với tần suất cao, hiệu suất cùng khả năng hướng tới Sprint Goal của nhóm Scrum giảm sút do có quá nhiều ràng buộc. Điều này nói thì dễ, song trong một hệ thống lớn cùng một phần cutting edge phức tạp thì không đơn giản. Khi đó vai trò của việc thiết kế cũng như phân rã chức năng trở nên quan trọng.
Để tăng sự độc lập, những nhóm Scrum A được thiết kế là feature team, làm việc trên một sản phẩm hoặc một nhóm chức năng cụ thể. Tôi không rõ nhóm thực hiện Firebase của Google được tổ chức theo phương pháp nào, song dù chia sẻ một tầm nhìn chung về sản phẩm, Firebase Database, Firebase Testlab… vẫn có sự phân mảnh lớn trong cách cấu hình, sử dụng (console hoặc API…) bởi họ được tổ chức theo feature team. Về mặt kiến trúc bạn có thể không hài lòng bởi việc tích hợp giữa những thành phần này không thực sự tự nhiên và nhất quán; song dưới góc độ phát triển sản phẩm, việc này cho hiệu quả cao bởi Google chỉ mất 12 tháng để cho ra đời một tập lớn dịch vụ hữu ích.
Scrum of Scrums cũng vậy, đây là cách mở rộng rất tự nhiên để tổ chức việc phát triển sản phẩm với quy mô lớn theo phương pháp scale up thay vì scale out. Những phương pháp khác hầu như cũng chia sẻ chung tầm nhìn này, nhưng có sự trưởng thành cao hơn (và đương nhiên, phức tạp hơn).
