How to run an effective Retrospectives meeting? (P1)

Minh xin được mở đầu bài viết bằng nguyên tắc thứ #12 trong bảng tuyên ngôn của Agile. “Sau một khoảng thời gian nhất định, team sẽ suy nghĩ làm thế nào để hiểu quả hơn, từ đó đưa ra những điều chỉnh phù hợp”

Nguyên tắc đó của Agile được kết hợp chặc chẽ trong Retrospectives Meeting, đây cũng là 1 trong 4 buổi meeting bắt buộc khi dự án chạy Scrum. Và cũng không phải không có cơ sở mà người ta nói Retrospective Meeting chính là cuộc họp nắm giữ vận mệnh của scrum team. Có 3 lý do chính để có thể đưa ra nhận định trên như sau:

• Retrospective là công cụ đào tạo: Trong một dự án, một team làm việc chung với nhau thì không ai là người hoàn hảo. Có người thiếu cái này, người thiếu cái kia, nhiều người chịu ảnh hưởng của những dự án cũ hoặc thói quen của bản thân. Người có nhiều kinh nghiệm, người mới ra trường. Vì vậy họ cần thời gian để học mà sẽ mắc lỗi đó là chuyện bình thường trong mỗi dự án. Retrospective đảm bảo mọi người luôn nhận được những feedback thường xuyên từ những thành viên trong team. Nhờ đó có thể hòa nhập và phát triển bản thân và cả dự án.
• Retrospective tạo ra văn hoá trao đổi tích cực: Một Leader hoặc Scrum Master (Vai trò Leader trong Scrum project) tốt sẽ sử dụng retrospective để nâng cao tinh thần tự kiểm điểm bản thân, tích cực cải thiện sản phẩm trong Team. Giúp cho Team ngày một tiến bộ, không tự hài lòng và ngủ quên trên chiển thắng.
• Retrospective chính là để tạo ra sự linh hoạt: Thường xuyên tổ chức Retrospective meeting đòi hỏi chúng ta phải luôn luôn thay đổi, tiến bộ liên tục.

Sau một khoản thời gian nhất định của dự án, thường là sau mỗi sprint đối với dự án Scrum hoặc mỗi Phase, mỗi lần release dự án chính là lúc chúng ta nhìn lại những gì mình đã đi qua , là lúc các thành viên trong dự án cùng ngồi lại để tìm ra những vấn đề đang tồn tại, cùng nhau đưa ra cách khắc phục cũng như tuyên dương khen thưởng những cá nhân có đóng góp cho sự thành công của dự án. Retrospectives Meeting là vô cùng cần thiết để giúp team của bạn rút ra những bài học kinh nghiệm và làm việc tốt hơn về sau.

Mặc dù Retrospectives Meeting là 1 trong 4 buổi meeting bắt buộc khi dự án chạy Scrum, nhưng không phải chỉ có dự án Scrum mới cần Retrospectives Meeting. Mà chúng ta cũng có thể mượn Retrospectives meeting từ Scrum và áp dụng cho tất cả các dự án đang chạy theo mô hình bất kỳ. Vậy áp dụng Retrospectives Meeting được tiến hành như thế nào? Theo phương pháp gì? Và làm sao để có một buổi Retrospectives Meeting hiệu quả?

Nói là có nhiều phương pháp tiến hành Retrospectives Meeting nhưng thực tế cuộc họp chỉ xoay quanh 3 vấn đề: Đã làm tốt những gì, phải cải thiện những gì, những gì cần phải hành động. Chỉ là tên gọi của các phương phảp khác nhau, nhưng bản chất vấn đề là như nhau

1. Phương pháp KPT

KPT là viết tắt của 3 chữ cái Keep, Problem và Try. Và cụ thể là:

Keep

Theo đúng ý nghĩa của từ Keep là giữ lại, những cái tốt, tích cực trong dự án có thể thúc đẩy sự phát triển của dự án. Ví dụ:

• Communication trong team rất tốt, không có mâu thuẩn giữa các thành viên trong nhóm.
• Thường xuyên sharing knowleadge với nhau
• Khách hàng rất hài lòng với chất lượng sản phẩm

Problem:

Đây chính là vấn đề chính mà một buổi Retrospectives Meeting cần giải quyết, nhưng vẫn đề đang xảy ra gây ảnh hưởng trực tiếp đến dự án, chất lượng công việc và tinh thần của của nhóm Ví dụ:

• Dev team không comment trong Bug nên nhiều khi fix bug khác expectation của QA nhưng QA không biết nên Reopen bug và phải confirm nhiều lần
• Dev không Unit test nên quá nhiều bug, và có khi phải đập đi làm lại
• QA log bug thiếu information. Gây khó khăn cho dev khi tái hiện bug Những vấn đề trên cần phải tìm cách khắc phụ trong giai đoạn sau của dự án, để có thể giúp dự án hoạt động hiệu quả hơn

Try

Mỗi problem thì sẽ có những biện pháp tương ứng để khắc phục. Và đó chính là TRY

• Dev phải comment action của mình trên bug
• Dev phải Unit test trước khi giao cho QA test
• Quy định rõ ràng information khi log bug mà Dev cần là gì. Và thống nhất phải đầy đủ những thông tin đó khi log bug

2. Retrospectives Meeting với Glad - Sad - Mad

Tương tự với KPT thì cuộc hợp mình sẽ chia thành 3 phần như sau: • Những hạng mục nào mà mình cảm thấy hài lòng thì được phân loại vào mục Glad. • Những hạng mục nào mà mình chưa cảm thấy hài lòng và có thể cải tiến được thì đưa vào mục Sad. • Những hạng mục nào mà gây cản trở nghiêm trọng và mình mong muốn loại bỏ nó ngay thì đưa vào mục Mad. Từ đó những mục Sad và Mad sẽ được thảo luận và tìm cách cải tiến trong thời gian sắp tới. Kể cả trong những hạng mục ở cột “Glad” thì cũng vẫn có thể cải tiến để nó tốt hơn.

3. Retrospectives Meeting với Start - Stop - Continue

3 mục trong phần này tương ứng như sau:

1. Chuẩn bị

Thông báo cho team thời gian địa điểm và các mục sẽ được bàn trong buổi họp. Yêu cầu mọi người chuẩn bị trước các vấn đề cần được thảo luận. Chuẩn bị trước các vật dụng cần thiết trong cuộc họp: Ví dụ:

• Sticky note
• Bảng
• Camera
• Bút màu
• .....

2. Cách thức thực hiện

Get Feedback

Cả team sẽ được phát mỗi người vài tờ sticknote và một cây bút. Mỗi người cho 5-10 phút để viết ra những vấn đề liên quan như Keep - Problem - Try. Bạn nên dùng màu của sticky note để phân biệt Về nguyên tắc bạn có thể tự đặt ra mỗi người tối thiểu 2 Keep, 2 Try, 2 Problem. Nếu ai có nhiều vấn đề thì có thể chọn vấn đề nổi cộm nhất. Sau khi viết xong thì dán lên bảng và bắt đầu thảo luận

Discuss

1. Bắt đầu bằng những điều tích cực, trong trường hợp này cụ thể là mục Keep để tạo không khí vui vẻ phấn khởi cho cả team
2. Review lại kết quả và plan của lần meeting trước nếu có, xem đã làm được những gì? Có cải thiện được hay không? Khen thưởng những cá nhân có đóng góp tích cực cho dự án.
3. Thảo luận về những vấn đề đang gặp phải của dự án (PROBLEM) và đưa ra giải pháp (TRY). Lưu ý: Nếu có căng thằng trong quá trình này thì có thể giải lao 5' và thay bằng teabreak và bàn tiếp tục sau đó

Summary

1. Đưa ra plan để thực hiện và review trong lần meeting sau
2. Ghi chép lại tất cả nội dung cuộc họp, có thể chụp hình bảng
3. Kết thúc

1. Do

• Make it safe: Để các thành viên có thể thoải mái giải bài vẫn đề thì cuộc họp chỉ nên bao gồm những thành viên của dự án, không có người ngoài. Địa điểm cũng nên là phòng họp riêng, riêng tư cho team
• Preparation is required: Nếu bạn muốn cuộc họp có thể mang lại hiệu quả và đúng ý nghĩa của nó thì các thành viên nên chuẩn bị trước những vấn đề và hướng giải quyết. Nếu như việc tìm vấn đề và đưa ra giải pháp chỉ gói gọn trong 1-2h meeting thì chưa hẳn là quyết định sáng suốt và đúng nhất. Những vật dụng trong cuộc họp cũng nên được chuẩn bị đầy đủ.
• Plan enough time: Nếu đồi với dự án Scrum thì mỗi Sprint 2 tuần thời gian cho Retrospectives meeting là 1.5 đến 2 giờ. Chúng ta có thể điều chỉnh thời gian họp tùy theo thời gian của mỗi Sprint. Còn đối với những dự án chạy theo mô hình khác thì có thể tùy chỉnh dựa vào thời gian chạy của từng giai đoạn, càng nhiều công việc, thì vấn đề càng thảo luận sẽ càng nhiều.
• Start positive by focusing on successes first: Cuộc họp nên được bắt đầu bằng những thành công của dự án, điều này dễ dàng tạo không khí vui vẻ và tích cực trao đổi giữa các thành viên trong dự án. Nếu như bạn làm theo hướng ngược lại, bắt đầu bằng những vấn đề khó khăn của dự án thì có nhiều vấn đề gây tranh cãi và không có lối thoát, tinh thần của mọi người sẽ đi xuống và có thể thấy mệt mỏi vì nghĩ đây là một cuộc chỉ trích, kiểm điểm. Điều này cực kì quan trọng và không thể bỏ qua
• Ask, "What else?" instead of, "Anything else?": Vấn đề này nghe có vẻ đơn giản phải không, nhưng thông điệp bạn muốn gửi đến nó không hẳn là như nhau. Trong khi "What else?" mang ý nghĩa mong chờ, khuyến khích những ý kiến đóng góp của mọi người thì "Anything else?" nói rằng có quá nhiều vấn đề, tốn quá nhiều thời gian rồi,và tôi đang cảm thấy chán.
• Make it fun: Tạo không khí vui vẻ, thoải mái và hãy làm cho cuộc họp của bạn trở thành một cuộc họp hữu ích, mọi người cảm giác thích thú vì có thể tìm ra phương hướng tiếp theo để cố gắng. Nếu có thể thì chuẩn bị một ích thức ăn nhẹ hoặc đồ ăn mà cả team yêu thích.
• Đánh số thứ tự ưu tiên công việc cần làm và review trong cuộc họp tiếp theo
• Action planing: Tất cả những công việc vạch ra trong thời gian tới phài được thực hiện và review trong cuộc họp sau.

2. Don'ts

• Play the blame game: Đây không phải là lúc để mọi người chỉ trích vì những việc không tốt đã xảy ra, hãy nhớ mục đích chính của chúng ta là thay đổi để phát triển
• Mời những người không liên quan tham dự cuộc họp.
• Họp quá ngắn hoặc quá dài. Thời gian cuộc họp nên được kiểm soát từ trước.
• Sa đà vào một vấn đề mà không có lối thoát. Nếu vấn đề không có hồi kết bạn có thể đề nghị cho thêm thời gian suy nghĩ mà sẽ bàn trong cuộc họp tiếp theo

Retrospective thực sự rất hữu ích cho việc xây dựng đội ngũ và sự gắn kết giữa các thành viên trong team với nhau. Bạn có thể áp dụng mô hình này cho bất cứ quy trình sản xuất nào, không nhất thiết phải là phát triển phần mềm hay agile. Có thể ban đầu sẽ gặp khó khăn một chút khi áp dụng, nhưng mình tin rằng nếu với thái độ tích cực thì sau một vài lần Retrospective meeting sẽ mang lại rất nhiều điều thú vị và giúp công việc nhóm của bạn ngày càng tiến triển theo chiều hướng tốt hơn.

Small changes have a bigger impact than good ideas that never happen

Tham khảo: http://blog.lucidmeetings.com/blog/how-to-lead-a-successful-project-retrospective-meeting https://www.scrumalliance.org/community/articles/2014/july/dos-and-don-ts-of-agile-retrospectives http://www.softwaretestinghelp.com/agile-retrospective-meetings/