Scrum Master
Người chịu trách nhiệm để Scrum chạy đúng và nhóm làm việc hiệu quả: huấn luyện, gỡ vướng, chắn nhiễu từ bên ngoài. Không giao việc, không chấm KPI, không quản lý ai cả.
Định nghĩa
Nghe tên thì tưởng sếp. Thực tế Scrum Master không có quyền giao việc cho ai, không duyệt nghỉ phép, không chấm hiệu suất. Scrum Guide 2020 xếp đây là người chịu trách nhiệm về hiệu quả của Scrum Team, làm điều đó bằng cách giúp mọi người hiểu và vận dụng Scrum, chứ không phải bằng quyền lực hành chính.
Đo một Scrum Master giỏi bằng việc team tự chạy được đến đâu khi anh ta nghỉ hai tuần.
Việc thật sự làm mỗi ngày
Scrum Guide chia trách nhiệm của Scrum Master theo ba hướng: với Scrum Team, với Product Owner, và với cả tổ chức.
- Với team: huấn luyện để team tự quản được, bám Definition of Done, và gỡ những thứ đang chặn.
- Với PO: đây là phần hay bị bỏ nhất. Giúp PO tìm cách diễn đạt Product Goal, giữ backlog gọn, và đứng ra tổ chức những buổi làm việc với stakeholder mà PO ngại chủ trì.
- Với tổ chức: phần khó nhất, vì nó động tới người ngoài Scrum Team. Gỡ rào cản giữa stakeholder và team, và giải thích đi giải thích lại vì sao không giao việc thẳng cho dev.
Việc "gỡ vướng" nghe mơ hồ nên nói cụ thể: xin quyền truy cập môi trường staging cho tester mất ba tuần chưa xong, hai team tranh nhau một con database dùng chung, khách hàng chỉ trả lời email vào thứ Sáu. Đó là loại việc Scrum Master phải chạy, chứ không phải ngồi cập nhật Jira hộ dev.
So sánh Scrum Master và Project Manager
| Tiêu chí | Scrum Master | Project Manager |
|---|---|---|
| Nguồn quyền | Ảnh hưởng, huấn luyện | Quyền hành chính, phân công |
| Kế hoạch | Team tự lập trong Sprint Planning | PM lập, giao xuống |
| Chịu trách nhiệm về | Hiệu quả của Scrum Team | Tiến độ, chi phí, phạm vi dự án |
| Báo cáo | Team tự minh bạch qua artifact | PM tổng hợp báo cáo lên trên |
| Đầu việc quen thuộc | Facilitate retro, gỡ impediment | Lập plan, quản lý rủi ro, hợp đồng |
Ở Việt Nam, khá nhiều nơi để một người mang danh Scrum Master nhưng vẫn làm đúng việc PM: chia task cho từng dev, hỏi tiến độ mỗi sáng, làm báo cáo tuần cho ban giám đốc. Đó là PM đổi tên. Không sai về mặt quản trị, chỉ là đừng gọi nhầm rồi tưởng mình đang làm Scrum.
Ví dụ thực tế
Team tám người làm phân hệ quyết toán cho một công ty cho thuê xe tự lái. Ba sprint liên tiếp không đạt Sprint Goal. Scrum Master không đi hỏi từng dev "sao chậm vậy", mà kéo dữ liệu ra: trung bình mỗi sprint có 4 ticket production chen ngang, mỗi ticket ngốn nửa ngày của một người.
Cách xử lý ở retro: team thống nhất giữ lại 20% capacity cho việc chen ngang, và Scrum Master làm việc với trưởng bộ phận vận hành để mọi yêu cầu gấp phải đi qua PO thay vì nhắn thẳng vào nhóm chat của dev. Sprint sau đạt goal. Team không hề cố hơn sprint trước một chút nào. Chỉ có 4 ticket chen ngang kia, từ chỗ chẳng ai buồn đếm, đã thành một dòng có chỗ ngồi đàng hoàng trong Sprint Backlog.
Dấu hiệu đang làm sai vai
- Chỉ làm thư ký cuộc họp: đặt lịch, ghi biên bản, nhắc mọi người cập nhật task.
- Trả lời thay dev trong Daily Scrum.
- Nhận luôn việc estimate cho team.
- Đưa số liệu velocity của team lên bảng so sánh với team khác.
- Ba tháng liền retro ra cùng một action item và chưa cái nào được làm.
BA kiêm Scrum Master được không
Được, và ở công ty dưới 50 người thì gần như bắt buộc phải kiêm. Rủi ro nằm ở xung đột vai: BA thường đứng về phía yêu cầu và tiến độ giao hàng, trong khi Scrum Master phải bảo vệ nhịp làm việc bền vững của team. Khi khách đòi nhét thêm hai màn hình vào sprint đang chạy, cái đầu BA muốn gật, cái đầu Scrum Master phải hỏi "vậy bỏ cái gì ra".
Nếu buộc phải kiêm, hãy nói rõ với team mình đang đội mũ nào trong từng buổi, và tuyệt đối tránh kiêm luôn cả PO. Một người vừa quyết định làm gì, vừa canh quy trình, vừa nghiệm thu thì chẳng còn ai để phản biện.
