Mở đầu — vì sao bài này quan trọng
Nếu bạn đang chuẩn bị thi chứng chỉ PSM I (Professional Scrum Master I), thì đây chính là viên gạch nền tảng mà mọi câu hỏi khác trong đề thi đều dựa vào. Rất nhiều học viên Việt Nam mắc một sai lầm tai hại: họ học thuộc lòng các sự kiện (events), các vai trò (accountabilities), các tạo tác (artifacts) một cách rời rạc, rồi đi thi với hy vọng "nhớ đủ là đỗ". Kết quả là họ trượt — không phải vì thiếu chi tiết, mà vì thiếu một bộ khung tư duy thống nhất để liên kết tất cả lại với nhau.
Scrum không phải là một danh sách các quy tắc cần tuân thủ. Scrum là một framework (khung làm việc) được xây dựng trên một nền tảng triết lý cụ thể. Khi bạn hiểu nền tảng đó, mọi quy tắc trong Scrum Guide trở nên hiển nhiên, logic và dễ nhớ. Bạn sẽ không cần "học vẹt" nữa — bạn sẽ tự suy luận ra câu trả lời đúng ngay cả với những câu hỏi tình huống mà bạn chưa từng gặp.
Bài học này tập trung vào bức tranh tổng thể: Scrum là gì, nó được xây dựng trên nền tảng nào, và tại sao cấu trúc của nó lại được thiết kế như vậy. Chúng ta sẽ đi sâu vào lý thuyết Scrum (Scrum Theory) — đặc biệt là hai nền tảng cốt lõi là empiricism (chủ nghĩa thực nghiệm) và lean thinking (tư duy tinh gọn) — cùng ba trụ cột giữ cho cả hệ thống đứng vững. Đây là "hệ điều hành" mà tất cả 59 bài học còn lại sẽ chạy trên đó.
Hãy hình dung như thế này: nếu các sự kiện, vai trò, tạo tác là những bộ phận của một chiếc xe, thì lý thuyết Scrum chính là nguyên lý động cơ đốt trong. Bạn có thể thay bánh xe, đổi màu sơn, nhưng nếu không hiểu động cơ vận hành ra sao, bạn sẽ không bao giờ sửa được xe khi nó hỏng. Trong kỳ thi PSM I, "xe hỏng" chính là những câu hỏi tình huống đánh lừa — và chỉ có hiểu nguyên lý mới giúp bạn chọn đúng.
Khái niệm cốt lõi
Scrum là gì — và không phải là gì
Theo Scrum Guide 2020, Scrum được định nghĩa là một framework gọn nhẹ (lightweight framework) giúp con người, đội nhóm và tổ chức tạo ra giá trị thông qua các giải pháp thích ứng (adaptive solutions) cho những vấn đề phức tạp.
Hãy chú ý ba từ khóa trong định nghĩa này, vì chúng xuất hiện liên tục trong đề thi:
- Lightweight (gọn nhẹ): Scrum cố tình giữ tối thiểu. Toàn bộ Scrum Guide chỉ khoảng 13 trang. Nó chỉ định nghĩa những gì bắt buộc, còn lại để bạn tự bổ sung kỹ thuật (techniques) phù hợp. Đây là lý do user story, planning poker, burndown chart... đều không phải là một phần của Scrum — chúng chỉ là các kỹ thuật tùy chọn được dùng cùng với Scrum.
- Framework (khung), không phải methodology (phương pháp luận): Một methodology cho bạn quy trình chi tiết từng bước. Một framework chỉ cho bạn bộ khung, và bạn lấp đầy phần còn lại. Scrum cố ý "không đầy đủ" (intentionally incomplete) — điều này là cố ý, không phải thiếu sót.
- Complex problems (vấn đề phức tạp): Scrum được thiết kế cho những vấn đề mà bạn không thể dự đoán hết từ đầu. Nếu công việc của bạn đơn giản, lặp lại và dự đoán được, bạn không cần Scrum.
Nền tảng 1 — Empiricism (Chủ nghĩa thực nghiệm)
Scrum được xây dựng trên empiricism. Đây là niềm tin rằng tri thức đến từ kinh nghiệm thực tế và việc ra quyết định dựa trên những gì đã quan sát được, chứ không phải dựa trên kế hoạch lý thuyết vạch sẵn.
Để dễ hiểu, hãy so sánh hai cách làm việc:
- Predictive (dự đoán / kế hoạch trước): Bạn lập kế hoạch toàn bộ dự án từ đầu, rồi thực thi đúng theo kế hoạch đó. Cách này hiệu quả khi mọi thứ ổn định và dự đoán được — ví dụ xây một bức tường gạch.
- Empirical (thực nghiệm): Bạn làm một phần nhỏ, quan sát kết quả, học hỏi, rồi điều chỉnh hướng đi cho phần tiếp theo. Cách này hiệu quả khi có nhiều bất định.
Nền tảng 2 — Lean Thinking (Tư duy tinh gọn)
Scrum Guide 2020 bổ sung lean thinking làm nền tảng thứ hai (cùng với empiricism). Tư duy tinh gọn tập trung vào hai nguyên tắc cốt lõi: giảm lãng phí (reducing waste) và tập trung vào điều thiết yếu (focusing on the essentials).
Đây chính là lý do giải thích "tính gọn nhẹ" của Scrum. Vì sao Scrum Guide chỉ có 13 trang? Vì sao chỉ có 5 sự kiện, 3 vai trò, 3 tạo tác? Vì sao Sprint Backlog chỉ chứa đúng những gì cần cho Sprint Goal? Tất cả đều phản ánh lean thinking: bỏ đi mọi thứ thừa thãi, chỉ giữ lại những gì tạo ra giá trị.
Một mẹo ghi nhớ cho kỳ thi: bất cứ khi nào một câu hỏi gợi ý thêm vào quy trình những bước "cho chắc ăn" (tài liệu thừa, họp thừa, phê duyệt thừa), hãy nghi ngờ — vì điều đó thường đi ngược lean thinking.
Ba trụ cột của Empiricism (3 Pillars)
Empiricism không tự nhiên hoạt động. Nó đứng vững nhờ ba trụ cột, và đây là nội dung cốt lõi nhất của bài học này:
1. Transparency (Minh bạch): Quy trình và công việc phải hiển thị rõ ràng với cả người thực hiện lẫn người tiếp nhận. Các quyết định quan trọng được đưa ra dựa trên trạng thái của ba tạo tác chính thức. Những tạo tác có độ minh bạch thấp sẽ dẫn đến quyết định sai lệch, làm giảm giá trị và tăng rủi ro. Minh bạch là điều kiện tiên quyết — không có nó, hai trụ cột còn lại trở nên vô nghĩa. Bạn không thể kiểm tra hay điều chỉnh dựa trên thông tin bị che giấu hoặc bóp méo.
Một ví dụ: nếu một Developer báo cáo "task gần xong" trong khi thực tế còn nửa công việc, thì sự minh bạch đã bị phá vỡ. Mọi quyết định dựa trên báo cáo đó đều rủi ro.
2. Inspection (Kiểm tra): Các tạo tác của Scrum và tiến độ hướng tới mục tiêu phải được kiểm tra thường xuyên và cẩn trọng để phát hiện những sai lệch hoặc vấn đề không mong muốn. Kiểm tra không phải để bắt lỗi hay đổ trách nhiệm, mà để học hỏi. Scrum cung cấp nhịp điệu (cadence) cho việc kiểm tra thông qua các sự kiện của nó. Lưu ý: kiểm tra mà không có minh bạch là vô ích — bạn không thể kiểm tra thứ mình không nhìn thấy đúng bản chất.
3. Adaptation (Thích ứng): Nếu việc kiểm tra cho thấy có sai lệch vượt giới hạn chấp nhận được, hoặc sản phẩm tạo ra sẽ không đạt yêu cầu, thì quy trình hoặc vật liệu đầu vào phải được điều chỉnh ngay. Sự điều chỉnh phải diễn ra càng sớm càng tốt để giảm thiểu sai lệch xa hơn. Thích ứng trở nên khó khăn khi những người liên quan không được trao quyền hoặc không tự quản lý — đó là lý do Scrum đòi hỏi đội nhóm tự quản (self-managing).
Hãy nhớ chuỗi quan hệ nhân quả này, vì nó là chìa khóa để trả lời hàng loạt câu hỏi PSM I:
> Minh bạch cho phép Kiểm tra. Kiểm tra cho phép Thích ứng. Thiếu bất kỳ trụ cột nào, cả hệ thống sụp đổ.
Cách ba trụ cột "sống" trong Scrum
Điều khiến nhiều học viên bất ngờ: ba trụ cột không phải lý thuyết suông, mà được "nhúng" vào từng thành phần của Scrum. Mỗi sự kiện Scrum thực chất là một cơ hội chính thức để kiểm tra và thích ứng. Mỗi tạo tác được thiết kế để tối đa hóa minh bạch. Bạn sẽ thấy điều này rõ hơn ở các bài sau, nhưng ngay bây giờ hãy ghi nhớ: mọi quy tắc trong Scrum đều phục vụ một trong ba trụ cột. Khi gặp câu hỏi khó, hãy tự hỏi "quy tắc này đang bảo vệ trụ cột nào?" — câu trả lời thường lộ ra ngay.
Tình huống thực tế
Ví dụ 1 — Tiki và bài học về tính minh bạch
Hãy tưởng tượng một đội phát triển tính năng thanh toán tại một sàn thương mại điện tử lớn của Việt Nam như Tiki. Đội có 6 Developer, làm Sprint hai tuần. Trong ba Sprint liên tiếp, mọi cuộc họp Sprint Review đều diễn ra "tốt đẹp": Product Owner báo cáo tiến độ với ban lãnh đạo rằng "tính năng đã hoàn thành 90%".
Vấn đề là con số "90%" đó không dựa trên một Definition of Done rõ ràng. Có những phần "xong" nghĩa là code chạy được trên máy lập trình viên, có phần "xong" nghĩa là đã qua kiểm thử. Khi đến hạn ra mắt, đội phát hiện 30% công việc thực tế chưa hoàn thành theo tiêu chuẩn chất lượng, dẫn đến trễ hai tuần và một đợt sự cố thanh toán.
Diễn giải: Đây là một thất bại điển hình của trụ cột Transparency. Tạo tác (Increment) không minh bạch vì không có chuẩn "hoàn thành" chung. Khi minh bạch bị phá vỡ, mọi cuộc Inspection (Sprint Review) đều dựa trên thông tin sai, và mọi Adaptation đều đi sai hướng.
Bài học rút ra: Minh bạch không tự nhiên có. Nó phải được tạo ra một cách chủ động thông qua các tiêu chuẩn chung và sự trung thực. Trong PSM I, khi bạn thấy một đội "tiến độ tốt trên giấy nhưng thất bại trong thực tế", gần như chắc chắn gốc rễ là vấn đề minh bạch.
Ví dụ 2 — Startup giao đồ ăn ở TP.HCM và sức mạnh của vòng lặp thực nghiệm
Một startup giao đồ ăn giả định ở TP.HCM, gọi là FoodFast, muốn xây dựng tính năng "đặt món theo nhóm" (group order). Ban đầu, CEO yêu cầu đội lập kế hoạch chi tiết 6 tháng với đầy đủ tài liệu đặc tả cho mọi màn hình.
Đội Scrum thuyết phục CEO làm theo cách thực nghiệm: thay vì xây toàn bộ, họ phát hành một phiên bản tối giản chỉ cho phép tối đa 3 người trong một nhóm sau Sprint đầu tiên. Họ quan sát dữ liệu thật từ 500 người dùng. Kết quả bất ngờ: phần lớn nhóm đặt món chỉ có 2 người (cặp đôi, đồng nghiệp ăn trưa), và điều người dùng thực sự cần là chia tiền tự động, chứ không phải nhóm đông người.
Nhờ phát hiện này sau một Sprint, đội đã chuyển hướng (adapt) sang tính năng chia tiền, tiết kiệm khoảng 4 tháng công sức lẽ ra sẽ đổ vào các tính năng nhóm lớn mà gần như không ai dùng.
Diễn giải: Đây là empiricism đúng nghĩa: làm nhỏ → quan sát thực tế → học → thích ứng. Đồng thời là lean thinking: bỏ đi 4 tháng công việc lãng phí, chỉ tập trung vào điều thiết yếu.
Bài học rút ra: Sức mạnh của Scrum không nằm ở việc "đoán đúng kế hoạch", mà ở việc rút ngắn khoảng cách giữa giả định và kiểm chứng. Sprint ngắn chính là cơ chế biến điều này thành hiện thực.
Ví dụ 3 — Đội ngân hàng số bỏ Retrospective: chuỗi trụ cột bị đứt
Một đội phát triển ứng dụng ngân hàng số tại một ngân hàng Việt Nam quyết định "tạm bỏ Sprint Retrospective trong vài Sprint để kịp deadline". Trong mắt họ, đây là cuộc họp "ít quan trọng nhất".
Hậu quả xuất hiện sau hai tháng: cùng một loại lỗi tích hợp lặp lại ở mỗi Sprint, các thành viên ngày càng bức xúc với nhau nhưng không có nơi để nói, và quy trình làm việc không hề cải thiện dù khối lượng việc tăng.
Diễn giải: Sprint Retrospective chính là cơ hội Inspection và Adaptation dành cho quy trình làm việc của đội. Bỏ nó đi nghĩa là đội tự cắt đứt trụ cột Inspection ở cấp độ quy trình. Không kiểm tra thì không thể thích ứng, và đội bị mắc kẹt trong cùng những sai lầm.
Bài học rút ra: Vì sao Scrum bất biến (immutable)? Vì mỗi thành phần phục vụ một trụ cột. Khi bạn loại bỏ một sự kiện, bạn không "tiết kiệm thời gian" — bạn đang vô hiệu hóa một phần của cơ chế empiricism. Đây là dạng câu hỏi PSM I rất phổ biến, và câu trả lời đúng luôn là: không được bỏ bất kỳ sự kiện nào.
Hướng dẫn từng bước
Để xây dựng nền tảng tư duy framework vững chắc trước khi đi vào chi tiết, hãy làm theo các bước sau:
- Nắm định nghĩa Scrum thuộc lòng. Học chính xác câu định nghĩa: "framework gọn nhẹ giúp con người, đội nhóm, tổ chức tạo giá trị qua các giải pháp thích ứng cho vấn đề phức tạp". Mỗi từ đều có thể bị hỏi.
- Phân biệt rõ framework với methodology. Tự nhắc: Scrum cố ý không đầy đủ. Nó cho khung, bạn lấp kỹ thuật. Điều này giải thích vì sao rất nhiều thứ quen thuộc (user story, planning poker, story point) không nằm trong Scrum.
- Ghi nhớ hai nền tảng: empiricism + lean thinking. Với mỗi nền tảng, viết ra một câu giải thích bằng lời của chính bạn. Empiricism = ra quyết định dựa trên quan sát thực tế. Lean thinking = giảm lãng phí, tập trung điều thiết yếu.
- Vẽ sơ đồ ba trụ cột theo đúng thứ tự nhân quả. Transparency → Inspection → Adaptation. Vẽ mũi tên chỉ rõ trụ cột trước là điều kiện cho trụ cột sau. Dán nó lên bàn học.
- Tự kiểm tra bằng câu hỏi ngược. Lấy bất kỳ quy tắc Scrum nào bạn biết (ví dụ "Daily Scrum giới hạn 15 phút") và tự hỏi: quy tắc này phục vụ trụ cột nào? Nếu trả lời được, bạn đã hiểu framework.
- Áp dụng "bộ lọc bất biến". Mỗi khi gặp câu hỏi tình huống có yếu tố "bỏ bớt", "thêm vào cho chắc", "làm tắt" — dừng lại và đối chiếu với tính bất biến của Scrum và ba trụ cột.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm Scrum là một quy trình (process) hoàn chỉnh. Nhiều người nghĩ Scrum chỉ ra cho họ làm gì từng bước. Sai. Scrum là framework, chỉ định nghĩa cái tối thiểu bắt buộc. Mẹo: khi đề thi nói "Scrum yêu cầu bạn phải dùng [một kỹ thuật cụ thể]", hãy cảnh giác — Scrum hiếm khi bắt buộc một kỹ thuật nào.
Lỗi 2 — Quên rằng có HAI nền tảng. Trước Scrum Guide 2020 chỉ nói về empiricism. Bản 2020 bổ sung lean thinking. Nhiều tài liệu cũ trên mạng vẫn thiếu. Mẹo: nhớ cặp đôi "empiricism + lean thinking".
Lỗi 3 — Đảo lộn thứ tự hoặc bỏ sót trụ cột. Thứ tự đúng là Transparency → Inspection → Adaptation. Mẹo ghi nhớ: "Nhìn thấy (minh bạch) → Soi xét (kiểm tra) → Sửa đổi (thích ứng)". Ba chữ T-I-A theo đúng dòng chảy logic.
Lỗi 4 — Tưởng Inspection là để bắt lỗi và đổ trách nhiệm. Kiểm tra trong Scrum là để học và cải thiện, không phải để trừng phạt. Mẹo: nếu đáp án mang màu sắc "kiểm soát, quản lý vi mô, đánh giá cá nhân", thường là sai.
Lỗi 5 — Cho rằng có thể bỏ một phần Scrum mà vẫn là Scrum. Mẹo: khắc cốt câu "Scrum is immutable" — triển khai một phần thì kết quả không còn là Scrum.
Mẹo tổng quát cho PSM I: Khi phân vân giữa hai đáp án, hãy chọn đáp án nào bảo vệ tốt nhất sự minh bạch, hỗ trợ kiểm tra và cho phép đội tự thích ứng. Đáp án "by the book" gần như luôn nghiêng về trao quyền cho đội, giữ minh bạch và tôn trọng cấu trúc bất biến của Scrum.
Bài tập thực hành
- Định nghĩa bằng lời của bạn. Không nhìn tài liệu, viết ra định nghĩa Scrum, hai nền tảng và ba trụ cột. Sau đó đối chiếu với bài học. Lặp lại đến khi viết đúng 100%.
- Phân loại nhân-quả. Cho ba tình huống sau, xác định trụ cột nào bị vi phạm:
- Tìm trụ cột phía sau quy tắc. Với mỗi quy tắc, ghi ra trụ cột nó phục vụ: Sprint tối đa một tháng; Definition of Done chung cho cả đội; Daily Scrum hằng ngày; Increment phải dùng được. Giải thích ngắn gọn vì sao.
- Empirical hay Predictive? Liệt kê 3 đầu việc trong công việc thực tế của bạn. Với mỗi việc, quyết định nên dùng cách tiếp cận thực nghiệm hay dự đoán, và giải thích lý do dựa trên mức độ phức tạp/bất định.
- Phản biện một "lối tắt". Viết một đoạn 5–7 câu phản biện lập luận: "Đội mình deadline gấp, nên bỏ Retrospective vài Sprint cũng không sao." Dùng khái niệm ba trụ cột và tính bất biến để bảo vệ quan điểm.
Tóm tắt
- Scrum là một framework gọn nhẹ, cố ý không đầy đủ, dành cho việc giải quyết các vấn đề phức tạp. Nó cho bạn bộ khung; bạn tự lấp đầy bằng các kỹ thuật phù hợp.
- Scrum là bất biến (immutable): triển khai một phần thì kết quả không còn là Scrum. Mỗi thành phần đều phục vụ một mục đích trong tổng thể.
- Scrum đứng trên hai nền tảng: empiricism (ra quyết định dựa trên quan sát thực tế) và lean thinking (giảm lãng phí, tập trung điều thiết yếu).
- Empiricism được giữ vững bởi ba trụ cột theo chuỗi nhân quả: Transparency → Inspection → Adaptation. Minh bạch cho phép kiểm tra; kiểm tra cho phép thích ứng. Thiếu một trụ cột, cả hệ thống sụp đổ.
- Mọi sự kiện, vai trò và tạo tác trong Scrum đều tồn tại để phục vụ một trong ba trụ cột. Khi gặp câu hỏi khó trong PSM I, hãy hỏi "quy tắc này bảo vệ trụ cột nào?" — đó là la bàn dẫn bạn tới đáp án đúng.