Mở đầu — vì sao bài này quan trọng
Nếu bạn đang ôn thi PSPO I, hãy ghi nhớ một điều: rất nhiều câu hỏi trong bài thi không kiểm tra xem bạn có thuộc lòng Scrum Guide hay không, mà kiểm tra xem bạn có tư duy theo đúng tinh thần của Scrum hay không. Và cái tinh thần đó có một cái tên: empiricism — tính kinh nghiệm, hay còn gọi là "kiểm soát tiến trình dựa trên thực nghiệm" (empirical process control).
Tại sao tôi nhấn mạnh điều này ngay từ đầu? Bởi vì trong thực tế đi làm tại Việt Nam, tôi gặp rất nhiều Product Owner và team "làm Scrum" nhưng lại tư duy theo kiểu kế hoạch cứng (predictive/waterfall trá hình): lập một bản kế hoạch chi tiết 6 tháng, cam kết toàn bộ scope ngay từ Sprint 1, rồi gồng mình ép thực tế khớp với kế hoạch. Họ có Daily Scrum, có Sprint, có bảng Jira đẹp — nhưng họ không làm Scrum, vì họ thiếu cái gốc rễ: ra quyết định dựa trên những gì đã quan sát được, chứ không phải dựa trên giả định ban đầu.
Empiricism là nền móng. Nếu bạn hiểu sai phần này, thì mọi thứ phía trên — Product Goal, Sprint, Backlog, các sự kiện — đều trở thành nghi thức trống rỗng. Hiểu đúng phần này, bạn sẽ trả lời được hàng loạt câu hỏi thi một cách tự nhiên, và quan trọng hơn, bạn sẽ trở thành một PO thực sự tạo ra giá trị thay vì chỉ "chạy quy trình".
Khái niệm cốt lõi
Empiricism là gì
Empiricism (chủ nghĩa kinh nghiệm) khẳng định rằng: tri thức đến từ kinh nghiệm, và các quyết định nên được đưa ra dựa trên những gì đã quan sát được (what is known/observed), chứ không phải dựa trên dự đoán hay lý thuyết suông.
Scrum Guide 2020 nói rất rõ: "Scrum được xây dựng trên nền tảng của empiricism và lean thinking. Empiricism khẳng định rằng tri thức đến từ kinh nghiệm và việc ra quyết định dựa trên những gì đã được quan sát."
Hãy đối chiếu với cách làm truyền thống để thấy sự khác biệt. Trong mô hình predictive (định trước), bạn tin rằng nếu lập kế hoạch đủ kỹ ngay từ đầu thì kết quả sẽ chắc chắn. Nó hoạt động tốt khi vấn đề đơn giản, công nghệ ổn định, yêu cầu không đổi. Nhưng phát triển sản phẩm phần mềm hiếm khi như vậy — đó là môi trường phức tạp (complex), nơi có quá nhiều biến số chưa biết, khách hàng cũng không chắc mình muốn gì cho đến khi nhìn thấy sản phẩm. Trong môi trường này, kế hoạch chi tiết ban đầu gần như chắc chắn sai. Empiricism chấp nhận sự thật đó và đưa ra cách làm phù hợp: tiến từng bước nhỏ, quan sát kết quả thực, rồi điều chỉnh.
Một cách nói ngắn gọn để nhớ: Predictive = "plan rồi làm". Empirical = "làm một ít, nhìn kết quả, rồi quyết bước tiếp theo".
Liên hệ với mô hình Cynefin
Để hiểu tại sao Scrum chọn empiricism, hãy nhớ tới khung Cynefin. Công việc của một team phát triển sản phẩm thường rơi vào vùng complex — quan hệ nhân-quả chỉ nhìn rõ được sau khi đã thử. Trong vùng này, công thức đúng là "probe – sense – respond": thử nghiệm một việc nhỏ, cảm nhận kết quả, rồi phản hồi. Đó chính xác là cách Scrum vận hành qua các Sprint ngắn. Bạn không cần thuộc Cynefin để thi PSPO I, nhưng nó giúp bạn thấm lý do vì sao empiricism là lựa chọn bắt buộc chứ không phải tùy chọn.
Ba trụ cột của empiricism
Empiricism trong Scrum đứng trên ba trụ cột (three pillars). Đây là phần xuất hiện rất thường xuyên trong đề thi, nên bạn cần hiểu sâu chứ không chỉ thuộc tên.
1. Transparency (Minh bạch). Tiến trình và công việc phải được thể hiện một cách minh bạch cho cả người làm lẫn người nhận kết quả. Minh bạch là điều kiện tiên quyết: nếu thông tin bị che giấu hoặc sai lệch, thì mọi quyết định dựa trên nó đều rủi ro. Ví dụ cụ thể: Product Backlog phải rõ ràng và được sắp xếp công khai; Definition of Done phải được cả team hiểu giống nhau; trạng thái công việc trên bảng phải phản ánh đúng thực tế. Nếu một Developer đánh dấu một task là "Done" trong khi nó chưa được test, đó là phá vỡ tính minh bạch — và nó sẽ làm hỏng hai trụ cột còn lại.
2. Inspection (Kiểm tra/Thanh tra). Phải thường xuyên kiểm tra các "artifact" của Scrum (Product Backlog, Sprint Backlog, Increment) và tiến độ hướng tới mục tiêu đã thỏa thuận, để phát hiện những sai lệch hoặc vấn đề không mong muốn. Lưu ý từ khóa trong Scrum Guide: việc kiểm tra phải diligent (cẩn trọng) nhưng không gây cản trở công việc. Inspection không có nghĩa là giám sát kiểu sếp soi nhân viên — nó là việc cả team cùng nhìn vào thực tế để học.
3. Adaptation (Thích nghi/Điều chỉnh). Nếu việc kiểm tra cho thấy có sai lệch vượt ngoài 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ì tiến trình hoặc vật liệu đang xử lý phải được điều chỉnh càng sớm càng tốt để giảm thiểu sai lệch tiếp theo. Adaptation là điểm mà nhiều team thất bại: họ kiểm tra, thấy vấn đề, nhưng rồi… vẫn làm như cũ. Inspection mà không kéo theo Adaptation thì vô nghĩa.
Mối quan hệ giữa ba trụ cột
Đây là chỗ tinh tế mà đề thi hay "gài". Ba trụ cột không độc lập — chúng phụ thuộc lẫn nhau theo một chuỗi:
- Không có Transparency thì Inspection vô giá trị. Bạn không thể kiểm tra cái mà bạn không nhìn thấy đúng. Nếu Increment trông như đã xong nhưng thực chất còn lỗi ẩn, thì việc "kiểm tra" tại Sprint Review chỉ tạo ra quyết định sai.
- Inspection mà không dẫn tới Adaptation thì lãng phí. Quan sát ra vấn đề mà không thay đổi gì thì cũng như không quan sát.
Empiricism và vai trò Product Owner
Là một PO, bạn là người chịu trách nhiệm tối đa hóa giá trị. Mà giá trị thì không thể "tính toán chắc chắn" trước được — nó phải được kiểm chứng qua thực tế. Empiricism chính là công cụ tư duy của bạn: thay vì cãi nhau trong phòng họp về việc tính năng nào sẽ thành công, bạn xây một phần nhỏ, đưa ra Increment, quan sát phản hồi của người dùng/khách hàng tại Sprint Review, rồi điều chỉnh thứ tự Backlog. PO giỏi là PO biết "đặt cược nhỏ và học nhanh", chứ không phải PO biết viết bản đặc tả dày nhất.
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT nội địa và tính năng "mua chung"
Một công ty thương mại điện tử tại TP.HCM (gọi là ShopViet) muốn ra mắt tính năng "mua chung" (group buy) — nhiều người gom đơn để được giá rẻ. Ban đầu, Product Owner và ban giám đốc lập kế hoạch xây dựng toàn bộ hệ thống trong 4 tháng: tạo nhóm, mời bạn bè, chia sẻ qua Zalo, theo dõi tiến độ gom đơn, xử lý hoàn tiền nếu nhóm không đủ người. Tổng cộng khoảng 40 user story, cam kết cứng với CEO ngay từ đầu.
PO mới về sau đó đề xuất cách làm theo empiricism. Thay vì cam kết 40 story, trong 2 Sprint đầu (4 tuần), team chỉ làm phiên bản tối giản: một người tạo nhóm, share link Zalo, đủ 3 người thì chốt giá. Họ đưa Increment này cho khoảng 500 khách hàng thật dùng thử.
Diễn giải: Tại Sprint Review, dữ liệu quan sát được (transparency) gây bất ngờ — 70% người dùng không mời bạn bè như giả định, mà tự gom đơn của chính mình bằng cách mua nhiều món để đạt mốc giá. Việc "mời bạn qua Zalo" mà team định đầu tư cả tháng gần như không ai dùng. Team inspect dữ liệu này, rồi adapt: bỏ phần lớn tính năng mời bạn, dồn nguồn lực vào tối ưu trải nghiệm gom đơn cá nhân.
Bài học: Nếu ShopViet làm theo kế hoạch cứng ban đầu, họ đã tốn 1 tháng xây tính năng gần như không ai dùng. Empiricism giúp họ tiết kiệm hàng trăm triệu đồng và rút ngắn thời gian ra thị trường. Mấu chốt là họ dám đưa một Increment nhỏ ra để quan sát thực tế thay vì tranh luận trên giả định.
Ví dụ 2 — Khi minh bạch bị phá vỡ ở một fintech
Một startup fintech tại Hà Nội (gọi là PayNhanh) làm ví điện tử. Áp lực ra mắt khiến các Developer có thói quen đánh dấu story là "Done" khi code đã chạy được trên máy của họ, nhưng chưa qua kiểm thử tích hợp và chưa đáp ứng Definition of Done. Bảng Jira lúc nào cũng "xanh", báo cáo lên cho PO và stakeholder đều đẹp.
Diễn giải: Vấn đề là tính minh bạch đã bị phá vỡ. Tại các Sprint Review, PO trình bày Increment với nhà đầu tư dựa trên niềm tin "mọi thứ đã Done". Đến khi gom lại để release, hàng loạt lỗi tích hợp lộ ra: chức năng nạp tiền xung đột với chức năng chuyển khoản. Inspection tại Review trước đó hoàn toàn vô giá trị, vì cái được kiểm tra không phản ánh đúng thực tế. Quyết định "release vào cuối quý" mà PO cam kết với nhà đầu tư dựa trên dữ liệu giả.
Scrum Master sau đó siết lại Definition of Done và yêu cầu trạng thái trên bảng phải phản ánh đúng. Chỉ khi minh bạch được khôi phục, các buổi inspect mới thực sự có ý nghĩa và team mới adapt được kịp thời.
Bài học: "Không có Transparency thì Inspection vô giá trị" không phải là câu lý thuyết — nó là nguyên nhân trực tiếp khiến cả một chuỗi quyết định sai lầm xảy ra. Là PO, bạn phải bảo vệ tính minh bạch như bảo vệ tài sản, vì mọi quyết định giá trị của bạn đều dựa trên nó.
Ví dụ 3 — Inspect mà không Adapt tại một agency outsourcing
Một công ty gia công phần mềm (gọi là TechBridge) làm dự án cho khách Singapore. Mỗi Sprint Retrospective, team đều phát hiện cùng một vấn đề: ước lượng luôn lạc quan quá mức, Sprint nào cũng "cháy". Họ ghi nhận đầy đủ vào biên bản — kiểm tra rất kỹ. Nhưng Sprint sau, họ vẫn lặp lại y hệt: nhận quá nhiều story, không thay đổi cách ước lượng, không giảm khối lượng cam kết.
Diễn giải: Đây là ví dụ kinh điển của "Inspection không dẫn tới Adaptation". Team có đủ ba sự kiện, có minh bạch về vấn đề, có kiểm tra — nhưng thiếu trụ cột thứ ba. Họ biến Retrospective thành buổi "than thở" rồi để đó. Empirical process control chỉ tạo ra giá trị khi vòng lặp khép kín: quan sát phải dẫn tới hành động thay đổi.
Khi một Scrum Master mới yêu cầu mỗi Retrospective chỉ chọn một cải tiến cụ thể và đưa nó thành một mục có thể kiểm chứng trong Sprint Backlog kế tiếp, mọi thứ bắt đầu chuyển động. Sau 3 Sprint, độ chính xác của forecast cải thiện rõ rệt.
Bài học: Kiểm tra mà không thích nghi là lãng phí. Đừng để các sự kiện Scrum trở thành nghi thức. Mỗi lần inspect, hãy hỏi: "Chúng ta sẽ thay đổi điều gì dựa trên những gì vừa thấy?"
Hướng dẫn từng bước
Dưới đây là cách bạn — với tư cách PO — vận hành tư duy empirical trong công việc hằng ngày:
- Bắt đầu nhỏ, ưu tiên học hỏi. Với mỗi giả định lớn về giá trị, hãy hỏi: phần nhỏ nhất nào có thể giúp ta kiểm chứng giả định này? Đưa nó lên đầu Backlog. Mục tiêu của những Sprint đầu thường là học, không phải xây cho đủ.
- Đảm bảo Transparency trước mọi quyết định. Trước Sprint Review hay bất kỳ quyết định nào, kiểm tra: Increment này có thực sự "Done" theo DoD không? Backlog có phản ánh đúng hiểu biết hiện tại không? Trạng thái công việc có thật không? Nếu thông tin không đáng tin, hãy sửa nó trước khi ra quyết định.
- Biến mỗi sự kiện thành một điểm Inspect. Sprint Planning inspect Product Backlog và năng lực team; Daily Scrum inspect tiến độ hướng tới Sprint Goal; Sprint Review inspect Increment với stakeholder; Retrospective inspect cách làm việc. Đi vào mỗi sự kiện với câu hỏi rõ ràng: "Chúng ta đang muốn quan sát điều gì?"
- Luôn kết thúc Inspect bằng một Adapt cụ thể. Sau khi quan sát, hãy quyết định một thay đổi có thể hành động được: sắp xếp lại thứ tự Backlog, bỏ một tính năng, điều chỉnh Sprint Goal kế tiếp, thay đổi cách ước lượng. Ghi nó vào nơi sẽ được thực thi (Backlog, Sprint Backlog).
- Rút ngắn vòng lặp để học nhanh hơn. Sprint càng ngắn, bạn càng nhận phản hồi sớm và rủi ro mỗi lần "đặt cược" càng nhỏ. Đây là lý do Scrum giới hạn Sprint tối đa 1 tháng — để vòng inspect & adapt không quá thưa.
- Lặp lại. Empiricism không phải làm một lần. Đó là nhịp đập liên tục: minh bạch → kiểm tra → thích nghi, Sprint này qua Sprint khác.
Lỗi thường gặp & mẹo
Lỗi 1: Nhầm "có đủ sự kiện" với "đang làm empirical". Nhiều team có đủ 5 event nhưng vẫn tư duy predictive. Mẹo: với mỗi event, hỏi "buổi này dẫn tới thay đổi gì không?" Nếu câu trả lời thường xuyên là "không", bạn đang chạy nghi thức.
Lỗi 2: Coi nhẹ Transparency. Báo cáo tô hồng, DoD mơ hồ, trạng thái "Done giả". Mẹo: bảo vệ một Definition of Done rõ ràng và chung cho cả team — đây là công cụ minh bạch quan trọng nhất của Increment.
Lỗi 3: Inspect nhưng không Adapt. Như ví dụ TechBridge. Mẹo: mỗi Retrospective chỉ chọn 1–2 cải tiến và đưa vào Sprint Backlog kế tiếp như công việc thật.
Lỗi 4: Adapt mà không dựa trên dữ liệu quan sát. Đổi hướng liên tục theo cảm tính hoặc theo ý sếp lớn nhất phòng (HiPPO) cũng không phải empiricism. Adaptation phải bắt nguồn từ những gì đã quan sát, không phải từ ý kiến to nhất.
Lỗi 5: Lập kế hoạch chi tiết quá xa. Cam kết cứng scope 6 tháng đi ngược tinh thần empirical. Mẹo cho thi và cho việc thật: hãy phân biệt forecast (dự báo, có thể sai) với commitment (cam kết). Empiricism làm việc với forecast.
Mẹo phòng thi: Khi gặp câu hỏi PSPO I có chữ "empirical", "inspect", "adapt", "transparency", hãy ưu tiên đáp án thể hiện việc quan sát thực tế và điều chỉnh thường xuyên, và loại bỏ ngay những đáp án thiên về "kế hoạch chi tiết từ đầu", "cam kết toàn bộ scope", hoặc "tuân thủ kế hoạch bất chấp thực tế thay đổi". Cũng nhớ: ba trụ cột là Transparency – Inspection – Adaptation (đừng nhầm với Scrum Values; đó là chủ đề riêng).
Bài tập thực hành
- Phân biệt nhanh: Viết ra 3 quyết định gần đây trong dự án của bạn. Với mỗi quyết định, xác định: nó dựa trên dữ liệu đã quan sát hay dựa trên giả định/kế hoạch ban đầu? Bao nhiêu phần trăm là empirical thật sự?
- Soi ba trụ cột: Chọn dự án bạn đang làm. Đánh giá từng trụ cột trên thang 1–5: Transparency (thông tin có đáng tin không?), Inspection (các event có thực sự kiểm tra điều gì không?), Adaptation (chúng ta có thay đổi dựa trên quan sát không?). Trụ cột yếu nhất là gì, và một hành động cụ thể để cải thiện nó?
- Thiết kế một thử nghiệm: Lấy một tính năng lớn mà team định xây nguyên khối. Hãy phác thảo phiên bản nhỏ nhất có thể đưa ra trong 1 Sprint để kiểm chứng giả định giá trị của nó. Bạn sẽ quan sát chỉ số nào để biết giả định đúng hay sai?
- Luyện đề: Tự đặt 5 câu hỏi trắc nghiệm về ba trụ cột và mối quan hệ giữa chúng (ví dụ: "Điều gì xảy ra với Inspection nếu Transparency bị phá vỡ?"). Trả lời rồi đối chiếu lại với Scrum Guide.
Tóm tắt
- Empiricism = ra quyết định dựa trên những gì đã quan sát được, không phải dựa trên dự đoán hay kế hoạch ban đầu. Đây là nền tảng của Scrum, phù hợp cho công việc phức tạp nơi yêu cầu và công nghệ luôn biến động.
- Empiricism vận hành qua ba trụ cột: Transparency (minh bạch), Inspection (kiểm tra), Adaptation (thích nghi).
- Ba trụ cột phụ thuộc nhau: không minh bạch thì kiểm tra vô giá trị; kiểm tra mà không thích nghi thì lãng phí.
- Mỗi sự kiện Scrum là một cơ hội inspect & adapt; Sprint ngắn giúp vòng lặp học hỏi nhanh và rủi ro nhỏ.
- Với PO: tối đa hóa giá trị không phải bằng bản kế hoạch dày nhất, mà bằng cách đặt cược nhỏ, đưa Increment ra, quan sát phản hồi thực, rồi điều chỉnh Backlog.
- Cảnh giác với "Scrum nghi thức": có đủ event nhưng tư duy predictive, báo cáo tô hồng, hoặc inspect mà không bao giờ adapt — đó là dấu hiệu empiricism đã chết dù Scrum vẫn "có vẻ" đang chạy.