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à ở đó ScrumMaster 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 ScrumMaster đã 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 khi hiểu lầm rằng trách nhiệm của ScrumMaster 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à một ScrumMaster cung cấp. Một trong số những đó là loại bỏ các trở ngại xuất hiện 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 đề của ngày hôm nay. 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 ScrumMaster.

Đ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ở cho 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 rằng, 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 đằng sau các 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ột chiếc 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 các vấn đề. Trong Scrum, bản chất tự tổ chức của một nhóm có thể hiểu bằng đó là năng lực giải quyết các vấn đề khi họ 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 xong 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 đến đều cần ScrumMaster giải quyết? Điều gì xảy đến khi chỉ ScrumMaster 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 đến khi chỉ ScrumMaster mới có thể giải quyết các vấn đề liên quan tới cơ sở hạ tầng? Một ScrumMaster giải quyết hầu hết các vấn đề xảy đến thì không phải là đang giúp đỡ cho nhóm. Mà anh ấy đang chủ động cản trở khả năng (sự trưởng thàng) 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, ScrumMaster đã phải tự mình giải quyết vấn đề này.

Vấn đề này chỉ là một 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 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, ScrumMaster không thực sự giúp cho 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 đó, ScrumMaster có thể chỉ ra trở ngại thực sự bằng cách giúp Nhóm tìm ra các 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ù gả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 ScrumMaster.

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 sự mẫu thuận giữa hai thành viên. Thay vì nói về bản thân những vấn đề, ScrumMaster được giao cho 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 đề, ScrumMaster không giúp nhóm phát triển kĩ năng giải quyết các vấn đề nếu nó tái diễn trong tương lai. Thay vào đó, ScrumMaster có thể hỗ trợ tổ chức một phiên “giải quyết căng thẳng”, trong phiên đó, 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 đề). ScrumMaster 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, khi mà ScrumMaster đượ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, ScrumMaster 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, ScrumMaster 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 các 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.

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

Các ScrumMaster thành công giúp cho Nhóm Phát triển phát triển được 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à ScrumMaster 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 ScrumMaster hay không hãy giám sát năng lực của một 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à ScrumMaster không bao giờ giải quyết các vấn đề?

Liệu điều này có đồng nghĩa với việc ScrumMaster không giải quyết vấn đề gì? Dĩ nhiên là không. ScrumMaster vẫn là một phần của Nhóm Scrum. Một ScrumMaster 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 một ScrumMaster 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 cho 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 “Một ScrumMaster 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 giúp 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, 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 ScrumMaster. 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 ScrumMaster.
• 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à ScrumMaster, bạn đặc biệt 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 ScrumMaster 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 ScrumMaster 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 một 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 đến tiếp theo. Đó cũng là cách mà ScrumMaster 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ù với việc ả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 ScrumMaster (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à ScrumMaster 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 đó, ScrumMaster 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). ScrumMaster 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 vài 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à “các trở ngại” được chọn bởi chính ScrumMaster. Chúng tôi cũng cung cấp một vài mẹo cho bạn để ứng dụng.