Menu
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Đang tải...

Bài 9 — Coaching Teams — Group dynamics

Advanced Scrum Master PSM II Bài 9/60

Mở đầu — vì sao bài này quan trọng

Ở cấp độ PSM I, chúng ta thường nhìn nhóm như một danh sách những con người ngồi cạnh nhau, mỗi người có vai trò và đầu việc riêng. Nhưng một Scrum Master ở cấp độ PSM II phải nhìn xa hơn: nhóm không phải là phép cộng của các cá nhân, mà là một hệ thống sống có nhịp đập riêng, có cảm xúc tập thể, có những "luật ngầm" mà không ai viết ra nhưng ai cũng tuân theo.

Đây chính là điểm khác biệt lớn giữa coaching cá nhân (Bài 8) và coaching nhóm (bài này). Khi bạn coach một người, bạn làm việc với suy nghĩ và hành vi của riêng họ. Khi bạn coach một nhóm, bạn làm việc với group dynamics — động lực nhóm — tức là cách các thành viên tương tác, ảnh hưởng, kéo hoặc đẩy lẫn nhau. Một thành viên giỏi có thể bị "trung hòa" bởi một nhóm độc hại; ngược lại, một nhóm khỏe mạnh có thể nâng đỡ cả những người yếu nhất.

Nếu bạn không hiểu group dynamics, bạn sẽ thường xuyên bối rối: "Tại sao retro nào cũng êm đềm nhưng vấn đề không bao giờ được giải quyết?", "Tại sao nhóm này cãi nhau suốt mà vẫn ra kết quả tốt, còn nhóm kia hòa thuận mà trì trệ?". Câu trả lời nằm ở chỗ mỗi nhóm đang ở một giai đoạn phát triển khác nhau, và mỗi giai đoạn cần một cách can thiệp khác nhau. Hiểu được điều này, bạn sẽ thôi áp dụng cùng một "công thức" cho mọi nhóm, và bắt đầu coach đúng thứ nhóm thực sự cần.

Khái niệm cốt lõi

Tuckman's Stages — bốn (rồi năm) giai đoạn phát triển nhóm

Năm 1965, nhà tâm lý học Bruce Tuckman đưa ra mô hình mô tả hành trình mà gần như mọi nhóm đều đi qua. Mô hình này đơn giản nhưng cực kỳ hữu dụng cho Scrum Master vì nó cho bạn một "bản đồ" để định vị nhóm mình đang ở đâu.

1. Forming (Hình thành) — lịch sự nhưng dè dặt. Đây là giai đoạn "trăng mật". Mọi người mới gặp nhau hoặc mới được ghép thành nhóm. Ai cũng lịch sự, giữ ý, tránh xung đột. Bề ngoài có vẻ hòa thuận nhưng thực chất là sự né tránh: chưa ai dám nói thật, chưa ai biết ranh giới của nhau. Năng suất thấp vì nhóm còn loay hoay tìm hiểu "chúng ta là ai, làm việc cùng nhau thế nào". Thành viên hướng nhiều câu hỏi về phía Scrum Master và leader — họ cần định hướng.

2. Storming (Bão tố) — xung đột nổi lên bề mặt. Khi sự dè dặt ban đầu tan biến, những khác biệt thật bắt đầu lộ ra. Người này thấy người kia làm ẩu, người kia thấy người này quá cầu toàn. Có tranh cãi về cách làm, về quyền quyết định, về "ai mới đúng". Đây là giai đoạn khó chịu nhất nhưng quan trọng nhất. Nhiều Scrum Master non kinh nghiệm sợ xung đột nên cố dập tắt, vô tình đẩy nhóm quay lại Forming giả tạo. Thực ra storming là dấu hiệu lành mạnh: nó cho thấy mọi người đã đủ tin tưởng để bất đồng công khai.

3. Norming (Chuẩn hóa) — luật chơi được thống nhất. Sau cơn bão, nhóm bắt đầu tự thiết lập các "norms" — chuẩn mực, quy ước làm việc. Họ thống nhất Definition of Done thực chất, cách review code, cách xử lý khi ai đó bị block, giờ Daily Scrum, văn hóa phản hồi. Niềm tin tăng lên. Mọi người bắt đầu giúp đỡ nhau thay vì bảo vệ lãnh thổ. Năng suất tăng dần.

4. Performing (Vận hành đỉnh cao) — nhóm tự vận hành. Đây là giai đoạn nhóm thực sự self-managing. Họ giải quyết vấn đề mà không cần Scrum Master chỉ đạo, tự điều chỉnh, tự cải tiến. Vai trò của Scrum Master chuyển từ "định hướng" sang "đứng xa quan sát và thỉnh thoảng gợi mở". Đây là đích đến, nhưng cần nhớ: rất ít nhóm ở mãi đây.

5. Adjourning (Giải thể) — Tuckman bổ sung sau này. Khi dự án kết thúc hoặc nhóm tái cấu trúc, có một quá trình "chia tay" về mặt cảm xúc. Scrum Master cần ghi nhận thành quả và giúp mọi người khép lại đẹp đẽ.

Điều quan trọng nhất: các giai đoạn KHÔNG tuyến tính

Một sai lầm phổ biến là nghĩ nhóm đi thẳng từ 1 đến 4 rồi dừng. Thực tế, bất kỳ thay đổi nào cũng có thể đẩy nhóm quay về Storming hoặc Forming: thêm thành viên mới, đổi Product Owner, đổi công nghệ, tái cơ cấu công ty, thậm chí một Sprint thất bại nặng. Một nhóm đang Performing có thể "tụt" về Storming chỉ sau một tuần khi sếp lớn nghỉ việc. Scrum Master giỏi không hoảng khi điều này xảy ra — họ nhận diện và coach lại đúng giai đoạn.

Coaching style phải đổi theo giai đoạn

Đây là phần ứng dụng cốt lõi. Mô hình Situational Leadership gợi ý rằng phong cách dẫn dắt phải thay đổi:

  • Forming → Scrum Master mang phong cách directing/structuring: tạo cấu trúc, làm rõ Scrum, thiết lập an toàn, giúp mọi người làm quen. Đây chưa phải lúc đặt câu hỏi mở quá nhiều.
  • Storming → phong cách facilitating/coaching xung đột: không dập tắt mà giúp nhóm bất đồng một cách lành mạnh, đưa xung đột ra ánh sáng, dạy nhóm tách "vấn đề" khỏi "con người".
  • Norming → phong cách supporting: lùi lại, để nhóm tự đặt luật, chỉ can thiệp khi norms hình thành lệch hướng.
  • Performing → phong cách delegating/observing: gần như vô hình, chỉ bảo vệ nhóm khỏi nhiễu loạn bên ngoài và gợi mở khi cần.
Nếu bạn dùng phong cách "delegating" với một nhóm đang Forming, họ sẽ hỗn loạn vì thiếu định hướng. Nếu bạn dùng "directing" với nhóm đang Performing, bạn bóp nghẹt sự tự chủ của họ. Đọc đúng giai đoạn rồi chọn đúng style — đó là nghệ thuật coaching nhóm.

Tình huống thực tế

Tình huống 1 — Nhóm "quá hòa thuận" tại một fintech ở TP.HCM

Một công ty fintech tại Quận 1, TP.HCM thành lập nhóm mới gồm 7 kỹ sư để xây dựng module thanh toán QR. Sau 3 Sprint, mọi Sprint Review đều "ổn", mọi Retro đều kết thúc bằng câu "nhóm mình làm tốt rồi, không có gì để cải thiện". Anh Tuấn, Scrum Master, ban đầu hài lòng. Nhưng velocity lại không tăng và có 2 bug nghiêm trọng lọt ra production.

Diễn giải: Tuấn nhận ra nhóm đang kẹt ở Forming, không phải đang ở Performing như anh tưởng. Sự "hòa thuận" thực ra là né tránh — các kỹ sư mới ghép nhóm, đa số là người miền Bắc và miền Trung mới chuyển vào, chưa đủ thân để dám phản biện nhau. Một bạn senior thấy code của bạn khác có vấn đề nhưng ngại nói vì "mới quen, nói ra sợ mất lòng". Đây chính là biểu hiện kinh điển của Forming kéo dài.

Tuấn thay đổi cách facilitate Retro: thay vì hỏi chung chung "có gì cải thiện không", anh dùng kỹ thuật viết ẩn danh trên sticky note, rồi gom nhóm các ý kiến lại. Lần đầu tiên, những bất đồng âm ỉ được đưa ra giấy — về review code hời hợt, về việc một người ôm quá nhiều task quan trọng. Nhóm bước vào Storming. Trong 2 tuần đầu khá căng, nhưng đến Sprint thứ 6 họ tự thống nhất được quy ước review (Norming) và bug production giảm hẳn.

Bài học: Hòa thuận không phải lúc nào cũng là dấu hiệu nhóm khỏe mạnh. Một nhóm chưa bao giờ Storming thường là nhóm chưa đủ tin tưởng để bất đồng. Việc của Scrum Master đôi khi là tạo điều kiện cho xung đột lành mạnh xuất hiện, không phải giữ cho mặt nước phẳng lặng.

Tình huống 2 — Một thành viên mới kéo nhóm Performing tụt về Storming

Tại một công ty outsourcing phần mềm ở Đà Nẵng, nhóm "Falcon" gồm 6 người đã làm việc cùng nhau 14 tháng, đạt trạng thái Performing rõ rệt: tự phân chia công việc, tự giải quyết block, Scrum Master gần như chỉ ngồi quan sát. Rồi công ty thắng một hợp đồng lớn từ khách hàng Nhật, cần scale gấp. Họ thêm 3 kỹ sư mới cùng lúc vào nhóm Falcon, nâng lên 9 người.

Chỉ sau 2 tuần, không khí nhóm thay đổi. Daily Scrum dài lê thê, tranh cãi về coding convention vốn đã ổn định trở lại nảy lửa, vài thành viên cũ tỏ ra khó chịu vì "phải giải thích lại từ đầu".

Diễn giải: Chị Linh, Scrum Master, ban đầu lo lắng vì nghĩ nhóm "thoái hóa". Nhưng nhìn qua lăng kính Tuckman, chị hiểu đây là điều tất yếu: thêm 3 thành viên = một nhóm mới về bản chất, và nó bị kéo về Storming. Chị không cố ép nhóm trở lại nhịp cũ. Thay vào đó, chị tổ chức một buổi team agreement workshop để cả nhóm — cũ lẫn mới — cùng viết lại Working Agreement và Definition of Done, thay vì để người cũ áp đặt luật cũ lên người mới. Chị cũng tạm thời quay lại phong cách facilitating tích cực hơn trong các sự kiện. Sau khoảng 5 tuần, Falcon ổn định lại ở Norming và dần trở về Performing với 9 người.

Bài học: Mọi thay đổi về thành phần nhóm đều reset một phần group dynamics. Đừng kỳ vọng nhóm cũ "dạy" nhóm mới rồi mọi thứ tự ổn. Scrum Master phải chủ động đưa nhóm đi lại qua các giai đoạn, và sẵn sàng "downshift" phong cách coaching về directing/facilitating khi cần.

Tình huống 3 — Storming bị hiểu nhầm là "nhóm có vấn đề thái độ"

Một startup thương mại điện tử ở Hà Nội có nhóm 5 người thường xuyên tranh luận gay gắt trong Sprint Planning về kiến trúc hệ thống. Một quản lý cấp trên dự một buổi, thấy "cãi nhau" liền yêu cầu Scrum Master "chấn chỉnh thái độ nhóm, làm việc phải hòa nhã".

Diễn giải: Anh Phong, Scrum Master, đứng trước lựa chọn khó. Nếu nghe sếp và dập xung đột, nhóm sẽ thụt lùi. Phong quan sát kỹ và nhận ra: tranh luận của nhóm luôn xoay quanh vấn đề kỹ thuật, không công kích cá nhân, và sau mỗi lần "cãi" họ vẫn ăn trưa vui vẻ cùng nhau. Đây là Storming lành mạnh, thậm chí là dấu hiệu của một nhóm đang tiến gần Norming. Phong giải thích với quản lý bằng ngôn ngữ của mô hình Tuckman, cho thấy đây là giai đoạn cần thiết để nhóm tự xây chuẩn mực, và cam kết sẽ chỉ can thiệp nếu xung đột chuyển sang công kích cá nhân. Anh cũng dạy nhóm một quy ước nhỏ: "tranh luận về ý tưởng, không tranh luận về con người" và "disagree and commit" sau khi đã quyết.

Bài học: Không phải mọi xung đột đều xấu, và một phần việc của Scrum Master là bảo vệ giai đoạn Storming lành mạnh trước áp lực từ bên ngoài muốn "mọi thứ phải êm đẹp". Phân biệt được xung đột-về-vấn đề (lành mạnh) và xung đột-về-con người (độc hại) là kỹ năng cốt lõi.

Hướng dẫn từng bước

Đây là quy trình thực tế để coach nhóm dựa trên group dynamics:

  • Quan sát và chẩn đoán giai đoạn. Trước khi can thiệp, dành ít nhất 1–2 Sprint để quan sát. Hỏi: Mức độ thẳng thắn của nhóm thế nào? Họ có dám bất đồng công khai không? Ai đang đặt câu hỏi cho ai? Có "luật ngầm" nào đang chi phối không? Dùng các sự kiện Scrum như "phòng thí nghiệm" để đọc động lực nhóm.
  • Định vị trên bản đồ Tuckman. Xác định nhóm đang ở Forming, Storming, Norming hay Performing. Cẩn thận với "Forming giả trang Performing" (hòa thuận do né tránh) như tình huống 1.
  • Chọn phong cách coaching tương ứng. Forming → directing; Storming → facilitating; Norming → supporting; Performing → delegating. Viết ra cho chính mình phong cách bạn sẽ dùng trong Sprint tới.
  • Can thiệp đúng đòn bẩy. Ở Forming: tạo cấu trúc và an toàn. Ở Storming: đưa xung đột ra ánh sáng một cách an toàn (sticky note ẩn danh, facilitation kỹ). Ở Norming: giúp nhóm hệ thống hóa Working Agreement. Ở Performing: lùi lại và bảo vệ nhóm khỏi nhiễu loạn.
  • Theo dõi tín hiệu chuyển giai đoạn. Mỗi khi có thay đổi lớn (người mới, đổi PO, tái cơ cấu), chủ động dự đoán nhóm sẽ bị kéo về giai đoạn sớm hơn và chuẩn bị coach lại.
  • Phản tư sau mỗi Sprint. Tự hỏi: phong cách của mình tuần này có khớp với giai đoạn nhóm không? Mình đang giúp nhóm tiến lên hay vô tình giữ nhóm lại?

Lỗi thường gặp & mẹo

Lỗi 1 — Coi hòa thuận là đích đến. Nhiều Scrum Master tự hào vì nhóm "không bao giờ cãi nhau". Đó có thể là dấu hiệu nhóm kẹt ở Forming. Mẹo: nếu nhóm chưa từng Storming, hãy chủ động tạo không gian an toàn cho bất đồng.

Lỗi 2 — Dập tắt Storming vì sợ. Xung đột làm Scrum Master non kinh nghiệm khó chịu, nên họ vội hòa giải. Mẹo: phân biệt xung đột-về-vấn đề (cần khuyến khích) và xung đột-về-con người (cần can thiệp). Chỉ can thiệp loại thứ hai.

Lỗi 3 — Dùng một phong cách cho mọi nhóm, mọi lúc. Áp delegating lên nhóm Forming gây hỗn loạn; áp directing lên nhóm Performing gây ngột ngạt. Mẹo: coi phong cách coaching như một "núm vặn" cần điều chỉnh liên tục, không phải một cài đặt cố định.

Lỗi 4 — Quên rằng giai đoạn có thể đảo ngược. Thêm người, đổi sếp, đổi tech → nhóm tụt giai đoạn. Mẹo: mỗi khi có thay đổi thành phần, hãy chủ động tổ chức lại Working Agreement thay vì kỳ vọng nhóm tự xử.

Lỗi 5 — Coach cá nhân khi vấn đề nằm ở hệ thống nhóm. Một người "im lặng" trong nhóm có thể không phải do tính cách, mà do norm ngầm "ai nói nhiều sẽ bị giao thêm việc". Mẹo: luôn tự hỏi "đây là vấn đề của người này, hay là triệu chứng của động lực nhóm?".

Bài tập thực hành

  • Chẩn đoán nhóm của bạn. Viết ra một trang: nhóm bạn đang coach đang ở giai đoạn Tuckman nào? Liệt kê 3 bằng chứng cụ thể (cách họ hành xử trong Retro, mức độ bất đồng công khai, ai đặt câu hỏi cho ai). Nếu nghi ngờ "Forming giả Performing", giải thích vì sao.
  • Lập kế hoạch phong cách. Dựa trên giai đoạn vừa chẩn đoán, viết phong cách coaching bạn sẽ dùng trong Sprint tới (directing/facilitating/supporting/delegating) và 2 hành động cụ thể tương ứng.
  • Mô phỏng cú sốc. Tưởng tượng tuần sau nhóm bạn thêm 2 thành viên mới. Viết ra: nhóm sẽ bị kéo về giai đoạn nào, và bạn sẽ làm 3 việc gì để giúp nhóm vượt qua nhanh nhất.
  • Quan sát xung đột. Trong Retro hoặc Planning tới, ghi lại một lần nhóm bất đồng. Phân loại: đó là xung đột-về-vấn đề hay về-con người? Cách bạn xử lý có phù hợp không?

Tóm tắt

Coaching nhóm khác hẳn coaching cá nhân vì bạn đang làm việc với một hệ thống sống có động lực riêng — group dynamics. Mô hình Tuckman cho bạn bản đồ bốn giai đoạn: Forming (lịch sự, dè dặt), Storming (xung đột nổi lên), Norming (luật chơi được thống nhất) và Performing (nhóm tự vận hành), cộng thêm Adjourning khi nhóm giải thể. Điều cốt lõi cần nhớ: các giai đoạn không tuyến tính — bất kỳ thay đổi nào về thành phần nhóm hay môi trường cũng có thể kéo nhóm tụt về giai đoạn sớm hơn. Nhiệm vụ của Scrum Master là đọc đúng giai đoạn rồi điều chỉnh phong cách coaching cho phù hợp: directing ở Forming, facilitating ở Storming, supporting ở Norming, delegating ở Performing. Đừng coi hòa thuận là đích đến, đừng sợ Storming lành mạnh, và luôn tự hỏi vấn đề trước mắt là của cá nhân hay là triệu chứng của động lực nhóm. Khi bạn thành thạo việc này, bạn sẽ thôi áp dụng một công thức cứng nhắc và bắt đầu coach đúng thứ mà nhóm thực sự cần ở thời điểm đó.