Quy mô nhóm và điểm giới hạn của Scrum Master
Khi quy mô nhóm ngày càng lớn, những cuộc trao đổi rời rạc bắt đầu kết tụ thành các nhóm nhỏ không chính thức. Mỗi nhóm nhỏ thường đề xuất những ý tưởng hoàn toàn khác nhau. Không ý tưởng nào là sai, nhưng đội cần có định hướng và sự tập trung để tránh bị phân tán. Khi các cuộc trao đổi ngầm xuất hiện ngày càng nhiều hơn, các nhóm bắt đầu vận động cho những ý tưởng đã được thảo luận riêng trước đó rồi mới mang ra tranh luận với cả đội. Dù điều này không phải lúc nào cũng tiêu cực, nó lại làm gia tăng mâu thuẫn và kéo dài quá trình đạt được sự đồng thuận - vốn là yếu tố cốt lõi trong một nhóm Scrum hiệu quả.
Các nhóm có quy mô quá lớn thường khó vận hành hiệu quả, tuy nhiên, quan niệm “càng đông càng tốt” vẫn còn tồn tại. Liệu đây là biểu hiện của xu hướng mở rộng quyền lực cá nhân, hay chỉ là nỗ lực bù đắp quá mức nhằm giảm thiểu rủi ro thất bại bằng cách tăng số lượng thành viên?
Một Scrum Master đánh giá quy mô nhóm dựa trên động lực nhóm - cách mà các thành viên tương tác, phối hợp và hỗ trợ lẫn nhau để đạt mục tiêu chung. Trong khi đó, một nhà quản lý truyền thống - người có nền tảng vững chắc về quản lý dự án thường nhìn nhận vấn đề này theo phạm vi kiểm soát, tức là số lượng nhân sự mà họ có thể quản lý hiệu quả.
Cốt lõi của vấn đề nằm ở việc làm thế nào để tối ưu hóa sự phối hợp nguồn lực và duy trì giao tiếp hiệu quả trong nhóm.
Bài học đầu tiên
Bài học đầu tiên tôi rút ra là phạm vi kiểm soát của một Scrum Master có thể bị vượt ngưỡng rất nhanh. Trong nhóm Scrum đầu tiên mà tôi tham gia, chúng tôi có tổng cộng 13 thành viên: tám lập trình viên (developer), hai chuyên viên phân tích nghiệp vụ (BA), một chuyên viên kiểm định chất lượng (QA), một chủ sở hữu sản phẩm (PO), và tôi đảm nhận vai trò Scrum Master (SM). Do không có phòng họp cố định, tôi đã tự tạo một bảng Kanban thủ công bằng tấm bảng gấp ba và sticky notes. Mục đích đơn giản là giúp nhóm có một công cụ trực quan để theo dõi luồng công việc mỗi ngày.
Thế nhưng, trong các buổi daily stand-up, tôi nhận ra phần lớn thời gian của mình lại bị cuốn vào việc đọc và sắp xếp sticky notes. Vấn đề không nằm ở thao tác di chuyển sticky notes - điều đó hoàn toàn có thể giải quyết bằng phần mềm hoặc giao lại cho một thành viên phụ trách. Vấn đề thực sự là tôi - Scrum Master, không thể tập trung lắng nghe và tiếp nhận hết những điều các thành viên trong nhóm truyền đạt.
Bài học thứ hai
Bài học thứ hai tôi nhận ra là các nghi thức trong Scrum (Scrum ceremonies) thường kéo dài hơn nhiều khi nhóm đông thành viên hơn, và điều đó rất dễ khiến các thành viên mất kiên nhẫn. Nhóm càng đông, nhu cầu trao đổi và tương tác càng lớn, dẫn đến lời phàn nàn quen thuộc: “Tại sao chúng ta phải dành quá nhiều thời gian cho các cuộc họp như vậy?”
Một buổi daily stand-up với sáu người thường chỉ nên kéo dài tối đa 15 phút, với điều kiện nhóm đủ kỷ luật để tuân theo đúng khuôn mẫu: “Hôm qua tôi đã làm gì? Hôm nay tôi sẽ làm gì? Và trở ngại của tôi là gì?” Nếu nhóm bạn chưa thực hiện được điều này, hãy bắt đầu thực hành ngay từ hôm nay.
Khi số lượng thành viên tăng lên khoảng mười hai người, thời lượng buổi họp có thể kéo dài đến 30 phút. Và điều tương tự cũng xảy ra với tất cả các nghi thức và sự kiện Scrum khác.
Vì vậy, hãy tự hỏi: Nhóm của bạn có đang dành quá nhiều thời gian cho các nghi thức Scrum không?, Đây là một câu hỏi đáng để suy ngẫm.
Bài học thứ ba
Bài học thứ ba tôi rút ra, và có lẽ cũng là bài học quan trọng nhất, đó là: càng nhiều người thì càng có nhiều cuộc trò chuyện, và cũng càng dễ lệch khỏi trọng tâm. Khi quy mô nhóm mở rộng, một vài tiếng nói có xu hướng trở nên áp đảo, trong khi những người khác lại dần bị lu mờ, không phải vì cố ý, mà chỉ vì sự thuận tiện trong cách nhóm trao đổi và ra quyết định.
Hãy tự hỏi: “Mọi thành viên trong nhóm có thực sự theo kịp cuộc thảo luận này không? Chủ đề này có cần được tách riêng để bàn sâu hơn không?”. Theo kinh nghiệm của tôi, những người ít khi lên tiếng thường dễ bị “nhấn chìm” giữa các luồng trao đổi. Và điều đó, về lâu dài, có thể làm tổn hại đến sự đồng thuận và niềm tin trong nhóm - những yếu tố cốt lõi cho một Scrum Team bền vững.
Khi quy mô nhóm ngày càng lớn, những cuộc trao đổi rời rạc bắt đầu kết tụ thành các nhóm nhỏ không chính thức. Trong đội của tôi, dần dần hình thành hai nhóm riêng biệt cùng với một nhóm độc lập không liên kết với ai. Mỗi nhóm nhỏ đều có một “thủ lĩnh ngầm” - những người cạnh tranh với nhau để khẳng định vị thế. Việc này một phần là để giành quyền chỉ đạo kỹ thuật, một phần là để truyền bá ý tưởng và kiểm soát nhóm còn lại lẫn các thành viên của nhóm không liên kết.
Một Scrum Master không nên bị cuốn vào những vòng xoáy chính trị trong nội bộ nhóm, nhưng bạn bắt buộc phải nắm được mạch đập của nhóm - tức là phải theo sát tình hình, tinh tế cảm nhận sự chuyển động tâm lý và tương tác nhóm để kịp thời điều chỉnh trước khi vấn đề trở nên nghiêm trọng.
Mỗi nhóm nhỏ thường đề xuất những ý tưởng hoàn toàn khác nhau. Không ý tưởng nào là sai, nhưng đội cần có định hướng và sự tập trung để tránh bị phân tán. Rất dễ rơi vào tình trạng muốn đưa ra giải pháp đúng thay cho cả nhóm, nhưng nếu làm vậy, bạn sẽ không còn phát huy được vai trò Nhà lãnh đạo phục vụ và đánh mất bản chất của một Scrum Master thực thụ. Khi các cuộc trao đổi ngầm xuất hiện ngày càng nhiều hơn, các nhóm bắt đầu vận động cho những ý tưởng đã được thảo luận riêng trước đó rồi mới mang ra tranh luận với cả đội. Dù điều này không phải lúc nào cũng tiêu cực, nó lại làm gia tăng mâu thuẫn và kéo dài quá trình đạt được sự đồng thuận - vốn là yếu tố cốt lõi trong một nhóm Scrum hiệu quả.
Khi những thành viên trầm lặng trong nhóm bị lấn át bởi những tiếng nói áp đảo, họ sẽ bắt đầu thể hiện sự kháng cự thụ động. Dù tôi đã nỗ lực hết sức để khuyến khích họ chia sẻ ý kiến, bầu không khí im lặng vẫn bao trùm. Tôi tin rằng họ cảm thấy rủi ro khi lên tiếng lớn hơn lợi ích có thể đạt được. Trong một trường hợp, một lập trình viên đã gửi email đầy bức xúc cho giám đốc, phàn nàn rằng bản thân bị xem nhẹ và liên tục bị giao nhiệm vụ “tuần tra lỗi” (bug patrol). Từ đó, sự việc nhanh chóng trở thành một vấn đề nghiêm trọng - kiểu căng thẳng thường âm ỉ tích tụ khi các mối lo ngại không thể được bày tỏ một cách an toàn trong môi trường nhóm.
Hãy bắt đầu từ những thay đổi nhỏ
Sẽ thật tuyệt nếu tôi có thể nói rằng chúng tôi đã giải quyết được vấn đề bằng cách chia đội thành những nhóm nhỏ hơn. Tuy nhiên, do những ràng buộc về chính sách nội bộ và cơ cấu tổ chức, điều đó không thể thực hiện được. Một Scrum Master cần biết cách cân bằng giữa tính hiệu quả và tính khả thi - nghĩa là không nên đi quá xa khỏi nhóm hoặc rời khỏi phạm vi hỗ trợ của ban quản lý. Nhìn lại, tôi nghĩ lẽ ra mình nên tận dụng nguồn lực và quy trình nội bộ sẵn có để thúc đẩy việc tách nhóm. Có thể điều đó đã mang lại kết quả tích cực, miễn là tôi không bị thay thế trước khi kịp thấy được tác động. Dù vậy, bước đầu tiên luôn phải là giành được sự ủng hộ của ban quản lý và các bên liên quan, đồng thời truyền đạt rõ ràng lý do cũng như lợi ích của sự thay đổi này đối với cả nhóm.
Cuối cùng, tôi quyết định tập trung vào những gì chúng tôi thực sự có thể kiểm soát và cải thiện. Giải pháp của tôi là xây dựng agenda rõ ràng cho các buổi họp và tạm hoãn những chủ đề ngoài phạm vi, đặc biệt khi chỉ liên quan đến một vài người. Chúng tôi đã đạt được nhiều kết quả tích cực khi áp dụng các kỹ thuật ước lượng trong Scrum và giảm quy mô các câu chuyện người dùng. Cách làm này giúp các cuộc trao đổi trở nên tập trung hơn, tránh lan man và tiết kiệm đáng kể thời gian. Bên cạnh đó, những buổi ăn trưa chung của nhóm đã giúp nâng cao tinh thần đồng đội đáng kể, dù vậy, tôi tin rằng nếu có thêm một vài hoạt động team-building khác, hiệu quả gắn kết sẽ còn cao hơn nữa. Do làm việc trong khuôn khổ hợp đồng cố định, chúng tôi không có nhiều thời gian linh hoạt để triển khai những hoạt động như vậy.
Từ trải nghiệm của mình, tôi rút ra rằng: các Scrum Master nên chủ động khám phá những hình thức team-building đa dạng, tìm hiểu xem ban quản lý có thể hỗ trợ tổ chức các buổi họp mặt ngoài văn phòng hay không. Đồng thời, hãy sáng tạo hơn trong các buổi họp hồi tưởng. Ví dụ, ở một dự án khác, chúng tôi đã thử trò chơi Agile Jeopardy - một hình thức đố vui kiểm tra kiến thức về Agile và Scrum của cả nhóm. Không chỉ đem lại sự vui vẻ, trò chơi này còn giúp khơi dậy tinh thần học hỏi và gắn kết giữa các thành viên.
Kết luận
Khi một nhóm Scrum phát triển vượt quá mười hai thành viên, vai trò của bạn sẽ giống Project Manager hơn là Scrum Master. Bạn sẽ dành ít thời gian hơn cho các hoạt động hỗ trợ, loại bỏ trở ngại hay điều phối các vấn đề phát sinh, và nhiều thời gian hơn cho việc theo dõi tiến độ và báo cáo quản lý.
Nếu có thể, tôi khuyến nghị duy trì quy mô nhóm lý tưởng từ năm đến bảy người. Theo kinh nghiệm cá nhân, bốn nhóm Scrum là giới hạn tối đa mà một Scrum Master có thể quản lý hiệu quả - và nếu chỉ có hai nhóm thì sẽ là điều kiện lý tưởng nhất. Những nhóm nhỏ giúp bạn có thời gian tập trung cho các hoạt động mang tính chiến lược, thay vì chỉ xoay quanh các buổi họp và nghi lễ Scrum.
Tác giả: Donald “Mark” Haynes
Xem thêm:
Biết Dừng Để Tiến Xa: Cách Tập Trung Vào Ít Dự Án Hơn Nhưng Tạo Ra Giá Trị Lớn Hơn
Scrum Master và Project Manager