Lời đồn thứ 13 : Scrum Master không được loại bỏ thành viên trong nhóm Scrum

Scrum được mong đợi sẽ là một khung làm việc đơn giản mà vẫn đầy đủ để chuyển giao 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 trường hợp, một viên đạn bạc hay một phương pháp hoàn thiện. Thay vào đó, Scrum cung cấp các ranh giới tối thiểu mà trong đó các nhóm có thể tự tổ chức để giải quyết các vấn đề phức tạp bằng cách sử dụng một phuơng pháp tiếp cận thực nghiệm. Sự đơn giản này là điểm mạnh lớn nhất của nó, nhưng cũng là nguồn gốc của nhiều sự hiểu lầm cũng như những lời đồn xung quanh Scrum.

Hãy bắt đầu với một trường hợp

"Như vậy là Tim đã quyết định không tham gia một lần nữa " - một nhà phát triển tham gia Daily Scrum hỏi một cách bực bội. Những người có mặt phát ra tiếng thở dài thất bại và nhún vai. "Ngay cả sau khi chúng ta nói chuyện về sự cần thiết của việc chia sẻ tiến bộ của chúng ta một cách công khai?" - một nhà phát triển khác tiếp tục. Có thể thấy rõ ràng sự căng thẳng. Tim đã không tham gia Daily Scrum trong gần hai tháng nay. Sử dụng thời gian của anh ấy cho "những thứ rất quan trọng", Tim thích sử dụng thời gian dành cho Daily Scrum để viết code. Nhưng ngoại trừ số lượng commit (code commit) khổng lồ của anh ta cuối mỗi sprint - mà chúng thường loại bỏ công việc người khác đã làm - không ai thực sự biết anh ấy thực sự làm việc gi ? Vấn đề đã được nhóm phát triển đưa ra nhiều lần trong các buổi cải tiến Sprint , mà không có giải pháp. Scrum Master của nhóm - Tes - đã trao đổi về vấn đề đó với Tim nhiều lần, cố gắng tìm ra nguyên nhân điều gì khiến cho Tim lại không chia sẻ thông tin như vậy (to play his cards so close to his chest) . Nhưng bất chấp những cuộc nói chuyện tốt, không có gì thay đổi sau đó. Nhóm trở nên ngày càng mệt mỏi với "cuộc chiến". Tinh thần giảm sút. Và bởi vì không thể dự đoán được Tim đang làm gì và nó sẽ tác động như thế nào tới Sprint, nhóm đã ngày càng do dự khi cam kết mục tiêu Sprint. Đã thử rất nhiều cách khác nhau để giải quyết tình hình, Tess quyết định loại bỏ Tim ra khỏi nhóm Scrum.

Trường hợp này minh hoạ cho hành động cân bằng giữa bản chất tự tổ chức của nhóm Scrum và làm cho Scrum làm việc cho cả nhóm và cả tổ chức lớn hơn. Trường hợp chúng ta vừa mô tả là một trong những quyết định khó khăn mà đôi khi Scrum Master phải đối mặt.

Khi được hỏi Scrum Master có thể loại bỏ một người nào đó khỏi nhóm hay không, hầu hết mọi người đều trả lời "không" một cách đanh thép và đầy tính nguyên tắc. Nó có thể tạo ra sự phân cấp trong nhóm, nó có thể tổn thương tới môi trường tin cậy, thay vào đó nó nên được ủy quyền cho nhân sự / quản lý và nó đi ngược lại bản chất tự tổ chức của nhóm phát triển.

Tuy nhiên, trong bài viết này, chúng ta sẽ làm rõ trường hợp nguyên tắc này thực tế là một lời đồn, một phần dựa trên sự hiểu biết không đầy đủ về khái niệm Scrum Master là một nhà lãnh đạo phục vụ. Có những tình huống mà Scrum Master có trách nhiệm và quyền hạn để loại bỏ một người nào đỏ khỏi nhóm.

Hướng dẫn Scrum nói gì ?

Hướng dẫn Scrum không nói rõ ràng rằng Scrum Master có thể loại bỏ một người nào đó khỏi nhóm Scrum. Nhưng Hướng dẫn Scrum nhấn mạnh một số trách nhiệm liên quan :

• Scrum Master chịu trách nhiệm quảng bá và hỗ trợ Scrum như được định nghĩa trong Hướng dẫn Scrum với nhóm và tổ chức rộng hơn;
• Là một nhà lãnh đạo phục vụ, Scrum Master giúp tạo ra một môi trường mà nhóm Scrum có thể làm việc hiệu quả với Scrum;
• Scrum Master chịu trách nhiệm cho việc loại bỏ các trở ngại cản trở tiến độ của nhóm phát triển. Rất nhiều thứ có thể là trở ngại, từ những chiếc laptop bị hỏng cho tới sự xung đột của nhóm và từ sự gián đoạn cho tới việc thiếu các kỹ năng. Nhưng một Scrum Master nên quan tâm chủ yếu tới những trở ngại có thể gây nguy hiểm cho mục tiêu Sprint và vượt qua khả năng tự giải quyết của nhóm phát triển. Nói chung, Scrum Master cố gắng loại bỏ hoặc giải quyết những thứ có thể cản trở khả năng làm việc hiệu quả của nhóm phát triển với Scrum (và rộng hơn, là của toàn bộ tổ chức).

Một cách khác để xem xét điều này là Scrum Master là một nhà lãnh đạo phục vụ bằng cách thiết lập và duy trì các quy tắc của trò chơi trong phi cung cấp cho người chơi sự tự do và hỗ trợ để chơi trò trơi một cách hiệu quả nhất có thể. Mặc dù Scrum Master làm mọi thứ để giúp mọi người chơi trò chơi với khả năng tốt nhất của mình, trách nhiệm chính của anh ấy (cô ấy) là đảm bảo rằng trò chơi được chơi đúng. Diễn giải sang việc phát triển sản phẩm, điều này có nghĩa là cung cấp một sản phẩm có giá trị trong các bước gia tăng để học trong hành trình và cho phép thông tin chi tiết hơn xuất hiện.

Việc loại bỏ các trở ngại - những thứ cản trở trò chơi được vận hành tốt - là một trong những trách nhiệm của Scrum Master. Do đó, câu hỏi bây giờ trở thành "một thành viên của nhóm có thể trở thành trở ngại đối với trò chơi không ?

" Một thành viên của nhóm Scrum có thể trở thành những trở ngại không ?

Thành viên là những trở ngại ?

Mặc dù chúng ta cảm thấy không thoải mái khi đánh giá thành viên là những trở ngại, thực tế là các thành viên có thể cản trở việc làm việc với Scrum một cách hiệu quả. Ví dụ :

• Như ở trường hợp bên trên, một nhà phát triển làm mọi thứ một cách bí mật, không tiết lộ anh ấy đang làm gì, mọi thứ tiến triển thế nào hay làm sao mọi người có thể giúp anh ta. Dù anh ta làm bất cứ việc gì cũng không ai thực sự biết. Một cách hiển nhiên, nhà phát triển này không hiểu lợi ích của Daily Scrum nên không bao giờ tham dự.
• Một nhà phát triển thường xuyên dành những buổi tối của mình để tự ý loại bỏ những đoạn code của nhóm , thay thế bằng những đoạn code mà cô ấy cảm thấy vượt trội so với những gì nhóm đã làm - bất chấp sự thất vọng ngày càng gia tăng trong nhóm phát triển.
• Một nhà phát triển sử dụng mọi cơ hội anh ta có để thể hiện sự bất mãn với Scrum, là người khởi xướng nhiều cuộc tranh luận căng thẳng trong các sự kiện Scrum khác nhau, làm mọi người sao nhãng khỏi những vấn đề trong tầm tay của họ.
• Một nhà phát triển thường xuyên ỷ lại vào thâm niên của mình và liên tục chỉ trích tiêu cực đối với công việc của người khác. Nó khiến cho mọi người cảm thấy bấp bênh và không an toàn khi anh ta ở trong phòng.

Nếu những ví dụ trên chưa phải lý do đủ thuyết phục để loại bỏ một người ra khỏi nhóm. Vậy điều gì sẽ xảy ra nếu các điều kiện sau đây cũng chính xác :

• Tình trạng đó đã điễn ra trong một thời gian và không có triển vọng cải thiện. Bầu không khí trong nhóm ngày càng căng thẳng
• Nhóm phát triển nhận thức rõ tình hình và có một chút không thích nó. Đã có nhiều cuộc trao đổi về tình trạng đó trong các buổi cải tiến Sprint. Nhưng không có ý chí để hành động. Nhóm này ngại hành động, họ e ngại rằng đó không phải trách nhiệm của họ và không có can đảm để đưa ra quyến định mạnh mẽ như loại bỏ một người nào đó ra khỏi nhóm
• Scrum Master đã có những cuộc trao đổi với thanh viên được đề cập để họ nhận thức được ảnh hưởng của họ đối với nhóm

Nói một cách khác, có một cuộc xung đột chưa giải quyết làm ảnh hưởng tới hoạt động của nhóm Scrum. Kết quả là, bạn có thể bắt đầu thấy những thứ như mọi người bỏ qua các sự kiện Scrum để tránh xung đột, các cuộc thảo luận hữu ích sẽ được rút ngắn(hoặc loại bỏ hoàn toàn) và mọi người sẽ ít cởi mở và minh bạch hơn về công việc của họ. Cân nhắc về cuộc xung đột như vậy, liệu nó có thực sự hợp lý đối với một Scrum Master không làm gì và chờ cho nhóm tự đưa ra quyết định ? Nếu mọi người đều rõ ràng rằng điều này là không hiệu quả, và nó ảnh hưởng tới việc nhóm hoạt động tốt như thế nào , thì Scrum Master chính là người thích hợp - với vai trò là nhà lãnh đạo phục vụ - bước vào và làm những gì cần làm - không quan tâm điều đó khó khăn như thế nào.

Có phù hợp với đạo đức không khi một Scrum Master không làm gì và đợi cho nhóm tự đưa qua quyết định ?

Một tác động tới sự tin tưởng ?

Một phản đối phổ biến là việc loại bỏ thành viên ra khỏi nhóm có thể làm hỏng sự tin tưởng. Làm sao mọi người có thể cảm thấy an toàn khi mà họ biết Scrum Master có thể hành động như thế ?

Lập luận này bắt đầu với giả định rằng có một "môi trường đáng tin tưởng" có thể bị tổn hại. Nhưng nếu một nhóm đang ứng phó với một cuộc xung đột chưa được giải quyết - như những ví dụ nói trên - đã có rất nhiều thứ đang diễn ra đang ảnh hưởng mạnh mẽ tới sự tin tưởng. Có khả năng rất lớn là nhóm đang tồn tại trong trạng thái hòa hợp giả tạo - một trạng thái không lành mạnh. Lấy các hành vi sau đây làm minh họa cho một môi trường tin tưởng; chúng có xảy ra trong một nhóm với những xung đột được đề cập trước đó không ? :

• Có những cuộc trao đổi khó khăn mà không sợ bị trả thù ;
• Nghiêm trọng hóa hoặc hoài nghi về điêù gì đó mà không sợ bị trả thù hoặc mang ra làm trò đùa ;
• Phạm sai lầm mà không bị đổ lỗi hoặc trừng phạt ;
• Dựa vào những người khác trong nhóm giúp bạn khi bạn gặp bế tắc ;
• Có khả năng "chiến đấu thân thiện" (có một cuộc tranh luận căng thẳng mà không ảnh hưởng tới mối quan hệ giữa những người liên quan);
• Thừa nhận rằng bạn không biết điều gì đó hoặc sợ điều đó mà không phải lo lắng gì tới hậu quả;
• Tin tưởng rằng những gì mọi người nói thực sự là những gì họ nghĩ;

Nếu bạn đọc giữa các dòng này, nó cần một ít nỗ lực để có thể liên kết sự thiếu vắng những hành vi này với sự thiếu tính minh bạch, thanh tra và thích nghi - các nguyên tắc cốt lõi của quá trình thực nghiệm mà Scrum được hình thành từ nó và là cốt lõi của những gì Scrum Master cần bảo vệ.

Điều ngược lại có phải là đúng đắn ? Thay vì giảm dần sự tin tưởng, việc loại bỏ một thành viên khỏi nhóm giúp phục hồi sự tin tưởng. Dưới góc độ động lực nhóm, nó tạo ra không gian cho nhóm để tìm ra cách cộng tác hiệu quả hơn. Và Scrum Master cũng đã chứng minh rằng họ sẵn sàng đưa ra quyết định khó khăn như loại bỏ một thành viên nào đó vì lợi ích chung của nhóm. Thay vì làm giảm sự tin tưởng, sự loại bỏ có thể là một tín hiệu mạnh mẽ để giúp khôi phục sự tin tưởng.

Thay vì làm giảm sự tin tưởng, sự loại bỏ có thể là một tín hiệu mạnh mẽ để giúp khôi phục sự tin tưởng.

Tại sao lại không ủy quyền quyết định cho nhân sự hoặc quản lý ?

Một câu trả lời thường gặp cho tình huống hóc búa trong bài viết này đó là ủy quyền quyết định cho một số bên ở ngoài nhóm, ví dụ như nhân sự hoặc quản lý . Hãy để họ đưa ra quyết định dựa trên các bằng chứng được trình bày. Tuy nhiên, cách tiếp cận này cho thấy sự tồn tại của niềm tin truyền thống về vai trò của quản lý trong Scrum.

Để làm việc hiệu quả với Scrum , Hướng dẫn Scrum chỉ quy định 3 vai trò : một chủ sản phẩm (PO), một Scrum Master và một nhóm phát triển. Cùng nhau, ba vai trò đó có toàn quyền quyết định trong việc phát triển sản phẩm và quy trình nội bộ như một nhóm. Mặc dù nhà quản lý chắc chắn vẫn tham gia, họ không phải là những người đưa ra quyết định. Nếu có, nó sẽ làm suy yếu tính tự tổ chức của nhóm Scrum và báo hiệu rằng sau tất cả, sức mạnh đưa ra quyết định về phát triển sản phẩm và quy trình nội bộ không thực sự thuộc về nhóm Scrum. Có, hoặc muốn ủy quyền các loại quyết định như này báo hiệu rằng nhóm không thực sự là nhóm tự tổ chức. Nó trở lên rất hữu ích nếu bạn nhớ rằng quyết định loại bỏ ai đó khỏi nhóm không có nghĩa là họ sẽ bị sa thải. Họ có thể có giá trị rất quan trọng trong một nhóm khác hoặc một vị trí khác trong công ty - chỉ là không phù hợp với nhóm này.

Rất có ích để nhớ rằng đó không phải là sa thải một người khỏi công ty , mà chỉ là đưa ra khỏi một nhóm

Như vậy, bạn loại bỏ một ai đó ra khỏi nhóm bằng cách nào ?

Loại bỏ một người nào đó ra khỏi nhóm là một quyết định vô cùng khó khăn, và thực sự phải là phuơng án cuối cùng. Scrum Master nên làm tất cả những gì có thể để giúp cho nhóm phá triển có thể tự giải quyết xung đột. Nhưng nếu tất cả đều thất bại, sự loại bỏ có thể là một lực chọn khả thi. Mặc dù gần như chắc chắn không có cách tốt nhất để loại bỏ một người khỏi một nhóm, dưới đây là một số điều có thể cân nhắc :

• Đảm bảo rằng người được đề cập đã có đủ cơ hội để cải thiện. Như vậy, quyết định sẽ không đến như một sự bất ngờ hoàn toàn.
• Hãy trung thực về những lý do lọai bỏ một ai đó khỏi nhóm.
• Không loại bỏ thành viên ra khỏi nhóm trước mặt mọi người. Gặp riêng người đó và thông báo quyết định. Hãy thân thiện, thông cảm nhưng vững vàng và kiên quyết. Hãy dành đủ thời gian để người đó đủ cơ hội phản hồi và hỏi tất cả những gì trong ý nghĩ của họ.
• Đảm bảo rằng bạn đã liên kết tất cả những người và phòng ban cần thiết trong quyết định (ví dụ nhân sự, quản lý), trong khi vẫn kiểm soát quyết định mà bạn đưa ra với vai trò Scrum Master.
• Không làm nó trở thành cá nhân và không sử dụng các lý do cá nhân để đưa ra quyết định. Dựa trên những gì được quan sát đúng và (ít nhất) chia sẻ bởi đa số thành viên của nhóm.
• Quyết định cùng nhau làm thế nào để tiến hành công việc từ đây. Tùy thuộc vào tình hình, một thành viên có thể muốn rời đi ngay lập tức. Nhưng họ cũng có thể muốn hoàn thành Sprint hiện tại. Trong bất kỳ trường hợp nào, hãy đảm bảo rằng sẽ theo sát người đó một vài ngày sau quyết định.
• Khi quyết định được đưa ra, hãy chia sẻ nó với nhóm phát triển. Hãy cho họ cơ hội phản hồi và đối ứng với những gì đã xảy ra. Đây có thể là khoảnh khắc cho sự khuây khỏa nhưng cũng là cho một cuộc trao đổi khó khăn về cách thức ngăn chặn việc tương tự trong tuơng lai.
• Loại bỏ ai đó khỏi một nhóm thực sự là khó khăn - đặc biệt là cho người bị loại bỏ. Hãy trở nên đặc biệt tôn trọng và cảm thông.
• Đừng khoe khoang với người khác về cách bạn loại bỏ ai đó khỏi nhóm hay cách bạn bước lên và làm điều gì đó khó khăn. Hãy đối xử với người bạn loại bỏ và tình huống cần thiết với sự tôn trọng tối đa. Loại bỏ một ai đó khỏi nhóm không phải là một thứ đáng tự hào.

Thế còn chủ sản phẩm thì sao ?

Chúng tôi cảm thấy rằng những lý do được nêu trong bài viết này cũng áp dụng cho chủ sản phẩm. Có rất nhiều cách mà chủ sản phẩm có thể cản trở trò chơi :

• Chủ sản phẩm không sẵn lòng hoặc không đủ sẵn sàng để nhóm phát triển có thể làm rõ các yêu cầu và xác định những gì cần phải xây dựng
• Chủ sản phẩm không có quyền hạn hoặc không đủ tầm nhìn về sản phẩm để có thể đưa ra bất kỳ quyết định nào về sản phẩm , làm cho việc thanh tra và thích nghi một cách nhanh chóng trở trên khó khăn
• Chủ sản phẩm tạo ra một bầu không khí không hữu ích cho Scrum, ví dụ : tập trung mạh vào các cam kết và kiểm soát

Nếu tất cả các giải pháp khác đều đã thất bại, phương án cuối cùng của Scrum Master là thay thế chủ sản phẩm bằng một người nào đó từ bên trong hoặc bên ngoài tổ chức phù hợp hơn với vai trò đó. Nếu như không thể tìm thấy người đó, giá trị của Scrum Master sẽ giảm sút tới mức mọi người có thể tự hỏi liệu nó có hữu ích để tiếp tục hay không. Điều này - một lần nữa - nhấn mạnh rằng Scrum Master cần một sự ủy quyền từ nhà quản lý.

Kết luận

Scrum Master chủ yếu chịu trách nhiệm về khung làm việc Scrum và cho quá trình thực nghiệm làm nền tảng cho nó. Đôi khi, điều này có thể yêu cầu Scrum Master loại bỏ ai đó khỏi nhóm. Xung đột kéo dài trong các nhóm giữa các cá nhân có thể phá vỡ môi trường tin tưởng cho quá trình thực nghiệm làm việc(xem các ví dụ trong bài). Bởi vì đặc tính tự tổ chức của nó, nhóm phát triển cần được hỗ trợ trong bất kỳ cách nào để tự giải quyết xung đột. Nhưng nếu như nhóm phát triển không thể tự giải quyết xung đột ngay cả sau những nỗ lực lặp đi lặp lại, nó trở thành trở ngại cho Scrum Master giải quyết. Trong trường hợp này, Scrum Master - với vai trò của nhà lãnh đạo phục vụ - có trách nhiệm và quyền hạn để hành động; vì lợi ích của nhóm và quá trình thực nghiệm của Scrum. Rõ ràng , đây là phương án cuối cùng và một điều gì đó cần tránh.

(*Nguồn :https://www.scrum.org/resources/blog/myth-13-scrum-master-cant-remove-people-scrum-team *)