June 27, 2021 
Khởi nguồn là một phương pháp tiếp cận được sử dụng trong các dự án phát triển phần mềm, Agile trong những năm gần đây đã vượt ra khỏi địa hạt này và ảnh hưởng đến nhiều lĩnh vực non-tech khác như quản lý nhân sự, marketing, quản trị và lãnh đạo.
Câu hỏi mà chúng tôi thường xuyên nhận được từ khách hàng và đối tác của Enable Startup là: Agile có thực sự lý tưởng, “toàn năng” như cách mà người người nhà nhà đang nói về nó? Về cơ bản, câu trả lời của tôi là “Có”, bởi Agile từ góc nhìn của cá nhân tôi là một tinh thần, hơn là một bộ quy tắc, và tinh thần đó đa phần là có lợi. Vấn đề đáng nói ở đây là áp dụng Agile như thế nào trong thực tế, có những best practices nào đã được rút ra từ các dự án đi trước và cần cân nhắc những gì trong từng trường hợp cụ thể.
Ở bài viết này, tôi sẽ trình bày một số điểm then chốt về Agile cũng như những nguyên tắc áp dụng Agile nhằm tăng hiệu quả làm việc và tính ổn định, sức bền của team (high-performance teams). Đây là những gì được đúc rút từ kinh nghiệm hơn 11 năm làm việc trong ngành phần mềm của cá nhân tôi và hiện tại đang được áp dụng trong hầu hết các dự án tại Enable Startup.
Bài viết được chia thành 2 phần:
Phần 1: Hiểu về Agile, High-performance team và các khái niệm liên quan
Phần 2: Quy trình và cách thức xây dựng high-performance team tại Enable Startup
Điều đầu tiên cần lưu ý: không có một công thức chung đúng cho mọi công ty trong việc xây dựng high-performance team. Tùy vào đặc điểm về nguồn lực cũng như văn hóa mà mỗi doanh nghiệp tự xác định cho mình những “nguyên liệu” và rút ra những best practices riêng.
Tầm quan trọng của yếu tố văn hóa
Ở đây tôi đặc biệt muốn nhấn mạnh hai chữ “văn hóa”, bởi như có thể thấy, Agile nói chung và 6 tiêu chí của high-performance scrum team nói riêng đều đặc biệt đề cao yếu tố con người, theo nghĩa từng cá nhân cũng như tương tác giữa các cá nhân với nhau. Do đó, văn hóa có thể nói là xuất phát điểm, kim chỉ nam cho mọi chiến lược lập nhóm.
Văn hóa về cơ bản bao gồm văn hóa dân tộc, văn hóa vùng miền, văn hóa doanh nghiệp. Chẳng hạn, cùng mục tiêu đảm bảo tính tôn trọng (Respect) trong team, một công ty chịu ảnh hưởng của văn hóa Á Đông có thể sẽ phải cân nhắc đến tuổi tác, số năm kinh nghiệm của các thành viên nhiều hơn so với một công ty ở Mỹ. Hay ở phạm trù văn hóa doanh nghiệp, một công ty hướng ngoại chắc hẳn sẽ có những phương thức khác với một công ty hướng nội trong việc duy trì khả năng tập trung (Focus), tần suất họp team và các kênh feedback nội bộ nhằm đảm bảo tính cởi mở (Openness) giữa các thành viên.
Nói tóm lại, việc đánh giá lại những yếu tố văn hóa chi phối đến dự án ngay từ đầu sẽ giúp bạn xác định được một số giới hạn, lường trước được đâu là những điểm có thể tùy cơ ứng biến và đâu là những quy chuẩn không nên phá vỡ, cùng với đó là có những ý tưởng, hình dung ban đầu về chiến lược lập nhóm.
Các tiêu chí và hoạt động cụ thể
Sau khi đã “lấy đà” từ việc đánh giá lại văn hóa và nguồn lực, bước tiếp theo là bắt tay vào thiết kế team. Dưới đây là những câu hỏi mà tôi cho là quan trọng nhất, cùng với đó là các phương pháp cụ thể mà Enable Startup sử dụng để trả lời chúng.
| Câu hỏi | Giải pháp |
| 1. Team nên gồm bao nhiêu thành viên? | Team size từ 3-7 thành viên (không tính Scrum Master và Product Owner) |
| 2. Làm sao để lựa chọn thành viên cho team? | Hai tiêu chí cần cân nhắc: Tính đa dạng (Diversity) và khả năng bổ trợ lẫn nhau (Complementarity) |
| 3. Giao tiếp trong team nên diễn ra như thế nào? | Meetings & Feedback Loop |
| 4. Trong trường hợp cần bổ sung nhân lực, nên áp dụng chiến lược tuyển dụng nào? | Peer Recruitment |
| 5. Những hoạt động nào là cần thiết để nuôi dưỡng nguồn lực cho team? | - Xây dựng lộ trình phát triển cá nhân (Career Progression) - Thực hành song song hai loại hình team: chuyên môn hóa (functional) và đa chức năng (cross-functional) |
Mô hình 5 giai đoạn phát triển nhóm của Tuckman
Trước khi đi vào phân tích chi tiết từng giải pháp, tôi muốn giới thiệu ngắn gọn về mô hình 5 giai đoạn phát triển nhóm của Tuckman (The five-step Tuckman stages of group development) – một khung lý thuyết mà cá nhân tôi rất tâm đắc và áp dụng sâu sát trong quá trình vận hành Enable Startup.
Giai đoạn 1 – Forming. Tại bước đầu tiên này, team cần xác định rõ tầm nhìn và mục tiêu chiến lược. Từ đó cần thống nhất các quy tắc, quy trình cần thiết trước khi team bắt đầu vận hành. Một điều rất quan trọng là các mục tiêu cần có khung đo lường cụ thể và minh bạch, đủ để tất cả thành viên nắm được và cùng tham gia giám sát trong suốt chiều dài dự án.
Giai đoạn 2 - Storming. Tại thời điểm này, áp lực và những khác biệt về quan điểm có thể bắt đầu xuất hiện. Đây là giai đoạn mà các nguyên tắc trong giao tiếp và tranh luận nên được tạo ra để cả team dễ dàng đạt được đồng thuận, từ đó thúc đẩy hiệu suất cá nhân và gián tiếp tạo ra hiệu suất chung của team.
Giai đoạn 3 - Norming. Bước sang giai đoạn này các thành viên bắt đầu làm việc nhịp nhàng và hiểu nhau hơn. Trong nội bộ team cũng sẽ bắt đầu xuất hiện những nguyên tắc ngầm định để giúp công việc trở nên hiệu quả hơn. Ở thời điểm này các chỉ số về hiệu quả (Performance Metrics và Delivery Metrics) nên được hiệu chỉnh sao cho phù hợp và ổn định, cả team bắt đầu có khả năng dự đoán về tiến độ cũng như có những sáng kiến để nâng cao tính sáng tạo, cải thiện hiệu năng sản phẩm.
Giai đoạn 4 - Performing. Một khi đã xây dựng được sự gắn kết và đồng cảm, nhóm bắt đầu hoạt động hiệu quả như một thể thống nhất, đủ sức đảm nhận các nhiệm vụ quan trọng hơn và đạt được mục tiêu dễ dàng hơn.
Giai đoạn 5 - Adjourning. Sau một khoảng thời gian nhất định, nhóm sẽ nhìn lại hiệu suất của mình, rà soát lại những điểm được và chưa được. Ở giai đoạn này, mỗi thành viên trong team cần nhận được sự ghi nhận xứng đáng và có thể được trao nhiều nhiệm vụ quan trọng hơn.
Việc nắm rõ được vòng đời nói trên giúp chúng tôi nhận ra rằng, muốn phát triển team nhanh nhất thì nguyên tắc là phải làm sao để tăng tốc cho từng giai đoạn.
Từ đó, các giải pháp cụ thể như ở Bảng 1. được đề ra. Dưới đây chúng ta sẽ cùng đi sâu vào chi tiết.
Quy mô nhóm (Team size)
Số lượng thành viên trong team không chỉ đơn giản là một con số. Việc thêm hay bớt một thành viên sẽ dẫn đến những sự thay đổi quan trọng sau đây:
- Số lượng mối quan hệ trong team như được minh họa bởi công thức dưới đây
- Thời gian mỗi thành viên phải dành ra trong ngày để quản lý các mối quan hệ này (lưu ý: một phần trong quỹ thời gian đó dành cho các nội dung ngoài lề công việc)
Các rủi ro liên quan đến mức độ hài lòng trong từng mối quan hệ.
Con số được đề xuất trong Scrum Guide là 3-9 thành viên, không tính Scrum Master và Product Owner. Tuy vậy từ 3 đến 9 là một khoảng cách đáng kể, nhất là nếu như quy ra thành số lượng mối quan hệ cần quản lý (3 vs. 36 theo như cách tính ở trên).
Từ các kinh nghiệm thực tế cũng như đối chiếu với các nghiên cứu trong Scrum Team Size, con số mà chúng tôi thường áp dụng cho các dự án tại Enable Startup là 3-6 thành viên mỗi team, không tính Scrum Master và Product Owner. Trong trường hợp dự án yêu cầu nhiều hơn 7 thành viên, phương án sẽ là chia thành 2 team nhỏ. Quy mô nhóm như vậy cho thấy hiệu quả tối ưu cho các dự án phát triển MVP kéo dài từ 3-12 tháng.
Tính đa dạng và khả năng bổ trợ của các thành viên (Diversity & Complementarity)
Agile nói chung và Scrum nói riêng nhấn mạnh tính linh hoạt và những cơ chế trao đổi, sửa sai giữa các thành viên để giúp dự án liên tục được tối ưu, bởi vậy tính đa dạng là một tiêu chí không thể thiếu.
Tính đa dạng trong một high-performance team không chỉ bao gồm phương diện tuổi nghề, kiến thức, kỹ năng chuyên môn mà còn cả về tính cách, góc nhìn hay kể cả giới tính.
Câu hỏi đặt ra là đa dạng đến đâu thì đủ và như thế nào sẽ là thừa, hay nói cách khác phản tác dụng?
Một lần nữa, không có câu trả lời nào là chuẩn cho mọi trường hợp. Tuy vậy, một nguyên tắc tối quan trọng là không nên “cố đấm ăn xôi” để đảm bảo tiêu chí đa dạng, mà vô tình làm tổn thương các tiêu chí khác cũng quan trọng không kém như cơ hội công bằng cho mọi người hay tính minh bạch.
Họp nhóm (Meetings)
Mục đích của meetings là nhằm đảm bảo các thành viên đều nắm được tình hình công việc và nhiệm vụ kế tiếp. Mô hình Scrum đã đề xuất một hệ thống phân loại meetings khá toàn diện và “đo ni đóng giày” cho các dự án phát triển phần mềm, bao gồm Daily Standup Meeting, Sprint Planning Meeting, Sprint Review Meeting, Retrospective Meeting, Product Backlog Refinement Meetings.
Dựa trên mô hình này, bạn có thể điều chỉnh cho phù hợp với dự án cụ thể, tuy nhiên cần đảm bảo các yếu tố then chốt như tính đều đặn, được lên kế hoạch một cách khoa học và có những bài học rút ra vào cuối mỗi meeting.
Về nội dung thảo luận trong meeting, ngoài các vấn đề chuyên môn, các yếu tố tác động đến cảm xúc như áp lực công việc, bất đồng ý kiến, sai sót về cách thực hiện, kết quả không như ý cũng cần được đặc biệt lưu ý. Scrum Master, ngoài vai trò duy trì việc thực hành các tiêu chuẩn Scrum cũng như các Scrum best practices, còn là người có trách nhiệm quan sát và tạo điều kiện nhằm đảm bảo mỗi thành viên luôn có một sức khỏe tinh thần tốt nhất, từ đó đáp ứng hiệu suất chung của dự án.
Liên tục phản hồi (Feedback Loop)
Feedback giúp các thành viên hiểu nhau hơn, thúc đẩy sự ghi nhận cũng như kịp thời phát hiện các điểm còn thiếu sót. Hoạt động này nên được thực hiện thường xuyên thông qua các buổi họp, trong đó mỗi cá nhân được dành riêng một thời lượng để nêu lên tiếng nói của mình và các thành viên còn lại được yêu cầu lắng nghe, đưa ra ý kiến cũng như phản biện nếu có. Feedback không chỉ nói ra rồi để đấy, mà cần được rút lại thành các bài học cụ thể (lessons learned).
Tuyển dụng đồng cấp (Peer Recruitment)
Trong trường hợp cần bổ sung thành viên cho team, peer recruitment, tạm dịch là tuyển dụng đồng cấp, là phương pháp mà chúng tôi khuyên dùng. Lý do đơn giản là vì không ai có thể hiểu về những gì team cần hơn là chính các thành viên trong team.
Điều này có thể không đúng với các mô hình tổ chức team truyền thống, nơi mà mỗi thành viên chỉ tập trung vào một góc nhỏ của dự án. Tuy nhiên, một khi đã đi theo Agile, mỗi thành viên đã được mặc định phải hiểu về dự án tương đối toàn diện. Bởi vậy peer recruitment áp dụng ở đây trở nên đặc biệt đúng chỗ.
******************
Nếu như các nguyên tắc kể trên được áp dụng trong khuôn khổ từng nhóm dự án, thì một câu hỏi quan trọng không kém là những hoạt động nào là cần thiết trong một công ty nhằm nuôi dưỡng nguồn lực bền vững, sẵn sàng cấu thành nên các nhóm dự án này? Tại Enable Startup, có hai giải pháp chính để giải quyết vấn đề: 1. Ở mức độ cá nhân , chúng tôi xây dựng, theo dõi lộ trình phát triển bài bản cho từng thành viên; 2. Ở góc độ tập thể, chúng tôi vận hành song song hai loại hình tổ chức team: chuyên môn hóa (functional) và đa chức năng (cross-functional).
Xây dựng và theo dõi lộ trình phát triển cho từng thành viên (Career Progression)
Đây là một điểm cực kỳ quan trọng nhưng lại thường xuyên bị coi nhẹ.
Thật vậy, một tổ chức muốn đạt được hiệu quả cao không thể bỏ qua trải nghiệm của từng cá nhân tạo nên nó. Bên cạnh việc nhắc đi nhắc lại về mục tiêu cần đạt được cho khách hàng và công ty, mỗi thành viên cũng cần được nhìn nhận những gì đã đóng góp, phân tích đánh giá chất lượng làm việc cũng như định hướng các nấc thang phát triển của họ trong tương lai.
Việc xây dựng một framework về Career Progression bởi vậy là tối quan trọng để giúp các cá nhân có lộ trình phát triển phù hợp, từ đó có động lực mạnh mẽ hơn và đóng góp nhiều giá trị cho tổ chức. Không ít người nghĩ rằng career progression chỉ cần thiết cho các công ty lớn. Cá nhân tôi tin rằng quan điểm này hoàn toàn sai lầm. Việc trực tiếp quan sát và hỗ trợ lộ trình phát triển của từng nhân viên thực sự là một trong những trải nghiệm tuyệt vời và ý nghĩa nhất mà tôi có được ở vị trí điều hành một công ty nhỏ.
Vận hành song song hai loại hình tổ chức team: chuyên môn hóa (functional) và đa chức năng (cross-functional)
Functional Team
Functional team có thể hiểu tương đương như một đơn vị kinh doanh chiến lược (business unit), chuyên sâu về một lĩnh vực nhất định, có chức năng tuyển dụng, nghiên cứu, đào tạo, đánh giá nhân lực trong khuôn khổ chuyên môn đó. Tại Enable Startup, chúng tôi có những functional team như Account Management, Marketing, UX-UI, Web & Mobile Apps Development, Data Science và IoT. Mục tiêu của các team này là nhằm tuyển chọn, nuôi dưỡng những cá nhân có đủ trình độ để sẵn sàng tham gia các cross-functional team.
Cross-functional Team
Đây là loại hình tổ chức nhóm ngắn hạn được thành lập khi có dự án mới, product mới, và đi từ đầu đến khi kết thúc dự án hoặc sản phẩm.
Như vậy functional teams là được xem như một talent pool nhằm chuẩn bị “nguyên liệu” cho cross-functional teams, hạn chế tối đa việc tuyển dụng một cách bị động, dẫn đến nhiều rủi ro như thiếu hiểu biết văn hoá công ty, trình độ chuyên môn không đủ đáp ứng, phong cách làm việc không phù hợp.
Việc song hành 2 loại hình tổ chức nhóm này cực kỳ phù hợp để một mặt, đáp ứng các nhiệm vụ chiến lược, dài hạn về phát triển nguồn nhân lực; mặt khác đảm bảo khả năng luân chuyển nội bộ linh hoạt nhằm phục vụ cho các dự án ngắn hạn hoặc mục tiêu trong từng giai đoạn nhất định của tổ chức.
Lời kết
Tư duy Agile là một hướng tiếp cận tốt nhằm xây dựng high-performance team. Tuy vậy thực thi nó bằng cách nào lại đòi hỏi mỗi tổ chức hiểu sâu sắc về điều kiện nội tại của team cũng như các yếu tố khách quan của từng dự án.
Việc nghiên cứu và đúc rút thành một bộ quy tắc, quy trình, tiêu chí chặt chẽ cho việc xây dựng high-performance team dành riêng cho từng doanh nghiệp là điều cực kỳ quan trọng. Nên nhớ, bạn không cần đợi công ty của mình lớn bằng bất kỳ công ty XYZ nào mới bắt tay vào công việc này. Ngược lại, bạn làm nó càng sớm công ty của bạn lớn càng nhanh.
Rất hy vọng những kinh nghiệm trên đây của Enable Startup sẽ giúp ích cho những doanh nghiệp vừa và nhỏ đang nỗ lực xây dựng các high-performance team. Chúng tôi cũng háo hức nhận được những ý kiến phản biện hoặc chia sẻ về quan điểm, trải nghiệm của bạn ngay dưới phần bình luận hoặc qua hòm mail [email protected]!
