Scrum được định hướng là một khung làm việc đơn giản nhưng hiệu quả để phân phối các sản phẩm phức tạp. Scrum không phải là một giải pháp cho mọi vấn đề, một lời giải tuyệt đối cho những vấn đề hóc búa hay một phương pháp toàn diện. Thay vào đó, Scrum đề ra những giới hạn tối thiểu trong việc nhóm có thể tự tổ chức để giải quyết một vấn đề phức tạp nào đó theo hướng thực tiễn, quan sát và thực hành thay vì chỉ lý thuyết chung chung. Sự tối giản này chính là sức mạnh lớn nhất của Scrum, nhưng cũng chính là nguồn cơn của rất nhiều lời đồn đoán và sự hiểu lầm xung quanh nó. Trong loạt bài viết này, chúng tôi – Christiaan Verwijs và Barry Overeem – sẽ “giải mã những hiểu lầm” của bạn, sẽ đề cập đến những đồn đoán và hiểu lầm phổ biến nhất. Thea Schukken là tác giả của những minh họa tuyệt vời cho loạt bài viết này.
Hiểu nhầm về việc ScrumMaster phải xuất hiện trong suốt buổi Scrum Hằng ngày
Mọi người thường hiểu nhầm về việc ScrumMaster phải luôn xuất hiện trong suốt buổi Scrum Hằng ngày. Ở một vài nhóm, ScrumMaster được giao nhiệm vụ tổ chức các buổi Scrum Hằng ngày. Trong khi, các đội khác cảm thấy rằng ScrumMaster cần đứng ra giải quyết các trở ngại. Dù bằng cách nào thì luôn đòi hỏi sự hiện diện của ScrumMaster.
Hướng dẫn về Scrum nói gì?
Theo như Hướng dẫn Scrum (Scrum Guide), Nhóm Phát triển chịu trách nhiệm về các buổi Scrum Hằng ngày. Scrum được xây dựng dựa trên sự quan sát rằng phát triển sản phẩm là một tiến trình khó khăn và phức tạp. Sự phức tạp này thể hiện rõ ở tính khó đoán định cao. Ngay cả như trong quy mô của một Sprint riêng lẻ thì mọi thứ cũng rất có thể không theo như kỳ vọng. Một thành viên cốt cán của nhóm bị ốm trong Sprint. Một lỗi nghiêm trọng được phát hiện và cần phải sửa chữa ngay lập tức. Hay một ý tưởng mới nảy ra và phù hợp hơn với Mục tiêu của Sprint. Giao tiếp thường xuyên trong Nhóm Phát triển là rất quan trọng để đối phó với những thay đổi ngay khi chúng xảy ra.
Các buổi Scrum Hằng ngày là một trong những ranh giới của Scrum và đem đến cho Nhóm Phát triển ít nhất một cơ hội mỗi ngày để cập nhật công việc và lập kế hoạch cho ngày tiếp theo. Cả nhóm sẽ làm việc cùng nhau như thế nào cho đến buổi Scrum Hằng tiếp theo để đạt được Mục tiêu Sprint? Kết quả của buổi Scrum Hằng ngày là một bản kế hoạch cho mỗi ngày và có thể là một vài thay đổi với Sprint Backlog để đạt được Mục tiêu Sprintl. Mặc dù ScrumMaster có thể xuất hiện để tổ chức Scrum Hằng ngày, tuy nhiên điều này là không bắt buộc. ScrumMaster phải đảm bảo rằng một buổi Scrum Hằng ngày diễn ra, nhưng Nhóm Phát triển là người chịu trách nhiệm thực hiện cuộc họp. Không ai ngoài Nhóm Phát triển và có thể là cả ScrumMaster được phép tham gia. Nếu Scrum Hằng ngày dẫn đến quyết định ảnh hưởng đến người khác (ví dụ như Product Owner), họ có thể được Nhóm Phát triển hỏi ý kiến sau.
Do vậy ScrumMaster có thể tham gia Scrum Hằng ngày, nhưng điều này là không bắt buộc trong Scrum.
Các vấn đề tiềm năng
Khi mà ScrumMaster xuất hiện trong mọi buổi Scrum Hằng ngày, sẽ có một vài “dấu hiệu” chỉ ra những vấn đề trong việc áp dụng Scrum:
- ScrumMaster hoạt động như là một quản lý của nhóm, và sử dụng Scrum Hằng ngày để chia sẻ công việc và ra quyết định thay cho Nhóm Phát triển;
- Nhóm Phát triển không hỗ trợ hoặc cam kết với Scrum, và cần ScrumMaster để “đảm bảo chắc chắn rằng điều đó xảy ra”. Trong trường hợp này, cần xác định được động lực sâu xa đằng sau của nhóm để làm việc với Scrum;
- Nhóm Phát triển dựa vào ScrumMaster để tạo điều kiện giao tiếp trong nhóm. Điều này có thể gây cản trở khả năng học cách tự tổ chức của Nhóm Phát triển.
- ScrumMaster sử dụng Scrum Hằng ngày để cảm thấy ý nghĩa. Là một người đầy tớ lãnh đạo, sự thành công của một ScrumMaster thường bộc lộ theo những cách gián tiếp (phát triển theo thời gian, bầu không khí thân thiện, học hỏi). Với một vài ScrumMaster, Scrum Hằng ngày tạo cơ hội cho họ chiếm lấy sân khấu chính nhằm tạo ra đóng góp nổi bật – ngay cả khi điều đó không có lợi cho Nhóm Phát triển vì những lý do kể trên.
Thủ thuật
Những thủ thuật sau đều rất hữu ích để khiến Scrum Hằng ngày (cũng như ScrumMaster) hiệu quả hơn:
- Nhấn mạnh lại mục đích của Scrum Hằng ngày ngay từ lúc ban đầu.
- Lùi lại (theo đúng nghĩa đen) phía sau trong buổi Scrum Hằng ngày, đặt bản thân bên ngoài Nhóm Phát triển
- Giới hạn bản thân chỉ đặt những câu hỏi mở xuyên suốt Scrum Hằng ngày;
- Giới hạn bản thân chỉ đặt những câu hỏi liên quan đến sự minh bạch, kiểm tra và thích nghi: “Cách nhìn mới này ảnh hưởng đến Mục tiêu Sprint của chúng ta như thế nào?”, “Công việc mới nào cần phải được minh bạch?” hoặc “Chúng ta có thể làm gì hôm nay để giúp nhau đạt được Mục tiêu Sprint?”
- Đừng quá chủ động thực hiện Scrum Hằng ngày bằng việc yêu cầu mỗi thành viên trả lời 3 câu hỏi của Scrum Hằng ngày. Thay vào đó, hãy để mọi người tự quyết định ai là người tiếp theo;
- Đừng tham dự vào Scrum Hằng ngày. Hãy quan sát những gì xảy ra sau đó;
- Nhờ ai đó trong Nhóm Phát triển hỗ trợ triển khai Scrum Hằng ngày;
- Hãy để Nhóm Phát triển lựa chọn thời gian bắt đầu và địa điểm. Đây là sự kiện của họ vì vậy hãy để họ chọn thời điểm phù hợp nhất với mình. Điều này làm tăng cảm giác được tự chủ và khuyến khích nhóm bắt đầu đúng giờ.
Lời kết
Trong bài blog này, chúng tôi đã mô tả hiểu lầm về việc Scrum Master phải xuất hiện trong buổi Scrum Hằng ngày. Chúng tôi đã cung cấp cái nhìn từ Hướng dẫn Scrum, mô tả một vài ví dụ về vấn đề có khả năng xảy ra trong việc áp dụng Scrum và chia sẻ những mẹo về việc thực hiện Scrum Hằng ngày hiệu quả hơn.
Ý kiến của bạn về hiểu lầm này là gì? Chúng tôi cũng luôn mong muốn được học hỏi từ những trải nghiệm thực thế của chính bạn.
