Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa nhận một đội mới gồm tám người. Họ giỏi chuyên môn, nhưng tuần đầu tiên đã xảy ra ba va chạm nhỏ: một bạn dev gửi tin nhắn quan trọng lúc 11 giờ đêm và bực mình vì sáng hôm sau chưa ai trả lời; một bạn khác liên tục đi họp Daily trễ năm phút khiến cả đội phải đợi; và khi review code, hai người tranh cãi gay gắt vì một người nghĩ "comment chỉ là gợi ý" còn người kia nghĩ "comment là phải sửa". Không ai sai cả. Vấn đề là cả đội chưa bao giờ ngồi lại để thống nhất rõ ràng cách họ làm việc với nhau.
Đó chính xác là khoảng trống mà Team Working Agreements (Thỏa thuận làm việc nhóm) lấp đầy. Đây là một trong những công cụ đơn giản nhất nhưng có sức mạnh ngầm lớn nhất trong toolbox của một Scrum Master. Nó không phải là quy trình cồng kềnh, không phải là tài liệu pháp lý, mà là một tập hợp các "luật chơi" do chính đội tự đặt ra và tự cam kết tuân theo.
Là Scrum Master, bạn sẽ thường xuyên thấy mình ở vai trò "người giữa": ai đó phàn nàn với bạn về đồng đội thay vì nói thẳng. Working Agreements là cách bạn chuyển những kỳ vọng ngầm — vốn dễ gây xung đột — thành những thỏa thuận hiển ngôn mà cả đội cùng sở hữu. Khi có rồi, bạn không còn phải đóng vai "cảnh sát"; bạn chỉ cần chỉ vào tấm bảng và hỏi: "Chúng ta đã thống nhất điều gì nhỉ?" Trong bài này, chúng ta sẽ học cách tạo ra, duy trì và làm sống động những thỏa thuận đó.
Khái niệm cốt lõi
Working Agreements là gì?
Working Agreements là một bộ các quy tắc hiển ngôn (explicit) mô tả cách một đội đồng ý làm việc cùng nhau. Từ khóa quan trọng nhất ở đây là hiển ngôn — biến những kỳ vọng nằm trong đầu mỗi người thành thứ được viết ra, nhìn thấy được, và ai cũng đồng thuận.
Mỗi đội đều có "luật ngầm". Vấn đề là luật ngầm của bạn và luật ngầm của tôi không giống nhau. Bạn nghĩ đến muộn 10 phút là bình thường; tôi nghĩ đó là thiếu tôn trọng. Khi không nói ra, những khác biệt này âm ỉ rồi bùng nổ. Working Agreements là cách đưa chúng ra ánh sáng để cả đội cùng chọn một chuẩn chung.
Ba đặc tính khiến một thỏa thuận thực sự "có sức"
Không phải danh sách quy tắc nào dán lên tường cũng là Working Agreement thật sự. Một thỏa thuận tốt cần ba đặc tính:
- Do chính đội tạo ra (team-owned). Nếu Scrum Master hay Manager áp đặt từ trên xuống, đó là nội quy, không phải thỏa thuận. Sức mạnh của Working Agreement đến từ việc chính đội nghĩ ra và cam kết. Người ta giữ lời với điều họ tự hứa, không phải điều bị bắt hứa.
- Cụ thể và quan sát được. "Tôn trọng lẫn nhau" là một câu khẩu hiệu vô dụng vì không ai đo được. "Khi không đồng ý với một ý kiến, ta phản hồi vào nội dung chứ không công kích cá nhân" thì cụ thể hơn nhiều. Quy tắc tốt phải khiến người ngoài cũng nhận ra được khi nào nó bị vi phạm.
- Sống động và có thể thay đổi (living document). Working Agreement không phải bia đá. Đội thay đổi, hoàn cảnh thay đổi, thỏa thuận cũng phải tiến hóa. Retrospective là nơi lý tưởng để bổ sung, sửa hoặc loại bỏ những điều không còn phù hợp.
Những lĩnh vực thường được thỏa thuận
Khi tổ chức buổi xây dựng Working Agreements, bạn nên dẫn dắt đội suy nghĩ qua một số nhóm chủ đề. Đây là những "vùng đất" hay phát sinh hiểu lầm nhất:
Kênh giao tiếp (Communication channels). Khi nào dùng Slack/Telegram, khi nào dùng email, khi nào gọi điện hay gặp trực tiếp? Một thỏa thuận điển hình: "Việc khẩn cần phản hồi trong ngày thì nhắn Slack; việc cần lưu vết hoặc liên quan bên ngoài thì email; quyết định lớn thì họp trực tiếp/online." Đội cũng nên thỏa thuận thời gian phản hồi kỳ vọng — ví dụ "tin nhắn trong giờ làm việc cố gắng trả lời trong 2 giờ, ngoài giờ thì không bắt buộc."
Giờ giấc và sự hiện diện (Core hours & availability). Mấy giờ thì cả đội chắc chắn online để hợp tác (core hours)? Daily Scrum lúc mấy giờ và quy tắc khi đến trễ là gì? Camera bật hay tắt khi họp online? Đặc biệt quan trọng với đội làm việc linh hoạt hoặc remote.
Cách họp (Meeting etiquette). Đến đúng giờ, tắt thông báo, không vừa họp vừa làm việc khác, ai cũng được nói. Một quy tắc rất thực dụng: "Họp bắt đầu đúng giờ kể cả khi thiếu người."
Định nghĩa và quy trình kỹ thuật. Code review trong bao lâu phải xong? Bao nhiêu người approve thì được merge? Khi build đỏ thì ưu tiên ra sao? (Lưu ý: chi tiết về Definition of Done thuộc về một công cụ riêng — ở đây ta chỉ thỏa thuận hành vi xoay quanh nó.)
Ra quyết định và xử lý bất đồng. Khi đội không thống nhất, ta quyết theo cách nào — đa số, đồng thuận, hay người phụ trách quyết? Bất đồng kỹ thuật giải quyết ra sao mà không biến thành xung đột cá nhân?
Cách đưa và nhận phản hồi, cách báo khi gặp trở ngại (raise blocker). Khi nào và bằng cách nào một người báo rằng mình đang bị kẹt?
Bạn không cần phủ hết mọi lĩnh vực ngay lần đầu. Thực tế, một đội mới chỉ nên bắt đầu với 5–8 thỏa thuận quan trọng nhất rồi bổ sung dần.
Tình huống thực tế
Tình huống 1 — Đội remote ở một công ty fintech Hà Nội và "cơn lũ Slack lúc nửa đêm"
Tại một công ty fintech ở Hà Nội (tạm gọi là VietPay), đội Payment gồm chín người chuyển sang làm hybrid sau dịch. Trong ba tuần, mức độ hài lòng của đội rớt thấy rõ trong khảo sát nội bộ. Khi Scrum Master đào sâu, gốc rễ lộ ra: một bạn senior có thói quen code khuya và hay tag đồng đội vào Slack lúc 11–12 giờ đêm. Hai bạn có con nhỏ cảm thấy bị áp lực phải trả lời, dù không ai yêu cầu. Họ ngại nói ra vì sợ bị xem là "không tận tâm".
Scrum Master tổ chức một buổi Working Agreements 60 phút. Đội cùng viết ra quy tắc: "(1) Ngoài khung 8h–18h, mọi tin nhắn Slack mặc định là không khẩn; không ai bị kỳ vọng phải trả lời. (2) Ai muốn làm khuya cứ tự nhiên, nhưng dùng tính năng 'schedule send' để tin nhắn được gửi vào sáng hôm sau. (3) Việc thực sự khẩn cấp ngoài giờ thì gọi điện thoại, không nhắn Slack."
Bài học: Xung đột không nằm ở con người mà ở kỳ vọng ngầm khác nhau về "khi nào thì phải trả lời". Khi biến nó thành quy tắc cụ thể, ai cũng được giải phóng — bạn senior vẫn làm khuya thoải mái, hai bạn kia hết áy náy. Một thỏa thuận tốt thường khiến mọi bên cùng thắng chứ không phải bắt ai phải hy sinh.
Tình huống 2 — Startup thương mại điện tử ở TP.HCM và buổi Daily "mãi không bắt đầu"
Một startup e-commerce ở TP.HCM (tạm gọi Shopla) có đội bảy người. Daily Scrum lên lịch 9h30 nhưng thực tế gần như luôn bắt đầu lúc 9h40 vì phải đợi vài người. Trung bình mỗi ngày mất 10 phút chờ đợi nhân với 7 người là khoảng 70 phút công bị lãng phí — một tuần là gần 6 giờ người, tương đương gần một ngày công.
Scrum Master không ra lệnh. Thay vào đó, trong retro, anh đưa con số đó lên màn hình và để đội tự phản ứng. Đội tự đề xuất hai thỏa thuận: "(1) Daily bắt đầu đúng 9h30 dù thiếu ai; người đến trễ tự cập nhật sau qua kênh chat. (2) Ai biết trước mình bận thì báo trong nhóm trước 9h." Họ còn thêm một "luật chơi vui": ai trễ ba lần trong một sprint thì mời cả đội một cữ cà phê — do chính đội nghĩ ra, nhẹ nhàng và không mang tính trừng phạt.
Bài học: Dữ liệu cụ thể thuyết phục mạnh hơn lời rao giảng. Và khi để đội tự nghĩ ra giải pháp (kể cả cơ chế nhắc nhở vui vẻ), họ tuân thủ tốt hơn nhiều so với khi bị Scrum Master áp luật. Sau hai tuần, Daily bắt đầu đúng giờ trên 90% số buổi.
Tình huống 3 — Đội phân tán Việt Nam – Singapore và bất đồng về code review
Một đội sản phẩm phân tán giữa Việt Nam và Singapore (tạm gọi NovaTech) liên tục căng thẳng quanh chuyện code review. Phía Singapore quen phong cách review thẳng thắn, comment ngắn gọn kiểu "this is wrong, change it". Phía Việt Nam cảm thấy bị xúc phạm và đôi khi giận dỗi không phản hồi. Pull request thì ùn ứ, có cái nằm ba ngày chưa ai duyệt.
Scrum Master tổ chức buổi Working Agreements xoáy riêng vào review. Đội thống nhất: "(1) Mọi comment review nhắm vào code, không nhắm vào người; ưu tiên đặt câu hỏi ('Liệu chỗ này có thể bị null không?') thay vì ra lệnh. (2) PR phải được review trong vòng một ngày làm việc; nếu reviewer bận thì báo và chuyển cho người khác. (3) Bất đồng kỹ thuật chưa giải quyết được sau hai vòng comment thì chuyển sang gọi 15 phút thay vì tiếp tục gõ chữ."
Bài học: Khác biệt văn hóa giao tiếp là nguồn xung đột rất thật, đặc biệt trong các đội xuyên biên giới phổ biến ở Đông Nam Á. Working Agreements là nơi an toàn để cả đội nói thẳng về phong cách giao tiếp và thống nhất một chuẩn chung, thay vì để mỗi bên âm thầm khó chịu.
Hướng dẫn từng bước
Dưới đây là cách tổ chức một buổi xây dựng Working Agreements hiệu quả, thường gói gọn trong 45–60 phút.
Bước 1 — Chuẩn bị bối cảnh và lý do. Mở đầu bằng việc giải thích vì sao ta làm việc này: để giảm hiểu lầm, để mọi người cùng một trang, để đội tự quyết cách làm việc của mình. Nhấn mạnh đây là thỏa thuận của đội, không phải nội quy của Scrum Master. Nếu là đội mới hoàn toàn, đây là một phần tự nhiên của giai đoạn hình thành đội.
Bước 2 — Gợi mở các lĩnh vực. Đưa ra các nhóm chủ đề (giao tiếp, giờ giấc, họp, review, ra quyết định, phản hồi...) như những điểm khơi gợi. Đừng để trang giấy trắng. Bạn có thể hỏi: "Tuần qua điều gì khiến bạn khó chịu mà ngại nói ra?" Câu hỏi này thường lôi ra đúng những vấn đề cần thỏa thuận nhất.
Bước 3 — Brainstorm cá nhân rồi gom nhóm. Cho mỗi người viết đề xuất riêng lên sticky note (vài phút im lặng) trước khi chia sẻ. Cách này đảm bảo người ít nói cũng có tiếng nói, tránh việc một hai người lớn tiếng lấn át. Sau đó dán lên bảng và gom các ý tương tự.
Bước 4 — Thảo luận và mài giũa cho cụ thể. Với mỗi đề xuất, hỏi: "Quy tắc này trông như thế nào trong thực tế? Làm sao biết nó bị vi phạm?" Biến những câu khẩu hiệu mơ hồ thành hành vi quan sát được. Loại bỏ những điều quá hiển nhiên hoặc không ai thực sự quan tâm.
Bước 5 — Kiểm tra đồng thuận. Đây là bước then chốt. Dùng một kỹ thuật như "giơ ngón tay 1–5" (fist of five) hoặc bỏ phiếu chấm. Một thỏa thuận chỉ thành luật khi cả đội đủ ủng hộ — nếu còn người phản đối mạnh, hãy thảo luận tiếp hoặc bỏ qua. Đừng ép buộc; thỏa thuận bị ép sẽ không được tôn trọng.
Bước 6 — Giới hạn số lượng. Đừng tham. Chốt lại 5–8 thỏa thuận quan trọng nhất. Một danh sách 20 quy tắc không ai nhớ nổi thì vô dụng. Ít mà thật thì hơn nhiều mà hình thức.
Bước 7 — Làm cho nó hiển thị. Dán Working Agreements ở nơi ai cũng thấy: một góc bảng vật lý, một trang ghim trong kênh chat, một thẻ trên đầu board. Thỏa thuận khuất tầm mắt là thỏa thuận sẽ chết.
Bước 8 — Định kỳ xem lại. Đưa Working Agreements vào lịch retro định kỳ (ví dụ mỗi 2–3 sprint). Hỏi: "Quy tắc nào ta vẫn giữ tốt? Quy tắc nào đã lỗi thời? Có tình huống mới nào cần thỏa thuận thêm không?"
Lỗi thường gặp & mẹo
Lỗi 1 — Scrum Master tự viết rồi bắt đội ký. Đây là sai lầm phổ biến nhất và làm hỏng toàn bộ giá trị của công cụ. Khi bạn áp luật từ trên xuống, đội xem đó là việc của bạn, không phải của họ. Mẹo: hãy đóng vai người điều phối (facilitator), không phải người ra luật. Đặt câu hỏi, ghi chép, để đội nói.
Lỗi 2 — Quy tắc quá chung chung, sáo rỗng. "Tôn trọng nhau", "giao tiếp cởi mở", "luôn cố gắng hết sức" — nghe hay nhưng vô nghĩa vì không đo được. Mẹo: với mỗi quy tắc, hỏi "trông nó như thế nào trong một ngày làm việc thật?" cho tới khi nó trở thành hành vi cụ thể.
Lỗi 3 — Viết xong rồi quên. Rất nhiều đội tổ chức một buổi hoành tráng, dán bảng đẹp đẽ, rồi không bao giờ nhắc lại. Sau một tháng không ai nhớ. Mẹo: để bảng ở nơi dễ thấy và chủ động viện dẫn nó khi có tình huống liên quan — "Mình nhớ đội có thỏa thuận về việc này, ta xem lại nhé".
Lỗi 4 — Quá nhiều quy tắc. Danh sách dài khiến không ai nhớ và biến đội thành bộ máy quan liêu. Mẹo: giữ tối đa khoảng 7 điều; muốn thêm cái mới thì cân nhắc bỏ bớt cái cũ.
Lỗi 5 — Không có cơ chế khi ai đó vi phạm. Nếu phá vỡ thỏa thuận mà chẳng có gì xảy ra, thỏa thuận sẽ mục dần. Mẹo: thỏa thuận luôn với đội rằng bất kỳ ai cũng có quyền (và trách nhiệm) nhẹ nhàng nhắc đồng đội: "Này, chỗ này hơi lệch với thỏa thuận của mình đấy." Tự đội giám sát lẫn nhau, không phải Scrum Master đi bắt lỗi.
Mẹo nâng cao — Dùng Working Agreements để gỡ xung đột mà không cần đối đầu. Khi A phàn nàn về B, thay vì phân xử, hãy hỏi: "Đội mình đã có thỏa thuận nào về tình huống này chưa? Nếu chưa, đây có phải điều ta nên thỏa thuận không?" Cách này chuyển một mâu thuẫn cá nhân thành một cuộc thảo luận về quy tắc chung — bớt cảm tính, dễ giải quyết hơn nhiều.
Bài tập thực hành
Bài tập 1 — Soi kỳ vọng ngầm của chính bạn. Viết ra 5 "luật ngầm" mà bạn vẫn mặc định đúng khi làm việc nhóm (ví dụ: "tin nhắn nên được trả lời trong vòng một giờ"). Với mỗi luật, tự hỏi: liệu đồng đội của mình có chắc chắn nghĩ giống vậy không? Bài tập này giúp bạn cảm nhận mức độ phổ biến của kỳ vọng ngầm.
Bài tập 2 — Mài một câu khẩu hiệu thành quy tắc cụ thể. Lấy ba câu chung chung sau và viết lại cho cụ thể, quan sát được: "Tôn trọng lẫn nhau", "Giao tiếp hiệu quả", "Họp đúng giờ". Ví dụ "Họp đúng giờ" có thể thành "Họp bắt đầu đúng giờ kể cả khi thiếu người; ai trễ tự cập nhật sau".
Bài tập 3 — Thiết kế kịch bản buổi 45 phút. Giả sử bạn vừa nhận một đội mới sáu người, một nửa ở TP.HCM một nửa làm remote ở tỉnh. Hãy phác thảo agenda buổi xây dựng Working Agreements: bạn mở đầu thế nào, gợi mở những lĩnh vực nào trước, dùng kỹ thuật gì để kiểm tra đồng thuận. Viết ra 6 thỏa thuận bạn dự đoán đội này sẽ cần nhất.
Bài tập 4 (nếu đang dẫn một đội thật) — Chạy thử và theo dõi. Tổ chức buổi Working Agreements thật, chốt tối đa 7 thỏa thuận, dán nơi dễ thấy. Sau hai sprint, đưa lại vào retro và hỏi đội: điều nào đang giữ tốt, điều nào cần sửa, có cần thêm điều mới không. Ghi lại sự thay đổi.
Tóm tắt
Team Working Agreements là công cụ biến những kỳ vọng ngầm — vốn là mầm mống của hầu hết xung đột trong đội — thành các quy tắc hiển ngôn mà cả đội cùng sở hữu. Sức mạnh của nó không nằm ở danh sách quy tắc, mà ở quá trình cả đội cùng ngồi xuống, nói thật về cách họ muốn làm việc với nhau, và cùng cam kết.
Những điểm cốt lõi cần nhớ:
- Một Working Agreement tốt phải do chính đội tạo ra, cụ thể và quan sát được, và là tài liệu sống được xem lại định kỳ.
- Các lĩnh vực hay cần thỏa thuận nhất: kênh giao tiếp và thời gian phản hồi, giờ giấc và sự hiện diện, cách họp, quy trình review, cách ra quyết định và xử lý bất đồng.
- Vai trò của Scrum Master là điều phối, không áp đặt. Bạn đặt câu hỏi và giữ không gian an toàn để đội tự nói ra.
- Giữ danh sách ngắn (5–8 điều), làm cho nó hiển thị, và viện dẫn nó khi có tình huống thật — đặc biệt như một cách gỡ xung đột mà không cần đối đầu cá nhân.