Theo Scrum Guide , mục đích của Sprint Retrospective là lên kế hoạch gia tăng chất lượng và hiệu quả.
The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.
Nguồn: Scrum Guide
Cho dù bạn có thường xuyên thực hiện retrospective hay không, bạn cũng nên đề phòng các mô hình Sprint Retrospective sai lầm sau đây từ Scrum Team, Development Team, Scrum Master cũng như tổ chức của mình.
Các mô hình Sprint Retrospective sai lầm từ Scrum Team
#NoRetro: Không thực hiện retrospective vì nhóm tin rằng không có gì để cải thiện.
Không có cái gọi là Agile Nirwana – nơi mọi thứ đều hoàn hảo. Như người ta vẫn thường nói, trở nên linh hoạt là một hành trình chứ không phải điểm đến và vẫn luôn có điều gì đó chúng ta có thể cải thiện.
Dispensable buffer: Nhóm hủy bỏ retrospective khi cần thêm thời gian để hoàn thành Sprint Goal.
Việc xem thời gian retrospective như một khoản dự trữ khẩn cấp của Sprint là dấu hiệu phổ biến của Scrum chú trọng vào thành phẩm. Tôi tin rằng, đây thậm chí còn là mô hình tồi tệ hơn cả #NoRetro vì phỏng đoán rằng không có gì để cải thiện. Điều này chỉ là sự nguỵ biện quá mức xen với sự kiêu ngạo của con người. Tuy nhiên, việc hủy bỏ ngẫu nhiên retrospective để đạt được Sprint Goal lại là dấu hiệu rõ ràng cho thấy nhóm không hiểu các nguyên tắc cơ bản của Scrum, như chủ nghĩa kinh nghiệm (empiricism) và việc cải tiến liên tục (continuous improvement). Nếu Scrum Team liên tục không đạt được Sprint Goal, nhóm cần kiểm tra xem những gì đang diễn ra. Hãy đoán xem sự kiện Scrum nào được thiết kế để phục vụ mục đích này?
Rushed retrospective: Nhóm thực hiện vội vàng và phân bổ ít thời gian hơn nhiều so với thời gian cần thiết (60 đến 180 phút) cho việc retrospective.
Việc này sẽ dẫn đến kết quả là một buổi retrospective mang lại ít giá trị. Sớm muộn rồi hầu hết các thành viên trong nhóm sẽ coi đó là một sự lãng phí. Hãy làm đúng bằng cách bố trí đủ thời gian hoặc cân nhắc việc dừng retrospective lại. Và trong khi bạn thực hiện việc đó, tại sao bạn không từ bỏ Scrum hoàn toàn luôn nhỉ?
Someone sings: Là khi một người bất kỳ tham gia retrospective và cung cấp thông tin trong sự kiện cho những người bên ngoài.
Đối với việc retrospective, quy tắc Vegas phát biểu rằng: những gì được nói ra sẽ chỉ nội bộ nhóm được biết – what is said in the room stays in the room. Quy tắc này không có ngoại lệ.
Extensive whining: Nhóm sử dụng retrospective chủ yếu để phàn nàn về tình huống và giả định vai trò của nạn nhân.
Việc thay đổi đòi hỏi sự phản ánh và đôi khi là một cơ hội tốt để xả hơi. Tuy nhiên, khi đã xác định được các vấn đề quan trọng, bạn nên dừng việc xả hơi này lại và cố gắng thay đổi chúng cho dù mục đích của việc retrospective là gì.
UNSMART: Nhóm lựa chọn giải quyết các hành động UNSMART.
Bill Wake đã tạo ra từ viết tắt SMART để chỉ các hành động hợp lý: S – Specific – Cụ thể, M – Measurable – Có thể đo lường, A – Achievable – Có thể đạt được, R – Relevant – Có liên quan, T – Time-boxed – Trong giới hạn thời gian. Tuy nhiên, nếu nhóm lựa chọn các hành động UNSMART, tự nó sẽ thất bại và góp phần tạo ra khuynh hướng cho rằng agile không hiệu quả.
#NoAccountability: Mặc dù các hành động đã được đồng thuận trước nhưng không ai chịu trách nhiệm hoàn thành.
Nếu tin rằng “nhóm” sẽ sửa lỗi X, có lẽ mọi người đều nghĩ rằng một thành viên khác của nhóm sẽ xử lý việc này. Hãy để một ai đó chịu trách nhiệm chính thay vì để cả nhóm thực hiện.
What improvement? Nhóm không kiểm tra trạng thái của các hành động từ những lần retrospective trước đó.
Tính tự chủ của nhóm phải gắn liền với trách nhiệm. Nếu bạn không theo dõi những gì bạn muốn cải thiện trước đây, tại sao ngay từ đầu bạn lại quan tâm đến việc lựa chọn các hành động đó để cải thiện?
Các mô hình Sprint Retrospective sai lầm từ Development Team
Product Owner non-grata: Product Owner không được hoan nghênh trong sự kiện retrospective.
Một số người vẫn tin rằng – vì bất kỳ lý do gì – chỉ các thành viên của Development Team và Scrum Master mới nên tham gia buổi retrospective của nhóm. Tuy nhiên, Scrum Guide chỉ rõ rằng Scrum Team, bao gồm cả Product Owner, nên tham gia sự kiện này. Điều này vì một lý do rất chính đáng: cả nhóm cùng nhau giành chiến thắng và cũng cùng nhau thất bại. Làm thế nào để nhóm hoạt động nếu không có Product Owner?
Các mô hình Sprint Retrospective sai lầm từ Scrum Master
Waste of time: Nhóm không đánh giá chung giá trị của buổi retrospective.
Nếu một số thành viên trong nhóm xem retrospective có ít hoặc không có giá trị, điều này thường do chính bản thân việc retrospective rất tệ. Liệu đó có phải là một quy trình luôn giống nhau, mang tính nghi thức và rất nhàm chán không? Hãy thử thay đổi địa điểm tổ chức hoặc tổ chức một buổi retrospective với bia hoặc rượu thử xem. Có rất nhiều điều mà Scrum Master có thể làm để khiến các buổi retrospective trở nên tuyệt vời và giảm tỷ lệ vắng mặt của các thành viên. Theo kinh nghiệm của tôi, những người hướng nội cũng thích tham gia vào các buổi retrospective.
Prisoners: Một số thành viên trong nhóm chỉ tham gia vì họ bị buộc phải tham gia.
Đừng gây áp lực cho bất kỳ ai rằng phải tham gia vào buổi retrospective. Thay vào đó, hãy khiến buổi retrospective xứng đáng với thời gian mà họ bỏ ra. Động lực để nhóm liên tục cải thiện cần được thúc đẩy bởi động lực nội tại, chứ không phải bởi sự sợ hãi hay vũ lực. Mẹo của tôi là sử dụng mẫu Retro “Tại sao bạn có mặt ở đây?” bên dưới.
Groundhog day: Khi các buổi retrospective không bao giờ thay đổi về thành phần, địa điểm hay thời lượng.
Trong trường hợp này, nhóm thường có xu hướng xem xét lại các vấn đề giống nhau từ hôm này qua hôm khác – đây gọi là groundhog day với một kết thúc không có hậu.
Let’s have it next Sprint: Nhóm trì hoãn buổi retrospective sang Sprint kế tiếp.
Ngoài chức năng “kiểm tra & điều chỉnh”, retrospective cũng đóng vai trò như một thời điểm kết thúc, điều chỉnh lại tâm trí của mọi người để nhóm có thể tập trung vào Sprint mới. Ngoài ra, Scrum Team phải chọn ít nhất một hoạt động quan trọng trong retrospective để thực hiện trong Sprint sắp tới. Đây là lý do tại sao chúng ta cần tổ chức retrospective trước khi thực hiện Sprint Planning cho Sprint sau. Việc trì hoãn sang Sprint kế tiếp có thể làm gián đoạn quy trình của nhóm và khiến một hoặc nhiều vấn đề quan trọng không được giám sát trong suốt Sprint.
#NoDocumentation: Không ai dành ra vài phút để ghi lại nội dung nhằm sử dụng về sau.
Retrospective là một khoản đầu tư đáng kể và cần được thực hiện nghiêm túc. Việc ghi chép và chụp ảnh sẽ hỗ trợ quá trình này.
No psychological safety: Khi retrospective trở thành một chu kỳ vô tận của những lời đổ lỗi và chỉ điểm lẫn nhau.
Cả nhóm cùng nhau giành chiến thắng và cũng cùng nhau thất bại. Việc đổ lỗi cho thấy sự thất bại của Scrum Master với tư cách là người dẫn dắt buổi retrospective cũng như sự thiếu chín chắn và kỹ năng giao tiếp của nhóm.
Bullying: Một hoặc hai thành viên trong nhóm đang thống trị buổi retrospective.
Hành vi này thường là dấu hiệu của một Scrum Master yếu kém hoặc không quan tâm đến buổi retrospective. Buổi retrospective phải là một nơi an toàn mà mọi người – kể cả những người hướng nội – cũng có thể giải quyết các vấn đề và đưa ra phản hồi của họ mà không bị ảnh hưởng bởi bên thứ ba. Nếu một số thành viên trong nhóm đang chiếm ưu thế trong cuộc trao đổi, thậm chí có thể bắt nạt hoặc đe dọa các thành viên khác, buổi retrospective sẽ không còn an toàn nữa. Sự thất bại này sẽ dẫn đến việc mọi người không còn muốn tham gia retrospective và khiến kết quả trở nên không mang lại giá trị. Đây là trách nhiệm chính của Scrum Master – đảm bảo mọi người đều được lắng nghe và có cơ hội nói lên suy nghĩ của mình. Cũng như theo Google, thời gian lên tiếng của mọi người được phân bổ đồng đều cũng là dấu hiệu của một nhóm hoạt động hiệu quả.
Stakeholder alert: Các bên liên quan tham gia vào buổi retrospective.
Trong Scrum, có một số sự kiện được thực hiện để giải quyết nhu cầu giao tiếp và thông tin của các bên liên quan như Sprint Review, Daily Scrum, thậm chí có thể là Product Backlog refinement, chưa kể các cơ hội trao đổi tại nơi uống nước, khu cà phê hoặc trong giờ ăn trưa. Nếu chừng đó thời gian vẫn không đủ, nhóm có thể xem xét tổ chức các cuộc họp bổ sung nếu cho rằng việc này là cần thiết. Tuy nhiên, retrospective là vượt quá giới hạn đối với các bên liên quan.
Passivity: Các thành viên trong nhóm có mặt tại buổi retrospective nhưng không chủ động tham gia.
Có rất nhiều lý do cho hành vi này như họ coi việc retrospective là lãng phí thời gian; môi trường retrospective không an toàn hay những người tham gia cảm thấy chán nản vì nó đã được đoán trước hoặc thiếu sự tiến bộ. Có thể, các thành viên trong nhóm chỉ lo sợ những hậu quả tiêu cực khi họ vắng mặt và do đó quyết định xuất hiện nhưng không hề có ý định tham gia. Trong trường hợp này, không có cách nào để khắc phục một cách nhanh chóng và Scrum Master cần phải tìm ra hình thức retrospective nào sẽ hiệu quả trong bối cảnh cụ thể của nhóm mình.
Các mô hình Sprint Retrospective sai lầm từ Tổ chức
No suitable venue: Không có nơi nào thích hợp để tổ chức retrospective.
Nơi ít thích hợp nhất để thực hiện retrospective là phòng họp với chiếc bàn hình chữ nhật được bao quanh bởi những chiếc ghế. Tuy nhiên, đây là địa điểm phổ biến nhất để tổ chức các buổi retrospective. Để trở nên linh hoạt, chúng ta cần có không gian. Nếu không có không gian, bạn cần trở nên sáng tạo và đi đến một nơi khác. Nếu thời tiết tốt, hãy lấy thêm thức ăn và ra bên ngoài trời. Hoặc thuê một không gian thích hợp ở một nơi khác. Nếu điều này vẫn không hiệu quả, có thể do vấn đề ngân sách, hãy bỏ ra ít nhất một cái bàn để bạn có thể ngồi/đứng trong vòng tròn chẳng hạn. Bạn cần sáng tạo thêm.
Line managers present: Các Quản lý Chuyên môn tham gia vào buổi retrospective.
Đây là một trong những mô hình Sprint Retrospective tồi tệ nhất mà tôi có thể nghĩ ra. Điều này biến buổi retrospective trở thành một nơi không an toàn. Và liệu ai có thể tin rằng một nơi không an toàn lại tạo ra một cuộc thảo luận cởi mở giữa các thành viên trong nhóm? Bất kỳ Quản lý Chuyên môn nào khăng khăng như vậy cũng cho thấy sự thiếu hiểu biết của họ về cách thực hành Scrum cơ bản.
Let us see your minutes: Một ai đó của tổ chức – không thuộc Scrum Team – yêu cầu xem biên bản retrospective.
Điều này cũng tệ như việc Quản lý Chuyên môn muốn tham gia vào buổi retrospective. Tất nhiên, quyền truy cập phải bị từ chối.
Kết luận
Có nhiều hình thức khiến buổi retrospective thất bại, ngay cả khi, thoạt nhìn nó có vẻ hiệu quả. Theo quan điểm của tôi, ba mô hình Sprint Retrospective sai lầm hàng đầu là: không làm cho buổi retrospective trở thành một nơi an toàn, thời gian phát biểu của các thành viên được phân bổ không đồng đều và buổi retrospective chỉ mang tính nghi thức, không bao giờ thay đổi.
Liệu tôi có thiếu mô hình Sprint Retrospective sai lầm nào không? Hãy chia sẻ với chúng tôi trong phần bình luận bên dưới nhé!
Lược dịch: Masterskills
Nguồn: 21 Sprint Retrospective Anti-Patterns Impeding Scrum Teams
Mục đích thật sự của Agile
Hệ tư duy của Disciplined Agile
