Một nhóm Scrum gồm có 03 vai trò: Product Owner, Development Team, Scrum Master. Vậy Scrum Master có được kiêm nhiệm vai trò thành viên nhóm phát triển (Development Team)?
Scrum không yêu cầu Scrum Master chuyên trách, Scrum Master hoàn toàn có thể vừa tham gia phát triển sản phẩm vừa đảm nhiệm vai trò Scrum Master.
Thực tế, các nhóm Scrum hiện nay đang sử dụng các hình thức Scrum Master như sau:
Mỗi mô hình đều có những ưu nhược điểm riêng, sau đây là ưu nhược điểm của từng mô hình:
Scrum Master không cố định mà các thành viên trong nhóm phát triển sẽ luân phiên nhau đảm nhận vai trò Scrum Master trong một hoặc một vài Sprint. Mô hình này mỗi khi được đề xuất thường dễ được thông qua, vì ai cũng được trao cơ hội trải nghiệm vai trò Scrum Master. Thật ra, lý do quan trọng hơn là việc tiết kiệm chi phí, hoặc thậm chí là sự ngại thay đổi của tổ chức.
Nếu công việc của Scrum Master là chỉ người ghi chép, người tổ chức cuộc họp, theo dõi backlog, deadline, hay cập nhật burndown chart thì việc luân phiên đảm nhiệm vai trò Scrum Master cũng khá ổn. Tuy nhiên, trách nhiệm của Scrum Master không đơn giản như thế. Vai trò của Scrum Master bao gồm nhưng không giới hạn các trách nhiệm sau đây:
Làm thế nào để một Scrum Master hoàn thành các yêu cầu đó trong một vài Sprints? Đặc biệt đối với các thành viên không thực sự phù hợp với vai trò servant leader, hoặc thiếu kỹ năng và kiến thức về Scrum.
Scrum Team áp dụng mô hình Scrum Master luân phiên thì cũng giống như Scrum Team không có Scrum Master. Thực chất đây không phải là Scrum mà là Zombie Scrum.
Trong một số hoàn cảnh nhất định như nhóm mới thành lập và chưa có một Scrum Master có kinh nghiệm, việc tạm thời xoay tua vai trò Scrum Master đối với vài thành viên phù hợp cũng là một giải pháp tốt trong ngắn hạn. Tuy nhiên, về lâu dài khi có người phù hợp thì vẫn nên có Scrum Master cố định.
Đây là mô hình khá phổ biến với các công ty outsource khi áp dụng mô hình Scrum. Khi đó, một thành viên nhóm phát triển, thường là người có kinh nghiệm, sẽ kiêm luôn vai trò Scrum Master.
Thuận lợi của mô hình này là Scrum Master hiểu công việc và dễ dàng giao tiếp với các thành viên trong nhóm Scrum, nắm bắt nhanh các khó khăn trong công việc của nhóm phát triển, nhờ vậy có thể giúp nhóm giải quyết nhanh các khó khăn trở ngại trong Sprint.
Tuy nhiên, Scrum Master theo mô hình này sẽ gặp những khó khăn như sau:
Nhìn chung, về mặt lý thuyết, mô hình này có vẻ tiết kiệm chi phí vì không dùng hết một “head count” cho vị trí Scrum Master. Tuy nhiên, hiệu quả làm việc chung của nhóm thường không tốt bằng mô hình Scrum chuyên trách.
Đây là mô hình mà Scrum Master dành toàn thời gian cho một nhóm Scrum hoặc có thể đảm nhận vai trò Scrum Master cho vài nhóm Scrum cùng lúc.
Ưu điểm của mô hình này là Scrum Master có thể dành toàn thời gian để giúp nhóm hiểu được các giá trị của Scrum, hiểu rõ ý nghĩa và áp dụng hiệu quả các practices của Scrum, dẫn dắt và xây dựng văn hóa làm viêc nhóm, tinh thần tự quản. Scrum Master có thời gian quan sát sự giao tiếp và tương tác giữa các thành viên trong nhóm, thúc đẩy và đảm bảo tính minh bạch, khuyến khích sự chia sẽ kiến thức, kỹ năng và sự phát triển của các thành viên trong nhóm.
Trở ngại duy nhất của mô hình này là vấn đề chi phí, mối quan tâm chính của các công ty startup, các agency hoặc công ty outsource. Tuy nhiên, các công ty lớn hoặc có định hướng mở rộng quy mô nên xem xét mô hình này vì hiệu quả làm việc của nhóm sẽ tốt hơn. Hơn nữa, một Scrum Master có kinh nghiệm có thể đảm nhiệm được 2 đến 3 nhóm Scrum và chi phí không còn là một trở ngại nữa.
Mỗi mô hình Scrum Master đều có những khó khăn và ưu thế riêng. Tuy nhiên, mô hình Scrum Master luân phiên chỉ nên áp dụng trong giai đoạn đầu khi mới triển khai Scrum và chưa có người phù hợp đảm nhiện vai trò Scrum Master. Scrum không yêu cầu các vai trò phải chuyên trách và toàn thời gian nhưng việc thay đổi thường xuyên cấu trúc nhóm sẽ ảnh hưởng không tốt đến khả năng làm việc và tự tổ chức của nhóm Scrum. Do vậy, mô hình Scrum Master kiêm nhiệm hay toàn thời gian sẽ là lựa chọn hợp lý hơn.
Cảm ơn các bạn đã đọc bài viết này.
Nếu bạn có câu hỏi, đánh giá, hay góp ý cho tác giả, xin vui lòng để lại comment bên dưới.
