Sprint Retrospective

Buổi này dễ thành nơi mọi người thay nhau nói "sprint vừa rồi ổn mà" rồi giải tán sớm mười lăm phút. Ổn thật thì tốt, nhưng ba sprint liền đều ổn thì thường là không ai muốn nói. Retrospective diễn ra sau Sprint Review và trước Sprint Planning kế tiếp, nhìn vào cách team làm ra sản phẩm chứ không nhìn vào bản thân sản phẩm.

Scrum Guide 2020 nêu đầu ra thế này: team chọn những cải tiến có tác động lớn nhất và xử lý chúng sớm nhất có thể, thậm chí có thể đưa thẳng vào Sprint Backlog của sprint kế tiếp. Chỗ này rất hay bị trích sai. Bản 2017 từng bắt buộc phải nhét ít nhất một cải tiến vào Sprint Backlog, bản 2020 đã gỡ ràng buộc đó, nên đừng đem nó ra làm luật với team. Nhưng nếu bạn hỏi mình, cách chắc chắn nhất để một cải tiến không nằm chết trong biên bản vẫn là biến nó thành một item có người đứng tên.

Retro mà không có gì thay đổi ở sprint sau thì đó chỉ là buổi than thở có tổ chức.

Timebox và thành phần

Thành phần: chỉ Scrum Team. Không mời quản lý cấp trên, không mời khách hàng. Đây là chỗ duy nhất trong Scrum mà mọi người được nói thẳng về việc mình làm chưa tốt, và sự có mặt của một người có quyền đánh giá lương thưởng sẽ dập tắt điều đó trong ba phút.

Vài định dạng dễ dùng

Đổi định dạng vài sprint một lần, dùng mãi một kiểu thì đến sprint thứ sáu ai cũng trả lời cho xong.

• Start / Stop / Continue. Đơn giản nhất, hợp team mới.
• Mad / Sad / Glad. Chạm được vào cảm xúc, hợp khi team đang căng.
• 4Ls: Liked, Learned, Lacked, Longed for. Cân bằng, hợp team đã quen retro.
• Thuyền buồm. Gió đẩy đi, mỏ neo kéo lại, đá ngầm phía trước. Hợp khi cần nhìn cả rủi ro sắp tới.
• Retro theo số liệu. Mở burndown, số bug production, cycle time ra rồi mới hỏi vì sao. Hợp team đã chín, tránh được kiểu bàn cảm tính.

Câu mở đầu nên nhắc Prime Directive của Norman Kerth: giả định rằng ai cũng đã làm tốt nhất có thể với thông tin và nguồn lực họ có lúc đó. Nghe hơi sách vở, nhưng nó đặt được cái tông cho cả buổi.

Ví dụ thực tế

Ba kỳ retro liên tiếp, tờ giấy dán trên bảng của một team kho vận đều có đúng một dòng: "review code chậm". Và cả ba lần đều không có hành động nào đi kèm.

Sprint thứ tư, Scrum Master đổi cách: thay vì hỏi cảm nhận, kéo số liệu ra. Trung bình một pull request nằm chờ 2,3 ngày mới có người review, trong khi thời gian code thực tế chỉ 1,5 ngày. Con số đó làm cả team im lặng vài giây.

Hành động đưa ra rất nhỏ: mỗi sáng sau Daily, ai có pull request chờ trên 4 tiếng thì nói tên ra; hai dev senior tự nhận khung 9 đến 10 giờ dành riêng cho review. Đưa thành một task trong Sprint Backlog sprint sau, có người phụ trách. Sau ba sprint, thời gian chờ review xuống còn khoảng 0,6 ngày.

Cải tiến ăn thua thường nhỏ và cụ thể cỡ đó, chứ hiếm khi là câu "cả team cần giao tiếp tốt hơn".

Lỗi hay gặp

Hai kiểu hỏng nặng nhất nằm ở hai đầu đối nhau. Một đầu là buổi kể tội: mọi phát biểu đều quy về một người hoặc một bộ phận, chữa bằng cách bắt buộc nói ở dạng sự việc và tác động, không nêu tên. Đầu kia là buổi ai cũng gật đã nói ở trên, và nó thường tới từ việc team không tin nói ra thì có gì đổi, hoặc từ việc có một người cầm quyền đánh giá ngồi trong phòng.

Ba lỗi còn lại nằm ở phần sau buổi họp:

• Action item không có chủ. Ghi "cải thiện tài liệu" mà không ai đứng tên, không hạn chót.
• Ra 8 hành động một lúc. Chọn tối đa 2, làm cho xong, rồi mới thêm.
• Bỏ retro vì bận. Sprint càng gấp càng cần, vì bỏ nó là team mất cách duy nhất để tự sửa mình.

Mẹo khi đi làm

Mở đầu mỗi retro bằng việc đọc lại hành động của sprint trước và hỏi thẳng: làm chưa, kết quả ra sao. Chỉ riêng thói quen này đã thay đổi hẳn thái độ của team, vì mọi người biết cái mình nói ra sẽ được kiểm tra lại.

Nếu team ngại nói thành lời, cho viết ẩn danh trên bảng chung 5 phút đầu rồi mới bàn. Với team Việt Nam mới làm quen retro, cách này thường mở được cái khóa đầu tiên.