Dân Agile thường nói “Scrum thì dễ áp dụng nhưng khó tinh thông”, vì lý thuyết là một chuyện nhưng khi đi vào thực tế lại hoàn toàn khác hẳn. Ngay trong một công ty, việc áp dụng Scrum vào từng team cũng đã cần có nhiều sự điều chỉnh, huống chi là ở các công ty hoạt động trong các ngành nghề khác nhau, đặc điểm tổ chức, nhân sự khác nhau thì sự khác biệt lại càng lớn.
Như chúng ta đã biết, trong Scrum chỉ có Nhóm Phát triển và Product Owner:
Nhóm Scrum không có một chức danh nào khác trong Nhóm Phát triển là Developer (Nhà Phát triển). Do đó việc có chức danh như Tech Lead được khuyến cáo là mang lại rất nhiều vấn đề cho Nhóm Phát triển như:
– Mất đi tính sở hữu tập thể (collective ownership) của Nhóm Phát triển. Điều này ảnh hưởng tới tính cam kết và động lực của các thành viên trong nhóm.
– Không tận dụng được trí tuệ tập thể. Các thành viên sẽ không muốn đóng góp những cải tiến về mặt kỹ thuật cho sản phẩm.
– Giảm khả năng tự tổ chức của nhóm và có thể quay về mô hình truyền thống.
Tuy nhiên, khả năng tự tổ chức không phải là yếu tố hiển nhiên với tất cả thành viên trong các nhóm Agile ví dụ như các tình huống sau:
– Có sự chênh lệch trình độ rất lớn (hầu hết đều là người mới – đang trong quá trình học việc). Các thành viên cơ bản không đóng góp được gì.
– Là nhóm phân tán, việc giao tiếp với nhau rất khó khăn.
– Nhóm không có khả năng thống nhất được một cách thiết kế/làm việc trong dự án làm cho codebase của dự án bị nát.
– Việc giao tiếp và thương lượng về mặt kỹ thuật với bên ngoài như Product Owner, stakeholder chỉ có một người có khả năng làm được và cần một người chịu trách nhiệm do đặc tính của tổ chức hoặc khách hàng.
Lúc này một Tech Lead, người có tiếng nói cuối cùng về mặt kỹ thuật của nhóm sẽ giải quyết được tình trạng này. Tuy nhiên, Tech Lead cần phải ý thức rất rõ những vấn đề có thể gặp phải như trên và có kế hoạch để giải quyết triệt để những vấn đề này.
Sau đây là một số mẹo mà Tech Lead nên thực hiện:
– Học cách để giao phó và trao quyền để từ đó thành viên nhóm trưởng thành cũng như tăng tính sở hữu tập thể của nhóm.
– Dành thời gian để code, không chỉ quản lý và thiết kế. Bạn phải code để nhóm học được cách làm và bạn không bị mất nghề.
– Trực quan hóa kiến trúc để các thành viên biết mình đang làm gì trong bức tranh tổng thể. Đó cũng là cách để thành viên học và tự ra được quyết định chứ không phụ thuộc hoàn toàn vào Tech Lead.
– Dành thời gian làm việc 1-1 với thành viên trong nhóm để giải quyết những khó khăn của từng thành viên và giúp các thành viên trưởng thành.
– Quản lý công việc và lãnh đạo con người chứ không phải ngược lại.
Hy vọng rằng những chia sẻ trong bài viết này sẽ giúp cho bạn có thêm kinh nghiệm áp dụng Scrum trong nhóm của bạn.
Phạm Anh Đới.
