Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa được giao làm Scrum Master cho một đội mới toanh: bảy con người đến từ bốn phòng ban khác nhau, mỗi người mang theo thói quen làm việc riêng, kỳ vọng riêng và một định nghĩa "thế nào là làm tốt" rất khác nhau. Tuần đầu tiên trôi qua trong sự lịch sự khách sáo. Tuần thứ hai, những bất đồng ngầm bắt đầu lộ ra: người thì cho rằng phải họp đầy đủ mới ra quyết định, người lại muốn ai làm phần nấy. Đến sprint thứ ba, đội rơi vào trạng thái mà người ta hay gọi là "đông mà không mạnh" — đông người nhưng chẳng ai thực sự đồng lòng.
Vấn đề ở đây không phải vì họ kém năng lực. Vấn đề là họ chưa bao giờ ngồi lại để cùng trả lời những câu hỏi nền tảng: Chúng ta tồn tại để làm gì? Chúng ta làm việc với nhau theo nguyên tắc nào? Thế nào là thành công với riêng đội này? Đây chính là khoảng trống mà Team Chartering — hoạt động xây dựng "hiến chương đội" — được sinh ra để lấp đầy.
Trong bộ công cụ của một Scrum Master, Team Chartering là công cụ bạn dùng ở thời điểm forming — giai đoạn hình thành đội. Khác với Working Agreements (thỏa thuận làm việc) mà chúng ta sẽ học riêng ở bài sau và thường tập trung vào các quy tắc vận hành hằng ngày, Team Charter là một tài liệu nền tảng ở tầng cao hơn: nó định hình bản sắc và lý do tồn tại của cả đội. Nắm vững công cụ này, bạn sẽ giúp một nhóm người xa lạ trở thành một đội thực sự nhanh hơn nhiều, thay vì để họ tự dò dẫm qua hàng tháng trời thử-và-sai đầy tốn kém.
Khái niệm cốt lõi
Team Charter (hiến chương đội) là một tài liệu ngắn gọn, được cả đội cùng xây dựng, trả lời câu hỏi nền tảng nhất: "Chúng ta là ai, tồn tại để làm gì, và sẽ cư xử với nhau ra sao?". Điểm mấu chốt không nằm ở bản tài liệu cuối cùng, mà nằm ở quá trình cùng nhau tạo ra nó. Một charter do sếp viết sẵn rồi phát xuống chỉ là tờ giấy. Một charter do cả đội tranh luận, thương lượng và đồng thuận mới thực sự có sức ràng buộc tinh thần.
Một Team Charter đầy đủ thường gồm bốn thành phần cốt lõi sau.
1. Vision / Purpose — Vì sao đội tồn tại
Đây là phần trả lời câu hỏi "Tại sao?". Nó mô tả bức tranh tương lai mà đội muốn góp phần tạo ra, hoặc lý do sâu xa khiến đội này được lập nên. Vision không phải là việc bạn làm, mà là lý do khiến việc đó đáng làm.
Ví dụ, một đội phát triển ứng dụng giao đồ ăn có thể viết: "Chúng tôi tồn tại để mỗi bữa ăn của người dùng đến tay nhanh, nóng và đúng như họ mong đợi — biến việc đặt món thành niềm vui chứ không phải sự chờ đợi lo lắng." Câu này không nói về code, về sprint, mà nói về ý nghĩa. Khi đội mệt mỏi, chính phần Vision là thứ kéo họ đứng dậy.
2. Mission — Chúng ta làm gì
Nếu Vision là "vì sao", thì Mission là "cái gì". Mission mô tả cụ thể hơn phạm vi công việc, đối tượng phục vụ và giá trị mà đội mang lại trong hiện tại. Mission gần mặt đất hơn Vision: nó nói về sản phẩm, dịch vụ hay năng lực cụ thể mà đội chịu trách nhiệm.
Vẫn đội giao đồ ăn ở trên, Mission có thể là: "Chúng tôi xây dựng và vận hành module theo dõi đơn hàng theo thời gian thực, đảm bảo người dùng luôn biết đơn của mình đang ở đâu, và tài xế luôn có lộ trình tối ưu." Mission giúp đội phân biệt được "việc của mình" với "việc không phải của mình" — một ranh giới cực kỳ quan trọng để tránh ôm đồm hoặc đùn đẩy.
3. Values — Chúng ta cư xử thế nào
Values (giá trị) là những nguyên tắc hành xử mà đội cam kết tuân theo. Đây là phần dễ bị viết sáo rỗng nhất, vì ai cũng có thể ghi "trung thực, tôn trọng, chuyên nghiệp". Mẹo để Values có sức sống là biến mỗi giá trị thành một hành vi quan sát được. Thay vì chỉ ghi "minh bạch", hãy ghi "Khi gặp khó, chúng tôi nói ra trong daily ngay hôm đó thay vì giấu đến phút chót."
Values là phần nối Team Charter với đời sống hằng ngày của đội. Nó cũng là căn cứ để giải quyết xung đột sau này: khi hai người bất đồng, bạn có thể quay lại hỏi "Cách làm này có đúng với giá trị mà cả đội đã cam kết không?".
4. Success criteria — Thế nào là thành công
Thành phần cuối cùng trả lời câu hỏi: "Làm sao chúng ta biết mình đang đi đúng hướng và đã thành công?". Success criteria nên bao gồm cả những tiêu chí về kết quả sản phẩm (ví dụ: tỷ lệ đơn giao đúng giờ đạt 95%) lẫn tiêu chí về sức khỏe đội (ví dụ: mỗi thành viên đều cảm thấy an toàn để nêu ý kiến trái chiều). Việc định nghĩa thành công ngay từ đầu giúp đội tránh tình trạng "chạy mãi mà không biết đích ở đâu", đồng thời tạo cơ sở để nhìn lại và ăn mừng khi đạt được.
Bốn thành phần này tạo thành một mạch logic: Vision (vì sao tồn tại) dẫn xuống Mission (làm gì để hiện thực hóa Vision), được dẫn dắt bởi Values (cách cư xử trên hành trình đó), và được đo lường bằng Success criteria (biết mình đã tới đâu). Một charter tốt là một charter mà bốn phần này nhất quán với nhau, không mâu thuẫn.
Tình huống thực tế
Ví dụ 1 — Đội "Pegasus" tại một fintech ở TP.HCM
Một công ty fintech tại Quận 1, TP.HCM (gọi là VietPay) lập một đội mới tên Pegasus gồm 6 người để xây tính năng thanh toán qua mã QR liên ngân hàng. Đội gom từ ba nguồn: hai dev cũ của VietPay, ba người mới tuyển và một QA thuê ngoài. Trong ba tuần đầu, năng suất rất thấp — velocity chỉ đạt khoảng 40% so với kỳ vọng, và các cuộc họp thường kéo dài vì ai cũng muốn áp đặt cách làm cũ của mình.
Scrum Master tổ chức một buổi Team Chartering kéo dài nửa ngày. Khi đến phần Vision, một tranh luận thú vị nổ ra: nhóm dev cũ nghĩ đội tồn tại để "giao tính năng đúng deadline", trong khi nhóm mới nghĩ đội tồn tại để "tạo trải nghiệm thanh toán mượt cho người dùng". Sau khi đào sâu, cả đội nhận ra deadline chỉ là phương tiện, còn trải nghiệm người dùng mới là đích thực sự. Họ chốt Vision: "Mỗi giao dịch QR phải nhanh dưới 3 giây và không bao giờ khiến người dùng phải lo lắng tiền của mình đi đâu."
Bài học: Chính sự bất đồng về Vision đã phơi bày một xung đột ngầm về ưu tiên mà nếu không có buổi chartering thì sẽ âm ỉ cả quý. Sau buổi đó, velocity của Pegasus tăng lên 75% chỉ sau hai sprint, vì các quyết định tranh cãi nay có một "ngọn hải đăng" để chiếu vào.
Ví dụ 2 — Đội phân tán giữa Hà Nội và Singapore
Một công ty SaaS có đội kỹ thuật chia đôi: 4 người ở Hà Nội, 3 người ở Singapore. Văn hóa làm việc khác biệt rõ rệt — nhóm Hà Nội quen trao đổi trực tiếp, nhiệt tình nhưng đôi khi ngại nói "không"; nhóm Singapore thì thẳng thắn, thích viết rõ ràng và phản biện trực diện. Hệ quả là nhóm Hà Nội thấy đồng nghiệp "lạnh lùng, khó gần", còn nhóm Singapore thấy đối tác "mơ hồ, hay né tránh".
Scrum Master quyết định làm buổi chartering tập trung mạnh vào phần Values. Họ dành thời gian để mỗi bên nói rõ "điều gì khiến tôi cảm thấy được tôn trọng" và "điều gì khiến tôi khó chịu". Kết quả, đội thống nhất một giá trị cụ thể: "Phản biện thẳng vào ý tưởng, không vào con người — và mọi 'không' đều phải kèm lý do." Họ cũng thống nhất rằng việc nói "không" được khuyến khích, không bị xem là mất lịch sự.
Bài học: Trong môi trường đa văn hóa của Đông Nam Á, phần Values của Team Charter không phải là trang trí — nó là công cụ phòng ngừa xung đột văn hóa. Việc biến giá trị trừu tượng thành hành vi cụ thể đã giúp hai nửa của đội ngừng hiểu lầm nhau.
Ví dụ 3 — Khi charter bị bỏ xó
Một startup thương mại điện tử ở Đà Nẵng tổ chức buổi chartering rất hoành tráng: in poster, dán tường, chụp hình đăng nội bộ. Nhưng sáu tuần sau, khi Scrum Master hỏi "Success criteria của đội mình là gì nhỉ?", không ai nhớ nổi. Tấm poster vẫn treo đó nhưng đã trở thành vật trang trí vô hình.
Sau khi nhìn lại, Scrum Master nhận ra lỗi của mình: charter được tạo ra một lần rồi không bao giờ được nhắc đến nữa. Họ sửa bằng cách đưa charter vào nhịp làm việc: mỗi đầu sprint planning, đội dành 2 phút đọc lại Vision; mỗi retrospective, đội đối chiếu hành vi thực tế với Values đã cam kết.
Bài học: Một Team Charter không phải sự kiện một lần, mà là tài liệu sống. Giá trị của nó chỉ phát huy khi được nhắc lại và cập nhật đều đặn. Charter bị bỏ xó cũng vô dụng như không có charter.
Hướng dẫn từng bước
Dưới đây là quy trình bạn có thể áp dụng để facilitate một buổi Team Chartering hiệu quả, thường kéo dài từ 2 đến 4 giờ tùy quy mô đội.
Bước 1 — Chuẩn bị bối cảnh. Trước buổi họp, gửi cho đội biết mục đích và đảm bảo có mặt đầy đủ thành viên, bao gồm cả Product Owner. Chuẩn bị bảng (vật lý hoặc Miro/Mural nếu phân tán), giấy note và bút. Nếu đội mới hoàn toàn, hãy bắt đầu bằng một hoạt động làm quen ngắn để phá băng.
Bước 2 — Xây dựng Vision / Purpose. Đặt câu hỏi: "Nếu đội chúng ta thành công rực rỡ sau một năm, thế giới của người dùng sẽ khác đi như thế nào?". Cho mỗi người viết câu trả lời riêng lên note, rồi gom nhóm, thảo luận và chắt lọc thành 1–2 câu Vision chung. Đừng vội — đây là phần đáng đầu tư thời gian nhất.
Bước 3 — Làm rõ Mission. Hỏi: "Cụ thể, đội chúng ta chịu trách nhiệm tạo ra cái gì? Phục vụ ai? Ranh giới công việc của chúng ta tới đâu?". Viết Mission sao cho người ngoài đọc vào cũng hiểu đội này làm gì.
Bước 4 — Thống nhất Values. Hỏi mỗi người: "Điều gì khiến bạn làm việc hết mình? Điều gì làm bạn mất động lực?". Từ đó rút ra 4–6 giá trị, và với mỗi giá trị, bắt buộc viết kèm một hành vi cụ thể quan sát được. Tránh viết quá nhiều — 6 giá trị mà sống được tốt hơn 12 giá trị bị quên.
Bước 5 — Định nghĩa Success criteria. Hỏi: "Sáu tháng nữa, dựa vào đâu chúng ta biết mình đã thành công?". Phân thành hai nhóm: tiêu chí kết quả (đo được bằng số) và tiêu chí sức khỏe đội (cảm nhận, có thể đo bằng khảo sát định kỳ).
Bước 6 — Chốt và trực quan hóa. Tổng hợp cả bốn phần thành một trang duy nhất. Đọc to lại cho cả đội nghe và xác nhận đồng thuận. Đặt charter ở nơi ai cũng nhìn thấy — kênh chung, tường ảo hoặc đầu trang của board.
Bước 7 — Lên lịch xem lại. Hẹn một thời điểm — thường là sau 2–3 sprint — để cả đội nhìn lại charter và điều chỉnh nếu cần. Điều này biến charter từ một sự kiện thành một tài liệu sống.
Lỗi thường gặp & mẹo
Lỗi 1 — Sếp viết hộ, đội chỉ ký. Đây là lỗi phá hỏng toàn bộ giá trị của công cụ. Charter có sức mạnh vì nó là sản phẩm của sự đồng thuận. Nếu nó được áp xuống, nó chỉ còn là khẩu hiệu. Mẹo: Vai trò của Scrum Master là facilitator, không phải tác giả. Hãy đặt câu hỏi và để đội tự viết.
Lỗi 2 — Viết quá dài, quá hoa mỹ. Một charter ba trang đầy mỹ từ sẽ không ai nhớ. Mẹo: Ép tất cả vào một trang. Nếu một câu không giúp đội ra quyết định tốt hơn, hãy cắt nó.
Lỗi 3 — Values trừu tượng. "Tôn trọng, chính trực, đam mê" — những từ này đẹp nhưng vô dụng nếu không gắn với hành vi. Mẹo: Với mỗi giá trị, hỏi "Cụ thể trong daily/planning/retro, giá trị này trông như thế nào?".
Lỗi 4 — Làm một lần rồi quên. Như ví dụ 3 ở trên, charter bị bỏ xó là lãng phí lớn nhất. Mẹo: Gắn việc nhắc lại charter vào các sự kiện Scrum định kỳ.
Lỗi 5 — Nhầm Team Charter với Working Agreements. Charter ở tầng bản sắc (vì sao, làm gì, cư xử ra sao ở mức giá trị); Working Agreements ở tầng vận hành (giờ daily, quy tắc code review, cách xử lý khi build hỏng). Mẹo: Làm Charter trước để định khung, rồi mới làm Working Agreements để cụ thể hóa hành vi hằng ngày.
Mẹo bổ sung: Đừng làm chartering ngay buổi đầu tiên đội gặp nhau khi mọi người còn quá xa lạ và ngại nói thật. Đôi khi để đội làm việc chung 1–2 sprint rồi mới chartering sẽ cho ra charter chân thực hơn, vì lúc đó họ đã có trải nghiệm chung để soi chiếu.
Bài tập thực hành
Bài tập 1 — Phác thảo charter cho đội của bạn. Lấy đội hiện tại (hoặc một đội bạn từng làm) và viết nháp cả bốn thành phần: Vision, Mission, Values (kèm hành vi cụ thể), Success criteria. Giới hạn trong một trang A4. Sau đó tự hỏi: bốn phần này có nhất quán với nhau không?
Bài tập 2 — Soi chiếu Values. Chọn ba giá trị mà bạn nghĩ đội mình nên có. Với mỗi giá trị, viết ra: (a) một hành vi cụ thể thể hiện giá trị đó, và (b) một hành vi vi phạm giá trị đó. Bài tập này luyện cho bạn kỹ năng biến giá trị trừu tượng thành thứ quan sát được.
Bài tập 3 — Thiết kế agenda buổi chartering. Dựa trên hướng dẫn 7 bước, hãy soạn một agenda chi tiết cho buổi Team Chartering 3 giờ cho một đội 7 người mới thành lập, phân bổ thời gian cho từng phần và ghi rõ câu hỏi facilitation bạn sẽ dùng.
Tóm tắt
Team Chartering là công cụ bạn dùng ở giai đoạn hình thành đội, giúp một nhóm người xa lạ trở thành một đội thực sự bằng cách cùng nhau trả lời những câu hỏi nền tảng. Một Team Charter đầy đủ gồm bốn thành phần: Vision / Purpose (vì sao đội tồn tại), Mission (đội làm gì), Values (đội cư xử thế nào), và Success criteria (thế nào là thành công). Bốn phần này phải nhất quán với nhau.
Điều quan trọng nhất cần nhớ: giá trị của charter không nằm ở bản tài liệu, mà nằm ở quá trình cùng tạo ra nó và việc giữ nó sống qua thời gian. Là Scrum Master, vai trò của bạn là facilitator giúp đội tự viết, không phải người viết hộ. Hãy giữ charter ngắn gọn, biến mỗi giá trị thành hành vi quan sát được, và đưa nó vào nhịp làm việc đều đặn của đội. Khi làm đúng, Team Charter sẽ trở thành ngọn hải đăng giúp đội ra quyết định nhất quán và vượt qua những lúc khó khăn.