Đội 10 năm làm waterfall chuyển sang Scrum: "Agile hình thức" và lộ trình chuyển đổi thực chất

Tình huống minh hoạ

Tình huống dưới đây là giả định, dùng để minh hoạ.

Phòng Phát triển hệ thống của một công ty bảo hiểm nhân thọ có 25 người, nhiều năm làm theo mô hình thác nước: phân tích – thiết kế – lập trình – kiểm thử – triển khai. Ban lãnh đạo yêu cầu "chuyển sang agile trong quý này" sau một hội thảo chuyển đổi số.

Ba tháng sau, chị Mai – PM mới được bổ nhiệm làm Agile Coach nội bộ – quan sát thấy:

• Các "sprint" hai tuần thực chất là các giai đoạn cũ: sprint 1–3 phân tích, sprint 4–8 lập trình, sprint 9–10 kiểm thử.
• Daily Scrum biến thành buổi trưởng nhóm giao việc và hỏi "xong chưa?".
• Đội kiểm thử vẫn là phòng riêng, nhận bản build vào cuối chu kỳ.
• Sản phẩm phần mềm quản lý hợp đồng cho đại lý vẫn dự kiến bàn giao một lần sau sáu tháng.
• Nhân viên nói: "Agile chỉ là thêm họp."

Phân tích theo PMBOK® Guide

Development Approach and Life Cycle Performance Domain phân biệt rõ cách tiếp cận dự đoán (predictive), thích ứng (adaptive) và lai (hybrid). Agile không phải tập hợp các cuộc họp, mà là cách tiếp cận dựa trên bàn giao gia tăng có giá trị, phản hồi thường xuyên và đội tự tổ chức.

Agile Practice Guide nhấn mạnh agile là mindset dựa trên các giá trị và nguyên tắc của Tuyên ngôn Agile (Agile Manifesto); các phương pháp như Scrum, Kanban là cách thực hiện mindset đó. Khi chỉ chép lại nghi thức mà không đổi tư duy, tổ chức có "agile hình thức".

Team Performance Domain: đội tự tổ chức cần được trao quyền, an toàn tâm lý và lãnh đạo phục vụ (servant leadership). Trưởng nhóm giao việc trong Daily Scrum đi ngược điều này.

Nguyên nhân gốc:

1. Chuyển đổi được ra lệnh từ trên xuống, không giải thích "vì sao", không có mục tiêu kinh doanh cụ thể.
2. Cấu trúc tổ chức giữ nguyên: phòng phân tích, phòng lập trình, phòng kiểm thử tách rời – không có đội liên chức năng (cross-functional).
3. Vai trò quản lý cũ không được định nghĩa lại; trưởng nhóm lo mất quyền.
4. Không có đào tạo và hướng dẫn thực hành, chỉ có hội thảo.

Cách xử lý

1. Làm rõ "vì sao" bằng mục tiêu kinh doanh

Cùng lãnh đạo xác định vấn đề cần giải quyết: ví dụ thời gian ra sản phẩm bảo hiểm mới cho đại lý quá dài, phản hồi từ đại lý đến quá muộn. Mục tiêu đo được: rút ngắn thời gian từ ý tưởng tới bản dùng thử đầu tiên.

2. Thí điểm với một đội, không chuyển cả phòng cùng lúc

Chọn một sản phẩm có giá trị rõ và người dùng sẵn sàng phản hồi. Tổ chức 7–8 người gồm phân tích, lập trình, kiểm thử ngồi cùng nhau.