Là một hoạt động diễn ra định kỳ, thường là vào cuối một chu kỳ phát triển của Agile (Iterator or Sprint). Các thành viên trong team sẽ cùng xem xét lại cách mà họ đang làm việc từ đó đưa ra được các action (hành động) để quá trình làm việc được tốt hơn trong những chu kỳ phát triển tiếp theo.

• Toàn bộ thành viên trong Agile team được kỳ vọng là nên tham gia (team phát triển thì chắc chắn phải tham gia đủ rồi).
• Điều thứ 12 trong 12 nguyên tắc của nguyên lý Agile định nghĩa:
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  • Tạm dịch: Một cách thường xuyên, nhóm xem xét lại vào việc làm cách nào để làm việc hiệu quả hơn, và chuyển chúng thành những hành động hợp lý để áp dụng.
• Dịch sang tiếng Việt ta tạm gọi là họp "cải tiến", tiếng Nhật gọi là họp 振り返り(furikaeri).

Giá trị:

• Retrospective là một hoạt động cực kỳ quan trọng trong Agile, nó giúp cả team luôn nhìn nhận đánh giá lại chặng đường phát triển để trở nên tốt hơn, để thích nghi với mọi biến động cũng như giúp cả team cùng cộng tác với nhau để loại bỏ mọi trở ngại mà team gặp phải.
• Retrospective không hiệu quả sẽ dẫn đến việc áp dụng Agile rất khó khăn. Retrospective phải trở thành một thói quen, thành một nét văn hoá của team thì nó mới phát huy hết công lực của nó.

Tuy nhiên để retrospective một cách hiệu quả cũng phải là một điều dễ dàng gì. Những câu hỏi sau giúp đánh giá việc áp dụng retrospective có hiệu quả hay không?

• Retrospective có diễn ra định kỳ trong mỗi chu kỳ phát triển hay không?
• Mọi thành viên trong team có tham gia một cách tích cực không?
• Sau cuối buổi họp có đưa ra được những action cụ thể không?
• Có kế hoạch triển khai action rõ ràng không?
• Những action có đảm bảo được toàn bộ team thực hiện hay không?
• Việc thực hiện những action có được xem xét ở lần họp tới hay không?

Điều quan trọng thường bị hiểu nhầm

Có một số thất bại trong việc thực hiện retrospective như sau:

Team cảm thấy càng ngày càng không hứng thú với họp Retrospective: có thể do nhiều nguyên nhân như là team không thấy được tầm quan trọng cũng như hiệu quả mà Retrospective mang lại, cũng có thể là do việc thực hiện Retrospective lặp đi lặp lại một cách nhàm chán khiến cho các member tham gia một cách gượng ép, không tích cực phân tích và đưa ra các ý kiến.

Hứng lên thì mới làm: việc thực hiện Retrospective hàng cuối mỗi chu kỳ phát triển khiến cho team thấy không cần thiết → quyết định khi thấy team lắm vấn đề thì mới làm.

Các action đưa ra không được team để tâm hoặc không được triển khai một cách tích cực: họp Retrospective xong và đã có được action cụ thể nhưng trong quá trình phát triển ở chu kỳ mới thì team lại không để tâm tới việc thực hiện action lắm khiến cho việc thực thi và triển khai action không hiệu quả → action đưa ra đã không trở thành 1 công việc yêu cầu của chu kỳ phát triển mới.

Chưa lập kế hoạch triển khai action: team đã list ra được action nhưng chưa lên được kế hoạch triển khai action. Một kế hoạch triển khai action phải gồm những yếu tố cơ bản sau:

1. WHAT? mục tiêu là gì
2. WHO? ai chịu trách nhiệm triển khai
3. HOW? triển khai như thế nào
4. WHEN? hạn là tới bao giờ

Những điều quan trọng mà nếu ta không hiểu rõ sẽ dễ dẫn tới việc triển khai Retrospective gặp vấn đề

• Retrospective phải được diễn ra thường xuyên vào cuối mỗi chu kỳ phát triển.
• Toàn team nên tham gia.
• Phải phân tích rõ được root cause (nguyên nhân cốt lõi) + đưa ra action tương ứng để giải quyết.
• Phải lập kế hoạch triển khai action.
• Phải đo lường hiệu quả của action.
• Cuối cùng cũng là cái khó nhất: biến retrospective thành một thói quen, thành một nét văn hoá của team.

Những lưu ý để Retrospective hiệu quả

Những lưu ý sau sẽ giúp chúng ta tổ chức được một buổi Retrospective được hiệu quả:

Giúp team nhận ra rằng những action mà chúng ta đang tìm kiếm là những hành động mà họ có thể làm (trao quyền cho team trong việc lựa chọn action và triển khai) → những action được team lựa chọn và triển khai chứ không phải là những action bị áp đặt.

Tập trung vào việc học (learning) và hiểu (understanding) thay vì khiển trách. → Hãy để nguyên tắc này trở thành một tư tưởng chung cho cả team ngay từ lúc bắt đầu.

Giới hạn số lượng problem cũng như số lượng action mà được đưa ra trong retrospective. Việc có quá nhiều problem cũng như  action sẽ dễ dẫn đến một rủi ro là chúng sẽ không DONE (không được giải quyết) được. Vì vậy tốt hơn là ta nên có một vài action "chất" để triển khai (tập trung vào "chất" hơn là "lượng").

Áp dụng "golden rules for agile process improvement" (nguyên tắc vàng để cải tiến tiến trình agile) để giúp team làm việc nuột, hiệu quả và tích cực hơn. Gồm có 5 nguyên tắc sau

1. Dare to share – As early as possible and frequently (Sẵn sang chia sẻ – ngay khi có thể và diễn ra thường xuyên): thành viên trong team sẵn sàng chia sẻ + cập nhật những tài liệu về quá trình phát triển, mô tả sản phầm, feedback nhận được lên những công cụ hữu hình với toàn team (wiki, google docs,..)
2. The result depends on the team – Not the individual members (Kết quả phụ thuộc vào cả team chứ ko phải từ 1 cá nhân riêng lẻ nào cả)
3. The one who checks out a task is not necessarily the one who has to finish it (Người checkout(rời bỏ task) ko nhất thiết phải là người bắt buộc hoàn thành nó): Team làm việc hỗ trợ, cộng tác với nhau nên hoàn toàn ok khi một ai đó đỏng góp một chút cho product rồi bàn giao lại cho người khác. Nếu member nào muốn đóng góp thêm cho dự án thì member đó chỉ cần chờ cho khi task avaiable thì member đó sẽ đóng góp phần mình muốn đưa vào.
4. The one’s working on a task are the right people (Người đang xử lý task nào thì anh ta luôn là người làm đúng).
5. You may critique anything, but you may never criticize anyone (Bạn có thể phê phán bất kì thứ gì nhưng ko bao giờ được phê phán bất kỳ người nào): Team cần tập trung vào việc hoàn thành product và luôn luôn tin tưởng vào sự đóng góp của các member khác.

Tập trung vào những problem đã được phát hiện 1 cách rõ ràng, hỗ trợ team member tìm được action thiết thực đối với team để giải quyết problem đó, giúp công việc tiến triển hơn.

Sử dụng các phương pháp tìm nguyên nhân gốc rễ (Root Cause Analysis) để tìm nguyên nhân thật sự của problem. Từ đó đưa ra được action để chống tái phát problem đó. Việc hiểu rõ được nguyên nhân gốc rễ giúp team có động lực làm việc hơn.

Theo dõi, khảo sát mức độ hiệu quả của những action để team hiểu được những action có hiệu quả cũng như những action không có tác dụng → hữu hình với toàn team.

Sử dụng những ngón nghề khác nhau, phụ thuộc vào tính chất problem, mindset của team trong việc tiến hành retrospective (toolbox). Những toolbox sẽ được liệt kê ở phần sau trong bài viết này.

Những Toolbox cho Agile Retrospective

1. Asking Questions (Các mẫu câu để hỏi)

Dùng để đặt câu hỏi cho team + tập hợp và phân loại câu trả lời → câu trả lời có thể sử dụng để xác định các action cải tiến thực thi cho chu kỳ phát triển tới.

Sử dụng 4 câu hỏi của Norman Kerth:

1. What did we do well, that if we don’t discuss we might forget? Cái gì chúng ta đã làm tốt mà nếu chúng ta ko trao đổi về nó ngay thì chúng ta có thể quên mất?
2. What did we learn? Chúng ta đã học hỏi được cái gì?
3. What should we do differently next time? Cái gì chúng ta nên thay đổi trong lần tới nhỉ?
4. What still puzzles us? Cái gì vẫn còn là nan giải?

Ngoài ra còn những mẫu câu hỏi sau:

• What helps you to be successful as a team? Cái gì giúp chúng ta trở nên thành công giống như là 1 team?
• How did you do it? Bạn đã làm nó như thế nào?
• Where and when did it go wrong in this iteration? Ở đâu và lúc nào đã khiến nó trở nên sai lầm trong chu kỳ phát triển này?
• What do you expect, from whom? Cái bạn đang mong chờ là gì, và từ ai?
• Which tools or techniques proved to be useful? Which did not? Công cụ hay kỹ thuật nào đã chứng tỏ được sẽ hữu dụng? Cái nào không?
• What is your biggest impediment? Sự trở ngại lớn nhất của bạn là gì?
• If you could change one thing, what would it be? Nếu bạn có thể thay đổi 1 điều, bạn sẽ muốn thay đổi gì?
• What causes the problems that you had in this iteration? Cái gì là nguyên nhân của những problem bạn gặp phải trong chu kỳ  phát triển này?
• Are there things that you can do to these causes? Đó có phải là những điều mà bạn có thể làm để xử lý những nguyên nhân kia?
• What do you need from people outside the team to solve the problems? Bạn cần những gì từ người ngoài team để giải quyết những problem đó?

2. Starfish (Sao biển)

Có thể áp dụng trong mọi trường hợp cũng như bất kỳ team nào.

Là hình tròn gồm 5 phần (tương ứng với 5 cánh của sao biển)

1. STOP: những action không mang lại giá trị cho team → nên dừng lại
2. LESS: những action tốn công sức, tài nguyên nhưng lại mang lại ít hiệu quả → nên hạn chế bớt
3. KEEP: những action đã mang lại hiệu quả tốt → nên tiếp tục áp dụng
4. MORE: những action khả thi có triển vọng → nên phát huy áp dụng hơn nữa.
5. START: những action muốn áp dụng → đưa vào trong chu kỳ phát triển tới.

Các bước tiến hành:

1. Bắt đầu với STOP, cả team brainstorming để liệt kê các ý kiến cho STOP rồi mỗi người dành 2 phút để đọc to lên ý kiến của mình và dành 10 phút để thảo luận về ý kiến đó nếu cần thiết.
2. Lặp lại với LESS, KEEP, MORE
3. Đối với START ta dùng phương pháp vote của Toyota để chọn ra action mà mọi người muốn triển khai hay thảo luận. Sau khi chọn xong thì toàn team sẽ thảo luận về nó để đưa ra đường lối triển khai, bao gồm:

• Người chịu trách nhiệm
• Hạn cuối.
• Và quan trọng nhất là tiêu chuẩn đo lường độ thành công của action.

3. Sailboat (Thuyền buồm)

Vẽ 1 bức ảnh

1. Islands (đảo): mục tiêu (goal) của team
2. The rocks (đá ngầm): những rủi ro team có thể gặp phải trên đường tiến tới mục tiêu của team.
3. The anchor (mỏ neo): những gì đang khiến cho con thuyền bị chậm lại
4. The clouds + the wind (mây và gió): những gì giúp con thuyền tiến nhanh tới mục tiêu (hòn đảo).

Các bước thực hiện:

1. Vẽ bức ảnh gồm 4 thành phần như trên
2. Viết mục tiêu lên đảo
3. Brainstorming để viết các ý kiến vào 3 mục 2,3,4 trong 10 phút.
4. Đọc to các ý kiến + thảo luận để trao đổi thêm về các action ở vùng mây. Những action giúp team tăng tốc hơn.
5. Thảo luận về các action giúp giảm bớt những rủi ro ở vùng đá ngầm.
6. Sử dụng phương pháp voting để chọn những action đưa vào triển khai trong chu kỳ phát triển tới.

Kết luận

• Để áp dụng Retrospective một cách hiệu quả → khó
• Tuy nghiên để team ngày càng trưởng thành hơn, làm việc hiệu quả hơn, và quy trình của team được mượt hơn thì không thể phủ nhận vai trò của Retrospective.
• Để áp dụng Retrospective cho tốt thì mỗi thành viên trong team phải trang bị cho mình kỹ năng phát hiện vấn đề cũng như cách tìm ra hướng giải quyết vấn đề.
• Nên dùng Retrospective để cải thiện chính Retrospective: giúp Retrospective phát huy hiệu quả của nó hơn.

Tham khảo

Bài viết được tổng hợp lại dựa trên kinh nghiệm triển khai của tác giả cũng và tham khảo qua cuốn "Getting Value out of Agile Retrospectives".