Thêm nhiều người để giải quyết cùng một vấn đề chỉ khiến việc giải quyết vấn đề đó trở nên khó khăn hơn. Nhưng nếu bạn đã tìm ra cách để trở nên hiệu quả hơn khi nhóm phát triển tăng trưởng, thì điều đó có nghĩa là bạn đang mở rộng quy mô.
Trong nhiều thập kỷ, Scrum Guide đã thiết lập các nền tảng cơ sở để giúp các nhóm và công ty giải quyết những nhu cầu này. Tuy nhiên, việc mở rộng phạm vi ngoài các nhóm riêng lẻ đòi hỏi một cách tiếp cận khác. Để thực hiện điều này, kỹ thuật Scrum of Scrums – gọi tắt là SoS – đã được tạo ra.
Đọc thêm: Jira là gì? Dùng Jira cho các nhóm Scrum như thế nào?
Lịch sử của Scrum of Scrums
Phương pháp Scrum of Scrums lần đầu tiên được thực hiện vào năm 1996 bởi Jeff Sutherland và Ken Schwaber, hai nhà tiên phong của Scrum Framework. Cả Sutherland và Schwaber đều cần một cách để phối hợp tám đơn vị kinh doanh với nhiều dòng sản phẩm trên mỗi đơn vị kinh doanh và đồng bộ hóa các nhóm riêng lẻ với nhau. Vì vậy, họ đã thử một cách mới để mở rộng quy mô các nhóm scrum nhằm đạt được mục tiêu này. Trải nghiệm này đã truyền cảm hứng cho Sutherland xuất bản một bài báo vào năm 2001 với tiêu đề “Agile Can Scale: Inventing and Reinventing SCRUM in Five Company” (tạm dịch: Agile trong mở rộng quy mô: Phát minh và tái định nghĩa SCRUM tại 5 công ty), lần đầu tiên công khai đề cập đến Scrum of Scrums.
Kể từ đó, Scrum of Scrums ngày càng trở nên phổ biến như một phương pháp kết hợp chặt chẽ với việc mở rộng quy mô nhanh chóng.
Scrum of Scrums là gì?
Scrum of Scrums là một kỹ thuật mở rộng trong Agile nhằm kết nối nhiều nhóm làm việc cùng nhau để giải quyết các bài toán phức tạp.
Nó giúp các nhóm phát triển và bàn giao các sản phẩm phức tạp thông qua nguyên tắc minh bạch, kiểm tra và thích ứng trên quy mô lớn. Sự thành công của phương pháp này được biểu hiện thông qua một Scrum team có hiệu suất cao, nơi các thành viên cùng hướng tới một mục tiêu chung, có sự tin tưởng, tôn trọng và thống nhất.
Để làm được điều này, một trong những điều kiện quan trọng mà chúng ta cần quan tâm là team size (số lượng người trong nhóm). Nghiên cứu từ Hackman và Vidmar cho thấy: về mặt lý thuyết, 4-6 người là “quy mô nhóm hoàn hảo”. Các nhóm quá nhỏ hoặc quá lớn thường gặp khó khăn trong việc bàn giao các sản phẩm phức tạp.
Quy mô nhóm càng lớn thì càng có nhiều mối liên hệ giữa các thành viên trong nhóm, khiến cho việc tạo niềm tin và mục đích chung trở nên khó khăn hơn.
Do đó, chia một nhóm lớn thành hai hoặc ba nhóm nhỏ hơn có thể giúp phát triển các mối quan hệ giữa các thành viên và duy trì kết quả mong muốn.
Hãy cẩn thận khi tách team. Chúng ta cần chú ý đến việc cân bằng kĩ năng giữa các nhóm, tái định nghĩa lại cơ chế giao tiếp của các nhóm và chia nhỏ các công việc một cách cẩn thận. Sự phụ thuộc không mong muốn và các nút thắt cổ chai (bottleneck) có thể xuất hiện và làm chậm quá trình bàn giao sản phẩm. Vì vậy, chúng ta cần tập trung cao độ vào các phiên retrospective và ưu tiên cải tiến các story để vượt qua những thách thức này.
Khi nhiều team được tạo ra với cùng một mục tiêu chung, sự phối hợp hiệu quả là một điều cần thiết, từ đó nảy sinh ra nhu cầu về Scrum of Scrums.
Mục đích của Scrum of Scrums
Scrum of Scrums là một nhóm ảo bao gồm các đại biểu có liên kết với đến các nhóm phát triển ban đầu. So với cấu trúc phân cấp tổ chức thông thường hoặc các nhóm project-based, các cấu trúc nhóm liên kết này sẽ giúp giảm các liên hệ cần có. Mục đích là để điều phối các nhóm nhỏ hơn, độc lập. Các nhóm áp dụng Scrum of Scrums không chỉ phối hợp bàn giao mà còn đảm bảo sản phẩm được tích hợp đầy đủ vào cuối mỗi sprint. Do đó, Scrum of Scrums hoạt động như một nhóm phát hành (release) mang lại giá trị cho khách hàng.
Các tổ chức thường sử dụng cách tiếp cận này như một bước đầu tiên để mở rộng quy mô linh hoạt và tổ chức bàn giao các sản phẩm phức tạp và lớn hơn.
Scrum of Scrums – cấu trúc mở rộng
Nhóm Scrum of Scrums mới được thành lập có các hoạt động gần giống nhau, tham gia vào các sự kiện giống nhau và có các vai trò giống như nhóm Scrum thông thường. Để bàn giao một sản phẩm tích hợp, có khả năng chuyển giao vào cuối mỗi sprint, các team SoS cần có các vai trò bổ sung, chẳng hạn như kiến trúc sư Agile hoặc các QA leader.
Ví dụ, sẽ cần có chức danh: PO (Product Owner) chính. PO chính chịu trách nhiệm giám sát nhóm PO và giúp định hướng tầm nhìn bao quát về sản phẩm.
Vai trò này không cần phải được thực hiện bởi một người có chức danh cao (ví dụ: CTO) và vai trò này nên có trách nhiệm giống như một PO thông thường.
Một vai trò mới khác là SoS Master, người nên tập trung vào tiến độ và các trở ngại khi xử lý backlog mà các nhóm khác có thể nhìn thấy, tạo điều kiện ưu tiên hoặc loại bỏ các trở ngại và liên tục nâng cao hiệu quả của team SoS.
Những vai trò mới này sử dụng 15 phút hàng ngày được chia tỷ lệ như daily scum thông thường để sắp xếp buổi gặp mặt, cải thiện và giải quyết các trở ngại. Đại diện của mỗi nhóm hoặc PO nên thảo luận về những trở ngại của nhóm, rủi ro trong việc đạt được mục tiêu sprint hoặc sự phụ thuộc vào các nhóm khác, sau đó là chia sẻ cải tiến đã được thực hiện để các nhóm khác có thể tận dụng.
Kết luận
Scrum of Scrums được sử dụng rộng rãi và là một cách quan trọng để mở rộng scrum. Điều kiện tiên quyết quan trọng để mở rộng quy mô là điều chỉnh thành phần nhóm phù hợp và cung cấp cho nhóm đủ thời gian và không gian để phát triển thông qua các giai đoạn của mô hình phát triển nhóm của Tuckman:
- Giai đoạn Hình thành (Forming)
- Giai đoạn Sóng gió (Storming)
- Giai đoạn Ổn định (Norming)
- Giai đoạn Hoạt động hiệu quả (Performing)
- Giai đoạn Thoái trào (Adjourning)
Khi các nhóm đã sẵn sàng, đây là một số cân nhắc có thể hữu ích:
- Tổ chức scrum daily mở rộng trong vòng 15 phút, tương tự daily scrum thông thường.
- Tiến hành scrum daily mở rộng trong 15 phút sau daily scrum hàng ngày của nhóm cuối cùng.
- Thiết lập một thỏa thuận làm việc cho team Scrum of Scrums.
- Thống nhất về định nghĩa hoàn thành (Definition of Done) của mỗi cá nhân và tập thể; chia sẻ với mọi thành viên trong team.
- Thiết lập một thói quen hoặc agenda để giữ cho daily scrum mở rộng được tập trung
- Bắt đầu theo dõi số ngày bạn bị block bởi các trở ngại
- Theo dõi xem có daily scrum mở rộng được bắt đầu và hoàn thành đúng thời gian
- Trước tiên, hãy tập trung bàn giao các story có dependencies để giảm thiểu rủi ro và tạo điều kiện cho các nhóm khác.
- Theo dõi và trực quan hóa các ngày làm việc cho đến khi có cuộc họp demo
Nói chung, không có cách nào đúng hoàn toàn để mở rộng quy mô Agile. Nhưng nhiều tổ chức đã thành công trong việc phát triển các quy trình, nhóm và văn hóa của họ bằng cách sử dụng các khuôn khổ để mở rộng quy mô nhanh. Tìm hiểu thêm về các khung Agile được mở rộng quy mô hàng đầu được sử dụng ngày nay và hơn thế nữa tại website của BiPlus: biplus.com.vn
Và Facebook: https://www.facebook.com/AtlassianInVietnam
(Nguồn tham khảo: CHRIS SPANNER/ How to scale scrum/ Atlassian.com)
