Mở đầu — vì sao bài này quan trọng
Hãy hình dung bạn vừa được giao dẫn dắt một đội phát triển sản phẩm mới, hoặc đội của bạn chuẩn bị bước vào một quý đầy thử thách với một mục tiêu lớn mà ai cũng biết là khó. Trong buổi kick-off, không khí phòng họp thường rơi vào một trong hai trạng thái: hoặc mọi người gật gù đồng ý cho qua chuyện, hoặc có một sự im lặng nặng nề mà ai cũng cảm nhận được nhưng không ai dám nói ra. Cả hai trạng thái đó đều nguy hiểm. Sự đồng thuận giả tạo che giấu những kỳ vọng không khớp nhau, còn sự im lặng che giấu những nỗi lo đang âm ỉ. Và khi kỳ vọng lệch nhau hoặc nỗi lo không được nói ra, chúng không biến mất — chúng chuyển thành xung đột ngầm, thành sự trì hoãn, thành những cuộc họp căng thẳng ở giữa Sprint.
Hopes and Fears (Hy vọng và Nỗi sợ) là một công cụ facilitation cực kỳ đơn giản nhưng mạnh mẽ, được thiết kế đúng để xử lý khoảnh khắc đó. Nó là một "team alignment opener" — một hoạt động mở đầu giúp cả đội thẳng thắn đặt lên bàn hai thứ mà con người thường giấu kín nhất khi bắt đầu một việc mới: điều họ mong sẽ xảy ra, và điều họ sợ sẽ xảy ra. Khi cả hai được nói ra, đội bỗng nhiên có chung một bản đồ về những gì quan trọng và những gì rủi ro, ngay từ ngày đầu tiên.
Với vai trò Scrum Master, đây là một trong những công cụ "nhẹ tay nhưng nặng giá trị" nhất trong toolbox của bạn. Nó không cần chuẩn bị cầu kỳ, chạy được trong 30–45 phút, áp dụng được cho buổi khởi động dự án, đầu quý, lúc đội đón thành viên mới, hay trước một thay đổi lớn về quy trình. Trong bài này, bạn sẽ học cách hiểu đúng bản chất của nó, vì sao nó hiệu quả về mặt tâm lý, và cách dẫn dắt nó một cách chuyên nghiệp.
Khái niệm cốt lõi
Hopes and Fears là gì
Về bản chất, Hopes and Fears là một hoạt động thu thập song song hai loại thông tin từ mỗi cá nhân trong đội:
- Hope (Hy vọng): Kết quả tốt đẹp nhất mà người đó mong muốn từ sáng kiến / Sprint / quý / dự án sắp tới. Đây là câu trả lời cho câu hỏi: "Nếu mọi việc diễn ra tuyệt vời, ba tháng sau nhìn lại, bạn mong điều gì đã xảy ra?"
- Fear (Nỗi sợ): Kết quả tệ nhất, hoặc điều khiến người đó lo lắng. Đây là câu trả lời cho: "Điều gì khiến bạn trằn trọc? Nếu việc này thất bại, theo bạn nó sẽ thất bại như thế nào?"
Vì sao công cụ này hiệu quả
Hopes and Fears hoạt động dựa trên ba cơ chế tâm lý mà một Scrum Master nên hiểu rõ:
Thứ nhất, đặt tên cho cảm xúc làm giảm cường độ của nó. Trong tâm lý học có khái niệm "affect labeling" — khi con người gọi tên được nỗi lo của mình thành lời, mức độ căng thẳng giảm xuống. Một nỗi sợ mơ hồ "không biết dự án này có ổn không" là thứ gây tê liệt; còn một nỗi sợ cụ thể "tôi sợ scope sẽ phình ra mà deadline không đổi" là thứ có thể bàn bạc và xử lý được.
Thứ hai, nó tạo ra sự an toàn tâm lý (psychological safety) ngay từ đầu. Khi Scrum Master mời mọi người nói ra nỗi sợ một cách công khai và được đón nhận không phán xét, đội học được rằng "ở đây nói thật là an toàn". Đây là nền móng cho mọi hoạt động cộng tác về sau.
Thứ ba, nó căn chỉnh kỳ vọng (expectation alignment). Rất nhiều xung đột trong đội không đến từ việc người ta bất đồng, mà đến từ việc mỗi người tưởng tượng một "thành công" khác nhau. Khi tất cả Hope được đặt cạnh nhau, bạn sẽ thấy ngay những điểm trùng (giá trị chung) và những điểm lệch (cần thương lượng).
Phân biệt với các công cụ lân cận
Để không nhầm lẫn, hãy định vị rõ Hopes and Fears trong toolbox. Nó là một hoạt động mở đầu mang tính hướng về tương lai và cảm xúc. Nó khác với một buổi phân tích rủi ro kỹ thuật chi tiết — Hopes and Fears chạm vào cả cảm xúc lẫn rủi ro, nhanh và rộng, chứ không đi sâu vào từng rủi ro để lập kế hoạch ứng phó chi tiết. Nó cũng khác với một retrospective nhìn về quá khứ. Vị trí tự nhiên của Hopes and Fears là ở điểm khởi đầu của một hành trình: kick-off dự án, đầu quý, ngày đầu của một team mới, hoặc ngay trước khi triển khai một thay đổi lớn.
Khi nào nên dùng và khi nào không
Dùng khi: khởi động dự án/sản phẩm mới; bắt đầu quý hoặc một PI (Program Increment); team vừa hình thành hoặc đón thành viên mới; trước một thay đổi lớn (đổi quy trình, tái cấu trúc, áp dụng công cụ mới); khi bạn cảm nhận có sự lo lắng ngầm nhưng không ai nói ra.
Cân nhắc kỹ khi: đội đang ở giữa một khủng hoảng cấp bách cần hành động ngay (lúc đó họ cần quyết định, không cần thổ lộ cảm xúc); hoặc khi mức độ an toàn tâm lý quá thấp đến mức không ai dám viết nỗi sợ thật — trong trường hợp này, hãy cho viết ẩn danh.
Tình huống thực tế
Tình huống 1 — Công ty fintech ở TP.HCM khởi động đội ví điện tử
Một công ty fintech tại Quận 1, TP.HCM (tạm gọi là MoMoPay) thành lập một đội mới gồm 8 người để xây dựng tính năng "chia hóa đơn nhóm" trong vòng một quý. Đội gồm 4 dev, 1 tester, 1 designer, 1 Product Owner và 1 người từ phòng tuân thủ (compliance) — một tổ hợp chưa từng làm việc cùng nhau. Áp lực rất rõ: ban lãnh đạo muốn ra mắt trước Tết để đón mùa lì xì.
Chị Scrum Master mở buổi kick-off bằng Hopes and Fears thay vì đi thẳng vào kế hoạch. Sau 7 phút viết im lặng, các Hope dán lên tường lộ ra một điều thú vị: dev mong "code base sạch, không phải vá víu vội"; PO mong "ra mắt đúng hẹn trước Tết"; còn bạn compliance mong "không bị Ngân hàng Nhà nước tuýt còi". Ba kỳ vọng này không sai, nhưng chúng kéo theo ba hướng khác nhau. Phần Fears còn quan trọng hơn: bạn compliance viết "tôi sợ đội sẽ coi khâu pháp lý là thủ tục phiền phức và bỏ qua tôi cho đến phút chót". Cả phòng im lặng — vì đó đúng là điều sắp xảy ra.
Diễn giải: Buổi đó kéo dài 40 phút, và kết quả không phải một bản kế hoạch hoàn chỉnh, mà là ba thỏa thuận: PO chấp nhận cắt scope để bảo vệ chất lượng, đội đồng ý đưa compliance vào ngay từ buổi refinement đầu tiên, và tất cả thống nhất một "lằn ranh đỏ" về pháp lý không được vượt qua dù có gấp đến đâu.
Bài học: Hopes and Fears không tạo ra giải pháp, nó tạo ra sự thật chung mà từ đó giải pháp có thể nảy sinh. Nỗi sợ của người ít tiếng nói nhất (compliance) hóa ra lại là rủi ro lớn nhất của cả dự án — và nó chỉ lộ ra vì có không gian để nói.
Tình huống 2 — Công ty gia công phần mềm ở Đà Nẵng áp dụng quy trình mới
Một công ty outsourcing khoảng 200 người ở Đà Nẵng quyết định chuyển một đội từ cách làm "ai bảo gì làm nấy" sang Scrum thực thụ. Nhiều thành viên đã quen với cách cũ và ngấm ngầm hoài nghi. Scrum Master mới về biết rằng nếu đi thẳng vào dạy quy trình, anh sẽ vấp phải sự kháng cự thụ động.
Anh chạy Hopes and Fears, nhưng cho viết ẩn danh vì biết an toàn tâm lý còn thấp. Các tờ Fears thu về thẳng thắn đến bất ngờ: "Tôi sợ daily standup chỉ là họp báo cáo cho sếp"; "Tôi sợ làm Scrum xong vẫn bị ép overtime như cũ"; "Tôi sợ ý kiến của mình trong retro không thay đổi được gì". Đây là những nỗi sợ mà nếu hỏi thẳng từng người, không ai dám nói.
Diễn giải: Thay vì phản bác, Scrum Master gom nhóm các nỗi sợ lại và biến mỗi nhóm thành một cam kết cụ thể. Với nỗi sợ "standup thành báo cáo cho sếp", anh thỏa thuận manager sẽ không tham dự daily. Với nỗi sợ "retro vô dụng", anh cam kết mỗi retro chỉ chốt tối đa hai action item nhưng phải làm cho bằng được.
Bài học: Khi an toàn tâm lý còn thấp, biến thể ẩn danh giúp công cụ vẫn hoạt động. Và quan trọng hơn, Fears chính là danh sách rủi ro về sự chấp nhận thay đổi (adoption risks) — thứ quý giá nhất khi bạn đang dẫn dắt một transformation.
Tình huống 3 — Startup thương mại điện tử bước vào quý cao điểm
Một startup e-commerce ở Hà Nội với đội kỹ thuật 12 người bước vào quý 4 — mùa sale lớn nhất năm với chiến dịch 11/11 và 12/12. Năm trước, hệ thống sập trong giờ cao điểm và cả đội nhớ mãi cú đó. Scrum Master dùng Hopes and Fears để mở đầu quý.
Lần này có một điểm tinh tế: Hope của đội rất khiêm tốn ("mong hệ thống đừng sập") trong khi Hope của Product Owner lại tham vọng ("mong doanh thu tăng gấp đôi năm ngoái"). Khoảng cách giữa hai loại Hope này tự nó là một thông điệp — đội đang sợ hãi quá khứ đến mức không dám mơ. Phần Fears thì hầu hết xoay quanh đúng nỗi ám ảnh năm cũ.
Diễn giải: Scrum Master không vội xóa nỗi sợ. Thay vào đó, anh dùng chính nỗi sợ "hệ thống sập" làm nhiên liệu: đội biến nó thành ưu tiên số một cho quý — đầu tư vào load testing và một kế hoạch ứng phó sự cố. Đồng thời, anh giúp đội và PO nói chuyện thẳng về khoảng cách kỳ vọng, để mục tiêu doanh thu đi kèm cam kết đầu tư hạ tầng tương xứng.
Bài học: Hopes and Fears làm lộ ra khoảng cách kỳ vọng giữa các vai trò — đặc biệt giữa đội kỹ thuật và Product Owner. Và một nỗi sợ được thừa nhận đúng cách có thể trở thành động lực hành động mạnh nhất, thay vì thành sự né tránh.
Hướng dẫn từng bước
Dưới đây là cách dẫn dắt một phiên Hopes and Fears chuẩn, áp dụng được cả trực tiếp lẫn online.
Bước 1 — Chuẩn bị (trước buổi họp). Xác định rõ "phạm vi" mà bạn đang hỏi về: là Sprint này, quý này, dự án này, hay thay đổi này? Phạm vi càng rõ, câu trả lời càng chất lượng. Chuẩn bị bề mặt làm việc: tường + giấy nhớ hai màu (một màu cho Hope, một màu cho Fear) nếu offline; hoặc một bảng Miro/Mural/FigJam chia hai cột nếu online. Quyết định trước: viết công khai hay ẩn danh, dựa trên mức độ an toàn tâm lý bạn cảm nhận.
Bước 2 — Khung cảnh và đặt câu hỏi (3–5 phút). Giải thích ngắn gọn mục đích: "Hôm nay trước khi lập kế hoạch, chúng ta dành ít phút để mọi người nói ra điều mình mong và điều mình lo, để cả đội cùng nhìn rõ bức tranh." Đưa ra hai câu hỏi rõ ràng. Ví dụ: "Nếu quý này thành công rực rỡ, ba tháng sau bạn mong điều gì đã xảy ra?" và "Điều gì khiến bạn lo lắng nhất về quý này?" Nhấn mạnh: không có câu trả lời sai, và nỗi sợ được tôn trọng.
Bước 3 — Viết im lặng (5–8 phút). Cho mỗi người viết riêng, mỗi ý một tờ giấy nhớ. Khuyến khích viết 2–3 Hope và 2–3 Fear. Im lặng là kỷ luật quan trọng nhất ở bước này — bảo vệ nó.
Bước 4 — Chia sẻ và dán lên (10–15 phút). Lần lượt từng người đọc và dán giấy của mình lên hai cột Hope / Fear. Nếu ẩn danh, bạn thu giấy và đọc to thay họ. Quy tắc vàng: không tranh luận, không phản bác, không "trấn an" trong lúc chia sẻ. Chỉ ghi nhận. Nếu ai đó muốn vội vàng giải quyết một nỗi sợ, hãy nhẹ nhàng dừng lại: "Cảm ơn, ta sẽ quay lại phần xử lý sau."
Bước 5 — Gom nhóm (clustering) (5–10 phút). Cùng đội nhóm các giấy giống nhau lại. Bạn sẽ thấy nổi lên vài chủ đề lớn ở cả hai cột. Đây là lúc bức tranh chung hiện ra rõ nhất.
Bước 6 — Chuyển hóa thành hành động (10–15 phút). Đây là bước phân biệt một Scrum Master nghiệp dư với chuyên nghiệp. Đừng để buổi họp kết thúc ở việc "đã nói ra". Với các Fear lớn, hỏi: "Chúng ta có thể làm gì để giảm khả năng điều này xảy ra?" Với các Hope chung, hỏi: "Chúng ta có thể đưa điều này vào cách làm việc như thế nào?" Chốt 2–3 hành động cụ thể, có người phụ trách. Một số Fear nằm ngoài tầm kiểm soát của đội — hãy thừa nhận chúng thật và ghi lại như điều cần theo dõi, đừng giả vờ giải quyết được.
Bước 7 — Đóng lại và lưu giữ. Chụp ảnh bảng, lưu lại. Cuối quý hoặc cuối dự án, mở lại nó trong retrospective: những Hope nào đã thành hiện thực? Những Fear nào đã xảy ra, và đội đã ứng phó ra sao? Việc khép vòng này biến Hopes and Fears từ một hoạt động cảm xúc thành một công cụ học hỏi.
Lỗi thường gặp & mẹo
Lỗi 1 — Bỏ qua bước chuyển hóa thành hành động. Đây là lỗi phổ biến nhất. Đội nói ra hết Hope và Fear, cảm thấy nhẹ nhõm, rồi... không có gì thay đổi. Lần sau họ sẽ coi hoạt động này là "trị liệu cảm xúc vô bổ". Mẹo: luôn dành ít nhất một phần ba thời gian cho việc biến Fear lớn thành hành động cụ thể.
Lỗi 2 — Scrum Master vội trấn an hoặc phản bác nỗi sợ. Khi ai đó nói ra nỗi sợ, phản xạ tự nhiên là "đừng lo, sẽ ổn thôi". Nhưng làm vậy là phủ nhận cảm xúc của họ và dạy cả đội rằng nói thật sẽ bị gạt đi. Mẹo: chỉ ghi nhận trong lúc chia sẻ — "Cảm ơn bạn đã nói ra điều này" — và để việc xử lý cho bước hành động.
Lỗi 3 — Để người to tiếng nhất định hình cả phòng. Nếu bỏ qua bước viết im lặng và cho nói tự do ngay, người hướng ngoại và cấp cao sẽ chiếm sóng. Mẹo: luôn giữ silent writing trước.
Lỗi 4 — Hỏi quá mơ hồ về phạm vi. "Bạn mong gì?" mà không rõ mong về cái gì sẽ cho ra câu trả lời lan man. Mẹo: neo câu hỏi vào một phạm vi và mốc thời gian cụ thể.
Lỗi 5 — Dùng công khai trong môi trường thiếu an toàn. Nếu đội còn sợ sếp, viết công khai sẽ chỉ thu về những nỗi sợ "an toàn", vô thưởng vô phạt. Mẹo: dùng ẩn danh, và cân nhắc để quản lý cấp trên không có mặt.
Lỗi 6 — Để nỗi sợ ngoài tầm kiểm soát làm chùng khí thế. Một số Fear (ví dụ "công ty có thể cắt ngân sách") đội không giải quyết được. Mẹo: thừa nhận thẳng thắn, phân loại rõ "trong tầm tay" và "ngoài tầm tay", và tập trung năng lượng vào nhóm đầu.
Mẹo nâng cao: Cân chỉnh tỷ lệ. Nếu đội đang quá lạc quan ngây thơ, đào sâu hơn vào Fears. Nếu đội đang sợ hãi và bi quan, hãy dành thêm thời gian cho Hopes để khơi lại năng lượng. Người facilitator giỏi đọc được "nhiệt độ" của phòng và điều chỉnh trọng tâm cho phù hợp.
Bài tập thực hành
Bài tập 1 — Tự chạy thử với một bối cảnh thật. Chọn một sự kiện sắp tới của đội bạn (một Sprint quan trọng, một quý mới, một thay đổi quy trình). Tự viết ra 3 Hope và 3 Fear của chính bạn về nó. Sau đó, viết hai câu hỏi mở mà bạn sẽ dùng để dẫn dắt đội — neo rõ vào phạm vi và mốc thời gian.
Bài tập 2 — Thiết kế phiên 40 phút. Lập một agenda chi tiết cho một phiên Hopes and Fears 40 phút, ghi rõ thời lượng từng bước, công cụ bạn dùng (offline hay online), và quyết định công khai hay ẩn danh kèm lý do dựa trên mức an toàn tâm lý của đội bạn.
Bài tập 3 — Luyện chuyển hóa Fear thành hành động. Lấy 3 nỗi sợ giả định sau và với mỗi cái, viết một hành động cụ thể có thể giảm thiểu nó, đồng thời phân loại nó là "trong tầm tay đội" hay "ngoài tầm tay": (a) "Tôi sợ scope phình ra mà deadline không đổi"; (b) "Tôi sợ thành viên mới không hòa nhập được"; (c) "Tôi sợ khách hàng đổi yêu cầu liên tục giữa Sprint".
Bài tập 4 — Khép vòng. Tưởng tượng quý đã kết thúc. Viết kịch bản 5 phút mở đầu một retrospective trong đó bạn mang lại bảng Hopes and Fears từ đầu quý và dẫn đội nhìn lại: Hope nào thành hiện thực, Fear nào đã xảy ra và đội đã ứng phó thế nào.
Tóm tắt
Hopes and Fears là một công cụ mở đầu đơn giản, nhanh và giàu giá trị, giúp đội căn chỉnh kỳ vọng và làm lộ những nỗi lo ngầm ngay từ điểm khởi đầu của một hành trình — kick-off dự án, đầu quý, đón team mới hay trước một thay đổi lớn. Cốt lõi của nó là mỗi người viết im lặng ra điều mình mong (Hope) và điều mình sợ (Fear), rồi cùng chia sẻ trong không gian không phán xét.
Nó hiệu quả vì ba lý do tâm lý: đặt tên cho nỗi lo làm giảm cường độ của nó, tạo an toàn tâm lý ngay từ đầu, và phơi bày khoảng cách kỳ vọng giữa các vai trò. Như các tình huống ở MoMoPay, công ty outsourcing Đà Nẵng và startup e-commerce Hà Nội cho thấy, giá trị lớn nhất thường nằm ở những nỗi sợ mà người ít tiếng nói nhất nói ra, hoặc ở khoảng cách kỳ vọng giữa đội kỹ thuật và Product Owner.
Để dẫn dắt tốt, hãy nhớ kỷ luật quan trọng nhất: viết im lặng trước, ghi nhận không phản bác khi chia sẻ, và luôn chuyển hóa nỗi sợ thành hành động cụ thể thay vì dừng ở việc nói ra. Và đừng quên khép vòng — mang bảng Hopes and Fears quay lại ở cuối hành trình để cả đội cùng học. Khi làm đúng, công cụ nhỏ bé này sẽ là một trong những "alignment opener" đáng tin cậy nhất trong toolbox của bạn.