- vừa được xem lúc

[PMStarter] Họp Retrospective với phương pháp Mad / Sad / Glad

0 0 25

Người đăng: Tuấn Dương Hồng

Theo Viblo Asia

A/ Retrospective để làm gì

Bao lâu rồi team / department của bạn chưa được retrospecive. Từ lúc mình học về PM, đi vòng quanh hỏi các team trong công ty thì thường mọi người thường bỏ qua cuộc họp này. Hoặc hú họa thì chỉ họp cho có kiểu 10' - 15' nhằm để thảo luận nhanh vấn đề, hoặc căng hơn thì sẽ có tranh cãi ... xong nhanh chóng kết thúc cuộc họp. Cơ bản từ lúc làm Project Manager (PM), mình khá là thích loại cuộc họp này nhất vì thấy nó thật sự hữu ích cho công việc và tinh thần của team mình. Và cũng thể hiện được vai trò của 1 PM / Scrum Master rõ ràng nhất.

Chung quy lại cuộc họp Retro là nơi team nhìn lại, khen ngợi cho những thành công, đưa những vấn đề ra để mổ xẻ, nói ra những tâm tư, khúc mắc của mình để chia sẻ và thấu cảm cùng nhau. Vai trò của PM trong cuộc họp này dẫn dắt, thấu cảm, nhìn nhận vấn đề, cùng giải quyết và gắn kết team lại với nhau.

B/ Phương pháp Mad / Sad / Glad (MSG)

Trên cơ bản thì thường không có hướng dẫn chung nào cho các cuộc họp retro cả. Mỗi PM hoặc mỗi team sẽ tìm ra các để trao đổi và cải tiến lẫn nhau trong dạng cuộc họp này. Bản thân mình là PM cho công ty Tech Product nên thường phải tham gia nhiều team, nên mình thường tìm các cách hay phương pháp khác nhau để apply vào từng team, tùy thuộc theo tính chất và thời điểm làm Retro.

Phương pháp MSG này thúc đẩy các thành viên ghi ra cảm nhận của mình qua các trạng thái MAD / SAD / GLAD

  • MAD: Điều gì, quy trình gì làm bạn khó chịu nhất ? Thường là quy trình, hệ thống hoặc cá nhân mà mình cần thay đổi trong team
  • SAD: Điều gì làm bạn buồn, khoảng khắc hay sự việc gì làm bạn bận lòng.? Thường là cảm xúc, thời điểm hoặc vấn đề gì đó làm team cảm thấy buồn hoặc thất vọng
  • GLAD: Điều gì làm bạn vui, làm bạn cảm thấy hạnh phúc trong suốt quá trình làm việc cùng nhau, điều gì bạn làm tốt, điều gì cần được lan toản nhiều hơn ? Thường là sản phẩm, hay việc áp dụng nào đó thành công, hoặc một cá nhân xuất sắc, cống hiến cho team và cần được tuyên dương

Việc sử dụng MSG giúp cho

  • Chia sẻ những cảm xúc giúp team đồng cảm và tăng tinh thần làm việc
  • Có được thông tin và insight quan trọng về cho việc hệ thống, quy trình tác động tới tâm trạng của team như thế nào
  • Thích hợp để đo lường cảm xúc của các thành viên sau 1 sprint / campaign hay một sự kiện nào đó

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

Trong bài viết này, mình sẽ chia sẻ format MSG ở dạng họp offline, ở một phòng họp cố định nhé. Về việc họp online thì mình thấy có một sổ platform hỗ trợ, nhưng mình chưa thử nên chưa dám share😄

C.1/ Chuẩn bị

C.1.1/ Dụng cụ trong buổi họp

  • Board & bút viết: Buổi họp này thuộc về họp brainstorm nên sẽ rất cần board và bút để các thành viên theo dõi được nội dung. Hãy đảm bảo phòng họp bạn đặt có board và có bút nhé
  • Giấy notes & viết: Mình sẽ cần notes cho tất cả thành viên. Kinh nghiệm của mình là đừng tiết kiệm, đủ note cho thành viên để họ có thể open viết ngay và luôn. Tránh chờ đợi để mượn viết nhau, nhiều khi sẽ quên ý tưởng đó
  • Nước: Nghe có vẻ lạ, nhưng nó cần thiết. Bạn sẽ cần nói nhiều, đừng để mình và các thành viên bị khát. Và thật ra order nước cho team cũng là một ý hay. Tin mình đi, mọi người được uống nước sẽ thấy thoải mái hơn

C.1.2/ Vẽ hình trên board

Một vài gợi ý trên internet là in hình ra, nhưng cơ bản là mình thích vẽ dù mình vẽ ... khá tệ🙂. Việc minh họa MSG một cách vui nhộn cùng team cũng là insight thú vị của PM đấy, không cần quá đẹp miễn là gần gũi với team

Hãy kèm theo hashtag hoặc gợi ý cho từng MSG sẵn trên board, đó sẽ là keyword để giúp cho team ghi note đó

Image_20230217_172951_494.jpeg

C.2/ Bắt đầu

C.2.1/ Share về mục tiêu của buổi Retro

Buổi họp nào cũng cần mục tiêu. Hãy chia sẻ cho team bạn biết mình vì sao phải retro, retro mang lại điều gì cho team. Hãy tạo cho team cảm giác thoải mái, để họ biết buổi này là thời điểm để mình trải lòng và chia sẻ thay vì để trách hay đổ trách nhiệm.

Và đừng quên time-box cho buổi họp của mình nhé. Những buổi họp dạng này nếu không quản lý thời gian tốt sẽ dễ bị lạc trôi. Theo Scrum chuẩn thì retro không quá 3 giờ, mình thường apply cho team 1h30 thôi. Để tránh tốn quá nhiều thời gian mọi người.

C.2.2/ Giải thích nhanh về luật MSG

Giải thích thật nhanh về Mad / Sad / Glad, cho vài ví dụ minh họa và quan sát thái độ của team mình để đảm bảo là team đều hiểu và hứng thú với trò chơi bạn đề ra.

Luật chơi mình gợi ý

  • Tùy thuộc số lượng thành viên, thường để thời gian 5' - 10' để viết và dán note
  • Quy định mỗi thành viên có số lượng note tối thiểu nếu cần nhé. Để tránh làm vỡ chiến thuật retro của bản thân mình🙂
  • Mỗi note nên có đánh dấu. Ví dụ ghi M hay S hay G cho từng note để dễ thống kê sau buổi họp nhé

C.2.3/ Chơi game

Hãy gợi mở và khuyến khích các thành viên thực hiện việc ghi ra các cảm nghĩ của mình. Có thể cho ví dụ về các vấn đề đang có trong nhóm. Hoặc chính bản thân các bạn hãy ghi ra và thực hiện gắn note trên board. Điều này sẽ thúc đẩy các thành viên mở lòng và thực hiện theo đấy.

Có thể mở vài bài nhạc không lời, vỗ vai các thành viên để khuyến khích tinh thần, dẫn họ đi ra khỏi chỗ ngồi. Vài động tác hình thể sẽ làm các thành viên thoát khỏi sự gò bó của công việc thường ngày. Tùy thuộc vào mức độ gắn kết của bạn với team mà chọn chiến thuật thực hiện nhé.

Image_20230217_172951_269.jpeg

C.3/ Tổng hợp

Tùy thuộc theo số lượng note bạn có trên board mà bạn sẽ chọn chiến thuật để xử lý các note đó như thế nào. Sau đây là một vài gợi ý của mình

  • Hãy nói về GLAD trước: Mình thường sẽ nói về GLAD trước, những điều vui vẻ luôn làm chúng ta thoải mái và dễ mờ lòng hơn. Đừng quên cho team hoặc thành viên một tràng vỗ tay để tán dương cho những thành công nha. Sau đó sẽ là SAD, về những chia sẻ, thất vọng và nỗi buồn. Chỗ này nếu PM host thì có thể sử dụng kỹ năng thấu cảm (Empathy), quan sát, dùng eye contact để phân tích và điều phối cảm xúc các thành viên cho hợp lý nha. Cuối cùng sẽ là MAD, đây thường sẽ là nhóm VẤN ĐỀ (problem), nhóm chúng ta muốn thay đổi, hãy để ý không khí buổi họp trong session này để quản lý xung đột khi cần nhé
  • Kêu gọi sự đồng tình: Hãy hỏi team và thành viên "Có ai thấy giống vậy không ?" "Chúng ta đã ... như vậy đúng không mọi người?" Dùng voting để thu thập ý kiến nhé. Xong hãy ghi lại số lượng để chúng ta có được những sự kiện / vấn đề được nhiều thành viên cảm nhất cho session sau nè
  • Hãy đi qua tất cả các note: Hãy đọc to và đi qua hết các card, có thể chia chúng theo những danh mục (ví dụ quy trình, tiến trình nghề nghiệp, môi trường, ...) để bạn để quản lý và phản hồi chung cho nhóm vấn đề. Đối với những vấn đề (thường ở MAD) thì bạn sẽ cần ghi lại trên board và số lượng voting để chúng ta brainstorm lúc sau

C.4/ Giải quyết vấn đề

Hãy xem thời gian và thống nhất với team mình về số lượng vấn đề chúng ta sẽ giải quyết. Đôi khi trong buổi đó chúng ta chỉ cần tập trung thảo luận 1-2 vấn đề quan trọng thôi. Đừng quá tham lam, có những vấn đề khi giải quyết được sẽ mang được hiệu quả rất lớn hoặc giải quyết được luôn các vấn đề khác luôn đó. Hãy có chiến thuật khi lựa vấn đề giải quyết nhen. Một vài tips và bước mình hay thực hiện

  • Lặp lại vấn đề và kêu gọi thảo luận chung: Hãy khuyến khích team mô tả lại vấn đề lại nữa. Chỉa sẻ cảm nghĩ về vấn đề để có thêm thông tin về nó
  • Hãy cố gắng tìm nguồn gốc phát sinh (Root cause): Một trong những lỗi sai thường gặp là chúng ta hay đi thẳng vào giải pháp. Thường nó sẽ work với những trường hợp khi có sự cố hoặc khẩn cấp (Incident). Còn vấn đề thì nên tìm root cause. Hãy thử vài phương pháp phân tích vấn đề nhé, mình thường sử dụng 5 Whys để trace thử vài round của vấn đề với team
  • Để team cùng lên giải pháp: Sau khi chắc mình đã đủ thông tin thì hãy kêu gọi giải pháp cùng team. Việc cả team cùng lên giải pháp sẽ kêu gọi được sự tự giác và cam kết của thành viên. Hãy liên tục khai vấn (coach) team rằng chúng ta khi làm giải pháp đó đã giải quyết được vấn đề chưa ? Hỏi ý kiến tất cả thành viên để có số phiếu vote cao nhất cùng thực hiện nha
  • Lên kế hoạch thực hiện: Hãy đưa các bước cần làm và thời gian cụ thể nhằm chắc là giải pháp của team khả thi và sẽ được thực hiện nha
  • Cuối cùng là ... take notes và document lại: Trong kỹ thuật dự án có một loại tài liệu là Lesson Learned, hãy note các bài học này vào trong đó xuyên suốt quá trình dự án của bạn nhé. Các notes và quá trình brainstorm cũng cần note và lưu trữ lại khi team cần nhé

Nên vẫn lưu ý thời gian buổi họp, nếu chúng ta đã quá giờ thì hãy tập trung chốt giải pháp và kế hoạch áp dụng thay vì chốt sơ sài rồi qua vấn đề khác nhé. Quan trọng của buổi Retro là kết quả cải tiến và sự đồng lòng thực hiện của các thành viên nhé.

D/ Kết luận

Phương pháp Mad Sad Glad không phải là phương pháp duy nhất cũng như hữu dụng nhất trong các tất cả buộc họp Retro, nhưng đây là phương pháp truyền thống và thường được áp dụng để thu thập cảm xúc, vấn đề phiền lòng của các thành viên sau một khoảng thời gian hoặc sự kiện nào đó. Hãy đảm bảo là bạn chọn đúng phương pháp để buổi Retro của mình được hiệu quả nhé. Chung quy vai trò của người PM sẽ là người hỗ trợ (facilitator), người chủ trì (host) nhằm đảm bảo team / department mình được chỉa sẻ, thảo luận và cải tiến mỗi ngày cùng nhau là được. Chúc các bạn có buổi họp Retro thành công nhé.

Bình luận

Bài viết tương tự

- vừa được xem lúc

Các mô hình phát triển phần mềm

1. Định nghĩa. Mô hình phát triển phần mềm hay quy trình phát triển phần mềm xác định các pha/ giai đoạn trong xây dựng phần mềm. Có nhiều loại mô hình phát triển phần mềm khác nhau ví dụ như:.

0 0 112

- vừa được xem lúc

Tìm hiểu về cách thiết kế Class Diagram

Trong 1 dự án, việc tổ chức code cũng như clean code là 1 điều rất quan trọng, nếu cách thiết kế các class hợp lý và rõ ràng sẽ giúp ích rất nhiều cho việc mở rộng và bảo trì sau này. Để làm được điều này chúng ta cần phải có 1 bản thiết kế Class Diagram thật sự hợp lý.

0 0 92

- vừa được xem lúc

Chuyện thay đổi

Thay đổi là một thứ gì đó luôn luôn đáng sợ. Cách đây vài tháng mình có duyên đi làm cho một banking solution tên là X.

0 0 47

- vừa được xem lúc

Tôi trên con đường nỗ lực trở thành Agile Leader - Phần I

Mong muốn chia sẻ với mọi người về những trăn trở, những niềm vui, những bài học tích lũy, những mảnh kiến thức hay góp nhặt được trên con đường phấn đấu trở thành một Agile leader. Phần đầu này tôi muốn chia sẻ về định hướng, hay nói cách khác là điều gì cá nhân cần tập trung để trở thành một Agile

0 0 30

- vừa được xem lúc

9 ý tưởng cho buổi Retrospective hiệu quả!

Với những bạn đang vận hành dự án theo Scrum hoặc ít nhất đang cố gắng thử vận hành, ắt hẳn biết đến một scrum event quan trọng - Retrospective. Một event để scrum team cùng nhìn nhận lại lại cách thức làm việc, hợp tác với nhau hay nói chung là các vấn đề về quy trình, con người trong dự án.

0 0 71

- vừa được xem lúc

Mô hình phát triển phần mềm: Agile

1. Agile là gì. 2. Phát triển phần mềm theo Agile.

0 1 634