Thực thi một cách tiếp cận Scrum thống nhất cho tất cả các nhóm trong một bộ phận

Nơi tôi làm việc, gần đây chúng tôi đã chuyển đổi phát triển Agile bằng Scrum. Chúng tôi đã trải qua những cơn đau ngày càng tăng điển hình nhưng đã đạt được một cách tiếp cận có vẻ hiệu quả cho đến bây giờ (liệu nó có hoạt động lâu dài hay không là một câu hỏi khác!).

Rõ ràng, ban quản lý bộ phận rất vui khi quá trình chuyển đổi sang Scrum đang hoạt động. Nhưng họ đã bắt đầu làm một cái gì đó, với tôi, cảm thấy sai.

Quản lý sẽ quan sát một nhóm, xem những gì làm việc cho họ và quy định nó cho toàn bộ bộ phận. Những thứ như:

• Định nghĩa của "Xong"
• Những giá trị điểm câu chuyện nào có thể được sử dụng để chỉ câu chuyện (ví dụ: bỏ 8 từ chuỗi sợi vì 1, 2, 3, 5, 13, v.v. là những giá trị duy nhất được sử dụng trong lần chạy nước rút mà họ quan sát được)
• Nói với các đội, họ phải hiệu chỉnh giá trị điểm câu chuyện của mình bằng 1 để "cập nhật nhãn UI" và giới hạn họ ở giới hạn trên 20
  • (mặc dù không phải tất cả các dự án của chúng tôi đều có khách hàng và không phải tất cả các nhà phát triển đều có trải nghiệm UI)
• Nói với các đội sử dụng ước tính điểm câu chuyện là 100 để có nghĩa là "chúng ta sẽ chia câu chuyện này sau"
• Nói các đội sử dụng ước tính điểm vô cực để nói "đây là một thiên anh hùng ca" hoặc "chúng tôi cần thêm thông tin"

Tôi hiểu rằng họ đang cố gắng để trở nên hữu ích, nhưng không phải tất cả những điều ở trên phải là nhóm Scrum cụ thể sao? Điều đó có nghĩa là, những gì hoạt động cho một nhóm các cá nhân trong một dự án có thể không có ý nghĩa với một nhóm khác trong dự án khác.

Tôi lo ngại chúng ta đang trôi dạt vào một cách tiếp cận Agile rất cứng nhắc và cứng nhắc. Tôi có hợp lý khi nghĩ điều này không, hay tôi phản ứng thái quá?

Biên tập

Chỉ cần làm rõ ... bởi "Quản lý" và "Người quản lý" Tôi không có nghĩa là Chủ sở hữu sản phẩm. Ý tôi là bất kỳ người quản lý nào ngoài Nhóm Scrum, nhưng trong Phòng Phần mềm.

Tất nhiên là bạn có lý khi nghĩ như vậy. Thực tế là bạn đang nói về "thực thi Scrum" là một tiếng còi báo động đáng sợ.
Scrum là lần đầu tiên và quan trọng nhất về việc tự tổ chức nhóm; họ có thể chọn cách thực hiện công việc và cách tự tổ chức. Quản lý chỉ có tiếng nói trong những gì công việc cần phải được thực hiện.
Lý do tại sao các nhóm nên tự tổ chức là vì chúng luôn là duy nhất, do tính chất khác nhau của từng thành viên trong nhóm (và những người họ làm việc cùng) và do sự khác biệt của các sản phẩm họ làm việc. Một thực hành hoạt động hoàn toàn tốt cho một nhóm, có thể có tác dụng phụ đối với một nhóm khác. Đó là lý do tại sao trong một phạm vi nhất định (siêu hình hộp cát thường được sử dụng), họ phải thử nghiệm, tìm hiểu và tìm ra cái gì phù hợp nhất với họ.
Những gì bạn cần là một bậc thầy Scrum rất có năng lực (mỗi nhóm một người), người có thể hướng dẫn một nhóm trong khám phá này, nhưng đồng thời cũng có thể làm việc với ban quản lý để có được sự tự do cho nhóm tiếp tục khám phá đó.

Chào mừng bạn đến với một trong những cơn ác mộng tồi tệ nhất của Scrum. Bạn đã gặp phải một trong những lý do khiến scrum không thể cung cấp những thứ tuyệt vời mà mọi người có trong tâm trí khi áp dụng nó.

Thật không may, scrum không tương thích với quản lý cấp trên có xu hướng tập trung hóa và tạo ra các quy trình quản lý trên toàn tổ chức và các nhóm. Để thành công, quản lý cấp trên phải thay đổi suy nghĩ và tập trung vào những gì họ cần từ các đội. Họ không nên tập trung vào cách các đội làm việc. Lần duy nhất họ nên tham gia, là nếu một đội không biểu diễn để tìm ra lý do.

Tôi tin rằng bạn phải ngồi xuống với ban quản lý và nói về yêu cầu của họ và những gì họ muốn các đội cung cấp. Đó có thể là một yêu cầu toàn cầu cho tất cả các đội. Đó có thể là ước tính mà họ hiểu, thời lượng, v.v. Những điều đó không nên ra lệnh cho các quy trình của đội. Điều quan trọng là bạn tách biệt các kỳ vọng quản lý khỏi cách bạn chạy scrum. Mỗi nhóm phải tìm ra tốc độ của riêng mình và cách điều khiển các dự án của riêng họ, điều đó sẽ giúp họ thành công, làm việc hiệu quả và cung cấp những gì quản lý cần. Ví dụ, nếu bạn có ước tính 15 điểm câu chuyện, nhóm sẽ có thể tính các điểm đó thành ngày con người (hoặc giờ) dựa trên vận tốc nhóm trung bình. Nhưng nó sẽ là duy nhất cho đội.

Là một công ty, cân bằng các nguồn lực của bạn nên là một lợi thế cạnh tranh. Mặt khác, chỉ cần tạo ra một loạt các công ty phần mềm riêng lẻ mất loại đòn bẩy này. Một tổ chức có nhiều nhóm và dự án phải được quan tâm với việc chuyển đổi và cân bằng nhóm. Tôi không nghĩ rằng đó là một ý tưởng tốt cho mọi kết hợp nhóm duy nhất để viết lại cuốn sách về cách họ sẽ làm scrum.

Bất cứ khi nào bạn đang cố gắng tổng hợp mọi thứ để đo lường một cái gì đó, tính nhất quán là quan trọng, tức là không so sánh táo và cam. Quản lý nên tập trung vào các nhu cầu cấp cao hơn này, nhưng hãy đảm bảo rằng họ không tham gia quá nhiều vào các chi tiết về cách các nhóm hoạt động. Cố gắng áp dụng các đề xuất của họ, nhưng hãy chuẩn bị để bảo vệ lý do tại sao một đội có thể là ngoại lệ. Bất cứ ai chỉ không thích cá nhân một cách làm việc cụ thể đều cần mặc quần người lớn và đối phó với nó.

Phải có sự linh hoạt, để bạn có thể hoàn thành công việc. Cần có sự nhất quán khi cần thiết. Nếu thành viên nhóm được thay đổi, mọi người sẽ không cảm thấy như đó là ngày đầu tiên đi làm.

Có thể các đội của bạn không bao giờ thay đổi, nhưng bạn nên cho sự lựa chọn đó một cơ hội bằng cách có sự nhất quán.

Không có bạn không phản ứng thái quá và bạn có lý do chính đáng để được quan tâm. Quản lý nên được tập trung vào thay đổi văn hóa. Ban quản lý cần thiết lập hướng đi đúng đắn và trình bày bối cảnh cho các đội để thực hiện điều đó bằng cách sử dụng các nghi thức nhanh nhẹn hoạt động tốt để nhóm làm việc hiệu quả.

Tôi cảm thấy may mắn khi tôi làm việc trong một tổ chức đã trải qua quá trình chuyển đổi nhanh từ thác nước trong hơn một năm và bắt đầu trong danh mục đầu tư mà tôi làm việc. Ban đầu họ bắt đầu với một dự án nơi một nhóm nhanh nhẹn được thành lập. Sự thành công của việc phân phối thông qua các nghi thức nhanh như retros, ước tính tương đối, dự báo lịch sử sử dụng vận tốc đã dẫn đến toàn bộ danh mục đầu tư hình thành các đội bổ sung với tồn đọng của riêng họ.

Từ kinh nghiệm, Agile không được kê đơn và bạn không thể đưa ra phương pháp cắt cookie. Chỉ vì nó hoạt động trong một nhóm không có nghĩa là nó sẽ hoạt động trong một nhóm khác. Tôi biết điều này từ kinh nghiệm vì ban đầu chúng tôi nghĩ rằng chúng tôi có thể bắt đầu các đội mới bằng cách áp dụng những điều tương tự như DoD, ý nghĩa của 1 điểm, 8 điểm có nghĩa là gì. Nhưng nó không hoạt động như ngữ cảnh mà chúng có rất ít ý nghĩa khi áp dụng cho một nhóm khác. Ngẫu nhiên, đối với một câu chuyện nhóm trên 8 điểm có nghĩa là nó quá lớn và cần phải chia tách.

Điều làm việc là thiết lập các hướng dẫn cho các đội, như họ phải thực hiện các hoạt động độc lập, hồi tưởng, giới thiệu cùng một lúc và tại mỗi hành động retro nơi trêu chọc và thực hiện để cải thiện các đội mới. Những thứ khác như định nghĩa hoàn thành và định cỡ các điểm câu chuyện đã được giới thiệu sau một vài lần chạy nước rút khi nhóm làm quen với khái niệm tường thuật câu chuyện và hoàn thành các lá bài và không được đưa vào nước rút tiếp theo.

Tôi biết đây là một việc khó bán cho ban quản lý vì họ muốn biết khi nào các dự án sẽ được giao và khi thành lập các nhóm nhanh nhẹn mới rất khó để đưa ra bức tranh đó. Nhưng bây giờ danh mục đầu tư có tiếng là có khả năng giao hàng nhanh nhẹn. Chúng tôi vẫn sẽ vấp ngã nếu phương pháp cắt cookie tiếp tục được đẩy sang các đội khác.

Sự không nhất quán trong thực tế giữa các nhóm Scrum thực sự có thể là một vấn đề, ví dụ nếu các thành viên trong nhóm di chuyển giữa các nhóm.

Sẽ tốt hơn nếu bạn cố gắng giải quyết các vấn đề chia sẻ kiến ​​thức giữa các nhóm theo cách nhanh nhẹn hơn - có lẽ là điều gì đó như chạy các phiên Lean Coffee hoặc Scrum-of-Scrum liên quan đến các bậc thầy scrum của bạn. Điều này hy vọng sẽ khiến quản lý của bạn nhận ra rằng bạn đang sở hữu khu vực này và ngừng cố gắng quản lý các vấn đề theo cách từ trên xuống.