Retrospective meeting là gì

Sprint Retrospective là gì?

(hay còn gọi là họp cải tiến, họp rút kinh nghiệm)

Sprint Retrospective là sự kiện diễn ra sau Sprint Review, và trước Sprint Planning.

Sprint Retro là cơ hội để đội phát triển tự nhìn lại chính mình (thanh tra chính mình) và cho ra được những cải tiến nên được thực hiện trong Sprint tiếp theo.

Thực hiện các cải tiến này chính là thể hiện được mặt thanh tra và thích nghi của Scrum Team.

Trong Sprint Retro, nội dung mà team sẽ bàn bạc liên quan đến 3 câu hỏi sau:

- Điều gì thuận lợi trong Sprint?

- Điều gì chưa tốt, cần cải tiến?

- Cần làm gì để Sprint tiếp theo tốt hơn?

Vì sao cần có Sprint Retrospective Meeting?

Khi chưa từng làm hoạt động này, chắc bạn sẽ cần những lý do để bắt đầu. Không chỉ thế, rất nhiều team ban đầu thực hiện đều đặn các buổi Retrospective nhưng lâu dần thấy chán và không tiếp tục làm nữa. Đó là lúc cần quay về ý nghĩa và giá trị mà các buổi Retrospective meeting đem lại cho người tham gia.

Điểm qua những ý nghĩa thiết thực, không thể chối cãi của các buổi họp mà tất cả đội nhóm cùng thực hiện reflection với nhau trong buổi họp Retrospective.

- Nó tạo ra không gian an toàn cho các thành viên chia sẻ những feedback, quan điểm cá nhân về công việc của đội nhóm.

- Tại đây team có thể ăn mừng chiến thắng và tìm thấy những cơ hội phát triển

- Team cũng có thể cho ra được 1 danh sách những hành động cần làm, kèm theo owner để giúp Sprint sau hoạt động trơn mượt hơn.

- Những sự thay đổi nhỏ, qua từng tuần sẽ tích lũy tạo nên những cải tiến đột phá

- Những ý kiến góc nhìn được đưa lên bàn, giúp các thành viên cảm thấy được lắng nghe và tôn trọng. .

Sự khác nhau giữa Sprint Review và Sprint Retrospective

- Sprint Review tạo cơ hội cho team giới thiệu, minh họa về sản phẩm vừa hoàn thành. Chủ đề của buổi họp nói về sản phẩm, tính năng, phần tăng trưởng. PO và các stakeholder tham gia Review có thể trải nghiệm, dùng thử, đưa ra feedback cải tiến sản phẩm.

- Còn Sprint Retrospective là cơ hội để đội phát triển reflect, nhìn lại những việc đã hoàn thành, chúc mừng nhau về những điều làm tốt và khám phá ra các cải tiến cho quy trình làm việc, con người trong cả Sprint vừa diễn ra.

Làm thế nào để tổ chức Sprint Retrospective?

Ai tham gia vào Sprint Retrospective

Đội phát triển, Scrum Master đều là thành phần bắt buộc tham gia Sprint Retrospective.

Product Owner nên tham gia cùng để đưa ra những góc nhìn cải tiến mối quan hệ cộng tác giữa PO và đội phát triển.

Product Owner hoàn toàn có thể tham gia cùng đội phát triển trong buổi họp Retro với mong muốn hiểu thêm về sự phức tạp trong công việc của đội đang làm. Còn Scrum Master tham gia với vai trò chính là khích lệ, động viên team đưa ra những cải tiến cho quy trình, công cụ, và cả những cải tiến practices nhằm tăng cường mối quan hệ cộng tác, teamwork của team tự chủ.

Buổi Sprint retrospective không chỉ quan tâm nhìn nhận và cải tiến quy trình, công cụ mà nó còn hướng đến con người và mối quan hệ.

Thời lượng của buổi Retrospective

Retrospective chỉ nên kéo dài tối đa 3 tiếng đối với Sprint có độ dài 1 tháng.

Sprint ngắn hơn thì họp Retrospective ngắn hơn. Sprint 1 tuần thì Retro chỉ nên tối đa khoảng 45'.

Template tham khảo của Retrospective 45 phút

Sau đây là agenda tham khảo cho 1 buổi họp Retrospective (không chỉ áp dụng cho Sprint, mà còn có thể áp dụng cho việc nhìn lại 1 quý, 1 dự án)

1. Setting the stage - Tạo bối cảnh và không khí cho buổi họp

Setting the stage hiểu là khởi động, lên tinh thần cho cuộc thảo luận của team. Hãy sử dụng những giây phút đầu tiên của buổi họp để khiến mọi người cảm thấy thoải mái và hào hứng chia sẻ.

Dưới đây là 1 vài yếu tố về tinh thần mà các thành viên nên chuẩn bị trước khi bước vào cuộc họp Retrospective:

• Không cá nhân hóa vấn đề (take it personally), đừng xem mọi chuyện là trỏ về bản thân mình.
• Lắng nghe với cái đầu mở và ghi nhớ rằng trải nghiệm của ai cũng đều đáng quý.
• Thiết lập ranh giới thảo luận cho cuộc họp - vấn đề sẽ đề cập đến trong khoảng thời gian nào (Sprint vừa diễn ra, hay quý vừa qua, hay dự án)
• Tinh thần cải tiến, cùng phát triển, tránh tư duy đổ lỗi.

2. Gather data - Thu thập dữ liệu

Đây là lúc mọi thành viên đều cần chia sẻ thông tin, kèm các quan sát, nhìn nhận của bản thân về công việc của team trong tuần.

Ở phần này, team có thể sử dụng các format khác nhau từ Glad Sad Mad, Start Stop Continue, Keep Problem Try, Starfish, 4Ls. để đặt câu hỏi giúp các thành viên đưa ra ý kiến, quan điểm cá nhân.

Nhìn chung các format dẫn dắt này đều quay xung quanh 3 câu hỏi chính

• Điều gì làm tốt, thuận lợi?
• Điều gì chưa tốt, cần cải tiến
• Hành động cải tiến tiếp theo là gì?

Lưu ý rằng mỗi format điều phối phần thu thập dữ liệu sẽ có mục đích khác nhau. Ví dụ Glad Sad Mad tập trung vào cảm xúc của các thành viên hơn, từ đó tìm ra vấn đề thẳm sâu. Hay Start Stop Continue thì có hơi hướng khơi gợi hành động cho tương lai.

Mỗi thành viên tham gia đều ghi nhận định và quan sát của mình lên giấy note, và cùng đẩy lên 1 bảng trắng hoặc online board, để ai cũng có thể biết được ý kiến của nhau.

3. Generate insights - Đào sâu vấn đề

Từ các card ý kiến của thành viên, cả team cùng sắp xếp, gom nhóm, loại bỏ các ý kiến trùng. Sau đó team cùng đọc hiểu và đào sâu vấn đề. Kỹ thuật 5 Why - đặt câu hỏi Vì sao 5 lần là một trong những cách giúp các thành viên khám phá ra nguyên nhân cốt lõi của các sự vật - hiện tượng, hay các quan sát mà họ nêu ra.

Cố gắng liên kết các dữ liệu, và luận giải, móc nối, đúc rút các vấn đề thành những mô thức hành vi, mô thức sai lầm, hay các practices hiệu quả, hoặc bài học kinh nghiệm sẽ rất hữu ích để team mang theo bên mình trong những Sprint tiếp theo.

4. Decide what to do - Xác định hành động cải tiến

Có quá nhiều kiến giải ý tưởng, insights mà không biến chúng thành hành động thì cũng vô ích.

Đây là lúc team cần nhìn vào tính thực tiễn của các insights, bài học vừa rút ra và đưa ra những hành động cải tiến có thể làm được luôn, đưa vào Sprint sau triển khai.

Hãy dùng phương thức dot voting, để cùng giới hạn danh sách các cải tiến xuống còn từ 3-5 cải tiến. Với sự tập trung vào 1 số ít hành động cải tiến nhất định, team có thể keep track, follow up và không bị bỏ sót ở Sprint tiếp.

Và nhớ là lưu giữ vào bảng task board để ai cũng có thể nhìn thấy. Đi kèm với đó, team bạn cũng đừng quên bầu ra 1 owner cho mỗi hành động cải tiến. Nếu không thì các cải tiến của team bạn sẽ rơi vào tình trạng cha chung không ai khóc.

5. Close retrospective - Kết thúc buổi họp

Cuối cùng, hãy kết thúc buổi họp bằng cách tóm tắt lại những gì đã diễn ra, đặc biệt đề cập đến các hành động cần thực hiện và owner của các hành động đó.

Team cũng có thể kết thúc bằng 1 phần đánh giá nhanh hiệu quả của hoạt động Retrospective vừa diễn ra, xem mức độ hài lòng của mọi người là bao nhiêu từ 1-5 chẳng hạn.

Bài học rút ra khi thực hiện Retrospective tại Magestore

Trên thực tế, hoạt động cải tiến rút kinh nghiệm là một trong những hoạt động khó điều phối. Nhất là trong team có toàn các anh em developer, tối ngày chỉ quan tâm đến những dòng code.

Chúng mình nhận thấy rằng, hoạt động này đòi hỏi các thành viên cần có ý thức về bản thân (self-awareness) tốt. Thậm chí, team cũng cần có những người có trí thông minh cảm xúc (EQ) cao để dẫn dắt, điều phối được hiệu quả.

Sau một thời gian trải nghiệm các cách thức Retrospective khác nhau, cùng với đó là hỏi thăm kinh nghiệm thực hành của các team tự chủ tại Magestore, chúng mình cũng đã lượm lặt được 1 vài bài học thú vị. Mong là chúng sẽ hữu ích với buổi họp cải tiến trong team của bạn.

1. Thẳng thắn chia sẻ vướng mắc trong daily meeting giúp team có action cải tiến luôn

Chị Amber, một thành viên của team triển khai dự án tại Magestore chia sẻ. Một điểm hay của team chị là mọi người sẽ nêu luôn các khúc mắc tại daily stand-up meeting và sau đó bàn phương hướng giải quyết tức thời nếu được.

Các phương án này sẽ được team lưu giữ lại trên cột Open trong issue board trên Gitlab. Những khoảnh khắc retrospective đến từng ngày như vậy giúp team thích ứng và có solution sửa chữa được những vấn đề tồn đọng một cách nhanh chóng, chứ không phải đợi đến buổi retro cuối tuần mới phát hiện và xử lý.

2. Sprint Retrospective nên đề ra cải tiến nhỏ có tính thực tiễn, và hành động được luôn

Có câu nói:

Small changes have a big impact than good idea that never happen.

Ý nói rằng những thay đổi nhỏ sẽ có tác động lớn hơn là những ý tưởng chẳng bao giờ được thực hiện.

Đây cũng là một bài học mà anh Mike, CIO tại Magestore, có hơn 10 năm kinh nghiệm với các dự án tech chia sẻ. Anh nói rằng, team nên rút ra các ý tưởng cải tiến nhỏ trong phạm vi 1 Sprint. Nhỏ ở đây hiểu là có tính thực thi, và hành động được luôn trong Sprint sau. Chứ không phải là những ý tưởng cải tiến to và thiếu tính thực thi, chỉ là nói xuông.

3. Cần follow-up action cải tiến và chọn owner để đảm bảo chúng diễn ra

Đây tiếp tục là một kinh nghiệm nữa được anh Mike rút ra sau một quá trình thực hành Sprint Retrospective ở nhiều team tự chủ khác nhau.

Team có sự trao đổi, đúc kết được những bài học kinh nghiệm quý báu, và đề ra được các hành động cải tiến là rất tốt. Nhưng quan trọng hơn là sau đó action plan thế nào.

Các hành động này có đi vào thực tế, trở thành thứ team làm hàng ngày?

Để đảm bảo các ý tưởng cải tiến thành hiện thực, hãy chọn mỗi hành động cải tiến một owner, là người sẽ nhắc nhở, keep track, đảm bảo các thành viên khác thực hiện như những gì đã thảo luận ở trong buổi họp Retrospective.

4. Linh động thay đổi format để khớp với tính chất công việc hoặc của buổi Retrospective.

Để giúp cho các buổi Retrospective không bị nhàm chán, hãy thử linh hoạt thay đổi các phương thức điều phối, dẫn dắt buổi Retrospective meeting.

Như đã chia sẻ tại cuốn Agile Playbook trong bài viết các phương pháp họp Retrospective, bạn có thể thử nghiệm và cho team nhìn nhận xem 1 format nào là phù hợp với tính chất công việc của team.

Tại Magestore, các team tự chủ chúng mình thường sử dụng format Glad Sad Mad cho buổi họp Retrospective của Sprint một tuần. Format này đặc biệt giúp chúng mình khám phá tâm trạng và cảm xúc của nhau, giúp các thành viên hiểu nhau hơn và tìm ra cải tiến giúp mọi người không chỉ làm việc hiệu quả mà còn trở nên hạnh phúc hơn.

Còn đối với các dự án thực chiến, team thường sử dụng các format Keep Stop Start hay Keep Problem Try để rút ra được những hành động đưa vào thực tế một cách nhanh chóng.

Cùng tùy vào tính chất công việc và sự yêu thích của các thành viên mà team sẽ đi đến quyết định gắn bó dài lâu hơn với 1 format nào đó.

5. Đưa Retrospective thành cuộc họp online khi working remote.

Hiện Magestore cũng đang áp dụng chế độ working remote. Và để các thành viên đồng bộ với nhau, chúng mình đã đưa các cuộc họp này lên nền tảng online.

Đơn giản với các công cụ Google Hangout hay Zoom dùng để gọi nhóm, Google Docs, Google Sheet để ghi lại nội dung buổi họp ngay trong khi diễn ra. Đi kèm với đó là các task board trên trelllo, gitlab để tracking các task trong một Sprint.

Ngoài ra, chúng mình còn sử dụng thêm công cụ Ideaboardz - để các thành viên ghi lại các ý kiến dạng post-it-note cho các format dạng Glad Slad Mad, Keep Stop Start.

Tiến trình cuộc họp vẫn thế, chỉ khác một chút là cần dùng linh hoạt hơn các công cụ hỗ trợ để điều phối cuộc họp.

Còn bạn thì sao? Team của bạn đang tổ chức các buổi họp cải tiến, rút kinh nghiệm cho Sprint, cho dự án hay cho quý như thế nào?

Hãy chia sẻ thêm với Magestore nhé!

Chúc các bạn tổ chức được những buổi Retrospective đầy hứng khởi cho team của mình!