Mở đầu — vì sao bài này quan trọng
Nếu bạn chỉ được phép nhớ MỘT khái niệm duy nhất để vượt qua kỳ thi PSM I, thì đó chính là Empiricism (chủ nghĩa thực nghiệm). Đây không phải là một thuật ngữ trang trí trong Scrum Guide — nó là nền móng mà toàn bộ ngôi nhà Scrum được dựng lên. Mọi sự kiện (event), mọi tạo tác (artifact), mọi accountability mà bạn sẽ học ở các bài sau đều tồn tại để phục vụ một mục đích duy nhất: làm cho empiricism vận hành được trong thực tế.
Trong kỳ thi PSM I, rất nhiều câu hỏi nhìn bề ngoài là về Sprint Planning, về Daily Scrum, hay về vai trò của Scrum Master, nhưng câu trả lời đúng thực ra lại nằm ở chỗ bạn có hiểu empiricism hay không. Khi bạn phân vân giữa hai đáp án, hãy tự hỏi: "Đáp án nào giúp đội nhóm quan sát thực tế, kiểm tra thường xuyên, và điều chỉnh dựa trên bằng chứng?" — đó thường là đáp án by-the-book.
Empiricism trả lời cho câu hỏi cốt lõi: trong một môi trường phức tạp, nơi không ai có thể dự đoán chính xác tương lai, làm sao chúng ta vẫn ra quyết định tốt và tạo ra giá trị? Câu trả lời của Scrum rất khiêm tốn nhưng mạnh mẽ: chúng ta không dự đoán, chúng ta thực nghiệm. Bài học này sẽ giúp bạn nắm thật chắc ba trụ cột Transparency, Inspection, Adaptation — và quan trọng hơn, hiểu được tinh thần đằng sau chúng.
Khái niệm cốt lõi
Empiricism là gì?
Scrum Guide 2020 nói rất rõ: "Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed." Tạm dịch: Scrum được xây dựng trên empiricism và lean thinking. Empiricism khẳng định rằng tri thức đến từ kinh nghiệm, và quyết định được đưa ra dựa trên những gì đã quan sát được.
Hãy để ý ba từ khóa: knowledge — experience — observed. Empiricism là một cách kiểm soát quy trình (process control) dựa trên thực tế đã xảy ra, chứ không dựa trên kế hoạch đã được vẽ ra từ trước. Đây gọi là empirical process control theory — lý thuyết kiểm soát quy trình thực nghiệm.
Để dễ hình dung, hãy tưởng tượng bạn đi trong sương mù dày đặc. Bạn không thể nhìn thấy đích đến cách 5 km. Bạn chỉ thấy được vài mét trước mặt. Cách đi an toàn không phải là vạch sẵn một lộ trình chi tiết cho cả 5 km (vì sương mù sẽ làm kế hoạch đó sai bét), mà là: bước vài bước, dừng lại quan sát, điều chỉnh hướng, rồi lại bước tiếp. Đó chính là empiricism. Mỗi vòng lặp ngắn (mỗi Sprint) là một lần bạn bước ra khỏi sương mù một chút và nhìn rõ hơn.
Tại sao Scrum chọn empiricism?
Scrum được thiết kế cho công việc phức tạp (complex) — nơi có nhiều ẩn số hơn là điều đã biết. Trong những công việc lặp đi lặp lại, có thể đoán trước (như dây chuyền lắp ráp), người ta dùng defined process control (kiểm soát quy trình định nghĩa sẵn): biết đầu vào, biết đầu ra, làm theo công thức. Nhưng phát triển sản phẩm mới — đặc biệt là phần mềm — gần như không bao giờ giống hệt lần trước. Yêu cầu thay đổi, công nghệ thay đổi, thị trường thay đổi, con người thay đổi.
Khi bạn cố áp một kế hoạch cứng nhắc lên một bài toán phức tạp, bạn sẽ thất bại — đây là lý do mô hình Waterfall (thác nước) thường vỡ trận với phần mềm. Empiricism chấp nhận sự thật rằng ta không thể biết hết mọi thứ ngay từ đầu, và biến sự không chắc chắn đó thành lợi thế bằng cách học liên tục qua từng vòng lặp ngắn.
Ba trụ cột của Empiricism
Scrum Guide khẳng định: "Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation." Ba trụ cột này nâng đỡ mọi triển khai của empirical process control. Điều cực kỳ quan trọng cho kỳ thi: ba trụ cột này hoạt động theo trình tự và phụ thuộc lẫn nhau. Bỏ một cái là cả hệ thống sụp.
1. Transparency (Minh bạch)
Transparency nghĩa là quá trình làm việc và kết quả công việc phải được nhìn thấy rõ ràng đối với cả người làm lẫn người nhận. Những quyết định quan trọng phải dựa trên trạng thái của ba artifact: Product Backlog, Sprint Backlog, và Increment.
Nhưng minh bạch không chỉ là "thấy được" — nó còn đòi hỏi một tiêu chuẩn chung (common standard) để mọi người hiểu giống nhau về những gì họ đang thấy. Ví dụ kinh điển: nếu một Developer nói một hạng mục "đã xong" (Done) nhưng chưa kiểm thử, còn Product Owner hiểu "Done" là đã sẵn sàng phát hành — thì sự minh bạch bị phá vỡ, dù ai cũng "thấy" hạng mục đó. Đây là lý do Definition of Done tồn tại.
Hãy nhớ công thức tư duy này: Transparency là điều kiện tiên quyết. Không có minh bạch, hai trụ cột kia trở nên vô nghĩa.
2. Inspection (Kiểm tra)
Inspection nghĩa là các artifact và tiến độ hướng tới mục tiêu phải được kiểm tra thường xuyên và chuyên cần (frequently and diligently) để phát hiện những sai lệch hoặc vấn đề không mong muốn. Scrum cung cấp nhịp điệu (cadence) cho việc kiểm tra này thông qua năm sự kiện.
Một điểm tinh tế mà PSM I rất hay test: Inspection mà không có Transparency thì gây hiểu lầm và lãng phí. Nếu bạn kiểm tra một thứ không minh bạch (số liệu sai, "Done" giả), bạn sẽ rút ra kết luận sai. Scrum Guide nói rõ inspection nên được hỗ trợ bởi sự cẩn trọng và phải dẫn tới adaptation — kiểm tra không phải để kiểm tra, mà để có cơ sở điều chỉnh.
3. Adaptation (Thích nghi)
Adaptation nghĩa là khi việc kiểm tra phát hiện một hay nhiều khía cạnh của quy trình đi chệch khỏi giới hạn chấp nhận được, hoặc sản phẩm tạo ra sẽ không thể chấp nhận, thì quy trình hoặc vật liệu đang được xử lý phải được điều chỉnh — và việc điều chỉnh phải được thực hiện càng sớm càng tốt để giảm thiểu sai lệch xa hơn.
Adaptation là trụ cột dễ bị "rơi" nhất trong thực tế. Đội nhóm kiểm tra, thấy vấn đề, gật gù... rồi không thay đổi gì cả. Scrum Guide có một câu rất đắt: "Adaptation becomes more difficult when the people involved are not empowered or self-managing." — Việc thích nghi 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ý. Đây là cầu nối lý giải vì sao Scrum đòi hỏi đội tự quản (self-managing) — bạn sẽ học sâu ở Bài 28.
Mối liên hệ chuỗi: Transparency → Inspection → Adaptation
Hãy ghi nhớ chuỗi nhân quả này như một câu thần chú thi cử:
> Minh bạch tạo điều kiện cho kiểm tra. Kiểm tra tạo cơ sở cho thích nghi. Thiếu bất kỳ mắt xích nào, vòng lặp học hỏi đứt gãy.
- Không minh bạch → kiểm tra ra dữ liệu sai → thích nghi sai hướng.
- Minh bạch + kiểm tra nhưng không thích nghi → biết bệnh mà không chữa, lãng phí công sức kiểm tra.
- Đủ cả ba → vòng lặp học hỏi (empirical loop) vận hành, rủi ro được kiểm soát.
Tình huống thực tế
Ví dụ 1 — Tiki và bài học về "Done giả" (phá vỡ Transparency)
Hãy hình dung một đội phát triển tính năng "thanh toán trả góp" tại một sàn thương mại điện tử lớn như Tiki. Trong suốt 4 Sprint đầu, mỗi Sprint Review đội đều báo cáo "hoàn thành 8/8 hạng mục". Product Owner và stakeholder rất phấn khởi, burndown chart đẹp như mơ.
Nhưng đến Sprint 5, khi chuẩn bị phát hành thật, mọi thứ vỡ lở: các hạng mục "Done" trước đó chưa hề được kiểm thử tích hợp với cổng thanh toán ngân hàng, chưa xử lý lỗi mạng, chưa kiểm thử bảo mật. Hóa ra "Done" của đội chỉ có nghĩa là "code chạy được trên máy lập trình viên".
Diễn giải: Đây là một thất bại điển hình của trụ cột Transparency. Mọi người "thấy" con số 8/8, nhưng vì không có một Definition of Done chung và đáng tin, con số đó là minh bạch giả tạo. Inspection trong các buổi Sprint Review trở nên vô nghĩa vì nó kiểm tra một thực tế bị bóp méo.
Bài học rút ra: Minh bạch không tự nhiên mà có — nó phải được tạo ra bằng tiêu chuẩn chung (như Definition of Done) và bằng văn hóa dám nói thật. Một đội minh bạch sẽ nói "chúng tôi hoàn thành 5/8, ba cái còn lại vướng phần kiểm thử bảo mật" — nghe khó chịu hơn, nhưng đó mới là dữ liệu để điều chỉnh đúng.
Ví dụ 2 — Startup fintech ở TP.HCM và vòng lặp empiricism cứu cả sản phẩm
Một startup fintech giả định tên MoMoPay đang xây ứng dụng cho vay tiêu dùng. Ban đầu, đội ngũ tin chắc rằng người dùng muốn một quy trình duyệt vay tự động hoàn toàn trong 30 giây. Họ định nghĩa Product Goal quanh giả thuyết đó.
Thay vì dồn 6 tháng xây dựng toàn bộ rồi mới ra mắt, đội chia thành các Sprint hai tuần. Sau Sprint thứ ba, họ phát hành một phiên bản Increment cho 200 người dùng thật ở TP.HCM. Tại Sprint Review, dữ liệu thực tế (inspection) cho thấy: 70% người dùng bỏ ngang ở bước xác thực tự động vì họ không tin tưởng việc "máy duyệt vay" và muốn nói chuyện với người thật.
Đội đã adapt: họ điều chỉnh Product Backlog, bổ sung một bước xác nhận qua nhân viên tư vấn cho các khoản vay lớn, đẩy việc tự động hóa xuống các khoản nhỏ. Ba Sprint sau, tỷ lệ hoàn tất hồ sơ tăng từ 30% lên 68%.
Diễn giải: Đây là empiricism vận hành trọn vẹn. Minh bạch (Increment thật + dữ liệu hành vi thật) → Kiểm tra (phân tích tại Sprint Review) → Thích nghi (điều chỉnh Product Backlog ngay Sprint sau). Quan trọng nhất: họ thích nghi sớm, khi mới chỉ tốn 6 tuần, thay vì sau 6 tháng.
Bài học rút ra: Giá trị lớn nhất của các Sprint ngắn không phải là "làm nhanh", mà là tạo ra nhiều điểm kiểm tra và thích nghi. Mỗi Sprint là một cơ hội học hỏi. Đội nào trì hoãn việc tạo ra Increment thật là đang tự bịt mắt mình trong sương mù.
Ví dụ 3 — Đội ngoài Đà Nẵng kiểm tra mà không thích nghi (gãy trụ cột Adaptation)
Một công ty outsourcing ở Đà Nẵng có đội Scrum chạy đầy đủ nghi thức. Mỗi Sprint Retrospective, họ đều ghi ra cùng một vấn đề: "Môi trường test không ổn định, làm chậm việc kiểm thử." Vấn đề này xuất hiện trong biên bản retro suốt 7 Sprint liên tiếp. Nhưng vì việc cấp ngân sách cho hạ tầng nằm ngoài quyền của đội, không ai được trao quyền giải quyết, nên Sprint nào cũng ghi nhận rồi để đó.
Diễn giải: Đội này có Transparency (họ thấy rõ vấn đề) và Inspection (họ kiểm tra đều đặn mỗi retro), nhưng Adaptation bị gãy. Đúng như Scrum Guide cảnh báo: thích nghi trở nên bất khả thi khi con người không được trao quyền. Ở đây, vai trò Scrum Master lẽ ra phải đưa impediment này lên cấp tổ chức để gỡ — chính là lý do Scrum Master có accountability về việc loại bỏ trở ngại (Bài 30) và dẫn dắt thay đổi tổ chức (Bài 39).
Bài học rút ra: Inspection mà không dẫn tới Adaptation là một sân khấu lãng phí. Nó tạo cảm giác "chúng ta đang làm Scrum" trong khi vòng lặp học hỏi thực chất đã chết. Trong kỳ thi, hãy cảnh giác với những kịch bản mô tả đội "họp đều đặn nhưng không có gì thay đổi" — đó là dấu hiệu empiricism bị phá vỡ ở trụ cột thứ ba.
Hướng dẫn từng bước
Khi gặp bất kỳ tình huống nào (trong công việc thật hoặc trong phòng thi), bạn có thể dùng quy trình tư duy năm bước sau để kiểm chứng empiricism có đang vận hành lành mạnh không:
- Xác định artifact và mục tiêu đang được nói tới. Empiricism luôn xoay quanh ba artifact (Product Backlog, Sprint Backlog, Increment) và các commitment đi kèm. Hỏi: chúng ta đang muốn quan sát điều gì?
- Kiểm tra Transparency. Mọi người có nhìn thấy cùng một thực tế không? Có tiêu chuẩn chung (như Definition of Done) để hiểu giống nhau không? Có ai đang che giấu hay tô hồng dữ liệu không? Nếu minh bạch yếu, dừng lại và sửa cái này trước.
- Kiểm tra Inspection. Việc kiểm tra có diễn ra đủ thường xuyên không? Scrum đã gắn sẵn các điểm kiểm tra vào năm sự kiện — Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, và bản thân Sprint là container. Hỏi: chúng ta kiểm tra ở đâu, bao lâu một lần?
- Kiểm tra Adaptation. Khi kiểm tra phát hiện sai lệch, đội có thực sự thay đổi không, và có thay đổi sớm không? Người liên quan có được trao quyền để hành động không? Nếu chỉ ghi nhận mà không thay đổi, vòng lặp đã đứt.
- Đối chiếu với cadence của Sprint. Empiricism cần nhịp điệu đều đặn. Sprint càng ngắn, số điểm kiểm tra và thích nghi càng nhiều, rủi ro càng được kiểm soát chặt. Hỏi: nhịp học hỏi của đội có đủ ngắn để giảm rủi ro không?
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm Transparency với Openness (một trong 5 Scrum Values). Đây là bẫy kinh điển trong đề thi. Transparency là một trụ cột của empiricism, nói về việc làm cho công việc và artifact nhìn thấy được và hiểu được theo tiêu chuẩn chung. Openness là một giá trị (value) về thái độ con người — sẵn sàng cởi mở về công việc và thách thức. Bạn sẽ phân biệt sâu hai khái niệm này ở Bài 58, nhưng hãy nhớ ngay: Transparency là về artifact và quy trình, Openness là về con người và thái độ.
Lỗi 2 — Cho rằng Inspection chỉ diễn ra ở các event. Năm sự kiện cung cấp nhịp điệu chính thức cho inspection, nhưng kiểm tra có thể (và nên) xảy ra liên tục. Tuy nhiên — cẩn thận với chiều ngược lại: Scrum Guide nói inspection không nên diễn ra dày tới mức cản trở chính công việc. Bạn sẽ làm rõ ranh giới "inspection event vs touchpoint" ở Bài 57.
Lỗi 3 — Tưởng adaptation chỉ là điều chỉnh quy trình. Adaptation áp dụng cho cả quy trình (cách làm việc — thường điều chỉnh ở Retrospective) lẫn sản phẩm/vật liệu đang xử lý (Product Backlog, kế hoạch — thường điều chỉnh ở Sprint Review và Daily Scrum). Đừng bó hẹp adaptation chỉ vào retro.
Mẹo 1 — Học thuộc thứ tự và sự phụ thuộc. Khi phân vân, hãy nhớ chuỗi: Transparency làm nền cho Inspection, Inspection làm cơ sở cho Adaptation. Rất nhiều câu hỏi xoay quanh việc bạn có hiểu sự phụ thuộc này không.
Mẹo 2 — Empiricism luôn chống lại "kế hoạch cứng nhắc". Nếu một đáp án ngụ ý "khóa toàn bộ phạm vi từ đầu", "không cho phép thay đổi giữa chừng", hoặc "phải bám sát kế hoạch ban đầu bất kể bằng chứng" — đó là tư duy predictive, đối nghịch empirical. Gần như chắc chắn sai trong PSM I.
Mẹo 3 — Gắn empiricism với lean thinking. Scrum Guide 2020 đặt empiricism cạnh lean thinking (giảm lãng phí, tập trung vào điều thiết yếu). Đừng nhầm hai cái là một — bạn sẽ phân biệt rõ ở Bài 48 — nhưng hãy nhớ cả hai cùng là nền tảng của Scrum.
Bài tập thực hành
- Định nghĩa bằng lời của bạn: Viết ra một câu (không quá 30 từ) định nghĩa empiricism, có chứa ba từ khóa "knowledge", "experience", "observed". So sánh với nguyên văn Scrum Guide.
- Phân tích chuỗi nhân quả: Với mỗi tình huống sau, hãy xác định trụ cột nào đang bị phá vỡ (Transparency, Inspection, hay Adaptation):
- Soi đội của bạn (hoặc một đội bạn biết): Chấm điểm từ 1–5 cho từng trụ cột trong đội đó. Trụ cột nào yếu nhất? Một hành động cụ thể nào có thể cải thiện trụ cột yếu nhất ngay trong Sprint tới?
- Câu hỏi tư duy thi: Tại sao Scrum lại chọn Sprint ngắn (tối đa một tháng)? Hãy trả lời bằng ngôn ngữ của ba trụ cột empiricism, không dùng từ "nhanh".
- Phản biện: Có người nói "Đội tôi kiểm tra rất kỹ và minh bạch tuyệt đối, vậy là làm Scrum tốt rồi." Dựa vào bài học, hãy chỉ ra điều gì còn thiếu trong tuyên bố này.
Tóm tắt
- Empiricism là nền tảng của Scrum: tri thức đến từ kinh nghiệm, quyết định dựa trên những gì đã quan sát được — đây là empirical process control theory, phù hợp cho công việc phức tạp nơi không thể dự đoán trước.
- Scrum chọn empiricism vì phát triển sản phẩm là công việc phức tạp; áp kế hoạch cứng nhắc (defined process) sẽ thất bại. Đối lập với empirical là tư duy predictive — chủ đề bạn sẽ đào sâu ở Bài 24.
- Ba trụ cột nâng đỡ empiricism: Transparency (minh bạch — làm cho công việc nhìn thấy và hiểu được theo tiêu chuẩn chung), Inspection (kiểm tra thường xuyên, chuyên cần), Adaptation (điều chỉnh sớm khi phát hiện sai lệch).
- Ba trụ cột phụ thuộc theo chuỗi: Transparency làm nền cho Inspection, Inspection làm cơ sở cho Adaptation. Thiếu một mắt xích, vòng lặp học hỏi đứt gãy.
- Sai lầm hay gặp: "Done giả" phá vỡ minh bạch; kiểm tra đều nhưng không thay đổi làm gãy adaptation; thích nghi bất khả khi con người không được trao quyền — đây là lý do Scrum cần đội tự quản.
- Đối với PSM I: khi phân vân, chọn đáp án nào tăng minh bạch, tăng tần suất kiểm tra, và thúc đẩy thích nghi sớm. Đề phòng bẫy nhầm Transparency với Openness.