Scrum Master, cái tay này làm việc gì?

Scrum Master không quản lí nhân sự, không quản lí tiến độ, cũng chẳng quản lí công việc được gán cho ai, càng không quản lí tiền bạc, hay yêu cầu. Vậy thế cái tay này làm cái gì?

Trong những lớp học tôi dạy về Scrum, phần nhiều học viên cứ nghĩ là ScrumMaster chẳng có việc gì để làm. Nên trong các ý kiến thảo luận, họ thường để một ai đó – như Product Owner, hay Developer, Tester. – kiêm nhiệm. Cực chẳng đã mới để một người làm ScrumMaster độc lập, vì sợ tốn rì-suộc (resource) hehe.

Kì thực thì có vài ScrumMaster mới nhận cái công việc này sẽ thấy ngập lụt, “ôi sao nhiều việc thế”, “thế này thì làm sao nổi” hehe..

Vậy thì hằng ngày cái vị ScrumMaster này làm những gì? Xin liệt kê ra đây vài cái bạn xem có nhiều không nhé:

1. Tổ chức các cuộc họp

Chả có mô hình làm việc nào lại có lắm kiếu họp thế: Họp kế hoạch, Họp sơ kết, Họp Cải tiến, Họp viết Yêu cầu, Họp Scrum Hằng ngày, rồi đủ các kiểu họp đột xuất khác. ..

Đó là cấu thành rất cơ bản để vận hành cơ chế Thanh tra – Thích nghi. Thực ra chúng không phải là “họp” theo nghĩa truyền thống, mà là thời gian cộng tác. Giữ cho các  cuộc họp này đầy đủ, đúng giờ và hữu ích không hề là việc dễ.

2. Chọc ngoáy liên tục (còn gọi là thanh tra quy trình)

Giữ “con mắt cú vọ” trên tất cả các phương diện của dự án, ScrumMaster sẽ phải dùng hàng tá các câu hỏi để phát lộ vấn đề, phát lộ ý tưởng, để giúp nhóm nhanh chóng đạt được mục tiêu Sprint.

Để “quan sát” ta có thể bắt đầu với:

• Mình có nhìn thấy taskboard không?
• Khách hàng có biết việc gì đang diễn tra trên bảng không?
• Có gì được cập nhật từ hôm qua đến nay không?
• Có nhìn thấy burndown\burnup không?
• Có điểm nào bất thường trên burndown chart không?
• ….

Để điều tra, “đào bới” thêm, ta có thể dùng các câu hỏi Socratic:

• Tôi nhận thấy <tình huống>, chúng ta sẽ làm gì?
• Tôi quan sát thấy <tình huống>, nó có quan trọng không?
• Tôi thấy <cảm giác>, bạn có thấy điều đó?
• Chúng ta sẽ cố tìm lý do của <tình trạng>?
• Bạn nghĩ chúng ta cần làm gì?
• Ai có ý tưởng gì về <tình trạng>?
• Điều này có hiệu quả không?
• Bạn đã quyết định điều gì?
• Bạn nên làm gì [với tình huống\vấn đề này]?

Danh sách câu hỏi loại này có thể nối dài thêm nữa, phục thuộc vào bối cảnh, sự phức tạp và khả năng thanh tra của ScrumMaster. Tuy vậy, việc này rất mất thời giờ, mất năng lượng và đòi hỏi cả cơ bắp lẫn trí tuệ.

Để điều tra nguyên nhân của vấn đề, ScrumMaster còn phải thành thạo và liên tục sử dụng 5WHYs (Hỏi 5 lần tại sao) để tìm ra cách thúc đẩy nhóm tiến lên.

3. Loại bỏ trở ngại

Nếu như phần (2) chỉ với mục đích “bới bèo ra thật nhiều bọ” (thật nhiều vấn đề của nhóm) thì cái thực sự mà ScrumMaster quan tâm là đầu tư công sức để loại bỏ các trở lực đó. Qua đó giúp nhóm hiệu suất hơn, nhanh chóng đạt được mục tiêu Sprint.

Vấn đề thì muôn hình muôn vẻ, cho nên việc này cũng muôn hình muôn vẻ. Mà có nhóm làm việc nào thực sự lại ít vấn đề? Cho nên ScrumMaster sẽ luôn chân luôn tay. Thậm chí không kiểm soát nổi vấn đề nếu không có phương pháp làm việc khoa học.

4. Tìm kiếm cải tiến

• ProductOwner của tôi làm việc thế nào?
• Nhóm Phát triển đang làm việc thế nào?
• Các kỹ thuật đang được dùng thế nào?
• Tổ chức đang làm việc ra sao?
• Ai cần được huấn luyện về cái gì?
• Quy trình có dư thừa cái gì không?
• Có thể mua sắm hay làm mới công cụ gì để tăng năng suất và gia tăng không khí vui vẻ không?
• …

Đó là vài câu hỏi thường trực. Cải tiến là thứ cần phải làm liên tục, chứ không phải đợi đến buổi họp Cải tiến Sprint mới động não. Trong khi Developer, ProductOwner bận rộn với công việc của họ, thì ScrumMaster sẽ phải âm thầm nhưng chăm chỉ nghiên cứu, phân tích và tìm ra các cải tiến để hỗ trợ nhóm.

5. Huấn luyện (Coaching) Scrum cho nhóm

Ở những nhóm mới làm việc kiểu Scrum, mọi người thường chưa nắm rõ các quy tắc (dù ít ỏi) và ràng buộc của Scrum, nên có thể mắc sai lầm. Nhiệm vụ của ScrumMaster là giúp các thành viên hiểu rõ, thực hành tốt và gặt hái thành công từ Scrum. Mà việc này thì phải theo sát, không thể lơ là.

Trong nhiều trường hợp, ScrumMaster còn phải chịu trách nhiệm tổ chức các “community of practices”, xây dựng và bảo trì kho tri thức Agile cho các thành viên của nhóm và trong phạm vi rộng hơn.

Không thể có Agile mà không có học tập. Nên việc này rất tiên quyết. À, thế nhưng bạn có biết việc học diễn ra bao lâu chưa? Bạn đã nghe con số 10.000 giờ thực hành có chủ đích liên tục chưa?

Trong cấu hình của Nhóm Scrum, có một tay có thể rất lười nhác, nhưng lại có quyền lực lớn là ProductOwner hoặc khách hàng. Tay này có khi chỉ chầu chực là phá hỏng luồng làm việc của nhóm với những bug cần fix gấp, hay những tính năng tuyệt cú mèo “anh vừa mới nghĩ ra”. Cần phải huấn luyện Scrum cho tay này để anh em phối hợp nhịp nhàng. Đấy cũng là nhiệm vụ rất mệt nhọc của Scrum Master.

6. Chụp ảnh, quay phim, ghi ghi chép chép, dán dán dính dính

Mấy việc này không có tên, nhưng nó là những việc quan trọng không kém.

ScrumMaster có đôi mắt cú vọ để thanh tra mọi thứ, nhưng lại có một bộ nhớ của con người. Mà cái này dung lượng vừa bị giới hạn, lại có tính chất phần nhiều giống như RAM chứ không như ROM. Vậy nên phải thu thập dữ liệu, phân loại để chuẩn bị phân tích.

Không có dữ liệu thực tế, quyết định cải tiến có thể sẽ không phát huy tác dụng.

Mà mấy cái việc không tên này, cũng giống như mấy việc nội trợ ở nhà ấy; chẳng thể gọi là gì, nhưng thử mó tay vào mà xem, “đi đời” vài tiếng như chơi đấy.

7. Động viên, hỗ trợ nhóm

Bản thân công việc loại bỏ trở ngại cho nhóm đã là một lực thúc đẩy nhóm tiến lên. Tuy vậy, đôi khi ScrumMaster còn phải làm nhiều hơn nữa. Động viên, thử thách, thúc đẩy nhóm Scrum cũng là công việc quan trọng của ScrumMaster.

Hôm nay mình đã làm điều gì để khiến ai đó được “kích hoạt” không?

Hôm nay mình làm cho\tạo điều kiện cho ai làm cho nhóm vui vẻ không?

Có trò gì để khiến những chú “trâu ” kia thư giãn một chút không?

v.v.

8. Thôi, bạn thêm giúp tôi vào danh sách này nhé, còn dài lắm. Vả lại tôi có phải là ScrumMaster của các bạn đâu, nên làm sao biết được là sẽ cần phải làm những gì nữa?

Mời bạn điền tiếp!

Dương Trọng Tấn 

Nguồn : tapchilaptrinh.vn