Mở rộng Scrum một cách đơn giản với khái niệm của khung làm việc Nexus

Thông thường, Scrum hiệu quả đối với nhóm từ 3-9 thành viên, nhưng trong một số trường hợp, có một số team cần làm việc chung vì sự phức tạp và độ lớn của sản phẩm đó. Kinh nghiệm thực tiễn tốt nhất chỉ ra rằng Scrum không hiệu quả cao cho các nhóm lớn và 1 Product Owner, 1 Scrum Master cho nhóm quy mô lớn là không đủ để xử lý công việc của họ và sự cộng tác của nhóm cũng trở nên không hiệu quả do các nghi lễ và sự tương tác đòi hỏi nhiều thời gian hơn so với dự kiến. Để giải quyết vấn đề này, giải pháp đơn giản nhất là phân chia các nhóm thành hai hay nhiều nhóm scrum và bắt đầu thực hiện phương pháp scrum của scrum để cộng tác giữa các nhóm. Scrum của scrum là đơn giản nhất nhưng nó chỉ giúp chia sẻ kiến thức giữa hai nhóm và bao gồm chỉ các Scrum Master và Product Owner của các nhóm ngồi lại cùng nhau và tạo sự liên kết đồng nhất.

Nếu một nhóm trờ lên lớn hơn kích thước tối ưu (3-9 thành viên) của một nhóm Scrum, các vấn đề sẽ trở lên phức tạp hơn. Sự cộng tác của nhóm sẽ trở lên khó khăn khi mà việc liên kết giữa quá nhiều người sẽ trở lên khó khăn. Daily Scrum sẽ không thể hoàn thành trong 15 phút time-boxed và thờ gian sẽ bị lãng phí đối với toàn bộ thành viên của nhóm, vấn đề tương tự cũng được phản ánh ở trong các buổi họp Scrum khác. Ngoài ra, Scrum Master sẽ gặp khó khăn trong việc loại bỏ các trở ngại của nhó bời vì nếu kích thước của nhóm gia tăng thì số lượng trở ngại cũng gia tăng theo tỉ lệ thuận tương ứng. Để giải quyết vấn đề này thì cần phải chia nhóm thành hai hoặc nhiều các nhóm nhỏ hơn.

Thực tế, khung làm việc Nexus là giải phải cho nhóm lớn làm việc trên cùng một Product. Do đó, sẽ chỉ có một Product Backlog duy nhất được dùng chung bởi tất cả các nhóm cũng như sprint sẽ phải được bắt đầu và kết thúc cùng một thời điểm đối với tất cả các team.

Nexus cung cấp cho chúng ta ý tưởng về nhóm tích hợp chuyên trách để có thể loại bỏ các khoảng cách trong việc cộng tác giữa nhiều nhóm. Ý tưởng về nhóm chuyên trách này xuất hiện để giúp các nhóm phát triển có thể tập trung vào các đầu việc của srpint một cách nhanh chóng. Nhóm tích hợp tập trung sẽ đảm bảo về sự liên kết về yêu cầu kinh doanh cũng như tích hợp source code của nhiều nhóm khác nhau. Lợi ích chính của việc có nhóm tích hợp đó là đảm bảo sẽ có tăng trưởng tích hợp được kiểm thử và có khả năng bàn giao cho khách hàng sau mỗi sprint.

Cấu trúc nhóm ban đầu :

Cấu trúc nhóm sau khi triển khai nhóm tích hợp Nexus

Mô tả và Lợi ích:

Trong ví dụ bên trên, chúng ta vừa tạo ra hai nhóm từ một nhóm lớn ban đầu nhưng chỉ có một Product Owner và một Product Backlog được hai nhóm cùng chia sẻ. Chúng ta đưa Business Analyst (BA) ra khỏi nhóm phát triển bởi vì nếu là thành viên của nhóm phát triển, các BA sẽ không làm việc trên cùng một câu truyện người dùng mà họ sẽ làm với các dị bản câu truyện người dùng trong các sprint sắp tới. Vì vậy, chúng ta đặt họ như một phần của nhóm tích hợp để họ tham gia vào việc liên kế yêu cầu kinh doanh và các vấn đề liên quan giữa hai nhóm. Chúng ta sẽ đặt BA là một phần của nhóm phát triển trong vai trò là Sprint Backlog owner để họ chịu trách nhiệu trả lời các yêu cầu liên quan tới Sprint Backlog. Đây cũng là phương pháp hữu hiệu để dự phòng cho Product Owner trong trường hợp PO vắng mặt hoặc bị loại bỏ vĩnh viễn khỏi nhóm. Cho hai nhóm Scrum, chúng ta sẽ phải có hai Scrum Master để hướng dẫn nhóm của mình cũng như loại bỏ các trở ngại của nhóm để đạt được các mục tiêu của sprint. Chúng ta kéo hai thành viên của nhóm phát triển (một developer và một QA) vào làm thành viên của nhóm tích hợp. Nhiệm vụ chính của họ, như một thành viên của nhóm phát triển, là tích hợp source code và thực hiện kiểm thử tích hợp để đảm bảo code base sẵn sàng để phát hành. Đồng thời họ cũng đảm bảo việc đồng nhất sự phụ thuộc giữa các nhóm. Thành viên của nhóm tích hợp đồng thời cũng là đại diện của nhóm phát triển và vai trò này sẽ được quay vòng để đảm bảo rằng mọi thành viên đều có đóng góp trong việc tích hợp, cộng tác giữa các nhóm và sản phẩm.