Mở đầu — vì sao bài này quan trọng
Khi bạn còn là Scrum Master cho một team duy nhất, thế giới khá gọn gàng: một Product Backlog, một Product Owner, một nhóm người ngồi cùng nhau (hoặc cùng họp online), và mọi sự phối hợp gói gọn trong bốn bức tường của team đó. Nhưng đời thực hiếm khi dừng lại ở một team. Sản phẩm lớn lên, công ty thuê thêm người, và rất nhanh bạn sẽ thấy hai, ba, năm team cùng "đụng tay" vào một sản phẩm.
Đây chính là điểm mà rất nhiều Scrum Master vấp ngã — và cũng là một trong những chủ đề được hỏi nhiều nhất trong kỳ thi PSM II. Lý do là vì khi có nhiều team, bản năng tự nhiên của tổ chức là "chia để trị": mỗi team một backlog riêng, mỗi team một PO riêng, mỗi team một định nghĩa "xong" riêng. Nghe thì hợp lý, nhưng nó âm thầm phá vỡ chính bản chất của Scrum và biến sản phẩm thống nhất thành một mớ phân mảnh.
Bài học này giúp bạn nắm vững lập trường (stance) của Scrum Guide về nhiều team làm chung một sản phẩm, hiểu vì sao lập trường đó không phải là sự cứng nhắc mà là một thiết kế có chủ đích, và quan trọng nhất: biết cách điều phối (coordinate) công việc giữa các team mà không sa vào kiểm soát tập trung kiểu cũ. Lưu ý: bài này tập trung vào động lực và nguyên tắc khi nhiều team chia sẻ một sản phẩm. Các framework scaling cụ thể như Nexus, LeSS, SAFe sẽ được mổ xẻ riêng ở các bài sau.
Khái niệm cốt lõi
Lập trường của Scrum Guide: bốn cái "MỘT"
Scrum Guide 2020 nói rất rõ một điều thường bị bỏ qua: "Nếu nhiều Scrum Team cùng làm việc trên một sản phẩm, họ chia sẻ chung một Product Goal, một Product Backlog, và một Product Owner." Hãy ghi nhớ bốn cái "MỘT" này như xương sống của toàn bài:
Một Product Backlog (một backlog sản phẩm). Dù có bao nhiêu team, sản phẩm chỉ có một danh sách công việc duy nhất, được sắp xếp thứ tự ưu tiên thống nhất. Đây là điểm gây sốc nhất với người mới: "Ủa, 5 team mà chỉ một backlog thì làm sao mỗi team biết làm gì?". Câu trả lời là: các team kéo (pull) công việc từ cùng một backlog đó, chứ không phải mỗi team sở hữu một backlog riêng. Một backlog đảm bảo rằng việc quan trọng nhất với sản phẩm luôn được làm trước, bất kể nó "thuộc về" team nào.
Một Product Goal (một mục tiêu sản phẩm). Tất cả các team đều chèo về cùng một đích. Product Goal là cam kết (commitment) gắn với Product Backlog, là trạng thái tương lai của sản phẩm mà mọi người cùng hướng tới. Nhiều team mà mỗi team đuổi theo một mục tiêu khác nhau thì đó không còn là "một sản phẩm" nữa — đó là nhiều dự án bị buộc chung tên gọi.
Một Product Owner (một chủ sản phẩm). Đây là điểm gây tranh cãi nhất. Scrum Guide khẳng định một sản phẩm có một PO chịu trách nhiệm tối đa hóa giá trị. Người này có thể (và thường nên) ủy quyền việc làm rõ chi tiết backlog cho người khác, nhưng trách nhiệm giải trình về thứ tự ưu tiên và giá trị không bị chia năm xẻ bảy. Khi mỗi team có một "PO" riêng tự quyết ưu tiên, bạn sẽ có những team kéo nhau theo các hướng mâu thuẫn.
Một Definition of Done được định nghĩa chung (shared DoD). Khi nhiều team cùng tích hợp công việc vào một sản phẩm, họ phải tuân theo cùng một Definition of Done — hoặc ít nhất một DoD chung tối thiểu mà mọi Increment phải đạt. Nếu team A coi "xong" là code chạy được trên máy mình, còn team B coi "xong" là đã test tích hợp đầy đủ, thì khi ghép hai phần lại, "Increment" của bạn không thực sự dùng được. DoD chung chính là hợp đồng chất lượng giữ cho sản phẩm luôn ở trạng thái có thể release.
Vì sao thiết kế này quan trọng — không phải là giáo điều
Bốn cái "MỘT" không phải để làm khó bạn. Chúng tồn tại để bảo vệ một thứ duy nhất: tính minh bạch và sự thống nhất của sản phẩm. Mục tiêu cuối của Scrum là tạo ra một Increment tích hợp được, có thể release, ít nhất một lần mỗi Sprint. Khi nhiều team làm việc, rủi ro lớn nhất không phải là "team này code chậm", mà là "các mảnh ghép không khớp nhau". Bốn cái "MỘT" chính là cơ chế chống phân mảnh.
Điều phối (Coordination), không phải kiểm soát (Control)
Đây là sự chuyển dịch tư duy then chốt của bài. Khi có nhiều team, sếp thường muốn dựng một lớp "quản lý dự án" ở trên để điều phối — kiểu cũ gọi là command-and-control. Nhưng Scrum đi theo hướng ngược lại: điều phối nên xuất phát từ chính các team (self-coordination), thông qua những cơ chế nhẹ:
- Sự phụ thuộc (dependencies) được làm cho minh bạch trên cùng một backlog, để các team tự nhìn thấy và tự thương lượng.
- Refinement chung giữa các team để chia nhỏ và phân bổ công việc sao cho giảm phụ thuộc.
- Các "đại sứ" (ambassadors / scrum of scrums) — đại diện của mỗi team gặp nhau định kỳ để đồng bộ, không phải để báo cáo lên cấp trên.
- Một Increment tích hợp chung mỗi Sprint — đây là "chốt kiểm tra thực tế" mạnh nhất: nếu các team không khớp nhau, việc tích hợp sẽ phơi bày ngay lập tức.
Tình huống thực tế
Tình huống 1 — Tiki và "ba PO ba hướng"
Giả định một bối cảnh quen thuộc ở các công ty công nghệ Việt Nam: một sàn thương mại điện tử cỡ Tiki mở rộng mảng "trang chủ và tìm kiếm sản phẩm" từ một team lên ba team (đặt tên là Web, Mobile, và Search). Vì muốn "mỗi team tự chủ", ban đầu họ giao mỗi team một Product Owner riêng, mỗi PO một backlog riêng.
Sau ba Sprint, vấn đề lộ ra: team Search xây một bộ lọc sản phẩm rất mạnh, nhưng team Web lại đang ưu tiên làm lại banner khuyến mãi và chưa hề chừa chỗ cho bộ lọc mới trên giao diện. Team Mobile thì hiểu "ưu tiên" theo cách thứ ba. Kết quả: ba mảnh việc ngốn hàng trăm giờ công nhưng không ghép lại thành một trải nghiệm tìm kiếm hoàn chỉnh cho khách. Mỗi PO đều "đúng" theo backlog của mình, nhưng sản phẩm thì sai.
Diễn giải: Đây chính là cái giá của việc vi phạm "một PO, một backlog, một Product Goal". Khi không có một người chịu trách nhiệm tối đa hóa giá trị toàn sản phẩm, các ưu tiên cục bộ sẽ xung đột mà chẳng ai phát hiện cho đến khi ghép sản phẩm lại.
Cách Scrum Master xử lý: SM đề xuất hợp nhất về một PO duy nhất cho toàn bộ trải nghiệm "Discovery", giữ lại ba người cũ làm "PO Proxy" / chuyên gia lĩnh vực hỗ trợ làm rõ backlog — nhưng quyền quyết thứ tự ưu tiên cuối cùng thuộc về một người. Họ gộp ba backlog thành một, đặt một Product Goal chung là "Khách tìm thấy sản phẩm họ muốn trong dưới 3 lần chạm". Hai Sprint sau, các xung đột ưu tiên gần như biến mất vì ai cũng nhìn vào cùng một danh sách đã được xếp hạng.
Bài học rút ra: "Tự chủ của team" không có nghĩa là "mỗi team một sản phẩm con". Tự chủ nằm ở cách team làm việc, không phải ở việc quyết định cái gì quan trọng nhất cho sản phẩm.
Tình huống 2 — Fintech ở Singapore và DoD lệch chuẩn
Một công ty fintech tại Singapore (gọi là PayFlow) có 4 team cùng xây nền tảng thanh toán. Mỗi team có DoD riêng. Team Core Payments coi "Done" bao gồm cả kiểm thử bảo mật và test tích hợp. Team Notifications, vì áp lực tiến độ, định nghĩa "Done" chỉ là "đã merge và test đơn vị (unit test) pass".
Đến cuối quý, khi ghép để release một tính năng chuyển tiền xuyên biên giới, đội vận hành phát hiện module Notifications gửi thông báo sai số tiền trong điều kiện đồng thời (race condition) — lỗi mà team Core Payments hẳn đã bắt được nếu có test tích hợp. Sự cố làm trễ release ba tuần và phải giải trình với cơ quan quản lý (MAS).
Diễn giải: Khi nhiều team đóng góp vào một Increment chung, DoD yếu nhất sẽ kéo chất lượng cả sản phẩm xuống. Một chuỗi xích chỉ mạnh bằng mắt xích yếu nhất. Nếu không có DoD chung tối thiểu, "Done" của team này thực ra chỉ là "có vẻ xong".
Cách Scrum Master xử lý: Các SM của 4 team tổ chức một buổi workshop chung để cùng định nghĩa một DoD nền tảng áp dụng cho mọi team (gồm test tích hợp, quét bảo mật, và kiểm tra ngưỡng hiệu năng). Mỗi team vẫn được phép thêm tiêu chí khắt khe hơn cho riêng mình, nhưng không được nới lỏng dưới mức chung.
Bài học rút ra: DoD chung không phải là sự áp đặt từ trên xuống — nó nên được các team cùng định nghĩa (mutually-defined). Nhưng một khi đã thống nhất, nó là sàn chất lượng không ai được phá.
Tình huống 3 — Startup VNG game studio và sự phụ thuộc ẩn
Một studio game thuộc một công ty lớn như VNG có 3 team: Gameplay, Economy (hệ thống vật phẩm/tiền tệ trong game), và Live-Ops (sự kiện theo mùa). Họ giữ đúng một backlog, một PO, một Product Goal — rất chuẩn. Nhưng họ vẫn liên tục trễ vì phụ thuộc chéo: tính năng sự kiện của Live-Ops cần API từ Economy, mà Economy lại đang dồn sức cho việc khác.
Trong Sprint Planning, mỗi team chỉ nhìn phần việc của mình nên không ai thấy được "nút thắt cổ chai". Đến giữa Sprint, Live-Ops bị kẹt vì chờ Economy.
Diễn giải: Có đủ bốn cái "MỘT" là điều kiện cần, nhưng chưa đủ. Phụ thuộc giữa các team là kẻ thù lớn nhất của việc giao hàng đúng hẹn. Nếu phụ thuộc không được làm minh bạch trước khi Sprint bắt đầu, nó sẽ nổ ra giữa Sprint.
Cách Scrum Master xử lý: SM giới thiệu một buổi Refinement chung liên team trước mỗi Sprint, nơi đại diện 3 team cùng nhìn vào các hạng mục backlog sắp tới và vẽ ra các đường phụ thuộc. Những hạng mục có phụ thuộc chéo được sắp xếp lại thứ tự để phần "nền" (API của Economy) được làm trước. Họ cũng lập một "scrum of scrums" 15 phút, ba lần một tuần, để các đại diện đồng bộ tiến độ phụ thuộc.
Bài học rút ra: Phối hợp nhiều team không phải là "họp nhiều hơn", mà là làm phụ thuộc trở nên nhìn thấy được và thiết kế công việc để giảm phụ thuộc ngay từ khâu refinement.
Hướng dẫn từng bước
Khi bạn được giao làm Scrum Master cho một bối cảnh nhiều team trên một sản phẩm, đây là lộ trình thực tế:
- Xác minh bốn cái "MỘT". Đặt câu hỏi thẳng: Chúng ta có một Product Backlog không? Một Product Goal không? Một Product Owner chịu trách nhiệm cuối cùng không? Một DoD chung không? Bất kỳ câu trả lời "không" nào cũng là điểm cần xử lý đầu tiên, vì nó là gốc rễ của phần lớn rối loạn.
- Hợp nhất backlog, làm cho ưu tiên minh bạch. Nếu đang tồn tại nhiều backlog, hãy giúp PO gộp về một, sắp xếp theo giá trị toàn sản phẩm. Các team kéo việc từ đây.
- Cùng định nghĩa DoD chung tối thiểu. Tổ chức workshop có mặt đại diện kỹ thuật của tất cả các team. Mục tiêu: một sàn chất lượng mà mọi Increment phải vượt qua. Team mạnh hơn được phép khắt khe hơn, nhưng không ai dưới sàn.
- Vẽ bản đồ phụ thuộc trong Refinement chung. Trước Sprint, cho các đại diện cùng nhìn các hạng mục sắp làm và đánh dấu phụ thuộc chéo. Sắp xếp lại để phần nền tảng đi trước. Tốt hơn nữa: chia nhỏ công việc sao cho mỗi hạng mục một team làm được trọn vẹn (giảm phụ thuộc về mức tối thiểu).
- Thiết lập cơ chế đồng bộ nhẹ. Một "scrum of scrums" hoặc cuộc đồng bộ ngắn của các đại diện, đủ tần suất để bắt sớm các nút thắt. Nhấn mạnh: đây là nơi team tự điều phối, không phải nơi báo cáo lên sếp.
- Bảo vệ một Increment tích hợp mỗi Sprint. Đẩy mạnh tích hợp liên tục. Mỗi Sprint phải tạo ra một Increment ghép từ tất cả các team, đã đạt DoD chung. Đây là phép thử thật nhất cho việc các team có thực sự khớp nhau hay không.
- Dùng một Sprint Review chung. Thay vì mỗi team review riêng, hãy hướng tới một buổi review thể hiện Increment tích hợp trước stakeholder. Điều này củng cố tư duy "một sản phẩm".
Lỗi thường gặp & mẹo
Lỗi: "Mỗi team một PO cho tự chủ." Đây là cái bẫy phổ biến nhất ở Việt Nam vì nghe rất tiến bộ. Hệ quả là ưu tiên xung đột. Mẹo: phân biệt rõ giữa trách nhiệm tối đa hóa giá trị (một PO) và công việc làm rõ chi tiết backlog (có thể ủy quyền cho nhiều PO Proxy / chuyên gia).
Lỗi: Mỗi team một DoD riêng. Dẫn đến Increment "giả xong". Mẹo: DoD chung là hợp đồng chất lượng. Định nghĩa nó cùng nhau, nhưng coi nó là sàn không thể nới.
Lỗi: Coi điều phối là việc của một "Project Manager" ở trên. Điều này tái lập command-and-control và giết chết tự tổ chức. Mẹo: để điều phối nảy sinh từ chính các team qua refinement chung và đồng bộ ngang hàng.
Lỗi: Bỏ qua phụ thuộc cho đến giữa Sprint. Mẹo: làm phụ thuộc minh bạch trước Sprint, và ưu tiên thiết kế công việc để giảm phụ thuộc thay vì chỉ quản lý nó.
Lỗi: Không bao giờ tích hợp cho đến cuối quý. Tích hợp muộn là nơi mọi rủi ro tích tụ và nổ. Mẹo: tích hợp mỗi Sprint, lý tưởng là liên tục hàng ngày.
Mẹo về số lượng team: Một PO có thể quản lý ưu tiên cho khoảng 3–5 team là hợp lý. Vượt quá, hãy cân nhắc một framework scaling chính thức (sẽ học ở các bài Nexus, LeSS, SAFe) thay vì tự chế.
Bài tập thực hành
- Kiểm toán bốn cái "MỘT". Với một sản phẩm nhiều team bạn biết (nơi bạn làm hoặc một tình huống giả định), trả lời từng câu: Có một backlog? Một Product Goal? Một PO chịu trách nhiệm cuối? Một DoD chung? Ghi ra điểm nào đang vi phạm và một hành động cụ thể để khắc phục.
- Bản đồ phụ thuộc. Lấy 5–6 hạng mục backlog sắp tới của một sản phẩm 3 team. Vẽ sơ đồ các phụ thuộc chéo. Đề xuất một thứ tự ưu tiên mới và một cách chia nhỏ công việc để giảm số phụ thuộc xuống ít nhất một nửa.
- Soạn DoD chung. Viết một Definition of Done chung tối thiểu (5–8 tiêu chí) áp dụng cho mọi team trong tình huống PayFlow ở trên. Đánh dấu tiêu chí nào là "sàn bắt buộc" và tiêu chí nào team có thể thêm tùy chọn.
- Phản biện tình huống. Sếp bạn muốn lập một "phòng PMO" để điều phối 4 team Scrum. Viết một đoạn 150 từ thuyết phục sếp dùng cơ chế tự điều phối (refinement chung + scrum of scrums + Increment tích hợp) thay vì lớp kiểm soát tập trung.
Tóm tắt
Khi nhiều Scrum Team cùng làm trên một sản phẩm, hãy khắc cốt bốn cái "MỘT": một Product Backlog, một Product Goal, một Product Owner, và một Definition of Done được định nghĩa chung. Đây không phải giáo điều mà là cơ chế chống phân mảnh, bảo vệ tính thống nhất và minh bạch của sản phẩm.
Sai lầm phổ biến nhất là chia nhỏ những thứ vốn phải là "một" — mỗi team một PO, một backlog, một DoD — với lý do "tự chủ". Hệ quả luôn là ưu tiên xung đột và Increment giả xong. Tự chủ thật sự nằm ở cách team làm việc, không ở việc quyết định cái gì quan trọng nhất.
Cuối cùng, hãy nhớ sự khác biệt giữa điều phối và kiểm soát: thay vì dựng một lớp quản lý tập trung, hãy thiết kế hệ thống để các team tự đồng bộ — qua refinement chung làm phụ thuộc minh bạch, qua đồng bộ ngang hàng kiểu scrum of scrums, và quan trọng nhất, qua một Increment tích hợp mỗi Sprint làm phép thử thực tế. Đó là nền tảng để bạn bước vào các framework scaling cụ thể ở những bài tiếp theo.