Những tờ sticky note vẫn còn trên tường phòng họp khi mọi người bước ra ngoài. Có tờ được viết rất cẩn thận, có tờ viết vội, và một tờ có vệt cà phê nhỏ ở góc. Cái board nhìn khá thật: quá nhiều work in progress, ownership của review chưa rõ, câu trả lời từ product đến muộn, và release checklist chỉ được tin khi có người nhắc lại hai lần. Trong một khoảnh khắc, team đã gọi tên đúng ma sát. Câu hỏi khó hơn là tuần sau có gì khác đi không.
Đây là chỗ nhiều buổi retrospective thất bại rất lặng. Không phải vì mọi người hời hợt, và cũng không phải vì format sai. Nó thất bại vì meeting tạo ra cảm giác nhẹ người nhưng không tạo ra bước tiếp theo. Ai cũng thấy tốt hơn một chút vì đã được nói. Sticky note được gom nhóm. Facilitator cảm ơn cả phòng. Rồi thứ Hai đến, áp lực cũ quay lại, và retro trở thành thêm một nơi team học cách thành thật mà không còn kỳ vọng thay đổi.
Một retrospective hữu ích nên có tham vọng nhỏ hơn nhưng trí nhớ mạnh hơn. Nó không cố sửa cả hệ thống trong một giờ. Nó chọn một hành vi team có thể đổi, giao cho một người owns phần follow-up, ghi lại decision ở nơi team sẽ nhìn thấy lại, và kiểm tra xem hành vi đó có thật sự dịch chuyển không. Thay đổi có thể rất nhỏ: review pull request cũ nhất trước khi mở việc mới, hỏi product question trước buổi trưa, mỗi tuần có một người owns release checklist, hoặc tạm dừng intake khi QA đã quá tải.
Nhỏ là điều quan trọng. Action item quá lớn thường nghe trưởng thành nhưng biến mất rất nhanh vì không ai cầm nổi. Cải thiện communication. Giảm technical debt. Làm estimation tốt hơn. Những vấn đề đó có thể thật, nhưng chúng quá rộng để sống sót qua một ngày bận. Một action tốt nên giống experiment hơn: trong hai tuần tới, mỗi story trước khi vào development phải có một product decision owner và một ví dụ về edge case team lo nhất. Nó đủ cụ thể để thử và đủ nhỏ để inspect.
Từ experiment cũng bảo vệ trust. Khi một action được nói như luật vĩnh viễn, mọi người dễ phòng thủ hoặc lo rằng retro đang biến thành phiên xét xử. Khi nó được nói như một thử nghiệm ngắn, team có thể học mà không cần mọi người đồng ý mãi mãi. Mình không nói đây là process hoàn hảo. Mình chỉ nói nỗi đau hiện tại đáng để thử một hành vi khác trong hai tuần.
Trust là chất liệu nằm dưới toàn bộ chuyện này. Một team có thể dùng Start, Stop, Continue hoặc Mad, Sad, Glad mà vẫn né sự thật nếu nói thẳng không an toàn. Mọi người cần biết rằng gọi tên một vấn đề sẽ không biến thành blame, đánh giá performance, hay lời phàn nàn riêng về một cá nhân. Việc của facilitator một phần là giữ ranh giới đó. Hãy nói về system, handoff, decision path, queue, tín hiệu bị thiếu. Nếu có một người liên quan, hãy gọi tên hành vi và context cẩn thận thay vì biến retro thành một phiên xử.
Ownership là ranh giới tiếp theo. Một retro action không có owner thường chỉ là một hy vọng. Owner không cần tự giải quyết mọi thứ. Họ chịu trách nhiệm làm phần kiểm tra tiếp theo trở nên nhìn thấy được: cập nhật decision record, hỏi experiment có diễn ra không, mang kết quả quay lại retro sau, và nói rõ khi action cần thêm hỗ trợ. Ownership cho thay đổi một chỗ để sống sau khi meeting kết thúc.
Decision record hữu ích vì trí nhớ rất yếu khi delivery pressure tăng lên. Một ghi chú ngắn là đủ: team đã thấy nỗi đau gì, chọn experiment nào, ai owns follow-up, khi nào review lại, và tín hiệu nào cho thấy nó có tác dụng. Không cần template nặng. Nó có thể là một trang wiki, một comment được pin trên board, hoặc một dòng trong sprint note. Điều quan trọng là retro tiếp theo có thể bắt đầu bằng việc nhìn lại commitment cũ thay vì bắt đầu từ một bức tường trống.
Measurement nên khiêm tốn và dùng được. Không phải cải tiến nào cũng cần dashboard. Đôi khi chỉ cần xem pull request quá hai ngày đã giảm từ sáu xuống hai chưa. Đôi khi là product question có được trả lời trước khi implementation bắt đầu không. Đôi khi là support handoff note có còn bị trả lại vì thiếu cùng một field nữa không. Measure nên mô tả hành vi, không chỉ mô tả cảm xúc. Cảm thấy tốt hơn là điều đáng quý, nhưng hành vi đổi mới là thứ bảo vệ team khi tuần làm việc bận lại.
Cũng cần một chút can đảm để đóng những action cũ. Nếu experiment không hiệu quả, team nên nói được điều đó mà không xấu hổ. Có thể owner không có authority. Có thể tín hiệu đo sai. Có thể nỗi đau thật nhưng action được chọn quá gián tiếp. Đó vẫn là học. Pattern không lành mạnh không phải là experiment thất bại; pattern không lành mạnh là giữ một action thất bại còn sống chỉ vì không ai muốn thừa nhận nó đã thành vật trang trí.
Một retrospective tạo ra thay đổi thường ít kịch tính hơn mình tưởng. Có thể không có khoảnh khắc workshop thật lớn, không có root cause hoàn hảo, cũng không có bài phát biểu truyền cảm hứng. Chỉ có một team đang cụ thể hơn một chút về chính cách làm việc của mình: hành vi này đang làm mình đau, hành vi nhỏ hơn kia có thể giúp, người này sẽ giữ nó visible, ghi chú này lưu lại decision, và tín hiệu này cho biết thay đổi có sống được trong delivery thật hay không.
Lần tới khi retro kết thúc với một bức tường đầy note, hãy thử hỏi một câu bình tĩnh trước khi mọi người rời phòng: tuần sau người khác có thể quan sát điều gì để biết meeting này có ý nghĩa? Câu trả lời không cần lớn. Nó chỉ cần nhìn thấy được. Nếu team của bạn từng có một thói quen retro nhỏ nhưng thật sự đổi cách công việc diễn ra sau đó, tôi rất muốn nghe điều gì đã làm nó ở lại.