Scrum Master giải quyết MỌI VẤN ĐỀ

 Hiểu lầm này là về cách giải quyết vấn đề đang cản trở Nhóm Phát triển thực hiện công việc của họ. Từ những vấn đề như hỏng bộ phát wifi cho tới các yêu cầu liên quan đến từ các cuộc họp bên ngoài nhóm. Từ làm rõ các công việc không hiểu rõ tới giải quyết mâu thuẫn nội bộ.

Chúng tôi đã gặp khá nhiều nhóm mà Scrum Master phải dành toàn bộ thời gian để giải quyết các vấn đề nêu trên, hay nói cách khác là giải quyết các “trở ngại”. Một vài Scrum Master đã mất rất nhiều thời gian để thiết lập “Impediment Board” (bảng các trở ngại) và mời các thành viên Nhóm Phát triển điền thêm các cản trở mới vào để “xử lý” chúng. Ngày hôm nay, chúng ta sẽ tìm hiểu về hiểu lầm rằng trách nhiệm của Scrum Master là giải quyết mọi vấn đề đang cản trở Nhóm Phát triển.

Giải mã hiểu lầm

Trong Hướng dẫn Scrum (Scrum Guide) mô tả các “dịch vụ” khác nhau mà Scrum Master cung cấp. Một trong số đó là loại bỏ các trở ngại trong quá trình làm việc của Nhóm Phát triển. Trước tiên, chúng ta thấy việc này dường như củng cố cho vấn đề này. Nhưng trở ngại là một từ khoá quan trọng ở đây. Những cản trở dường như xuất hiện quá thường xuyên, do đó bất cứ vấn đề gì xuất hiện trong Sprint sẽ mặc định được coi là “chướng ngại vật”. Nhưng đây không phải là cách mà chúng ta hiểu về trách nhiệm này của Scrum Master.

Điều gì tạo ra các “chướng ngại vật”?

“Chướng ngại vật” là những vấn đề gây cản trở tiến trình của một Nhóm Phát triển và nằm ngoài khả năng giải quyết của họ. Điều này có nghĩa là, các trở ngại có mối quan hệ mật thiết tới một khái niệm quan trọng khác của Scrum đó là Tự tổ chức (self-organization). Những ý nghĩa đằng sau trách nhiệm này đó là – phát triển phần mềm là nỗ lực rất phức tạp và khó tiên lượng – nhiều loại vấn đề không mong đợi có xu hướng xảy ra trong Sprint. Những vấn đề ví dụ như:

• Thành viên nhóm bị ốm
• Các vấn đề với môi trường phát triển
• Máy tính bị hỏng
• Product Owner vắng mặt
• Mâu thuẫn trong nội bộ nhóm
• Bug xảy ra trong môi trường sản xuất

Một yêu cầu được đặt ra cho các Nhóm Phát triển, đó là sử dụng chuyên môn, khả năng sáng tạo và trí thông minh để giải quyết vấn đề. Trong Scrum, bản chất tự tổ chức của một nhóm có thể được hiểu bằng năng lực giải quyết các vấn đề gặp phải mà không phải phân bổ quyền giải quyết vấn đề đó cho người ngoài nhóm. Với cách đó, chúng tôi muốn giải thích các cản trở như những vấn đề mà khi được giải quyết sẽ cải thiện các cơ hội, do đó Nhóm Phát triển có thể tự giải quyết các vấn đề tương tự trong tương lai.

Nhiều dạng vấn đề có thể giải quyết được bởi Nhóm Phát triển, như làm rõ các đặc tả không rõ ràng, sửa lỗi trên sản phẩm đã triển khai hoặc thậm chí đưa ra giải pháp cho một mâu thuẫn trong nhóm.

Sự khác nhau là rất nhỏ nhưng hậu quả thì không. Liệu một Nhóm Phát triển có thật sự tự tổ chức khi tất cả các vấn đề xảy ra đều cần Scrum Master giải quyết? Điều gì xảy ra khi chỉ Scrum Master có thể giúp Nhóm Phát triển làm rõ với Product Owner các đặc tả chưa rõ ràng, hoặc phân tách một công việc có khối lượng quá lớn? Điều gì sẽ xảy ra khi chỉ Scrum Master mới có thể giải quyết các vấn đề liên quan tới cơ sở hạ tầng? Một Scrum Master giải quyết hầu hết các vấn đề xảy ra thì không phải là đang giúp đỡ nhóm. Mà anh ấy đang chủ động cản trở khả năng (sự trưởng thành) của Nhóm Phát triển trong việc giải quyết vấn đề của riêng họ.

Các vấn đề và trở ngại trong thực tế

Sẽ rất mơ hồ nếu như toàn bộ bài viết này dành để nói về “tự tổ chức” và “các trở ngại”, do vậy chúng ta sẽ đi vào tìm hiểu thông qua các ví dụ thực tế.

VÍ DỤ #1: Các vấn đề liên quan tới cơ sở vật chất/hạ tầng

Giả sử một Nhóm Phát triển gặp vấn đề về hạ tầng. Nhóm không thể triển khai các ứng dụng, do vậy họ phụ thuộc vào một nhóm khác. Vào ngày trước buổi Sơ kết Sprint, Nhóm Phát triển có vấn đề với một bản triển khai. Trở ngại này được đưa ra trong buổi Scrum Hằng ngày, Scrum Master đã phải tự mình giải quyết vấn đề này.

Vấn đề này chỉ là triệu chứng của một trở ngại sâu xa hơn; đó là khả năng không thể tự giải quyết vấn đề của Nhóm hoặc ít nhất giải quyết vấn đề liên quan tới việc triển khai. Bằng cách chỉ giải quyết vấn đề khi cấp bách, Scrum Master không thực sự giúp Nhóm Phát triển cải thiện khả năng giải quyết các vấn đề tương tự. Thay vào đó, Scrum Master có thể chỉ ra trở ngại thực sự bằng cách giúp Nhóm tìm ra cách giải quyết cho những vấn đề đó. Một giải pháp có thể là bổ sung kĩ năng hoặc nhân sự cần thiết vào nhóm để giải quyết vấn đề. Một giải pháp khác có thể cho Nhóm Phát triển thiết lập và quản lý cơ sở hạ tầng của riêng họ (DevOps). Một giải pháp “low-tech” hơn đó là tạo ra các kênh giao tiếp giữa Nhóm Phát triển và người có khả năng giải quyết vấn đề với việc triển khai (ví dụ như các liên lạc viên). Dù giải pháp là gì đi chăng nữa, chúng nên xuất phát từ Nhóm Phát triển với sự trợ giúp của Scrum Master.

VÍ DỤ #2: Mâu thuẫn nội bộ

Một ví dụ khác. Giả sử Nhóm Phát triển đang phải đối mặt với mẫu thuận giữa hai thành viên. Thay vì nói về bản thân vấn đề, Scrum Master được giao nhiệm vụ giải quyết mâu thuẫn. Trở ngại thật sự ở đây là việc nhóm không có khả năng giải quyết mâu thuẫn của mình. Có lẽ bên trong nhóm có tâm lý không an toàn để có thể nói về việc đó. Hoặc mọi người không biết cách để nói ra mâu thuẫn hay không dũng cảm để thực hiện điều đó. Bằng cách chỉ giải quyết vấn đề, Scrum Master không giúp Nhóm phát triển kĩ năng giải quyết các vấn đề tái diễn trong tương lai. Thay vào đó, Scrum Master có thể hỗ trợ tổ chức một phiên “giải quyết căng thẳng”, trong đó, những cảm xúc khó chịu được nêu ra và nhóm sẽ dàn xếp cùng nhau (thay vì được giao cho vấn đề). Scrum Master có thể làm mẫu cho hành vi cần thiết để giải quyết mâu thuẫn, như hỏi các câu hỏi mở, thể hiện sự cảm thông và tìm ra điểm chung, sau đó mời các thành viên nhóm làm điều tương tự.

VÍ DỤ #3: Thiếu việc

Ví dụ cuối cùng, giả sử Nhóm Phát triển thấy rằng một nửa thành viên không có gì để làm. Điều này được đưa ra như một trở ngại trong buổi Scrum Hằng ngày, Scrum Master được giao thêm nhiệm vụ là tìm công việc cho họ làm. Trở ngại thật sự ở đây là Nhóm Phát triển hiển nhiên không hợp tác nhằm thúc đẩy tất cả mọi người đóng góp, để đạt được Mục tiêu Sprint. Thay vì tìm kiếm công việc, Scrum Master nên điều tra xem điều gì đang thật sự xảy ra trong nhóm. Anh ấy sẽ chỉ ra điều này trong một chủ đề của buổi Cải tiến Sprint. Hoặc có lẽ Nhóm Phát triển không biết đến các phương pháp có thể thúc đẩy việc hợp tác, ví dụ như lập trình cặp hoặc theo nhóm, hay chia nhỏ công việc, hoặc kiểm tra công việc của nhau. Hoặc có thể trong nhóm có những người đang cư xử như là “trụ cột của nhóm” và làm số lượng lớn công việc, và những người còn lại thực hiện các công việc nhỏ nhặt khác. Dù theo cách nào đi chăng nữa, Scrum Master có thể giúp Nhóm Phát triển trở nên tự tổ chức hơn bằng cách tìm ra giải pháp cho những trở ngại đó, chứ không phải cho các vấn đề được nêu ra trong Scrum Hằng ngày.

Một số trở ngại trong quá trình làm việc của Nhóm phát triển

Trở thành một Scrum Master thành công có nghĩa là…

Scrum Master thành công giúp Nhóm Phát triển nâng cao khả năng giải quyết các vấn đề của riêng họ. Đây là điều mà các nhóm phải học và Scrum Master giúp họ thực hiện được điều đó. Những điều có thể được coi là trở ngại ở Sprint 1 rất có thể sẽ trở thành vấn đề thật sự mà nhóm có thể dễ dàng xử lý trong Sprint 5. Nếu bạn muốn biết bạn có đang làm tốt nhiệm vụ của một Scrum Master hay không, hãy giám sát năng lực của Nhóm Phát triển khi họ giải quyết các vấn đề của riêng họ trong một thời gian. Nếu thấy năng lực có tiến triển, bạn đang làm rất tốt công việc của mình.

Vậy là Scrum Master không bao giờ giải quyết vấn đề?

Liệu điều này có đồng nghĩa với việc Scrum Master không giải quyết vấn đề gì? Dĩ nhiên là không. Scrum Master vẫn là một phần của Nhóm Scrum. Scrum Master có thể sẽ phải sửa bộ phát wifi bị hỏng nếu Nhóm Phát triển đang hoàn toàn tập trung vào giải quyết một vấn đề lớn liên quan tới kĩ thuật. Hoặc Scrum Master có thể hỗ trợ Nhóm Phát triển trong buổi họp phân tách công việc để họ có thể dễ dàng thực hiện trong Sprint, Giải quyết các vấn đề cho Nhóm Phát triển hoàn toàn có thể chấp nhận được nếu được thực hiện đúng mục đích, nhưng cần lưu ý không làm điều này quá thường xuyên. Trước khi giải quyết một vấn đề, cân nhắc nếu như bạn đang thật sự giúp Nhóm Phát triển gia tăng năng lực giải quyết các vấn đề tương tượng của riêng họ. Hãy nhớ rằng “Scrum Master nên Gợi mở, chứ không Giải quyết.”

Mẹo

• Đừng đợi đến buổi Scrum Hằng ngày mới đưa ra các trở ngại. Hãy coi Scrum Hằng ngày là cơ hội tối thiểu nhất để thảo luận các trở ngại. Những cản trở thực sự tới tiến trình của nhóm cần được thảo luận ngay lập tức.
• Bất cứ khi nào một chướng ngại tiềm năng được nêu ra, hãy cân nhắc những việc có thể xảy đến nếu như bạn không làm gì cả. Sẽ có ai khác trong Nhóm Phát triển lo việc này chứ?
• Không có vấn đề gì nếu phải dùng tới “Impediment Board”, nhằm minh bạch những trở ngại đã được loại bỏ. Nhưng cần đảm bảo rằng chúng được dùng cho những trở ngại thực sự, chứ không phải dành cho bất cứ vấn đề gì mà Nhóm Phát triển thấy cần phải “đùn đẩy” sang cho Scrum Master. Ngoài ra, hãy đảm bảo rằng chiếc bảng là của toàn bộ Nhóm Scrum, chứ không phải dành riêng cho Scrum Master.
• Không phải mọi trở ngại đều quan trọng. Sử dụng Mục tiêu Sprint như một kim chỉ nam hướng dẫn. Là Scrum Master, bạn nên làm việc với các trở ngại đang có khả năng cản trở Nhóm Phát triển đạt được Mục tiêu Sprint. Tập trung vào những trở ngại trước khi giải quyết bất cứ thứ gì khác;
• Hãy dũng cảm và sáng tạo trong việc xoá bỏ các trở ngại. Hãy nhớ “Một Scrum Master giỏi sẽ thúc đẩy các ý kiến nhằm xoá bỏ những cản trở tới năng suất nhóm. Một Scrum Master vĩ đại sẽ luôn sẵn sàng để xin được tha thứ.” (Geoff Watts – Scrum Mastery)
• Một trong những công cụ mạnh mẽ nhất của huấn luyện viên là sử dụng quyền im lặng. Giữ im lặng và quan sát điều gì sẽ xảy ra tiếp theo. Đó cũng là cách mà Scrum Master nên hành động. Như là một thí nghiệm bạn không cần làm gì và hãy quan sát điều gì sẽ xảy ra.
• Hợp tác với Product Owner. Các trở ngại thường liên quan tới các vấn đề như quản lý sản phẩm, việc hợp tác giữa bên liên quan và nhà cung ứng. Product Owner là nhân tố quan trọng trong vấn đề này. Do vậy, hãy đảm bảo duy trì mối quan hệ gắn bó với Product Owner.
• Hiểu sự khác biệt giữa “cản trở” (block) và “trở ngại” (impediment). Một cản trở chỉ ảnh hưởng tới nhiệm vụ đơn lẻ, trong khi các trở ngại hoạt động như một chiếc dù, ảnh hưởng từ từ làm chậm dần cả quá trình. Thường xuyên, Nhóm Phát triển tự mình có thể giải quyết các cản trở trong khi các trở ngại cần được xử lý bởi Scrum Master (IIan Goldstein – Scrum Shortcuts with cutting corners)
• Tập trung vào các vấn đề thực sự, không phải vấn đề xảy đến đầu tiên. Hỏi các câu hỏi nhằm hiểu hơn về tình huống. Kiểm tra xem đó thực sự là trở ngại hay là một cơ hội để học tập cho Nhóm Phát triển

“Tập trung vào vấn đề thực sự, không phải vấn đề xảy đến đầu tiên”

Lời kết

Ngày hôm nay chúng ta đã giải mã một hiểu lầm khác đó là Scrum Master chịu trách nghiệm giải quyết mọi vấn đề có thể cản trở tiến trình của Nhóm Phát triển trong việc đạt được Mục tiêu Sprint. Thay vào đó, Scrum Master nên giúp Nhóm Phát triển gia tăng khả năng tự giải quyết các vấn đề tương tự (tự tổ chức). Scrum Master thực hiện điều đó bằng cách chỉ ra các vấn đề đang “hoạt động như một chiếc dù” đối với nhóm, không chỉ xuất hiện bất cứ lúc nào. Trong bài này chúng tôi đã đưa ra một số ví dụ cụ thể và làm rõ các loại vấn đề mà nhóm nên giải quyết, cũng như các vấn đề thực sự là “trở ngại” được chọn bởi chính Scrum Master. Chúng tôi cũng cung cấp một vài mẹo cho bạn để ứng dụng.

Nguồn: Scrum.org