Những tiêu cực của các nhà quản lý phát triển như Scrum Master là gì?


27

Người ta thường đồng ý rằng các nhà quản lý nhóm không nên là những bậc thầy scrum, nhưng tôi đang đấu tranh để xem tại sao. Về ngữ cảnh, tôi là Quản lý phát triển ứng dụng với 4 nhà phát triển trong Nhóm Scrum. Tôi đến từ nền tảng Scrum Master và đã giới thiệu scrum cho tổ chức. Tôi đã xây dựng đội ngũ từ đầu và nói rõ rằng mọi việc tôi làm là để tạo điều kiện cho nhóm và họ đưa ra quyết định. Với tư cách là một đội, chúng tôi rất cởi mở - họ thậm chí còn làm tôi im lặng trong một lúc để loại bỏ cảm giác 'báo cáo' mà chúng tôi đang bắt đầu có được. Sự thiếu cởi mở nói chung là lý lẽ lớn nhất chống lại người quản lý là chủ scrum, nhưng xử lý tốt, dễ dàng vượt qua với văn hóa đúng đắn.

Tôi đã được cảnh báo bởi các huấn luyện viên scrum có kinh nghiệm rằng đây là một tình huống nguy hiểm và có những rủi ro 'nếu mọi thứ trở nên tồi tệ'. Cách tôi nhìn nhận, 2 vị trí không xung đột, trong cả hai vai trò tôi đều có cùng mục tiêu cho nhóm và cá nhân. Scrum giải quyết xung đột trong nhóm, theo truyền thống có thể là vai trò của người quản lý. Bản chất tự quản lý của chạy nước rút lấy đi sự phân bổ công việc mà một người quản lý thường làm.

Tất cả những gì tôi thực sự thấy còn lại với tư cách là người quản lý dev là đảm bảo nhu cầu cá nhân được đáp ứng, mục tiêu nghề nghiệp, nơi làm việc, v.v. Tôi có một tuần bắt kịp với mỗi thành viên trong nhóm để đưa ra bất kỳ vấn đề nào và xử lý bất kỳ nhiệm vụ quản trị viên nào. Rất nhiều điều này liên quan trực tiếp đến đội, hoặc vai trò của tôi là chủ scrum.

Tôi hiểu trong các tổ chức lớn làm thế nào điều này có thể không thể quản lý và có vai trò riêng biệt nhưng đối với một tổ chức nhỏ, chúng tôi chắc chắn không thể biện minh cho một Scrum Master hoặc Development Manager khác.

Xin hãy soi sáng cho tôi về những cạm bẫy của các Nhà quản lý phát triển với tư cách là Scrum Master, ngoại trừ những điểm tôi nêu ra ở trên và đã vượt qua.



Chủ sở hữu sản phẩm là ai?
Aaron Kurtzhals

@Thomas, Cảm ơn. Tôi đã nhìn thấy những điều này, và yếu tố chính trong đó là 'thứ hạng kéo' mà tôi đã cố gắng phác thảo mà tôi không làm được.
SpoonerNZ

@AaronKurtzhals, Chủ sở hữu sản phẩm là người quản lý tiếp thị kỹ thuật số của chúng tôi, sản phẩm chính của đội là một trang web. Có thể đáng chú ý tôi đã thực sự là huấn luyện viên của toàn đội.
SpoonerNZ

Theo ý kiến ​​của tôi, bất kỳ ai cũng là chủ sở hữu sản phẩm nên không bao giờ chạy scrum. Tài nguyên QA không phải là một lựa chọn tồi vì nó giữ cho chúng bám sát với những gì đang đi xuống. Các nhà phát triển là một lựa chọn meh vì họ có quyền lợi trong việc giữ cho khối lượng công việc nhẹ nhàng.
Giàn khoan

Câu trả lời:


18

Về cơ bản, bạn có một xung đột lợi ích. Công việc của người quản lý là đáp ứng thời hạn. Công việc của một bậc thầy scrum là đảm bảo các ước tính chính xác nhất có thể và làm việc với tốc độ bền vững. Một người quản lý có xu hướng muốn có nhiều công việc hơn trong một cuộc chạy nước rút, và một bậc thầy scrum có xu hướng muốn một số tiền có thể được hoàn thành thực tế, bất kể thời hạn bên ngoài. Mặc dù một người quản lý giỏi có thể cân bằng xung đột đó, nhưng sẽ dễ dàng hơn nhiều khi công việc được phân chia giữa hai người. Người quản lý thường phù hợp hơn nhiều cho vai trò chủ sở hữu sản phẩm.

Không có gì sai khi đóng vai trò là bậc thầy scrum nếu không có ai trong nhóm của bạn quen thuộc với nó, nhưng nhóm của bạn sẽ thấy lợi ích nếu bạn thực hiện vai trò đó sau một vài tháng. Điều quan trọng là vai trò đó được coi là ngang hàng. Ngay cả các bậc thầy scrum không quản lý cũng thường phải xoay vòng sau một thời gian vì nhóm bắt đầu đối xử với họ quá giống như một người quản lý.


Tôi hoàn toàn đồng ý nếu nó nói 'một bậc thầy scrum có xu hướng muốn có số tiền phù hợp'.
SpoonerNZ

24

Tôi tin rằng vấn đề chính là với tư cách là người quản lý, bạn có quyền nói với nhóm phải làm gì. Một chủ scrum không có thẩm quyền này ngoài việc thực thi các nguyên tắc của Scrum.

Điều đó có nghĩa là gì? Đầu vào của người quản lý sẽ mặc nhiên mang nhiều trọng lượng hơn. Bạn có thể không có ý đó, hoặc muốn nó, nhưng vào cuối ngày sự nghiệp và tiền lương của các thành viên trong nhóm của bạn phụ thuộc một cách nào đó vào bạn. Và họ biết điều đó. Và điều này làm mờ đi mối quan hệ.

Bạn vẫn có thể làm điều đó? Tất nhiên. Bạn chỉ cần làm việc rất chăm chỉ để củng cố rằng bạn là một người lãnh đạo đầy tớ và từ trên xuống sẽ không bay.


Tôi hiểu điều này và cảm thấy rằng trong đội của chúng tôi, chúng tôi đã vượt qua điều này - thường thì trong các quyết định hồi cứu sẽ được đưa ra mà tôi không nhất thiết phải đồng ý, nhưng tôi có niềm tin vào đội nên rất vui khi họ chơi hết. Nếu đây là lý do DUY NHẤT, tôi nghĩ tôi an toàn, do đó câu hỏi tìm kiếm lý do khác.
SpoonerNZ

2
Tôi là một người quản lý dev, người đã hành động như một bậc thầy scrum, và đây chính xác là vấn đề tôi gặp phải. Đó là cách quá hấp dẫn để dành scrum nói với mỗi nhà phát triển những gì họ sẽ làm. Nó đã làm việc tốt hơn cho chúng tôi để có một nhà phát triển cao cấp là bậc thầy scrum.
Gort Robot

24

Tôi thực sự đã thấy những gì xảy ra khi một "người quản lý kỹ thuật" tham gia quá nhiều vào các cơ chế hàng ngày của một dự án, và nó không hay. Trong trường hợp của chúng tôi, người quản lý được đề cập không phải là chủ scrum mà đang cố gắng đồng ý một số quyết định đó; Nếu chúng ta không thực sự một bậc thầy scrum riêng biệt để chơi phòng thủ thì điều đó sẽ đau đớn hơn nhiều.

(Ngẫu nhiên, đây không phải người quản lý của tôi , vì vậy tôi cảm thấy khá khách quan về điểm này.)

Tôi sẽ xem xét những gì tôi thấy là xung đột lợi ích chính; nếu bạn không nghĩ rằng bất kỳ điều nào trong số này áp dụng cho tình huống của bạn, thì có lẽ bạn có thể làm cả hai. Nhưng hãy chắc chắn rằng bạn kiểm tra lại các giả định này một cách thường xuyên để đảm bảo bạn không rơi vào bất kỳ bẫy nào sau đây:

  1. Các nhà quản lý kỹ thuật thường chịu trách nhiệm cho một vai trò nhất định trong nhiều nhóm. Nếu chỉ có một đội, thì đó là "người dẫn đầu" nhiều hơn là "người quản lý". Sự dàn trải trách nhiệm này có nghĩa là ít thời gian hơn với nhóm và ít thời gian hơn với dự án / sản phẩm và có xu hướng dẫn đến quản lý theo kiểu "hit and run".

  2. Quản lý kỹ thuật có nhiều nhiệm vụ quản lý khác cho doanh nghiệp. Họ cần làm huấn luyện / đào tạo, đánh giá hiệu suất, phỏng vấn / tuyển dụng, cơ sở hạ tầng / kế hoạch tài nguyên dài hạn, v.v. Điều này có thể dễ dàng trở thành một công việc toàn thời gian và có nghĩa là rất ít để dành cho việc tạo điều kiện.

  3. Một lịch trình bận rộn cũng có thể áp đặt cho đội; các nhà quản lý kỹ thuật có thể cần (hoặc muốn) để kéo các thành viên trong nhóm vào các cuộc họp tại thời điểm mà nhóm cho là thời điểm không thuận lợi. Thông thường, công việc của chủ scrum là quản lý và cố gắng loại bỏ các gián đoạn, nhưng không thể khách quan về điều đó khi bạn có lịch trình riêng để lo lắng. Các bậc thầy Scrum hiếm khi cần gặp riêng với các thành viên trong nhóm vì tất cả các cuộc họp đó đã được lên lịch trước (đứng lên, hồi tưởng, v.v.)

  4. Các nhà quản lý kỹ thuật phải đối phó với các mối quan tâm xuyên suốt của dự án và sự thúc đẩy tự nhiên của họ sẽ là cố gắng chuẩn hóa mọi thứ - thư viện, kiểm soát nguồn, thuật toán, bố cục, màu sắc, bất cứ điều gì. Mặc dù điều này thực sự có thể là một điều tốt cho công ty, nhưng cuối cùng nó không khiến ai phải làm nũng vì những gì nhóm muốn làm, và họ có thể có những lý do rất chính đáng để muốn làm điều gì đó khác biệt. Điều này chạy ngược lại với những lý tưởng "cải tiến liên tục" bên dưới Scrum và các phương pháp tương tự.

  5. Các nhà quản lý xuất thân từ một chuyên gia trong vai trò mà họ quản lý sẽ có những ý tưởng khá mạnh mẽ của riêng họ về cách thức thực hiện công việc và thời gian cần thiết. Đây không phải là một điều xấu với tư cách là người quản lý , nhưng với tư cách là một bậc thầy scrum, điều đó thường có nghĩa là thiên vị các thành viên trong nhóm trong các thiết kế hoặc ước tính mà họ sẽ không đồng ý - và họ có thể biết nhiều hơn bạn về vấn đề này.

  6. Các thành viên trong nhóm sẽ luôn gặp khó khăn trong việc phân biệt giữa yêu cầu và đơn đặt hàng. Họ sẽ không nói với bạn điều này và thậm chí có thể không nhận ra điều đó. Ngay cả khi bạn nói rõ rằng bạn chỉ đang hỏi và không nói, trong suy nghĩ của họ, bạn vẫn là người quản lý của họ và có những rủi ro ở cấp độ nghề nghiệp khi nói "không". Đây có lẽ là vấn đề ngấm ngầm nhất trong tất cả các vấn đề bởi vì bạn không thể làm gì về vấn đề này - đó là thái độ của họ chứ không phải vấn đề của bạn .

Nếu bạn chắc chắn rằng bạn sẽ không bao giờ rơi vào bất kỳ bẫy nào trong số này, thì hãy tiếp tục ... nhưng tôi nhắc lại, hãy đảm bảo bạn thường xuyên xác thực các giả định của mình bằng cách nói chuyện với nhóm của bạn (và các đội / quản lý khác!) và đảm bảo rằng chúng không xảy ra theo cách tinh tế hoặc vô thức mà có thể bạn không nhận thấy.

Nói một cách tích cực, tôi sẽ nói thêm rằng việc bạn coi vấn đề đủ quan trọng để thực sự đặt câu hỏi có nghĩa là bạn có thể khá giỏi trong cả hai vai trò. Quan tâm đến nhóm và không chỉ là tham vọng nghề nghiệp của riêng bạn có lẽ chiếm hơn một nửa so với quản lý tốt, trong sách của tôi dù sao đi nữa.

... nhưng giỏi cả hai không nhất thiết có nghĩa là bạn có thể giỏi cả hai cùng một lúc, mọi lúc . Hãy cẩn thận về điều đó.


7

Đây không phải là tôn giáo và các quy tắc của Scrum không phải là giáo điều. Nếu đã từng có trường hợp cho vai trò Quản lý nhân sự / Srum Master kết hợp, bạn đã thực hiện một vai trò tốt. Hãy cảnh giác với những cạm bẫy mà bạn đã đề cập, nhưng sẽ không bao giờ có một bộ quy tắc duy nhất phù hợp với mọi tình huống một cách hoàn hảo.

Nếu nhóm của bạn cảm thấy thoải mái khi bạn thực hiện cả hai vai trò, thì không có lý do gì để bắt đầu mọi thứ chỉ để phù hợp với các quy tắc của một cuốn sách.


2
Đây là câu trả lời thực dụng nhất +1
ozz

3

Vấn đề lớn nhất tôi thấy là tình huống nhóm có vấn đề liên quan đến bạn, người quản lý. Nếu họ là thiếu niên, hoặc thiếu tự tin, họ có thể sợ phải lên tiếng trong quá trình hồi tưởng. Điều này có thể hạn chế tính hiệu quả của các hồi cứu. Nhiều người sợ nói "Tôi cảm thấy người quản lý không thực tế" khi người quản lý có mặt.

Vì vậy, có thể bạn tha thứ cho mình khỏi quá khứ để giải quyết vấn đề này. Bây giờ nhóm của bạn đang thực hiện hồi cứu mà không có chủ scrum, cũng có khả năng hạn chế hiệu quả của quá trình hồi cứu.

Trong cả hai trường hợp, bạn đang có một tác động tiêu cực đến nhóm.


2

Vấn đề chính tôi thấy là bạn đang gửi tin nhắn mâu thuẫn cho nhóm về tổ chức của nhóm.

Dưới đây là hai tổ chức nhóm có thể. Cả hai đều có thể thành công. Họ khác nhau. (Chúng không phải là lựa chọn duy nhất có thể.)

  1. Nhóm nghiên cứu có một nhà lãnh đạo được chỉ định chính thức. Trưởng nhóm chịu trách nhiệm cuối cùng cho hiệu suất chung của các đội. Trưởng nhóm có thể không đưa ra tất cả các quyết định, nhưng trưởng nhóm có tiếng nói cuối cùng về tất cả các quyết định.
  2. Nhóm tự tổ chức và không có một nhà lãnh đạo được chỉ định chính thức. Mọi người trong nhóm chịu trách nhiệm về hiệu suất chung của chính họ và của đội. Scrum Master tạo điều kiện cho quá trình Scrum, nhưng không được trao quyền để đưa ra quyết định đơn phương cho nhóm.

Nghe có vẻ như cấu trúc nhóm thực sự của bạn là # 1, nhưng bằng cách sử dụng thuật ngữ và một số quy trình từ Scrum, bạn đang ám chỉ rằng cấu trúc đó là # 2. Ý kiến ​​của tôi là # 1 không phải là Scrum.

Dưới đây là hai gợi ý về cách giải quyết xung đột.

  1. Tiếp tục làm mọi thứ như bạn, nhưng làm rõ rằng bạn là trưởng nhóm và bạn không theo dõi Scrum 100%. Có lẽ sẽ giúp giải thích rằng trong khi bạn thấy giá trị trong việc tách biệt nhiệm vụ của người quản lý và chủ scrum, điều đó không khả thi đối với công ty.
  2. Trao trách nhiệm Scrum Master, càng nhiều càng tốt cho người khác. Ngay cả khi bạn vẫn phải duy trì một số trách nhiệm như xóa các rào cản và làm chệch hướng những phiền nhiễu từ phần còn lại của tổ chức, thì vẫn sẽ giúp phần lớn công việc của Scrum Master được thực hiện bởi một người ngang hàng.

1

Những tiêu cực của các nhà quản lý phát triển như Scrum Master là gì?

Quản lý phát triển được thuê để:

  • Giải quyết các vấn đề phát triển .
  • Theo dõi và giảm nợ kỹ thuật.
  • Phát triển đội ngũ kỹ thuật.

Nền tảng và chuyên môn của họ khiến họ tập trung vào các vấn đề kỹ thuật .


Mặt khác, các nhà quản lý dự án / thạc sĩ scrum được thuê để;

  • Đảm bảo thành công dự án.
  • Chỉ định công việc và xử lý lỗi / câu hỏi cho các tài nguyên phát triển phù hợp.
  • Phối hợp với nhóm phát triển để loại bỏ tất cả các trở ngại có thể trì hoãn hoàn thành dự án.
  • Chuyển tiếp tình trạng dự án để quản lý cấp trên.

  • Khi một dự án hoặc một công ty phát triển đến một quy mô nhất định, sẽ không hiệu quả và không khôn ngoan khi yêu cầu người quản lý phát triển thực hiện cả hai nhiệm vụ.
  • Người quản lý phát triển nên có khuynh hướng đưa "lặn sâu" vào mã và / hoặc kiến ​​trúc, trong khi đó, người quản lý dự án / chủ scrum luôn phải quan tâm đến quan điểm "50.000 feet".

  • Hầu hết các nhà quản lý phát triển đã dành nhiều năm để phát triển mã. Vấn đề phát triển rất quen thuộc với họ.

    • Do đó, chúng hữu ích nhất khi chúng đang giải quyết các vấn đề kỹ thuật.
  • Vai trò quản lý dự án / scrum master yêu cầu những người có tổ chức và định hướng rất chi tiết, nhưng không siêu kỹ thuật.
  • Khi bạn có thể đủ khả năng để cho những người này chuyên về những điều họ giỏi, thì công việc kinh doanh hiệu quả nhất.
  • Và khi bạn có thể giảm tải các trách nhiệm liên quan đến scrum từ một người quản lý phát triển, anh ấy / cô ấy có thể dành nhiều thời gian hơn cho các vấn đề kỹ thuật và giảm nợ kỹ thuật.

Tôi đã đánh giá thấp điều này khi bạn dường như không mô tả chính xác người quản lý phát triển hoặc người quản lý scrum. Ngoài ra câu hỏi này không liên quan gì đến quản lý dự án.
SpoonerNZ

0

Tôi sẽ lắng nghe huấn luyện viên scrum có kinh nghiệm. Có thể là bạn sẽ làm việc tốt trong 99% thời gian. Tuy nhiên, khi 1% đáng sợ đó xuất hiện và xung đột vai trò bạn có cơ hội làm hỏng không chỉ mối quan hệ của một cá nhân với bạn mà cả tình trạng của cả đội. Và sau một lần làm hỏng vai trò của bạn, cả người quản lý và người quản lý scrum sẽ bị hủy hoại.

Nếu tôi là bạn, tôi sẽ xác định một cá nhân trong nhóm có tiềm năng trở thành bậc thầy về scrum và đi cùng anh ấy / cô ấy. Tôi luôn xem một bậc thầy scrum là người mà nhóm tin tưởng và là người hiểu quy trình, công việc kinh doanh và các công cụ kỹ thuật đáng sợ. Nếu bạn chọn một người có khả năng, vai trò chủ scrum không phải (và thậm chí không gần với) một công việc toàn thời gian.


3
Trở thành một bậc thầy scrum có thể dễ dàng trở thành một công việc toàn thời gian tùy thuộc vào môi trường bạn đang ở. Việc loại bỏ các trở ngại và hoạt động can thiệp cho nhóm có thể cực kỳ tốn thời gian trong các công ty (đặc biệt là các công ty quan liêu lớn) không được sử dụng cho các phương pháp Agile.
Matthew Flynn

1
@MatthewFlynn: Điểm tốt. Tuy nhiên ... trong trường hợp đó, họ sẽ có đủ nguồn lực để dành cho một người kiểm tra toàn thời gian (tôi có cảm giác từ bài đăng rằng có sự thiếu hụt tài nguyên). Tuy nhiên, tôi làm việc tại một trong những công ty lớn mà bạn đề cập và một bậc thầy scrum toàn thời gian vẫn không phải lúc nào cũng được bảo hành. Chúng tôi vẫn có họ nhưng họ thường cản trở nhóm làm việc hiệu quả vì họ gây ra nhiều rắc rối hơn trong khi cố gắng biện minh / làm quá mức các vị trí toàn thời gian của họ.
c_maker

1
Điểm tốt trở lại ngay tại bạn. Tôi cho rằng nó phụ thuộc vào công ty và cá nhân. Không ngạc nhiên, thực sự.
Matthew Flynn

1
Cảm ơn vì sự trả lời. Tôi đang cố gắng xác định những gì có thể gây ra, hoặc là 'đáng sợ 1%', bởi vì tôi không thể thấy các vai trò xung đột như thế nào một khi rõ ràng với đội tôi là một người lãnh đạo đầy tớ. Một người lãnh đạo đầy tớ vẫn là một nhà lãnh đạo.
SpoonerNZ

Tôi cũng đã cân nhắc việc biến nhà phát triển cấp cao của chúng tôi thành một bậc thầy scrum, nhưng thực tế tôi không thể thấy nhiều việc phải làm! Lựa chọn khác mà tôi đã cân nhắc là trở thành bậc thầy về scrum chứ không phải người quản lý, nhưng Trưởng phòng CNTT sẽ không thích ý tưởng quản lý con người của toàn đội rơi vào anh ta.
SpoonerNZ
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.