Transparency trong dự án Agile hiểu như thế nào mới đúng?

Transparency (minh bạch) là gì? Áp dụng nó như nào trong doanh nghiệp có lẽ nhiều người không trả lời được mặc dù đang đảm nhận các vị trí như: Scrum Master, Product Owner, Business Analyst, Project Manager, Head of Software Development tại doanh nghiệp.

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ạ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ư:

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?

Minh bạch định nghĩa hoàn thành, 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.

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 đó.

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.

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.

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ẻ 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?”.

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.

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ế.

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.

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.

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. 

Theo Apexglobal