Chia sẻ của Maru Iqbal – người đã đào tạo kiến thức Agile, Scrum và Kanban cho hơn 1.000 cá nhân và hướng dẫn chuyển đổi Agile cho các tổ chức với hơn 60 nhóm. Mary là người sáng lập Rebel Scrum, một công ty tư vấn hỗ trợ các nhóm chuyển đổi Agile và cung cấp các dịch vụ đào tạo được xây dựng dựa trên kinh nghiệm thực tế. Rebel Scrum có kinh nghiệm trong việc hỗ trợ chuyển đổi Agile quy mô lớn trên nhiều môi trường khác nhau, trong đó có chuyển đổi công nghệ và kinh doanh.
Trong framework Scrum, Retrospective (Hồi tưởng) là sự kiện cuối cùng trong một sprint. Retrospective giúp nhóm nhận ra cách để phối hợp làm việc tốt hơn và cải thiện chất lượng của sản phẩm. Nếu Sprint Review (Đánh giá Sprint) là cơ hội để nhóm phân tích increment (phần gia tăng), thì Sprint Retrospective là cơ hội để nhóm phân tích chính mình. Trong sự kiện này, nhóm sẽ thảo luận về cách sprint đã diễn ra, bao gồm các vấn đề liên quan đến các cá nhân, tương tác, quy trình, công cụ và định nghĩa hoàn thành (Definition of Done).
Kết thúc quá trình Retrospective, nhóm sẽ nhận ra những ý tưởng để cải tiến và thực hiện chúng sớm nhất có thể. Nhiều nhóm quyết định đưa những ý tưởng cải tiến này vào backlog của sprint tiếp theo để nâng cao khả năng thực hiện chúng và tăng tính minh bạch.
Giống như tất cả những sự kiện khác trong Scrum, Sprint Retrospective cũng có giới hạn thời gian, tối đa là 3 tiếng cho một sprint kéo dài một tháng và ngắn hơn đối với những sprint ngắn.
Sprint Retrospective
- Người tham gia: Nhóm Scrum – Product Owner, Scrum Master và các nhà phát triển
- Tần suất: 1 lần tại thời điểm kết thúc sprint, sau Sprint Review
- Đầu ra chính:
- Đánh giá cách sprint diễn ra, bao gồm các vấn đề liên quan đến cá nhân, tương tác, quy trình, công cụ và định nghĩa hoàn thành.
- Tìm ra những cách để cải thiện sprint và phương pháp làm việc nhóm
- Đưa ra các ý tưởng cải tiến (có thể thêm vào backlog của sprint tiếp theo)
- Cải thiện tính minh bạch
Ai là người tổ chức Sprint Retrospective?
Scrum Guide không đề cập điều này, tuy nhiên người chịu trách nhiệm tổ chức Retrospective thường là Scrum Master. Tôi đề xuất Scrum Master động viên cả những người khác tổ chức Retrospective để khuyến khích những góc nhìn và điểm tập trung khác có thể mang đến lợi ích cho nhóm. Hãy để Product Owner tổ chức sự kiện một vài lần hoặc để các nhà phát triển lần lượt đứng ra tổ chức. Nhóm cũng có thể cân nhắc mời các khách mời – những người quản lý tài nguyên IT hay các chuyên gia bảo mật – tham gia hoặc tổ chức sự kiện, đặc biệt là khi có những vấn đề về tổ chức hay kỹ thuật mà họ có thể hỗ trợ giải quyết.
Ý tưởng Retrospective
Mỗi nhóm có thể quyết định cách thực hiện Retrospective của mình, và việc thay đổi phương pháp tiếp cận theo thời gian có thể là một ý hay. Dưới đây là một vài ý tưởng cơ bản.
Những gì diễn ra suôn sẻ, những gì chưa suôn sẻ, ý tưởng cải tiến
Là một người thẳng thắn, phương pháp thực hiện Retrospective ưa thích của tôi là cách đơn giản nhất. Hãy tái hiện những cột dưới đây bằng một bảng trắng vật lý hoặc điện tử (xem phần Tổ chức Sprint Retrospective trực tuyến bên dưới để tham khảo một số công cụ). Hãy yêu cầu các thành viên nhóm dán những ghi chú vào mỗi cột để chia sẻ ý kiến của họ. Tiếp theo, hãy chọn từ một đến ba ý tưởng từ cột Ý tưởng cải tiến để nhóm tập trung thực hiện trong sprint tiếp theo. Hãy nhớ rằng bạn thường không thể làm được tất cả mọi thứ, vậy nên hãy chỉ chọn một vài ý tưởng tốt nhất để cải tiến và bỏ qua phần còn lại.
Stop-start-continue
Đây là một ý tưởng đơn giản khác cho Retrospective. Đôi khi tôi thường áp dụng ý tưởng này để đa dạng hóa cách thức tổ chức sự kiện. Như ví dụ dưới đây, hãy yêu cầu các thành viên nhóm chia sẻ suy nghĩ của mình bằng cách ghi chú trong mỗi cột. Sau đó, hãy chọn từ một đến ba ý tưởng từ cột start để nhóm tập trung thực hiện trong sprint tiếp theo.
Drop-add-continue-keep
Tương tự với hai ý tưởng trên, kỹ thuật đơn giản này là một cách để giúp các thành viên trong nhóm suy nghĩ về những gì họ nên dừng lại (stop / drop) và những gì nên bắt đầu (start / add) vào quy trình, những gì họ nên tiếp tục làm và những gì nên giữ lại. Thông thường, ô Continue đại diện cho quy trình, còn ô Keep đại diện cho các công cụ. Đừng quên nhắc các thành viên nhóm cân nhắc đến các khía cạnh cá nhân, tương tác, quy trình, công cụ và định nghĩa hoàn thành khi tham gia Retrospective. Nếu nhóm của bạn áp dụng các thực hành bổ sung (complementary practice) trong thỏa thuận nhóm (team agreement), thì đôi khi bạn cũng nên kiểm tra các điều khoản đó trong Sprint Retrospective. Hãy nhớ rằng thành Rome không được xây nên trong một ngày, và ngay cả những phần gia tăng nhỏ cho quy trình của nhóm cũng có thể tạo ra sự khác biệt đáng kinh ngạc theo thời gian.
1, 2, 4 – All
Phương pháp này dựa trên kỹ thuật 1, 2, 4, All được trang LiberatingStructures.com đề xuất, bạn có thể thay đổi nó cho phù hợp với kích thước nhóm của mình. Để bắt đầu, hãy yêu cầu các thành viên brainstorm ý tưởng cải tiến trong 1 phút. Sau đó, hãy để các cá nhân ghép cặp và trao đổi với nhau trong 2 phút để tìm ra ý tưởng tốt nhất trong cặp. Tiếp theo, hãy để các cặp ghép đôi với nhau thành một nhóm 4 người, đưa ra các ý tưởng và thảo luận trong 4 phút để chọn ra ý tưởng tốt nhất. Cuối cùng, các nhóm nhỏ cùng hội ý với nhau và chọn ra ý tưởng tốt nhất. Tất cả mọi người sẽ thảo luận trong ít nhất 5 phút để thống nhất ý tưởng cải tiến nên tập trung trong sprint sau.
Tôi khuyến khích bạn truy cập trang LiberatingStructures.com để tham khảo thêm các ý tưởng khác. Gần như bất kỳ phương pháp nào trên trang web này cũng có thể giúp bạn tổ chức thành công một Sprint Retrospective hiệu quả.
Tập trung
Tôi thích phương pháp này vì nó bao gồm cả khái niệm về tầm nhìn. Áp dụng phương pháp này, bạn sẽ hỏi các thành viên nhóm nơi mà họ muốn đi đến. Hãy thảo luận về việc nhóm sẽ như thế nào vào 6 tháng sau, và hỏi họ điều gì đang cản trở họ thực hiện kế hoạch và làm thế nào để giải quyết trở ngại. Nếu bạn đang tập trung vào những cải tiến cụ thể, bạn có thể áp dụng phương pháp này cho một hoặc hai lần Retrospective liền nhau để nhóm hình dung ra cả quá trình theo thời gian.
Thuyền buồm
Đây là một phương pháp Retrospective yêu thích khác của tôi vì nó đơn giản. Việc xem Scrum Master cố gắng vẽ bức hình minh họa cũng rất thú vị! Thật may mắn là Mural đã có sẵn một template đẹp sử dụng một biến thể của phương pháp Thuyền buồm. Hãy vẽ một chiếc thuyền buồm đơn giản và hỏi nhóm điều gì đang diễn ra suôn sẻ hay điều gì đang thúc đẩy nhóm tiến về phía trước. Sau đó, hãy hỏi xem điều gì đang cản họ lại hay đang gặp trục trặc. Cuối cùng, hãy yêu cầu nhóm brainstorm ý tưởng cải tiến và chọn ra ý tưởng tốt nhất để mang vào sprint tiếp theo.
5 whys
Nếu nhóm đang đối mặt với một vấn đề và chưa tìm ra nguyên nhân gốc rễ gây ra vấn đề đó, kỹ thuật 5 whys từ lĩnh vực phân tích kinh doanh có thể giúp họ phân tích sâu hơn. Lấy ví dụ, giả sử nhóm đang gặp vấn đề không thể tiến đến Done ở mỗi Sprint. Vấn đề này sẽ được đặt lên trên cùng của bảng trắng. Sau đó, nhóm sẽ hỏi lý do tại sao vấn đề tồn tại và viết câu trả lời vào khung bên dưới. Tiếp theo, nhóm tiếp tục hỏi tại sao, nhưng lần này là hỏi về nguyên nhân cho lý do trước đó họ vừa mới xác định. Tiếp tục quá trình này cho đến khi nhóm xác định được nguyên nhân gốc rễ thật sự (thường sẽ sáng tỏ sau 5 bước).
Brainstorm và bỏ phiếu cho các ý tưởng cải tiến
Nếu các thành viên nhóm đều rất nhiệt tình, Scrum Master có thể tổ chức một buổi brainstorming các ý tưởng cải tiến. Tuy nhiên, Scrum Master không nên áp dụng phương pháp này cho mỗi lần Retrospective vì nó sẽ trở nên khá nhàm chán sau một thời gian. Phương pháp đơn giản này sẽ trở nên hiệu quả nếu được áp dụng lâu lâu một lần.
Brainstorm các ý tưởng cải tiến, minh họa tính khả thi và độ quan trọng
Để phát triển phương pháp brainstorming hơn một chút, đầu tiên hãy yêu cầu các thành viên nhóm brainstorm các ý tưởng cải tiến. Sau đó, hãy biểu diễn các ý tưởng trên một đồ thị với độ quan trọng (importance) trên trục Y và tính khả thi (feasibility) trên trục X. Việc xác định các ý tưởng quan trọng nhất và khả thi nhất có thể giúp nhóm dễ dàng lựa chọn những ý tưởng cần đưa vào sprint tiếp theo.
Quy trình, công cụ, cá nhân, tương tác và định nghĩa hoàn thành
Phương pháp này giúp các thành viên nhóm suy nghĩ một cách rộng hơn. Hãy yêu cầu các thành viên xác định điều gì đang diễn ra suôn sẻ và các ý tưởng cải tiến theo các tiêu chí: quy trình, công cụ, cá nhân / tương tác và định nghĩa hoàn thành. Sau đó, hãy để nhóm bỏ phiếu cho những ý tưởng nên đưa vào sprint tiếp theo.
Tổ chức Sprint Retrospective trực tuyến
Nhiều nhóm đã tìm cách tổ chức các sự kiện Scrum trực tuyến vì ảnh hưởng của đại dịch. Các nền tảng hội nghị như Microsoft Teams, WebEx và Zoom hỗ trợ tính năng chia sẻ bảng trắng, TFS và Jira thậm chí còn có các công cụ đặc biệt dành cho Retrospective được tích hợp sẵn. Tôi đề xuất thêm Mural, nền tảng cung cấp tính năng chia sẻ bảng trắng dễ sử dụng, cùng rất nhiều template hữu ích cho cuộc họp Retrospective hay bảng Kanban và nhiều hơn thế nữa. Reetrio.io cũng là một công cụ hữu ích khác cho Retrospective trực tuyến.
Kết
Sprint Retrospective trở nên đặc biệt hiệu quả khi được tổ chức và thực hiện đúng cách. Sau mỗi sprint, nhóm xác định ít nhất một ý tưởng cải tiến cho sprint tiếp theo. Hãy nhớ rằng ngay cả những cải tiến nhỏ cũng có thể mang đến những thay đổi đáng kinh ngạc theo thời gian, vì vậy đừng bỏ qua quá trình quan trọng này!
The original article: Ideas for Scrum’s Sprint Retrospective Event
The translated article above belongs to the author Mary Iqbal and Scrum.org. Metacoders commits not to use this content for any commercial purpose.
