Retrospective tuần nào cũng ra một danh sách giống hệt: biến buổi nhìn lại thành cải tiến thật

Tình huống minh hoạ

Tình huống dưới đây là giả định, dùng để minh hoạ.

Một đội Scrum 8 người phát triển hệ thống quản lý kho cho công ty logistics, sprint hai tuần. Scrum Master mới nhận việc, anh Long, đọc lại biên bản 8 buổi Sprint Retrospective gần nhất và nhận thấy:

• Ba vấn đề lặp lại ở cả 8 buổi: môi trường kiểm thử chậm và hay sập; yêu cầu bị đổi giữa sprint; build tự động mất 50 phút.
• Tổng cộng 22 hành động cải tiến được ghi lại, chỉ 3 được thực hiện xong.
• Buổi retrospective luôn theo đúng một khuôn "Tốt / Chưa tốt / Hành động", kéo dài 30 phút, thường bị cắt ngắn vì sprint review kéo dài.
• Trưởng phòng phát triển thường ngồi dự; khi có mặt ông, đội chủ yếu nói về công cụ, không ai nhắc tới việc ông hay giao việc gấp trực tiếp cho thành viên.

Một thành viên nói thẳng: "Retro chỉ là buổi than phiền định kỳ, có thay đổi gì đâu."

Phân tích theo PMBOK® Guide / Agile Practice Guide

Mục đích của retrospective

Scrum Guide 2020 nêu mục đích của Sprint Retrospective là lập kế hoạch tăng chất lượng và hiệu quả; đội xem xét con người, tương tác, quy trình, công cụ và Definition of Done. Retrospective có timebox tối đa 3 giờ cho sprint một tháng (sprint ngắn hơn thường ngắn hơn). Điểm hay bị bỏ qua: các cải tiến có tác động lớn nhất nên được xử lý càng sớm càng tốt và có thể đưa vào Sprint Backlog của sprint tiếp theo.

Agile Alliance liệt kê các cạm bẫy thường gặp: buổi retrospective biến thành cuộc than phiền hay tranh cãi; thiếu sự an toàn để mọi người dám nói (sự hiện diện của cấp quản lý có thể kìm hãm thảo luận); có quá ít hoặc quá nhiều hành động — thường chỉ một hai hành động mỗi chu kỳ là đủ; và nghi thức trở nên rỗng khi cùng một vấn đề cứ lặp lại mà không được giải quyết.

Vấn đề của đội và vấn đề của hệ thống

Không phải vấn đề nào cũng nằm trong tầm tay đội. Large-Scale Scrum (LeSS) có một sự kiện riêng là Overall Retrospective, nơi Product Owner, Scrum Master, đại diện các đội và quản lý cùng xử lý vấn đề liên đội, tổ chức và hệ thống, thường dùng sơ đồ nhân quả (cause-effect diagram) để tìm nguyên nhân gốc. Dù đội không áp dụng LeSS, ý tưởng này hữu ích: môi trường kiểm thử thuộc phòng hạ tầng, yêu cầu đổi giữa sprint liên quan tới cách các stakeholder làm việc với PO — đội cần một kênh leo thang chứ không thể tự sửa.

Liên hệ PMBOK® Guide