Năng lực mà một nhóm tự tổ chức xoay quanh các mục tiêu đã được đặt ra là yếu tố then chốt đối với toàn bộ các phương pháp luận Agile, trong đó bao gồm cả Scrum. Trên thực tế, Bản tuyên ngôn Agile cũng nói tới các nhóm Tự tổ chức khi đề cập rằng “những thiết kế, yêu cầu, kiến trúc tốt nhất đều đến từ các nhóm tự tổ chức”.

Nhằm đạt được mục tiêu đã đặt ra, nhóm cần phải ra quyết định chọn cách tốt nhất để đạt được mục tiêu đó. Một số nhóm có thể sẽ thống nhất rằng tất cả những quyết định liên quan tới kĩ thuật sẽ được thực hiện bởi duy nhất một người trong nhóm.

Những nhóm khác sẽ quyết định chia nhỏ nhiệm vụ đối với các quyết định đó dựa theo những giới hạn về kĩ thuật, ví dụ Chuyên gia về CSDL sẽ ra quyết định về cơ sở dữ liệu, Lập trình viên Python kinh nghiệm nhất sẽ ra quyết định về Python.

Nhưng vẫn có những nhóm để chính những người đang thực hiện tính năng đó ra quyết định, nhưng họ có trách nghiệm phải chia sẻ kết quả của quyết định với nhóm.

Không phải mọi nhóm Agile sẽ tự tổ chức theo cùng một cách

Chúng ta cần lưu ý hai điểm sau:

• Đầu tiên, không phải mọi nhóm Agile sẽ tổ chức nhóm theo cùng một cách và điều đó không thành vấn đề.
• Thứ hai, tận dụng lợi thế từ việc tổng hợp các trí thông minh khác nhau trong cùng một nhóm nhìn chung sẽ tạo ra  cách tốt hơn để tổ chức công việc, hơn là chỉ phụ thuộc vào trí thông minh của một mình người quản lý.

Lợi ích của việc cho phép một nhóm tự tổ chức không phải chỉ là nhóm sẽ tìm ra cách tối ưu những công việc của mình mà người quản lý đã bỏ lỡ. Hơn thế, họ được khuyến khích để làm chủ vấn đề.

Chúng ta có thực sự mong đợi nhóm Agile sẽ Tự tổ chức?

Một trong những chỉ trích về nhóm tự tổ chức mà chúng ta thường nghe là “Chúng tôi không chỉ đặt tám con người ngồi cùng nhau và bảo họ hãy tự tổ chức đi và ngồi chờ một kết quả thật tốt”. Chà, tôi cũng không chắc nếu chúng ta có thể đặt tám người ngẫu nhiên cùng nhau và mong đợi điều gì đó, nhưng một nhóm Agile không nên là một tổ hợp ngẫu nhiên. Trong thực tế, những người trong tổ chức mà chịu trách nhiệm thực hiện một dự án Scrum nên dành nhiều công sức để lựa chọn cá nhân phù hợp với nhóm.

Quản lý tác động các kiểm soát tinh tế hơn là Tự tổ chức

Trong tài liệu gốc khi mô tả về Scrum, Takeuchi và Nonaka đã xác định “subtle control” là một trong sáu nguyên lý quan trọng. Họ liệt kê những quyết định về nhân viên là một trách nghiệm quản lý quan trọng.

“Lựa chọn đúng người cho nhóm dự án trong khi kiểm soát những thay đổi như thêm hoặc loại bỏ thành viên khi cần thiết [là một trách nghiệm quản lý quan trọng]. “Chúng tôi sẽ thêm thành viên lớn tuổi hơn và bảo thủ hơn vào nhóm để nhóm có thể cân bằng sự chuyển dịch quá nhiều về hướng chủ nghĩa cấp tiến,” Một nhân viên Honda cho biết “Chúng tôi lựa chọn cẩn thận và thận trọng rất lâu để có thể chọn ra thành viên của dự án. Chúng tôi đã phân tích những tính cách khác nhau để thấy liệu họ có hợp nhau không.”

Lựa chọn đúng người cho Nhóm Agile

Nếu bạn là một nhà quản lý nhân sự, hoặc bạn có quyền ảnh hưởng tới cấu trúc nhóm trong tổ chức, dưới đây là một vài yếu tố mà bạn nên cân nhắc.

Tạo kỉ luật cần thiết cho Nhóm Agile

Đối với một nhóm liên chức năng tất cả các kĩ năng cần thiết từ khâu lên ý tưởng cho tới thực hiện các tính năng cần được trình bày với cả nhóm là điều vô cùng quan trọng. Điều này có thể khiến kích thước nhóm ban đầu có thể sẽ lớn hơn bạn tưởng.

Nhưng qua thời gian, các thành viên nhóm sẽ học được vài kĩ năng từ chính đồng nghiệp của mình. Đây là kết quả tự nhiên của một nhóm Scrum. Trong khi một số thành viên nhóm phát triển các kĩ năng rộng hơn, vài cá nhân có thể sẽ được chuyển sang các nhóm khác.

Pha trộn các trình độ khác nhau (về kĩ thuật)

Trong việc cân nhắc về kích thước nhóm, bạn nên cố gắng để cân bằng các cấp độ về kĩ năng trong cùng một nhóm. Nếu một nhóm có ba lập trình viên lâu năm và không có bất cứ lập trình viên ít-kinh nghiệm nào, chúng ta sẽ gặp phải tình huống khi những lập trình viên lâu năm cần phải viết mã các tính năng đơn giản thì họ không muốn thực hiện. Trong khi đó một lập trình viên cấp thấp sẽ thấy hứng thú hơn để làm việc với những tính năng như vậy, mà họ cũng có thể hưởng lợi thông qua học hỏi và làm việc cùng với các lập trình viên giỏi hơn.

Cân bằng các lĩnh vực/kiến thức trong nhóm

Ngoài việc cân bằng các kĩ năng về kỹ thuật, chúng ta cũng nên cố để cân bằng giữa những kiến thức sâu về lĩnh vực mà chúng ta đang làm việc hoặc những vấn đề mà chúng ta đang cố giải quyết.

Điều này không nhằm để nói rằng nếu chúng ta có cơ hội để lắp ráp một nhóm với toàn bộ các chuyên gia về lĩnh vực mà mà chúng ta không nên nhận. Hơn cả như thế, chúng ta nên cân nhắc những mục tiêu lâu dài về tổ chức của chúng ta. Một trong những mục tiêu đó có thể là xây dựng nên kiến thức về một lĩnh vực xuyên suốt tổ chức. Bạn sẽ có một thời gian khó khăn để đạt được mục tiêu đó nếu như đặt tất cả chuyên gia về cùng lĩnh vực trong một nhóm.

Tìm kiếm sự đa dạng

Sự đang dạng đồng nghĩa với sự khác biệt , trong đó giới tính, sắc tộc và văn hoá chỉ là ba ví dụ nhỏ. Những điều này đều quan trọng như nhau, từ cách cá nhân nghĩ về vấn đề, làm thế nào họ ra quyết định và họ cần bao nhiêu thông tin trước khi ra quyết đinh và v.v… Nghiên cứu chỉ ra rằng “Những nhóm đồng chất (giống nhau) sẽ đạt được đồng thuận về đa số nhanh hơn là những nhóm dị chất (khác biệt) nhưng họ đạt được điều đó nhờ việc loại bỏ khả năng của tất cả các lựa chọn khác”

Cân nhắc sự bền vững khi hình thành các nhóm Agile

Mất khá nhiều thời gian để các thành viên nhóm Agile có thể làm việc hoà hợp cùng nhau. Do đó, cân nhắc các thành viên đã làm việc rất tốt cùng nhau trong quá khứ. Khi hình thành một nhóm mới, hãy cân nhắc các thành viên nhóm đã mất bao nhiêu thời gian để có thể làm việc cùng nhau trước khi một vài hoặc tất cả mọi người bị phân tán sang nhiệm vụ khác.

Vài lo ngại thông thường với các nhóm tự tổ chức

Hãy cân nhắc một vài sự trăn trở khi phụ thuộc vào một nhóm tự tổ chức.

Trong nhóm có một cá nhân quyết định tất cả

Một điều đáng quan ngại nếu tồn tại một cá tính vượt trội , ví dụ như Tech lead sẽ quyết định tự tổ chức là như thế nào hoặc anh/ cô ấy sẽ đưa ra tất cả quyết định.

Hoặc một cá tính vượt trội sẽ buộc anh ấy/ cô ấy ra quyết định trước khi nhóm có cơ hội để thảo luận về một vấn đề.

Nếu bạn biết điều này ngay từ đầu, bạn cần kéo anh ấy/ cô ấy ra một bên và giải thích vấn đề đang gặp phải. Hãy cho cô ấy biết cô ấy nên làm điều gì “đúng” và cô ấy nên để ý tới các thành viên khác và để cho họ có cơ hội được thể hiện quan điểm của mình nữa.

Hãy hỏi cô ấy nếu cô ấy nghĩ nhóm sẽ đưa ra quyết định đúng đắn nếu cô ấy có ý định trình bày suy nghĩ của mình như là một lựa chọn hơn là một quyết định đầy thử thách.

Hãy kéo cô ấy trở thành một người cố vấn cho những người khác – công việc của cô ấy nên chỉ đảm bảo những quyết định đúng đắn được đưa ra nhưng cách thành viên nhóm phát triển thì sẽ tạo ra những quyết định đúng đắn cho các dự án tiếp theo (mà cô ấy có thể không ở đó cùng với họ)

Nhóm của tôi trông cậy hoàn toàn vào ScrumMaster

Sự lo lắng thứ hai hay là nhóm quá bị động, thay vì tự quản họ sẽ tìm kiếm ScrumMaster/huấn luyện viên và mong họ ra quyết định cho mình.

Nếu điều này xảy ra, hãy đảm bảo các thành viên nhóm biết rằng công việc của ScrumMaster là để hỗ trợ chứ không phải ra quyết định thay họ. Nếu bạn đang ở vị trí kép, là một ScrumMaster đồng thời cũng là một thành viên nhóm, bạn không cần kìm nén quan điểm của mình và giữ im lặng toàn bộ thời gian.

Tuy nhiên bạn nên tìm kiếm cách để gắn gết những người khác bằng cách không đưa ra quyết định trong mọi trường hợp. Ví dụ, hỏi ý kiến của những người khác trước khi đưa ra quan điểm của mình.

Nhóm vẫn còn quá non nớt để có thể tự quản

Điều thứ ba cần quan tâm đó là thành viên nhóm còn quá non nớt để có thể tự quản. Tôi chưa từng gặp một nhóm quá non nớt để tự quản. Nếu các thành viên nhóm có đủ kinh nghiệm để xây dựng nên một sản phẩm phần mềm, họ có lẽ có đủ kinh nghiệm để tìm ra cách làm thể nào để tự tổ chức.

Nếu không, hãy gia tăng thời gian huấn luyện.

Thông thường, việc này này sẽ vấp phải sự phản đối như “Tôi không tin tưởng nhóm có thể tự quản theo cách mà tôi muốn”. Quá tồi.  Ảnh hưởng kiểm soát tinh tế đối với những người bạn tập hợp lại để hình thành nhóm và mục tiêu mà bạn đề ra cho nhóm đó, chứ không phải là việc họ đã tự tổ chức như thể nào để thực hiện công việc hằng ngày của mình.

Tác giả: Mike Cohn| Nguồn: mountaingoatsoftware.com