Menu
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Đang tải...

Bài 14 — Plus / Delta — Simplest retro

Scrum Master Toolbox Bài 14/60

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn là một Scrum Master mới nhận team. Sprint đầu tiên vừa kết thúc, mọi người mệt nhoài sau hai tuần chạy nước rút để kịp demo. Bạn mở lịch và thấy 9 giờ sáng thứ Sáu có một sự kiện tên là "Retrospective", kéo dài 90 phút. Cả team nhìn bạn với ánh mắt vừa hoài nghi vừa cầu cứu: "Anh ơi, mình họp nhanh thôi được không?".

Đây chính là khoảnh khắc bạn cần Plus / Delta.

Plus / Delta là retrospective đơn giản nhất trong toàn bộ hộp đồ nghề của một Scrum Master. Nó chỉ có hai cột, không cần đạo cụ cầu kỳ, không cần chuẩn bị nửa ngày, và có thể chạy gọn trong 15 phút. Nhưng đừng để sự đơn giản đó đánh lừa bạn. Trong rất nhiều bối cảnh thực tế ở Việt Nam — team đang quá tải, văn hoá chưa quen nói thẳng, hay đơn giản là cuối ngày ai cũng muốn về sớm — thì một retro 15 phút mà thực chất còn quý hơn một retro 90 phút mà cả team ngồi nhìn đồng hồ.

Bài này dạy bạn một kỹ năng nền tảng: làm sao để giữ nhịp cải tiến liên tục ngay cả khi không có thời gian, không có công cụ, và không có năng lượng. Plus / Delta là "retro phòng thủ" — thứ bạn luôn có trong túi để không bao giờ phải bỏ một retrospective nào chỉ vì lý do "hôm nay bận quá". Trong dàn bài khoá học này, bạn sẽ học hàng chục kỹ thuật retro công phu hơn (Sailboat, Starfish, Mad/Sad/Glad, 4Ls...), nhưng Plus / Delta là viên gạch đầu tiên, là thứ bạn dùng nhiều nhất và là nơi nhiều người mới bắt đầu hành trình facilitation.

Khái niệm cốt lõi

Plus / Delta là một định dạng phản hồi (feedback format) gồm đúng hai cột, thường được trình bày trên một bảng trắng hoặc một bảng Miro/Mural chia đôi.

Cột Plus (+)

Cột Plus ghi lại những điều đã diễn ra tốt và team muốn tiếp tục duy trì. Đây không chỉ là lời khen suông. Plus có hai vai trò quan trọng:

  • Ghi nhận để bảo tồn: Khi một thực hành tốt được nói ra và viết lên bảng, nó trở nên hữu hình. Team biết rõ "à, cái này đang hiệu quả, đừng bỏ". Nhiều thói quen tốt bị mất đi đơn giản vì không ai nhận ra chúng đang tồn tại.
  • Tạo an toàn tâm lý: Bắt đầu bằng điều tích cực giúp không khí buổi họp nhẹ nhàng, đặc biệt quan trọng với team Việt Nam vốn dễ ngại khi phải "chê" trực diện.

Cột Delta (Δ)

Ký hiệu Δ (delta) trong toán học và khoa học nghĩa là "sự thay đổi", "độ chênh lệch". Đây là điểm tinh tế và là lý do Plus / Delta mạnh hơn vẻ ngoài của nó.

Cột Delta không phải là cột "những điều tệ hại" hay "cột than phiền". Delta là những điều ta muốn thay đổi cho lần tới. Sự khác biệt về ngôn từ này cực kỳ quan trọng:

  • "Minus / Negative" (tiêu cực) hướng người ta vào việc đổ lỗi, phòng thủ, kể tội.
  • "Delta" (thay đổi) hướng người ta vào tương lai và giải pháp.
Khi bạn hỏi "Điều gì tệ ở sprint này?", bạn nhận về sự bức xúc. Khi bạn hỏi "Lần tới ta muốn làm khác đi điều gì?", bạn nhận về đề xuất hành động. Cùng một vấn đề, nhưng khung tư duy hoàn toàn khác. Đây là lý do các facilitator có kinh nghiệm rất kỹ tính trong việc gọi tên cột là "Delta" chứ không phải "Minus".

Triết lý đằng sau

Plus / Delta xuất phát từ văn hoá cải tiến liên tục và được phổ biến rộng trong các môi trường Agile và cả trong giáo dục, huấn luyện. Nguyên lý cốt lõi: một vòng lặp phản hồi nhỏ nhưng đều đặn còn giá trị hơn một vòng lặp lớn nhưng thưa thớt. Thà retro 15 phút mỗi sprint còn hơn retro hoành tráng mỗi quý rồi quên béng cả quý.

So với các kỹ thuật retro phức tạp hơn, Plus / Delta có ưu điểm riêng: tốc độ, tính phổ quát (dùng được cho cả họp, workshop, training, không chỉ sprint), và rào cản tham gia gần như bằng không. Nhược điểm của nó — chiều sâu hạn chế — cũng chính là thứ ta sẽ bàn ở phần "Lỗi thường gặp".

Tình huống thực tế

Tình huống 1 — Team quá tải tại một fintech ở TP.HCM

Công ty Tikop (giả định, một startup fintech khoảng 40 người ở quận 1, TP.HCM) đang trong giai đoạn nước rút trước khi ra mắt tính năng đầu tư quỹ. Team Payment gồm 6 người vừa kết thúc một sprint cực căng. Scrum Master tên Hằng biết rất rõ: nếu cô đề xuất một retro 90 phút với đủ trò chơi, cả team sẽ ngầm phản kháng và ngồi cho có.

Hằng quyết định chạy Plus / Delta trong 18 phút. Cô set stage 2 phút: "Mình biết tuần này ai cũng đuối. Mình làm nhanh thôi, hai cột, mỗi người viết 2 phút rồi mình gom lại." Kết quả thu được:

  • Plus: "Bạn QA test song song với dev nên không bị dồn cuối sprint", "Daily đứng đúng giờ, không lê thê", "Anh PO trả lời câu hỏi trong vòng 1 tiếng".
  • Delta: "Story 'Tích hợp cổng thanh toán' quá to, nên tách nhỏ", "Bị hai lần đổi yêu cầu giữa sprint mà không ai báo trước", "Môi trường staging hay sập, mất 3 tiếng debug oan".
Từ cột Delta, team chốt đúng một hành động: "Sprint tới, mọi thay đổi yêu cầu giữa sprint phải được PO thông báo trong channel #payment trong vòng 1 giờ." Chỉ một hành động, nhưng nó nhắm vào nỗi đau lớn nhất.

Bài học: Plus / Delta cho phép Hằng giữ được kỷ luật cải tiến ngay cả khi team kiệt sức. Cô không cố nhồi nhét — cô chọn đúng một việc khả thi.

Tình huống 2 — Sau một workshop, không phải sprint

Plus / Delta không chỉ dùng cho Sprint Retrospective. Tại một agency phần mềm ở Đà Nẵng, anh Tuấn — một Scrum Master kiêm facilitator — vừa chạy xong buổi workshop Story Mapping kéo dài cả ngày với khách hàng Singapore. 4 giờ chiều, mọi người mệt, nhưng anh dành 10 phút cuối để chạy Plus / Delta về chính buổi workshop đó.

  • Plus: "Có bản đồ trực quan nên khách hiểu nhanh", "Chia nhóm nhỏ thảo luận hiệu quả".
  • Delta: "Buổi sáng thiếu giải lao nên đuối", "Nên gửi tài liệu trước cho khách đọc".
Buổi workshop hôm sau với khách hàng khác, anh Tuấn áp dụng ngay: gửi tài liệu trước, chèn giải lao mỗi 60 phút.

Bài học: Plus / Delta là công cụ "meta" — bạn có thể dùng nó để cải tiến bất kỳ sự kiện nào, kể cả chính cách bạn điều phối. Đây là thói quen vàng của một facilitator chuyên nghiệp: luôn rút kinh nghiệm ngay sau mỗi buổi, khi trí nhớ còn tươi.

Tình huống 3 — Khi sự đơn giản trở thành cái bẫy

Một team tại một công ty outsourcing lớn ở Hà Nội (khoảng 200 nhân sự, tạm gọi là FSoft-style team) đã chạy Plus / Delta suốt 8 sprint liên tiếp. Ban đầu rất tốt. Nhưng đến sprint thứ 6, Scrum Master tên Linh nhận ra một dấu hiệu xấu: cột Delta cứ lặp đi lặp lại "staging không ổn định", "estimate chưa chuẩn" — sprint nào cũng vậy, nhưng chẳng có gì thay đổi.

Vấn đề: Plus / Delta giỏi phát hiện triệu chứng nhưng không giỏi đào sâu gốc rễ. Cùng một Delta xuất hiện 6 lần liên tiếp là tín hiệu cần một công cụ khác. Linh quyết định sprint tới đổi sang Five Whys (sẽ học ở bài sau) để truy nguyên nhân gốc của vấn đề staging, thay vì lại liệt kê nó lần thứ 7.

Bài học: Sự đơn giản của Plus / Delta là điểm mạnh nhưng cũng là giới hạn. Một Scrum Master giỏi biết khi nào nên dùng nó và khi nào nên "nâng cấp" sang công cụ sâu hơn. Plus / Delta là con dao đa năng, không phải con dao mổ.

Hướng dẫn từng bước

Plus / Delta chuẩn chạy trong 15–30 phút. Dưới đây là khung 5 bước.

Bước 1 — Set the stage (2 phút). Mở đầu bằng cách giải thích ngắn gọn mục tiêu và luật chơi. Vẽ hai cột lên bảng: một bên dấu + (Plus), một bên ký hiệu Δ (Delta). Nói rõ định nghĩa: "Plus là điều tốt ta muốn giữ. Delta là điều ta muốn làm khác đi lần tới — không phải để than phiền, mà để cải thiện." Câu này nhỏ nhưng định hình toàn bộ không khí buổi họp. Có thể hỏi nhanh một câu check-in một từ để mọi người "vào nhịp".

Bước 2 — Thu thập ý kiến (5–8 phút). Có hai cách:

  • Cách viết (khuyến nghị): Mỗi người tự viết ý kiến lên sticky note (giấy hoặc số), im lặng trong 3–5 phút. Cách này quan trọng với văn hoá Việt Nam vì nó cho người hướng nội và người ít thâm niên cơ hội đóng góp mà không bị "lép vế" trước người nói nhiều.
  • Cách nói: Đi vòng quanh, mỗi người nêu một Plus và một Delta. Nhanh hơn nhưng dễ bị chi phối bởi người mạnh tiếng.
Bước 3 — Nhóm và làm rõ (3–5 phút). Gom các note giống nhau lại. Đọc to từng cụm, hỏi người viết làm rõ nếu cần. Đừng tranh luận đúng/sai ở bước này — chỉ làm rõ để cả team hiểu chung.

Bước 4 — Chọn hành động (3–5 phút). Đây là bước nhiều người bỏ qua và đó là sai lầm chí mạng. Từ cột Delta, hãy hỏi: "Trong các Delta này, ta chọn một đến hai điều để hành động ngay sprint tới?" Dùng dot voting (mỗi người 1–2 chấm) nếu cần. Chốt hành động phải cụ thể: ai làm, làm gì, đến khi nào. "Cải thiện staging" không phải hành động. "Bạn Nam dựng cảnh báo khi staging sập, xong trước thứ Tư" mới là hành động.

Bước 5 — Đóng buổi (1–2 phút). Đọc lại hành động đã chốt, xác nhận người chịu trách nhiệm. Cảm ơn team. Chụp lại bảng để lần sau đối chiếu. Lần retro sau, bắt đầu bằng việc kiểm tra hành động kỳ trước có làm được không — điều này tạo trách nhiệm giải trình.

Lỗi thường gặp & mẹo

Lỗi 1 — Biến Delta thành phiên than phiền. Khi facilitator để cột Delta trượt thành "kể tội", buổi họp trở nên độc hại. Mẹo: Luôn gọi tên là "Delta", luôn đóng khung bằng câu hỏi hướng tương lai "Ta muốn làm khác đi điều gì?", và chuyển ngay mọi lời phàn nàn thành đề xuất hành động.

Lỗi 2 — Không chốt hành động. Liệt kê xong rồi giải tán là retro vô nghĩa. Sprint sau Delta y nguyên. Mẹo: Bắt buộc có bước chọn hành động. Thà chốt một hành động và làm được, còn hơn năm hành động rồi quên hết. Kỷ luật hành động sẽ được học sâu ở bài riêng, nhưng nguyên tắc tối thiểu: mỗi retro ra ít nhất một việc làm được.

Lỗi 3 — Dùng Plus / Delta mãi mãi. Như tình huống 3, lặp lại một định dạng quá lâu khiến team chán và bỏ sót gốc rễ. Mẹo: Luân phiên định dạng. Dùng Plus / Delta khi cần nhanh, đổi sang kỹ thuật khác khi cần sâu hoặc khi team mất hứng.

Lỗi 4 — Cột Plus bị bỏ lơ. Nhiều SM lao thẳng vào Delta, coi Plus là thủ tục. Hậu quả: team chỉ nhớ điều xấu, mất động lực. Mẹo: Dành thời gian thật cho Plus. Ghi nhận công khai là một dạng phần thưởng tinh thần rất rẻ mà hiệu quả.

Lỗi 5 — Facilitator áp đặt ý kiến. Khi SM cũng là người nêu nhiều Delta nhất, team sẽ im lặng dựa dẫm. Mẹo: Giữ vai trung lập. Bạn điều phối quá trình, không phải người phán xét nội dung.

Mẹo cho team phân tán/remote: Dùng bảng số (Miro, Mural, hoặc đơn giản là một file chia hai cột). Cho viết đồng thời để tiết kiệm thời gian. Bật timer hiển thị để giữ nhịp.

Mẹo văn hoá Việt Nam: Ưu tiên cách viết im lặng thay vì nói vòng tròn, để giảm rào cản thứ bậc và giúp người mới, người ít nói dám đóng góp. Một câu mở đầu chân thành của SM ("mình muốn nghe thật, không ai bị đánh giá") tạo khác biệt lớn về độ thẳng thắn.

Bài tập thực hành

  • Chạy thử với chính buổi học này. Lấy một tờ giấy, kẻ hai cột + và Δ. Viết 2 Plus và 2 Delta về cách bạn đang học khoá này. Từ cột Delta, chọn đúng một điều bạn sẽ thay đổi ở bài tiếp theo. Đây là cách nhanh nhất để cảm nhận sức mạnh của định dạng.
  • Thiết kế kịch bản 15 phút. Giả sử team bạn vừa xong một sprint căng thẳng và chỉ có 15 phút. Viết ra timeline chi tiết của bạn: phút nào làm gì, bạn sẽ nói câu mở đầu (set the stage) như thế nào? Đặc biệt soạn sẵn câu nói để định nghĩa Delta sao cho không bị hiểu thành "than phiền".
  • Phân biệt Delta và Minus. Cho ba câu sau, viết lại theo khung Delta hướng tương lai: (a) "QA làm chậm quá"; (b) "Họp daily lê thê chán chết"; (c) "PO đổi yêu cầu liên tục". Mục tiêu: biến lời chê thành đề xuất thay đổi cụ thể.
  • Nhận diện thời điểm nâng cấp. Hãy viết ra ba dấu hiệu cho thấy team bạn nên ngừng dùng Plus / Delta và chuyển sang một kỹ thuật retro sâu hơn. (Gợi ý: nghĩ về tình huống 3.)

Tóm tắt

Plus / Delta là retrospective đơn giản nhất và cũng là công cụ phòng thủ đáng tin cậy nhất trong hộp đồ nghề của bạn. Hai cột: Plus (+) cho điều tốt cần giữ, Delta (Δ) cho điều muốn thay đổi lần tới — chú ý là "thay đổi", không phải "tiêu cực". Nó chạy gọn trong 15–30 phút, không cần đạo cụ, dùng được cho cả sprint, workshop lẫn để tự soi cách bạn điều phối.

Sức mạnh thật sự của nó nằm ở khả năng giữ nhịp cải tiến liên tục ngay cả khi team quá tải, không có thời gian, hoặc văn hoá chưa quen nói thẳng. Nhưng hãy nhớ ba điều: luôn chốt ít nhất một hành động cụ thể, đừng để Delta thành phiên than phiền, và đừng dùng mãi một định dạng đến mức team mất hứng hay bỏ sót gốc rễ. Khi cùng một Delta lặp lại nhiều sprint, đó là tín hiệu nâng cấp sang công cụ sâu hơn.

Nắm vững Plus / Delta nghĩa là bạn không bao giờ có lý do để bỏ một retrospective nào. Và một Scrum Master không bao giờ bỏ cải tiến chính là một Scrum Master mà team sẽ tin tưởng.