Mở đầu — vì sao bài này quan trọng
Nếu bạn hỏi mười người đang làm Agile câu "Scrum Team gồm những vai trò nào?", rất có thể tám người sẽ trả lời theo phản xạ: "Có Product Owner, Scrum Master, và Development Team — ba vai trò". Câu trả lời đó đúng với Scrum Guide cũ, nhưng đã lỗi thời và sẽ khiến bạn rớt nhiều câu trong kỳ thi PSM I.
Scrum Guide 2020 đã định nghĩa lại một cách rất có chủ đích: Scrum Team là một đơn vị thống nhất, gồm một nhóm người duy nhất, không có sub-team và không có phân cấp. Bên trong nó có ba "accountabilities" (trách nhiệm giải trình): Product Owner, Scrum Master và Developers. Sự thay đổi tinh tế này — từ "ba team/role" sang "một team với ba accountabilities" — là một trong những điểm bị hỏi xoáy nhiều nhất trong đề thi.
Bài này là nền tảng. Trước khi đào sâu từng accountability (Bài 9, 10, 11), bạn phải nắm vững bức tranh tổng thể: Scrum Team là gì, đặc điểm cốt lõi (nhỏ, cross-functional, self-managing), và tại sao việc gọi đúng tên lại quan trọng đến vậy. Nắm chắc bài này, bạn sẽ tránh được cả một họ câu hỏi gài bẫy trong đề thi và — quan trọng hơn — hiểu đúng tinh thần của Scrum để áp dụng vào công việc thật.
Khái niệm cốt lõi
Scrum Team là một đơn vị thống nhất, không sub-team
Scrum Guide 2020 mở đầu phần về Scrum Team bằng một câu rất mạnh: "The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies."
Hãy đọc kỹ ba ý trong đó:
- One Scrum Master, one Product Owner — chỉ MỘT người cho mỗi accountability này. Một Scrum Team không thể có hai Product Owner cùng lúc, cũng không có hai Scrum Master.
- Developers (số nhiều) — đây là tất cả những người làm công việc tạo ra Increment trong mỗi Sprint. Không còn gọi là "Development Team" như trước.
- No sub-teams or hierarchies — không có nhóm con (kiểu "đội tester riêng", "đội backend riêng" tách biệt), không có cấp bậc trên dưới bên trong team.
Ba accountabilities, không phải ba "role"
Đây là điểm bạn phải khắc cốt ghi tâm cho kỳ thi. Scrum Guide 2020 cố tình tránh dùng từ "role" và thay bằng "accountability". Lý do:
- "Role" gợi cảm giác chức danh, vị trí trong sơ đồ tổ chức. Một người có thể "đóng vai" nhưng không thực sự chịu trách nhiệm.
- "Accountability" nghĩa là trách nhiệm giải trình cuối cùng — ai là người chịu trách nhiệm cho kết quả nào. Product Owner chịu trách nhiệm tối đa hóa giá trị sản phẩm. Scrum Master chịu trách nhiệm cho tính hiệu quả của Scrum Team. Developers chịu trách nhiệm tạo ra một Increment "Done" mỗi Sprint.
Đặc điểm 1: Nhỏ — thường 10 người hoặc ít hơn
Scrum Guide 2020 viết: "The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people."
Lưu ý mấy điểm dễ bị gài:
- Con số "10 hoặc ít hơn" là tính toàn bộ Scrum Team, tức là đã bao gồm cả Product Owner và Scrum Master, chứ không phải "10 Developers cộng thêm PO và SM".
- Đây là con số điển hình (typical), không phải quy tắc cứng. Scrum Guide không ép buộc tối thiểu/tối đa tuyệt đối. (So với Scrum Guide cũ ghi "3 đến 9 Developers" — con số này đã bị bỏ.)
- Triết lý đằng sau: team nhỏ giao tiếp tốt hơn, năng suất cao hơn. Khi team quá lớn, chi phí giao tiếp tăng theo cấp số nhân.
Đặc điểm 2: Cross-functional
Scrum Team phải là cross-functional — nghĩa là tập thể này sở hữu đủ mọi kỹ năng cần thiết để tạo ra giá trị trong mỗi Sprint, mà không phụ thuộc vào người ngoài team.
Điểm tinh tế: cross-functional là đặc tính của cả team, không phải yêu cầu mỗi cá nhân phải biết tất cả mọi thứ. Một lập trình viên backend không cần biết thiết kế UX; nhưng tập hợp cả team thì phải có người làm được UX. (Khái niệm này được đào sâu ở Bài 29, ở đây chỉ cần nắm nguyên tắc nền.)
Đặc điểm 3: Self-managing
Scrum Team là self-managing (tự quản lý): chính team tự quyết định ai làm gì, khi nào và làm như thế nào. Không có ai bên ngoài team ra lệnh chia việc.
Lưu ý thuật ngữ: Scrum Guide 2020 dùng "self-managing", thay cho "self-organizing" của bản cũ. "Self-organizing" chỉ nói về việc tự quyết định "ai làm việc gì". "Self-managing" rộng hơn: tự quyết "ai, làm gì, khi nào, làm như thế nào". (Đặc điểm self-managing được đào sâu ở Bài 28.)
Toàn bộ Scrum Team chịu trách nhiệm chung
Một câu rất hay bị bỏ qua trong Scrum Guide 2020: "The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint."
Đọc kỹ: KHÔNG phải chỉ Developers, mà là TOÀN BỘ Scrum Team — gồm cả Product Owner và Scrum Master — cùng chịu trách nhiệm tạo ra một Increment có giá trị mỗi Sprint. Đây là điểm phân biệt rất tinh tế với câu "Developers chịu trách nhiệm tạo ra Increment". Cả hai câu đều đúng nhưng ở mức độ khác nhau: Developers là người trực tiếp build, nhưng accountability cuối cùng cho một Increment có giá trị thuộc về cả team.
Đề thi PSM I rất thích đặt hai mệnh đề này cạnh nhau để xem bạn có phân biệt được không.
Scrum Team chịu trách nhiệm cho mọi hoạt động liên quan đến sản phẩm
Scrum Guide 2020 cũng nói Scrum Team chịu trách nhiệm cho tất cả các hoạt động liên quan đến sản phẩm: hợp tác với stakeholder, kiểm thử, nghiên cứu, phát triển, thử nghiệm, vận hành, bảo trì... Điều này xóa bỏ quan niệm cũ rằng Scrum chỉ lo phần "code". Scrum Team là một đơn vị tự cấp (self-contained) chịu trách nhiệm end-to-end cho sản phẩm.
Tình huống thực tế
Tình huống 1: Tiki tách team theo chức năng và hậu quả của "sub-team"
Giả sử tại một công ty thương mại điện tử lớn ở TP.HCM (lấy bối cảnh kiểu Tiki), một "Scrum Team" cho tính năng giỏ hàng được tổ chức như sau: 5 lập trình viên ngồi ở tầng 3, 3 tester ngồi ở tầng 5 và báo cáo cho một QA Lead riêng. Mỗi Sprint, dev "ném" code sang cho QA test, và khi có bug thì hai bên đổ lỗi qua lại.
Diễn giải: Đây thực chất là hai sub-team có phân cấp riêng (QA Lead), vi phạm trực tiếp nguyên tắc "no sub-teams or hierarchies". Hậu quả thực tế: trong một Sprint hai tuần, code thường được "ném" sang QA vào ngày thứ 8, dẫn đến 4 ngày cuối Sprint dồn dập, và 30% bug bị đẩy sang Sprint sau vì không kịp test. Increment không bao giờ thực sự "Done" trong Sprint.
Bài học: Khi gộp tester vào chính Scrum Team (không còn QA Lead riêng, không còn ranh giới tầng 3 — tầng 5), việc kiểm thử diễn ra song song ngay từ ngày đầu Sprint. Cả team cùng sở hữu chất lượng. Đây chính là tinh thần "một đơn vị thống nhất" và "cross-functional".
Tình huống 2: Startup fintech ở Hà Nội với team 14 người ì ạch
Một startup fintech ở Hà Nội có một "Scrum Team" 14 người làm app ví điện tử: 1 PO, 1 SM, và 12 Developers. Mỗi Daily Scrum kéo dài 35 phút vì quá nhiều người phải nói. Sprint Planning thường mất gần 5 tiếng. Nhiều thành viên cảm thấy "việc của mình chẳng liên quan đến nửa số người trong phòng".
Diễn giải: Team đã vượt xa ngưỡng "thường 10 người hoặc ít hơn". Chi phí giao tiếp tăng vọt, các Scrum event trở nên dài và kém hiệu quả. Đây không phải là tự nhiên xấu, mà là dấu hiệu cần "reorganize into multiple cohesive Scrum Teams".
Bài học: Họ tách thành 2 Scrum Team, mỗi team 7 người (1 PO chung cho cả product, mỗi team 1 SM, còn lại là Developers), cùng làm trên một product, chia sẻ chung Product Goal và Product Backlog. Sau khi tách, Daily Scrum của mỗi team rút về đúng 15 phút, và tốc độ giao việc rõ rệt hơn. Lưu ý cho kỳ thi: giải pháp đúng "by the book" là tách team, KHÔNG phải tạo thêm cấp quản lý hay sub-team.
Tình huống 3: Câu hỏi "ai chịu trách nhiệm cho Increment?"
Trong một buổi review nội bộ tại một công ty outsourcing ở Đà Nẵng, sếp hỏi: "Sprint này Increment không đủ giá trị, lỗi tại ai? Tại Developers code chậm à?". Scrum Master trả lời: "Theo Scrum, toàn bộ Scrum Team chịu trách nhiệm cho việc tạo ra một Increment có giá trị mỗi Sprint — gồm cả Product Owner trong việc sắp xếp ưu tiên backlog và em trong việc gỡ impediment, chứ không chỉ riêng các bạn Developers."
Diễn giải: Đây là minh họa sống động cho câu "The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint". Việc đổ lỗi cho riêng một nhóm đi ngược lại tinh thần "một đơn vị thống nhất".
Bài học: Trong kỳ thi, nếu gặp câu "Who is accountable for the Increment?", hãy đọc kỹ. Nếu hỏi về việc tạo ra một Increment có giá trị mỗi Sprint → đáp án là "the entire Scrum Team". Nếu hỏi cụ thể về việc ai làm/build ra Increment "Done" → đáp án là "Developers". Sắc thái câu hỏi quyết định đáp án.
Hướng dẫn từng bước
Khi bạn cần "soi" một team trong thực tế (hoặc trong một câu hỏi tình huống của đề thi) để xác định nó có đúng là một Scrum Team theo chuẩn không, hãy đi theo các bước sau:
- Đếm số người và cấu trúc. Tổng cộng có bao nhiêu người? Có vượt quá ngưỡng "thường 10 hoặc ít hơn" không? Nếu có, nguyên tắc xử lý là tách thành nhiều Scrum Team, không tạo thêm cấp.
- Kiểm tra "một đơn vị thống nhất". Có sub-team không (đội test riêng, đội backend riêng tách biệt)? Có cấp bậc bên trong không (team lead ra lệnh, junior chỉ nghe theo)? Nếu có → vi phạm nguyên tắc no sub-teams/hierarchies.
- Xác nhận đúng ba accountabilities. Có đúng MỘT Product Owner và MỘT Scrum Master không? Phần còn lại là Developers? Cẩn thận với những từ như "Development Team" (thuật ngữ cũ) hay "ba team".
- Kiểm tra tính cross-functional. Team có đủ kỹ năng để tự tạo ra Increment mỗi Sprint mà không phụ thuộc người ngoài không? Nếu mỗi Sprint phải "xin" một chuyên gia ở phòng ban khác mới làm xong việc → chưa cross-functional.
- Kiểm tra tính self-managing. Ai quyết định cách làm việc, chia việc? Nếu một quản lý bên ngoài giao việc chi tiết cho từng người → vi phạm self-managing.
- Xác định accountability cho kết quả. Khi có vấn đề về Increment, câu trả lời "by the book" là cả Scrum Team chịu trách nhiệm cho một Increment có giá trị, chứ không đổ lỗi cho một nhóm con.
Lỗi thường gặp & mẹo
Lỗi 1: Gọi Scrum Team gồm "ba team" hoặc "ba role". Đây là cái bẫy phổ biến nhất. Hãy ghi nhớ: 1 Scrum Team, 3 accountabilities. Không có ba team. Không có khái niệm "role" trong Scrum Guide 2020.
Lỗi 2: Vẫn dùng "Development Team". Scrum Guide 2020 đã bỏ "Development Team" và "Dev Team", thay bằng "Developers". Nếu một câu trả lời nhắc đến "Development Team như một nhóm tách biệt bên trong Scrum Team", đó thường là đáp án sai.
Lỗi 3: Nghĩ "10 hoặc ít hơn" chỉ tính Developers. Con số này tính cả PO và SM. Tổng Scrum Team thường 10 người hoặc ít hơn.
Lỗi 4: Coi cross-functional nghĩa là mỗi người phải biết mọi thứ. Sai. Cross-functional là đặc tính của cả team, không phải của từng cá nhân.
Lỗi 5: Lẫn lộn "self-organizing" và "self-managing". Bản 2020 dùng "self-managing" (rộng hơn). Nếu đề nhấn mạnh thuật ngữ, hãy chọn "self-managing".
Lỗi 6: Khi team quá lớn thì thêm quản lý hoặc tạo sub-team. Giải pháp đúng của Scrum Guide là tách thành nhiều Scrum Team cùng làm trên một product.
Mẹo ghi nhớ nhanh:
- "1 team — 3 accountabilities — 10 or fewer".
- PO và SM: mỗi cái đúng MỘT người. Developers: số nhiều.
- "Entire Scrum Team" chịu trách nhiệm cho Increment có giá trị; "Developers" build ra Increment "Done".
- No sub-teams, no hierarchies, cross-functional, self-managing.
Bài tập thực hành
- Tự kiểm tra định nghĩa: Không nhìn tài liệu, hãy viết ra một câu định nghĩa Scrum Team bao gồm: số accountabilities, có sub-team hay không, kích thước điển hình. Sau đó so với Scrum Guide 2020.
- Phân tích team của bạn: Áp dụng 6 bước trong phần "Hướng dẫn từng bước" cho chính team bạn đang làm (hoặc một team bạn biết). Ghi ra ít nhất 2 điểm chưa khớp chuẩn Scrum và đề xuất cách điều chỉnh.
- Phân biệt sắc thái accountability: Cho hai câu hỏi sau, chọn đáp án và giải thích lý do:
- Tình huống tách team: Một product có 16 người đang ở trong "một Scrum Team". Hãy viết phương án tổ chức lại theo đúng Scrum Guide, nêu rõ: chia thành mấy team, dùng chung Product Owner / Product Backlog / Product Goal như thế nào, và TẠI SAO không chọn cách thêm một tầng quản lý.
- Bẫy thuật ngữ: Viết ra 3 thuật ngữ của Scrum Guide cũ liên quan đến Scrum Team mà bản 2020 đã thay đổi, kèm thuật ngữ mới tương ứng. (Gợi ý: Development Team → Developers; role → accountability; self-organizing → self-managing.)
Tóm tắt
- Scrum Team là một đơn vị thống nhất, một nhóm người duy nhất, không có sub-team và không có phân cấp bên trong.
- Bên trong có ba accountabilities (không phải ba role, không phải ba team): một Product Owner, một Scrum Master, và Developers.
- Đặc điểm cốt lõi: nhỏ (thường 10 người hoặc ít hơn, tính cả PO và SM), cross-functional (đủ kỹ năng tự tạo value mỗi Sprint), và self-managing (tự quyết ai, làm gì, khi nào, như thế nào).
- Toàn bộ Scrum Team chịu trách nhiệm cho việc tạo ra một Increment có giá trị mỗi Sprint, và chịu trách nhiệm cho mọi hoạt động liên quan đến sản phẩm.
- Khi team quá lớn: tách thành nhiều Scrum Team cùng làm trên một product, không thêm cấp quản lý hay sub-team.
- Cảnh giác bẫy thuật ngữ của bản cũ: "Development Team", "role", "self-organizing", và con số "3–9". Bản 2020 dùng "Developers", "accountability", "self-managing", "10 or fewer".