Trong một tổ chức Agile, sự minh bạch là tối quan trọng, nó là nền tảng để xây dựng sự tin tưởng và hợp tác bên trong tổ chức cũng như giữa tổ chức với các bên liên quan bên ngoài tổ chức, giúp các bên liên quan có đủ đầy đủ thông tin để ra quyết định kịp thời và đúng đắn. Sự minh bạch là nền tảng để tổ chức thanh tra quy trình hoạt động, quy trình phát triển sản phẩm từ đó liên tục cải tiến để tốt hơn. Sự hạn chế về tính minh bạch có thể dẫn đến các quyết định sai lầm và lãng phí nguồn lực.
Sự minh bạch là một trong ba nguyên tắc cốt lõi của Scrum. Nói về sự minh bạch, Scrum Guide 2020 đề cập một cách ngắn gọn:
Sự minh bạch (Scrum Guide 2020)
"Quy trình và công việc mới phải được những người thực hiện công việc cũng như những người nhận công việc nhìn thấy".
Có thật sự, tính minh bạch chỉ yêu cầu đơn giản như vậy?
Theo tôi, đặc tính "được nhìn thấy" ở đây là không đủ để mô tả về sự minh bạch và rất dễ gây hiểu nhầm. Việc Product Owner luôn cập nhật yêu cầu mới của khách hàng vào Jira Backlog thì có đảm bảo tính minh bạch của Product Backlog? hay trạng thái công việc luôn được cập nhật đầy đủ bởi Developers có đảm bảo tính minh bạch của Sprint Backlog?
Quay lại với bản Scrum Guide 2017, nguyên văn phần giải thích về sự minh bạch như sau:
Sự minh bạch (Scrum Guide 2017)
Các khía cạnh quan trọng của quy trình phải được những người chịu trách nhiệm về kết quả nhìn thấy. Tính minh bạch đòi hỏi các khía cạnh đó phải được định nghĩa theo một tiêu chuẩn chung để những người quan sát có cùng hiểu biết về những gì đang được nhìn thấy.
Theo tôi, định nghĩa sự minh bạch trên đây mới đầy đủ. Rất tiếc, có hai ý rất quan trọng khi nói về sự minh bạch trong bản Scrum 2017 đó là "các khía cạnh quan trọng của quy trình" và "sự hiểu biết chung" đã bị bỏ đi trong bản Scrum Guide 2020. Liệu có phải đây là sự tiến hóa ngược của Scrum Guide? Trong khi cố gắng tinh gọn bớt từ ngữ để tăng sự linh hoạt, Scrum Guide 2020 đã làm mất đi ý nghĩa đầy đủ của sự minh bạch.
Tới đây, nếu bạn vẫn còn phân vân về ý nghĩa thật sự của tính minh bạch trong Scrum hay Agile nói chung, xin hãy đọc tiếp phần phân tích bên dưới.
Viện Rủi ro Tài chính Quốc tế gọi tắt là IFRI có trụ sở tại Geneve Thụy Sỹ đưa ra 05 đặc tính cần có của thông tin để đảm bảo tính minh bạch trong lĩnh vực tài chính, ngân hàng. 05 đặc điểm đó là:
Tất cả các đặc điểm trên nhằm tạo điều kiện thuận lợi để người sử dụng thông tin đưa ra những quyết định có giá trị.
Đễ dễ hình dung, lấy ví dụ các công ty niêm yết trên thị trường chứng khoán phải cam kết minh bạch thông tin thông qua việc công bố báo cáo tài chính đầy đủ đúng hạn, báo cáo kiểm toán độc lập (đảm bảo tính tin cậy), cập nhất kết quả lợi nhuận bất thường, thay đổi thành viên hội đồng quản trị, ... Tất cả điều này nhằm đảm bảo nhà đầu tư có đầy đủ thông tin quan trọng, kịp thời được trình bày rõ ràng, có tính so sánh để giúp nhà đầu tư ra quyết định.
Các yêu cầu về tính minh bạch thông tin ở trên hoàn toàn áp dụng được cho nhóm phát triển sản phẩm Scrum. Ví dụ, để duy trì tính minh bạch của Product Backlog, nhóm Scrum cần đảm bảo các điều sau đây:
Sau cùng, tất cả các yếu tố trên nhằm tạo điều kiện để nhóm Scrum dễ dàng quyết định các hạng mục cần làm trong Sprint và xác định mục tiêu Sprint!
Có thể thấy, thông tin nếu được hiển thị đầy đủ với các bên liên quan nhưng thiếu một 5 trong các thuộc tính trên vẫn bị coi là chưa đủ minh bạch. Tuy nhiên, sự minh bạch trong tổ chức Agile hay nhóm làm việc Scrum còn yêu cầu nhiều hơn thế!
Scrum là quy trình dựa trên thực nghiệm, kết quả là quan trọng nhưng kinh nghiệm học được cũng quan trọng không kém. Sự hiểu biết về hệ thống cùng với chu kỳ thanh tra, thích nghi thường xuyên sẽ giúp nhóm Scrum liên tục cải tiến và thích ứng kịp thời. Ví dụ, DoD giúp cho nhóm Scrum "thấy" được các bước cần thiết tạo ra phần tăng trưởng sản phẩm. Điều này là cần thiết để Developers có thể xác định khi nào là "hoàn thành". Các bước quan trọng của một "Value Stream" cần được nhìn thấy bởi các cá nhân liên quan để tạo điều kiện cho sự phối hợp diễn ra.
Định nghĩa hoàn thành (DoD) giúp đảm bảo sự minh bạch cho phần tăng trưởng sản phẩm
Cũng cần lưu ý, để tránh lãnh phí thời gian vào việc xây dựng và hiển thị quá nhiều thứ liên quan đến quy trình (cái không mang lại giá trị cho khách hàng), Agile/Scrum chỉ yêu cầu ở mức độ "các khía cạnh quan trọng của quy trình". Ví dụ, Scrum không khuyến khích xây dựng DoD cho hạng mục công việc vì nó quá chi tiết và không mang lại nhiều giá trị mà chỉ yêu cầu DoD ở cấp độ phần tăng trưởng sản phẩm - phần mang tới giá trị cho khách hàng.
Khi làm việc với các mô tả chức năng phức tạp, các đo lường kiểu định tính, thông tin dù được hiển thị rõ ràng tới mấy cũng khó được hiểu giống nhau. Sẽ không có một kỹ thuật mô tả hay công cụ nào giúp đạt được điều này nếu không có sự giao tiếp thường xuyên giữa các thành viên trong tổ chức.
Chính vì vậy, Agile/Scrum coi trọng giao tiếp thường xuyên, thông qua các sự kiện được lặp lại để thúc đẩy sự hợp tác, chia sẻ, giúp tăng cường tính minh bạch. Ví dụ, Daily Scrum diễn ra hàng ngày để các Developers có hiểu biết chung về tiến độ của công việc. Sprint Planning giúp Product Owner và Developers có hiểu biết chung về những hạng mục ưu tiên cho Sprint. Retrospective để các thành viên trong nhóm có hiểu biết chung về yếu tố cản trở đến hiệu suất của nhóm hoặc chất lượng sản phẩm. Các cuộc họp "Review" giúp nhóm phát triển, khách hàng và các bên liên quan có hiểu biết chung về kỳ vọng của khách hàng và các giá trị mà nhóm Agile/Scrum đang cung cấp.
"Daily Scrum"/ "Stand-up"/ "Hurdle" giúp đảm bảo sự hiểu biết giống nhau giữa các thành viên trong nhóm
Thông tin được cập nhật và đầy đủ, kịp thời; các khía cạnh quan trọng của quy trình phải được nhìn thấy; sự hiểu biết chung về những gì đang diễn ra là 03 khía cạnh cần thiết để đảm bảo tính mình bạch trong một tổ chức Agile. Hai yếu tố đầu tiên tạo điều kiện thuận lợi chứ chưa đủ. Để có sự hiểu biết chung về những gì đang diễn ra kịp thời, đòi hỏi một thiết kế tổ chức phù hợp, sự hiện diện của các nhóm được trao quyền và giao tiếp thường xuyên.
Hy vọng bài viết trên đây có thể giúp các bạn hiểu rõ hơn về sự minh bạch và tầm quan trọng của nó trong tổ chức Agile.
