Mở đầu — vì sao bài này quan trọng
Nếu bạn đã làm thử vài đề thi PSM I, bạn sẽ nhận ra một điều thú vị: đề thi không chỉ kiểm tra xem bạn có thuộc Scrum Guide hay không, mà còn kiểm tra xem bạn có nhận diện được những kiểu làm Scrum sai đang phổ biến ngoài đời thực hay không. Đây chính là vùng đất của anti-patterns — những "khuôn mẫu phản tác dụng".
Một anti-pattern là một cách làm trông có vẻ hợp lý, được nhiều đội nhóm áp dụng, nhưng thực chất lại đi ngược tinh thần và quy tắc của Scrum. Vấn đề là: chính vì chúng phổ biến nên rất nhiều thí sinh, do quen với "Scrum ở công ty mình", lại chọn đáp án mô tả anti-pattern và tưởng đó là đúng. Đề thi PSM I được thiết kế cực kỳ tinh vi để bẫy đúng điểm này. Họ mô tả một tình huống rất đời thường — nghe quen tai như văn phòng của bạn — rồi hỏi "Scrum Master nên làm gì?". Nếu bạn trả lời theo thói quen, bạn sai. Nếu bạn trả lời "theo sách" (by the book), bạn đúng.
Bài học này sẽ giúp bạn xây dựng một "radar" để phát hiện anti-patterns. Khi bạn đọc một câu hỏi và thấy mô tả khớp với một anti-pattern quen thuộc, bạn lập tức biết: đáp án đúng là đáp án chỉ ra cái sai và đưa team về đúng Scrum, chứ không phải đáp án "thuận theo" thực tế lệch chuẩn. Nắm vững nhóm anti-patterns này có thể giúp bạn ăn chắc 10–15 câu trong bài thi 80 câu — đủ để vượt qua ngưỡng 85%.
Khái niệm cốt lõi
"Scrum But" — biến thể Scrum tự chế
Đây là anti-pattern nổi tiếng nhất, được Jeff Sutherland đặt tên. Công thức của nó luôn có dạng: "Chúng tôi làm Scrum, NHƯNG..."
- "Chúng tôi làm Scrum, nhưng bỏ Retrospective vì không có thời gian."
- "Chúng tôi làm Scrum, nhưng không có Definition of Done."
- "Chúng tôi làm Scrum, nhưng Sprint dài 6 tuần và có thể kéo dài thêm nếu chưa xong."
- "Chúng tôi làm Scrum, nhưng Product Owner do một ủy ban quyết định."
Nói cách khác: bỏ một mảnh, bạn không còn làm Scrum nữa. Bạn đang làm một thứ gì đó khác. Trong đề thi, mọi đáp án ngụ ý "bỏ event này cũng được", "DoD là tùy chọn", "Sprint có thể gia hạn" đều SAI.
"Mini-Waterfall" — thác nước thu nhỏ trong Sprint
Anti-pattern thứ hai cực kỳ phổ biến ở Việt Nam, đặc biệt tại các công ty outsourcing chuyển từ mô hình truyền thống. Team chia mỗi Sprint thành các giai đoạn tuần tự: tuần 1 phân tích, tuần 2 thiết kế, tuần 3 code, tuần 4 test. Kết quả là Increment chỉ "hoàn thành" vào ngày cuối Sprint, hoặc tệ hơn, việc test bị đẩy sang Sprint sau.
Đây là mini-waterfall — một dòng thác nước thu nhỏ nhét vào trong Sprint. Nó vi phạm tinh thần Scrum vì:
- Increment phải có khả năng "Done" và sử dụng được, không phải nửa vời.
- Developers là cross-functional (đa năng), làm việc cùng nhau để tạo giá trị, chứ không phải chuyền tay theo dây chuyền.
- Tạo Increment xuyên suốt Sprint mới đảm bảo tính minh bạch và khả năng inspect.
Một số anti-pattern "kinh điển" khác PSM I hay hỏi
- Scrum Master như người quản lý dự án (PM): giao việc cho Developers, quyết định ai làm gì, theo dõi tiến độ để ép deadline. Sai. Scrum Master là servant-leader, không quản vi mô; Developers tự tổ chức (self-managing).
- Daily Scrum biến thành buổi báo cáo cho Scrum Master/sếp: từng người lần lượt báo cáo "hôm qua tôi làm gì" cho Scrum Master ghi nhận. Sai. Daily Scrum là của Developers, để họ tự inspect tiến độ hướng tới Sprint Goal.
- Product Owner ủy ban: nhiều người cùng làm PO, hoặc PO là "người chuyển tiếp" không có quyền quyết định. Sai. PO là một người duy nhất, chịu trách nhiệm cuối cùng (accountable) về Product Backlog.
- Sprint Goal bị bỏ qua hoặc là "làm xong hết các item": Sprint không có mục tiêu mạch lạc, chỉ là danh sách việc rời rạc. Sai.
- Bỏ Sprint Review/Retrospective khi gấp: như đã nói, vi phạm all-or-nothing.
- Sprint zero / Hardening Sprint / Release Sprint: thêm các "Sprint đặc biệt" không tạo ra Increment có giá trị. Scrum chỉ có một loại Sprint.
- "Velocity là KPI": dùng velocity để so sánh các team hay làm thước đo năng suất nhân viên. Velocity chỉ là công cụ forecasting nội bộ của team.
- Re-estimate liên tục giữa Sprint, thay đổi Sprint Backlog tùy hứng từ bên ngoài: chỉ Developers mới được điều chỉnh Sprint Backlog; phạm vi (scope) có thể được làm rõ và thương lượng lại với PO khi hiểu thêm, nhưng Sprint Goal phải giữ nguyên.
Tình huống thực tế
Tình huống 1 — Công ty FPT Software và cái "Scrum But" bỏ Retrospective
Một team 7 người tại một trung tâm phát triển phần mềm thuộc FPT Software ở Hà Nội đang chạy Sprint 2 tuần cho một khách hàng Nhật Bản. Vì áp lực deadline, project manager thông báo: "Từ Sprint này, mình bỏ Retrospective nhé, mất 1 tiếng rưỡi mỗi Sprint mà mình thì đang trễ. Mọi người cứ tập trung code thôi." Trong 4 Sprint tiếp theo, team vẫn họp Daily, vẫn có Sprint Review demo cho khách. Mọi người tự tin nói "team mình vẫn đang làm Scrum đúng chuẩn".
Diễn giải: Đây là "Scrum But" điển hình — "làm Scrum nhưng bỏ Retro". Hệ quả thực tế: sau 4 Sprint, cùng những lỗi giao tiếp với khách Nhật, cùng vấn đề ước lượng sai, cùng kiểu môi trường test hỏng cứ lặp đi lặp lại mà không ai dừng lại để cải tiến. Velocity tụt dần. Khi vấn đề tích tụ đủ lớn, khách hàng nổi giận. Trong góc nhìn PSM I: ngay từ khoảnh khắc bỏ Retrospective, team này không còn làm Scrum. Sprint Retrospective là cơ hội chính thức để inspect và adapt quy trình — bỏ nó đi nghĩa là tháo mất bánh răng "cải tiến liên tục".
Bài học: Trong đề thi, nếu gặp câu "Team gặp khó về thời gian, có nên rút ngắn hay bỏ một event không?", đáp án đúng luôn là giữ event nhưng tổ chức hiệu quả hơn, không bao giờ là bỏ. Event có thể kết thúc sớm khi đạt mục đích, nhưng không được loại bỏ.
Tình huống 2 — Startup Fintech "MoMoPay giả định" và mini-waterfall
Một startup fintech tại TP.HCM (gọi là "PayQuick" cho ẩn danh) có một Squad gồm 1 PO, 1 Scrum Master và 6 Developers, chạy Sprint 3 tuần. Cách họ làm: tuần đầu, hai bạn Business Analyst viết spec chi tiết; tuần hai, ba bạn backend/frontend mới bắt đầu code; tuần ba, hai bạn QA test. Vấn đề: tester thường chỉ nhận được build vào ngày thứ 18/21, nên 80% Sprint nào cũng "lòi" ra bug vào ngày cuối và phải đẩy phần test sang Sprint sau. Increment cuối Sprint không bao giờ thực sự "Done".
Diễn giải: Đây là mini-waterfall trá hình dưới vỏ bọc Scrum. Họ có đủ events, có đủ vai trò, nhưng cách tổ chức công việc bên trong vẫn là dây chuyền tuần tự. Hậu quả: Increment không đáp ứng Definition of Done, không thể release, tính minh bạch bị phá vỡ vì Sprint Review demo một sản phẩm chưa thật sự hoàn chỉnh. Carry-over (việc tồn đọng chuyển Sprint) trở thành chuyện thường ngày, khiến forecasting vô nghĩa.
Bài học: Scrum kỳ vọng Developers cross-functional và làm việc song song để tạo Increment "Done" liên tục, ít nhất một Increment mỗi Sprint. Trong đề thi, các đáp án mô tả "phân tích xong rồi mới code, code xong rồi mới test theo từng tuần" thường là bẫy anti-pattern. Đáp án đúng hướng tới việc team cùng nhau hoàn thành các hạng mục nhỏ, "Done" sớm và thường xuyên.
Tình huống 3 — Ngân hàng số và Daily Scrum thành buổi điểm danh
Tại một dự án chuyển đổi số của một ngân hàng lớn ở Đông Nam Á, một anh trưởng nhóm vừa được phong làm "Scrum Master" nhưng giữ nguyên tư duy quản lý cũ. Mỗi sáng 9h, Daily Scrum diễn ra như sau: anh đứng trước bảng, gọi tên từng Developer, mỗi người báo cáo "hôm qua em làm X, hôm nay em làm Y", anh ghi chép vào file Excel theo dõi tiến độ và thỉnh thoảng chen vào "việc này phải xong trước thứ Sáu nhé". Cuộc họp kéo dài 25–30 phút, ai báo cáo xong thì ngồi nghịch điện thoại chờ tới lượt.
Diễn giải: Có ít nhất ba anti-pattern chồng lên nhau ở đây. Thứ nhất, Daily Scrum bị biến thành status report cho Scrum Master thay vì là buổi inspect-and-adapt của chính Developers. Thứ hai, Scrum Master đang hành xử như PM/quản lý vi mô: giao deadline, theo dõi tiến độ cá nhân. Thứ ba, vì mọi người chỉ "báo cáo lên trên" nên không ai thực sự phối hợp để hướng tới Sprint Goal — tinh thần self-managing bị triệt tiêu.
Bài học: Daily Scrum thuộc về Developers. Scrum Master chỉ đảm bảo nó diễn ra, đúng timebox 15 phút, và để Developers tự điều phối. Nếu đề thi mô tả "Scrum Master gọi tên từng người yêu cầu báo cáo", hãy nhận diện ngay đây là anti-pattern. Đáp án đúng là Scrum Master dạy lại team rằng Daily Scrum là của họ, để họ tự lập kế hoạch cho ngày làm việc hướng tới Sprint Goal.
Hướng dẫn từng bước
Khi gặp một câu hỏi tình huống (scenario) trong PSM I, hãy áp dụng quy trình 5 bước để phát hiện anti-pattern:
- Đọc kỹ phần mô tả tình huống trước khi đọc câu hỏi. Tự hỏi: "Tình huống này có gì lệch chuẩn so với Scrum Guide không?" Gạch chân các chi tiết như "bỏ event", "một người làm hộ nhiều vai trò", "ai đó ra lệnh cho Developers".
- Nhận diện anti-pattern cụ thể. Đối chiếu với danh sách quen thuộc: Scrum But? Mini-waterfall? SM làm PM? Daily thành báo cáo? PO ủy ban? Sprint đặc biệt? Velocity làm KPI? Việc gọi đúng tên anti-pattern giúp bạn biết "cái sai" nằm ở đâu.
- Loại các đáp án thuận theo anti-pattern. Bất kỳ đáp án nào "hợp thức hóa" cái sai (ví dụ: "Đồng ý bỏ Retro vì team bận") đều bị loại ngay, kể cả khi nó nghe rất thực tế và dễ chịu.
- Ưu tiên đáp án giúp tăng transparency và đưa team về đúng Scrum. Thường là các động từ: teach (dạy), coach (khai vấn), facilitate (điều phối), make transparent (làm minh bạch vấn đề). Tránh các động từ mang tính ra lệnh: assign, force, decide for the team.
- Kiểm tra lại bằng nguyên tắc all-or-nothing và accountabilities. Đáp án đúng không bao giờ vi phạm vai trò (ai chịu trách nhiệm gì) và không bao giờ loại bỏ thành phần cốt lõi của Scrum.
Lỗi thường gặp & mẹo
- Lỗi: Trả lời theo "Scrum ở công ty mình". Đây là cái bẫy lớn nhất. Công ty bạn có thể đang làm Scrum-But mà bạn không biết. Hãy luôn trả lời theo Scrum Guide chuẩn, không theo trải nghiệm cá nhân.
- Lỗi: Nhầm "linh hoạt" với "đúng". Scrum đề cao thích nghi, nên nhiều người tưởng "bỏ bớt event cho linh hoạt" là tinh thần Scrum. Sai. Linh hoạt nằm ở cách làm việc bên trong các quy tắc, không phải ở việc xóa bỏ quy tắc.
- Lỗi: Cho rằng Scrum Master phải "ra tay xử lý" mọi anti-pattern bằng quyền lực. Scrum Master không có quyền ra lệnh. Mẹo: khi phân vân giữa "Scrum Master tự quyết" và "Scrum Master coach/teach để team tự quyết", thường vế sau là đúng.
- Mẹo nhận diện nhanh từ khóa bẫy: các cụm như "but", "skip", "extend the Sprint", "PO committee", "hardening sprint", "report to the Scrum Master", "assign tasks to developers", "rollover/carry-over là bình thường" gần như luôn báo hiệu anti-pattern.
- Mẹo về "Done": bất cứ khi nào tình huống nói Increment "gần như xong", "còn thiếu test", "sẽ hoàn thiện Sprint sau" — đó là cờ đỏ vi phạm Definition of Done, một dạng anti-pattern về chất lượng.
- Lỗi: Quên rằng một số "thực hành" là tùy chọn, không phải anti-pattern. Cẩn thận phân biệt: User Stories, story points, Definition of Ready là tùy chọn (không bắt buộc nhưng không sai). Trong khi bỏ Retrospective hay bỏ DoD mới là vi phạm Scrum. Đừng đánh đồng "không bắt buộc" với "anti-pattern".
Bài tập thực hành
- Gắn nhãn anti-pattern. Với mỗi phát biểu sau, hãy gọi tên anti-pattern và giải thích nó vi phạm điều gì trong Scrum Guide:
- Viết lại đáp án đúng. Lấy Tình huống 3 (Daily Scrum thành điểm danh) ở trên. Hãy viết ra 3 hành động cụ thể mà một Scrum Master "theo sách" nên làm để đưa Daily Scrum về đúng bản chất, không dùng quyền ra lệnh.
- Tự tạo bẫy. Hãy tự viết một câu hỏi trắc nghiệm 4 đáp án, trong đó có 1 đáp án đúng theo Scrum Guide và 3 đáp án là anti-pattern nghe rất hợp lý. Đưa cho bạn học cùng làm thử — nếu họ chọn nhầm anti-pattern, bạn đã hiểu đúng cơ chế bẫy của đề thi.
- Soi chính team của bạn. Liệt kê 3 cách làm tại nơi bạn đang làm việc mà bạn nghi là "Scrum But" hoặc mini-waterfall. Với mỗi cái, viết một câu giải thích nó che giấu vấn đề gì.
Tóm tắt
- Anti-patterns là vùng đề thi PSM I "bẫy" nhiều thí sinh nhất, vì chúng quá phổ biến ngoài đời nên dễ bị nhầm là đúng.
- "Scrum But" ("làm Scrum nhưng bỏ X") luôn sai, vì Scrum Guide là all-or-nothing: bỏ một thành phần cốt lõi nghĩa là không còn làm Scrum.
- Mini-waterfall (chia Sprint thành các giai đoạn tuần tự phân tích–thiết kế–code–test) phá vỡ tinh thần cross-functional và làm Increment không "Done".
- Các anti-pattern kinh điển khác: Scrum Master làm PM/quản lý vi mô, Daily Scrum thành buổi báo cáo, PO ủy ban, Sprint đặc biệt (Sprint zero/Hardening), velocity làm KPI, Sprint có thể gia hạn.
- Quy tắc chọn đáp án: ưu tiên đáp án tăng minh bạch, tôn trọng accountabilities, và đưa team về đúng Scrum Guide; loại mọi đáp án "thuận theo cái sai cho dễ".
- Phân biệt rạch ròi: bỏ DoD/Retro là vi phạm, còn User Stories/story points/DoR chỉ là tùy chọn — đừng đánh đồng hai loại.
- Luôn trả lời "theo sách", không trả lời theo "Scrum ở công ty mình".