Mở đầu — vì sao bài này quan trọng
Nếu bạn để ý kỹ Scrum Guide phiên bản 2020, bạn sẽ thấy một thay đổi tưởng nhỏ nhưng lại cực kỳ quan trọng: cụm từ "self-organizing" (tự tổ chức) đã được thay bằng "self-managing" (tự quản lý). Trong kỳ thi PSM I, đây là một trong những "bẫy" mà người ra đề rất thích đặt ra, bởi vì rất nhiều ứng viên học từ tài liệu cũ hoặc học theo trí nhớ mà không cập nhật.
Nhưng vượt ra ngoài chuyện thi cử, hiểu đúng "self-managing" còn là chìa khóa để bạn làm tốt vai trò Scrum Master ngoài đời thật. Bởi vì 90% lý do các nhóm Scrum thất bại không nằm ở việc họ không biết viết user story hay không vẽ được burndown chart — mà nằm ở việc nhóm chưa thực sự tự quản lý. Họ vẫn chờ sếp giao việc, vẫn chờ project manager phân công ai làm gì, vẫn không dám tự quyết. Và một Scrum Master không hiểu rõ self-management thì sẽ vô tình "bảo bọc" nhóm quá mức, biến mình thành một dạng quản lý trá hình.
Trong bài này, chúng ta sẽ làm rõ: self-managing nghĩa là gì, nó khác self-organizing ra sao, một nhóm tự quản lý có những đặc điểm cụ thể nào, và quan trọng nhất — làm thế nào để bạn nuôi dưỡng năng lực tự quản lý cho nhóm mà không buông lỏng cũng không kiểm soát.
Khái niệm cốt lõi
Định nghĩa "self-managing" theo Scrum Guide 2020
Scrum Guide 2020 nói rất rõ về Scrum Team:
> "Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how."
Hãy chú ý cụm "who does what, when, and how" — ai làm gì, khi nào, và như thế nào. Đây chính là điểm mấu chốt cần ghi nhớ. Một nhóm tự quản lý là nhóm tự quyết định bốn điều: WHO (ai làm), WHAT (làm việc gì trong phạm vi Sprint), WHEN (khi nào làm), và HOW (làm bằng cách nào).
Sự khác biệt giữa self-organizing và self-managing
Đây là phần PSM I rất hay kiểm tra, nên bạn cần nắm thật chắc.
Self-organizing (trước 2020): Nhóm tự tổ chức nghĩa là nhóm tự quyết định HOW — cách họ biến công việc thành sản phẩm. Ai đó (thường là bên ngoài, ví dụ Product Owner hay quản lý) sẽ đưa ra công việc cần làm, còn nhóm tự sắp xếp cách thực hiện. Tức là phạm vi tự chủ chủ yếu xoay quanh "cách làm".
Self-managing (từ 2020): Phạm vi tự chủ được mở rộng. Nhóm không chỉ tự quyết HOW mà còn tự quyết WHO, WHAT và WHEN. Nói cách khác, quyền tự chủ của nhóm bao trùm cả việc lựa chọn công việc nào sẽ đưa vào Sprint (trong Sprint Planning), ai sẽ đảm nhận, theo trình tự thời gian nào, và bằng cách nào.
Một cách dễ nhớ: self-organizing là "tự sắp xếp cách làm", còn self-managing là "tự quản lý toàn bộ công việc của mình". Self-managing là một khái niệm rộng hơn, bao hàm cả self-organizing bên trong nó.
| Khía cạnh | Self-organizing (cũ) | Self-managing (2020) |
|---|---|---|
| HOW (cách làm) | Có | Có |
| WHO (ai làm) | Một phần | Có |
| WHAT (làm gì) | Hạn chế | Có (trong phạm vi Sprint) |
| WHEN (khi nào) | Hạn chế | Có |
"WHAT" ở đây không có nghĩa là nhóm tự quyết toàn bộ sản phẩm
Đây là một điểm gây nhầm lẫn nguy hiểm. Khi nói nhóm tự quyết WHAT, ta KHÔNG có ý nói nhóm tự quyết sản phẩm sẽ có tính năng gì, ưu tiên ra sao — đó là trách nhiệm của Product Owner thông qua việc quản lý Product Backlog và Product Goal. Cái "WHAT" mà nhóm tự quản lý là: trong Sprint Planning, nhóm tự quyết bao nhiêu công việc họ có thể đưa vào Sprint, và cụ thể những hạng mục nào. Developers là người chọn lượng công việc đưa vào Sprint Backlog, không ai ép buộc họ.
Hãy phân biệt rõ:
- Product Owner quyết định thứ tự ưu tiên và giá trị — cái gì quan trọng hơn cái gì.
- Scrum Team (cụ thể là Developers) quyết định lượng công việc kéo vào Sprint và cách thực hiện.
Tại sao Scrum lại cần self-management?
Self-management không phải là một "đặc quyền" được trao cho nhóm để họ thấy thoải mái. Nó là nền tảng của empiricism (kinh nghiệm luận). Người gần công việc nhất luôn là người hiểu rõ công việc nhất. Khi để chính những người làm việc tự quyết định, các quyết định được đưa ra nhanh hơn, sát thực tế hơn, và quan trọng là tạo ra cam kết tự nguyện — người ta gìn giữ điều mình tự chọn hơn là điều bị áp đặt.
Đặc điểm của một nhóm tự quản lý
Một Scrum Team tự quản lý thực thụ thường có những đặc điểm sau:
- Tự lấy việc, không chờ giao việc. Trong Daily Scrum, các thành viên tự kéo (pull) công việc về phía mình thay vì chờ một người phân công (push).
- Tự ra quyết định kỹ thuật và quy trình mà không cần xin phép bên ngoài, trong phạm vi đã được định nghĩa (Definition of Done, chuẩn chất lượng của tổ chức).
- Chịu trách nhiệm tập thể về kết quả Sprint. Không có chuyện "đó là task của bạn ấy, không phải của tôi". Cả nhóm cùng chịu trách nhiệm với Sprint Goal.
- Tự điều chỉnh khi gặp vấn đề — chủ động re-plan trong Sprint khi thấy kế hoạch ban đầu không còn phù hợp.
- Có ranh giới rõ ràng (boundaries). Tự quản lý không phải là vô chính phủ. Nhóm tự chủ trong phạm vi của Sprint Goal, Definition of Done, và các giá trị Scrum.
Tình huống thực tế
Ví dụ 1: Đội phát triển app giao hàng tại một startup ở TP.HCM
Một startup logistics ở Quận 7, TP.HCM (tạm gọi là FastShip) có một nhóm 6 Developers. Trước đây, Trưởng phòng kỹ thuật Anh Tuấn họp đầu tuần và phân công cụ thể: "Bạn Lan làm màn hình thanh toán, bạn Hùng làm API tracking, bạn Minh fix bug danh sách đơn." Mọi người ngồi yên chờ được giao việc. Khi Lan kẹt vì một API chưa sẵn sàng, cô ngồi đợi vì "việc đó không thuộc phần mình".
Sau khi chuyển sang Scrum đúng nghĩa, Scrum Master tên Phương đã giúp nhóm thay đổi. Trong Sprint Planning, thay vì Anh Tuấn phân công, chính các Developers cùng nhau quyết định họ sẽ lấy bao nhiêu hạng mục từ Product Backlog (do Product Owner đã sắp ưu tiên) và tự thống nhất cách chia nhau làm. Khi Lan bị kẹt API, cô không còn ngồi đợi mà chủ động sang hỗ trợ Hùng đẩy nhanh phần backend, rồi cả hai cùng quay lại làm thanh toán.
Bài học rút ra: Sự dịch chuyển từ "chờ giao việc" sang "tự lấy việc" chính là biểu hiện rõ nhất của self-management. Năng suất của FastShip tăng vì không còn thời gian chết do chờ phân công, và quan trọng hơn, nhóm bắt đầu cảm thấy đây là Sprint "của họ".
Ví dụ 2: Hiểu sai "self-managing" thành "vô chính phủ" tại một công ty fintech ở Hà Nội
Một công ty fintech ở Hà Nội (tạm gọi là PayViet) nghe nói Scrum đề cao tự quản lý, nên Giám đốc công nghệ tuyên bố: "Từ nay nhóm tự do hoàn toàn, các bạn muốn làm gì thì làm." Kết quả là sau 3 Sprint, nhóm bắt đầu mỗi người làm một kiểu code, không ai tuân theo chuẩn chất lượng chung, có người tự ý bỏ qua việc viết test vì "tôi tự quản lý mà". Số lỗi trên production tăng gấp đôi.
Scrum Master mới về tên Đức nhận ra vấn đề: nhóm đã nhầm tự quản lý với việc không có ranh giới nào cả. Anh giúp nhóm xây dựng lại Definition of Done rõ ràng (bắt buộc có unit test, qua code review, không có lỗi nghiêm trọng), và nhắc nhở rằng tự quản lý luôn nằm trong khuôn khổ Sprint Goal và chuẩn chất lượng của tổ chức.
Bài học rút ra: Self-management không có nghĩa là không có ranh giới. Một nhóm tự quản lý hiệu quả là nhóm tự chủ bên trong một bộ ranh giới rõ ràng. Trong kỳ thi PSM I, nếu gặp đáp án kiểu "nhóm tự quản lý nên có thể bỏ qua Definition of Done nếu muốn" — đó chắc chắn là đáp án sai.
Ví dụ 3: Scrum Master "ôm việc" làm hỏng năng lực tự quản lý
Tại một công ty gia công phần mềm ở Đà Nẵng (tạm gọi là DevHub), Scrum Master tên Hà rất nhiệt tình. Mỗi khi nhóm gặp bất đồng về cách chia việc, chị nhảy vào quyết hộ. Mỗi khi có một quyết định kỹ thuật khó, chị hỏi ý kiến Tech Lead rồi truyền đạt lại cho nhóm. Nhóm dần dần quen với việc cứ có vấn đề là chờ "chị Hà giải quyết".
Sau 6 tháng, một Scrum Master khác quan sát và chỉ ra: Hà đang vô tình giết chết năng lực tự quản lý của nhóm. Bằng cách luôn ra quyết định thay nhóm, chị đã biến mình thành một dạng quản lý mới. Hà thay đổi cách tiếp cận: thay vì giải quyết hộ, chị đặt câu hỏi để nhóm tự tìm ra giải pháp ("Theo các bạn, mình nên xử lý chỗ này thế nào?"), và kiên nhẫn chịu đựng những khoảng im lặng khó chịu cho đến khi nhóm tự lên tiếng.
Bài học rút ra: Vai trò của Scrum Master không phải là quản lý nhóm, mà là nuôi dưỡng năng lực tự quản lý của nhóm. Một Scrum Master giỏi đôi khi phải kiềm chế bản năng "giúp đỡ" để nhóm có không gian tự trưởng thành.
Hướng dẫn từng bước
Nếu bạn đang là Scrum Master và muốn xây dựng một nhóm thực sự tự quản lý, đây là lộ trình thực tế:
Bước 1 — Làm rõ ranh giới. Trước khi trao quyền tự chủ, hãy đảm bảo nhóm hiểu rõ các ranh giới: Sprint Goal là gì, Definition of Done ra sao, các chuẩn chất lượng nào của tổ chức không được phá vỡ. Tự quản lý chỉ có ý nghĩa khi có khuôn khổ.
Bước 2 — Chuyển từ "push" sang "pull". Trong Daily Scrum và suốt Sprint, khuyến khích các thành viên tự kéo công việc về mình thay vì chờ phân công. Bạn có thể bắt đầu bằng cách đơn giản không phân công việc nữa, và để nhóm tự thương lượng.
Bước 3 — Đặt câu hỏi thay vì đưa câu trả lời. Khi nhóm hỏi bạn nên làm gì, hãy hỏi ngược lại: "Bạn nghĩ sao?" "Nhóm mình có những lựa chọn nào?". Mục tiêu là dịch chuyển trung tâm ra quyết định về phía nhóm.
Bước 4 — Bảo vệ không gian tự quyết của nhóm. Khi quản lý hay stakeholder cố gắng can thiệp vào việc "ai làm gì, làm thế nào", Scrum Master cần khéo léo bảo vệ quyền tự quản lý của nhóm, giải thích vì sao điều đó quan trọng.
Bước 5 — Dùng Retrospective để củng cố. Định kỳ trong Sprint Retrospective, hãy đưa câu hỏi "Lần này chúng ta tự quản lý tốt ở đâu, và ở đâu chúng ta lại rơi vào thói quen chờ chỉ đạo?" để nhóm tự nhìn lại và cải thiện.
Bước 6 — Tăng dần mức độ tự chủ. Self-management là một năng lực được nuôi dưỡng theo thời gian, không phải công tắc bật/tắt. Một nhóm mới có thể cần nhiều hỗ trợ hơn lúc đầu, rồi giảm dần khi họ trưởng thành.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm self-managing với self-organizing trong bài thi. Nếu đề hỏi Scrum Team trong Scrum Guide 2020 được mô tả là gì, đáp án đúng là "self-managing", không phải "self-organizing". Hãy nhớ: Guide 2020 đã thay đổi thuật ngữ này.
Lỗi 2 — Hiểu tự quản lý là không cần ranh giới. Như ví dụ PayViet, tự quản lý luôn nằm trong khuôn khổ Sprint Goal và Definition of Done. Đáp án nào gợi ý nhóm có thể phá vỡ chuẩn chất lượng vì "tự quản lý" đều sai.
Lỗi 3 — Cho rằng Scrum Master hoặc Product Owner phân công việc cho Developers. Không ai bên ngoài Developers được giao việc cụ thể cho từng Developer. Developers tự quyết ai làm gì. Đây là câu hỏi kinh điển của PSM I.
Lỗi 4 — Nhầm "tự quyết WHAT" thành "nhóm tự quyết toàn bộ tính năng sản phẩm". Product Owner mới là người quyết ưu tiên và giá trị qua Product Backlog. Nhóm tự quyết lượng công việc kéo vào Sprint, không phải nội dung chiến lược sản phẩm.
Mẹo ghi nhớ: Liên hệ self-managing với bốn chữ WHO – WHAT – WHEN – HOW. Còn self-organizing (cũ) chỉ tập trung vào HOW. Một câu thần chú đơn giản: "Self-managing = tự quyết ai, gì, khi nào, và như thế nào — trong ranh giới của Sprint."
Mẹo thực hành: Khi phân vân một câu hỏi PSM I về tự quản lý, hãy tự hỏi: "Đáp án này có làm tăng hay giảm quyền tự quyết của nhóm?" và "Đáp án này có tôn trọng ranh giới (Sprint Goal, DoD) không?". Đáp án đúng thường là cái vừa trao quyền cho nhóm vừa giữ ranh giới.
Bài tập thực hành
Bài tập 1 — Phân biệt thuật ngữ. Hãy tự viết ra (không nhìn tài liệu) sự khác biệt giữa self-organizing và self-managing theo bốn yếu tố WHO, WHAT, WHEN, HOW. Sau đó đối chiếu với bảng trong bài.
Bài tập 2 — Tình huống ra quyết định. Trong Sprint Planning, Product Owner nói: "Tôi muốn ba tính năng này hoàn thành trong Sprint tới." Developers cho rằng chỉ làm kịp hai. Theo nguyên tắc self-management, ai có quyền quyết định lượng công việc đưa vào Sprint? Hãy viết câu trả lời và giải thích.
Bài tập 3 — Tự đánh giá nhóm của bạn. Nếu bạn đang làm trong một nhóm, hãy chấm điểm nhóm mình (1–5) trên năm đặc điểm của nhóm tự quản lý đã nêu trong bài. Đặc điểm nào yếu nhất? Bạn sẽ làm gì trong Sprint tới để cải thiện?
Bài tập 4 — Xử lý can thiệp. Một quản lý cấp cao bước vào Daily Scrum và bắt đầu phân công việc cho từng Developer. Với vai trò Scrum Master, bạn sẽ phản ứng thế nào để bảo vệ quyền tự quản lý của nhóm mà vẫn giữ quan hệ tốt với quản lý đó? Viết ra kịch bản phản hồi của bạn.
(Gợi ý đáp án Bài tập 2: Developers là người quyết định lượng công việc kéo vào Sprint Backlog. Product Owner quyết ưu tiên và có thể đàm phán phạm vi, nhưng không thể ép số lượng. Đây chính là biểu hiện của self-management ở khía cạnh WHAT.)
Tóm tắt
- Scrum Guide 2020 đã đổi "self-organizing" thành "self-managing" — đây là điểm PSM I rất hay kiểm tra.
- Self-organizing (cũ): nhóm tự quyết HOW (cách làm).
- Self-managing (2020): nhóm tự quyết WHO, WHAT, WHEN và HOW — ai làm, làm gì (lượng công việc trong Sprint), khi nào, và bằng cách nào.
- "WHAT" mà nhóm tự quyết là lượng và hạng mục công việc kéo vào Sprint, KHÔNG phải ưu tiên hay giá trị sản phẩm — đó vẫn là trách nhiệm của Product Owner.
- Self-management luôn nằm trong ranh giới: Sprint Goal, Definition of Done, và chuẩn chất lượng của tổ chức. Tự quản lý không phải là vô chính phủ.
- Vai trò Scrum Master là nuôi dưỡng năng lực tự quản lý, không phải ra quyết định thay nhóm. Hãy đặt câu hỏi thay vì đưa câu trả lời.
- Không ai bên ngoài Developers được phân công việc cụ thể cho từng Developer — nhóm tự quyết.