Những điều cần tránh trong buổi Sprint Retrospective

Có rất nhiều hiểu lầm, và hiểu sai cũng như những hạn chế khiến các Scrum team không thể nhận được giá trị thực tế mà Scrum có thể mang lại. Một trong những hiểu lầm và hiểu sai, trực tiếp ảnh hướng đến chủ nghĩa kinh nghiệm, và khiến team áp dụng Scrum cũng như không, đó là: Không có được một buổi Sprint Retrospective đúng nghĩa. Dưới đây tôi sẽ liệt kê qua 9 những sai lầm hay mắc phải của một Scrum team về buổi Sprint Retrospective của mình. Hi vọng rằng sẽ giúp được các Scrum team tránh và có thể tổ chức một buổi Sprint Retrospective hiệu quả hơn.

Không có buổi Sprint Retrospective nào cả

Vâng! Đây là sai lầm thường gặp nhất của Scrum team cho buổi Sprint Retrospective. Có rất nhiều Scrum team không thực hiện, hoặc không đủ thời gian để thực hiện một buổi Sprint Retrospective. Khi được hỏi lý do vì sao, thì thường tôi nhận được những câu trả lời như sau:

• Áp lực công việc dồn dập quá, team không có thời gian để thực hiện: Cấp trên yêu cầu cao trong việc delivery khiến team không có thời gian để dành cho những event như Sprint Retrospective, là một trong những câu trả lời tôi nhận được nhiều nhất. Những Scrum team này đa phần còn mắc nhiều vấn đề khác kèm theo vì không hiểu được giá trị của Scrum và Agile mang lại. Nguyên nhân chính là do vai trò Scrum Master hoặc sự hiểu đúng về và Agile/ Scrum của tổ chức có phần chưa được tốt. Nên sau một thời gian áp dụng, tổ chức không nhận được kết quả hay thay đổi. Lúc này, sự kiên nhẫn của tổ chức sẽ dần kém đi và tăng áp lực lên Scrum team, khiến việc áp dụng Scrum sẽ ngày càng xa vời. Hoặc thậm chí còn có trường hợp cấp lãnh đạo muốn áp dụng Scrum nhưng chưa tìm hiểu kỹ, và chưa có mindset phù hợp dẫn đến hiểu sai và có những cách tiếp cận Scrum team chưa hợp lý.
• Không thấy được giá trị của buổi Sprint Retrospective nên bỏ qua nó, dành thời gian để xây dựng sản phẩm: Đây cũng là một vấn đề liên quan đến việc, vai trò Scrum Master đang thiếu hoặc không có được một Scrum Master đúng nghĩa. Scrum team không được hướng dẫn hỗ trợ để có được những giá trị đúng mà event này mang lại. Thay vào đó những buổi Sprint Retrospective có thiên hướng chỉ trích, cãi vã và một số hành vi không phù hợp. Sau đó dẫn đến sự ngán ngẩm, mất lòng tin và không ai còn coi trọng hay muốn dành thời gian cho Sprint Retrospective cả.
• Không biết Sprint Retrospective là gì, chưa nghe qua bao giờ: Vâng, bạn không hề đọc lầm đâu. Việc không được trang bị kiến thức cũng như hỗ trợ đúng, nhiều Scrum team đã tự học và áp dụng Scrum theo kiểu "thầy bói xem voi", và sau đó áp dụng kiến thức không đầy đủ đó vào công việc. Dẫn đến nhiều Scrum team vẫn đang “cố gắng” áp dụng Scrum mà không hề biết Sprint Retrospective là gì!?

Có người ngoài Scrum team tham dự buổi Sprint Retrospective  

Có nhiều Scrum team thực hiện buổi Sprint Retrospective công khai với các bên liên quan, vì nhiều lý do khác nhau. Như CEO hay ai đó có thẩm quyền yêu cầu Scrum team phải cho họ tham dự Sprint Retrospective. Tôi cũng từng gặp rất nhiều yêu cầu như vậy từ các bên liên quan vì họ muốn biết xem Scrum team đang hoạt động thế nào - và dĩ nhiên phải có sự giải thích phù hợp cho họ hiểu vì sao Sprint Retrospective chỉ nên dành cho riêng Scrum Team, vì việc Scrum yêu cầu chỉ có Scrum team tham dự buổi Sprint Retrospective là có lý do. Việc Scrum team tự quản và thảo luận làm thế nào để có một Sprint làm việc tốt hơn với nhau là rất cần thiết và tế nhị. Có rất nhiều chủ đề các cá nhân chỉ thoải mái và chia sẻ khi họ cảm thấy an toàn, nên việc có người ngoài, hay cấp trên tham dự thường sẽ khiến buổi Sprint Retrospective có thể trở nên giả tạo, hoặc sẽ vô tình khuyến khích Sprint Retrospective thành buổi chứng tỏ năng lực cá nhân với lãnh đạo.

Scrum Master rất cần cho việc hỗ trợ Scrum team trong những yêu cầu của người ngoài muốn tham dự Sprint Retrospective như trên. Nếu không mục đích chính Sprint Retrospective sẽ không còn đúng nữa, thay vào đó sẽ là buổi event giả tạo mà thôi.  


Có Sprint Retrospective nhưng không có một action item nào được thống nhất  

Rất nhiều team có những buổi Sprint Retrospective rất tốt, nhưng lại thiếu việc xác định làm thế nào để làm tốt hơn trong Sprint sau, hay/ hoặc tham lam và đặt quá nhiều action item để làm, nhưng lại không theo đuổi một cái nào cụ thể cả. Kết quả là, Sprint Retrospective trở thành một event vô nghĩa, sau vài Sprint, các team sẽ bắt đầu nhàm chán, và không thấy được Sprint Retrospective có giá trị gì nữa, vì chẳng có thay đổi hay tiến bộ nào xảy ra.  


Buổi Sprint Retrospective chỉ là để team khen nhau, đâu lại vào đấy  

Một trong những sai lầm nữa tôi hay thấy, đó là nhiều Scrum team thực hiện buổi Sprint Retrospective như một buổi khen thưởng thành tích. Nhóm chỉ tập trung vào những điều mình đã làm tốt nhưng quên mất việc làm thế nào để làm tốt hơn. Chỉ khen thưởng chính mình mà quên việc ngày càng trở nên tốt hơn, cũng sẽ là cái bẫy, chục Sprint sau vẫn như ngày đầu, từ từ khiến Scrum team không còn nhận được giá trị chính mà Sprint Retrospective mang lại.  


Thực hiện Sprint Retrospective ở quán beer  

Cả team vui vẻ cùng nhau sau giờ làm việc căng thẳng là một hoạt động tốt, nhưng mặc định thực hiện Sprint Retrospective ở quán beer sẽ là một câu chuyện khác. Việc thiếu nhận thức về sự khác nhau giữa team bonding và Sprint Retrospective tạo ra nhất nhiều tai hại. Mục tiêu của Sprint Retrospective là để Scrum team tìm cách để Sprint sau trở nên thú vị hơn cùng nhau (công việc). Còn team bonding là một hoạt động giúp nhóm xả stress và gắn kết hơn. Ngắn gọn là, làm sao để team cùng nhau tìm cách hay làm thế nào để làm tốt hơn trong Sprint sau khi đã ngà ngà say? Chưa nói đến cũng có nhiều thành viên không thoải mái khi phải tham dự và phải uống beer, dẫn đến việc không tham dự, hoặc bị miễn cưỡng tham dự vì không muốn mất lòng số đông. Có nhiều người đã phàn nàn rằng có có cảm giác bị cô lập khi từ chối tham dự Sprint Retrospective tại quán beer, và điều đó làm họ có hiểu lầm và có ác cảm với Sprint Retrospective.

Lời khuyên của tôi là nên tách rời team bonding và Sprint Retrospective ra và trả mỗi cái về đúng ý nghĩa của nó, việc gom lại như vậy không lợi gì mà còn gây nhiều hiểu lầm và tai hại. Sẽ không có vấn đề gì nếu team thực hiện Sprint Retrospective sau đó mời nhau một bữa tiệc tối cả.  


Không có Scrum Master/ hoặc không có Scrum Master thực sự để facilitate cho buổi Sprint Retrospective  

Dạo gần đây tôi bắt đầu thấy có nhiều Scrum team áp dụng Scrum nhưng không có  Scrum Master. Những team này thường là có một người (Developer) kiêm vai trò Scrum Master, hoặc thậm chí không có. Việc thiếu nhận thức về vài trò  Scrum Master và xem Scrum Master là một vai trò dễ, cấp thấp, ai làm cũng được, bổ nhiệm Scrum Master như một junior Project Manager, và PM sẽ trông nom một nhóm Scrum Master là một sai lầm vô cùng tai hại. Tôi nhấn mạnh là vô cùng tai hại. SM và PM là hai công việc khác nhau, và không liên quan gì đến nhau. Vậy làm sao lại có thể để một công việc không liên quan làm quản lý một công việc không liên quan khác!?

Thiếu sự chuẩn bị và hiểu biết đúng về Scrum là nguyên nhân của những sai lầm trên. Vai trò Scrum Master là một True Leader, không phải là một Manager. Vai trò Scrum Master rất khó đảm đương, và hơn hết để làm tốt Scrum Master, cá nhân đó phải có được kiến thức đúng và những kỹ năng cần thiết trước khi đảm nhiệm. Việc không đầu tư đúng, bổ nhiệm một người chưa đủ khả năng, hay kiến thức để làm Scrum Master, sẽ khiến cho Scrum team của bạn có một SM bù nhìn, và dẫn đến không chỉ Sprint Retrospective mà cả Scrum team đó không có Scrum Master nào để hỗ trợ cả.  


Không có Product Owner trong buổi Sprint Retrospective  

Có nhiều Scrum team không xem Product Owner là một thành viên trong Scrum team, hoặc thậm chí không có một vai trò Product Owner nào cả. Việc này dẫn đến hậu quả vô cùng lớn là Scrum team như một nhà máy sản xuất, ai kêu gì làm đó, luôn làm task này đến task khác, nhưng không hiểu đang đóng góp gì cho sản phẩm hay tổ chức. Việc thiếu vai trò Product Owner khiến team không có định hướng và dĩ nhiên trong câu chuyện này, là không có Product Owner cũng sẽ không thể có một buổi Sprint Retrospective hiệu quả được.  


Không phân biệt được Sprint Retrospective và Sprint Review  

Hiểu lầm này bắt nguồn từ việc hiểu chưa đúng mục đích của mỗi event trong Scrum, trong đó Sprint Retrospective là để Scrum team thảo luận về cách làm việc cùng nhau, và làm cùng nhau tốt hơn như thế nào trong Sprint sau. Còn Sprint Review là event mà Scrum team và Stakeholder cùng nhau thảo luận về sản phẩm, và Done Increment.  


Scrum Master không biết cách facilitate một buổi Sprint Retrospective  

​Hiểu lầm này có liên hệ với vấn đề tôi đề cập ở trên trong việc không có Scrum Master thực sự để facilitate Sprint Retrospective. Nhưng nó ở mức nhẹ hơn, đó là Scrum team có Sprint Retrospective nhưng hiện Scrum Master này đang cần những kỹ năng cần thiết để facilitate các event trong Scrum. Đây thường là các bạn Scrum Master mới, và nếu được hướng dẫn hỗ trợ, các Scrum Master này sẽ nhanh chóng biết cách và phát triển kỹ năng cần để có thể hỗ trợ Scrum event trong thời gian ngắn.

Tôi hi vọng những chia sẻ trên sẽ giúp bạn tránh được những sai lầm không đáng có trong việc áp dụng Scrum. Scrum không khó, nhưng để áp dụng Scrum rất khó, nó đòi hỏi phải có sự chuẩn bị về kiến thức đúng, và đầu tư đúng. Việc hiểu sai hay đánh giá thấp những vai trò hay sự kiện trong Scrum sẽ trực tiếp ảnh hưởng đến giá trị mà Scrum có thể mang lại cho sản phẩm và tổ chức của bạn.

Scrum on!

---

Tác giả: Khoa Doan
Khoa is one of 350 Professional Scrum Trainers (PST) of Scrum.org in the world and the first PST in Vietnam. He is ICF - Professional Certified Coach (PCC level). Besides that, Khoa is the Founder of Scrumviet - Professional Training Network (PTN) of Scrum.org. He is the host and organizer of Scrum day Vietnam.

---

 

---

Những bài viết khác có thể bạn sẽ quan tâm