Mở đầu — vì sao bài này quan trọng
Sau hơn năm mươi bài học, bạn đã có trong tay một "kho đồ nghề" khổng lồ: Retrospective theo Sailboat hay Starfish, Liberating Structures như 1-2-4-All hay TRIZ, các kỹ thuật ước lượng như Planning Poker hay Magic Estimation, công cụ làm rõ yêu cầu như Example Mapping, công cụ xử lý xung đột, công cụ chartering team... Vấn đề bây giờ không còn là "tôi có công cụ nào", mà là "trong tình huống cụ thể này, với team cụ thể này, tôi nên chọn công cụ nào?"
Đây chính là ranh giới phân biệt một Scrum Master mới vào nghề với một Scrum Master có kinh nghiệm. Người mới thường yêu thích một công cụ vừa học được và áp dụng nó cho mọi tình huống — giống như người mới mua búa thì nhìn đâu cũng thấy đinh. Người có kinh nghiệm thì đọc được "nhiệt độ" của team, hiểu team đang ở giai đoạn trưởng thành nào, và chọn công cụ phù hợp với giai đoạn đó.
Một công cụ tuyệt vời nhưng dùng sai thời điểm sẽ phản tác dụng. Ví dụ kinh điển: bạn đem một retrospective đào sâu xung đột cá nhân (kiểu mời mọi người nói thẳng điều khó chịu về nhau) vào một team vừa thành lập tuần trước — kết quả là team co cụm lại, mất an toàn tâm lý, và bạn vừa phá hỏng những viên gạch lòng tin đầu tiên. Ngược lại, dùng một trò chơi phá băng nhẹ nhàng cho một team đã làm việc với nhau hai năm và đang có mâu thuẫn ngầm âm ỉ — họ sẽ thấy bạn ngây thơ và lãng phí thời gian của họ.
Bài này dạy bạn một khung tư duy để chọn công cụ dựa trên độ trưởng thành của team (team maturity). Đây là kỹ năng "siêu công cụ" — công cụ để chọn công cụ.
Khái niệm cốt lõi
Mô hình Tuckman — bốn (năm) giai đoạn phát triển nhóm
Khung trưởng thành team được dùng phổ biến nhất là mô hình của Bruce Tuckman (1965), gồm bốn giai đoạn chính: Forming → Storming → Norming → Performing, và sau này bổ sung giai đoạn thứ năm Adjourning (giải tán). Điều quan trọng cần nhớ: đây không phải một đường thẳng đi một chiều. Khi có thành viên mới gia nhập, khi team đổi sản phẩm, đổi sếp, hay trải qua một sự cố lớn — team có thể "rớt" ngược về giai đoạn trước. Một team Performing hôm nay vẫn có thể quay về Storming nếu mất hai người chủ chốt.
1. Forming (Hình thành) — Team vừa mới ráp lại. Mọi người lịch sự, dè dặt, chưa hiểu nhau, chưa rõ vai trò và cách làm việc. Năng suất thấp vì còn nhiều mơ hồ. Họ phụ thuộc nhiều vào người dẫn dắt để được định hướng. An toàn tâm lý còn mong manh — không ai dám nói thẳng vì sợ bị đánh giá.
2. Storming (Bão tố) — Khi đã quen mặt, các khác biệt bắt đầu lộ ra. Xung đột về cách làm, về quyền lực, về tiêu chuẩn chất lượng nổi lên bề mặt. Đây là giai đoạn khó chịu nhất nhưng cũng cần thiết nhất — team nào né tránh hoàn toàn Storming thường là team đang giả vờ hòa thuận (false harmony) và sẽ trả giá sau.
3. Norming (Định chuẩn) — Team bắt đầu hình thành các thỏa thuận, chuẩn mực chung. Họ biết cách giải quyết bất đồng, biết ai giỏi việc gì, tin tưởng nhau hơn. Năng suất tăng dần. Họ chuyển từ "tôi" sang "chúng tôi".
4. Performing (Vận hành đỉnh cao) — Team tự tổ chức thật sự, ra quyết định nhanh, xử lý xung đột một cách lành mạnh mà không cần SM can thiệp nhiều. Họ liên tục tự cải tiến. Vai trò SM lúc này chuyển nhiều sang "thầy dạy" và "người mở rộng tầm nhìn".
Nguyên tắc nền tảng: công cụ phải khớp với giai đoạn
Logic chọn công cụ dựa trên một ý tưởng đơn giản: mỗi giai đoạn có một "nhu cầu chủ đạo" khác nhau, và công cụ tốt là công cụ phục vụ đúng nhu cầu chủ đạo đó.
- Forming cần: an toàn, làm quen, sự rõ ràng. → Chọn công cụ nhẹ, có cấu trúc cao, ít rủi ro bộc lộ. Ví dụ: Hopes and Fears, Team Chartering, Working Agreements, các retro đơn giản như Plus/Delta hay Mad/Sad/Glad, các trò phá băng nhẹ.
- Storming cần: kênh xả xung đột an toàn, làm rõ kỳ vọng lẫn nhau, tách vấn đề ra khỏi con người. → Chọn công cụ giúp đưa xung đột lên bàn một cách có cấu trúc và phi cá nhân hóa. Ví dụ: WINFY (What I Need From You), Conflict Mediation Tools, TRIZ (bóc anti-pattern một cách hài hước), Five Whys / Fishbone để quy về vấn đề hệ thống thay vì đổ lỗi cá nhân.
- Norming cần: củng cố thỏa thuận, đào sâu cải tiến, đa dạng góc nhìn. → Công cụ phong phú hơn, đào sâu hơn: Starfish, 4Ls, Sailboat, Six Thinking Hats, Lean Coffee, Liberating Structures phức tạp hơn.
- Performing cần: thử thách, đổi mới, tầm nhìn lớn, tránh tự mãn. → Công cụ chiến lược và khiêu khích tư duy: Premortem, Wicked Questions, Ecocycle Planning, Min Specs, Impact Mapping, Open Space.
Hai trục cần đọc thêm ngoài "giai đoạn"
Giai đoạn Tuckman là trục chính, nhưng một SM giỏi còn đọc thêm hai biến số:
- An toàn tâm lý (psychological safety) — Team có dám nói thật không? Đây là yếu tố quyết định bạn được đẩy sâu đến đâu. Một team Norming về kỹ thuật nhưng an toàn tâm lý thấp thì vẫn phải dùng công cụ nhẹ như team Forming.
- Tải năng lượng / bối cảnh thời điểm — Team vừa cháy deadline, vừa bị reorg, vừa mất người? Dù trưởng thành đến đâu, lúc này hãy chọn công cụ nhẹ, nuôi dưỡng, đừng đào sâu.
Tình huống thực tế
Tình huống 1 — Team mới tại một fintech ở TP.HCM: đừng đào sâu khi gạch lòng tin chưa khô
Một startup fintech tại Quận 1 (gọi là "MoMoPay Labs" cho dễ hình dung) vừa lập một squad mới gồm 7 người: 3 dev cũ chuyển từ team khác sang, 3 dev mới tuyển, và 1 QA. Anh SM mới về, vốn rất mê retro kiểu "radical candor", quyết định ngay sprint đầu tiên chạy một retrospective yêu cầu mỗi người nói "một điều bạn nghĩ người ngồi bên cạnh nên cải thiện".
Kết quả: phòng họp im lặng đến ngột ngạt. Ba bạn mới không dám hé răng vì mới vào một tuần. Mấy bạn cũ thì nói vài câu xã giao vô thưởng vô phạt. Một bạn QA bị một dev "góp ý thẳng" về chất lượng test case, mặt biến sắc và ba ngày sau xin chuyển team.
Diễn giải: Team đang ở Forming. Nhu cầu chủ đạo là an toàn và làm quen, không phải đối chất. Công cụ "phản hồi thẳng cá nhân" là công cụ của giai đoạn Norming/Performing, nơi lòng tin đã đủ dày để chịu được va chạm.
Bài học: Nếu được làm lại, sprint đầu nên là Hopes and Fears (mỗi người chia sẻ kỳ vọng và nỗi lo về team mới — đây là chia sẻ về bản thân, an toàn hơn nhiều so với phán xét người khác), tiếp theo là một buổi Team Working Agreements để cùng nhau định ra luật chơi. Retro đầu nên là Mad/Sad/Glad hoặc Plus/Delta — nhẹ, tập trung vào quy trình chứ không vào con người.
Tình huống 2 — Team Storming tại một công ty outsourcing ở Đà Nẵng: dùng cấu trúc để xả xung đột
Một team 6 người tại một công ty gia công phần mềm ở Đà Nẵng đã làm chung được khoảng 3 tháng. Lúc này hai "phe" hình thành rõ: nhóm dev senior muốn refactor codebase cho sạch, nhóm còn lại muốn cứ giao tính năng cho kịp deadline với khách Nhật. Các buổi daily bắt đầu căng, có hôm hai bạn lời qua tiếng lại. PO thì sốt ruột vì velocity tụt.
Chị SM nhận ra đây là Storming điển hình — và điều cần làm không phải là dập tắt xung đột mà là dẫn nó qua một cái máng có cấu trúc. Chị chọn hai công cụ:
- Một buổi WINFY (What I Need From You): từng nhóm nói rõ "điều tôi cần từ phía bên kia" theo một format cố định, kết thúc bằng câu trả lời "Có / Sẽ cố / Không / Tùy". Việc đóng khung lại biến những bức xúc mơ hồ thành các yêu cầu cụ thể, có thể thương lượng.
- Một buổi Fishbone (Ishikawa) để phân tích "vì sao velocity tụt", quy vấn đề về nguyên nhân hệ thống (nợ kỹ thuật, ước lượng kém, yêu cầu thay đổi liên tục) thay vì về "tại nhóm kia".
Diễn giải & bài học: Storming không phải dấu hiệu team tệ — nó là dấu hiệu team đang lớn lên. SM giỏi không né xung đột mà cấp cho nó một cấu trúc an toàn. Công cụ tách-vấn-đề-khỏi-con-người (Fishbone, Five Whys) và công cụ làm-rõ-kỳ-vọng (WINFY) là vũ khí chính của giai đoạn này.
Tình huống 3 — Team Performing tại một sản phẩm SaaS Singapore: thách thức để tránh tự mãn
Một product team 8 người ở một công ty SaaS tại Singapore đã làm chung gần hai năm. Họ tự tổ chức xuất sắc: daily gọn trong 8 phút, retro luôn ra action item và thực thi nghiêm túc, velocity ổn định. Nhưng SM nhận thấy một mùi nguy hiểm: các retro gần đây nhạt dần, ai cũng nói "sprint ổn, không có gì lớn". Đó là dấu hiệu complacency (tự mãn) — căn bệnh của team Performing.
SM quyết định không dùng các retro thông thường nữa mà nâng độ khó:
- Một buổi Premortem: "Giả sử 6 tháng nữa sản phẩm thất bại thảm hại — hãy kể cho tôi nghe vì sao." Bài tập tưởng tượng thất bại này lôi ra những rủi ro mà không ai dám nói khi mọi thứ đang "ổn".
- Một buổi Wicked Questions để bề mặt hóa các nghịch lý chiến lược ("Làm sao vừa ship nhanh cho khách enterprise vừa giữ codebase đủ sạch để scale?").
Bài học: Với team Performing, kẻ thù không phải xung đột mà là sự thoải mái. Công cụ phù hợp là công cụ khiêu khích, chiến lược, hướng tương lai — Premortem, Wicked Questions, Ecocycle, Impact Mapping. Đem mấy thứ này cho một team Forming thì vô dụng; đem cho team Performing thì như thổi luồng gió mới.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng mỗi khi cần chọn công cụ cho một buổi làm việc bất kỳ (retro, refinement, workshop...).
Bước 1 — Chẩn đoán giai đoạn của team. Quan sát các tín hiệu cụ thể, đừng đoán mò:
- Forming: nhiều câu hỏi "ai làm việc này?", "quy trình mình thế nào?"; ý kiến lịch sự, ít tranh luận.
- Storming: tranh luận gay gắt, có "phe"; daily căng thẳng; đổ lỗi qua lại.
- Norming: bắt đầu có thỏa thuận; tự nhắc nhau giữ luật; "chúng ta" nhiều hơn "tôi".
- Performing: tự ra quyết định; retro vẫn sâu sắc; SM ít phải can thiệp.
Bước 3 — Xác định nhu cầu chủ đạo của buổi này. Hãy viết một câu: "Mục tiêu thật sự của buổi này là ___." (xây lòng tin? xả xung đột? đào sâu cải tiến? thách thức tư duy?).
Bước 4 — Chọn 1–2 công cụ khớp với nhu cầu đó. Dùng bản đồ giai đoạn → công cụ ở phần Khái niệm cốt lõi làm điểm xuất phát. Ưu tiên công cụ bạn đã thực sự thành thạo hơn là công cụ "ngầu" mà bạn mới đọc.
Bước 5 — Hạ một bậc khi nghi ngờ. Nếu phân vân giữa "đào sâu" và "nhẹ nhàng", hãy chọn nhẹ nhàng. Hậu quả của việc đào quá nông là buổi họp hơi nhạt; hậu quả của việc đào quá sâu khi team chưa sẵn sàng là mất an toàn tâm lý — tốn hàng tháng để xây lại.
Bước 6 — Quan sát phản ứng và điều chỉnh. Trong buổi, đọc ngôn ngữ cơ thể. Im lặng dè dặt = bạn đẩy hơi sâu, lùi lại. Hào hứng tranh luận lành mạnh = đúng liều. Lần sau hiệu chỉnh dựa trên dữ liệu này.
Lỗi thường gặp & mẹo
Lỗi 1 — "Búa vàng" (golden hammer). Yêu thích một công cụ và áp nó cho mọi team, mọi giai đoạn. Mẹo: trước mỗi buổi, tự hỏi "Mình chọn công cụ này vì nó hợp tình huống hay vì nó là món tủ của mình?".
Lỗi 2 — Tưởng mô hình Tuckman là đường một chiều. Team có thể thụt lùi. Mẹo: mỗi khi team thay đổi nhân sự, đổi sản phẩm, hoặc qua một cú sốc lớn — hãy giả định team rớt về Forming/Storming và tạm thời quay lại công cụ nhẹ.
Lỗi 3 — Chẩn đoán giai đoạn qua "cảm giác" thay vì tín hiệu. Mẹo: ghi lại 2–3 quan sát cụ thể (câu nói, hành vi) làm bằng chứng cho chẩn đoán của bạn.
Lỗi 4 — Bỏ quên an toàn tâm lý, chỉ nhìn "thâm niên". Một team làm chung 2 năm chưa chắc đã Performing — họ có thể đang "giả hòa thuận" ở mức Forming kéo dài. Mẹo: đo an toàn tâm lý độc lập với thời gian làm việc cùng nhau.
Lỗi 5 — Né tránh Storming. Nhiều SM Việt Nam ngại xung đột vì văn hóa "dĩ hòa vi quý". Nhưng một team không bao giờ Storming là team không bao giờ thật sự Norming. Mẹo: đừng dập xung đột, hãy cho nó một cái máng có cấu trúc (xem Tình huống 2).
Mẹo tổng quát: Hãy duy trì một bảng cá nhân (ở bài "Xây dựng SM Toolbox" bạn sẽ làm kỹ hơn) ghi: tên công cụ — giai đoạn phù hợp — nhu cầu nó phục vụ — lần cuối mình dùng và kết quả. Đây là la bàn chọn công cụ của riêng bạn.
Bài tập thực hành
Bài tập 1 — Chẩn đoán team hiện tại của bạn. Viết ra 3 tín hiệu cụ thể (câu nói/hành vi quan sát được trong 2 tuần qua) và từ đó kết luận team bạn đang ở giai đoạn nào. Chấm thêm điểm an toàn tâm lý từ 1–5 và giải thích.
Bài tập 2 — Lập bản đồ công cụ. Lấy 8 công cụ bạn đã học trong khóa này, xếp mỗi công cụ vào (các) giai đoạn phù hợp nhất và viết một câu nêu "nhu cầu chủ đạo" mà nó phục vụ.
Bài tập 3 — Tình huống ngược. Cho tình huống sau: "Team 5 người, làm chung 4 tháng, gần đây hai bạn senior công khai bất đồng về kiến trúc trong daily, velocity giảm 30%." Hãy (a) xác định giai đoạn, (b) nêu nhu cầu chủ đạo, (c) chọn 2 công cụ và giải thích vì sao, (d) nêu một công cụ bạn sẽ tránh và lý do.
Bài tập 4 — Kế hoạch buổi tới. Áp dụng quy trình 6 bước ở phần Hướng dẫn cho buổi retro/refinement gần nhất sắp tới của bạn. Viết ra từng bước và công cụ cuối cùng bạn chọn.
Tóm tắt
- Sau khi đã có kho công cụ phong phú, kỹ năng quan trọng nhất là chọn đúng công cụ cho đúng tình huống — và biến số chính để chọn là độ trưởng thành của team.
- Mô hình Tuckman gồm Forming → Storming → Norming → Performing (và Adjourning). Đây không phải đường một chiều — team có thể thụt lùi khi đổi người, đổi sản phẩm, hay gặp cú sốc.
- Mỗi giai đoạn có một nhu cầu chủ đạo riêng: Forming cần an toàn và sự rõ ràng (công cụ nhẹ, cấu trúc cao); Storming cần kênh xả xung đột có cấu trúc (WINFY, Fishbone, TRIZ); Norming cần đào sâu cải tiến (Starfish, 4Ls, Six Thinking Hats); Performing cần thách thức và tầm nhìn (Premortem, Wicked Questions, Ecocycle).
- Đọc thêm hai biến số: an toàn tâm lý và năng lượng/bối cảnh thời điểm — chúng có thể buộc bạn "hạ một bậc" công cụ dù team trưởng thành.
- Khi phân vân, chọn công cụ nhẹ hơn: rủi ro đào quá sâu khi team chưa sẵn sàng tốn kém hơn nhiều so với một buổi hơi nhạt.
- Tránh "búa vàng": chọn công cụ vì nó hợp tình huống, không phải vì nó là món tủ của bạn.