Thành viên nhóm thống trị trong một nhóm Scrum

Bạn sẽ làm gì trong tình huống một thành viên trong nhóm cố gắng nhận trách nhiệm ban đầu không được giao cho anh ta mà là Scrum Master?

Nhóm Scrum tự tổ chức nên có chỗ cho ai đó chiếm ưu thế hơn một chút. Những người khác nên hỏi anh ta về ý tưởng của anh ta về các nhiệm vụ họ đang làm, nhưng sự thống trị của anh ta phải được kiểm soát.

Bạn có thể làm gì:

• Thúc đẩy người khác độc lập nhưng hợp tác - điều này có thể đạt được tốt nhất nếu bạn hợp tác với người quản lý và nhân sự của họ, người sẽ đặt ra cho họ một số kỳ vọng, sẽ được đánh giá một cách thường xuyên.
• Trong quá trình đứng lên, lập kế hoạch và hồi tưởng; Hãy để các thành viên khác trong nhóm nói trước. Trong quá trình đánh giá, hãy để các thành viên khác trong nhóm trình bày những câu chuyện của người dùng mà họ đã triển khai.
• Trước tiên, hãy chọn các nhiệm vụ khác để nhà phát triển vượt trội chỉ có thể chọn các nhiệm vụ mà mình muốn thực hiện.
• Tham gia lập trình cặp cho một số nhiệm vụ để thành viên nhóm thống trị đang cộng tác với các nhà phát triển khác.
• Hãy dân chủ - ý kiến ​​của một thành viên trong nhóm là không đủ để thực hiện các thay đổi cho quy trình - Scrum sẽ chỉ hoạt động nếu nhóm giao tiếp rõ ràng hoặc bạn sẽ chặn nhau.
• Nếu không điều này giúp bạn nên nói chuyện với thành viên nhóm thống trị và giải thích tình huống cho anh ta - nhưng hãy cẩn thận vì không có người lãnh đạo nhóm trong Scrum vì một lý do. Nếu bạn có sự hỗ trợ từ ban quản lý, bạn cũng có thể đe dọa sự ổn định công việc của anh ta, nhưng đây sẽ là lựa chọn cuối cùng.

Nếu thành viên nhóm thống trị không muốn mất sự thống trị của mình và các thành viên nhóm thụ động không muốn chủ động hơn, bạn sẽ cần sự hỗ trợ từ người quản lý và nhân sự của họ. Đây có thể là một vấn đề nếu quy trình Scrum không được quản lý khuyến khích.

Có lẽ, lý do cho câu hỏi này là bởi vì bạn cảm thấy rằng nhóm nào đó hoạt động kém vì người thống trị này. Có lẽ bởi vì phần còn lại của đội không đóng góp 100% bởi vì, tốt, vấn đề là gì?

Là người quản lý, nếu là bạn, bạn có trách nhiệm đảm bảo rằng tất cả nhân viên của bạn hiểu vai trò của họ là gì. Cụ thể, những gì mong đợi ở họ và cách họ sẽ được đánh giá. Là một thành viên trong nhóm trong nhóm Scrum, mỗi người chịu trách nhiệm cá nhân cho sự thành công của nhóm. Vì vậy, thành viên nhóm thống trị này cần biết rằng họ thất bại trong trách nhiệm đó và sẽ được đánh giá tương ứng.

Phản hồi là một điểm quan trọng. Nếu có một cuộc họp nhóm và người này chi phối cuộc thảo luận, buộc các thiết kế và cách tiếp cận của anh ta với các thành viên còn lại và đẩy những người còn lại vào vai trò thụ động thì anh ta cần phải nói một cách thẳng thắn và riêng tư rằng anh ta không đáp ứng được yêu cầu của vai trò. Nếu bạn phát hiện ra anh ta lén lút làm nổi bật những thành tích cá nhân của riêng anh ta, thì anh ta cần được gọi vào đó, và hiểu rằng thành tích cá nhân được đánh giá cao, ít hơn nhiều so với việc giúp nhóm có thành tích nhóm.

Tất cả đều khó khăn, nhưng đó là những gì các nhà quản lý và Scrum Master dành cho.

Có một cách khác có thể để đi về điều này. Làm cho nó một vấn đề nhóm. Gọi họ lại với nhau và nói với họ rằng họ đang đạt được kết quả thấp và đây là lý do. Yêu cầu họ đưa ra giải pháp. Bạn có thể ngạc nhiên.

Tại sao không hỏi ý kiến ​​nhà phát triển alpha. Hoàn toàn có thể anh ta không biết gì về hiệu ứng mà anh ta có. Hãy để anh ấy sang một bên và nói với anh ấy những gì bạn nghĩ. Bạn thậm chí có thể thảo luận về "hey bạn là nhà phát triển chính của chúng tôi, nhưng chúng tôi cần đưa những người này lên cấp của bạn, tôi cần sự giúp đỡ của bạn trong việc tìm ra cách chúng tôi có thể làm điều đó?". Biến sự thống trị của anh ấy thành một tài sản. Xem nếu anh ta có thể thấy cách làm điều đó.

Nếu anh ta đo lường mức độ anh ta hỗ trợ đội của anh ta và đưa họ lên cấp độ của anh ta thì anh ta sẽ có thêm động lực để làm điều đó.

Bạn ám chỉ rằng anh ta thực sự không làm việc vì lợi ích của đội (theo phỏng đoán của tôi), tức là anh ta xấu theo một cách nào đó, sau đó, hãy loại bỏ anh ta. Nhưng một người đàn ông khôn ngoan đã từng nói với tôi: Đừng cho rằng ý chí xấu, khi sự bất tài hoặc sự thiếu hiểu biết đơn giản có nhiều khả năng.

Có vẻ như anh ta cố gắng trở thành Scrum Master.

Làm rõ vị trí của bạn, và hành động phù hợp.

Vai trò của Scrum Master là cho phép tinh thần đồng đội. Nếu bạn không thể biến người này thành người duy nhất, hãy loại anh ta khỏi đội .

Lưu ý nhanh: Nhà phát triển vượt trội của bạn không có vấn đề gì hơn nhà phát triển thụ động của bạn.

kế hoạch chạy nước rút hiện tại là một vai trò xoay quanh đội

Lập kế hoạch chạy nước rút nên liên quan đến toàn bộ nhóm, không được trao cho một người tại một thời điểm. Trừ khi có một lý do chính đáng cho việc này, tôi thấy đây là một vấn đề nghiêm trọng.

Nếu những gì bạn đang nói là đúng và khách quan thì bạn có một vấn đề lớn trong tay: những người không tham gia và "Người thống trị", người ngăn cản một quá trình thực sự nhanh nhẹn. Là chủ srum, bạn phải hành động. Có lẽ bạn muốn đưa người quản lý dự án của bạn tự tin về tình huống này.

Nhiều đội đi lạc từ cốt lõi của sự nhanh nhẹn và công việc của bạn là đưa họ trở lại. Bạn cần dạy và nhúng lại các giá trị nhanh vào nhóm. Trong thực tế, bạn nên liên tục được dạy các giá trị nhanh. Giữ tầm nhìn của bạn nhanh nhẹn, làm cho nó rõ ràng và mạnh mẽ. Cho họ thấy cam kết của bạn về "nhanh nhẹn hoàn thành tốt".

Để làm điều này, hãy đưa chúng qua các tuyên ngôn nhanh và các giá trị Scrum. Hỏi họ ý nghĩa của sự hợp tác đối với họ và tại sao nó quan trọng. Hỏi họ về vai trò của niềm tin trong sự nhanh nhẹn. Đây là thời điểm tuyệt vời để nói về lý do tại sao không có vai trò lãnh đạo nhóm và không có vai trò quản lý dự án trong Scrum và trách nhiệm của toàn nhóm là tạo ra phần mềm tuyệt vời chứ không phải cá nhân.

Lập kế hoạch toàn bộ phiên hồi cứu xung quanh này. Yêu cầu họ cam kết với một số giá trị và theo dõi trong quá trình hồi cứu tiếp theo. Đừng chỉ tay, sử dụng các phương pháp trung tính.

Giới thiệu các phương pháp buộc các thành viên khác nêu ý kiến ​​của họ một cách an toàn. Một cái gì đó đơn giản như nắm tay năm là tuyệt vời để có được những giọng nói im lặng trong đội nghe. Nó làm cho đau đớn rõ ràng rằng nhóm không đồng ý với anh chàng thống trị. Lập kế hoạch Poker hoạt động tốt nhưng điều quan trọng là không cho phép bất kỳ cuộc thảo luận nào trước khi các thẻ được hiển thị. Bất cứ điều gì giúp người khác nghe mà không bắt đầu xung đột đều hữu ích.

Nếu mọi việc suôn sẻ, bạn đã sẵn sàng. Nếu không, hãy nói chuyện với anh ta về vấn đề. Sử dụng huấn luyện và đặt câu hỏi mạnh mẽ có thể giúp anh ấy nhận ra vấn đề rõ ràng. Cố gắng để đi đến nguyên nhân gốc rễ tại sao anh ta đã đảm nhận vai trò chi phối. Có lẽ anh ta thiếu niềm tin vào đội bóng (tại sao?) Và có thể anh ta cảm thấy mình có trách nhiệm với thành công (tại sao?). Tôi nghi ngờ vai trò này không phải là thứ anh ấy muốn và hoàn toàn có thể anh ấy muốn nó thay đổi. Anh ta có thể đến xung quanh và nhận ra nó.

Có lẽ nhà phát triển "thống trị" được khen thưởng bởi hiệu suất cá nhân của anh ấy hơn là thành tích của đội?

Trong quá khứ tôi đã đảm bảo rằng những người rất có tiếng nói và có ý tưởng rõ ràng cũng được khen thưởng (thông qua mục tiêu của họ) bằng cách thúc đẩy những đóng góp của người khác.

Nói chung, tôi nghĩ rằng đó là một ý tưởng tồi để thưởng cho các thành viên scrum một cách vững chắc về đóng góp cá nhân của họ hơn là vào thành tích của đội.

Bạn cũng có thể thử thực hiện vòng phản hồi 360 trong nhóm của mình cho tất cả các thành viên trong nhóm, chỉ khi bạn nghĩ rằng các thành viên khác trong nhóm sẽ trung thực trong nhận xét của họ.

Đề xuất rằng anh ta trở thành Scrum Master cho lần chạy nước rút sau.

Mọi người sẵn sàng nhận trách nhiệm không phải là vấn đề (miễn là họ không muốn độc quyền đối với họ), đó chính xác là những gì chúng tôi đang muốn đạt được với việc tự tổ chức.

Nhân tiện, các đội có vai trò chủ scrum luân phiên không phải là hiếm.

Nhiệm vụ duy nhất của chủ Scrum là đảm bảo mọi người chơi theo quy tắc sách Scrum. Nếu các bậc thầy không phải là Scrum sẽ tự làm điều đó mà không có sự can thiệp của chủ Scrum, điều đó sẽ cho thấy bạn đang ở trong hình dạng (Scrum-) tuyệt vời! Chủ Scrum càng ít phải làm, nhóm của bạn càng có ý nghĩa và tinh gọn hơn từ góc độ Scrum. Cuối cùng, vai trò của Scrum master có thể / nên bị loại bỏ, anh ta ở đó để giúp bạn bắt đầu và dạy cho bạn Scrum.

Một lần nữa, chủ Scrum không tham gia vào quá trình phát triển. Anh ta nên đảm bảo tất cả các bên liên quan trao đổi kịp thời về những điều đúng đắn, anh ta biết Scrum và cung cấp hướng dẫn làm Scrum, anh ta không phải là chủ sở hữu sản phẩm hoặc lãnh đạo dự án. Nếu bạn trải nghiệm điều gì đó khác biệt, bạn có thể không làm Scrum với tinh thần nhanh nhẹn. Tất nhiên, trong các cài đặt nhỏ hơn, Scrum master có thể là một trong những thành viên của nhóm hoặc chủ sở hữu cổ phần đóng vai trò phụ. Sau đó, nó chỉ là một cái mũ được đặt khi nó là thời gian cho các thủ tục. Đừng nhầm lẫn nó với vai trò lãnh đạo, đó là vai trò hướng dẫn.

Nắm bắt chủ nghĩa cá nhân và hiệu suất cá nhân, nhưng cũng cố gắng trao quyền cho các cá nhân thụ động để trở nên tham gia hơn.

Kinh nghiệm của tôi nói rằng mặc dù chúng có vẻ giống nhau từ cái nhìn đầu tiên, chủ nghĩa cộng sản và nhanh nhẹn không giống nhau. Agile không nhắm đến một xã hội không có giai cấp (nhóm) mà dành cho phần mềm hoạt động.

Cố gắng làm cho nhà phát triển alpha của bạn hiểu rằng anh ta có thể giúp bạn phát triển các kỹ năng khác bằng cách hỏi và huấn luyện, thay vì luôn trả lời trước và đạt được những thành tựu cá nhân. Chắc chắn nhà phát triển alpha của bạn là một người quan tâm đến phần mềm tốt và đó là thứ bạn không thể cho phép mình mất.