Làm thế nào để tôi đối phó với một nhóm scrum phản tác dụng?

Backstory:
Tôi đã làm việc như một phần của đội này trong ba năm qua và trong thời gian này chúng tôi đã có ba Scrum Master khác nhau, những người có tất cả mọi thứ khác nhau.

Vì sự thay đổi này trong Scrum Masters và cách họ điều hành chương trình, nó đã khiến nhóm của tôi tê liệt với ý tưởng về Scrum vì các nguyên tắc không được thực thi một cách nhất quán và một trong những Scrum Master là một người không tin vào sự nhanh nhẹn phát triển và chỉ giữ các sự kiện và hiện vật như một người mới để tuân thủ các quyết định của công ty.

Bây giờ các thành viên trong nhóm của tôi rất bực mình và buồn chán khi chúng tôi làm các sự kiện Scrum và một người nói riêng rất hay nói về điều này.

Hiện tại:
Hai tháng trước, công ty đã bổ nhiệm tôi Scrum Master trong nhóm của tôi vì sự cống hiến của tôi để làm việc nhanh nhẹn và các nguyên tắc của nó.

Tôi đang chịu đựng rất nhiều dưới áp lực không khí của các thành viên trong nhóm không sẵn sàng làm Scrum.

Như đã đề cập, họ cảm thấy khó chịu về toàn bộ quá trình, điều này gây khó khăn cho tôi vì họ không tham gia vào các cuộc trò chuyện cần thiết để làm cho Kế hoạch, Hồi cứu và Scrum hàng ngày có hiệu quả.

Đối với họ, Lập kế hoạch chỉ là một sự lãng phí thời gian, bởi vì chúng ta chỉ cần tràn vào Sprint mới và không hoàn thành công việc nào, vậy tại sao phải bận tâm.

Trong quá trình Hồi tưởng, tôi chỉ có thể cảm thấy rằng họ muốn nói "Dừng làm Scrum". Một người làm, nhưng những người khác im lặng và tôi phải đối phó với điều này mỗi lần.

Daily Scrum một lần nữa chỉ là một sự lãng phí thời gian cho họ vì không ai trong số họ bận tâm để nói chuyện và lên kế hoạch trong ngày. Họ chỉ nói "Tôi đã làm việc với nhiệm vụ X ngày hôm qua và sẽ làm việc lại vào hôm nay". Và hầu hết thời gian họ chỉ đùa giỡn cho đến khi tôi trở nên nghiêm khắc hơn.

Tôi đã rất lớn khi nói về cách họ dành thời gian trong những sự kiện này. Nhưng tôi đang chết ở bên trong vì tôi có niềm đam mê với điều này và họ không quan tâm nữa.

Hôm nay, người luôn chống lại tôi nói với tôi rằng hãy ngừng nói "Họ nói rằng đây là những gì họ đã cam kết cho Sprint này" bởi vì, theo lời của anh ấy, "Chúng tôi không bao giờ hoàn thành một Sprint. Sprint tiếp theo để hoàn thành hạn ngạch. Chúng tôi thực hiện KanBan trong thực tế. Vì vậy, hãy ngừng nói điều đó. "

Tôi hiểu lý do tại sao anh ấy nói điều này, nhưng anh ấy dường như không nhận ra rằng đây là vì anh ấy và mọi người khác trong đội không quan tâm. Họ chỉ làm việc thay vì đối phó với những trở ngại. Họ phàn nàn về những trở ngại, nhưng không làm gì với họ. Và khi tôi cố gắng giúp họ chỉ cần nhún vai.

Họ đã từng đưa ra một cái chết tiệt, nhưng trong hai năm qua, sự sẵn lòng của họ đã giảm xuống đáy đá ít nhiều.

Làm thế nào tôi có thể khiến họ thấy rằng đùa giỡn và lãng phí thời gian trong những cuộc họp này khiến công ty tốn rất nhiều tiền?

Bạn có thể đã nghe rất nhiều số liệu thống kê về các dự án phần mềm thất bại và đi đến kết luận rằng sự thất bại không có bản chất kỹ thuật. Các vấn đề công nghệ có thể được giải quyết thông qua hàng trăm giải pháp kỹ thuật, nhưng giải quyết các vấn đề trong bầu không khí nơi làm việc của bạn bằng cách sử dụng Scrum sẽ không hiệu quả.

Đề nghị của tôi ở đây là hoàn toàn ngừng xem đây là một vấn đề kỹ thuật. Đó không phải là về Scrum, nó không phải là về sự nổi bật hàng ngày, chạy nước rút, quá khứ hay bất cứ điều gì khác như thế. Bạn cần liên lạc với nhóm của bạn và tìm ra cách làm việc hiệu quả, làm hài lòng họ cũng như bạn và cấp trên.

Nếu họ nghĩ rằng nhật ký là một ý tưởng tồi, bạn không nên bảo họ làm tờ nhật báo và cố gắng đưa lý lẽ của bạn vào chúng. Hãy suy nghĩ cho bản thân những gì mà tờ nhật báo cung cấp cho bạn. Kiểm tra với nhóm của bạn xem họ cũng coi trọng những lợi thế đó. Tìm hiểu lý do tại sao họ không chia sẻ sự hiểu biết của bạn - như trong việc hiểu quan điểm của họ, chứ không phải trong việc thuyết phục họ về bất cứ điều gì. Sau đó kiểm tra xem các tờ nhật báo có thực sự giúp ích cho nhóm của bạn hay không, nếu bạn có thể đạt được nhiều hơn với một số cơ chế khác. Điều buồn cười về các bậc thầy Scrum là họ là những người phục vụ cho nhóm của họ - bạn hoàn toàn có thể phục vụ họ tốt nhất bằng cách bãi bỏ Scrum hoàn toàn.

Tóm lại, ngừng tập trung vào Scrum và thay vào đó hãy quay lại với những điều cơ bản của sự nhanh nhẹn. Bạn có thể muốn bắt đầu ngay từ đầu với tuyên ngôn nhanh : Các cá nhân giá trị và tương tác qua các quy trình và công cụ.

Theo kinh nghiệm của tôi, các đội bị vỡ mộng cần phải bắt đầu bằng cách có những hồi tưởng hiệu quả. Đó là lý do tại sao theo quan điểm của tôi, phần hồi tưởng là phần bắt buộc duy nhất của một quy trình nhanh. Mọi thứ khác có thể thay đổi thông qua các hồi tưởng.

Trong quá trình hồi cứu hiệu quả, bạn không chỉ phàn nàn về các vấn đề của mình, bạn chọn ít nhất một trong những vấn đề đó và xác định các giải pháp có thể cho nó, sau đó thử giải pháp đó qua lần lặp tiếp theo. Ở phần hồi tưởng tiếp theo, bạn nói về cách giải pháp đó hoạt động hoặc không hoạt động, và thực hiện các điều chỉnh tiếp theo nếu cần hoặc chọn một vấn đề khác để giải quyết.

Khi các thành viên trong nhóm thấy họ có khả năng thực hiện thay đổi thực tế trong quy trình của mình, họ sẽ trở nên sẵn sàng tham gia hơn.

Quá trình hồi cứu là lý do tại sao nếu bạn truy cập tất cả các nhóm tại một công ty hoạt động tốt, tất cả họ sẽ làm điều đó hơi khác. Chúng tôi có một số đội làm Kanban, một số đội làm XP, một số đội chỉ làm nổi bật vào Thứ Hai Thứ Sáu Thứ Sáu.

Nếu nhóm của bạn không thích cách bạn đối phó với nôn nao, hãy suy nghĩ một số cách tiếp cận khác nhau. Tôi đã chiến thắng các nhà phát triển rất miễn cưỡng chỉ bằng cách luôn lắng nghe các quan điểm và thử các giải pháp.

Được rồi, hãy bắt đầu sơ bộ - phần lớn của vấn đề là ở bạn - Bạn nghe, nhưng bạn không nghe. Nhóm của bạn đang cho bạn biết rõ vấn đề là gì. Bạn cần giải quyết chúng thay vì đổ lỗi cho nhóm của bạn.

Lập kế hoạch

Đối với họ, Lập kế hoạch chỉ là một sự lãng phí thời gian, bởi vì chúng ta chỉ cần tràn vào Sprint mới và không hoàn thành công việc nào, vậy tại sao phải bận tâm.

Chính xác. Nếu bạn luôn không phân bổ lượng thời gian chính xác cho các nhiệm vụ và chúng luôn bị đánh giá thấp, thì nó có tác động rất tiêu cực:

• Các nhà phát triển cảm thấy như họ liên tục chịu áp lực.
• "Tôi không thể hoàn thành công việc kịp thời".
• Vì quy trình không hoạt động, họ coi đó là một sự lãng phí thời gian.

Giải pháp : Khắc phục các ước tính của bạn bằng cách sử dụng kết hợp:

• Điểm câu chuyện (như sự kết hợp giữa thời gian và rủi ro).
• Không cho phép các tác vụ vào giai đoạn nước rút> 55 SP
• Dự toán so sánh
• Lập kế hoạch dựa trên bằng chứng

Để làm cơ sở cho việc này, bạn hoàn toàn cần theo dõi thời gian thực sự cần để hoàn thành các nhiệm vụ trước đó, bao gồm kiểm tra, viết tài liệu, kiểm tra viết, đào tạo người dùng cuối, nỗ lực tích hợp, triển khai. Vân vân.

Khi bạn có tổng thời gian cho một nhiệm vụ nhất định, bạn có thể căn cứ thời gian dự kiến ​​vào các nhiệm vụ trước đó.

Hỏi mọi thành viên nếu nhiệm vụ được giao cho họ cảm thấy phức tạp hơn hoặc dễ dàng hơn so với việc lựa chọn các nhiệm vụ trước đó, điều chỉnh số lượng nhiệm vụ được phân bổ dựa trên đó.

Nếu bạn chưa sử dụng SP trước đây, lời khuyên của tôi là hãy bắt đầu với 1h thực sự trung thực với công việc của thượng đế = 5SP làm hướng dẫn. Hãy ghi nhớ rằng trong môi trường phát triển bình thường, bạn sẽ nhận được có lẽ 6 của những mỗi ngày, vì vậy 30SP / ngày tối đa . Không bao giờ cho phép một nhiệm vụ mất hơn 2 ngày để lên bảng. Lý tưởng nhất, theo kinh nghiệm của tôi, bạn nên có 2 nhiệm vụ mỗi ngày.

Nếu bạn không thực hiện Lập kế hoạch một cách chính xác, phần còn lại của các hoạt động Scrum của bạn sẽ trông như lãng phí thời gian (bao gồm cả Lập kế hoạch).

Hồi tưởng

Trong quá trình Hồi tưởng, tôi chỉ có thể cảm thấy rằng họ muốn nói "Dừng làm Scrum". Một người làm, nhưng những người khác im lặng và tôi phải đối phó với điều này mỗi lần.

Nhắc nhở tôi Daily beatings will continue until morale improves!và hai trong số các công việc trước đây. Nếu bạn không loại bỏ những trở ngại, thì họ đúng rằng đây là một sự lãng phí thời gian.

Một lần nữa, hãy lắng nghe những gì mọi người đang thực sự nói. Nếu các khiếu nại được nêu ra trong quá trình hồi cứu không được giải quyết, tại sao lại phải thực hiện chúng?

Vì thế:

• Xem xét các kỹ thuật Six Thinking Hats để cải thiện giao tiếp.
• Giảm thời gian dành cho Hồi cứu, tối đa 30 phút.
• Đảm bảo rằng các khiếu nại được nêu trong quá trình Hồi cứu được giải quyết trước khi tiếp theo.

SCRUM hàng ngày

Daily Scrum một lần nữa chỉ là một sự lãng phí thời gian cho họ vì không ai trong số họ bận tâm để nói chuyện và lên kế hoạch trong ngày. Họ chỉ nói "Tôi đã làm việc với nhiệm vụ X ngày hôm qua và sẽ làm việc lại vào hôm nay". Và hầu hết thời gian họ chỉ đùa giỡn cho đến khi tôi trở nên nghiêm khắc hơn.

Âm thanh như bạn có hai vấn đề ở đây: các cuộc họp SCRUM quá dài và kế hoạch và tạo nhiệm vụ của bạn rất tệ.

Cả hai có thể làm cho âm thanh như một cuộc họp scrum là một sự lãng phí thời gian.

Đối với chiều dài SCRUM:

• Hãy thử tối đa 15 phút.
• Hãy thử mọi người đứng lên.
• Công thức cố định:
  • Bạn đã làm gì ngày hôm qua.
  • Bạn có kế hoạch gì hôm nay
  • Những gì các thành viên trong nhóm của bạn (không phải bạn!) Nên biết về nhiệm vụ, nó sẽ ảnh hưởng đến họ như thế nào.
• Đừng bận tâm với những trở ngại nếu bạn sẽ không giải quyết chúng.

Đây là bằng chứng thứ hai cho thấy kế hoạch của bạn làm suy yếu tình huống của bạn - nếu bạn không có gì cụ thể để báo cáo, điều đó có nghĩa là nhiệm vụ quá lớn và tất cả những gì bạn có thể nói là: Tôi đang làm việc với nó.

• Phá vỡ các nhiệm vụ thành các điểm đạn.
• Đảm bảo nhiệm vụ đủ nhỏ để mất ít hơn một ngày. Lý tưởng nhất là IMO, nhiệm vụ nên kéo dài ~ 3h và tương đương với khoảng 13 SP, vì vậy bạn có thể thực hiện 2 mỗi ngày trong hầu hết các điều kiện.

Đối phó với đội

Hôm nay, người luôn chống lại tôi nói với tôi rằng hãy ngừng nói "Họ nói rằng đây là những gì họ đã cam kết cho Sprint này" bởi vì, theo lời của anh ấy, "Chúng tôi không bao giờ hoàn thành một Sprint. Sprint tiếp theo để hoàn thành hạn ngạch. Chúng tôi thực hiện KanBan trong thực tế. Vì vậy, hãy ngừng nói điều đó. "

Anh ấy đúng. Bạn sai rồi. Bạn đang thực hiện SCRUM bastardized và / hoặc biến thể trên Kanban. Không phải lỗi của họ chút nào.

Tôi hiểu lý do tại sao anh ấy nói điều này, nhưng anh ấy dường như không nhận ra rằng đây là vì anh ấy và mọi người khác trong đội không quan tâm.

Tôi không nghĩ bạn hiểu gì cả. Họ có thể quan tâm ít hơn trước đây, tuy nhiên đổ lỗi cho họ không những không cải thiện bất cứ điều gì, nó có thể làm cho tình hình tồi tệ hơn. Nếu đó là đáy đá, họ thực sự có thể bắt đầu đào.

Họ chỉ làm việc thay vì đối phó với những trở ngại.

Và ở đây tôi nghĩ làm việc là công việc của họ. Tôi tự hỏi ai là người phải đối phó với những trở ngại .... ồ đúng rồi. Một bậc thầy Scrum. Đó là công việc của bạn . Họ nói với bạn những gì sai. Bạn sửa nó đi. Không phải hướng ngược lại.

Đây có lẽ là lý do tại sao bạn có quá nhiều vấn đề trong Hồi cứu.

Làm thế nào tôi có thể làm cho họ thấy rằng đùa giỡn và vòng tròn giật trong những cuộc họp này khiến công ty tốn rất nhiều tiền?

Dừng các cuộc họp vô ích và thay vào đó họ sẽ đùa giỡn với watercooler. Cũng xem đoạn về đánh đập cải thiện tinh thần. Nếu họ đang sử dụng sự hài hước như một cơ chế phòng thủ, bạn có một số vấn đề nghiêm trọng thưa ông!

Tham gia vào một trò đùa - như trong công việc với nhóm của bạn, không chống lại nó. (Ai fuuuuuuck quan tâm đến tiền của công ty? Bây giờ bạn có phải là cổ đông không?)

Tóm tắt

Kế hoạch tồi tệ của bạn đang làm cho các phần khác của SCRUM thất bại và tất cả những người tham gia đều khốn khổ. Họ thấy rằng không có gì thay đổi, không có gì được giải quyết, và những lời phàn nàn của họ không được lắng nghe.

Cải thiện kế hoạch của bạn, và bạn sẽ cải thiện dòng chảy và tinh thần.

Làm công việc của bạn loại bỏ những trở ngại và nhóm của bạn sẽ tiến bộ nhanh hơn. Hỏi họ những gì họ cảm thấy bạn nên làm để giúp họ.

Quan trọng nhất: Lắng nghe người của bạn. Họ đã nói với bạn (và tôi) vấn đề là gì.

Chúc may mắn!

Một trong những nguyên tắc nhanh nhẹn chính là quay trở lại, và sửa bất cứ điều gì sai. Điều đó không chỉ bao gồm tái cấu trúc mã và sửa lỗi, mà còn sửa quá trình phát triển.

Vậy, tại sao bạn không thực hiện một cuộc họp với nhóm của mình và xem bạn có thể cải thiện quy trình phát triển như thế nào? Nếu điều đó có nghĩa là, không có cuộc họp scrum hoặc standup, thì hãy là nó.

Ngoài ra, bạn đang phá vỡ một trong những nguyên tắc trong tuyên ngôn nhanh : "Cá nhân và tương tác qua các quy trình và công cụ".

Mặt khác, nếu nhóm của bạn nghĩ rằng sự phát triển lặp đi lặp lại là xấu, thì có lẽ bạn đang làm sai. Sẽ không có vấn đề gì nếu bạn không hoàn thành mọi thứ bạn đã lên kế hoạch cho một lần lặp - bạn luôn có thể chuyển mọi thứ sang lần lặp tiếp theo. Đó cũng là lý do tại sao bạn đánh dấu mọi thứ là "phải chứa", "tốt để có", v.v ... Miễn là bạn cung cấp chức năng mới, bạn đang làm tốt.

Chỉ là một câu nói nhỏ: trong công ty trước đây và hiện tại của tôi, chúng tôi đã làm và vẫn làm các cuộc họp chờ. Từ kinh nghiệm của tôi, họ rất lãng phí thời gian, vì mỗi lần họ biến thành hơn 30 phút họp báo cáo tình trạng và với tôi cung cấp rất ít thông tin. Mọi người nói về vấn đề của họ, mà thật lòng tôi không quan tâm.
Trong công ty trước đây của tôi, họ rất thông minh, nhận ra vấn đề này bằng cách đứng lên và ngăn họ lại ngay sau khi mọi người bắt đầu phàn nàn.

Nếu bạn muốn xem một video thực sự hay về scrum, hãy xem " Robert C. Martin - Vùng đất mà Scrum Quên ".

Theo ưu tiên của tôi, tôi sẽ xem xét các nhiệm vụ tiếp tục được thực hiện. Không đáp ứng mục tiêu là cực kỳ mất tinh thần. Bạn có cam kết quá nhiều? Có fatlogs nên được phá vỡ? Có những nút thắt ngoài tầm kiểm soát của bạn? Bạn có một định nghĩa rõ ràng về "thực hiện"? Các yêu cầu có rõ ràng không? Là số giờ cho mỗi nhà phát triển hợp lý (nghĩa là đưa vào tài khoản quản trị viên, đứng lên, lập kế hoạch, hồi cứu, phá vỡ bàn phím, công việc phi dự án).

Tiếp theo, bỏ bất cứ thứ gì không hoạt động. Quá trình không có giá trị chỉ là một kẻ trộm thời gian. Standups có thể tiêu tốn một lượng lớn thời gian nếu nó không tập trung và không cung cấp giá trị cho nhóm. Giờ có thể được chi tiêu tốt hơn ở nơi khác. Có lẽ cũng nên cân nhắc việc chia đội lên nếu nó quá lớn.

Cố gắng để có được một xử lý về những gì đang giải phóng đội. Có hồi tưởng và quan trọng hơn, hành động trên đầu ra. Điều quan trọng không kém là ăn mừng thành công cũng như nhìn vào thất bại.

Cuối cùng, bạn có thể muốn đánh giá cách tiếp cận của các bậc thầy scrum đã đi trước những người có thể đã làm hỏng thương hiệu để nói. Tôi đã từng làm việc với một bậc thầy độc hại trước khi mọi vấn đề được nêu ra được thêm vào khối lượng công việc của bạn cho dù bạn có biết về nó hay không. Kết quả cuối cùng: các vấn đề đã bị bỏ qua và mọi người làm việc trên khu vực nhỏ bé của họ với rất ít tinh thần đồng đội.

Làm cho nhóm của bạn đóng chạy nước rút của bạn một cách hiệu quả (như ít nhất là đóng 80% câu chuyện) chạy nước rút qua nước rút theo ý kiến ​​của tôi là điều quan trọng nhất bạn có thể làm. Nếu nhóm của bạn liên tục bị mất, thì đó là một dấu hiệu rõ ràng rằng bạn cần điều chỉnh các ước tính của mình.

Nhóm nên chấp nhận điều này, mặc dù có thể rất khó để khiến các nhà phát triển thực tế hơn về ước tính - Tôi đã làm việc với một nhóm không đóng nước rút trong một năm (đóng cửa ít hơn 50% so với nước rút) , luôn được ước tính và trong mọi kế hoạch / hồi tưởng, tôi là một giọng nói cô độc nói với họ ước tính của bạn, bạn đang quá tự tin, ngừng đưa ra lý do cho những gì ngăn cản bạn đưa ra ước tính và thay vào đó điều chỉnh ước tính để phản ánh thực tế ( có lẽ về mặt ngoại giao nhiều hơn thế nhưng đó là tình cảm cơ bản) - Khi bạn ở vị trí đó, tôi hoàn toàn đồng ý với người quản lý nhóm của bạn, người nói rằng quá trình này là một sự lãng phí thời gian bởi vì thực tế bạn đang làm KonBon, bất kể bạn gọi nó là gì Tại một thời điểm nhất định, ý kiến ​​của anh ta trở nên xác thực bởi các trường hợp. Nó '

Tại một số điểm bạn phải thiết lập lại mọi thứ, bạn phải khiến nhóm quyết liệt bù đắp cho ước tính của họ chỉ để hệ thống chuyển động. Khi một nhóm bắt đầu kết thúc câu chuyện một cách nhất quán, họ nên nhận ra rằng quy trình Agile chủ yếu là lẽ thường và việc không thực hiện nó theo một cách nào đó có hại cho năng suất của bạn. Nhưng miễn là "các cam kết" và "các mục tiêu chạy nước rút" không được thực hiện nghiêm túc, điều này xảy ra khi chúng không đạt được một cách nhất quán, thì toàn bộ điều này là một sự giả tạo và trở thành một sự suy giảm năng suất của các đội.

Bắt mọi người mua vào một cuộc chạy nước rút khác biệt đáng kể (về ước tính, lập kế hoạch, cam kết ect) là khó khăn, cuối cùng nhóm đó tôi đã hoàn thành điều đó do hai yếu tố. Một người chỉ đang thu thập dữ liệu từ JIRA và nói rằng "không có lý do nào cho việc này, các con số đang tắt, chúng luôn tắt theo một hướng, chúng tôi cần sửa nó, tôi không muốn xin lỗi theo kiểu retro, tôi muốn các con số cộng lại "- và cái khác là áp lực từ quản lý cao hơn mà cuối cùng tôi đã giải thích cho họ như ..." Điểm quan trọng của quá trình này là làm cho dòng thời gian phát triển của chúng ta có thể dự đoán được. Nếu chúng ta hoàn thành một khối lượng công việc không đổi chạy nước rút là tốt, độc lập với điều đó, hội đồng quản trị của chúng tôi cần phản ánh chính xác những gì chúng tôi làm được. Quản lý nhận thức rõ hơn về thành công của chúng tôi so với cam kết so với đầu ra thực tế của chúng tôi, vì lợi ích của riêng bạn, làm cho dòng chiếu lên với đầu ra để có vẻ như bạn đang hoàn thành công việc của mình thay vì chi tiêu một nửa mỗi lần chạy nước rút Không làm gì cả. Những người bị loại bỏ càng xa thời gian này, họ càng thấy bạn thất bại, những lời bào chữa mà bạn đưa ra theo kiểu retro thậm chí không phải là điều gì đó trong cuộc xem xét của họ, họ chỉ thấy bạn thất bại. "

Cuối cùng, nhóm của chúng tôi có lực kéo và mọi thứ bắt đầu suôn sẻ hơn và thấp hơn, chúng tôi thậm chí đã bắt đầu có sản lượng cao hơn một khi quá trình thực sự bắt đầu làm việc. Vì vậy, tl; dr - làm bất cứ điều gì cần thiết để bắt đầu chạy nước rút với mức độ thành công tương đối cao. Nếu bạn không làm điều đó, người quản lý nhóm của bạn sẽ tiếp tục xác nhận khả năng chống lại Scrum của anh ta bằng kết quả và cuối cùng sẽ đúng rằng quá trình của bạn thực tế chỉ là một sự giả tạo và lãng phí thời gian của mọi người.

Là một Scrum Master, bạn huấn luyện và hướng dẫn nhóm làm việc hiệu quả hơn. Khung Scrum là một công cụ mạnh mẽ để đạt được điều đó, nhưng khung Scrum tuyệt đối không bao giờ tự nó trở thành mục tiêu - nếu không bạn đang thực hiện Cargo Cult .

Có vẻ như bạn đã thực hiện Cargo Cult được 3 năm và mọi người nhận ra rằng đó là một phương pháp quản lý dự án khủng khiếp. Tin tốt là bạn đã có người thông minh , họ đã hiểu đúng. Thật không may, một số người trong công ty của bạn gọi nó là Scrum, nhưng một lần nữa bạn lại có những người thông minh , họ thậm chí còn nói với bạn rằng nhóm làm gì không được gọi là Scrum.

Lập kế hoạch chỉ là một sự lãng phí thời gian, bởi vì chúng ta chỉ cần tràn vào Sprint mới và không hoàn thành công việc nào, vậy tại sao phải bận tâm.

Chính xác. Quan tâm làm gì? Bạn cần tìm một câu trả lời, hay đúng hơn là bạn cần thay đổi quy hoạch và chạy nước rút để có một điểm cần lập kế hoạch. Hoặc là hoặc ngừng lãng phí thời gian của mọi người với Kế hoạch Sprint vô nghĩa. Bạn có thể muốn yêu cầu công ty gửi cho bạn một khóa đào tạo Scrum Master, bởi vì việc chạy một Kế hoạch Sprint tuyệt vời không phải là chuyện nhỏ.

Trong quá trình Hồi tưởng [...] những người khác im lặng và tôi phải đối phó với điều này mỗi lần.

Nếu bạn đang xử lý cùng một vấn đề mỗi Hồi cứu, mọi người thậm chí không bận tâm (nữa?) Để lên tiếng trong quá trình Hồi cứu, đó chỉ là một sự lãng phí thời gian. Trừ khi bạn hoặc nhóm bằng cách nào đó có thể giải quyết các vấn đề được nêu trong Hồi cứu, cuộc họp chỉ là làm mất tinh thần của nhóm. Các vấn đề được nêu trong Hồi cứu phải được giải quyết và cần có sự tiến triển của Hồi cứu tiếp theo.

Daily Scrum một lần nữa chỉ là một sự lãng phí thời gian cho họ vì không ai trong số họ bận tâm để nói chuyện và lên kế hoạch trong ngày. Họ chỉ nói "Tôi đã làm việc với nhiệm vụ X ngày hôm qua và sẽ làm việc lại vào hôm nay".

Thật vậy, tại sao phải lãng phí thời gian của mọi người nếu họ chỉ làm việc trên cùng một nhiệm vụ nhiều ngày? Họ hoàn toàn chính xác, rằng Daily Standup thực sự là vô nghĩa. Standup tạo điều kiện hợp tác chặt chẽ trong nhiều nhiệm vụ, mỗi nhiệm vụ có thể hoàn thành trong nửa ngày hoặc ít hơn. Nếu các nhiệm vụ của bạn không thể bị phá vỡ theo cách đó (do Lập kế hoạch Sprint bị hỏng hoặc do các nhiệm vụ của bạn thực sự không phù hợp với Scrum), sẽ không có nhiều điểm để tổ chức cuộc họp chờ hàng ngày trong 5 phút (đó là không quá 5 phút, phải không?).

"Chúng tôi không bao giờ hoàn thành một Sprint. Chúng tôi chỉ chuyển sang các nhiệm vụ và nhận những nhiệm vụ mới trong Sprint tiếp theo để hoàn thành hạn ngạch. Chúng tôi thực hiện KanBan trong thực tế. Vì vậy, hãy ngừng nói điều đó."

Tôi hiểu lý do tại sao anh ấy nói điều này, nhưng anh ấy dường như không nhận ra rằng đây là vì anh ấy và mọi người khác trong đội không quan tâm.

Không, bạn hoàn toàn không hiểu tại sao anh ấy nói điều này . Bạn có nguyên nhân gốc rễ của trở ngại - mà bạn cần giải quyết - sai. Họ không quan tâm vì thực hành quản lý dự án của nhóm rất tệ. Quan tâm đến việc thực hiện vận chuyển hàng hóa và thực hiện nhiệm vụ vận chuyển hàng hóa mạnh mẽ hơn không ngăn được việc trở thành Cargo Cult, một trong những phương pháp quản lý dự án tồi tệ nhất trong sự tồn tại (để bảo vệ bạn: cũng được sử dụng rộng rãi nhất).

bạn có thể làm gì về điều này?

1. Lắng nghe những lo lắng của họ. Một lần nữa, bạn may mắn vì bạn có những người thông minh .

2. Giúp họ giải quyết các trở ngại.

Và đó là nó, thực sự. Bạn sẽ cần thử nghiệm cách thay đổi Lập kế hoạch Sprint, Scrum hàng ngày và Hồi cứu để làm cho chúng có giá trị đối với nhóm - ngay cả khi bạn muốn bỏ nhãn Scrum, bạn vẫn có 3 cuộc họp với tần suất tương tự và mục đích tương tự nhau. phương pháp quản lý dự án ngoài kia. Đối với cách bạn sẽ thử nghiệm (tần suất, nội dung, người tổ chức cuộc họp, thời gian, thời lượng, v.v.), thật dễ dàng đến đáng ngạc nhiên: Hỏi nhóm. Đừng ép buộc ý tưởng của bạn đối với họ, nếu có bất cứ điều gì bạn nên để họ ép buộc ý tưởng của họ đối với bạn (giả sử họ có thể đồng ý với một số).

Nếu bạn sợ bạn sẽ mất kiểm soát, hãy đặt một số ranh giới trước, ví dụ:

• Các nhãn của các cuộc họp vẫn giữ nguyên.
• Các cuộc họp vẫn diễn ra và tần suất của các cuộc họp không thể thay đổi nhiều hơn hệ số 2.
• Bạn hiện đang thử nghiệm, vì vậy mọi thay đổi chỉ kéo dài trong 2 lần chạy nước rút, sau đó bạn trở lại mẫu cũ (tốt nhất nên dành thời gian trong vài tuần để tránh sự mơ hồ khi họ muốn tăng gấp đôi thời gian chạy nước rút).

Tôi nghĩ rằng tất cả mọi người đang trích dẫn cùng một dòng từ Tuyên ngôn Agile . Tôi sẽ làm tương tự: "Cá nhân và tương tác qua các quy trình và công cụ."

Nếu bạn là chủ nhân của SCRUM muốn sử dụng SCRUM để thực hiện công việc, bạn phải tiếp cận họ như một cá nhân tương tác với nhau. Bắt đầu động não làm thế nào để làm cho quá trình tốt hơn. Có lẽ bạn có thể thuyết phục họ thích SCRUM. Có lẽ họ có thể thuyết phục bạn sử dụng một quy trình khác. Hãy cùng tìm hiểu!

Có vẻ như nhóm đã nhận ra rằng hệ thống hiện tại không thực hiện công việc. Bạn có thể khuyến khích họ tin rằng nó có thể thực hiện công việc? Bạn đề cập đến một vài ví dụ. Nếu bạn nạp đầy Sprint để nó luôn bị rò rỉ ... hãy dừng lại. Đó là đội SCRUM của bạn. Giúp họ ngừng cam kết quá mức. Đẩy lùi quản lý để có được một số phòng thở. Sử dụng SCRUM cho những gì nó tốt cho. Sử dụng nó để trình bày dữ liệu cho quản lý rằng họ đang đẩy đủ mạnh đến mức họ đang mất giá trị từ quy trình của họ. Nếu quản lý muốn SCRUM là một quy trình, hãy nhờ họ giúp xây dựng không gian và năng lượng bạn cần để khắc phục. Là chủ nhân của SCRUM, công việc của bạn là giải quyết các vấn đề để nhóm có thể làm việc hiệu quả.

Một cách tiếp cận hữu ích khác có thể là sinh ra một quy trình mới trong cái cũ. Tiếp tục chạy SCRUM theo cách vô dụng tương tự, nhưng bỏ qua một phần nhỏ của lịch trình và nói "trong phần này của lịch trình, chúng tôi sẽ tìm ra cách sử dụng các công cụ đúng cách." Đừng quá quan trọng ở đó. Sử dụng số liệu của bạn. Tập trung vào tất cả các cuộc họp của bạn ở đó. Chỉ là phần còn lại của dự án "SCRUM" của bạn như một lá chắn để giữ cho quản lý hài lòng trong khi bạn và nhóm của bạn "[khám phá] cách phát triển phần mềm tốt hơn bằng cách thực hiện và giúp người khác làm việc đó". Theo thời gian, bạn sẽ muốn đặt ngày càng nhiều nhiệm vụ có giá trị của mình vào nhóm này và thùng cũ sẽ từ từ chết. Chẳng mấy chốc, bạn có một môi trường phát triển phần mềm sôi động và không ai là người khôn ngoan hơn.

Hoặc trộn và kết hợp chúng. Tôi đã làm việc trên một chương trình chống scrum. Các khách hàng muốn có thể thêm các nhiệm vụ mới tại bất kỳ thời điểm nào trong quá trình và yêu cầu chúng tôi hành động ngay lập tức. (Đây thực sự là một yêu cầu lành mạnh: công việc của họ rất biến động và họ thường cần hỗ trợ nhanh chóng ... đó là những gì chúng tôi đã được trả tiền). Tất nhiên, chúng tôi đã phải tìm ra cách giải quyết vấn đề "tại sao X không được thực hiện khi bạn hứa trong giai đoạn nước rút". Giải pháp của chúng tôi thực sự là xây dựng một quy trình gồm hai bước. Nhiệm vụ dài hạn đã được đưa vào SCRUM để ưu tiên thích hợp. Các nhiệm vụ ngắn hạn được đưa vào một quy trình homebrewed tập trung vào sự tương tác chặt chẽ giữa khách hàng và nhà phát triển. Điều này được hiểu rằng các khách hàng được hoan nghênh thúc đẩy chúng tôi sử dụng quy trình ngắn hạn này, nhưng họ hiểu rằng làm như vậy đã thúc đẩy trên Sprint ' dòng thời gian và họ đã bị cấm thêm yêu cầu mà không đồng thời nghe và giải quyết các vấn đề lập lịch trình mà họ gây ra. Kết quả? Nó đã làm việc. Hầu hết các nhiệm vụ được đưa vào quy trình SCRUM, giống như chúng nên và các trường hợp khẩn cấp tương tác liền mạch với chúng. Thái độ là "Nếu bạn muốn trở thành khách hàng, hãy xếp hàng cho câu chuyện SCRUM. Nếu bạn muốn trở thành đối tác, hãy thoải mái xuống và làm việc với chúng tôi ở cấp độ hàng ngày và làm cho sản phẩm này hoạt động ! "

Tôi nói điều này bởi vì tôi thực sự biết. Bạn có một vấn đề trong quản lý cấp trên với việc giám sát quá mức, không thể đặt ưu tiên và sẵn sàng thêm nhiều mục hơn nhưng không đẩy ngày phát hành trở lại.

Tôi đã từng nói rằng không có phương pháp nào có thể hoạt động như thế này, nhưng bây giờ tôi đã thấy Kanban tôi nói nó có thể, nhưng chỉ vì Kanban không phải quan tâm. Nó tiếp tục hoạt động khi quá tải. Nó sẽ không mang lại kết quả nhanh hơn nhưng sao lưu trong hàng đợi không được phép đặt ở bất kỳ cá nhân nào và vì vậy vấn đề quản lý thuộc về quản lý. Các báo cáo phản hồi cho thấy quá tải, đó là chính xác.

Vì sự thay đổi này trong Scrum Masters và cách họ điều hành chương trình

Oh tốt, đây có thể là vấn đề của bạn. Một bậc thầy Scrum không có mặt để điều hành một chương trình, anh ta không phải là người lãnh đạo dự án. Ông ở đó để đảm bảo tất cả các bên liên quan đang liên lạc và hoạt động là minh bạch.

Tôi tự hỏi đội đến từ đâu. Có thể là họ ít nhiều tự chủ trước khi Scrum (bao gồm cả chủ Scrum không thể tránh khỏi) bị bỏ rơi? Tại sao Scrum được giới thiệu ở nơi đầu tiên? Nó được cho là gì để giải quyết?

Scrum được cho là cung cấp hướng dẫn và nhóm của bạn đang nói rõ rằng họ không trải nghiệm nó hữu ích theo bất kỳ cách nào. Họ không quan tâm đến hướng dẫn, họ coi đó là một sự lãng phí thời gian không phù hợp. Rõ ràng ít nhất một người ra quyết định nghĩ rằng dù sao họ cũng cần được hướng dẫn. Ai? Tại sao? Họ có một điểm?

Đây là một vấn đề không giới hạn ở phần mềm.

Trong bất kỳ môi trường làm việc nào, sẽ có những người khác nhau với tính cách và khả năng khác nhau. Ngay cả khi Scrum là một phương pháp hoàn hảo, vẫn sẽ có người chống lại nó do tính cách và khả năng của họ.

Các nhà phát triển xử lý các nhiệm vụ khó khăn một cách hợp lý. Để có thể làm điều này, mỗi nhà phát triển sẽ có cách của mình để xử lý những thứ như vậy có thể hiển thị là ác cảm với những thứ như Scrum. Nếu tất cả các nhà phát triển được đào tạo từ đầu theo cùng một cách chính xác thì việc sử dụng một mẫu sẽ dễ dàng hơn rất nhiều, nhưng nếu không thì phải thích nghi ở phía nhà phát triển hoặc phía quản lý.

Ngoài ra, các nhà tư tưởng độc lập (nhà phát triển và các chuyên gia khác) thường không thích được chỉ dẫn cách thực hiện vì đó là công việc của họ và rất dễ xảy ra xung đột trong quan điểm. Scrum có vẻ giống như một số nghi thức vô nghĩa đối với một nhà tư tưởng logic, người thường sẽ phân tích và hành động phù hợp với từng vấn đề trong tay.

Dưới đây dường như gợi ý vấn đề ở đâu nhưng không phải là vấn đề gì. Chắc chắn có nhiều hơn thế. Tôi chỉ có thể giả định (không có kinh nghiệm) rằng các nhà phát triển đã thử nhưng đã bị ngăn chặn. Tôi đã thấy nó nhiều lần khi các nhà phát triển muốn sửa một cái gì đó nhưng một cái gì đó có hệ thống (quản lý, chính sách công ty, v.v.) khiến nó gần như không thể để họ từ bỏ. Họ thực sự không quan tâm hay họ không quan tâm đến việc làm điều gì đó mà họ tin rằng sẽ không giúp ích (có thể là do kinh nghiệm).

Tôi hiểu lý do tại sao anh ấy nói điều này, nhưng anh ấy dường như không nhận ra rằng đây là vì anh ấy và mọi người khác trong đội không quan tâm. Họ chỉ làm việc thay vì đối phó với những trở ngại. Họ phàn nàn về những trở ngại, nhưng không làm gì với họ. Và khi tôi cố gắng giúp họ chỉ cần nhún vai.

Họ đã từng đưa ra một cái chết tiệt, nhưng trong hai năm qua, sự sẵn lòng của họ đã giảm xuống đáy đá ít nhiều.

Làm thế nào tôi có thể làm cho họ thấy rằng đùa giỡn và vòng tròn giật trong những cuộc họp này khiến công ty tốn rất nhiều tiền?

Nếu một cái gì đó bị ép buộc vào người khác, thì mọi người buộc phải áp dụng phương pháp này để thuyết phục họ về lợi ích. Mặc dù, tôi không thực sự tin vào việc ép buộc mọi người làm việc, tôi đề nghị như trong mọi tình huống, lắng nghe mọi người và phát triển một phương pháp phù hợp với môi trường hiện tại.

Scrum không phải là không có điểm yếu của nó. Tôi có thể nói cho chính mình tất nhiên, nhưng tôi nghĩ các nhà phát triển ghét nó vì lý do tốt . Đó là ý kiến ​​trung thực của tôi rằng nó không phải là cố gắng .

Để hiểu lý do tại sao, hãy đọc những gì mọi bậc thầy scrum nên biết về scrum . Nó không phải do tôi viết, nhưng tất cả mọi thứ đều có đại diện cho trải nghiệm của tôi, mà tôi chỉ có thể tóm gọn là nỗi kinh hoàng .

Trong trường hợp của tôi, tôi đặc biệt phải chịu đựng dưới điểm 5. Về cơ bản, scrum đối xử với tôi như một đứa trẻ và một kẻ thua cuộc. Bây giờ, tôi là một nhà đồng phát triển tháo vát, giúp các đồng nghiệp của tôi, không có gì lạ khi tôi thích cái gì hơn!

Bây giờ tôi có một ông chủ mới (không phải là scrum), họ chỉ đi dạo và nói chuyện với mọi người, và tôi rất biết ơn vì điều đó! Một phần lý do tại sao điều này hoạt động là chúng tôi cũng có một phòng trò chuyện (chúng tôi sử dụng nhiều nhất) để liên lạc giữa các nhà phát triển. Nếu bất cứ ai đang có một chương trình nghị sự, chúng tôi sẽ đưa nó đến đó. Các cuộc họp chỉ dành cho các cuộc thảo luận dành cho nhà phát triển đặc biệt, không phải để áp đặt thời hạn nhân tạo hàng ngày lên chính mình.

Bạn đã nhận được rất nhiều câu trả lời xuất sắc. Dưới đây là một vài điểm có thể hữu ích:

Thay đổi phương pháp là khó

Đó là một thách thức lớn trong không gian làm việc, bởi vì bạn đang làm việc theo quán tính của "đây là cách chúng tôi làm việc" và chống lại áp lực của thời hạn và nhu cầu kinh doanh.

Bạn hoàn toàn đúng khi kết luận rằng nhóm của bạn cần dành nhiều thời gian hơn cho việc lập kế hoạch chứ không phải ít hơn ; kế hoạch đó là thứ mà thời gian của bạn hiện tại không được tốt và cần phải cải thiện. Vấn đề là, bạn không đến đó chỉ đơn giản bằng cách ra lệnh cho các quy tắc mới. Các quy tắc mới là một gánh nặng mới trước khi chúng trở thành một trợ giúp lớn. Và nếu họ không cung cấp giá trị lớn ngay lập tức , bạn sẽ tránh được hơn là hợp tác.

Tôi đánh giá cao Roy Osherove về chủ đề này. Anh ấy có một bản tóm tắt ngắn gọn về cách lập kế hoạch và thay đổi hiệu quả tại công ty của bạn và anh ấy đi sâu vào chủ đề ở độ sâu lớn hơn nhiều trong video này .

Quan sát cơ bản của Osherove là tất cả các thách thức sau đây cần phải được đáp ứng:

Động lực cá nhân: Tại sao một người nào đó quan tâm để cư xử một cách cụ thể?
Khả năng cá nhân: Họ có thể làm điều đó theo nghĩa đen?
Động lực xã hội: Có áp lực ngang hàng cho hành vi này?
Khả năng xã hội: Mọi người xung quanh có ủng hộ hành vi của tôi và giúp tôi giải quyết khi tôi cần giúp đỡ không?
Động lực cấu trúc: Có phần thưởng \ hình phạt cho hành vi tốt \ xấu?
Khả năng cấu trúc: Môi trường vật lý có hỗ trợ hành vi này không?

Bạn cần học cách phá vỡ nhiệm vụ

Nhóm của bạn cảm thấy rằng "Tôi đã làm việc với nhiệm vụ X ngày hôm qua và sẽ làm việc lại vào hôm nay" và họ có vẻ đúng, theo nghĩa là các nhiệm vụ tiếp tục bị đẩy lùi một tuần.

Điều thực sự hữu ích ở đây là học cách chia nhỏ các nhiệm vụ thành các thành phần nhỏ. Điều bạn đang tìm kiếm là câu trả lời cho câu hỏi "OK, bạn đang làm việc với nhiệm vụ X, nhưng cụ thể bạn đang làm gì trong nhiệm vụ X hôm nay ?"

Một số câu trả lời có thể là:

• Tôi đang học lớp mã kế thừa này.
• Tôi đang sửa một lỗi, có triệu chứng là (TRIỆU CHỨNG).
  • Nếu đây là một số lỗi đang diễn ra: "Hôm nay, thứ tôi sẽ thử là ... (KẾ HOẠCH)"
• Tôi cần thay đổi giao diện này.
• Tôi đang viết bài kiểm tra.
• Tôi đang tích hợp mã chưa được kiểm tra.

... Vân vân và vân vân. Có thể quan sát những gì bạn thực sự có thể hoàn thành trong một ngày hoặc trong một tuần là một trong những lợi ích tuyệt vời của Agile. Nhưng điều đó có nghĩa là bạn thực sự cần xem xét độ phân giải của từng ngày, chứ không phải một số Nhiệm vụ X nguyên khối sẽ sẵn sàng bất cứ khi nào nó sẵn sàng.

Xong so với Đã giao

Một vấn đề phổ biến (với Agile và lập kế hoạch nơi làm việc nói chung) là thời hạn có xu hướng đến từ quản lý, không phải từ các nhà phát triển. Thời hạn đó có thể được tách ra khỏi công việc thực tế sẽ được thực hiện - và đặc biệt, có khả năng muốn mọi thứ được giao càng nhanh càng tốt.

Vấn đề là, "giao ASAP" là một quá trình rất hỗn loạn. Nó khuyến khích cắt góc; mã hóa "nhanh và bẩn"; bỏ qua hướng dẫn; không dọn dẹp sau khi chính mình. Nó khuyến khích một tâm lý "hãy thử nó, xem nó có hoạt động không. Nếu có, hãy giao

Trong khi đó, nếu bạn đang làm việc có phương pháp, nếu bạn nghiêm túc về lập kế hoạch và thử nghiệm, thì bạn đã thiết lập một loạt các biển chỉ dẫn và lưới an toàn. Việc này có thể mất nhiều thời gian hơn - bạn dành nhiều thời gian cho những việc không tiếp tục giao hàng ngay lập tức và, bạn có thể không giỏi lắm trong quy trình làm việc này - nhưng nó sẽ ít biến động hơn.

Vì vậy, một điều cần tự hỏi mình là: Có phải các nhà phát triển đặt ra các mục tiêu chạy nước rút, theo nhu cầu và nhu cầu họ thực sự nhìn thấy? Hoặc là quản lý đặt ra thời hạn, để các nhà phát triển thử và đưa các cam kết của họ vào một lịch trình giống như nước rút?

Nếu các nhà phát triển không có đủ thời gian để lên kế hoạch cho mọi thứ hoặc làm việc theo một kế hoạch đáng tin cậy, thì không có gì lạ khi họ không thể đưa ra các ước tính hữu ích. :)

Đây có thể là một ý kiến ​​không phổ biến, nhưng bạn có thể không thể làm bất cứ điều gì về nó.

Tôi có thể tưởng tượng rằng qua nhiều năm tồn tại của đội và dòng người lãnh đạo, những người thực sự không hài lòng với đội, đã rời đi. Những gì bạn có vẫn là của những người có thể phàn nàn, nhưng không quan tâm đến việc thực sự nỗ lực cải thiện tình hình. Họ chỉ muốn dành 8 giờ để hack mã, không bị ai can thiệp và chỉ về nhà vào cuối ngày. Những gì bạn có ở đây dường như là vấn đề động lực nghiêm trọng. Và nó không phải là công việc của chủ scrum để giải quyết vấn đề đó. Đó là vấn đề của bất cứ ai trả tiền cho những người đó.

Nếu đây thực sự là trường hợp, thì chỉ có lựa chọn thực sự là loại bỏ đội hiện tại và bắt đầu lại từ đầu. Có thể để lại một hoặc hai người mà bạn nghĩ là tốt nhất trong đội và bắn hoặc chuyển phần còn lại sang các đội khác. Ít nhất bạn nên thảo luận về khả năng này với cấp trên của bạn.