Skeptic trong một nhóm Scrum

Công ty của tôi gần đây đã chuyển sang cách làm việc nhanh nhẹn và như một phần của nó, chúng tôi đã bắt đầu sử dụng SCRUM. Mặc dù tôi rất thoải mái với nó và cảm thấy rằng cách này vượt trội hơn so với cách truyền thống, một số đồng đội của tôi không có cùng quan điểm. Trên thực tế, họ rất hoài nghi về "tất cả những thứ nhanh nhẹn đó" và không nghiêm túc. Ví dụ, một trong những đồng đội luôn trễ hẹn trong các cuộc họp và không thực sự quan tâm đến nó. IMO quản lý cố gắng không chú ý đến điều này (có thể vì nó mới và cần có thời gian để mọi người quen với nó).

Câu hỏi của tôi là, làm thế nào để giải quyết vấn đề này trong khi không gây ra xung đột trong đội?

Khi phải đối mặt với sự hoài nghi cực độ, tôi thử một vài điều:

1.) Tôi chứng minh các kỹ thuật như TDD, liên tục triển khai, Pair Programming, Yêu cầu Gathering với người dùng của bạn, lặp ngắn vv Tôi không gọi những kỹ thuật Agile hay đàn hạc trên về Agile Manifesto (Tôi làm đàn hạc trên về phần mềm Nghề thủ công - nhưng đó là khác nhau; p). Tôi chỉ đơn giản chỉ cho các thành viên trong nhóm các công cụ và kỹ thuật hữu ích giúp cuộc sống của họ dễ dàng hơn. Họ có xu hướng nhảy vào băng nhóm Agile một khi họ thấy lợi ích hàng ngày.

2.) Tôi không trao đổi ngay lập tức sang một phương pháp SCRUM (hoặc khác) đầy đủ. Luôn luôn tốt nhất để giới thiệu các khía cạnh nhỏ của Agile tại một thời điểm.

3.) Tôi đồng ý với những người hoài nghi (đến một điểm). Agile không phải là viên đạn bạc và SCRUM, Kanban, Lean, v.v. cũng không phải là viên đạn bạc. Thay vào đó, tôi làm việc với họ để xem những khía cạnh nào có thể mang lại lợi ích cho họ ngay lập tức (Máy chủ CI thường không có trí tuệ) và sau đó tôi dùng thử phần còn lại "Hãy cho phép đứng lên trong một tuần và sau đó xem xét nó".

Giống như bất kỳ phương pháp nào, SCRUM và những người khác cần thực sự làm việc với nhóm và tổ chức, không xa lánh họ.

Vì vậy, để có được trực tiếp đến câu hỏi của bạn. Nâng cao nó với nhóm:

"Tôi cũng có một chút hoài nghi về các tình huống độc lập, nhưng tôi nghĩ với tư cách là một đội chúng ta nên cho nó đi đúng trong 1 tuần (không có lý do!) Và sau đó xem xét nó để xem nó có hiệu quả với chúng ta không. nghĩ sao? "

Một trường hợp điển hình của Scrum thực hiện sai .

Scrum đã được áp đặt cho nhóm. Nhóm (toàn bộ) đã không chọn nó.

Khi bạn muốn thực hiện nó, bạn phải có sự hỗ trợ đầy đủ của cả nhóm và quản lý, nếu không nó sẽ không hoạt động.

Chống lại sự thay đổi là kẻ thù của bạn ở đây.

Tôi đặc biệt khuyên bạn nên bắt đầu lại và trình bày Scrum cho nhóm và để họ đặt câu hỏi.

Nếu bạn không bán được ý tưởng, đừng cố ép họ sử dụng một phương pháp mà họ không muốn. Họ sẽ làm mọi cách để phá hoại nó. Đến muộn trong việc đứng lên hàng ngày là một trong những hành vi bạn sẽ nhận được.

Xin lưu ý rằng Scrum có thể không được khuyến khích cho công ty của bạn. Những người duy nhất có thể trả lời câu hỏi đó là những người làm việc tại căn cứ. Đội .

Có thể là khái niệm về các cuộc họp hàng ngày không áp dụng rất tốt cho những gì một người đang làm. Những cuộc họp đó không miễn phí.

Nếu những gì bạn đang làm đòi hỏi rất nhiều sự tập trung lâu dài, như toán học nặng, các cuộc họp có thể làm bạn khó chịu và bực bội. Tôi làm việc với một người như thế, người thích gặp nhau hàng tuần, điều đó hoàn toàn hợp lý.

Thành thật mà nói, nếu tôi ở trong nhóm lập trình của bạn, có lẽ tôi sẽ hoài nghi điều đó! Tôi đã thấy một hàng dài các phương pháp được cho là sẽ cách mạng hóa mọi thứ và khiến các dự án đến đúng giờ, trong phạm vi ngân sách và không có lỗi. Đây chỉ là mới nhất. Tại sao tôi nên tin dầu rắn? 10 năm trước, cùng một số người đã lơ lửng một cái gì đó khác, trong một vài năm một cái gì đó mới sẽ xuất hiện. Đừng hiểu lầm tôi nghĩ rằng một số phương pháp mới mang lại một số ý tưởng hữu ích. Thật không may, họ cũng mang rất nhiều giáo điều và những ý tưởng ngu ngốc.

Có thực sự quan trọng nếu anh ta không lên tàu? Chỉ cần giao cho anh ta một số nhiệm vụ lập trình và để anh ta làm theo cách anh ta muốn. Nếu công việc của anh ta là thỏa đáng hãy để anh ta được. Nếu công việc của anh ta không thỏa đáng, hãy thay thế anh ta. Tại sao nó rất quan trọng cho mọi người để theo dõi scrum?

Trong những năm qua, tôi đã thấy rất nhiều lập trình viên giỏi bỏ việc hoặc cảm thấy khó chịu vì người quản lý của họ liên tục đưa ra các phương pháp mới. Họ chỉ muốn viết mã và hoàn thành công việc. Tin tôi đi vài năm nữa, bạn sẽ chửi rủa scrum, và nhảy vào bất cứ thứ mốt mới nhất nào.

Nếu bạn đang làm nhanh thì bạn nên có một hồ sơ tồn đọng mà bạn đang làm việc. Sử dụng scrum để phát bài tập từ backlog.

Các bài tập lựa chọn (tốt nhất) được chọn đầu tiên khi bắt đầu cuộc họp. Khi bạn đến muộn, hãy đưa cho anh ấy những gì còn lại trong ngày.

Không thành vấn đề nếu anh ấy là món quà của Chúa để lập trình, anh ấy nhận được nhiệm vụ tào lao mà không ai muốn. Nếu anh ta cố gắng thực hiện một nhiệm vụ khác hoặc làm việc khác, toàn bộ nhóm cần phải dựa vào anh ta và buộc anh ta chỉ làm việc với nhiệm vụ "đã chọn" của mình. Bạn có thể nên có một bậc thầy xây dựng có thể từ chối những thay đổi của anh ta nếu anh ta không làm việc với công việc đã chọn.

Ngoài ra, đội nên được thiết lập mục tiêu và có khả năng bồi thường. Bạn có thể bỏ phiếu theo nhóm để không thưởng cho những người không tham gia. Điều này không thay đổi về số lượng quyền sở hữu mà quản lý của bạn đã trao cho nhóm nhanh nhẹn của bạn. Nhắc nhở quản lý những người đang làm tổn thương đội và ngăn đội thành công.

Nhắc nhở anh ta rằng nếu anh ta xuất hiện đúng giờ anh ta có thể tham gia vào quá trình.

Các đội Scrum được cho là tự tổ chức. Scrum cũng hoạt động bằng cách thực hiện tính minh bạch cực đoan trong mọi thứ.

Vì vậy, câu trả lời rõ ràng là Scrum Master gọi một cuộc họp, giải thích vấn đề (nhưng đừng tự đùa, mọi người trong nhóm đã biết chính xác vấn đề là gì) và sau đó nói với họ rằng họ đã có 1 giờ để tìm hiểu xem họ sẽ làm về nó. Rồi anh ngồi trong góc và ngậm miệng.

Rõ ràng, đây là một nhóm mới đối với Scrum. Vì vậy, chìa khóa là Scrum Master phải chấp nhận bất kỳ câu trả lời nào mà nhóm đưa ra. Nếu anh ta ghi đè lên chúng, hoặc áp đặt ý tưởng của riêng mình vào giải pháp, anh ta sẽ phá hủy niềm tin mà nhóm cần xây dựng với anh ta rằng họ được phép tự tổ chức. Có thể nhóm sẽ quyết định không làm gì cả.

Trong mọi trường hợp, vấn đề cần được xem xét tại Hồi cứu Sprint và hiệu quả của bất kỳ giải pháp nào họ đưa ra có thể được thảo luận.

Tránh "xung đột nhóm" thậm chí không phải là một yếu tố.

Bắn đồng đội, sau đó anh ta sẽ không gây ra tranh cãi trong đội.

Duyệt qua công việc cũ của bạn, tìm hiểu nhiều ví dụ về cách tiếp cận thác nước khiến bạn thất vọng nhiều lần trong quá khứ. Sau đó trình bày các trường hợp cho đồng đội của bạn. Với một cái nhìn thoáng qua thông thường, anh ta sẽ nhìn thấy ánh sáng.

Lập trình là một hoạt động chính xác vì vậy một cá nhân hiếm hoi sẽ không chấp nhận những sự thật khó khăn. Ít nhất, trên lý thuyết.

Ai đã đưa ra quyết định chuyển đổi và tại sao? Trường hợp những người hoài nghi về quyết định này hoặc quyết định chỉ rơi vào họ?

Bạn có quá cứng nhắc và / hoặc nhanh chóng trong việc thực hiện các phương pháp mới của mình không? Bạn đã đưa ra các sản phẩm tốt (không nhất thiết phải hoàn hảo) bằng phương pháp cũ của bạn? Bạn đã chứng minh cho những người hoài nghi rằng nó sẽ có lợi cho họ như thế nào chưa? Bạn có thể chứng minh điều đó? Những người đã "nhìn thấy ánh sáng" đã chứng minh những người hoài nghi về việc nó mang lại lợi ích gì cho họ, nhóm và công ty chưa?

Có lẽ bạn đang yêu cầu họ chấp nhận mọi thứ chỉ dựa trên lời của các tín đồ. Nhiều khả năng những người hoài nghi này đã đưa ra các phương pháp mới trước đây và không có lợi ích bao giờ nhận ra.

Có lẽ bạn có thể thực hiện một hoặc hai dự án chỉ với các tín đồ làm việc với nó bằng các thủ tục mới của bạn. Thực hiện các phép đo thực tế và chứng minh cho những người hoài nghi lợi ích thực sự. Thậm chí có thể thiết lập một cuộc cạnh tranh nhỏ giữa những người hoài nghi và cách cũ của họ và các tín đồ và cách mới của họ.

Tất nhiên sau đó bạn sẽ làm gì nếu những người hoài nghi chiến thắng?

Có một cuộc họp nhóm để thảo luận và tìm hiểu lý do tại sao công ty của bạn chuyển sang SCRUM và khiến mọi người xác định những gì họ nghĩ về SCRUM sẽ tăng thêm giá trị cho phương thức hoạt động hiện tại. Đôi khi các công ty thực hiện chuyển đổi xương (Tôi đã tham gia các cuộc họp scrum nơi không ai thực sự lắng nghe và mọi người chỉ nói về những gì họ đã làm ngày hôm qua và rời đi. Các đội này thường đạt đến trạng thái cân bằng như - "Tôi sẽ không hỏi bạn và bạn không gây rối với tôi "và đi lạch bạch ở đó. Đó chỉ là một sự lãng phí thời gian), vì vậy hãy mang những gì tốt nhất cho bạn.

Các cựu chiến binh thường có rất nhiều khả năng chống lại bất cứ điều gì có thể thay đổi phong cách làm việc hiện tại của họ, vì vậy bạn phải đảm bảo có đủ cà rốt để họ thoát khỏi quán tính. Trong trường hợp này, tôi sẽ có tỷ lệ 1: 1 với người đó hoặc biến anh ta thành chủ scrum :). Một khi bạn trao cho họ trách nhiệm, họ sẽ tìm thấy sự bình yên với nó hoặc loại bỏ hoàn toàn với nó bởi vì nó không làm tăng thêm giá trị. Cả hai đều giành chiến thắng.