Làm thế nào để giới thiệu Agile cho một nhóm sử dụng các phương pháp không Agile cứng nhắc?

Hãy xem xét một công ty tự hào được chứng nhận cho một số phương pháp không phải là Agile, sử dụng nó như một điểm bán hàng cho khách hàng của mình để thể hiện trách nhiệm.

Làm thế nào để bạn tiến hành giới thiệu Kanban hoặc Scrum dần dần mà không phá vỡ toàn bộ hệ thống của họ và vẫn khiến họ tự tin rằng nó vẫn có thể chịu trách nhiệm / có thể kiểm tra được ?

Tôi biết điều này có thể liên quan đến " Làm thế nào bạn sẽ giới thiệu một phương pháp nhanh như Scrum ", nhưng ở đây tôi tự hỏi về cách phá vỡ / làm việc xung quanh thực tế là công ty áp đặt một cách quản lý SDLC nhất định theo giả vờ rằng đó là cách duy nhất để có một dấu vết kiểm toán.

Tôi nghĩ thật hoang đường khi các nhóm dự án Agile không ghi lại các ứng dụng của họ và đây là điểm kháng cự đầu tiên bạn có được trong các công ty được chứng nhận có tài liệu tốt nhất theo tiêu chuẩn của họ.

Tôi làm việc trong một công ty được chứng nhận ISO-9001, nhưng chúng tôi C ScNG làm Scrum trên một số lượng lớn các dự án của chúng tôi. Trong trường hợp của chúng tôi, sự thay đổi đến từ những người đứng đầu Dự án phân phối (tức là những người khá cao cấp) và đó là lý do tại sao nó được thông qua - trái ngược với Quản lý dự án hoặc Nhà phát triển đang cố gắng thúc đẩy thay đổi này.

Một thực hành hữu ích chúng tôi theo dõi là Tài liệu Đủ nhưng Liên tục . Điều này rõ ràng có nghĩa là chúng tôi không tuân theo tất cả các mẫu được quy định cho dự án, nhưng có một sự hiểu biết và thỏa thuận có ý thức về những phần / tài liệu cần thiết so với những phần chỉ là chi phí vô nghĩa.

Sau đó, bạn cần xã hội hóa quan điểm này và được sự chấp thuận của nhóm Chất lượng hoặc bộ phận Tiêu chuẩn hoặc bất cứ điều gì nó được gọi.

Nguyên tắc Agile là tài liệu 'vừa đủ'. Bạn có thể thử và đẩy nó từ Khách hàng để bày tỏ với nhóm bao nhiêu là vừa đủ không? Người quản lý dự án có thể nói chuyện với khách hàng và hiểu những mong muốn và nhu cầu tổ chức của họ là gì và sau đó cả hai ghi lại quyết định và đáp ứng những mong đợi đó. Nếu nó đủ tốt cho họ (tức là khách hàng trả tiền), thì đó có thể là những gì bạn làm theo.

Nếu họ nghĩ Agile không mở rộng quy mô cho các dự án lớn, hãy thuyết phục họ có thể - bằng cách phân tách và nỗ lực song song.

Trong tổ chức lớn, việc kiểm soát và giám sát các chương trình lớn được thực hiện bằng cách điều hành Văn phòng giám sát dự án (PMO) thực hiện kế hoạch thông thường để quản lý chi phí / kế toán / quản lý tài nguyên, v.v. (biểu đồ ghi đĩa SCRUM cho một). Họ cần biết các kỹ thuật như tích hợp liên tục giúp họ sớm hơn thay vì muộn hơn và do đó, năng suất của mọi người sẽ tốt hơn để tránh các tài liệu trên không.

Agile là một tập hợp các kỹ năng mà một nhóm có thể học được, phần lớn là trực giao với các kỹ năng kỹ thuật truyền thống của chúng tôi. Nhưng nếu bạn thêm điều này vào các kỹ năng hiện có của họ, tất nhiên bạn có thể trở thành một nhóm hiệu quả hơn. Nổi bật hàng ngày (tức là các cuộc họp Scrum) sẽ không thể diễn ra trong một đêm - nhưng bạn sẽ có các cuộc họp nhóm thường xuyên (nói hai tuần một lần) hiện tại? Tôi muốn nói bắt đầu bằng cách chuyển đổi những người theo chương trình câu hỏi Scrum (không quá lén lút;) và truyền đạt cho nhóm rộng hơn lý do tại sao phương pháp này có thể hoạt động và không có nghĩa là tài liệu lỏng lẻo / tiêu chuẩn kém hoặc bất kỳ huyền thoại nào khác.

Trước tiên tôi muốn tách Scrum khỏi Kanban.

Với Kanban - và đây là một nguồn khá hay về cách thực hiện đúng - nguyên tắc là bạn tôn trọng quy trình thoát khi bạn bắt đầu. Kanban không phải là những gì bạn thay thế quy trình hiện tại, mà là những gì bạn áp dụng cho nó. Lập bản đồ, hình dung và thiết lập các điều kiện nhất định để cải thiện dần dần.

Scrum về cơ bản là khác nhau theo nghĩa là nó sẽ thay thế quá trình hiện có.

Một nhóm được sử dụng cho chu kỳ SDLC thác nước 12 tháng (hoặc lâu hơn) sẽ có một thời gian rất khó để chuyển sang Scrum. Việc rút ngắn dần chu kỳ xuống còn 6 hoặc 3 tháng với các chuyến tàu phát hành với phạm vi nhỏ hơn có thể là một bước trung gian hữu ích.

Giống như bất kỳ điều mới nào bạn sẽ cố gắng giới thiệu cho một tổ chức, bạn sẽ gặp phải sự phản đối mạnh mẽ. Bạn đã sẵn sàng để bị chỉ trích và có những trách nhiệm nếu nó thất bại? Bạn phải là một người mạnh mẽ. Đó là cái giá phải trả khi phơi bày bản thân.

• Hãy tự hỏi tại sao bạn muốn sử dụng Scrum . Bạn có cần phải giải quyết một vấn đề thực sự?
• Đảm bảo rằng BẠN cam kết với nó, bởi vì không ai sẽ làm điều đó cho bạn. Bạn sẽ là chủ sở hữu của điều. Ít nhất cho đến khi nó mang lại hiệu quả tích cực trong tổ chức
• Tự rèn luyện . Sách và internet là không đủ. Đi đến một khóa học trước, hoặc bạn sẽ tăng đáng kể cơ hội để thực hiện Scrum không chính xác. Điều này có thể sẽ dẫn nhóm của bạn đến kết quả tồi tệ hơn trước
• Bán nó cho đội trước . Bạn phải có sự hỗ trợ đầy đủ của họ, rõ ràng
• Đừng đề xuất thay đổi, đề xuất thử nghiệm . Và xem xét nó như thế. Scrum có thể không phù hợp với tổ chức của bạn (hoặc nhóm của bạn)
• Tìm một nhà tài trợ trong quản lý hàng đầu

Điều này gần như chính xác những gì đã xảy ra tại công ty chúng tôi. Chúng tôi theo phương pháp nghiêm ngặt, không nhanh nhẹn. Khi một Giám đốc kỹ thuật trưởng mới tham gia, người có một số kinh nghiệm với SCRUM , anh ấy nghĩ rằng sẽ rất tốt nếu dùng thử.

Cách chúng tôi đã làm là đưa một nhóm nhỏ các nhà phát triển (và các nhà phân tích) thành lập một nhóm SCRUM thí điểm. Chúng tôi đã theo phương pháp SCRUM nghiêm ngặt trong khoảng 4 tháng, sau đó công ty đã phản ánh về những gì chúng tôi đã làm, cách chúng tôi làm, phân tích dữ liệu (bạn biết, tất cả những thứ mà BA cần làm).

Những gì họ tìm thấy là phi công là một thành công lớn. Vì vậy, họ đã tạo ra một đội khác theo Kanban, và họ cũng đã thành công rực rỡ. Tôi nghĩ có người nói rằng phần còn lại của các nhà phát triển cũng thành lập các nhóm SCRUM / Kanban.

Tôi nghĩ phi công là then chốt. Nó đưa ra khía cạnh nghiêm ngặt của thời gian kinh doanh để đánh giá và thấy rằng nó hoạt động đầu tiên.

Tôi là huấn luyện viên Agile và một trong những chìa khóa để thay đổi sáng kiến ​​là mua ở tất cả các cấp! Điều này bao gồm giám đốc điều hành, nhóm phát triển, nhà quản lý, ... vv. Trước khi thông báo một nỗ lực thay đổi lớn hay nhỏ, tôi sẽ đề nghị đưa các cá nhân lên tàu với bạn trước. Làm điều này thông qua một cuộc trò chuyện của người thứ ba là cách dễ nhất để các cá nhân bắt đầu nghiên cứu những ý tưởng mới. Người thứ ba là gì? Một blog, video youtube, thuyết trình, ... Bằng cách này, những người đó có thể bắt đầu nảy ra ý tưởng của riêng họ và với tầm ảnh hưởng của bạn sẽ nhảy lên tàu với một sáng kiến ​​thay đổi.

Dưới đây là hai video xảo quyệt mà tôi đã sử dụng để thu hút sự quan tâm ở tất cả các cấp trong chuỗi thức ăn.

Kanban: http://www.youtube.com/watch?v=0EIMxyFw9T8

Scrum: http://www.youtube.com/watch?v=Q5k7a9YEoUI