Lần đầu tiên trở thành Scrum Master

Lần đầu tiên trở thành Scrum Master

Khoảng 4 tháng trước, lần đầu tiên tôi có cơ hội đóng vai trò là Scrum Master trong một nhóm nhỏ để phát triển một ứng dụng. Lúc đó tôi đã rất hào hứng khi tiếp cận khách hàng đầu tiên của mình, nhưng thú thật, tôi có vẻ hơi sợ hãi về những gì tôi đã biết lúc đó.

Tôi đã may mắn có được rất nhiều sự hỗ trợ và một đội ngũ xuất sắc giúp tôi ổn định vai trò. Ngoài ra sau khi tham dự khoá học PSM1, tôi tin rằng tôi đã sẵn sàng cho thử thách, mặc dù có một chút lo lắng khi bắt đầu vị trí mới này trong một dự án chặt chẽ.

Bài viết này tôi sẽ chia sẻ về những thách thức tôi đã gặp phải khi làm việc trong một nhóm nhỏ. Tôi hi vọng một số thông tin ở đây sẽ hữu ích cho một “beginner” Scrum Master.

Scrum master is a difficult role

Điều này không có gì ngạc nhiên khi vai trò của scrum master là đầy thách thức, đặc biệt nếu bạn có thêm một vai trò khác trong nhóm phát triển sản phẩm. Thật khó để hòa nhập 2 vai trò và tự tin rằng tôi có thể làm được điều này, tôi liên tục cảm thấy rằng tôi không phải là người phù hợp để hỗ trợ nhóm của mình và cảm giác rằng tôi đang làm họ thất vọng, điều này cuối cùng tan biến khi tôi ngày càng tự tin hơn và có khả năng xử lý các hoạt động hàng ngày của vai trò mới.
Trở thành scrum master là một kỹ năng có thể mất nhiều năm để luyện tập, nhưng chỉ bằng cách nắm lấy cơ hội, bạn mới có thể có được kinh nghiệm đó, có thể rất sợ khi luôn có người nhìn vào bạn để sẵn sàng đưa ra hỗ trợ, có thể là hòa giải và giải quyết những vấn đề trở ngại của nhóm, nhưng nỗi sợ này sẽ biến mất đi khi bạn ngày càng trở nên tốt hơn trong vai trò mới của mình.

Sự hỗ trợ là rất quan trọng

Tôi rất may mắn khi được làm việc bên cạnh những người đáng kinh ngạc, giỏi cả về kỹ năng kỹ thuật, agile coaching và product delivery. Đội ngũ của bạn luôn ở đó để hỗ trợ bạn giống như cách bạn đang hỗ trợ họ, vì vậy đừng bao giờ ngại khi yêu cầu phản hồi, lưu ý rằng hãy đưa ra phản hồi một cách trung thực và yêu cầu giúp đỡ khi bạn cảm thấy quá tải hoặc cảm thấy mình đã bỏ sót điêù gì đó.

Bạn có thể dành nhiều thời gian để tìm kiếm các cách tốt hơn để thực hành agile, các mẹo / thủ thuật / hack để sử dụng trong nhóm, đưa ra các hướng dẫn về cách thực hiện, nhưng không có gì đánh bại được một cuộc thảo luận trực tiếp trung thực về cách bạn đang làm và những việc cần làm tiếp theo để đạt được mục tiêu nhóm của bạn.

Hiểu tính cách nhóm của bạn

Trong sự nghiệp của mình, bạn sẽ làm việc với rất nhiều người khác nhau, với tư cách là scrum master, bạn nên hiểu rõ từng nhóm của mình, không chỉ tên và nhiệm vụ của họ, điều này có thể giúp bạn hiểu quan điểm của các thành viên cụ thể trong nhóm và cách tốt nhất để làm việc cùng mọi người. Nhóm của bạn có thể có những người thích giao tiếp theo các phong cách khác nhau, họ có thể không thoải mái trong ‘tâm điểm’ của một cuộc thảo luận nhóm, hoặc đơn giản là những người hướng nội hơn cần trợ giúp để bày tỏ mối quan tâm, hỗ trợ họ giải pháp hoặc thậm chí là xác định vấn đề của những thành viên bị cản trở trong công việc. Bạn thu thập được rất nhiều thông tin có ích khi có được hiểu biết sâu sắc về tính cách nhóm của bạn, họ quan tâm điều gì, và họ nhận thấy được những giá trị gì từ các sự kiện scrum.
Tạo ra một bầu không khí thoải mái cho tất cả các nhóm là điều quan trọng để mọi người có thể làm việc hiệu quả nhất. Hãy đảm bảo rằng mọi người đều cảm thấy thoải mái trong các cuộc họp và họ cảm thấy thời gian của mình được trân trọng. Tôi đã gặp một số vấn đề khi áp dụng điều này khi bắt đầu dự án, một số thành viên cảm thấy họ tham dự một cuộc họp không mang lại bất kỳ giá trị nào cho họ, điều này có thể dẫn đến việc đi họp muộn (chậm trễ) hoặc các thành viên trong nhóm của bạn cảm thấy rằng thời gian của họ đang bị lãng phí.

Tổ chức là chìa khóa

Một môi trường làm việc thiếu tổ chức có thể tạo ra sự hiểu lầm và các cuộc họp không cần thiết trong nhóm. Giữ cho bảng của bạn ngăn nắp, giữ cho dữ liệu rõ ràng và ngắn gọn, đảm bảo rằng bảng phản ánh công việc đang được thực hiện và các mục tiêu rõ ràng và được nhóm hiểu. Tất nhiên, điều này nói thì dễ hơn làm, vì tôi thấy rất khó khăn trong việc cập nhật tất cả các thay đổi và mức độ phức tạp ngày càng tăng của dự án, nắm bắt dữ liệu và hiển thị trực quan là một kỹ năng đáng kinh ngạc mà các scrum master và huấn luyện viên aglie có kinh nghiệm có thể giúp bạn.
Nhiều khi cả nhóm bắt đầu họp daily và thấy bảng kanban lộn xộn, không phản ánh công việc đang làm hoặc bất kỳ trở ngại nào. Đây là điều mà tôi phải tạo ra kỷ luật, tạo thói quen xem lại bảng kanban 15 phút trước khi họp daily hàng ngày để bất kỳ thay đổi nào trong hệ thống quản lý dự án của chúng tôi đều được phản ánh trong bảng kanban. Có issues trực quan này sẽ bắt đầu cuộc trò chuyện và sẽ cải thiện sự rõ ràng về các yêu cầu và các yếu tố cản trở tiềm năng, vì vậy điều này rất quan trọng để đảm bảo rằng tất cả các bánh xe đang quay theo hướng chính xác.

Các sự kiện là rất quan trọng và cần được đánh giá cao

Các sự kiện Scrum được xác định rõ ràng và là chìa khóa để cải thiện giao tiếp và tính cởi mở theo Tuyên ngôn Agile:
“Trong khoảng thời gian đều đặn, nhóm phản tư về cách trở nên hiệu quả hơn, sau đó điều chỉnh hành vi của mình cho phù hợp.”

Các sự kiện cho phép nhóm tạo ra các mục tiêu và thực hiện các chiến lược để đạt được chúng, nó giúp loại bỏ các trở ngại và xem xét công việc đã được thực hiện. Nhưng khi chúng tôi chạy sprint hàng tuần, việc duy trì các sự kiện scrum trong một dự án với thời hạn chặt chẽ dường như phản tác dụng, vì các phiên lập kế hoạch sprint sẽ rất ít thông tin và có quá nhiều ẩn số để ước tính và cam kết. Đây là lúc chúng tôi quyết định triển khai khung Kanban để tránh phạm phải những phần công việc mà bỏ sót thông tin quan trọng về độ phức tạp và phụ thuộc vào bên thứ ba.
Nhóm giữ các sự kiện như scrum hàng ngày và đánh giá như một phần của lịch trình hàng tuần, nhưng theo cách ít cấu trúc hơn và với ít công việc cần chuẩn bị hơn trước các sự kiện. Điều này giúp chúng tôi đạt được nhanh chóng mục tiêu của mình, hy sinh một số hành động được chứng minh là có lợi trong trường hợp này của chúng tôi.

Tập trung vào các mục tiêu

Trong chu kỳ phát triển sản phẩm, mục tiêu của nhóm bạn sẽ thay đổi thường xuyên, đây sẽ là các mục tiêu theo cấp độ cho từng ngày, từng tuần và từng đợt phát hành. Nắm bắt các mục tiêu và thấm nhuần chúng trong nhóm sẽ giúp mọi người tập trung vào những gì quan trọng, với tư cách là nhà phân tích sản phẩm của dự án và đóng vai trò là chủ sở hữu sản phẩm, đôi khi tôi thấy đây là một lời nhắc nhở mạnh mẽ cho tất cả nhóm về “chúng ta chiến đấu vì điều gì”. Điều chỉnh mục tiêu của bạn với các bên liên quan và minh bạch về việc bạn có thể làm được gì trong một tuần, đây là phần thách thức nhất, khi các yêu cầu thay đổi, độ phức tạp tăng lên và những ẩn số chưa được biết đến và mục tiêu hàng tuần bị trật bánh.

Ngay cả khi tỷ lệ thành công thấp khi thực hiện các mục tiêu hàng tuần hoặc hàng ngày, điều quan trọng là phải trực quan chúng nổi bật trên bảng, thảo luận về mục tiêu khi có cơ hội thuận tiện với nhóm, và thảo luận một cách trung thực về mức độ khả thi của nó, điều này sẽ giúp bạn đỡ đau đầu trong tương lai khi trao đổi với các bên liên quan.

Đừng nản lòng khi mọi thứ không theo ý bạn

Đừng dễ nản lòng khi một nhiệm vụ thất bại, điều cần làm là xem xét và sắp xếp lại các kỳ vọng. Tôi biết nó luôn đi kèm với những cuộc trò chuyện và giải thích khó khăn. Không đạt được mục tiêu là một phần của quá trình, bạn sẽ nhận được nhiều kiến thức hơn từ những tuần khó khăn với những vấn đề phức tạp hơn là từ một tuần dễ dàng mà mọi thứ đã trôi đi. Những kiến thức đó sẽ giúp ích cho bạn sau này, vì bây giờ bạn có thể hiểu thêm về điều gì ngăn cản sự phát triển và cần tập trung vào đâu để đảm bảo giá trị đang được chuyển giao.
Cách bạn thoát khỏi thất bại có thể xác định vai trò của bạn là một scrum master, bạn nên tự tin và trung thực về thất bại, yêu cầu phản hồi từ nhóm và đồng nghiệp, đi sâu vào vấn đề nằm ở đâu và bạn có thể làm gì để cải thiện nó.

Không có sổ tay

Chà, có rất nhiều sách, bài báo, bài đăng trên blog và cộng đồng dành riêng cho scrum và huấn luyện viên Agile, nhưng sự thật là điều này không bao giờ phù hợp với các tình huống thực tế. Không có mẫu mô tả nào về scrum và huấn luyện viên agile, nhóm của bạn luôn thay đổi và phát triển khi dự án triển khai, chìa khóa là thích ứng với những thay đổi đó, việc triển khai của bạn có thể không tuân theo tất cả các quy tắc agile / scrum nhưng vẫn có thể truyền tải các đặc tính của agile, bằng cách này bạn có thể hoàn thành công việc.
Có rất nhiều cách diễn giải về scrum và agile và điều đáng nhớ là các định nghĩa trong Hướng dẫn Scrum có thể không hoàn toàn phù hợp với các quy trình trong nhóm của bạn và cần được giải thích để phù hợp với yêu cầu của bạn.

Dịch từ Medium