Mở đầu — vì sao bài này quan trọng
Hãy thử hình dung: đội của bạn vừa kết thúc một buổi Retrospective rất hào hứng. Mọi người chia sẻ thẳng thắn, sticky note dán kín tường, và cuối buổi cả đội thống nhất ba "action item" để cải thiện. Ai cũng vui vẻ rời phòng họp với cảm giác "lần này sẽ khác".
Rồi Sprint trôi qua. Đến buổi Retro tiếp theo, bạn mở lại danh sách action cũ và nhận ra: chẳng có gì thay đổi. Không ai làm. Không ai nhớ. Và tệ hơn, khi bạn nhắc lại, vài người trong đội nhún vai: "À, cái đó hả? Tưởng ai khác lo rồi."
Đây là một trong những cái chết âm thầm nhưng phổ biến nhất của Retrospective: retro tạo ra action item → không có gì thay đổi → retro mất uy tín → đội ngừng nghiêm túc với retro → đội ngừng cải thiện. Khi vòng lặp này lặp lại đủ nhiều lần, học viên của bạn sẽ nghe được câu nói chí mạng: "Retro chỉ là buổi than vãn cho có lệ thôi."
Là Scrum Master, bạn không thiếu công cụ để chạy một buổi retro hay (suốt cả khóa học này bạn đã học hàng chục công cụ như vậy). Nhưng tất cả các công cụ đó đều vô nghĩa nếu output của chúng — các action item — không bao giờ được thực thi. Action Item Discipline chính là kỷ luật biến những lời nói trong phòng họp thành thay đổi thật sự trong cách đội làm việc. Đây không phải kỹ thuật facilitation hào nhoáng, mà là phần "cơ bắp" giúp toàn bộ nỗ lực cải tiến của bạn không đổ sông đổ bể.
Bài này tập trung hoàn toàn vào phần sau khi action item được sinh ra: cách viết action cho đúng, cách giao trách nhiệm, cách theo dõi, và cách đóng vòng lặp để đội tin rằng retro thật sự tạo ra thay đổi.
Khái niệm cốt lõi
Vấn đề gốc rễ: action item không phải là "thay đổi"
Sai lầm tư duy phổ biến nhất là xem việc viết ra một action item đã là hoàn thành cải tiến. Thực ra, action item chỉ là một lời hứa. Lời hứa không tự thực hiện. Khoảng cách giữa "chúng ta đồng ý làm X" và "X đã thực sự xảy ra" chính là nơi 80% giá trị của retro bị bốc hơi.
Có ba nguyên nhân khiến action item chết yểu mà bạn cần nhận diện:
- Mơ hồ — Action viết kiểu "giao tiếp tốt hơn", "test kỹ hơn", "chủ động hơn". Không ai biết "tốt hơn" nghĩa là gì, làm khi nào, đo bằng cách nào.
- Vô chủ — Action không có người chịu trách nhiệm rõ ràng. Khi "cả đội" chịu trách nhiệm thì thực tế là không ai chịu trách nhiệm.
- Mất tích — Action được ghi đâu đó (thường là một file Google Docs không ai mở lại) và không xuất hiện trong dòng công việc hàng ngày của đội.
SMART actions — biến lời hứa thành cam kết có thể kiểm chứng
Khung SMART vốn quen thuộc trong quản lý mục tiêu, nhưng áp dụng cho action item của retro thì cực kỳ đắt giá. Hãy đi qua từng chữ với góc nhìn của một Scrum Master:
- S — Specific (Cụ thể): Action phải mô tả một hành động quan sát được. Thay vì "cải thiện code review", hãy viết "thêm checklist 5 mục vào template Pull Request". Một người ngoài đọc vào phải hiểu chính xác cần làm gì.
- M — Measurable (Đo được): Phải có cách biết action đã hoàn thành hay chưa. "Họp standup ngắn hơn" thì mơ hồ; "standup kết thúc trong 15 phút, đo bằng hẹn giờ" thì đo được. Đo được không nhất thiết phải là con số phức tạp — đôi khi chỉ cần một câu hỏi yes/no rõ ràng: "Template PR mới đã được áp dụng chưa?"
- A — Achievable (Khả thi): Action phải nằm trong tầm kiểm soát của đội và làm được trong một Sprint. "Thuyết phục ban giám đốc thay đổi toàn bộ quy trình công ty" không phải action item của retro — đó là một dự án. Nếu vấn đề lớn, hãy cắt ra một bước nhỏ mà đội tự làm được tuần này.
- R — Relevant (Liên quan): Action phải thật sự giải quyết vấn đề đã nêu, không phải làm cho có. Đây là lúc bạn hỏi: "Nếu làm cái này, nó có thật sự gỡ được nỗi đau chúng ta vừa nói không?"
- T — Time-bound (Có hạn chót): Mỗi action cần một deadline cụ thể, thường là "trong Sprint này" hoặc một ngày rõ ràng. Không có deadline thì action sẽ trôi vô tận.
Owner đơn lẻ, không phải tập thể
Một nguyên tắc vàng: mỗi action item phải có đúng một owner (chủ sở hữu). Lưu ý owner không có nghĩa là người duy nhất làm action đó — owner là người đảm bảo nó được làm. Họ có thể nhờ người khác cùng làm, nhưng họ là người bạn sẽ hỏi "tiến độ tới đâu rồi?" Trách nhiệm cá nhân tạo ra lực kéo mà trách nhiệm tập thể không bao giờ có được.
Giới hạn số lượng — ít mà chất
Một đội không thể thay đổi mười thứ cùng lúc. Kinh nghiệm thực tế cho thấy 1–3 action item mỗi Sprint là vùng hợp lý. Nếu retro sinh ra mười điều cần cải thiện, hãy ưu tiên (dùng dot voting hay bất kỳ kỹ thuật bỏ phiếu nào) và chọn ra số ít quan trọng nhất. Hoàn thành trọn vẹn hai action còn hơn bỏ dở tám.
Đóng vòng lặp (Closing the loop)
Đây là phần bị bỏ quên nhiều nhất nhưng lại quan trọng nhất về mặt tâm lý. Mở đầu mỗi retro bằng việc xem lại action item của Sprint trước. Cái nào đã làm? Cái nào chưa, vì sao? Hành động đơn giản này gửi một thông điệp cực mạnh tới đội: "Những gì chúng ta nói ở đây được theo dõi và có hậu quả." Khi đội thấy action cũ được hoàn thành và có tác động, niềm tin vào retro tăng lên, và họ sẽ tham gia nghiêm túc hơn ở lần sau.
Tình huống thực tế
Tình huống 1 — Đội Tiki: từ "than vãn" thành cải tiến đo được
Một đội phát triển 7 người tại một công ty thương mại điện tử lớn ở TP.HCM (tạm gọi mô hình giống Tiki) gặp tình trạng kinh điển. Suốt 4 Sprint liên tục, retro của họ luôn nổi lên cùng một vấn đề: "build CI hay hỏng, mất thời gian." Mỗi lần họ đều ghi action "fix CI cho ổn định" — và mỗi lần action đó nằm im trong file note.
Scrum Master mới về quyết định áp dụng Action Item Discipline. Thay vì "fix CI cho ổn định", cả đội viết lại action theo SMART:
- Specific: "Thêm bước retry tự động cho 3 test flaky đã xác định (TC-101, TC-205, TC-340) và bật cảnh báo Slack khi build đỏ."
- Measurable: "Tỷ lệ build đỏ do flaky test giảm từ ~30% xuống dưới 10%, đo qua dashboard CI."
- Achievable: Nằm trong tầm tay đội, ước tính 1 ngày công.
- Relevant: Trực tiếp gỡ nỗi đau đã lặp lại 4 Sprint.
- Time-bound: "Xong trước cuối Sprint này (ngày 15)."
- Owner: Anh Hùng (dev), không phải "cả đội".
Bài học: Việc đưa action vào chính Sprint Backlog (chứ không để ngoài luồng) cộng với một owner cụ thể và một thước đo rõ ràng đã biến một lời than vãn lặp đi lặp lại thành cải tiến thật. Và việc "khoe" kết quả ở retro sau chính là cú đóng vòng lặp tạo niềm tin.
Tình huống 2 — Startup fintech Singapore: căn bệnh "action vô chủ"
Một startup fintech khoảng 25 người ở Singapore có văn hóa retro rất sôi nổi. Mỗi buổi sinh ra 6–8 action item, ai cũng gật gù đồng ý. Nhưng sau ba tháng, founder phàn nàn với agile coach rằng "đội nói nhiều mà chẳng đổi gì."
Coach ngồi dự một buổi và phát hiện vấn đề ngay lập tức: tất cả action đều ghi owner là "Team" hoặc "Everyone". Khi mọi người cùng sở hữu, không ai thực sự cầm. Thêm vào đó, danh sách 6–8 action mỗi Sprint là quá tải — đội không có băng thông cho ngần đó thay đổi song song với công việc giao hàng.
Coach áp hai luật đơn giản:
- Tối đa 2 action mỗi Sprint. Phần còn lại đưa vào một "parking lot" để cân nhắc Sprint sau.
- Mỗi action gán đúng một tên người, viết rõ trên bảng. Người đó đọc to action của mình trước cả đội như một cam kết.
Bài học: "Cả đội chịu trách nhiệm" nghe rất đẹp nhưng trên thực tế là công thức cho sự trì trệ. Một owner cụ thể, cộng với việc giới hạn số lượng để vừa sức, là đòn bẩy lớn nhất.
Tình huống 3 — Đội outsourcing Đà Nẵng: làm action "biến mất" khỏi tầm mắt
Một đội gia công phần mềm ở Đà Nẵng làm dự án cho khách hàng châu Âu. Họ vốn ghi action rất tốt theo SMART, có owner đàng hoàng. Nhưng action vẫn hay rơi rụng. Lý do? Chúng được lưu trong một Confluence page mà sau buổi retro không ai mở lại cho tới buổi sau.
Scrum Master thay đổi nơi sống của action item, không phải cách viết. Anh tạo trên Jira board một cột riêng tên "Retro Actions" và đưa từng action vào đó như một card có owner và due date. Mỗi card xuất hiện ngay trên bảng mà đội nhìn hàng ngày trong Daily Scrum. Thêm nữa, anh dành 60 giây cuối mỗi Daily Scrum để hỏi nhanh: "Có ai cần hỗ trợ gì cho retro action của mình không?"
Chỉ riêng việc kéo action ra khỏi nơi tối tăm và đặt nó vào dòng chảy công việc hàng ngày đã nâng tỷ lệ hoàn thành lên rõ rệt. Khi action ở ngay trước mắt và được nhắc nhẹ nhàng mỗi ngày, nó không còn cơ hội "biến mất".
Bài học: Action item phải hiện diện ở nơi đội nhìn mỗi ngày, không phải ngủ trong một tài liệu. Tích hợp việc theo dõi action vào Daily Scrum là một kỹ thuật rẻ tiền nhưng hiệu quả bất ngờ.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng ngay để xây dựng Action Item Discipline cho đội mình:
Bước 1 — Mở đầu retro bằng việc đóng vòng lặp cũ. Trước khi tạo action mới, dành 5–10 phút xem lại action của Sprint trước. Đánh dấu rõ: Hoàn thành / Đang làm / Chưa làm. Với cái chưa làm, hỏi thẳng (không phán xét): "Điều gì cản chúng ta?" Câu trả lời thường tiết lộ vấn đề sâu hơn.
Bước 2 — Hội tụ về số ít. Sau khi đội khám phá nhiều vấn đề, dùng bỏ phiếu (dot voting chẳng hạn) để chọn 1–3 vấn đề đáng làm nhất Sprint này. Đừng tham lam.
Bước 3 — Viết lại mỗi action theo SMART. Với mỗi action được chọn, đặt câu hỏi kiểm tra: Có cụ thể không? Làm sao biết nó xong? Tuần này làm nổi không? Nó có gỡ đúng nỗi đau không? Hạn chót khi nào? Sửa câu chữ ngay tại chỗ cho tới khi cả đội gật đầu.
Bước 4 — Gán một owner duy nhất. Hỏi: "Ai sẽ đảm bảo việc này xảy ra?" Để người đó tự nguyện nhận thay vì bị chỉ định, cam kết sẽ bền hơn. Ghi tên họ ngay cạnh action.
Bước 5 — Đưa action vào nơi đội nhìn hàng ngày. Tạo card trên board (Jira, Trello, bảng vật lý...), tốt nhất là đưa thành item có trên Sprint Backlog nếu nó tốn công đáng kể. Đừng để action sống ngoài luồng công việc.
Bước 6 — Theo dõi nhẹ trong Sprint. Lồng một câu hỏi nhanh vào Daily Scrum hoặc giữa Sprint: "Retro action tiến tới đâu, ai cần giúp?" Việc này giữ action sống mà không tạo cảm giác bị giám sát.
Bước 7 — Quay lại Bước 1 ở retro kế tiếp. Vòng lặp khép kín. Mỗi lần đội thấy action cũ được làm xong và có tác động, niềm tin vào retro lại lớn thêm một chút.
Lỗi thường gặp & mẹo
Lỗi: Sinh quá nhiều action. Tham lam là kẻ thù. Nếu đội cảm thấy bứt rứt vì phải bỏ qua nhiều vấn đề, hãy lập một "parking lot" để các vấn đề chưa chọn không bị mất — chúng sẽ được cân nhắc ở Sprint sau.
Lỗi: Owner là "cả đội". Như đã thấy ở tình huống fintech, đây là cái bẫy lớn nhất. Luôn quy về một cái tên. Owner điều phối, không nhất thiết tự tay làm hết.
Lỗi: Action không bao giờ được nhìn lại. Nếu retro của bạn không mở đầu bằng việc review action cũ, hãy bắt đầu ngay từ buổi tới. Đây là thay đổi đơn lẻ có tác động lớn nhất.
Lỗi: Action quá to, không khả thi trong một Sprint. Khi gặp vấn đề lớn ("kiến trúc hệ thống cần thiết kế lại"), đừng biến nó thành action retro. Hãy cắt ra một bước đầu tiên nhỏ mà đội tự làm được tuần này, ví dụ "tổ chức 1 buổi spike 2 giờ để phác thảo phương án".
Lỗi: Biến retro thành buổi giao việc khô khan. Discipline không có nghĩa là biến retro thành cuộc họp quản lý task. Vẫn giữ không khí an toàn, cởi mở. Kỷ luật nằm ở phần đuôi — cách action được viết, giao và theo dõi — chứ không bóp nghẹt phần khám phá.
Mẹo: Ăn mừng action hoàn thành. Khi một action xong và tạo tác động, hãy công khai ghi nhận ở retro sau. Điều này củng cố hành vi và cho đội thấy nỗ lực của họ có giá trị.
Mẹo: Nếu cùng một vấn đề lặp lại nhiều Sprint mà action không nhúc nhích, đó là tín hiệu vấn đề nằm ngoài tầm kiểm soát của đội (ví dụ phụ thuộc đội khác, ràng buộc tổ chức). Lúc này vai trò của bạn chuyển sang gỡ rào cản ở cấp cao hơn, thay vì tiếp tục ghi cùng một action vô vọng.
Bài tập thực hành
Bài tập 1 — Chữa action bệnh. Lấy ba action item "bệnh" dưới đây và viết lại từng cái theo SMART, có owner cụ thể:
- "Giao tiếp tốt hơn trong đội."
- "Giảm bug khi release."
- "Họp standup hiệu quả hơn."
Bài tập 2 — Soi lại đội thật của bạn. Mở danh sách action item của 3 Sprint gần nhất của đội bạn (nếu chưa có Scrum Master thật, dùng một đội bạn quan sát được). Đếm: bao nhiêu phần trăm đã thực sự hoàn thành? Với những cái chưa xong, phân loại nguyên nhân theo ba nhóm: Mơ hồ / Vô chủ / Mất tích. Bạn rút ra mẫu hình gì?
Bài tập 3 — Thiết kế cơ chế theo dõi. Đề xuất một cách cụ thể để action item của đội bạn "hiện diện" hàng ngày, phù hợp với công cụ đội đang dùng (Jira, Trello, bảng giấy...). Mô tả: action sẽ sống ở đâu, được nhắc lại vào lúc nào trong nhịp Sprint, và ai chịu trách nhiệm khơi lại.
Bài tập 4 — Kịch bản đóng vòng lặp. Viết ra 4–5 câu bạn sẽ nói để mở đầu buổi retro tiếp theo nhằm review action cũ một cách không phán xét, đặc biệt với những action chưa hoàn thành. Mục tiêu là tạo an toàn để đội nói thật lý do, thay vì biện hộ.
Tóm tắt
Action Item Discipline là chiếc cầu nối giữa "nói" và "làm" trong cải tiến liên tục. Không có nó, mọi công cụ retro tinh xảo nhất cũng chỉ tạo ra những lời hứa suông và dần dần làm đội mất niềm tin vào retro.
Những điểm cốt lõi cần nhớ:
- Action item chỉ là lời hứa — giá trị nằm ở việc thực thi, không phải ở việc viết ra.
- Viết action theo SMART: Cụ thể, Đo được, Khả thi, Liên quan, Có hạn chót.
- Một owner duy nhất cho mỗi action — "cả đội" nghĩa là không ai.
- Giới hạn 1–3 action mỗi Sprint — ít mà làm xong hơn nhiều mà bỏ dở.
- Đưa action vào nơi đội nhìn hàng ngày — board, Sprint Backlog, Daily Scrum — đừng để nó ngủ trong tài liệu.
- Đóng vòng lặp: luôn mở đầu retro bằng việc review action cũ. Đây là hành động tạo niềm tin mạnh nhất.