- 0908106080/ 0969182526
- bittrain@bittrain.coach
Một ngân hàng mất 3 tuần để phát triển một tính năng Mobile Banking.
Nhưng mất thêm 4 tháng để được triển khai Production.
Agile có thực sự là vấn đề?
Hay tổ chức đang gặp một loại "nợ" khác mà rất ít doanh nghiệp nhận ra?
Trong những năm gần đây, nhiều ngân hàng đã đầu tư mạnh vào Agile Transformation, xây dựng Digital Factory, triển khai Product Operating Model và đào tạo SAFe® nhằm rút ngắn thời gian đưa sản phẩm ra thị trường.
Tuy nhiên, thực tế tại nhiều tổ chức cho thấy một nghịch lý:
Một tính năng trên Mobile Banking chỉ mất vài tuần để phát triển, nhưng có thể mất thêm nhiều tháng để hoàn tất các bước kiểm thử, bảo mật, phê duyệt và triển khai.
Điểm nghẽn không nằm ở Scrum Team.
Điểm nghẽn nằm ở dependency giữa các khối CNTT, An toàn thông tin, Kiến trúc, Hạ tầng và Vận hành.
Qua kinh nghiệm đồng hành với nhiều doanh nghiệp và đối chiếu với các thực tiễn quốc tế, BitTrain nhận thấy điểm nghẽn thường xuất phát từ các dependency giữa Product Team và các nhóm hỗ trợ như Platform Engineering, Security, Infrastructure, Enterprise Architecture hay Data Platform.
Bài viết này phân tích vì sao dependency trở thành rào cản lớn trong chuyển đổi Agile, vai trò của Enabling Teams trong SAFe® và một số câu hỏi giúp lãnh đạo đánh giá lại mô hình vận hành của tổ chức.
Một Product Team hoàn thành User Story trong Sprint không có nghĩa là tính năng đó đã sẵn sàng đến tay khách hàng.
Trong thực tế, trước khi một tính năng được phát hành, nhóm phát triển thường phải làm việc với nhiều đơn vị khác:
Mỗi điểm phối hợp đều có thể làm phát sinh thời gian chờ. Khi các điểm phụ thuộc này tích lũy, chúng có thể tạo thành các nút thắt cổ chai (bottlenecks), tốc độ tạo ra giá trị bị ảnh hưởng dù Product Team vẫn làm việc đúng quy trình Agile.
Nếu mục tiêu của Agile là rút ngắn thời gian từ ý tưởng đến giá trị (Idea to Value), thì việc giảm dependency cũng quan trọng không kém việc tối ưu Sprint Planning hay Sprint Review.
Nhiều tổ chức tài chính trên thế giới đã đối mặt với bài toán tương tự khi mở rộng Agile.
Một ví dụ được chia sẻ công khai bởi Agile By Design là hành trình của Scotiabank. Thay vì chỉ tập trung nâng cao năng lực Product Team, tổ chức này cũng xem xét lại cách các nhóm hỗ trợ kỹ thuật phối hợp với đội phát triển.
Điểm đáng chú ý là tư duy chuyển từ "Service Provider" sang "Enabling Teams". Đây là một góc nhìn đáng tham khảo đối với các doanh nghiệp đang mở rộng Agile ở quy mô lớn.
Qua các chương trình Agile Coaching và tư vấn chuyển đổi, chúng tôi nhận thấy nhiều doanh nghiệp vô tình tối ưu từng bộ phận, thay vì tối ưu dòng chảy giá trị (Flow of Value).
Ví dụ:
Mỗi nhóm đều đạt KPI của mình, nhưng tổng thời gian đưa một tính năng đến khách hàng vẫn kéo dài.
Đây là dấu hiệu cho thấy tổ chức đang tối ưu cục bộ thay vì tối ưu toàn hệ thống.
Trong Agile ở quy mô doanh nghiệp, câu hỏi quan trọng không phải là:
"Đội nào làm việc hiệu quả nhất?"
Mà là:
"Điều gì đang làm chậm dòng chảy giá trị từ ý tưởng đến khách hàng?"
Ở nhiều tổ chức, các nhóm Platform, Security hoặc Infrastructure hoạt động theo mô hình Service Provider: nhận yêu cầu, xử lý và bàn giao kết quả.
Mô hình này giúp kiểm soát tốt nhưng cũng dễ tạo ra hàng đợi khi số lượng Product Team tăng lên.
Một cách tiếp cận khác là phát triển các Enabling Teams.
Thay vì làm thay Product Team, Enabling Teams tập trung vào:
Khi đó, vai trò của nhóm hỗ trợ không còn là "nơi nhận ticket", mà trở thành "đối tác phát triển năng lực" cho toàn bộ tổ chức.
Đối với các ngân hàng đang triển khai SAFe®, khái niệm Enabling Teams là một cách tiếp cận đáng chú ý.
Thay vì trở thành "đầu mối xử lý yêu cầu", các nhóm Platform, Architecture hoặc DevSecOps sẽ đồng hành cùng Agile Release Train để chia sẻ năng lực, giảm dependency và giúp Product Team có thể tự triển khai nhiều công việc hơn.
Đây cũng là một trong những nội dung được BitTrain đưa vào các chương trình Leading SAFe® và SAFe POPM®, đặc biệt khi làm việc với các doanh nghiệp có quy mô lớn và nhiều Agile Teams.
Trước khi lựa chọn framework hay tái cấu trúc tổ chức, BitTrain khuyến nghị đánh giá năm nhóm dependency quan trọng:
Đánh giá các dependency này giúp doanh nghiệp nhìn thấy những điểm nghẽn trước khi đầu tư thêm vào công cụ hoặc framework.
Nếu phần lớn câu trả lời là "chưa", có thể tổ chức đang cần nhìn lại mô hình vận hành, thay vì chỉ đầu tư thêm vào quy trình hoặc công cụ.
Tại BitTrain, chúng tôi nhìn Agile Coaching theo góc độ rộng hơn.
Một chương trình chuyển đổi thành công không chỉ dừng ở việc triển khai Scrum hay đào tạo SAFe®, mà còn bao gồm:
Đó cũng là lý do các chương trình Leading SAFe®, SAFe POPM® và Agile Coaching luôn gắn với các bài toán thực tế của doanh nghiệp, thay vì chỉ tập trung vào framework.
Mục tiêu cuối cùng của mọi chương trình chuyển đổi là giúp doanh nghiệp đưa giá trị đến khách hàng nhanh hơn, an toàn hơn và bền vững hơn.
Muốn làm được điều đó, Product Team thôi là chưa đủ.
Toàn bộ hệ thống – từ Platform, Security, Architecture đến Leadership – đều cần được thiết kế để cùng hướng tới một mục tiêu chung: tăng tốc dòng chảy giá trị.
Nếu doanh nghiệp của bạn đang gặp các dấu hiệu như:
đó có thể là lúc doanh nghiệp cần nhìn lại mô hình vận hành thay vì chỉ bổ sung thêm công cụ hay quy trình.
BitTrain đồng hành cùng doanh nghiệp thông qua các chương trình Agile Health Check, Agile Coaching, Leading SAFe®, SAFe POPM® và tư vấn Agile Transformation, giúp tổ chức xác định đúng điểm nghẽn và xây dựng lộ trình chuyển đổi phù hợp với bối cảnh doanh nghiệp Việt Nam.
