Mở đầu — vì sao bài này quan trọng
Có một câu nói tôi nghe rất nhiều từ các lãnh đạo khi triển khai Scrum: "Từ hôm nay, các bạn là một team tự quản (self-managing). Hãy tự quyết định, đừng chờ tôi nữa." Họ tuyên bố điều đó trong một cuộc họp, vỗ tay, rồi đi ra. Vài tuần sau, họ ngạc nhiên khi thấy team vẫn ngồi chờ chỉ thị, vẫn hỏi "anh muốn em làm cái nào trước", vẫn đẩy mọi quyết định khó lên trên.
Đây chính là sai lầm cốt lõi mà bài học này muốn bạn nhìn thẳng: tự quản là thứ được xây dựng (built), không phải thứ được tuyên bố (declared). Trong Scrum Guide 2020, từ "self-organizing" đã được thay bằng "self-managing" một cách có chủ đích. Self-organizing nghĩa là team tự chọn cách làm việc (the how). Self-managing nâng cấp lên: team tự quyết định ai làm gì, khi nào, và như thế nào để biến Product Backlog thành giá trị. Đây là sự dịch chuyển quyền quyết định lớn hơn nhiều, và nó không tự đến.
Với một Scrum Master ở cấp độ PSM II, đây là một trong những năng lực phân biệt bạn với người mới. Người mới nghĩ tự quản là "để mặc team". Người giỏi hiểu rằng tự quản là một trạng thái trưởng thành phải được nuôi dưỡng qua nhiều giai đoạn, đòi hỏi bạn chủ động thiết kế môi trường, dịch chuyển quyền lực một cách có kiểm soát, và biết khi nào nên rút lui. Bài này tập trung đúng vào cơ chế xây dựng đó — không bàn về psychological safety (Bài 25) hay systems thinking ở cấp tổ chức (Bài 10), mà về chính việc làm thế nào một team đi từ phụ thuộc đến tự quản thực sự.
Khái niệm cốt lõi
Tự quản thực sự nghĩa là gì
Một team tự quản không phải là một team không có lãnh đạo, cũng không phải một team làm gì cũng được. Đó là một team có ranh giới rõ ràng (boundaries) và bên trong ranh giới đó, họ có toàn quyền quyết định. Hãy hình dung một sân bóng: vạch vôi là ranh giới do tổ chức đặt ra (mục tiêu sản phẩm, ngân sách, ràng buộc tuân thủ, Definition of Done), còn cách chơi bên trong sân là của team. Lãnh đạo càng giỏi thì càng tập trung vẽ vạch vôi rõ ràng thay vì chạy vào sân đá hộ.
Tự quản đứng trên ba trụ cột: năng lực (competence) — team phải đủ kỹ năng để tự quyết; quyền (authority) — tổ chức phải thực sự trao quyền, không chỉ nói suông; và trách nhiệm (accountability) — team phải gánh hậu quả của quyết định. Thiếu một trong ba, tự quản sụp đổ. Trao quyền mà không có năng lực thì hỗn loạn. Có năng lực mà không có quyền thì ức chế. Có quyền mà không chịu trách nhiệm thì vô kỷ luật.
Các cấp độ tự quản
Đây là khung quan trọng nhất của bài. Tự quản không phải trạng thái bật/tắt mà là một thang liên tục. Tôi thường dùng bảng sau khi đánh giá một team:
| Cấp độ | Ai ra quyết định | Ví dụ điển hình |
|---|---|---|
| Dependent (Phụ thuộc) | Quản lý quyết định gần như mọi thứ | PM hoặc team lead phân công từng task, team chỉ thực thi |
| Consultative (Tham vấn) | Quản lý quyết định nhưng hỏi ý kiến team | Lead hỏi "theo các bạn nên làm thế nào" rồi tự chốt |
| Collaborative (Hợp tác) | Quản lý và team cùng quyết định | Cùng họp, cùng bàn, đồng thuận chung |
| Delegated (Ủy quyền) | Team quyết, quản lý đặt ranh giới và hỗ trợ | Team tự lập kế hoạch Sprint, tự chia việc; lead chỉ gỡ rào cản |
| Self-managing (Tự quản) | Team tự quyết toàn bộ "ai/khi nào/thế nào" trong ranh giới | Team tự lấy việc, tự cân bằng tải, tự giải quyết xung đột nội bộ |
Delegation Poker và bảy mức ủy quyền
Một công cụ thực hành tuyệt vời từ Management 3.0 là Delegation Poker, chia ủy quyền thành 7 mức: (1) Tell — tôi quyết và thông báo; (2) Sell — tôi quyết và thuyết phục; (3) Consult — hỏi ý kiến rồi tôi quyết; (4) Agree — cùng quyết; (5) Advise — tôi góp ý nhưng team quyết; (6) Inquire — team quyết rồi báo lại tôi; (7) Delegate — team toàn quyền, tôi không cần biết. Sức mạnh của công cụ này là nó tách ủy quyền theo từng loại quyết định, không cào bằng. Một team có thể ở mức 7 với việc "chọn thư viện kỹ thuật" nhưng mới ở mức 3 với việc "cam kết deadline với khách hàng". Làm rõ điều này gỡ bỏ vô số hiểu lầm ngầm giữa team và quản lý.
Tình huống thực tế
Tình huống 1 — Công ty fintech ở TP.HCM: tuyên bố mà không xây dựng
Một công ty fintech tại Quận 1, TP.HCM (khoảng 120 người, sản phẩm ví điện tử) quyết định "chuyển sang tự quản" sau khi CTO đi dự một hội thảo Agile. Trong một email gửi toàn bộ kỹ thuật, anh tuyên bố: "Kể từ Sprint tới, các team tự quyết mọi thứ, không còn team lead phân việc."
Kết quả ba tuần sau khá thảm. Velocity của team Payments tụt từ 34 xuống 19 điểm. Lý do? Trước đây team lead là người duy nhất nắm bức tranh kỹ thuật tổng thể và quan hệ với các phòng ban khác. Khi anh ngừng phân việc, team không có kỹ năng tự ưu tiên, không biết cách thương lượng với team Risk, và bắt đầu xảy ra mâu thuẫn về việc ai làm phần khó. Hai dev senior âm thầm tự chia nhau việc theo kiểu cũ, còn các bạn junior thì tê liệt vì không ai chỉ.
Diễn giải: CTO đã làm đúng phần "trao quyền" nhưng bỏ qua hoàn toàn "năng lực" và "ranh giới". Team chưa từng được dạy cách tự ưu tiên, chưa có Working Agreement, chưa có Definition of Done đủ rõ để tự kiểm soát chất lượng. Tuyên bố tự quản trong môi trường thiếu nền tảng giống như tháo bánh phụ xe đạp cho đứa trẻ chưa biết giữ thăng bằng.
Bài học: Trước khi trao quyền, hãy đầu tư vào năng lực và ranh giới. Scrum Master mới (do công ty thuê sau sự cố) đã làm ngược lại: tổ chức workshop để team tự xây Working Agreement, dùng Delegation Poker để làm rõ quyết định nào team được quyết, quyết định nào còn cần lead, rồi mới rút lui dần theo từng Sprint. Sau hai tháng velocity hồi phục lên 31 và quan trọng hơn, junior bắt đầu tự nhận việc.
Tình huống 2 — Tiki: dịch chuyển ranh giới theo từng nấc
Tại một team sản phẩm thuộc một sàn thương mại điện tử lớn của Việt Nam (gọi là team Logistics Tracking), Scrum Master tiếp cận việc xây tự quản theo cách rất kỷ luật. Cô không tuyên bố gì cả. Thay vào đó, mỗi Sprint Retrospective cô đưa ra một quyết định mà trước đây Engineering Manager (EM) thường nắm, rồi hỏi: "Liệu Sprint tới team có thể tự quyết việc này không?"
Sprint 5, team được trao quyền tự chọn thứ tự thực thi các item trong Sprint Backlog (trước đó EM sắp). Sprint 8, team được tự quyết về kỹ thuật triển khai mà không cần EM duyệt. Sprint 12, team được tự thương lượng phạm vi với Product Owner trong Sprint Planning mà EM không tham gia. Mỗi nấc đều có một cuộc trò chuyện rõ ràng với EM về ranh giới: cái gì team quyết, cái gì vẫn cần báo cáo.
Diễn giải: Đây là minh họa sách giáo khoa cho "building". Quyền lực được dịch chuyển từng phần, mỗi phần đều được team hấp thụ trước khi chuyển phần tiếp theo. EM cũng được chuẩn bị tâm lý để buông tay dần — đây là điểm hay bị bỏ qua, vì rào cản lớn nhất của tự quản thường không nằm ở team mà ở người quản lý sợ mất kiểm soát.
Bài học: Tự quản là một quá trình thương lượng lại quyền lực liên tục, có thể đo lường được theo Sprint. Nó cần sự kiên nhẫn và cần làm việc với cả team lẫn lớp quản lý phía trên.
Tình huống 3 — Startup SaaS Singapore: tự quản đi quá đà thành vô kỷ luật
Một startup SaaS B2B ở Singapore (18 người, vòng Series A) tự hào về văn hóa "no managers". Các team được tự quản hoàn toàn từ ngày đầu. Nghe rất đẹp, nhưng sau sáu tháng họ gặp vấn đề: chất lượng code không đồng đều, có team release không test, deadline với khách hàng bị lỡ liên tục mà không ai chịu trách nhiệm rõ ràng.
Vấn đề ở đây ngược với tình huống 1: họ có quyền và (phần nào) năng lực, nhưng thiếu accountability và thiếu ranh giới. "Tự quản" bị hiểu nhầm thành "không ai chịu trách nhiệm về kết quả". Khi một Sprint thất bại, mỗi người đổ cho hoàn cảnh.
Diễn giải: Tự quản không có nghĩa là không có trách nhiệm hay không có chuẩn chung. Một team tự quản trưởng thành thực ra tự áp đặt kỷ luật cao hơn lên chính mình, không phải thấp hơn. Họ cần Definition of Done chung, cần cam kết Sprint Goal rõ ràng, cần một cơ chế để chính team đối mặt với việc không đạt.
Bài học: Khi xây tự quản, đừng chỉ trao tự do — phải song hành với việc làm rõ trách nhiệm tập thể. Scrum Master ở đây đã giúp team thiết lập một Definition of Done thống nhất toàn công ty và đưa Sprint Goal thành cam kết được nhìn lại nghiêm túc mỗi Retro.
Hướng dẫn từng bước
Dưới đây là quy trình tôi khuyên bạn áp dụng để xây tự quản một cách có hệ thống.
Bước 1 — Chẩn đoán cấp độ hiện tại. Quan sát team trong 2-3 Sprint. Ai phân việc? Khi gặp rào cản, team tự gỡ hay chờ ai đó? Quyết định kỹ thuật do team hay do một người? Dùng bảng năm cấp độ ở trên để định vị. Đừng tự huyễn hoặc — hãy hỏi cả team và quản lý để đối chiếu.
Bước 2 — Làm rõ ranh giới hiện hữu. Liệt kê các loại quyết định team gặp hằng ngày (chọn task, cách triển khai kỹ thuật, ước lượng, cam kết deadline, tuyển người, ngân sách công cụ...). Với mỗi loại, dùng Delegation Poker để xác định mức ủy quyền hiện tại. Đây là bức tranh khởi điểm.
Bước 3 — Đầu tư vào năng lực trước khi trao quyền. Nếu team thiếu kỹ năng tự ưu tiên, dạy họ. Nếu thiếu kỹ năng kỹ thuật để tự quyết, sắp xếp mentoring, pairing. Tự quản đứng trên năng lực — không có năng lực thì trao quyền chỉ tạo hỗn loạn.
Bước 4 — Cùng team xây Working Agreement. Đây là bộ "luật chơi" do chính team viết ra: cách họp, cách lấy việc, cách xử lý bất đồng, định nghĩa chất lượng. Working Agreement là xương sống của tự quản vì nó thay thế sự chỉ huy bằng thỏa thuận chung.
Bước 5 — Dịch chuyển quyền lực từng nấc. Mỗi Retrospective, chọn một loại quyết định để nâng mức ủy quyền lên một bậc. Thông báo rõ với cả team và quản lý. Cho team thời gian hấp thụ trước khi chuyển nấc tiếp.
Bước 6 — Rút lui có chủ đích (intentional withdrawal). Khi team mạnh lên, bạn phải chủ động im lặng. Trong Daily Scrum, đừng trả lời thay. Khi có rào cản nhỏ, đợi xem team có tự gỡ không trước khi can thiệp. Đây là kỹ năng khó nhất — kìm bản năng giải cứu.
Bước 7 — Củng cố accountability. Đảm bảo team có Sprint Goal rõ, Definition of Done chung, và nhìn lại trung thực mỗi Sprint. Tự do phải đi kèm trách nhiệm tập thể.
Lỗi thường gặp & mẹo
Lỗi 1 — Tuyên bố thay vì xây. Như đã nói xuyên suốt bài, đây là lỗi số một. Mẹo: không bao giờ "trao quyền" bằng một thông báo. Hãy trao bằng hành động lặp lại qua nhiều Sprint.
Lỗi 2 — Trao quyền nhưng vẫn can thiệp ngầm. Lãnh đạo nói "team cứ quyết" nhưng sau đó âm thầm phủ quyết, hoặc tỏ thái độ khi team quyết khác ý mình. Điều này phá hủy niềm tin nhanh hơn cả việc không trao quyền. Mẹo: nếu một quyết định bạn không thực sự sẵn lòng để team quyết, đừng giả vờ trao — hãy thành thật giữ nó ở mức "Consult".
Lỗi 3 — Scrum Master trở thành nút cổ chai mới. Bạn rút quản lý ra nhưng lại tự biến mình thành người team phụ thuộc vào. Mẹo: tự hỏi mỗi tuần "nếu mình nghỉ phép một tháng, team có chạy được không?". Nếu câu trả lời là không, bạn đang xây sự phụ thuộc vào chính mình.
Lỗi 4 — Đẩy team quá nhanh. Leo từ Dependent thẳng lên Self-managing. Mẹo: mỗi lần chỉ một bậc, và cho thời gian hấp thụ.
Lỗi 5 — Quên lớp quản lý. Rào cản lớn nhất thường là EM/quản lý sợ mất việc hoặc mất kiểm soát. Mẹo: làm việc song song với họ, định nghĩa lại vai trò của họ (từ "phân việc" sang "phát triển con người và gỡ rào cản tổ chức") để họ không cảm thấy bị đe dọa.
Mẹo bổ sung — Đo lường tự quản. Một chỉ dấu đơn giản: đếm số lần trong một Sprint mà team đẩy quyết định lên cho bạn hoặc cho quản lý. Con số này giảm dần theo thời gian là tín hiệu tự quản đang tăng.
Bài tập thực hành
- Chẩn đoán team của bạn. Dùng bảng năm cấp độ, định vị team bạn đang ở đâu. Viết ba bằng chứng cụ thể cho đánh giá đó (ví dụ "junior luôn hỏi senior nên làm task nào trước" → dấu hiệu Dependent).
- Chơi Delegation Poker. Liệt kê 7 loại quyết định team gặp thường xuyên. Tự đánh giá mức ủy quyền hiện tại của mỗi loại (1-7). Sau đó nếu có thể, làm bài tập này cùng quản lý và so sánh — bạn sẽ phát hiện những khoảng vênh kỳ vọng rất đáng giá.
- Thiết kế lộ trình một bậc. Chọn một loại quyết định, viết ra kế hoạch cụ thể để nâng nó lên một mức ủy quyền trong ba Sprint tới: cần dạy team kỹ năng gì, làm rõ ranh giới nào, ai cần đồng thuận.
- Thử nghiệm rút lui. Trong Daily Scrum tiếp theo, hãy im lặng hoàn toàn, không trả lời thay, không nhắc việc. Ghi lại điều gì xảy ra: team có tự xoay xở không, ai bước lên thay bạn, có khoảng lặng khó chịu nào. Đây là bài tập về kỷ luật bản thân của Scrum Master.
Tóm tắt
Tự quản là thứ được xây dựng, không phải được tuyên bố. Trong Scrum 2020, self-managing nghĩa là team tự quyết "ai làm gì, khi nào, như thế nào" trong một ranh giới do tổ chức đặt ra. Nó đứng trên ba trụ cột: năng lực, quyền, và trách nhiệm — thiếu một là sụp.
Tự quản tồn tại trên một thang năm cấp độ, từ Dependent đến Self-managing, và việc của Scrum Master là chẩn đoán team đang ở đâu rồi dịch chuyển họ lên từng bậc một cách bền vững, không nhảy cóc. Công cụ Delegation Poker giúp tách ủy quyền theo từng loại quyết định thay vì cào bằng. Ba tình huống thực tế cho thấy ba kiểu thất bại: tuyên bố mà không xây nền (fintech TP.HCM), và tự do mà không có trách nhiệm (startup Singapore) — đối lập với cách làm đúng là dịch chuyển ranh giới từng nấc có kỷ luật (team thương mại điện tử).
Hãy nhớ: nhiệm vụ cuối cùng của bạn là làm cho team không cần đến bạn. Một Scrum Master giỏi không phải người team không thể thiếu, mà là người đã xây được một team có thể tự chạy khi mình vắng mặt.