Mở đầu — vì sao bài này quan trọng
Nếu bạn mở Scrum Guide ra và tìm từ "manager", bạn sẽ không thấy nó ở đâu cả. Scrum chỉ có ba accountability: Product Owner, Scrum Master và Developers. Không có sếp, không có team lead, không có phòng nhân sự trong khung Scrum chính thống.
Nhưng đây là sự thật mà mọi Scrum Master ở trình độ PSM II buộc phải đối diện: gần như mọi tổ chức thật ngoài đời đều có manager. Có line manager (quản lý trực tiếp, người ký đánh giá hiệu suất của bạn), có functional manager (quản lý theo chức năng — trưởng phòng QA, trưởng phòng kỹ thuật), có engineering manager, delivery manager, và đôi khi cả một tầng director phía trên. Họ không biến mất chỉ vì công ty "đang làm Agile". Họ vẫn tuyển người, vẫn sa thải, vẫn quyết lương thưởng, vẫn duyệt ngân sách.
Ở PSM I, người ta thường dạy bạn một câu trả lời đơn giản và hơi ngây thơ: "Scrum không có manager, nên hãy bảo họ đừng can thiệp vào team." Cách tiếp cận đó sẽ khiến bạn thất bại thảm hại trong thực tế. Một Scrum Master giỏi không phủ nhận sự tồn tại của manager — họ học cách làm việc cùng manager để biến những người này từ rào cản tiềm tàng thành đồng minh chiến lược.
Bài này tập trung riêng vào mối quan hệ giữa Scrum Master và các manager: line manager và functional manager. Đây là một trong những mối quan hệ khó nhất, dễ gây hiểu lầm nhất, và cũng quyết định nhiều nhất đến khả năng sống sót của Scrum trong tổ chức. Làm tốt mối quan hệ này, bạn mở khóa được nguồn lực, sự bảo trợ và khả năng dỡ bỏ impediment ở tầng tổ chức. Làm sai, bạn sẽ liên tục bị kéo về mô hình command-and-control cũ.
Khái niệm cốt lõi
Manager là ai, và họ thực sự chịu trách nhiệm gì
Trước khi làm việc với một manager, bạn phải hiểu chính xác trách nhiệm thật của họ — không phải trách nhiệm bạn tưởng tượng. Trong đa số tổ chức Việt Nam và khu vực, manager nắm các quyền sau:
- Hire & fire — tuyển dụng và chấm dứt hợp đồng. Họ quyết ai vào team, ai rời đi.
- Compensation — đề xuất lương, thưởng, tăng lương, thăng chức.
- Career development — định hướng phát triển nghề nghiệp, training, mentoring cho cá nhân.
- Performance management — đánh giá hiệu suất (performance review), đặt mục tiêu cá nhân.
- Resource & budget — phân bổ ngân sách, công cụ, headcount.
- Functional standards — với functional manager (ví dụ trưởng phòng QA), họ giữ chuẩn nghề nghiệp và best practice của chuyên môn đó.
Lằn ranh giữa "quản lý con người" và "quản lý công việc"
Đây là khái niệm trung tâm của cả bài. Trong một tổ chức Scrum trưởng thành, có một sự phân chia rõ ràng:
- Quản lý CON NGƯỜI thuộc về manager: phát triển con người, năng lực, sự nghiệp, môi trường làm việc.
- Quản lý CÔNG VIỆC thuộc về team Scrum: cái gì làm trước (Product Owner), làm thế nào và ai làm (Developers tự tổ chức), và làm sao để team vận hành hiệu quả (Scrum Master).
Manager như một nguồn lực dỡ impediment
Một góc nhìn mà nhiều Scrum Master mới bỏ lỡ: manager thường là người có quyền lực tổ chức mà bạn không có. Bạn không thể tự duyệt mua một license công cụ trị giá 50 triệu, không thể tự điều chuyển một người từ phòng khác sang, không thể tự thay đổi chính sách của bộ phận IT. Nhưng manager có thể.
Vì vậy, đối với những impediment vượt khỏi tầm với của team, manager không phải là kẻ thù — họ là cây cầu. Scrum Master giỏi xây dựng quan hệ với manager chính là để khi cần leo thang một impediment ở tầng tổ chức, đã có sẵn niềm tin và kênh giao tiếp.
Chuyển hóa vai trò manager trong Agile
Trong các tổ chức Agile trưởng thành, vai trò manager dịch chuyển từ "người ra lệnh và kiểm soát" sang ba dạng mới:
- Người xây dựng môi trường (environment builder) — tạo điều kiện để team tự quản phát huy.
- Người phát triển năng lực (capability developer) — đầu tư vào kỹ năng và sự trưởng thành của con người.
- Người dỡ rào cản hệ thống (system-level impediment remover) — xử lý những vấn đề liên phòng ban mà team không chạm tới được.
Tình huống thực tế
Tình huống 1 — Functional manager "mượn người" giữa Sprint (công ty fintech tại TP.HCM)
Tại một công ty fintech khoảng 200 nhân sự ở Quận 1, TP.HCM, có ba Scrum team cùng chia sẻ một phòng QA tập trung. Trưởng phòng QA — chị Hương — là functional manager của tất cả tester. Giữa Sprint, chị thường xuyên "mượn" tester từ team này sang chữa cháy cho team khác mà không báo trước, vì theo chị "tester là tài nguyên chung của công ty".
Hậu quả: team của bạn cam kết một Sprint Goal cần kiểm thử nặng, nhưng đến ngày thứ 4 thì tester biến mất ba ngày. Velocity sụp, Sprint Goal trượt, và niềm tin của Product Owner với team lung lay.
Diễn giải: Scrum Master ở đây không đôi co kiểu "Scrum không cho phép chị làm vậy". Thay vào đó, anh hẹn cà phê riêng với chị Hương và làm ba việc: (1) thừa nhận trách nhiệm chính đáng của chị là đảm bảo chất lượng toàn công ty; (2) cho chị thấy bằng số liệu rằng mỗi lần rút tester giữa Sprint, team mất trung bình 1,5 ngày context-switching và một Sprint Goal bị trượt khiến cả phòng kinh doanh chậm ra mắt tính năng; (3) đề xuất một thỏa thuận: nếu cần điều chuyển, sẽ thông qua Scrum Master và Product Owner để cùng đánh giá tác động, thay vì rút trực tiếp.
Bài học: Functional manager có lý do chính đáng cho hành vi của mình. Đừng chống lại lý do đó — hãy chỉ ra cái giá ẩn (hidden cost) bằng dữ liệu và đề xuất một cơ chế thay thế tôn trọng cả hai bên. Dài hạn, giải pháp gốc rễ là đưa tester thành thành viên cố định của từng team (cross-functional), nhưng đó là cuộc thay đổi tổ chức cần thời gian.
Tình huống 2 — Line manager ép cam kết vượt năng lực (công ty gia công phần mềm)
Một công ty outsourcing khoảng 500 người tại Hà Nội, làm dự án cho khách hàng Nhật. Anh Tuấn là engineering manager kiêm line manager của toàn bộ Developer trong hai Scrum team. Trước mỗi Sprint Planning, anh Tuấn gặp riêng từng Developer và nói: "Sprint này phải xong 40 story point nhé, anh đã hứa với khách rồi." Developer sợ ảnh hưởng đánh giá cuối năm nên gật đầu, dù năng lực thật chỉ tầm 28-30 point.
Kết quả: team liên tục cam kết quá tay, làm overtime, chất lượng tụt, bug production tăng. Trong retrospective, không ai dám nói thật vì anh Tuấn đôi khi ngồi dự.
Diễn giải: Đây là một impediment ở tầng line management — và nó cực kỳ nhạy cảm vì anh Tuấn chính là người chấm điểm Developer. Scrum Master xử lý theo nhiều lớp. Thứ nhất, đảm bảo anh Tuấn không ngồi trong retrospective để khôi phục an toàn tâm lý. Thứ hai, gặp riêng anh Tuấn để tách bạch hai chuyện: cam kết với khách hàng là việc của Product Owner thông qua thương lượng phạm vi và Sprint Goal — không phải áp số xuống từng Developer. Thứ ba, dùng dữ liệu thực: cho anh thấy biểu đồ rằng khi team cam kết 40 nhưng chỉ giao được 30, độ tin cậy với khách hàng Nhật còn tệ hơn so với cam kết 30 và giao đủ 30. Khách Nhật trọng chữ tín và sự ổn định hơn con số cao.
Bài học: Khi line manager dùng quyền lực đánh giá để ép công việc, Scrum Master phải vừa bảo vệ an toàn tâm lý của team, vừa cho manager thấy rằng hành vi của họ đang phá hủy chính điều họ muốn (uy tín với khách hàng). Đừng tấn công con người — tấn công vấn đề, và gắn nó với mục tiêu mà manager quan tâm.
Tình huống 3 — Biến manager thành đồng minh dỡ impediment (startup thương mại điện tử)
Một startup e-commerce ở Singapore mở rộng sang thị trường Việt Nam, đội kỹ thuật khoảng 30 người. Team của bạn liên tục bị chặn vì quy trình phê duyệt truy cập production cực kỳ rườm rà — mỗi lần deploy phải chờ phòng Security duyệt thủ công, trung bình 3 ngày. Đây là impediment Scrum Master không thể tự giải quyết.
Diễn giải: Thay vì âm thầm chịu đựng, Scrum Master mang vấn đề đến engineering manager với một gói trình bày gọn: tần suất bị chặn (8 lần/tháng), tổng thời gian chờ (khoảng 24 ngày-người mỗi quý), và đề xuất giải pháp (cấp quyền tự động hóa cho pipeline CI/CD với cổng kiểm soát tự động). Manager — vốn có quan hệ và quyền lực với phòng Security mà Scrum Master không có — đã đứng ra đàm phán và trong sáu tuần, quy trình rút từ 3 ngày xuống còn vài giờ.
Bài học: Manager là kênh dỡ impediment ở tầng tổ chức hiệu quả nhất mà Scrum Master sở hữu. Bí quyết là đến với họ kèm dữ liệu, tác động kinh doanh, và một đề xuất cụ thể — chứ không phải đến để than phiền. Khi bạn làm manager trông tốt trong mắt cấp trên của họ (vì đã giải quyết được vấn đề có số liệu rõ ràng), bạn đã biến họ thành đồng minh lâu dài.
Hướng dẫn từng bước
Dưới đây là quy trình thực dụng để xây dựng và vận hành mối quan hệ với manager.
Bước 1 — Lập bản đồ các manager liên quan. Xác định ai là line manager của từng thành viên, ai là functional manager (QA, BA, kỹ thuật), ai nắm ngân sách. Vẽ rõ mỗi người chịu trách nhiệm gì và họ có thể giúp/cản trở team ở điểm nào.
Bước 2 — Thiết lập quan hệ trước khi cần đến. Đừng đợi đến lúc khủng hoảng mới gặp manager lần đầu. Hẹn cà phê, lắng nghe áp lực và mục tiêu của họ. Một mối quan hệ có sẵn niềm tin sẽ cứu bạn khi xung đột xảy ra.
Bước 3 — Làm rõ ranh giới một cách tôn trọng. Trong một buổi nói chuyện thẳng thắn, thống nhất nguyên tắc: manager lo phát triển con người và môi trường; team lo cách thức và thứ tự công việc. Đóng khung điều này như một sự phân công có lợi cho manager (họ được giải phóng khỏi việc giao task vụn vặt để tập trung vào việc lớn hơn).
Bước 4 — Chuyển hướng đúng yêu cầu đến đúng người. Khi manager đụng vào việc của team, đừng chặn cứng. Hãy redirect: yêu cầu về thứ tự ưu tiên → đưa đến Product Owner; yêu cầu về cách làm → để Developers tự quyết; yêu cầu về hiệu suất cá nhân → đó đúng là việc của manager.
Bước 5 — Mời manager vào đúng các event. Sprint Review là cánh cửa lý tưởng để manager thấy giá trị team tạo ra và cho feedback ở cấp sản phẩm. Ngược lại, giữ manager ngoài retrospective và Daily Scrum để bảo vệ không gian tự tổ chức của team.
Bước 6 — Dùng manager để dỡ impediment tổ chức. Với mỗi impediment vượt tầm team, chuẩn bị: mô tả vấn đề, tần suất, tác động (bằng số), và đề xuất giải pháp. Mang gói này đến đúng manager có quyền hành động.
Bước 7 — Coach manager về vai trò Agile. Theo thời gian, giúp manager dịch chuyển từ kiểm soát công việc sang phát triển con người và hệ thống. Đo lường thành công bằng việc team ngày càng tự quản hơn, còn manager ngày càng tạo điều kiện nhiều hơn.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi manager là kẻ thù của Scrum. Đây là sai lầm phổ biến nhất của Scrum Master non kinh nghiệm. Thái độ đối đầu khiến manager phòng thủ và càng siết chặt kiểm soát. Mẹo: luôn bắt đầu bằng giả định thiện chí — manager hành động vì áp lực thật, không phải vì muốn phá Scrum.
Lỗi 2 — Trích dẫn Scrum Guide như kinh thánh. Nói "Scrum Guide không cho phép điều đó" gần như không bao giờ thuyết phục được một manager đang chịu áp lực kinh doanh. Mẹo: nói bằng ngôn ngữ kết quả và rủi ro kinh doanh, không phải bằng điều khoản lý thuyết.
Lỗi 3 — Bảo vệ team kiểu xây tường. Một số Scrum Master tự hào "tôi che chắn tuyệt đối cho team khỏi mọi manager". Điều này cô lập team và làm manager mất khả năng giúp đỡ. Mẹo: hãy là cây cầu hai chiều, không phải bức tường.
Lỗi 4 — Bỏ qua vai trò chính đáng của manager. Phát triển sự nghiệp, đào tạo, đánh giá hiệu suất là việc thật và quan trọng. Nếu bạn phủ nhận chúng, bạn mất uy tín. Mẹo: công khai tôn trọng và bảo vệ những phần việc thuộc về manager.
Lỗi 5 — Không phân biệt line và functional manager. Hai loại này có quyền lực và mối quan tâm khác nhau; cách tiếp cận giống hệt nhau sẽ phản tác dụng. Mẹo: với functional manager, nhấn mạnh chất lượng chuyên môn; với line manager, nhấn mạnh phát triển con người và sự ổn định cam kết.
Mẹo bổ sung: Luôn làm manager "trông tốt" trước cấp trên của họ khi bạn giải quyết được vấn đề chung. Sự công nhận này là nền tảng bền vững nhất của liên minh.
Bài tập thực hành
- Lập bản đồ quyền lực. Vẽ sơ đồ tất cả manager (line và functional) liên quan đến team bạn. Với mỗi người, ghi: trách nhiệm chính đáng của họ, một điểm họ có thể giúp team dỡ impediment, và một điểm họ đang vô tình lấn sang việc của team.
- Phân loại tình huống. Lấy năm yêu cầu gần nhất mà một manager đưa xuống team bạn. Với mỗi yêu cầu, xác định nó thuộc về ai: Product Owner (ưu tiên), Developers (cách làm), hay đúng là manager (con người/hiệu suất). Viết câu redirect bạn sẽ dùng cho mỗi trường hợp.
- Đóng vai. Cùng một đồng nghiệp đóng vai tình huống line manager ép cam kết 40 point khi team chỉ làm được 30. Tập một cuộc đối thoại 1-on-1 với manager, dùng dữ liệu và gắn vào mục tiêu của họ, không dùng câu "Scrum không cho phép".
- Chuẩn bị gói leo thang. Chọn một impediment thật vượt tầm team hiện tại. Viết một trang gồm: mô tả, tần suất, tác động bằng số, và đề xuất giải pháp. Đây là tài liệu bạn sẽ mang đến manager có quyền hành động.
Tóm tắt
Scrum Guide không có manager, nhưng tổ chức thật thì có — và đó là điều một Scrum Master PSM II phải làm chủ thay vì né tránh. Manager nắm các quyền chính đáng: tuyển dụng, sa thải, lương thưởng, phát triển sự nghiệp và đánh giá hiệu suất; những quyền này không xung đột với Scrum nếu họ ở đúng làn của mình.
Lằn ranh cốt lõi là: manager quản lý con người và môi trường, team Scrum quản lý công việc. Khi manager lấn sang việc của team, vai trò của Scrum Master không phải là chống đối, mà là redirect đúng người (Product Owner cho ưu tiên, Developers cho cách làm) một cách tôn trọng.
Quan trọng hơn cả, manager là nguồn lực mạnh nhất để dỡ impediment ở tầng tổ chức — thứ mà Scrum Master không có quyền tự làm. Hãy xây quan hệ trước khi cần đến, đến với họ bằng dữ liệu và đề xuất chứ không phải lời than phiền, và kiên nhẫn coach họ chuyển từ kiểm soát công việc sang phát triển con người và hệ thống. Làm tốt mối quan hệ này, bạn không chỉ bảo vệ được Scrum mà còn biến những người quyền lực nhất trong tổ chức thành đồng minh cho hành trình trưởng thành của team.