![[Những hiểu lầm trong Scrum] Scrum Master giải quyết MỌI VẤN ĐỀ](https://hocvienagile.com/wp-content/uploads/2022/10/HVA_logo_2019_175x115.png){kind=logo}
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.
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.
“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ư:
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ọ.
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ế.
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.
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ụ 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
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.
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.”
“Tập trung vào vấn đề thực sự, không phải vấn đề xảy đến đầu tiên”
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
Bài viết liên quan:
Khóa học liên quan:
