Đó là câu hỏi của một CTO thế hệ 8X ở một start-up công nghệ nhờ tôi tư vấn. Bạn ấy chia sẻ thêm rằng “đã hỏi đến nhiều người triển khai Agile nhưng chưa tìm được câu trả lời thoả đáng”. Tôi nghĩ những ai đã triển khai Agile thì phải biết ẩn ý đằng sau cái từ “Transparency” này chứ. Thông tin bạn ấy chia sẻ làm tôi không khỏi bất ngờ. Còn theo bạn thì: “Bạn hiểu thế nào về từ Transparency trong dự án Agile?”.
Trong 2 tháng qua, tôi đã mang câu hỏi ấy đi hỏi cả thảy 15 người trong network của tôi. Họ đang đảm nhận vai trò: Scrum Master, Product Owner, Business Analyst, Project Manager, Head of Software Development ở môi trường có triển khai Agile. Điều thú vị là mọi thứ chỉ xoay quanh:
- Transparency trong quản lý yêu cầu
- Transparency trong quản lý tiến trình phát triển
- Transparency trong quản lý các trở ngại
Chỉ gói gọn như thế. Hèn gì các bạn triển khai Agile luôn đối diện quá nhiều thách thức. Bạn có đang đối diện thách thức dự án Agile không?
Scrum framework đưa ra cái kiềng 3 chân để kiểm soát về mặt quản trị dự án theo hướng leadership. Trong đó có 1 chân là “Transparency”, tôi tạm dịch là “Minh bạch”. Còn để hiểu đầy đủ thì bạn cần nhìn vào các hoạt động thực hành theo Scrum như:
1) Minh bạch trong vài trò nhiệm vụ: Scrum phân định đúng 3 vai trò là Scrum Master, Product Owner và Development Team. Bên cạnh đó các vai trò còn lại gọi chung là Stakeholder. Đội dự án cần định nghĩa rõ vai trò, trách nhiệm và cơ chế kiểm soát của mỗi vai trò trong các hoạt động của dự án. Ví dụ: team đang chạy trong Sprint và Product Owner bỏ thay đổi yêu cầu hoặc giảm đi điều kiện nghiệm thu so với Sprint Goals thì cần phải có hành động gì? Ai thực hiện hành động ra quyết định? Bên cạnh đó công việc quản lý dự án đã chuyển một phần cho Development Team, và làm sao để giúp họ hiểu “quản lý” ở đây là gì và làm sao để thực hành chúng?
Bài viết liên quan: Vai trò Development Team trong dự án Agile
2) Minh bạch định nghĩa hoàn thành (Definition of Done hay gọi tắc là DoD), Minh bạch trong Sprint Goals: Đây là những điều kiện tiên quyết cần viết ra và đảm bảo tất cả team cùng hiểu giống nhau, kể cả Stakeholders.
3) Minh bạch tiến trình diễn ra công việc: Đảm bảo status và kết quả của công việc được cập nhật đúng theo thời gian thực khi công việc bắt đầu, kết thúc hoặc ở cuối ngày (nếu công việc đó diễn ra qua ngày). Đảm bảo các trở ngại được chia sẻ cho cả đội. Tiến trình cần minh bạch cho cả quản lý (stakeholders), họ chỉ cần xem burn-down chart thì biết được diễn biến của dự án mà không phải đọc báo cáo từ ai đó.
4) Minh bạch tầm nhìn về sản phẩm: Đây là điều các Product Owner hay che dấu hoặc không chia sẻ kịp thời dẫn đến tình trạng mất phương hướng cho team.
5) Minh bạch trong cách quản lý yêu cầu trên Product Backlog và bản thân mỗi User Story: Product Owner cần cho team biết về độ ưu tiên trên Product Backlog, Product Roadmap. Với User Story thì Product Owner cần cho biết được Business Value và điều kiện nghiệm thu cụ thể là gì. Ở vai trò Scrum Master, hay Development team, bạn đặt câu hỏi “Giá trị khách hàng đạt được thông qua User Story này là gì?” với Product Owner. Đôi khi bạn đối diện với sự “ậm ờ”, tốt nhất bạn bỏ User Story trở lại Product Backlog.
Bài viết liên quan: Cách thức quản lý Product Backlog trong dự án Agile
6) Minh bạch trong hoạt động xây dựng kiến trúc phần mềm: Với một số phần mềm thì có vai trò kiến trúc sư (Software Architect – SA) tham gia xây dựng và chuẩn bị kiến trúc cho team (người này thường thuộc nhóm Stakeholder). Nhiều bạn chia sẻ với tôi rằng đây vị trí này như là một hố đen của vũ trụ. Nhiều lúc User Story đã kéo vào Sprint Board rồi mà kiến trúc liên quan chưa sẵn sàng, hoặc nhiều khi kiến trúc liên User story đang triển khai phải thay đổi, hoặc nhiều khi SA hứa sẽ hỗ trợ mà không giữ được cam kết. Đây là lỗi của team không trả lời được câu hỏi trước khi đưa ra ước lượng cho User Story: “Bạn có thiết kế được không?”.
(Hình ảnh ở lớp học Agile Project Management Professional của Apex Global)
7) Minh bạch trong ước lượng (Estimate): Ước lượng Story Point là một hoạt động bắt buộc và mang nhiều tính quyết định đến sự minh bạch ở các hoạt động khác. Ước lượng là hành động xác nhận team đã hiểu yêu cầu giống nhau, hiểu cách tiếp cận thiết kế giống nhau, hiểu được cách triển khai code giống nhau, hiểu được làm sao để hoàn thành công việc kiểm thử giống nhau, tích hợp chúng với tính năng của sản phẩm đang có giống nhau và hiểu rằng ai cũng có khả năng thực hiện. Vậy mà trong thực tế triển khai hiếm đơn vị nào triển khai Agile làm được. Nguyên nhân sâu xa Scum Master nhiều khi không hiểu phương pháp thực hành ước lượng để hướng dẫn team.
Bài viết liên quan: Tại sao Planning Poker được khuyến khích dùng trong dự án Agile?
8) Minh bạch trong đi trễ về sớm và nghỉ phép của team: Nghỉ phép là việc không thể tránh khỏi và thành viên nào có kế hoạch nghỉ thì phải chia sẻ cho cả team biết ngay thời điểm lên kế hoạch. Trong tình huống bất khả kháng thì cả team cần biết thông tin và cùng đồng ý. Team là người ra quyết định chứ không phải là Scrum Master hay một người quản lý bên ngoài team. Self-organizing team là thế.
9) Minh bạch trong việc quản lý các trở ngại và cả các cải tiến: Tất cả các trở ngại phải được Scrum Master ghi nhận lại theo một cách quy củ và team tham gia mổ xẻ các root cause ở mỗi sự kiện Retrospective.
10) Minh bạch trong cách nghĩ và cách hành động của team: Đây là điều ít Scrum Master để ý tới. Điều gì sẽ xảy ra nếu các thành viên team nghĩ, hiểu mục tiêu, giá trị đề mang lại cho khách hàng khác nhau quá nhiều ở một thời điểm? Thật khó để gọi họ là một team (chỉ có thể gọi là 1 group) với tình huống này.
***
Đây là series bài viết về chủ đề “Ứng dụng Agile trong doanh nghiệp” tôi chia sẻ cho cộng đồng Agile Vietnam.
- Phần 1: Thực trạng ứng dụng Agile trong doanh nghiệp
- Phần 2: Khách hàng kỳ vọng điều gì từ dự án Agile?
- Phần 3: Team cần gì từ dự án Agile Scrum?
- Phần 4: Tại sao lãnh đạo đặt mục tiêu đưa Agile vào doanh nghiệp?
- Phần 5: Những thách thức triển khai Agile là gì?
***
Và tính minh bạch cần áp dụng ở tất cả các hoạt động khác trong hoạt động quản lý dự án Agile. Khi sự minh bạch không được triển khai đúng thì dự án Agile ở đó gặp vấn đề. Đó cũng là một trong những nguyên nhân gây thất bại trong việc xây dựng đội tự quản (Self-organizing team). Lỗi thường đến từ Agile Adoption không đúng cách và năng lực huấn luyện hạn chế của chính các Scrum Master. Có thể thông tin làm bạn chua xót, nhưng tôi nghĩ thà đối diện với trở ngại và vượt qua thật nhanh sẽ tốt hơn.
Bạn có thể bỏ vài giờ để đọc hiểu Scrum Guide và mạnh dạn triển khai Scrum. Nhưng bạn có hiểu rằng đằng sau mỗi từ ấy là những nguyên lý về quản lý và quản trị dự án? Bênh cạnh lý thuyết, thì những nguyên lý là thứ chúng tôi hướng dẫn thực hành và correct học viên ngay tại lớp đào tạo quản lý dự án Agile của mình. Riêng tôi thì nghĩ rằng: “Các bạn hiểu đúng, thực hành đúng ngay tại lớp thì sẽ giảm được nguy cơ làm sai khi triển khai ở doanh nghiệp”.
by Cao Trần