8 điều Scrum Master nên tránh

Vai trò Scrum Master rất quan trọng trong Scrum team, và đóng góp rất nhiều vào thành bại của sản phẩm. Nhưng xung quanh vai trò Scrum Master cũng có rất nhiều hiểu lầm, hay hiểu sai, dẫn đến nhiều vấn đề bất cập, cản trở khả năng thành công của Scrum Team.

Hôm nay tôi chia sẻ vài dòng về những sai lầm của các Scrum Master mà tôi thường thấy nhất. Hi vọng bài viết hữu ích cho những Scrum Master và qua đó mang lại giá trị tốt nhất cho Scrum Team

8 điều Scrum Master nên tránh - Scrumviet

1. Hài lòng với hiện trạng, không giúp team liên tục cải tiến.

Công việc của một Scrum Master là phải luôn hỗ trợ và hướng team đến những thay đổi tích cực. Đó là lý do cuối mỗi Sprint, Scrum team đều có buổi Sprint Retrospective. Việc liên tục cải tiến sẽ giúp team ngày càng phát huy tiềm lực của mình tốt hơn và qua đó mang lại nhiều hơn giá trị đến khách hàng.

Nhưng cũng có đâu đó những Scrum Master, đến một lúc nào đó thấy Scrum Team đã đủ tốt và không cần cải tiến gì thêm nữa. Điều này là một nguy hiểm tiềm ẩn cho Scrum team nói riêng, và tổ chức nói chung. Vì sao? Đơn giản là vì, thị trường và nhu cầu từ người dùng không dừng lại ở đó, mà ngày càng cao hơn, vì vậy Scrum team phải luôn phát triển theo nhu cầu đó để mang lại nhiều giá trị hơn đến với người dùng. Một ngày nào đó, nếu Scrum Team dừng lại và hài lòng với những điều đã có, hay Sản phẩm của các bạn không còn điều gì để cải thiện thêm, thì chính là lúc Scrum Team đang đi lùi, và sản phẩm cũng sẽ sớm bị thay thế trên thị trường.
​

2. Tránh né hay cố không để những mâu thuẫn xảy ra trong team.

Mâu thuẫn luôn có thể xảy ra trong một team, hoặc giữa hai cá nhân trong team. Mâu thuẫn là điều không thể không xảy ra, và không phải mâu thuẫn nào cũng mang lại ảnh hưởng không tốt. Cũng có những mâu thuẫn cần phải có, vì nó tạo ra thêm quan điểm, và sự sáng tạo.

Đọc thêm bài viết: Đa dạng hoá là gì? Vì sao lại quan trọng?

Nên việc né tránh mâu thuẫn hay dập tắt chúng khi chúng mới bắt đầu, đôi khi không những không giúp Scrum team tốt hơn mà còn gây hại nhiều hơn. Là một Scrum Master, bạn phải biết được đâu là những mâu thuẫn cần phải có và mang lại giá trị cho Scrum team, để nó được diễn ra chứ không phải ngăn cản hay tránh né mâu thuẫn.

3. Không giải quyết mâu thuẫn trong Scrum Team.

Đến đây bạn sẽ thấy nó ngược với điều ở trên, nhưng như đã đề cập: “không phải mâu thuẫn nào cũng là xấu”. Vậy bên cạnh những mâu thuẫn tốt, mang lại giá trị xây dựng team, cũng có những mâu thuẫn là độc hại và cần giúp team loại bỏ để có thể có môi trường làm việc lành mạnh hơn.

Vậy nên, việc né tránh, không hỗ trợ team để giải quyết những mâu thuẫn này (thường những mâu thuẫn này là những mâu thuẫn lớn, và không thể giải quyết bởi hai người hoặc bởi Scrum team), sẽ làm cho team chán nản, mất lòng tin vào nhau, và ảnh hưởng lớn đến tinh thần. Là một Scrum Master, bạn phải biết rằng đâu là những mâu thuẫn độc hại và cần phải hỗ trợ để Scrum team có thế sớm giải quyết.

​4. Giao task cho team và quản lý tiến độ.

Điều này là một trong những sai lầm phổ biến, tôi thường thấy ở những tổ chức chưa hiểu rõ  Agile, và có những Scrum Master chưa hiểu đúng vai trò và trách nhiệm của mình. Những Scrum Master này sẽ như là Project Manager, sẽ giao task cho những ai phù hợp vào mỗi Sprint, kiểm tra tiến độ và đốc thúc team làm theo đúng tiến độ.

Vai trò của Scrum Master là giúp Scrum team hiểu rõ giá trị của Scrum, áp dụng và nhận được giá trị từ Scrum. Scrum Master không phải là Project Manager.

5. Dùng việc cạnh tranh lẫn nhau để thúc đẩy năng suất.

Sai lầm này cũng rất hay gặp, và dễ mắc phải. Văn hoá so sánh và cạnh tranh sẽ mang lại giá trị tức thời về năng suất hay một chút tinh thần. Nhưng về lâu dài, giá trị từ nó sẽ ít lại và để lại nhiều hậu quả nặng nề hơn. Khi Scrum Team chỉ tập trung vào việc cạnh tranh lẫn nhau (kể cả là cạnh tranh trong nhóm, với các nhóm cùng công ty hay với đối thủ), mà quên mất việc xây dựng giá trị mà người dùng cần. Điều này cũng dẫn đến việc team dần không có lòng tin, không có sự cộng tác và hỗ trợ lẫn nhau.

6. Team muốn làm gì thì làm, chúng ta là team tự quản mà.

Có nhiều Scrum Master có sự hiểu lầm này, và không tập trung giúp Scrum Team hiểu được ý nghĩa của Self-Managed, cũng như không giúp Scrum team biết cách xây dựng mục tiêu.

Đây là một hiểu lầm nguy hiểm về Self-Managed. Đồng thời cũng chính là nguyên nhân mà Scrum Guide 2020 đã thay đổi từ Self-Organized thành Self-Managed, để tránh hiểu lầm này. Theo đó Scrum team có trách nhiệm tự quản lý công việc và xây dựng sản phẩm mang lại giá trị cho người dùng. Scrum team là một thành tố trong tổ chức, được xây dựng để kế thừa được tầm nhìn và giá trị của tổ chức đó. Scrum team không phải là một tập thể không có mục tiêu và làm việc không có tổ chức. Họ có mục tiêu rõ ràng, biết cách tự tổ chức và biết cách làm thể nào để đạt được mục tiêu đó. Và Scrum Master là người giúp Scrum team xác định mục tiêu, xây dựng tính tự quản, và lên kế hoạch đạt được mục tiêu đề ra.
​

​7. Chỉ tập trung vào những thứ quá chi tiết.

Đây là một sai lầm của khá nhiều Scrum Master, khi không hiểu rõ vai trò của mình, mà chỉ tập trung vào những việc, như quản lý tiến độ công việc, hay việc kéo task của thành viên. Hay thậm chí là theo sát bắt Scrum team phải tuân thủ theo Scrum Framework một cách máy móc.

Bạn còn sẽ thấy người Scrum Master này có thiên hướng giải quyết những vấn đề chi tiết trong công việc mà đáng ra là của những Developer: Theo giám sát Scrum team, và ra quyết định điều chỉnh ngay khi thấy điều gì không đúng, đặt luôn cả quan điểm và suy nghĩ của mình vào trong công việc của Developer, thậm chí còn tham gia vào làm cùng (!).

Việc làm thế nào để xây dựng được Done Increment vào cuối Sprint là trách nhiệm của Developer, không phải của một Scrum Master. Scrum team sẽ không thể Self-Managed, nếu Scrum Master liên tục có những hành động ảnh hưởng đến tính Self-Managed.

8. Facilitate buổi Sprint Retrospective một cách nhàm chán và lặp đi lặp lại.

Sprint Retrospective là một event mà kỹ năng Facilitate của Scrum Master phải thể hiện và phát huy tốt nhất. Event này đòi hỏi phải có một môi trường và không khí lành mạnh, mọi người phải cảm thấy an toàn để có thể nhìn nhận những điều có thể làm tốt hơn trong Sprint sau. Nên việc giúp Scrum team hiểu rõ giá trị của buổi Sprint Retrospective là chưa đủ. Mà bạn còn phải biết cách thay đổi chúng và làm cho chúng trở nên sinh động và hứng thú với Scrum team. Vì nếu không, dần dà Scrum team sẽ cảm thấy nhàm chán và không có mong muốn cải tiến tốt hơn cho Sprint sau nữa.

Lấy ví dụ, Nếu Scrum team đang có vấn đề về xây dựng lòng tin, hay những vấn đề ảnh hưởng đến môi trường làm việc của Scrum team. Thì việc chọn format là 4 Soils Sprint retrospective kết hợp với phương thức Liberating Structure 1-2-4-all có thể giúp Scrum team nhìn vào đúng vấn đề và tập trung làm sao để cải tiến chúng. Điều này sẽ mang lại sự mới mẻ, và đánh trúng vào điều Scrum team đang cần nhiều hơn.

Tôi cũng có viết rất nhiều cách để có thể Scrum Master có thể Facilitate một buổi Sprint Retrospective hiệu quả. Bạn có thể xem tại đây: ​https://www.scrumviet.org/sprint-retrospective-formats.html

Scrum on!