Mở đầu — vì sao bài này quan trọng
Nếu bạn đã từng chạy một buổi retrospective theo kiểu "What went well / What didn't go well", chắc bạn quen với cảm giác này: team chia mọi thứ thành hai cột trắng-đen — tốt hoặc xấu. Nhưng thực tế công việc của một nhóm Scrum hiếm khi đơn giản như vậy. Có những việc tốt mà team muốn làm nhiều hơn nữa. Có những việc không hề xấu, nhưng đang làm quá tay và tốn năng lượng. Có những thói quen rõ ràng gây hại và cần dừng hẳn. Một bảng hai cột không đủ chỗ cho những sắc thái đó.
Đây chính là lý do Starfish Retrospective (Retro Sao Biển) ra đời. Được Patrick Kua giới thiệu, Starfish dùng hình ảnh một con sao biển năm cánh để chia phản hồi của team thành năm mức độ thay vì hai. Năm cánh đó cho phép team nói chính xác hơn rất nhiều về cường độ họ muốn thay đổi mỗi việc — không chỉ "giữ hay bỏ" mà còn "làm nhiều hơn, làm ít đi, hay bắt đầu cái mới".
Trong bộ công cụ của Scrum Master, Starfish là một định dạng retrospective bạn nên thuộc nằm lòng. Nó đặc biệt mạnh khi team đã chạy retro được vài sprint, đã quá quen với format đơn giản và bắt đầu trả lời qua loa. Việc thêm sắc thái buộc mọi người suy nghĩ sâu hơn, và bài học hôm nay sẽ giúp bạn facilitate nó một cách thuần thục. Lưu ý: Bài 9 đã nói về Sailboat, Bài 11 sẽ nói về Mad/Sad/Glad — Starfish khác biệt ở chỗ nó tập trung vào cường độ điều chỉnh hành vi, đó là phần riêng của bài này.
Khái niệm cốt lõi
Năm cánh sao biển
Starfish chia mọi quan sát của team về sprint vừa qua thành năm vùng. Hãy hình dung một con sao biển vẽ giữa bảng, mỗi cánh là một vùng để dán sticky note:
- Keep doing (Tiếp tục giữ) — những việc đang chạy tốt với mức độ vừa phải. Không cần tăng, không cần giảm, chỉ cần duy trì. Ví dụ: "Daily Scrum của mình bắt đầu đúng giờ", "code review luôn xong trong ngày".
- More of (Làm nhiều hơn) — những việc tốt mà team muốn tăng cường. Đây không phải việc mới, mà là việc đã có nhưng còn ít, làm thêm sẽ có lợi. Ví dụ: "pair programming giúp ích, mình muốn làm nhiều hơn".
- Less of (Làm ít đi) — những việc không hẳn xấu nhưng đang chiếm quá nhiều thời gian hoặc năng lượng so với giá trị mang lại. Đây là cánh tinh tế nhất. Ví dụ: "họp căn chỉnh kế hoạch hữu ích nhưng đang quá dài".
- Start doing (Bắt đầu làm) — những việc mới mà team chưa làm và muốn thử. Đây là nguồn ý tưởng cải tiến. Ví dụ: "thử viết test trước khi code".
- Stop doing (Dừng hẳn) — những việc gây hại thực sự, không mang lại giá trị và cần loại bỏ. Ví dụ: "ngừng việc ngắt ngang giữa sprint bằng task gấp không qua backlog".
Vì sao năm cánh tốt hơn hai cột
Sức mạnh của Starfish nằm ở chỗ nó tách biệt cường độ thay vì chỉ phân loại tốt/xấu. Hãy lấy ví dụ "họp kế hoạch sprint". Trong format hai cột, nó sẽ rơi vào "tốt" (vì cần thiết) hoặc "xấu" (vì dài lê thê) — và team phải tranh cãi để quyết nó thuộc cột nào. Với Starfish, câu trả lời rõ ràng: nó thuộc cánh Less of — việc đúng, nhưng đang làm quá. Sự phân biệt này giúp team không vứt bỏ cả việc tốt chỉ vì một phần của nó đang quá tải.
Một điểm tinh tế nữa: hai cánh More of và Less of thừa nhận rằng cải tiến hiếm khi là bật/tắt. Phần lớn việc cải thiện một nhóm trưởng thành là điều chỉnh liều lượng — vặn lớn cái này một chút, vặn nhỏ cái kia một chút. Starfish là công cụ duy nhất trong các format retro phổ biến diễn đạt trực tiếp được ý "liều lượng" này.
Khi nào nên dùng Starfish
Starfish hợp nhất với:
- Team đã chạy Scrum được vài sprint và đã thuần thục các process cơ bản — họ có đủ chất liệu để nói về "nhiều hơn / ít đi".
- Khi bạn cảm thấy team đang trả lời retro hời hợt vì format quá quen.
- Khi muốn nhìn vào việc tinh chỉnh thực hành hơn là khủng hoảng lớn.
Tình huống thực tế
Ví dụ 1 — Tiki: gỡ "tắc nghẽn" ở cánh Less of
Một nhóm 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 (gọi là nhóm Catalog, tương tự bối cảnh Tiki) chạy retro suốt 6 sprint với format "Went well / Didn't go well". Mỗi lần "code review" đều xuất hiện ở cả hai cột: tốt vì bắt được bug, xấu vì làm task kẹt 2-3 ngày chờ duyệt. Team tranh cãi vòng vo mà không ra hành động.
Scrum Master chuyển sang Starfish ở sprint thứ 7. Lần này "code review" được dán thẳng vào cánh Less of — kèm ghi chú "ít vòng review hơn, ít đòi hỏi nitpick về style hơn". Bên cạnh đó, "review trong ngày" được dán vào Keep doing. Sự tách bạch giúp team thấy rõ: họ không muốn bỏ review, họ muốn giảm ma sát của nó. Hành động cụ thể đưa ra: bật linter tự động để máy lo phần style, và quy ước tối đa 1 vòng review cho task dưới 3 story point. Sau 2 sprint, thời gian trung bình một task nằm chờ review giảm từ 1,8 ngày xuống còn 0,6 ngày.
Bài học: Cánh Less of là nơi "vàng" của Starfish. Nó cho team một chỗ để nói "việc này tốt nhưng đang quá tay" mà không phải lên án nó là việc xấu.
Ví dụ 2 — Startup fintech Singapore: cánh More of khơi đúng động lực
Một startup fintech khoảng 25 người ở Singapore có một nhóm backend 6 thành viên đang trong giai đoạn mệt mỏi. Các buổi retro gần đây toàn nói về vấn đề, không khí nặng nề, tinh thần đi xuống. Scrum Master quyết định dùng Starfish nhưng cố ý dành nhiều thời gian cho cánh More of và Keep doing trước.
Khi được hỏi "việc gì đang tốt mà các bạn muốn làm nhiều hơn?", team bừng lên. Họ nhắc đến buổi "demo nội bộ thứ Sáu" mà ai cũng thích nhưng gần đây bị cắt vì bận; "pair khi gỡ bug khó" giúp họ học nhanh; "viết một dòng tóm tắt quyết định kỹ thuật vào wiki". Cả ba được dán vào More of, và team cam kết khôi phục demo thứ Sáu. Phần Less of/Stop chỉ có hai mục, được xử lý nhanh gọn.
Kết quả là buổi retro chuyển từ "danh sách than phiền" thành "danh sách nuôi dưỡng những gì đang hoạt động". Điểm health check tự đánh giá của team (thang 1-5) tăng từ 2,8 lên 3,6 sau ba sprint.
Bài học: Starfish có sẵn cấu trúc để cân bằng cảm xúc — ba cánh thiên về tích cực (Keep, More, Start) và hai cánh thiên về điều chỉnh (Less, Stop). Một Scrum Master khéo léo dùng tỉ lệ này để điều hướng năng lượng buổi retro.
Ví dụ 3 — Nhóm outsourcing Đà Nẵng: tránh bẫy "Stop = đổ lỗi"
Một công ty outsourcing ở Đà Nẵng có nhóm 8 người làm dự án cho khách Nhật. Lần đầu chạy Starfish, cánh Stop doing ngập sticky note kiểu "ngừng việc anh A hay quên cập nhật task", "ngừng để chị B nghỉ giữa sprint". Buổi retro biến thành màn chỉ trích cá nhân, hai thành viên im lặng tới cuối.
Scrum Master nhận ra sai lầm và sprint sau đặt lại luật: Stop doing chỉ nói về hành vi và quy trình, không nói về con người. Cô đổi cách diễn đạt mẫu — thay vì "ngừng việc anh A quên update", viết "ngừng tình trạng task không phản ánh đúng tiến độ trên board". Cùng vấn đề, nhưng hướng vào hệ thống. Không khí dịu hẳn, và team tìm ra giải pháp chung: thêm 1 phút cập nhật board cuối Daily Scrum.
Bài học: Cánh Stop doing dễ trở thành nơi đổ lỗi nhất. Scrum Master phải đặt ground rule rõ ràng và làm mẫu cách viết hướng vào hệ thống thay vì cá nhân.
Hướng dẫn từng bước
Dưới đây là quy trình chạy một buổi Starfish Retrospective khoảng 60 phút cho team 5-9 người.
Bước 1 — Chuẩn bị bảng (trước buổi). Vẽ một ngôi sao biển năm cánh ở giữa bảng (vật lý hoặc công cụ online như Miro, Mural, FigJam). Ghi rõ nhãn từng cánh: Keep doing, More of, Less of, Start doing, Stop doing. Chuẩn bị sẵn sticky note và bút, hoặc mở sẵn board cho team từ xa.
Bước 2 — Mở đầu và set the stage (5 phút). Chào team, nhắc lại Prime Directive (giả định mọi người đã làm tốt nhất trong hoàn cảnh của họ). Giải thích ngắn năm cánh, nhấn mạnh sự khác nhau giữa More/Less (điều chỉnh việc đã có) và Start/Stop (việc mới hoặc bỏ hẳn). Đây là phần hay bị bỏ qua nhưng quyết định chất lượng cả buổi.
Bước 3 — Brainstorm im lặng (8-10 phút). Mỗi người tự viết sticky note cho từng cánh, mỗi ý một note. Viết im lặng để tránh người nói to lấn át. Khuyến khích mỗi người có ít nhất một note ở cánh More of và Less of — đây là hai cánh thường bị bỏ trống nhưng giàu giá trị nhất.
Bước 4 — Dán và gom nhóm (8 phút). Mọi người dán note lên đúng cánh. Scrum Master gom các note giống nhau lại thành cụm. Đọc to từng cụm để cả team cùng nắm.
Bước 5 — Thảo luận theo độ ưu tiên (15-20 phút). Đừng cố bàn hết mọi note. Cho team dot-voting (mỗi người 3 điểm) để chọn 2-3 chủ đề đáng bàn nhất. Thường các cánh Less of và Stop doing thu hút nhiều phiếu vì chúng chạm vào điểm đau. Đào sâu từng chủ đề được chọn: vì sao xảy ra, ảnh hưởng thế nào.
Bước 6 — Chốt action item (8-10 phút). Với mỗi chủ đề ưu tiên, biến nó thành hành động cụ thể: ai làm, làm gì, khi nào kiểm tra. Giới hạn 2-3 action để team thực sự làm nổi. Một action tốt phải đo được — ví dụ "giảm tối đa 1 vòng review cho task nhỏ" thay vì "review nhanh hơn".
Bước 7 — Đóng buổi (3 phút). Tóm tắt action, xác nhận người chịu trách nhiệm, và làm một vòng check-out ngắn ("một từ mô tả cảm giác của bạn về buổi này").
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm lẫn giữa các cánh. Team hay phân vân note nên vào More of hay Start doing. Mẹo: hỏi "việc này mình đã làm chưa?" Nếu đã làm rồi mà muốn tăng → More of. Nếu chưa làm bao giờ → Start doing. Tương tự với Less of (đã làm, giảm bớt) và Stop doing (bỏ hẳn).
Lỗi 2 — Bỏ trống cánh More of và Less of. Đây là hai cánh tạo nên giá trị riêng của Starfish, nhưng cũng khó nghĩ nhất nên hay bị bỏ qua. Mẹo: facilitate riêng từng cánh này bằng câu hỏi gợi mở — "Có việc nào đang tốt mà ước gì làm được nhiều hơn?" và "Có việc nào hữu ích nhưng đang ngốn quá nhiều thời gian?".
Lỗi 3 — Biến Stop doing thành nơi đổ lỗi. Như ví dụ Đà Nẵng. Mẹo: đặt ground rule "nói về hệ thống, không nói về người", và tự bạn làm mẫu cách viết lại note hướng vào quy trình.
Lỗi 4 — Ôm đồm quá nhiều action. Bảng đầy note tạo cảm giác phải xử lý hết. Mẹo: thẳng thắn chốt tối đa 2-3 action. Note còn lại có thể đưa vào board để xem lại sprint sau.
Lỗi 5 — Dùng Starfish mãi không đổi. Bản thân Starfish cũng sẽ cũ nếu lặp lại nhiều lần. Mẹo: xen kẽ với các format khác trong khóa học này (Sailboat, 4Ls, Mad/Sad/Glad) để giữ sự tươi mới.
Mẹo cho team remote: Trên Miro/Mural, dùng timer hiển thị cho mỗi giai đoạn brainstorm, bật chế độ ẩn note của người khác trong lúc viết để tránh bị ảnh hưởng, và dùng tính năng voting có sẵn cho bước ưu tiên.
Bài tập thực hành
Bài tập 1 — Phân loại đúng cánh. Cho 6 quan sát sau, hãy xác định mỗi cái thuộc cánh nào của Starfish và giải thích lý do:
- "Daily Scrum đang vào nề nếp, đúng giờ."
- "Pair programming khi gặp bug khó rất hiệu quả, mình mới làm vài lần."
- "Họp refinement đang kéo dài hơn 2 tiếng."
- "Chưa bao giờ thử viết test trước khi code."
- "Có những task gấp được nhét vào giữa sprint không qua backlog."
- "Mình hay cập nhật wiki kỹ thuật, thấy ổn, cứ vậy duy trì."
Bài tập 2 — Viết lại note "đổ lỗi". Hãy viết lại ba note sau theo hướng tập trung vào hệ thống thay vì cá nhân:
- "Ngừng việc anh Tuấn luôn merge code chưa review."
- "Ngừng để chị Lan trả lời tin nhắn khách quá chậm."
- "Ngừng việc bạn QA bỏ sót test case."
Tóm tắt
Starfish Retrospective là một định dạng năm cánh — Keep doing, More of, Less of, Start doing, Stop doing — giúp team diễn đạt cường độ họ muốn điều chỉnh từng việc, thay vì chỉ phân loại tốt/xấu như format hai cột. Sức mạnh thật sự của nó nằm ở hai cánh More of và Less of: chúng thừa nhận rằng cải tiến của một nhóm trưởng thành phần lớn là chuyện vặn liều lượng, không phải bật/tắt.
Hãy nhớ ba điều quan trọng nhất từ bài này. Thứ nhất, phân biệt rõ "đã làm rồi, điều chỉnh" (More/Less) với "việc mới hoặc bỏ hẳn" (Start/Stop) — đó là chìa khóa giúp team dán note đúng chỗ. Thứ hai, cánh Less of là nơi quý giá nhất, cho team chỗ để nói "việc này tốt nhưng đang quá tay". Thứ ba, cánh Stop doing dễ thành nơi đổ lỗi, nên luôn đặt ground rule hướng vào hệ thống và làm mẫu cách viết. Cuối cùng, đừng ôm đồm — chốt 2-3 action đo được và thực sự theo đuổi chúng ở sprint sau. Đó mới là điều biến một buổi retro hay thành một team tiến bộ thật.