Mở đầu — vì sao bài này quan trọng
Khi bạn ôn thi PSM I, có một chủ đề khiến rất nhiều học viên Việt Nam lúng túng: scaling Scrum — tức là chuyện áp dụng Scrum cho nhiều team cùng làm trên một sản phẩm. Lý do lúng túng rất dễ hiểu. Ngoài thị trường, người ta nói về SAFe, LeSS, Nexus, Scrum@Scale như thể đó là "phần nâng cao bắt buộc" của Scrum. Bạn đi phỏng vấn, nhà tuyển dụng hỏi "em biết SAFe không?". Bạn đọc tin tuyển dụng, thấy ghi "ưu tiên ứng viên có kinh nghiệm scaling framework". Thế là bạn mặc định rằng đề thi PSM I cũng sẽ kiểm tra mấy thứ này.
Đây chính là cái bẫy. Đề thi PSM I của Scrum.org bám 100% vào Scrum Guide 2020, và Scrum Guide gần như không nói gì về scaling framework cụ thể. Nếu bạn mang tư duy "SAFe dạy thế này nên đáp án là thế kia" vào phòng thi, bạn sẽ chọn sai một cách rất đáng tiếc — vì các framework scaling thương mại có những khái niệm và vai trò mà Scrum nền tảng không hề có (ví dụ: Release Train Engineer, PI Planning, Program Increment...).
Bài này giúp bạn hiểu đúng góc nhìn của Scrum Guide về scaling, biết "Scrum of Scrums" thực chất là gì và không phải là gì, và quan trọng nhất là biết PSM I muốn bạn trả lời thế nào về chủ đề này. Đây là một bài "overview" — mục tiêu không phải biến bạn thành chuyên gia LeSS hay Nexus, mà giúp bạn không mất điểm oan trong phòng thi và có một bản đồ tư duy rõ ràng.
Khái niệm cốt lõi
Scrum Guide nói gì về scaling?
Câu trả lời ngắn gọn và quan trọng nhất: Scrum Guide 2020 không định nghĩa, không quy định, không khuyến nghị bất kỳ scaling framework nào. Scrum Guide mô tả Scrum cho một Scrum Team — một team duy nhất, thường có quy mô 10 người trở xuống.
Scrum Guide có một câu duy nhất liên quan trực tiếp đến quy mô team:
> "Nếu các Scrum Team trở nên quá lớn, họ nên cân nhắc tổ chức lại thành nhiều Scrum Team gắn kết, mỗi team tập trung vào cùng một sản phẩm. Do đó, các team này nên chia sẻ cùng một Product Goal, Product Backlog và Product Owner."
Hãy đọc kỹ câu này, vì nó chứa toàn bộ "lập trường" của Scrum về scaling. Khi nhiều team cùng làm trên một sản phẩm, Scrum Guide chỉ đặt ra ba ràng buộc nền tảng:
- Một Product Goal duy nhất cho tất cả các team — tất cả cùng hướng về một đích.
- Một Product Backlog duy nhất — không phải mỗi team một backlog riêng rẽ.
- Một Product Owner duy nhất — một người chịu trách nhiệm tối ưu giá trị sản phẩm, dù sản phẩm được nhiều team xây.
"Foundation Scrum" áp dụng cho work của một Scrum Team
Một điểm cốt lõi cho PSM I: Scrum nền tảng (foundational Scrum) được thiết kế cho công việc của một Scrum Team. Tất cả các sự kiện (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective), tất cả các artifact (Product Backlog, Sprint Backlog, Increment) đều được mô tả ở quy mô một team.
Khi bạn scale lên nhiều team, bạn không vứt bỏ nền tảng này. Bạn giữ nguyên nó cho từng team, rồi thêm các cơ chế phối hợp bên trên. Đây là tư duy của hầu hết các scaling framework đúng đắn: scaling không phải là "thay thế Scrum bằng thứ khác", mà là "lặp lại Scrum nhiều lần và thêm lớp điều phối".
Scrum of Scrums (SoS) là gì?
Scrum of Scrums là một kỹ thuật điều phối (scaling technique), không phải là một sự kiện trong Scrum Guide. Hãy ghi nhớ điều này thật chắc: bạn sẽ không tìm thấy chữ "Scrum of Scrums" trong Scrum Guide.
Về bản chất, SoS là một cuộc họp điều phối liên team. Mỗi Scrum Team cử một đại diện (thường là một Developer, không nhất thiết là Scrum Master) tham gia một buổi họp chung. Tại đó, các đại diện đồng bộ thông tin: team mình đã làm gì ảnh hưởng đến team khác, sắp tới sẽ làm gì có liên quan, và đâu là những phụ thuộc (dependencies) hay impediment liên team cần giải quyết.
Một số điểm dễ nhầm:
- SoS không phải là "Daily Scrum phóng to". Daily Scrum là sự kiện của Developers trong một team để inspect tiến độ hướng tới Sprint Goal. SoS là cơ chế giữa các team.
- Người tham gia SoS không bắt buộc là Scrum Master. Nhiều người tưởng "scrum of scrums" nghĩa là "các Scrum Master họp với nhau". Thực ra đại diện hợp lý nhất thường là một Developer hiểu rõ công việc kỹ thuật đang ảnh hưởng liên team.
- SoS chỉ là một trong nhiều kỹ thuật. Nó xuất hiện nhiều trong sách vở và là một ý tưởng kinh điển, nhưng các framework hiện đại như Nexus, LeSS có cách phối hợp riêng.
Các scaling framework phổ biến — chỉ cần biết ở mức "tên gọi"
Cho PSM I, bạn không cần học sâu các framework này. Chỉ cần nhận diện chúng là "framework xây dựng bên trên/quanh Scrum", không phải là Scrum:
- Nexus (do Scrum.org tạo ra) — gom 3–9 Scrum Team thành một "Nexus", thêm một Nexus Integration Team để lo việc tích hợp.
- LeSS (Large-Scale Scrum) — cố gắng giữ Scrum càng "thuần" càng tốt, ít thêm vai trò mới.
- SAFe (Scaled Agile Framework) — framework lớn, nhiều lớp, thêm rất nhiều vai trò và sự kiện không có trong Scrum.
- Scrum@Scale — do Jeff Sutherland phát triển, mở rộng chính ý tưởng Scrum of Scrums một cách có hệ thống.
Nguyên tắc bất biến khi scale
Dù bạn dùng framework nào, có những thứ Scrum Guide khẳng định không thay đổi khi scale:
- Vẫn chỉ có 3 accountabilities: Product Owner, Scrum Master, Developers. Scaling không tạo ra "Chief Product Owner" hay "Super Scrum Master" trong Scrum Guide.
- Vẫn là một Product, một Product Backlog, một Product Owner, một Product Goal.
- Mỗi team vẫn chạy đầy đủ 5 sự kiện và sản xuất ra Increment đáp ứng cùng một Definition of Done chung — vì cuối Sprint, công việc của tất cả các team phải tích hợp thành một Increment có thể release được.
Tình huống thực tế
Ví dụ 1 — Sàn thương mại điện tử ở TP.HCM mở rộng từ 1 lên 4 team
Hãy hình dung "MuaSamViet", một startup thương mại điện tử giả định ở Quận 1, TP.HCM. Ban đầu họ có một Scrum Team 8 người làm app mua sắm. Sau vòng gọi vốn, họ tuyển thêm và cần 4 team để làm nhanh hơn: một team lo Tìm kiếm & danh mục, một lo Giỏ hàng & thanh toán, một lo Giao hàng, một lo Tài khoản người dùng.
Cám dỗ đầu tiên của CTO là cho mỗi team một Product Owner riêng và mỗi team một backlog riêng. Nghe rất "gọn". Nhưng chỉ sau hai Sprint, vấn đề nổ ra: team Thanh toán ưu tiên tính năng mã giảm giá, team Giỏ hàng lại ưu tiên việc khác, không ai biết toàn bộ sản phẩm đang đi về đâu. Bốn backlog mâu thuẫn nhau, cuối Sprint bốn Increment không ghép được thành một bản app chạy được.
Diễn giải: Họ đã vi phạm đúng câu của Scrum Guide — bốn team trên cùng một sản phẩm (app MuaSamViet) thì phải dùng một Product Backlog, một Product Owner, một Product Goal. Họ sửa lại: giữ một Product Owner duy nhất chịu trách nhiệm giá trị toàn sản phẩm, một Product Backlog duy nhất, và đặt một Product Goal chung ("Tăng tỷ lệ hoàn tất đơn hàng từ 62% lên 75% trong quý"). Bốn team vẫn tự quản lý phần việc của mình, nhưng kéo việc từ cùng một backlog.
Bài học rút ra: Scaling không bắt đầu bằng việc thêm cuộc họp hay framework. Nó bắt đầu bằng việc giữ vững ba ràng buộc nền tảng: một PO, một Product Backlog, một Product Goal. Trong phòng thi, nếu gặp câu "5 team cùng làm một sản phẩm thì có mấy Product Owner?", đáp án theo Scrum Guide là một.
Ví dụ 2 — Ngân hàng số dùng Scrum of Scrums để gỡ phụ thuộc
Một ngân hàng số giả định, "TienPhongDigital", có 6 Scrum Team cùng xây dựng app ngân hàng. Vấn đề thường gặp: team API lõi thay đổi một endpoint, ba team khác phụ thuộc vào endpoint đó bị "vỡ" giữa Sprint mà không ai báo trước. Impediment liên team cứ âm ỉ.
Scrum Master các team đề xuất lập một buổi Scrum of Scrums ba lần mỗi tuần, kéo dài 15 phút. Mỗi team cử một Developer am hiểu kỹ thuật làm đại diện (không phải Scrum Master, vì người đại diện cần nói được chi tiết kỹ thuật ảnh hưởng team khác). Buổi họp chỉ xoay quanh ba câu: việc của team tôi sắp tới có ảnh hưởng gì đến team khác không, tôi đang chờ gì từ team khác, và có rào cản liên team nào cần leo thang. Nhờ đó, thay đổi endpoint được báo trước, các team kịp điều chỉnh Sprint Backlog.
Diễn giải: SoS ở đây hoạt động đúng vai trò: một kỹ thuật điều phối giải quyết dependency và impediment liên team. Nó không thay thế Daily Scrum của từng team (mỗi team vẫn có Daily Scrum riêng để hướng về Sprint Goal của mình).
Bài học rút ra: Khi đề thi mô tả "đại diện các team gặp nhau để đồng bộ công việc liên team", hãy nhận ra đó là một kỹ thuật scaling — không phải một sự kiện chính thức của Scrum Guide. Và đại diện không bắt buộc là Scrum Master.
Ví dụ 3 — Công ty gia công phần mềm ngộ nhận "SAFe = Scrum"
"VietSoft Outsourcing", một công ty gia công ở Đà Nẵng, được khách hàng Nhật yêu cầu áp dụng SAFe cho dự án 40 người. Một bạn Scrum Master mới của công ty, đang ôn PSM I, học thuộc cả khái niệm SAFe như "PI Planning", "Release Train Engineer", "ART (Agile Release Train)" và mặc định những thứ này là kiến thức Scrum.
Khi thi thử, bạn gặp câu hỏi: "Theo Scrum Guide, sự kiện nào dùng để lập kế hoạch cho nhiều team trước một 'Program Increment'?" Bạn chọn một đáp án nghe có vẻ liên quan đến "planning lớn". Sai. Vì Scrum Guide không có khái niệm Program Increment, không có sự kiện planning đa team. Đó là khái niệm của riêng SAFe.
Diễn giải: Bạn này lẫn lộn giữa "kiến thức về một framework thương mại" và "kiến thức Scrum theo Scrum Guide". Hai thứ khác nhau. PSM I chỉ kiểm tra cái thứ hai.
Bài học rút ra: Khi vào phòng thi PSM I, hãy "đeo kính Scrum Guide". Bất cứ vai trò, sự kiện, artifact nào không có trong Scrum Guide (Release Train Engineer, PI Planning, Chief Product Owner, Program Increment...) đều không phải là Scrum. Kiến thức SAFe của bạn vẫn quý ngoài đời, nhưng đừng để nó "lái" đáp án trong phòng thi.
Hướng dẫn từng bước
Đây là cách tiếp cận một câu hỏi PSM I liên quan đến scaling, theo từng bước:
- Xác định đề đang hỏi về một team hay nhiều team. Phần lớn câu hỏi PSM I là về một Scrum Team. Nếu đề nói "nhiều team trên cùng một sản phẩm", chuyển sang tư duy scaling.
- Áp ngay ba ràng buộc nền tảng. Nhiều team cùng một sản phẩm = một Product Owner, một Product Backlog, một Product Goal. Câu hỏi về "mấy PO / mấy backlog" gần như luôn có đáp án là "một".
- Kiểm tra Definition of Done chung. Cuối Sprint, công việc của tất cả các team phải tích hợp thành một Increment đáp ứng cùng một DoD. Nếu đáp án ngụ ý mỗi team có DoD riêng rẽ và không tích hợp được, hãy nghi ngờ.
- Nhận diện thuật ngữ "ngoài Scrum Guide". Nếu đáp án chứa thuật ngữ của SAFe/Nexus/LeSS mà Scrum Guide không có, và câu hỏi đang hỏi "theo Scrum Guide", thì đáp án đó thường sai.
- Phân biệt sự kiện chính thức với kỹ thuật. "Scrum of Scrums" là kỹ thuật, không phải sự kiện. Daily Scrum, Sprint Review... là sự kiện. Đừng để đề đánh tráo.
- Chọn đáp án "tối giản và đúng nguyên tắc". Khi phân vân, đáp án bám sát đúng nguyên tắc nền tảng của Scrum Guide (minimal, empirical, một team tự quản lý) thường là đáp án đúng.
Lỗi thường gặp & mẹo
Lỗi 1 — Tưởng Scrum of Scrums là sự kiện trong Scrum Guide. Không phải. Nó là kỹ thuật điều phối liên team. Scrum Guide không nhắc đến nó.
Lỗi 2 — Tưởng đại diện Scrum of Scrums phải là Scrum Master. Sai. Thường là một Developer hiểu rõ phần việc kỹ thuật đang ảnh hưởng liên team.
Lỗi 3 — Cho mỗi team một Product Owner và một Product Backlog riêng. Đây là vi phạm trực tiếp Scrum Guide khi các team làm chung một sản phẩm. Một sản phẩm = một PO, một backlog, một Product Goal.
Lỗi 4 — Mang kiến thức SAFe/LeSS vào làm "chân lý Scrum". PSM I chỉ kiểm tra Scrum Guide. Thuật ngữ riêng của framework thương mại không phải Scrum.
Lỗi 5 — Nghĩ rằng scale lên thì bỏ bớt sự kiện cho gọn. Ngược lại. Mỗi team vẫn giữ đầy đủ 5 sự kiện. Scaling thêm cơ chế phối hợp bên trên, không cắt xén nền tảng.
Lỗi 6 — Tin rằng Scrum Guide "ưu tiên" một scaling framework cụ thể. Scrum Guide trung lập hoàn toàn. Nó chỉ nêu nguyên tắc tổ chức lại thành nhiều team chia sẻ chung PO/Backlog/Goal, không gọi tên framework nào.
Mẹo ghi nhớ: Hãy nhớ cụm "Một sản phẩm — Một PO — Một Product Backlog — Một Product Goal — Một DoD tích hợp". Năm chữ "Một" này gói gọn 90% câu hỏi scaling ở PSM I. Và nhớ tách bạch: sự kiện (Scrum Guide có) vs kỹ thuật như Scrum of Scrums (Scrum Guide không có).
Bài tập thực hành
Hãy tự trả lời (rồi đối chiếu với nguyên tắc đã học):
- Công ty bạn có 5 Scrum Team cùng xây một sản phẩm. Theo Scrum Guide, họ nên có bao nhiêu Product Owner, bao nhiêu Product Backlog, bao nhiêu Product Goal? Vì sao?
- Một đồng nghiệp nói: "Scrum of Scrums là Daily Scrum dành cho các Scrum Master." Câu này sai ở mấy điểm? Hãy chỉ ra từng điểm.
- Trong phòng thi, bạn gặp đáp án nhắc đến "Release Train Engineer điều phối các team". Theo Scrum Guide, đáp án này đúng hay sai? Giải thích bằng nguyên tắc "đeo kính Scrum Guide".
- Tại sao khi scale lên nhiều team, tất cả vẫn phải chia sẻ một Definition of Done chung? Liên hệ với việc tích hợp Increment cuối Sprint.
- Tự viết một câu giải thích (2–3 dòng) cho sếp của bạn về lý do "không nên tách mỗi team một backlog riêng" khi cùng làm một sản phẩm — dùng đúng ngôn ngữ Scrum Guide.
Tóm tắt
- Scrum Guide 2020 không quy định bất kỳ scaling framework nào. Scrum nền tảng được mô tả cho một Scrum Team.
- Khi nhiều team cùng làm một sản phẩm, Scrum Guide chỉ đặt ba ràng buộc: một Product Owner, một Product Backlog, một Product Goal — cộng thêm một Definition of Done chung để Increment tích hợp được.
- Scrum of Scrums là một kỹ thuật điều phối liên team, không phải sự kiện trong Scrum Guide. Đại diện tham gia không bắt buộc là Scrum Master, thường là một Developer.
- Các framework như Nexus, LeSS, SAFe, Scrum@Scale là những cách tổ chức bên trên/quanh Scrum — chúng không phải là Scrum theo Scrum Guide. Thuật ngữ riêng của chúng (PI Planning, Release Train Engineer, Program Increment...) không xuất hiện trong đề PSM I như "kiến thức Scrum".
- Khi làm bài thi: "đeo kính Scrum Guide", áp năm chữ "Một", và tách bạch sự kiện với kỹ thuật. Đó là cách an toàn nhất để không mất điểm oan ở chủ đề scaling.