Hotline

0963 801 047
APEX Global
ACADEMY FOR PROFESSIONAL EXCELLENCE

Những thách thức triển khai Agile là gì?

2017-06-30  (2205)

Có một Head of Digital của một ngân hàng mời café và nhờ tôi tư vấn hướng tiếp cận để triển khai Agile. Tôi hỏi “Điều gì thôi thúc ngân hàng của bạn triển khai Agile?”, bạn ấy trả lời rằng một người bạn đang làm trưởng phòng của cty bảo hiểm quốc tế chia sẻ rằng “Văn hoá làm việc Agile đáp ứng sự thay đổi nhanh trong dự án và team làm việc rất cởi mở, nhưng đó là môi trường làm việc của họ thúc đẩy tốt teamwork, đó là một bức tranh đẹp. Để có được bức tranh Agile đẹp ấy thì các thách thức thường gặp là gì?”. Đây là lời chia sẻ thể hiện sự khao khát thành công đi kèm với một câu hỏi thú vị mà rất ít nhà quản lý bộ phận phát triển phần mềm dám hỏi. Có thể mọi người không cảm thấy thoải mái khi đề cập đến từ “thách thức” vậy.

Quan điểm của tôi thì trước sau gì bạn cũng phải nghĩ đến hai từ “thách thức” trong hành trình đưa Agile vào doanh nghiệp. Vậy thì hãy nghĩ đến cái đích của thành công và các rào cản cần chuẩn bị để vượt qua trong hành trình ấy.

Thach_thuc_trien_khai_Agile_la_gi_1

(Hình tác gia chia sẻ “Agile Business Analyst” ở Agile Vietnam Conference 2016 do cộng đồng Agile Vietnam tổ chức)

***

Bạn đang đọc phần 5 của series bài viết về chủ đề về “Ứng dụng Agile trong doanh nghiệp” bạn có thể đọc các phần của bài viết:

***

Trong quá trình đi huấn luyện Agile, chia sẻ về Agile, tôi nhận thấy một số điểm thách thức gây khó khăn, nhiều khi gây ra thất bại ê chề.

  • Nhận thức sai về Agile: Ở nhiều doanh nghiệp từ lãnh đạo, đến quản lý xem việc đưa Agile như một dự án như bao dự án theo cách làm truyền thống khác. Kết quả dự án Agile lăn ra chết vì thành viên nào cũng stress với cách làm nửa nạc nửa mỡ ( nửa theo truyền thống, nửa theo Agile). Muốn Agile thành công thì cần thôi thúc lãnh đạo học “nhận thức về Agile đầu tiên”.
  • Mục tiêu chiến lược không rõ ràng: Ở nhiều doanh nghiệp Agile được đưa vào doanh nghiệp từ một cấp quản lý chứ không phải đó là mục tiêu chiến lược của doanh nghiệp. Agile cần phối hợp hài hoà trong chuỗi giá trị của doanh nghiệp, từ khâu bán hàng, văn hoá hợp đồng, phát triển nguồn nhân lực. Kết quả thường là lãnh đạo không hỗ trợ, các phòng ban không phối hợp đồng bộ. Agile lại là một cái từ đáng lãng quên.
  • Đội dự án Agile hiểu không đúng về Agile: Trong một đội dự án Agile có 9 thành viên nhưng lại có nhiều trường phái Agile khác nhau, cách hiểu về nguyên lý thực hành làm việc nhóm cũng khác nhau. Thế là cả đám cãi nhau tối ngày về Agile, thay vì tranh luận về Business Value của khách hàng hay Potential Value từ giải pháp thiết kế. Hỏi ra thì mới biết, mỗi thành viên tự học Agile ở nhiều nơi khác nhau. Đào tạo hiểu đúng quy trình và nguyên lý làm việc nhóm là khởi đầu vượt qua thách thức.

Bài viết liên quan: Nguyên lý của Agile và sự thành công của phát triển phần mềm

  • Chọn sai người đào tạo: Lý thuyết Agile khá đơn giản, bạn có thể tự học được. Cái bạn cần học từ chuyên gia Agile là cách thực hành các nguyên lý làm việc nhóm, nguyên lý phát triển phần mềm và hiểu được sâu xa ý nghĩa của mỗi nguyên lý ấy. Nhiều bạn học Agile xong nhưng về cty không biết áp dụng vào công việc thực tế như thế nào và nói ậm ừ “học cho biết rồi triển khai từng phần của Agile”. Triển khai 1 phần tức là bạn đang đi lại vết xe đổ của người khác.
  • Không phân định rõ vai trò: Cũng ngộ, nhiều nơi triển khai Agile mà vẫn giữ vai trò Project Manager – PM trong dự án. Mà có PM nào thích chữ “Savant-leader” đâu? Thế là các PM ấy ôm cái quyền to như cây súng của mình mà hối thúc team. Chỉ 3 vai trò là đủ Scrum Master, Product Owner và Development team. Hỏi ra thì mới biết có sự nhọc nhằn giữa Title/Position và Role.

Bài viết liên quan: Đâu là chân dung của một Scrum Master chuyên nghiệp?

  • Không trao quyền đúng cách: Để team có thể collaborate tốt với nhau, collaborate tốt với khách hàng thì cần nói rõ vai trò của mỗi thành viên, trao quyền cho họ theo lộ trình trưởng thành trong việc làm nhóm của team. Thay vì có các vị trí Team Leader đứng giám sát và phân bổ công việc. Làm theo Agile không phải vậy.
  • Văn hoá làm việc không thúc đẩy làm việc nhóm: Trong dự án Agile mà còn phân định level của team là thua, level cao thì làm công việc khó, level thấp thì làm công việc dễ, vô tình bí kíp ở level cao hiếm khi được chia sẻ sang level thấp. Giao tiếp thì dùng email để có evident thay vì giao tiếp face-to-face. Đừng mong mà team tự quản được với cách tổ chức này.

Bài viết liên quan: Làm sao để xây dựng Đội tự quản (Self-Organizing Team) trong dự án Agile?

Thach_thuc_trien_khai_Agile_la_gi_2

(Nội dung trong module Agile for Manager trong khoá đào tạo quản lý dự án Agile chuyên nghiệp của Apex Global)

  • Retrospective là chuyện của Scrum Master: Agile là cải tiến liên tục, nhưng khi cả team nhận thức rằng sự kiện Retrospective là việc của Scrum Master đi hỏi team thì đó là dấu hiệu của Scrum-BUT.
  • Đánh giá năng lực dựa trên sự cố gắng của từng member: Cái này ngộ nhất, mỗi sprint có sprint goals, vậy mà khi nghiệm thu thì đánh giá năng lực của từng thành viên. “Đã là mục tiêu chung, tại sao cho cả đám chết chung khi sprint thất bại?” tôi từng hỏi câu hỏi này với trưởng bộ phận cty phần mềm. Kết quả tò ra là KPI đo theo công việc từng thành viên, chứ không phải theo mục tiêu của team.
  • Không xây dựng được tính kỷ luật làm việc: Đây là câu chuyện dài, nào là đi trễ, team không tham dự meeting, nghỉ phép không kế hoạch, tính OT cho cty, hết time-boxed thì không dừng. Làm sao để xây dựng được Self-organizing team khi team không có ý thức kỷ luật?

Bài viết liên quan: Những sai lầm thường gặp ở Daily Stand-up Meeting trong dự án Agile

Còn rất nhiều thách thức khác chờ bạn kể. Cả thế giới thành công với Agile và dùng Agile tạo ra lợi thế cạnh tranh cho hoạt động sản xuất kinh doanh cho doanh nghiệp họ. Họ làm được thì bạn cũng làm được. Mấu chốt là bạn chọn tiếp cận đúng cách.

By Cao Trần

Bài viết chia sẻ trên tường facebook của tác giả ở link