Là người quản lý nhóm và nhà phát triển trong nhóm Scrum

Tôi đang quản lý một nhóm gồm 6 người gần đây đã chuyển sang Scrum.

Chúng tôi có Scrum Master (một trong những nhà phát triển trong nhóm) và Chủ sở hữu sản phẩm.

Vì tôi có khá nhiều thời gian rảnh (vì rất nhiều công việc quản lý mà tôi từng làm hiện đang được Scrum Master và Product Chủ thực hiện) và vì tôi muốn duy trì liên quan về mặt kỹ thuật, tôi đang làm một số công việc phát triển kỹ thuật.

Tôi đóng vai trò là một phần của nhóm phát triển, cam kết thực hiện một số câu chuyện trong mỗi lần chạy nước rút và tham gia vào tất cả các cuộc họp với tư cách là một phần của nhóm.

Bạn có nghĩ rằng đó là một ý tưởng tốt? Nó có thể mâu thuẫn với "tự tổ chức" của đội không?

Hãy đọc những suy nghĩ đang phát triển của Roy Osherove về khả năng lãnh đạo nhóm trong một thế giới Agile tại 5whys.com

Anh ấy nói rất nhiều về ba giai đoạn quan trọng mà một đội trải qua khi nó phát triển từ Waterfall đến Scrum.

Giai đoạn sống sót (nơi mà hầu hết các đội tôi thấy đều tham gia) - trong đó nhóm không có thời gian để học - đòi hỏi một kiểu lãnh đạo và kiểm soát nhiều hơn để tạo ra thời gian học tập đó từ không có gì.

Giai đoạn học tập - nơi một nhóm có thời gian để học và đang sử dụng nó - đòi hỏi huấn luyện viên như người lãnh đạo, với sự kiểm soát khi mọi thứ sẽ mất quá nhiều thời gian để học một cách khó khăn (ví dụ như không chọn kiểm soát nguồn)

Giai đoạn tự tổ chức - Nơi các nhóm có thể tự giải quyết vấn đề của mình - đòi hỏi nhiều hơn về kiểu người lãnh đạo, điều đó không cho mọi người biết phải làm gì, mà chỉ cung cấp các ràng buộc và mục tiêu cuối cùng. Nhóm sẽ tự mình đến đó.

Khi tôi bắt gặp những ý tưởng của Roy, tại OpenVolcano '10 , tôi hoàn toàn không biết lý do tại sao nhóm của tôi đã ngừng cải thiện. Sau đó, tôi nhận ra rằng nhóm đã chuyển từ Sống sang Học và tôi đã không thay đổi phong cách quản lý của mình. Tôi đã làm như vậy và nó đã giúp rất nhiều.

Vì vậy, tôi khuyên bạn nên tìm ra giai đoạn nào trong ba giai đoạn mà bạn tham gia và quản lý theo đó.

Ngoài ra, đưa ra quyết định ngay bây giờ và là một nhà lãnh đạo hoặc một nhà phát triển. Đừng rơi vào cái bẫy nghĩ rằng bạn có thời gian rảnh rỗi cho đến khi bạn bước vào giai đoạn Tự tổ chức. Và, nếu bạn đến đó, hãy nhận ra rằng bạn là một người lãnh đạo nhóm tốt ( rất khó ) và chuyển sang một nhóm khác thay vì tái hòa nhập chính mình.

Nhận xét của pdr là hợp lệ, và tôi đồng ý với họ. Nhưng tôi không tin rằng chúng là phổ quát cho mọi trường hợp.

Phong cách quản lý của bạn sẽ quyết định mức độ tốt hoặc thậm chí nếu bạn nên xem xét làm việc trong hai vai trò.
Là người quản lý nhóm, bạn có thẩm quyền đối với các quyết định về hiệu suất và loại nghề nghiệp cho nhân viên của mình. Sử dụng không chính xác, sự chênh lệch quyền lực giữa bạn và chủ lao động có thể phá hỏng nỗ lực của bạn khi trở thành một phần của nhóm phát triển.

Miễn là bạn nhận thức được sự chênh lệch đó và bạn phân định rõ ràng giữa các vai trò của mình, tôi nghĩ rằng bạn có thể vừa là người quản lý vừa là nhà phát triển. Tôi đã thấy nó được thực hiện thành công một số lần và tôi hiện đang làm việc trong một nhóm trong tình huống tương tự.

Điều đáng chú ý là bạn không thể loại bỏ tất cả các ảnh hưởng của sự chênh lệch. Sẽ có lúc bạn cần cắn lưỡi và kìm nén từ một cuộc tranh luận sôi nổi. Sẽ có những người khác khi bạn cần rút con át chủ bài và chỉ ra rằng trách nhiệm cuối cùng đối với đội nằm ở bạn, vì vậy bạn đang tạo ra một diktat.

Bạn sẽ cần ít nhất hai nhà phát triển mạnh mẽ, có kinh nghiệm trong nhóm của bạn, những người an toàn về mặt chính trị. Vai trò của họ là giữ sự chênh lệch quyền lực trong kiểm tra và gọi bạn ra ngoài nếu mọi thứ mất cân bằng. Bạn có thể nhận được chỉ với một nhà phát triển mạnh khác, nhưng có một thứ hai cung cấp tính khách quan trong trường hợp hai bạn gặp bế tắc về một vấn đề.

Tôi thực sự thích nó khi người giám sát trực tiếp của tôi giữ cho mình liên quan đến kỹ thuật. Nó tạo điều kiện cho họ hiểu về những khó khăn của tôi và tôi nghĩ rằng chúng tôi kết thúc với một nhóm hoạt động tốt hơn.

Tôi đã trải qua một trải nghiệm tương tự trước đây, lãnh đạo một nhóm 6 nhà phát triển trong một nhóm Scrum. Bên cạnh những gì pdr và GlenH7 đã đề cập, những điều có ích:

1. Người thử nghiệm tốt nhất trong nhóm QA thực sự giỏi trong việc giữ cho chúng tôi có trách nhiệm với chất lượng công việc của chúng tôi, bao gồm cả công việc tôi đã làm. Khi tôi viết mã lỗi, cô ấy gọi tôi bằng mã theo cách mà nhà phát triển khác khó có thể làm được.
2. Tôi thường làm Sprint Demos, đặc biệt là khi chúng tôi có những lần chạy nước rút tồi. Vì tôi đã giới thiệu với CEO, thật xấu hổ khi mọi thứ không hoạt động. Ngoài việc đảm bảo rằng tôi hiểu các tính năng mà người khác phát triển, điều đó cũng có nghĩa là công cụ của tôi phải vững chắc như bất kỳ ai khác.
3. Tôi để người khác đưa ra quyết định. Kinh nghiệm của tôi khác với GlenH7, tôi luôn thấy đó là một sai lầm khi rút con át chủ bài. Thay vào đó, tôi đã nói về những hậu quả khác nhau của các quyết định, và nói rõ rằng nhà phát triển đã từng làm việc gì với những gì hậu quả đối với điều mà tôi nghĩ là cách làm "sai". Có nhiều lý do để làm điều này, nhưng lý do lớn nhất là khi lãnh đạo nhóm, bạn không có thời gian để đưa ra tất cả các quyết định.
4. Sử dụng một sản phẩm như Sonar có thể làm cho những thứ như chất lượng mã trở nên khách quan hơn.