Mở đầu — vì sao bài này quan trọng
Nếu bạn đã thi đậu PSM I, xin chúc mừng — bạn đã chứng minh được rằng mình biết Scrum. Bạn thuộc lòng ba vai trò (accountabilities), năm sự kiện (events), ba artifact và những cam kết đi kèm. Bạn biết Sprint không bao giờ dài quá một tháng, Daily Scrum là 15 phút, và Product Owner là người duy nhất sắp xếp Product Backlog. Đó là kiến thức nền tảng — không thể thiếu.
Nhưng đây là sự thật phũ phàng mà rất nhiều Scrum Master Việt Nam gặp phải sau 1–2 năm đi làm: biết Scrum không có nghĩa là bạn giúp được tổ chức làm Scrum tốt hơn. Bạn có thể đọc vanh vách Scrum Guide nhưng vẫn bất lực khi nhìn team họp Retrospective một cách hình thức, khi Product Owner thực chất chỉ là một người chuyển tin nhắn từ sếp xuống, hay khi team "cam kết" Sprint Goal chỉ để làm vừa lòng quản lý.
Đó chính là vực sâu ngăn cách giữa PSM I và PSM II. PSM I hỏi bạn "Scrum là gì?". PSM II hỏi bạn "Trong tình huống này, với những ràng buộc này, bạn — với tư cách Scrum Master — sẽ làm gì, và tại sao?". Bài này không dạy bạn thêm một kỹ thuật facilitation hay một mô hình coaching nào cả (những thứ đó nằm ở các bài sau). Bài này làm một việc quan trọng hơn: tái cấu trúc cách bạn tư duy — chuyển từ tư duy của một người thực thi luật chơi sang tư duy của một người giúp người khác chơi giỏi hơn. Nếu không vượt qua được sự dịch chuyển tư duy (mindset shift) này, mọi kỹ thuật bạn học ở phần còn lại của khóa sẽ chỉ là công cụ rời rạc, áp dụng máy móc và thường phản tác dụng.
Khái niệm cốt lõi
Sự khác biệt cốt lõi: từ "What" sang "How" và "Why"
Hãy bắt đầu bằng bảng so sánh nền tảng — bạn sẽ thấy mọi sự khác biệt khác đều nảy sinh từ đây:
| Khía cạnh | PSM I | PSM II |
|---|---|---|
| Kiến thức | "Scrum là gì?" — luật, định nghĩa, quy tắc | "Scrum áp dụng thế nào?" — vận dụng vào tình huống cụ thể |
| Câu hỏi cốt lõi | "Đúng hay sai theo Scrum Guide?" | "Điều gì sẽ giúp team này tiến lên?" |
| Vị thế | Người nắm luật, người nhắc nhở | Người làm vườn (gardener), người tạo điều kiện |
| Trọng tâm | Process — sự kiện, artifact diễn ra đúng | Outcome — giá trị, sự cải thiện, sức khỏe của hệ thống |
| Phản ứng với vấn đề | Áp dụng đúng quy tắc | Chẩn đoán nguyên nhân gốc, rồi mới chọn cách can thiệp |
| Phạm vi | Team | Team + tổ chức + hệ thống xung quanh |
| Câu trả lời điển hình | "Theo Scrum thì phải..." | "Còn tùy — bạn đang cố giải quyết vấn đề gì?" |
Ba sự dịch chuyển tư duy quan trọng nhất
1. Từ "tuân thủ" sang "hiệu quả" (compliance → effectiveness). Scrum Master PSM I thường ám ảnh với việc team có làm đúng không: Daily có đủ 15 phút không, có đứng không, có trả lời ba câu hỏi không. Scrum Master PSM II hỏi câu khác: "Daily Scrum này có thực sự giúp team tự tổ chức để đạt Sprint Goal không?". Một Daily 15 phút diễn ra đầy đủ nhưng vô hồn còn tệ hơn một Daily 12 phút mà cả team thực sự đồng bộ. Scrum không phải mục tiêu — Scrum là phương tiện. Mục tiêu là giá trị giao cho khách hàng và sự trưởng thành của team.
2. Từ "giải quyết vấn đề hộ team" sang "phát triển năng lực của team". Đây là cái bẫy lớn nhất với người Việt chúng ta, vì văn hóa của ta đề cao sự nhiệt tình, "xắn tay làm giúp". Một Scrum Master non sẽ tự mình gỡ impediment, tự mình nhắc việc, tự mình đi đòi câu trả lời từ phòng ban khác. Cảm giác rất hữu ích. Nhưng kết quả là team trở nên phụ thuộc vào bạn. Scrum Master PSM II hiểu mình đang xây dựng một self-managing team — và đôi khi cách giúp tốt nhất là không nhảy vào làm hộ, mà đặt câu hỏi để team tự tìm đường. Bạn đo lường thành công của mình không phải bằng việc "team cần tôi nhiều thế nào" mà bằng "team đã bớt cần tôi đến mức nào".
3. Từ "tập trung vào team" sang "tư duy hệ thống" (systems thinking). PSM I gói gọn trong phạm vi một Scrum Team. Nhưng phần lớn impediment nghiêm trọng nhất lại nằm ngoài team: cấu trúc phòng ban, chính sách thưởng phạt, cách công ty giao ngân sách theo dự án thay vì theo sản phẩm, văn hóa "sếp luôn đúng". Scrum Master PSM II nhìn team như một phần của một hệ thống lớn hơn, và hiểu rằng nhiều khi vấn đề của team chỉ là triệu chứng của một căn bệnh ở tầng tổ chức.
Servant leadership được hiểu lại
Ở PSM I, "servant leader" (lãnh đạo phục vụ) thường bị hiểu thành "người phục vụ team, lo hậu cần, đặt cơm họp, dọn lịch". Ở PSM II, servant leadership có nghĩa sâu hơn: bạn lãnh đạo sự thay đổi bằng cách phục vụ sự phát triển của người khác. Bạn dám đặt câu hỏi khó, dám phản chiếu (mirror) sự thật khó nghe cho cả team lẫn lãnh đạo, dám để team thất bại trong một việc nhỏ để học một bài học lớn. Đó là sự can đảm, không phải sự dễ chịu.
Tình huống thực tế
Tình huống 1: Daily Scrum "đẹp" nhưng vô nghĩa tại một fintech ở TP.HCM
Bối cảnh: Minh, một Scrum Master vừa đậu PSM I, vào làm tại một công ty fintech khoảng 80 người ở Quận 1. Anh rất tự hào vì Daily Scrum của team luôn diễn ra đúng 15 phút, mọi người đứng nghiêm túc, lần lượt trả lời "hôm qua tôi làm gì, hôm nay làm gì, có gì cản trở". Anh báo cáo với quản lý rằng "team tuân thủ Scrum 100%".
Nhưng một quan sát viên (Agile Coach được công ty thuê) ngồi dự ba buổi và phát hiện: mỗi người chỉ báo cáo cho Minh, không ai nói chuyện với nhau. Họ không hề điều chỉnh kế hoạch trong ngày dựa trên thông tin của nhau. Một dev bị block ba ngày liền vẫn nói "có gì cản trở" rồi... không ai làm gì cả. Daily Scrum trở thành buổi điểm danh trá hình.
Diễn giải: Minh đang ở tư duy PSM I — anh đo lường hình thức (đúng giờ, đúng câu hỏi) thay vì hiệu quả (team có tự đồng bộ để đạt Sprint Goal không). Coach hỏi Minh một câu PSM II điển hình: "Mục đích của Daily Scrum là gì, và buổi họp này có đang phục vụ mục đích đó không?". Minh nhận ra mình vô tình biến mình thành trung tâm — mọi người báo cáo cho anh chứ không phối hợp với nhau. Anh thử nghiệm: lùi ra khỏi vòng tròn, đứng dựa tường, không nhận báo cáo nữa, và đề nghị team tự nhìn vào Sprint Backlog để hỏi nhau "chúng ta có đang đi đúng hướng tới Sprint Goal không?". Sau hai tuần, Daily bắt đầu có những cuộc trao đổi thật.
Bài học: Tuân thủ hình thức (compliance) không bằng hiệu quả (effectiveness). Một sự kiện Scrum diễn ra "đúng" vẫn có thể hoàn toàn vô dụng.
Tình huống 2: Người Scrum Master "anh hùng" tại một công ty outsourcing ở Đà Nẵng
Bối cảnh: Lan là Scrum Master của một team 7 người làm dự án outsourcing cho khách hàng Nhật. Cô cực kỳ tận tâm: mỗi khi team gặp vướng mắc với bộ phận khác (DevOps, QA, khách hàng), Lan đều tự mình lao đi giải quyết. Team gọi cô là "chị Lan vạn năng". Velocity của team ổn định, khách hàng hài lòng, sếp khen Lan hết lời.
Rồi Lan nghỉ thai sản ba tháng. Trong ba tuần đầu vắng cô, team gần như tê liệt: không ai biết liên hệ ai bên DevOps, không ai dám trao đổi trực tiếp với khách hàng Nhật vì "trước giờ chị Lan lo hết", các impediment chất đống. Velocity tụt 40%.
Diễn giải: Lan đã làm rất tốt việc gỡ impediment — nhưng theo tư duy PSM I, nơi Scrum Master là người giải quyết vấn đề. Cô vô tình tạo ra một team phụ thuộc, không có năng lực tự quản. Một Scrum Master PSM II sẽ hỏi: "Nếu ngày mai tôi biến mất, team có tự đứng được không?". Đáng lẽ Lan nên dùng mỗi impediment như một cơ hội huấn luyện: thay vì tự đi gặp DevOps, cô đi cùng một thành viên team lần đầu, rồi lần sau để họ tự đi và chỉ hỗ trợ phía sau. Mục tiêu của Scrum Master không phải là trở nên không thể thiếu, mà là dần dần trở nên không cần thiết.
Bài học: Đo lường thành công của Scrum Master bằng năng lực tự quản của team, không phải bằng số việc bạn đã làm hộ.
Tình huống 3: Hai câu trả lời cho cùng một câu hỏi trong phòng thi PSM II
Bối cảnh: Đây là một dạng câu hỏi rất hay gặp trong đề PSM II. "Trong Sprint Planning, Developers nói họ không thể cam kết Sprint Goal vì yêu cầu chưa rõ. Scrum Master nên làm gì?". Các lựa chọn gồm: (A) Yêu cầu Product Owner làm rõ yêu cầu ngay lập tức; (B) Nhắc Developers rằng theo Scrum họ phải cam kết; (C) Quyết định thay phạm vi Sprint; (D) Tạo điều kiện để Developers và Product Owner cùng thảo luận, làm rõ điều gì đã biết/chưa biết và tìm một Sprint Goal khả thi với hiểu biết hiện tại.
Diễn giải: Tư duy PSM I dễ chọn (B) — vì "Scrum Guide nói team phải cam kết". Nhưng đó là cái bẫy. Đáp án PSM II là (D), vì nó thể hiện đúng vị thế của Scrum Master: không ra lệnh, không làm thay (loại C), không đẩy việc một chiều cho PO (A quá vội và bỏ qua Developers), mà tạo điều kiện cho cuộc đối thoại để team tự đi đến quyết định tốt. Lưu ý quan trọng: ở PSM II, các đáp án mang giọng "nhắc nhở về luật" hoặc "Scrum Master tự quyết định thay team" gần như luôn sai. Các đáp án đúng thường mang giọng facilitate, coach, giúp team tự thấy và tự chọn.
Bài học: Khi gặp câu hỏi tình huống, đừng tìm đáp án "đúng luật nhất" — hãy tìm đáp án thể hiện Scrum Master như một người tạo điều kiện giúp team tự ra quyết định, và luôn ưu tiên hiểu rõ vấn đề trước khi hành động.
Hướng dẫn từng bước
Làm sao để thực hành sự dịch chuyển tư duy này trong công việc hằng ngày, và cả trong phòng thi? Đây là một quy trình tư duy bạn có thể áp dụng ngay:
- Khi gặp một tình huống, hãy hỏi "Mục đích là gì?" trước khi hỏi "Luật nói sao?". Trước mỗi sự kiện hay vấn đề, tự nhắc: sự kiện này tồn tại để phục vụ điều gì? Daily Scrum để team tự đồng bộ. Retrospective để team cải tiến. Nếu hành động của bạn không phục vụ mục đích đó, nó vô nghĩa dù có "đúng luật".
- Chẩn đoán trước khi kê đơn. Khi thấy một triệu chứng (team trễ Sprint Goal, Retrospective im lặng, PO vắng mặt), đừng phản ứng ngay. Hỏi: "Đây là triệu chứng của vấn đề gì sâu hơn?". Một team trễ Sprint Goal có thể vì ước lượng kém, vì bị ngắt việc liên tục, vì PO đổi yêu cầu giữa Sprint, hay vì phụ thuộc team khác. Mỗi nguyên nhân cần một can thiệp khác nhau.
- Chọn vị thế (stance) phù hợp. Tự hỏi: tình huống này cần tôi dạy (teach), huấn luyện bằng câu hỏi (coach), tạo điều kiện (facilitate), hay cố vấn (mentor)? Mặc định của Scrum Master PSM II là đặt câu hỏi để người khác tự nghĩ, chứ không phải đưa câu trả lời. (Việc chuyển đổi giữa các stance này sẽ được đào sâu ở các bài coaching phía sau.)
- Ưu tiên phát triển năng lực hơn giải quyết nhanh. Trước khi tự làm hộ, hỏi: "Nếu tôi làm thay, team học được gì? Nếu tôi hướng dẫn team tự làm, dù chậm hơn, họ học được gì?". Trừ khi đang khủng hoảng, hãy chọn vế thứ hai.
- Luôn mở rộng tầm nhìn ra ngoài team. Khi gặp impediment, hỏi thêm: "Vấn đề này là của team, hay là triệu chứng của một thứ ở tầng tổ chức?". Nếu là tầng tổ chức, hành động của bạn cần hướng tới việc làm cho vấn đề đó hiện rõ (visible) với những người có quyền thay đổi nó.
- Trong phòng thi PSM II, loại nhanh các đáp án "ra lệnh" và "máy móc". Bất kỳ đáp án nào có dạng "Scrum Master bảo team phải...", "Scrum Master tự quyết định...", "vì Scrum Guide nói..." thường là bẫy. Đáp án đúng thường giúp team tự thấy, tự chọn.
Lỗi thường gặp & mẹo
Lỗi 1: Biến "It depends" thành cái cớ để né tránh. Đúng là câu trả lời PSM II thường là "còn tùy", nhưng điều đó không có nghĩa là bạn không cần biết gì cụ thể. "Còn tùy" phải đi kèm với khả năng phân tích các yếu tố mà nó phụ thuộc vào. Một Scrum Master giỏi nói: "Còn tùy — nếu team đang thiếu kỹ năng kỹ thuật thì tôi sẽ..., còn nếu vấn đề là PO vắng mặt thì tôi sẽ...". Mẹo: luôn nêu được ít nhất hai kịch bản và cách xử lý tương ứng.
Lỗi 2: Vứt bỏ kiến thức PSM I. Mindset shift không có nghĩa là quên luật. Ngược lại — bạn phải nắm luật chắc hơn để biết khi nào và tại sao một sự kiện đang phục vụ hay phản bội mục đích của nó. Hãy xem PSM I là nền móng, PSM II là tòa nhà xây trên đó.
Lỗi 3: Trở thành "Scrum cảnh sát" (Scrum police). Người mới chuyển tư duy đôi khi đi quá đà theo hướng ngược lại: săm soi mọi vi phạm nhỏ, ép team theo sách vở. Điều này phá hủy lòng tin. Mẹo: thay vì nói "team làm sai rồi", hãy hỏi "điều này có đang giúp chúng ta đạt mục tiêu không?" và để team tự nhận ra.
Lỗi 4: Nhầm bận rộn với hiệu quả. Văn hóa Việt dễ tôn vinh người "làm nhiều việc". Nhưng một Scrum Master ngồi yên đặt một câu hỏi đúng lúc có thể tạo giá trị hơn một người chạy đôn đáo cả ngày. Mẹo tự kiểm: cuối tuần, hỏi "tuần này team đã trưởng thành lên ở điểm nào nhờ tôi?", chứ không phải "tôi đã làm bao nhiêu việc?".
Mẹo vàng: Tập thói quen thay câu khẳng định bằng câu hỏi. Thay vì "Chúng ta nên làm X", hãy thử "Mọi người nghĩ chúng ta nên làm gì, và vì sao?". Đây là bài tập đơn giản nhất nhưng thay đổi vị thế của bạn nhiều nhất.
Bài tập thực hành
- Tự kiểm tư duy. Viết ra ba việc bạn đã làm hộ team trong tuần qua. Với mỗi việc, trả lời: nếu thay vì làm hộ, bạn hướng dẫn team tự làm, bạn sẽ đặt câu hỏi gì? Lần tới gặp tình huống tương tự, hãy thử cách thứ hai.
- Phân tích một sự kiện. Chọn một sự kiện Scrum gần nhất của team bạn (Daily, Retro, Review...). Tự đánh giá theo hai cột: cột "Compliance" (nó có diễn ra đúng luật không) và cột "Effectiveness" (nó có thực sự phục vụ mục đích của nó không). Nếu hai cột chênh nhau, đó chính là cơ hội cải tiến đầu tiên của bạn.
- Luyện đáp án "It depends". Lấy câu hỏi: "Team không hoàn thành Sprint Goal, Scrum Master nên làm gì?". Hãy viết ra ít nhất ba nguyên nhân gốc khác nhau, và với mỗi nguyên nhân, một cách phản ứng phù hợp. Mục tiêu là rèn phản xạ chẩn đoán trước, hành động sau.
- Bài tập tầm nhìn hệ thống. Liệt kê ba impediment lớn nhất của team bạn hiện tại. Đánh dấu cái nào nằm trong team và cái nào nằm ngoài team (tầng tổ chức). Với những cái ở tầng tổ chức, suy nghĩ: làm sao để biến chúng thành hiện rõ với người có quyền thay đổi?
Tóm tắt
Sự chuyển dịch từ PSM I sang PSM II không phải là học thêm kiến thức — mà là thay đổi cách bạn nhìn vai trò của chính mình. PSM I trả lời câu hỏi "Scrum là gì?"; PSM II trả lời câu hỏi "Trong bối cảnh này, điều gì sẽ giúp team và tổ chức tiến lên?". Ba sự dịch chuyển cốt lõi là: từ tuân thủ sang hiệu quả, từ giải quyết hộ sang phát triển năng lực, và từ tập trung vào team sang tư duy hệ thống. Câu trả lời điển hình của một Scrum Master trưởng thành luôn bắt đầu bằng "còn tùy" — không phải để né tránh, mà vì họ hiểu bối cảnh quyết định hành động, và họ luôn chẩn đoán trước khi kê đơn.
Hãy mang theo một câu hỏi duy nhất qua toàn bộ phần còn lại của khóa học này: "Hành động này có đang giúp team tự đứng vững hơn không?". Nếu giữ được câu hỏi đó trong đầu, mọi kỹ thuật facilitation, coaching và tư duy hệ thống bạn học ở các bài sau sẽ tự động rơi vào đúng chỗ của nó. Đó là khác biệt thật sự giữa một người biết Scrum và một người làm cho Scrum sống được trong tổ chức.