Mở đầu — vì sao bài này quan trọng
Ở cấp độ PSM I, bạn được dạy rằng Scrum Master nên giúp đội tự giải quyết xung đột, và rằng xung đột "lành mạnh" là tốt cho đội. Đúng, nhưng quá chung chung. Đến cấp PSM II, bạn sẽ đối diện với những xung đột không tự tan biến: hai senior developer không nhìn mặt nhau suốt ba sprint, một Product Owner và Tech Lead cãi nhau công khai về kiến trúc trước mặt cả đội, hay căng thẳng ngầm giữa team Việt Nam và đối tác Mỹ về cách báo cáo tiến độ. Những tình huống này không thể "đợi đội tự xử lý" được. Nếu bạn để mặc, chúng sẽ ăn mòn psychological safety, làm năng suất tụt dốc, và đôi khi khiến người giỏi nhất nghỉ việc.
Bài này tập trung vào kỹ năng giải quyết xung đột nâng cao dành cho Scrum Master — không phải để bạn trở thành quan tòa phán xử ai đúng ai sai, mà để bạn đọc được bản chất của xung đột, chọn đúng chế độ ứng xử, và can thiệp một cách có chủ đích. Đây là một trong những kỹ năng phân biệt rõ nhất giữa một Scrum Master "chạy ceremony" và một Scrum Master thực sự tạo ra giá trị cho tổ chức.
Khái niệm cốt lõi
Mô hình Thomas-Kilmann (TKI) — năm chế độ xử lý xung đột
Trái tim của bài này là mô hình Thomas-Kilmann Conflict Mode Instrument (TKI). Mô hình này đặt mọi cách phản ứng với xung đột lên hai trục:
- Assertiveness (tính quyết đoán): mức độ bạn theo đuổi mối quan tâm/lợi ích của chính mình.
- Cooperativeness (tính hợp tác): mức độ bạn quan tâm tới lợi ích của người khác.
| Chế độ | Quyết đoán? | Hợp tác? | Khi nào dùng |
|---|---|---|---|
| Competing (Cạnh tranh) | Cao | Thấp | Khủng hoảng cần quyết định nhanh, vấn đề an toàn/đạo đức, khi cần bảo vệ một quyết định không được lòng số đông |
| Collaborating (Hợp tác) | Cao | Cao | Vấn đề quan trọng với cả hai bên, cần giải pháp win-win, cần học hỏi lẫn nhau và xây dựng cam kết |
| Compromising (Thỏa hiệp) | Vừa | Vừa | Hai bên cân bằng quyền lực, cần giải pháp tạm thời, thời gian gấp |
| Avoiding (Né tránh) | Thấp | Thấp | Vấn đề nhỏ, cần thời gian hạ nhiệt, khi bạn không có đủ thông tin |
| Accommodating (Nhường nhịn) | Thấp | Cao | Khi bạn sai, khi quan hệ quan trọng hơn vấn đề, để "gửi gắm thiện chí" cho lần sau |
Phân biệt loại xung đột: Task vs Relationship vs Process
Trước khi chọn chế độ, bạn cần chẩn đoán xung đột thuộc loại nào (theo nghiên cứu của Karen Jehn):
- Task conflict (xung đột về nội dung công việc): bất đồng về cái gì cần làm, giải pháp kỹ thuật, ưu tiên. Loại này thường lành mạnh — tranh luận tốt làm quyết định tốt hơn.
- Relationship conflict (xung đột quan hệ): căng thẳng cá nhân, không ưa nhau, tổn thương cảm xúc. Loại này độc hại — cần can thiệp sớm.
- Process conflict (xung đột về cách làm): bất đồng về ai làm việc gì, quy trình, trách nhiệm.
Vai trò của Scrum Master: facilitator, không phải judge
Trong xung đột, Scrum Master hiếm khi nên đứng ở chế độ Competing để "ra phán quyết". Vai trò chính của bạn là tạo không gian an toàn để các bên tự đối thoại, đặt câu hỏi mạnh, và giúp họ tách con người ra khỏi vấn đề. Bạn dùng TKI theo hai cấp: (1) chọn chế độ cho chính bạn khi can thiệp, và (2) giúp các bên xung đột nhận ra họ đang kẹt ở chế độ nào và mở rộng lựa chọn của họ.
Tình huống thực tế
Tình huống 1 — Hai senior developer "chiến tranh lạnh" tại một fintech ở TP.HCM
Tại một công ty fintech khoảng 120 người ở Quận 1, TP.HCM, đội Scrum "Payments" có hai senior là Tuấn và Minh. Suốt ba sprint liền, velocity tụt từ 42 xuống 28 điểm. Trong Daily Scrum, hai người không bao giờ phản hồi nhau; các pull request của người này bị người kia review chậm trễ và soi mói. Nguồn cơn: ở sprint trước, Minh đã merge một thay đổi kiến trúc mà không hỏi Tuấn, làm hỏng một module Tuấn phụ trách trước demo.
Scrum Master Hương ban đầu chọn chế độ Avoiding — hy vọng hai người tự nguôi. Sau hai sprint thấy không ổn, cô chuyển hướng. Cô gặp riêng từng người (1-on-1) để hiểu lợi ích thật sự: Tuấn cảm thấy bị thiếu tôn trọng, còn Minh cảm thấy bị cản trở vì quy trình review quá chậm. Đây rõ ràng là relationship conflict đan xen process conflict, không phải thuần kỹ thuật.
Hương tổ chức một buổi đối thoại có facilitation, áp dụng tinh thần Collaborating. Cô đặt một quy tắc: mỗi người nói về tác động lên bản thân chứ không quy kết động cơ của người kia. Kết quả: hai người thống nhất một "definition of done cho thay đổi kiến trúc" (phải có một buổi design review 15 phút), và Minh xin lỗi về việc merge âm thầm. Velocity hồi phục về 40 ở sprint kế tiếp.
Bài học: Avoiding là một lựa chọn hợp lệ để hạ nhiệt ban đầu, nhưng nó có "hạn sử dụng". Khi xung đột bắt đầu ảnh hưởng tới giá trị giao cho khách hàng, Scrum Master phải chủ động chuyển sang Collaborating — và chìa khóa là tách tác động khỏi quy kết động cơ.
Tình huống 2 — PO và Tech Lead cãi nhau về kiến trúc, cần quyết định gấp
Tại một startup logistics ở Singapore phục vụ thị trường Đông Nam Á, hạn ra mắt tính năng theo dõi đơn hàng cho đối tác lớn chỉ còn 5 ngày. Product Owner muốn ship nhanh bằng giải pháp tạm; Tech Lead khăng khăng phải refactor để tránh nợ kỹ thuật, mất thêm 2 tuần. Cuộc họp planning biến thành tranh cãi gay gắt.
Scrum Master nhận ra đây là task conflict thật sự (về giải pháp), nhưng đang leo thang thành relationship conflict vì cả hai bắt đầu công kích cá nhân. Anh không chọn Collaborating (không đủ thời gian cho win-win lý tưởng), cũng không để PO dùng Competing áp đảo. Anh đề xuất Compromising có thời hạn: ship giải pháp tạm cho đúng hạn đối tác, nhưng đưa khoản refactor vào Product Backlog như một mục ưu tiên cao với cam kết rõ ràng từ PO sẽ làm trong sprint kế. Anh ghi lại quyết định và rủi ro nợ kỹ thuật một cách minh bạch (làm rõ "cái giá" để PO chịu trách nhiệm).
Bài học: Khi quyền lực hai bên cân bằng và thời gian gấp, Compromising là chế độ thực dụng. Nhưng một thỏa hiệp tốt phải minh bạch về cái giá phải trả và có cam kết theo dõi — nếu không, nó chỉ là "đá quả bóng" sang tương lai.
Tình huống 3 — Căng thẳng văn hóa giữa team Việt Nam và đối tác Mỹ
Một công ty gia công phần mềm ở Hà Nội làm cho khách hàng Mỹ. Phía Mỹ phàn nàn rằng team Việt "không bao giờ nói thẳng vấn đề" và "luôn nói yes rồi không kịp". Phía Việt thấy đối tác "thô lỗ, ép tiến độ". Đây là xung đột có yếu tố văn hóa: phong cách giao tiếp high-context (Việt Nam) gặp low-context (Mỹ).
Scrum Master không vội đứng về bên nào. Cô dùng chế độ pha trộn: với áp lực giao tiếp thẳng từ phía Mỹ, cô Accommodating ở mức độ giúp đội Việt tập nói rõ rủi ro sớm hơn (tạo một mục "risks & blockers" cố định trong báo cáo). Đồng thời cô giúp phía Mỹ hiểu rằng việc team Việt im lặng không phải là che giấu, mà là cách thể hiện tôn trọng — và đề nghị họ chủ động hỏi mở. Cô thiết lập một "team working agreement" chung về cách nêu vấn đề, giảm phụ thuộc vào suy đoán văn hóa.
Bài học: Xung đột xuyên văn hóa thường không phải lỗi của ai cả — nó là sự khác biệt trong "luật ngầm" giao tiếp. Scrum Master cần biến luật ngầm thành luật rõ ràng (explicit agreements) thay vì kỳ vọng hai bên tự đoán ý nhau.
Hướng dẫn từng bước
Khi đối diện một xung đột đáng kể, hãy đi theo quy trình sau:
- Quan sát và đặt tên (Observe & Name): Nhận diện dấu hiệu sớm — im lặng bất thường trong Daily, sub-team hình thành, review chậm, ngôn ngữ cơ thể phòng thủ. Đừng phủ nhận xung đột.
- Chẩn đoán loại xung đột: Đây là task, relationship hay process conflict? Hỏi riêng từng bên nếu cần. Task conflict thường có thể để đội tranh luận; relationship conflict cần can thiệp sớm hơn.
- Tìm lợi ích thật sự đằng sau lập trường (Interests, not Positions): Mượn từ phương pháp Harvard Negotiation — đừng dừng ở cái họ đòi (position), hãy đào tới vì sao họ cần (interest). "Tôi muốn refactor" có thể che giấu lợi ích "tôi sợ bị đổ lỗi khi hệ thống sập".
- Chọn chế độ TKI phù hợp cho bối cảnh: Cân nhắc tầm quan trọng của vấn đề, thời gian, và quan hệ lâu dài. Chọn một chế độ có chủ đích thay vì phản ứng theo bản năng.
- Tạo không gian an toàn để đối thoại: Đặt ground rules (nói về tác động, không quy kết động cơ; một người nói tại một thời điểm). Dùng câu hỏi mạnh thay vì đưa lời khuyên.
- Hướng tới thỏa thuận cụ thể và có thể kiểm chứng: Kết thúc bằng hành động rõ ràng, ai làm gì, kiểm tra lại khi nào. Ghi vào working agreement nếu cần.
- Theo dõi và củng cố: Quay lại sau 1–2 sprint. Một xung đột "được giải quyết" trên giấy mà không theo dõi thường tái phát.
Lỗi thường gặp & mẹo
- Luôn ép về Collaborating: Tốn thời gian cho những chuyện nhỏ làm đội mệt mỏi. Mẹo: hỏi "vấn đề này có đủ quan trọng và quan hệ có đủ giá trị để xứng đáng một buổi Collaborating không?".
- Lạm dụng Avoiding quá lâu: Né tránh hợp lý để hạ nhiệt, nhưng nếu kéo dài, xung đột âm ỉ sẽ phá psychological safety. Đặt cho mình một "deadline" để xem lại.
- Nhầm task conflict thành relationship conflict: Dập tắt mọi tranh luận làm đội mất khả năng ra quyết định tốt. Mẹo: tranh luận lành mạnh tập trung vào ý tưởng, độc hại khi chuyển sang con người.
- Đứng ra làm quan tòa: Khi Scrum Master tự phán xử ai đúng, bạn lấy mất quyền tự quản của đội và biến mình thành điểm phụ thuộc. Hãy là facilitator.
- Quy kết động cơ: "Anh ấy cố tình phá" là giả định nguy hiểm. Mẹo: dùng mẫu câu "Khi [sự việc] xảy ra, tôi cảm thấy [tác động]" thay vì "Anh đã cố ý...".
- Bỏ qua yếu tố văn hóa và quyền lực: Trong bối cảnh Việt Nam, người ít thâm niên thường ngại nói thẳng với người cao tuổi/cấp trên. Tạo kênh an toàn (1-on-1, ẩn danh) để lắng nghe phía yếu thế.
Bài tập thực hành
- Tự đánh giá TKI: Nhớ lại ba xung đột gần nhất bạn tham gia. Với mỗi xung đột, bạn đã dùng chế độ TKI nào? Đó có phải lựa chọn có chủ đích hay phản xạ? Nếu làm lại, bạn sẽ chọn khác không?
- Phân loại xung đột: Lấy một căng thẳng đang diễn ra trong đội bạn. Viết ra: nó là task, relationship hay process conflict? Lập trường (position) của mỗi bên là gì, và lợi ích thật sự (interest) đằng sau là gì?
- Đóng vai: Cùng một đồng nghiệp, diễn lại Tình huống 2 (PO vs Tech Lead, hạn 5 ngày). Một người làm PO, một làm Tech Lead, bạn làm Scrum Master. Thử dẫn dắt tới một Compromising minh bạch về cái giá phải trả trong 10 phút.
- Soạn ground rules: Viết 3 quy tắc nền tảng bạn sẽ đặt ra trước một buổi đối thoại xung đột, đảm bảo chúng giúp tách con người khỏi vấn đề.
Tóm tắt
Giải quyết xung đột ở cấp PSM II không phải là dập tắt mọi bất đồng, mà là chẩn đoán đúng và can thiệp có chủ đích. Mô hình Thomas-Kilmann cho bạn năm chế độ — Competing, Collaborating, Compromising, Avoiding, Accommodating — và sự trưởng thành nằm ở chỗ biết chọn đúng chế độ cho đúng bối cảnh, chứ không tôn thờ một chế độ duy nhất. Trước khi chọn, hãy phân loại xung đột (task / relationship / process) và đào sâu tới lợi ích thật thay vì lập trường bề mặt. Vai trò của bạn là facilitator tạo không gian an toàn, không phải quan tòa phán xử. Và cuối cùng: mọi thỏa thuận đều cần cụ thể, minh bạch về cái giá, và được theo dõi — vì một xung đột "giải quyết trên giấy" mà không củng cố sẽ luôn quay trở lại.