Mở đầu — vì sao bài này quan trọng
Nếu bạn đọc kỹ Scrum Guide, bạn sẽ thấy một câu nền tảng: "Scrum is founded on empiricism" — Scrum được xây dựng trên nền tảng của chủ nghĩa thực nghiệm. Và empiricism vận hành nhờ ba trụ cột: Transparency (minh bạch), Inspection (kiểm tra), và Adaptation (thích nghi). Trong bài 21 chúng ta đã nói về Empiricism như một triết lý nền tảng. Còn bài 39 này tập trung vào phần "cơ học" của nó: Inspect & Adapt cycles — những vòng lặp kiểm tra và thích nghi diễn ra như thế nào trong thực tế, ở những tầng nào, với nhịp độ ra sao.
Tại sao điều này quan trọng với một Product Owner đang chuẩn bị thi PSPO I? Vì đây là phần "ăn điểm" trong bài thi, và cũng là phần bị hiểu sai nhiều nhất. Rất nhiều ứng viên trả lời được "ba trụ cột của empiricism là gì" nhưng lại không trả lời được "khi nào thì inspect, ai inspect, adapt cái gì". Scrum Guide thiết kế tất cả các sự kiện (events) như những điểm dừng có chủ đích để inspect và adapt — không có sự kiện nào trong Scrum tồn tại chỉ để "họp cho có".
Quan trọng hơn cả việc thi cử: nếu bạn không hiểu cơ chế Inspect & Adapt, bạn sẽ vận hành Scrum như một lịch họp cố định, mất đi toàn bộ giá trị thực sự của nó. Bạn sẽ tổ chức Sprint Review chỉ để "demo cho sếp xem", chứ không phải để inspect Increment và adapt Product Backlog. Đó là sự khác biệt giữa "làm Scrum" và "diễn Scrum".
Khái niệm cốt lõi
Empirical Process Control là gì
Empirical Process Control (kiểm soát tiến trình bằng thực nghiệm) là cách quản lý công việc khi bạn không thể đoán trước hoàn hảo kết quả. Nó đối lập với Defined Process Control (kiểm soát tiến trình định nghĩa sẵn) — nơi bạn biết chính xác đầu vào tạo ra đầu ra nào, như một dây chuyền sản xuất ô tô.
Phát triển sản phẩm phần mềm là công việc phức tạp (complex work): yêu cầu thay đổi, công nghệ thay đổi, thị trường thay đổi, con người học hỏi qua thời gian. Bạn không thể lập một kế hoạch 12 tháng rồi thực thi y nguyên. Thay vào đó, bạn thử một bước ngắn, quan sát kết quả thật, rồi điều chỉnh hướng đi. Đó chính là empiricism.
Ba trụ cột:
- Transparency (Minh bạch): Bạn không thể inspect cái mà bạn không nhìn thấy rõ. Product Backlog phải minh bạch, Increment phải minh bạch, tiến độ phải minh bạch. Nếu PO giấu rủi ro, hoặc Developers báo cáo "gần xong" trong khi thực ra còn 40% việc, thì mọi inspection đều dựa trên thông tin sai.
- Inspection (Kiểm tra): Kiểm tra thường xuyên các Scrum artifacts và tiến độ hướng tới mục tiêu, để phát hiện sai lệch không mong muốn. Nhưng inspection phải vừa đủ — không được dày đến mức cản trở công việc.
- Adaptation (Thích nghi): Nếu inspection phát hiện ra điều gì đó lệch hướng, phải điều chỉnh càng sớm càng tốt để giảm thiểu sai lệch tiếp theo.
Inspect & Adapt diễn ra ở nhiều tầng (layers)
Đây là phần cốt lõi nhất của bài. Trong Scrum, Inspect & Adapt không phải một sự kiện duy nhất — nó là nhiều vòng lặp lồng vào nhau, với nhịp độ (cadence) khác nhau. Mỗi sự kiện Scrum chính là một điểm hẹn để inspect một artifact và adapt một thứ gì đó. Hãy nhìn bảng tổng hợp sau:
| Sự kiện (cadence) | Inspect cái gì | Adapt cái gì | Ai dẫn dắt |
|---|---|---|---|
| Daily Scrum (hằng ngày) | Sprint Backlog, tiến độ hướng tới Sprint Goal | Kế hoạch làm việc cho ngày tiếp theo (Sprint Backlog) | Developers |
| Sprint Review (cuối Sprint) | Increment, tiến độ hướng tới Product Goal | Product Backlog | Scrum Team + Stakeholders |
| Sprint Retrospective (cuối Sprint) | Cách thức làm việc: con người, quan hệ, quy trình, công cụ | Cách làm việc (definition of done, quy trình, cải tiến) | Scrum Team |
| Sprint Planning (đầu Sprint) | Product Backlog, năng lực Team, Product Goal | Sprint Backlog, Sprint Goal | Scrum Team |
| Product Backlog Refinement (liên tục) | Các Product Backlog Item | Product Backlog (chia nhỏ, làm rõ, ước lượng) | Scrum Team |
Sprint là vòng lặp Inspect & Adapt lớn nhất
Scrum Guide gọi Sprint là "the heartbeat of Scrum" — nhịp tim của Scrum. Đó không phải lời nói hoa mỹ. Sprint là container chứa tất cả các sự kiện khác, và độ dài Sprint chính là giới hạn rủi ro tối đa: nếu bạn đi sai hướng, bạn chỉ mất tối đa một Sprint trước khi inspect lại tại Sprint Review. Đây là lý do bài 43 sẽ bàn về chọn timebox — Sprint ngắn hơn nghĩa là vòng lặp inspect & adapt nhanh hơn, rủi ro thấp hơn, nhưng overhead cao hơn.
Mỗi event đều có timebox để bảo vệ nhịp inspect
Lý do tất cả các sự kiện đều có timebox (giới hạn thời gian) là để đảm bảo nhịp inspection diễn ra đều đặn và không bị trì hoãn. Nếu Daily Scrum kéo dài 90 phút, nó không còn là một điểm inspect nhanh để adapt kế hoạch ngày — nó trở thành một cuộc họp giải quyết vấn đề làm chậm nhịp tim. Timebox bảo vệ tính nhịp nhàng của empiricism.
Tình huống thực tế
Ví dụ 1 — Tiki và bài học "inspect sai tầng"
Hãy tưởng tượng một squad tại một sàn thương mại điện tử lớn ở Việt Nam (lấy bối cảnh tương tự Tiki), đang phát triển tính năng "đặt hàng nhanh trong 2 giờ". Sprint dài 2 tuần.
Vấn đề họ gặp: mỗi sáng, Daily Scrum của họ biến thành một buổi tranh luận về việc "có nên thêm tính năng chọn khung giờ giao hàng không". Cuộc họp kéo dài 40 phút, và họ liên tục thay đổi phạm vi (scope) trong giữa Sprint dựa trên ý kiến của một stakeholder vừa ghé qua.
Đây là lỗi inspect và adapt sai tầng. Daily Scrum là nơi inspect Sprint Backlog và adapt kế hoạch trong ngày để tiến tới Sprint Goal — KHÔNG phải nơi để adapt Product Backlog hay thay đổi scope dựa trên stakeholder. Việc adapt Product Backlog (thêm/bớt tính năng) thuộc về Sprint Review và quá trình Refinement.
Bài học rút ra: PO ở squad này cần kéo việc tranh luận scope ra khỏi Daily Scrum, đưa vào các buổi Refinement, và để quyết định adapt Product Backlog xảy ra đúng tại Sprint Review với đầy đủ stakeholder. Khi họ làm vậy, Daily Scrum rút xuống còn 12 phút và quay lại đúng chức năng: inspect tiến độ tới Sprint Goal.
Ví dụ 2 — Một fintech ở Singapore và vòng lặp "inspect không có transparency"
Một công ty fintech tại Singapore (giả định) phát triển ứng dụng ví điện tử. Họ làm đúng nhịp: Daily Scrum, Sprint Review, Retrospective đầy đủ. Nhưng sau 4 Sprint, sản phẩm vẫn không đạt được mục tiêu kinh doanh.
Khi đào sâu, vấn đề lộ ra: tại Sprint Review, Developers thường demo những thứ "trông như đã xong" nhưng chưa đạt Definition of Done — còn thiếu phần xử lý lỗi giao dịch, chưa test với tải thực. Increment được inspect tại Review không minh bạch về trạng thái thật. PO nhìn vào Increment "đẹp" và adapt Product Backlog dựa trên giả định rằng tính năng đã hoàn chỉnh, nên liên tục ưu tiên tính năng mới thay vì hoàn thiện cái cũ.
Đây là minh chứng cho nguyên tắc: Inspection chỉ tốt bằng mức độ Transparency của artifact được inspect. Vòng lặp Inspect & Adapt bị hỏng ngay từ trụ cột đầu tiên.
Bài học rút ra: Họ siết lại Definition of Done — chỉ những item thực sự "Done" mới được đưa vào Increment để inspect. Sau 2 Sprint, các quyết định adapt Product Backlog của PO chính xác hơn hẳn, vì giờ đây ông inspect dựa trên dữ liệu thật (tính năng chạy được trên production-like environment), không phải ảo giác.
Ví dụ 3 — VNG game studio và Retrospective "inspect mà không adapt"
Một studio game tại VNG (bối cảnh giả định) chạy Sprint Retrospective rất đều đặn. Mỗi Sprint, họ liệt kê ra 5-6 vấn đề: build chậm, môi trường test không ổn định, yêu cầu thay đổi liên tục từ creative director. Mọi người gật gù, ghi vào bảng, rồi... Sprint sau lại liệt kê đúng những vấn đề đó.
Đây là dạng hỏng phổ biến nhất: Inspection diễn ra nhưng Adaptation không xảy ra. Họ inspect cách làm việc rất tốt, nhưng không biến phát hiện thành hành động cụ thể, có người chịu trách nhiệm, có deadline.
Bài học rút ra: Scrum Master đề xuất một quy tắc đơn giản — mỗi Retrospective chỉ chọn một cải tiến (improvement) quan trọng nhất, đưa nó vào Sprint Backlog của Sprint kế tiếp như một việc thật sự được làm. Scrum Guide 2020 nói rõ điều này: Scrum Team có thể đưa các cải tiến vào Sprint Backlog của Sprint tiếp theo. Khi cải tiến trở thành một item được commit thay vì một dòng ghi chú, vòng lặp adapt mới thực sự khép kín. Sau vài Sprint, build time của họ giảm từ 25 phút xuống 8 phút — bằng chứng rằng vòng lặp đã chạy.
Hướng dẫn từng bước
Cách áp dụng tư duy Inspect & Adapt như một PO, theo từng bước:
Bước 1 — Xác định bạn đang ở tầng nào. Trước mỗi sự kiện, hỏi: "Cadence này inspect artifact nào, và adapt cái gì?" Daily → Sprint Backlog. Review → Increment & Product Backlog. Retro → cách làm việc. Đừng để các tầng lẫn vào nhau.
Bước 2 — Đảm bảo Transparency trước khi inspect. Với vai trò PO, trách nhiệm lớn nhất của bạn là giữ cho Product Backlog minh bạch. Trước Sprint Review, hãy chắc chắn rằng Increment được trình bày phản ánh đúng trạng thái thật (đạt Definition of Done). Không có minh bạch thì inspection chỉ tạo ra quyết định sai.
Bước 3 — Inspect dựa trên mục tiêu, không chỉ dựa trên danh sách công việc. Tại Daily, câu hỏi không phải "ai làm gì hôm qua" mà "chúng ta có đang tiến tới Sprint Goal không". Tại Review, câu hỏi là "Increment này đưa chúng ta gần Product Goal tới mức nào". Inspection luôn neo vào một commitment (Sprint Goal hoặc Product Goal).
Bước 4 — Biến phát hiện thành Adaptation cụ thể. Mỗi inspection phải kết thúc bằng một quyết định: reorder Product Backlog, thêm/bỏ item, thay đổi Sprint Backlog, hoặc một cải tiến quy trình. Adaptation phải có thể hành động được và xảy ra sớm.
Bước 5 — Đóng vòng lặp ở Sprint kế tiếp. Adaptation chỉ có giá trị nếu nó được thực thi. Cải tiến từ Retro vào Sprint Backlog. Product Backlog đã reorder thì phản ánh ngay ở Sprint Planning tiếp theo. Sau đó bạn lại inspect xem adaptation có hiệu quả không — đó là bản chất "vòng lặp".
Bước 6 — Điều chỉnh chính nhịp inspect nếu cần. Nếu rủi ro cao và bạn đi sai hướng quá lâu mới phát hiện, có thể Sprint của bạn đang quá dài. Empiricism cho phép bạn adapt cả cấu trúc vòng lặp.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi sự kiện Scrum là "lịch họp" thay vì điểm inspect & adapt. Nhiều team hỏi "có thể bỏ Daily Scrum không cho đỡ mất thời gian?". Câu hỏi đúng phải là "nhịp inspect mỗi ngày này có còn giúp chúng ta adapt kế hoạch hướng tới Sprint Goal không?". Sự kiện tồn tại vì cơ chế, không vì thủ tục.
Lỗi 2 — Inspect mà không adapt. Đã nói ở ví dụ 3. Mẹo: mỗi inspection bắt buộc kết thúc bằng ít nhất một quyết định hành động.
Lỗi 3 — Adapt mà không có transparency. Quyết định dựa trên thông tin mờ ám sẽ làm sai lệch hướng đi. Mẹo: trước khi adapt Product Backlog, kiểm tra xem Increment được inspect có thực sự "Done" không.
Lỗi 4 — Inspect quá nhiều, cản trở công việc. Scrum Guide cảnh báo: inspection không nên thường xuyên đến mức cản trở chính công việc. Đừng họp inspect liên miên. Năm sự kiện với cadence được thiết kế là đã đủ.
Lỗi 5 — Lẫn lộn tầng (như ví dụ Tiki). Mẹo ghi nhớ cho phòng thi: Daily adapt Sprint Backlog, Review adapt Product Backlog. Đây là cặp đối lập mà PSPO I rất hay đặt bẫy.
Mẹo thi PSPO I: Khi gặp câu hỏi "sự kiện nào là cơ hội để inspect và adapt", nhớ rằng mọi sự kiện đều là cơ hội inspect & adapt — và bản thân Sprint là container chứa tất cả. Câu hỏi thường tinh vi ở chỗ "adapt CÁI GÌ", nên hãy luôn ghép đúng cặp event ↔ artifact.
Bài tập thực hành
- Lập bảng cá nhân: Vẽ lại bảng 5 sự kiện với 3 cột (Inspect cái gì / Adapt cái gì / Ai dẫn dắt) mà không nhìn lại bài. Sau đó đối chiếu. Lặp lại đến khi điền đúng hoàn toàn trong 3 phút.
- Soi team của bạn: Với team hiện tại (hoặc team bạn quan sát), trả lời: vòng lặp inspect & adapt nào đang chạy tốt, vòng nào bị "inspect không adapt", vòng nào thiếu transparency? Ghi ra 1 hành động cụ thể để sửa vòng yếu nhất.
- Tình huống quyết định: Một stakeholder muốn thêm tính năng giữa Sprint. Theo cơ chế Inspect & Adapt, sự kiện nào là nơi đúng để đưa quyết định này vào, và adapt artifact nào? Viết câu trả lời 3-4 câu.
- Câu hỏi tự luận kiểu thi: "Tại sao Inspection mà không có Transparency lại nguy hiểm hơn là không inspect?" Trả lời trong 5 dòng, dùng lại ví dụ fintech.
Tóm tắt
- Scrum đặt nền trên empiricism, vận hành qua ba trụ cột không tách rời: Transparency → Inspection → Adaptation. Thiếu một trụ cột, cả hệ thống sụp.
- Inspect & Adapt không phải một sự kiện đơn lẻ, mà là nhiều vòng lặp lồng nhau với cadence khác nhau: Daily (mỗi ngày, inspect Sprint Backlog → adapt kế hoạch ngày), Sprint Review (cuối Sprint, inspect Increment → adapt Product Backlog), Retrospective (cuối Sprint, inspect cách làm việc → adapt quy trình), Sprint Planning và Refinement.
- Sprint là vòng lặp lớn nhất — nhịp tim của Scrum, đồng thời là giới hạn rủi ro tối đa.
- Mỗi event có timebox để bảo vệ nhịp inspect đều đặn.
- Ba dạng hỏng phổ biến: inspect sai tầng (Tiki), inspect không transparency (fintech), inspect mà không adapt (VNG). PO giỏi là người đảm bảo cả ba trụ cột đều khép kín ở mọi tầng.
- Mẹo phòng thi: luôn ghép đúng cặp event ↔ artifact được inspect ↔ artifact được adapt, đặc biệt phân biệt Daily adapt Sprint Backlog còn Review adapt Product Backlog.