“Cứ cãi nhau tối ngày, và nhiều khi rất stress, nhưng không biết làm sao để thoát được tình cảnh này!” Đó là lời chia sẻ của một quản lý cấp cao của một ngân hàng khi tôi hỏi “Điều gì là thách thức khi đưa Agile vào doanh nghiệp?”.
Tôi hỏi một bạn khác đến từ công ty phần mềm rằng “Cách đội dự án bạn tổ chức Backlog Grooming như thế nào?”. Bạn ấy chia sẻ rằng “Team Leader, BA và Senior Developer sẽ làm công việc ước lượng và chuẩn bị cho Sprint Planning”. Tôi hỏi tiếp “Thế với Sprint 2 tuần thì sự kiện Sprint Planning của các bạn có kết thúc trong 4 giờ không?”. Bạn ấy trả lời với tâm trạng ngao ngán “Cũng có lúc kết thúc đúng giờ, mà thường thì kết thúc trễ hơn”. “Thế Scrum Master làm gì ở tình huống team không giữ được time-box?” tôi hỏi tiếp. Bạn ấy buồn bã trả lời “Project Manager kiêm vai trò Scrum Master và chuyện này là bình thường với anh ấy, riết rồi cũng quen nên không ai nói gì.”.
(Hình tác giả – Người mặc áo xám tham gia chia sẻ “Lean Software Development” ở XP Vietnam Day 2016)
Đó là một vài thông tin tôi nhận được khi tìm hiểu về kinh nghiệm với Agile/Scrum ở mỗi đầu khoá đào tạo quản lý dự án Agile.
Điểm thú vị là có nhiều bạn học viên đến từ nhiều doanh nghiệp khác nhau chia sẻ nhiều điểm chung ấy. Tôi xin chia sẻ vài thực trạng điển hình trong quá trình đi đào tạo và coaching Agile.
1) Vai trò trong dự án Agile không được phân định rõ ràng. Dự án Agile/Scrum chỉ có đúng 3 vai trò là Scrum Master, Product Owner, Development team. Vậy mà có nhiều doanh nghiệp vẫn dùng BA, Team Leader, Tester trong dự án. Và dự án Agile được áp dụng theo kiểu mệnh lệnh trong quản lý, và phân rõ chức năng trong dự án theo cách quản lý dự án truyền thống hay làm.
2) Các vai trò trong dự án hiểu về Agile, đặc biệt là kiến thức thực hành về Scrum Framework không giống nhau. Đây là một trong những nguyên nhân cãi nhau tối ngày, và mỗi người cãi trên 1 quan điểm khác nhau. Ai cũng cho mình hiểu đúng. Giống như chuyện các thầy bói xem voi vậy, mỗi thầy nói về quan điểm khác nhau. Lỗi này nằm ở khâu đào tạo yếu hoặc không đúng cách.
3) Không xây dựng tính kỷ luật cho team. Nhiều khi sprint diễn ra 2 tuần, còn 2 ngày nữa là kết thúc sprint nhưng việc đã hết. Vậy là team kéo thêm việc vào làm cho vừa đủ sprint. Trong một trường hợp khác, vẫn sprint 2 tuần nhưng đến thời điểm thực hiện review sprint thì team chưa làm xong. Cách nhiều dự án làm là nới thêm thời gian để team hoàn thành sprint. Đây là những lỗi tạo ra tiền lệ xấu, kết cục việc ước lượng dường như vô nghĩa, Velocity không kiểm soát được.
4) Thay đổi yêu cầu thường xuyên. Tôi hỏi các bạn “Tại sao cho phép thay đổi yêu cầu trong sprint?”. Các bạn ngay ngô trả lời rằng “Yêu cầu quan trọng từ khách hàng, yêu cầu quan trọng từ quản lý”. Tôi hỏi tiếp “Thế Scrum Master ở đâu mà để chuyện này xảy ra?”. Bạn trả lời là “Yêu cầu thay đổi đến từ Scrum Master là nhiều nhất, Scrum Master chính là Project Manager đó ạ”. Thật là khó xử, đây là cách làm việc theo Scrum-BUT, hậu quả là tính kỷ luật của team thật tệ hại. Nhiều khi còn tệ hơn cách làm truyền thống.
5) Viết yêu cầu và ước lượng là công việc của Product Owner và quản lý. Agile đi theo trường phái leadership và tập trung nhiều vào mục tiêu (thay vì tập trung nhiều vào quá trình như cách quản lý dự án truyền thống). Team là người quyết định ship cái gì theo sprint goal. Thế nhưng team không tham gia viết yêu cầu, và ước lượng thì làm sao họ quyết ship cái gì được. Team chính là người làm chứ không phải là Product Owner hay quản lý. Hậu quả là có qúa nhiều cuộc cãi vã về yêu cầu trong quá trình thực thi sprint.
6) Không xây dựng đội tự quản. Agile theo Leadership, nhưng khi không xây dựng được đội tự quản thì đừng mong Agile mang lại kết quả tốt. Team lại chờ đợi và phán xét nhau thay vì cùng nhau phối hợp hướng vào mục tiêu chung của sprint là sprint goals.
Đó là một vài tình huống đang diễn ra trong dự án Agile ở nhiều doanh nghiệp. Bạn có thể gặp nhiều tình huống tương tự hoặc tệ hơn ở nhiều doanh nghiệp khác. Lãnh đạo và quản lý kỳ vọng Agile có thể giúp phát triển sản phẩm nhanh và chất lượng. Nhiều bạn thốt lên rằng “Thà đừng áp dụng Agile thì mọi thứ sẽ ổn hơn”. Bạn đã gặp thực trạng này chưa? Làm sao bạn vượt qua các thách thức đó?
Không phải tôi phủ nhận sự thành công của Agile/Scrum ở nhiều doanh nghiệp. Nhưng theo quan sát của tôi thì số doanh nghiệp thành công là chưa nhiều.
Theo Apexglobal
