Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa gia nhập một Scrum Team mới. Buổi Daily Scrum đầu tiên bắt đầu lúc 9 giờ sáng — nhưng hai bạn developer mãi 9 giờ 20 mới có mặt, một người vừa pha cà phê vừa nói, và buổi họp kéo dài tận 40 phút vì ai cũng tranh thủ "bàn luôn cho tiện". Bạn nhắn tin hỏi một đồng nghiệp về user story, ba tiếng sau mới có hồi âm. Đến cuối Sprint, không ai chắc chắn "Done" nghĩa là gì, và pull request thì nằm chờ review suốt hai ngày.
Không một ai trong nhóm này là người xấu hay thiếu năng lực. Vấn đề nằm ở chỗ: nhóm chưa bao giờ ngồi lại với nhau để thống nhất "chúng ta sẽ làm việc cùng nhau như thế nào". Đó chính là khoảng trống mà Working Agreement (Thỏa thuận làm việc) — đôi khi còn gọi là Team Norms (Chuẩn mực nhóm) — được sinh ra để lấp đầy.
Scrum Guide nói rất nhiều về các sự kiện, vai trò và artifact, nhưng lại cố tình để trống phần "cách nhóm tự vận hành hằng ngày". Đây không phải thiếu sót, mà là chủ đích: mỗi nhóm phải tự định nghĩa lấy bộ quy tắc phù hợp với hoàn cảnh của mình. Với một Product Owner, hiểu và đồng hành xây dựng Working Agreement là cực kỳ quan trọng — vì bạn là người tương tác với nhóm mỗi ngày, và những kỳ vọng không được nói ra chính là nguồn gốc của hầu hết xung đột âm ỉ. Bài học này sẽ giúp bạn hiểu Working Agreement là gì, vì sao nó quan trọng, và cách tạo ra một bản thỏa thuận thực sự sống động chứ không phải tờ giấy dán tường để cho có.
Khái niệm cốt lõi
Working Agreement là gì?
Working Agreement là một tập hợp các quy tắc và chuẩn mực do chính Scrum Team cùng nhau thống nhất, nhằm định nghĩa cách nhóm hợp tác, giao tiếp và làm việc với nhau hằng ngày. Điểm mấu chốt nằm ở hai chữ "cùng nhau thống nhất" — đây không phải là nội quy do quản lý áp xuống, mà là cam kết do chính các thành viên tự đặt ra cho chính mình.
Hãy phân biệt rõ Working Agreement với những thứ dễ nhầm lẫn:
- Nó khác Definition of Done (DoD): DoD nói về chất lượng của sản phẩm (khi nào một increment được coi là hoàn thành). Working Agreement nói về cách con người làm việc với nhau.
- Nó khác quy trình công ty: Quy trình HR hay policy công ty áp dụng cho mọi người. Working Agreement chỉ áp dụng trong phạm vi một nhóm cụ thể và do nhóm đó tự viết.
- Nó không phải hợp đồng pháp lý: Không ai bị phạt tiền khi vi phạm. Sức mạnh của nó đến từ sự cam kết tự nguyện và trách nhiệm với đồng đội.
Vì sao Working Agreement lại hiệu quả?
Lý do tâm lý học rất đơn giản: con người tuân thủ những quy tắc do chính mình tham gia tạo ra tốt hơn nhiều so với quy tắc bị áp đặt. Khi cả nhóm cùng ngồi xuống và nói "chúng ta đồng ý Daily Scrum bắt đầu lúc 9 giờ 30", thì việc đi muộn không còn là "vi phạm nội quy" mà là "thất hứa với đồng đội". Sự khác biệt về mặt cảm xúc là rất lớn.
Working Agreement cũng biến những kỳ vọng ngầm thành điều rõ ràng. Phần lớn mâu thuẫn trong nhóm không đến từ bất đồng lớn, mà đến từ những giả định khác nhau: "Tôi tưởng anh sẽ trả lời ngay", "Tôi nghĩ chúng ta không cần xin phép khi nghỉ". Khi mọi thứ được viết ra, không còn chỗ cho hiểu lầm.
Working Agreement thường bao gồm những gì?
Một bản Working Agreement tốt thường chạm tới các nhóm chủ đề sau:
1. Giao tiếp và sẵn sàng (Communication & Availability)
- Kênh nào dùng cho việc gì (ví dụ: Slack cho trao đổi nhanh, email cho việc chính thức).
- Thời gian phản hồi kỳ vọng — ví dụ "phản hồi tin nhắn Slack trong vòng 2 giờ trong giờ làm việc".
- Core hours: khung giờ tất cả mọi người cần online.
- Daily Scrum bắt đầu lúc mấy giờ, kéo dài tối đa bao lâu (ví dụ "9 giờ 30 sáng, tối đa 15 phút").
- Quy tắc đến đúng giờ và cách xử lý khi vắng mặt.
- Ai facilitate buổi nào.
- Quy tắc về pull request: review trong bao lâu, ai review.
- Bao nhiêu story được "in progress" cùng lúc (giới hạn WIP).
- Cách cập nhật trạng thái task trên Jira/board.
- Tôn trọng giờ tập trung sâu (không làm phiền nhau ngoài giờ họp).
- Cách đưa ra và tiếp nhận phản hồi.
- Không đổ lỗi cá nhân; tập trung vào vấn đề.
Tình huống thực tế
Ví dụ 1: Nhóm fintech ở TP.HCM và "căn bệnh đi muộn"
Một công ty fintech tại Quận 1, TP.HCM có một Scrum Team 7 người làm sản phẩm ví điện tử. Trong ba Sprint liên tiếp, Scrum Master nhận thấy Daily Scrum gần như không bao giờ bắt đầu đúng giờ — trung bình trễ 12 phút, và buổi họp thường dây dưa sang cả những cuộc tranh luận kỹ thuật dài dòng. Hệ quả là developer bắt đầu coi Daily là "buổi họp vô bổ" và tìm cách né.
Thay vì ra lệnh "từ mai phải đúng giờ", Scrum Master dành 30 phút trong buổi Retrospective để cả nhóm cùng xây Working Agreement về Daily Scrum. Nhóm thống nhất ba điều: (1) Daily bắt đầu đúng 9 giờ 30, ai đến sau coi như "đến muộn" và sẽ cập nhật trạng thái qua Slack thay vì làm cả nhóm chờ; (2) tối đa 15 phút, mọi cuộc thảo luận sâu sẽ được "parking lot" lại để bàn sau với đúng người liên quan; (3) một thành viên luân phiên giữ vai trò "người canh giờ" mỗi tuần.
Kết quả sau hai Sprint: tỷ lệ đến đúng giờ tăng từ khoảng 60% lên trên 95%, thời gian họp trung bình giảm còn 11 phút. Bài học rút ra: quy tắc do nhóm tự đặt và tự giám sát luân phiên tạo ra trách nhiệm tập thể mạnh hơn nhiều so với mệnh lệnh từ trên xuống.
Ví dụ 2: Đội remote của một startup SaaS Đông Nam Á
Một startup SaaS có đội kỹ thuật trải khắp Hà Nội, Đà Nẵng và Manila (Philippines), làm việc hoàn toàn từ xa. Vấn đề lớn nhất của họ không phải kỹ thuật mà là sự "mất kết nối": một developer ở Đà Nẵng gửi câu hỏi về API trên Slack, đến chiều mới có người trả lời, làm anh ấy bị kẹt cả buổi sáng. Trong khi đó, Product Owner liên tục bị "ping" lúc 9 giờ tối vì đồng nghiệp Manila lệch múi giờ một tiếng và quen làm muộn.
Nhóm họp lại và viết một Working Agreement dành riêng cho môi trường remote. Họ thống nhất: core hours chung là 10 giờ sáng đến 4 giờ chiều giờ Việt Nam — khoảng thời gian tất cả phải online và có thể họp; phản hồi Slack trong vòng 2 giờ vào giờ làm việc, nhưng tin nhắn sau 6 giờ chiều thì không kỳ vọng được trả lời cho đến sáng hôm sau; mọi quyết định quan trọng phải được ghi lại bằng văn bản trên kênh chung chứ không "nói miệng" trong call để người vắng mặt vẫn nắm được.
Sau một tháng, số lần developer báo "bị block vì chờ câu trả lời" giảm rõ rệt, và Product Owner lấy lại được buổi tối của mình. Bài học: với đội remote và đa múi giờ, Working Agreement không phải lựa chọn "có thì tốt" mà gần như là điều kiện sống còn để nhóm vận hành trơn tru.
Ví dụ 3: Khi Working Agreement trở thành tờ giấy chết
Một công ty gia công phần mềm (outsourcing) ở Hà Nội từng tổ chức một buổi workshop hoành tráng để xây Working Agreement. Họ in ra, dán lên tường phòng họp, chụp ảnh đăng lên trang nội bộ. Nhưng sáu tháng sau, khi một Agile Coach ghé thăm và hỏi "Working Agreement của các bạn có những điều gì?", không một ai trong nhóm nhớ nổi quá hai điều. Tờ giấy vẫn còn trên tường, nhưng đã hoàn toàn lỗi thời — nhóm đã chuyển sang dùng công cụ mới, đã thêm hai thành viên mới chưa từng tham gia thỏa thuận đó.
Agile Coach giúp nhóm "hồi sinh" bằng cách đưa Working Agreement vào nhịp định kỳ: mỗi Retrospective dành 5 phút đọc lại, hỏi "điều nào còn đúng, điều nào cần sửa, có cần thêm gì không". Khi có thành viên mới gia nhập, buổi onboarding bắt buộc đi qua bản thỏa thuận này. Bài học: Working Agreement là một tài liệu sống (living document); nếu không được rà soát và nhắc lại đều đặn, nó sẽ chết và mất hết tác dụng — tệ hơn, nó còn khiến nhóm hoài nghi về giá trị của mọi quy ước sau này.
Hướng dẫn từng bước
Đây là quy trình thực tế để tạo một Working Agreement hiệu quả cho nhóm của bạn:
Bước 1 — Chọn thời điểm và người tham gia. Tốt nhất là tổ chức khi nhóm mới thành lập, hoặc lồng vào một buổi Retrospective. Toàn bộ Scrum Team phải có mặt: Product Owner, Scrum Master và tất cả Developers. Nếu thiếu người, thỏa thuận sẽ không có sức ràng buộc với người vắng mặt.
Bước 2 — Đặt đúng câu hỏi gợi mở. Thay vì hỏi chung chung "chúng ta nên có quy tắc gì", hãy hỏi cụ thể: "Điều gì khiến bạn khó chịu trong cách làm việc hiện tại?", "Khi nào bạn thấy nhóm hợp tác tốt nhất?", "Bạn kỳ vọng đồng đội phản hồi nhanh đến mức nào?".
Bước 3 — Brainstorm và gom nhóm. Cho mỗi người viết ý tưởng lên sticky note (hoặc Miro/FigJam nếu remote), rồi gom thành các chủ đề như giao tiếp, họp hành, chất lượng code, văn hóa.
Bước 4 — Thảo luận và đạt đồng thuận. Đây là bước quan trọng nhất. Mỗi điều khoản chỉ được đưa vào nếu cả nhóm đồng ý — không phải biểu quyết đa số kiểu áp đảo thiểu số. Nếu có người phản đối, hãy bàn cho đến khi tìm được phương án mọi người chấp nhận được.
Bước 5 — Viết rõ ràng, cụ thể, đo được. Tránh câu mơ hồ như "giao tiếp tốt". Thay bằng "phản hồi Slack trong 2 giờ giờ làm việc". Càng cụ thể, càng dễ thực thi.
Bước 6 — Công khai và dễ truy cập. Đặt bản thỏa thuận ở nơi ai cũng thấy: pin trên kênh Slack, ghim đầu board Jira, hoặc trang Confluence/Notion của nhóm.
Bước 7 — Rà soát định kỳ. Đưa việc xem lại Working Agreement vào Retrospective định kỳ (ví dụ mỗi 2–3 Sprint). Thêm, bớt, sửa cho phù hợp với thực tế đã thay đổi.
Lỗi thường gặp & mẹo
Lỗi 1: Quản lý áp đặt thay vì nhóm tự xây. Khi sếp hoặc Scrum Master viết sẵn rồi bảo nhóm "ký vào", đó không còn là Working Agreement nữa mà là nội quy. Sức mạnh tự nguyện biến mất hoàn toàn. Mẹo: vai trò của bạn là người dẫn dắt thảo luận, không phải người ra đề.
Lỗi 2: Viết quá nhiều, quá dài. Một bản thỏa thuận 30 điều khoản sẽ không ai nhớ. Mẹo: giữ trong khoảng 5–10 điều cốt lõi, ưu tiên những gì đang thực sự gây đau.
Lỗi 3: Quy tắc mơ hồ. "Tôn trọng lẫn nhau" nghe hay nhưng không đo được. Mẹo: mỗi điều khoản nên trả lời được câu hỏi "làm sao biết ai đó đang tuân thủ hay vi phạm?".
Lỗi 4: Lập xong rồi bỏ quên. Như ví dụ 3, đây là cái chết phổ biến nhất. Mẹo: gắn việc rà soát vào nhịp Retrospective để nó luôn sống.
Lỗi 5: Không cập nhật khi có người mới. Thành viên mới chưa từng đồng ý thì không thấy ràng buộc. Mẹo: đưa Working Agreement vào checklist onboarding, và cho phép người mới đề xuất sửa đổi.
Mẹo dành riêng cho Product Owner: Bạn nên chủ động đưa vào thỏa thuận những điều giúp công việc của bạn trơn tru — ví dụ "PO sẽ trả lời câu hỏi về yêu cầu trong vòng nửa ngày", hoặc "Developers báo trước khi một story có nguy cơ không kịp Sprint". Working Agreement là cơ hội để bạn và nhóm thiết lập một mối quan hệ làm việc lành mạnh, có đi có lại.
Bài tập thực hành
Hãy thực hiện các bài tập sau để biến kiến thức thành kỹ năng:
- Tự đánh giá hiện trạng: Viết ra 3 tình huống trong nhóm hiện tại (hoặc nhóm bạn từng tham gia) khiến bạn từng khó chịu hoặc bối rối vì "không rõ luật chơi". Với mỗi tình huống, đề xuất một điều khoản Working Agreement cụ thể, đo được để giải quyết nó.
- Soạn bản nháp: Tự viết một bản Working Agreement nháp gồm đúng 7 điều, phủ ít nhất ba nhóm chủ đề (giao tiếp, sự kiện Scrum, chất lượng/văn hóa). Kiểm tra lại: có điều nào còn mơ hồ, không đo được không? Sửa cho cụ thể.
- Đóng vai facilitator: Viết ra 5 câu hỏi gợi mở bạn sẽ dùng để dẫn dắt một buổi workshop xây Working Agreement, sao cho khuyến khích cả những thành viên ít nói cũng tham gia.
- Tình huống xử lý: Một developer trong nhóm liên tục vi phạm điều khoản "review pull request trong vòng 4 giờ", khiến công việc của người khác bị kẹt. Hãy viết ra cách bạn sẽ đưa vấn đề này ra trong buổi Retrospective mà không biến nó thành màn đổ lỗi cá nhân.
Tóm tắt
Working Agreement là tập hợp các quy tắc và chuẩn mực do chính Scrum Team cùng nhau thống nhất, định nghĩa cách họ hợp tác và làm việc hằng ngày. Sức mạnh của nó nằm ở tính tự nguyện: con người tuân thủ những quy tắc do mình tham gia tạo ra tốt hơn nhiều so với mệnh lệnh áp đặt.
Những điểm cốt lõi cần ghi nhớ:
- Working Agreement khác với DoD (nói về sản phẩm) và quy trình công ty (áp cho tất cả) — nó nói về cách con người làm việc với nhau trong phạm vi một nhóm cụ thể.
- Nội dung tốt thường chạm tới: giao tiếp và thời gian phản hồi, các sự kiện Scrum, chất lượng và cách làm việc, hành vi và văn hóa nhóm.
- Quy tắc phải cụ thể, đo được — "phản hồi Slack trong 2 giờ" thay vì "giao tiếp tốt".
- Nó là tài liệu sống: phải được rà soát định kỳ trong Retrospective và cập nhật khi nhóm thay đổi, nếu không sẽ trở thành tờ giấy chết.
- Với môi trường remote, đa múi giờ (như nhiều đội ở Việt Nam và Đông Nam Á), Working Agreement gần như là điều kiện sống còn.