Trong sự kiện của AgileVietnam tại Hà Nội tháng 5 vừa qua, những người tham dự đã được nghe anh Phạm Mạnh Lân – co-founder của NAL Group – chia sẻ về quá trình chuyển đổi Agile tại công ty mình. Đây là một chủ đề thu hút được sự quan tâm của khá nhiều người bởi vì hiện tại có rất nhiều cá nhân và tổ chức đang tìm cách tiếp cận Agile/Scrum. Ngoài ra, NAL cũng có quy mô và đặc điểm khá tương đồng với nhiều công ty khác cùng lĩnh vực.
NAL Group là một startup với tuổi đời 3 năm, bao gồm 4 công ty hoạt động trong lĩnh vực gia công phần mềm (outsourcing). NAL có trụ sở tại Việt Nam và Nhật bản với tổng cộng khoảng 130 nhân viên. Doanh thu năm 2015 đạt 1,5 triệu USD, tăng gấp đôi mỗi năm.
Áp dụng Agile
Cách đây hơn 1 năm, NAL phải đưa ra quyết định thay đổi, xuất phát từ những khó khăn trong kinh doanh và sản xuất. Có quá nhiều biến động của thị trường và môi trường sản xuất mà công ty không lường trước được. Theo như lời anh Lân thì “kế hoạch kinh doanh và thực tiễn không khớp với nhau chút nào”. Dẫn chứng trường hợp thị trường Nhật Bản, trong khi tình hình các dự án outsourcing của thị trường Nhật Bản có xu hướng chững lại thì Nhật Bản dành quyền đăng cai Thế vận hội Olympic mùa hè 2020, điều này hứa hẹn một làn sóng đầu tư rất lớn và là cơ hội cho rất nhiều công ty đang làm ăn ở thị trường này. Nhưng sau đó một thời gian, bất ngờ có thông tin bê bối liên quan đến việc hối lộ để giành quyền đăng cai Olympic, vậy là các kế hoạch kinh doanh liên quan đến thị trường này đều phải suy tính lại.
Dẫn chứng của NAL chỉ là một trong số rất nhiều những tình huống mà chúng ta dễ dàng quan sát được trong thế giới nhiều biến động như ngày nay. Đây cũng là một yếu tố quan trọng cần xem xét để trả lời cho câu hỏi: Khi nào Agile, khi nào không?
Từ nhu cầu thay đổi đó, NAL đã quyết định thực hiện chuyển đổi theo hướng áp dụng Agile/Scrum. Sau 1 năm, cấu trúc và hoạt động của công ty đã có những thay đổi đáng kể.
Mô hình Agile/Scrum ở NAL
Theo chia sẻ của anh Lân, NAL đang tổ chức công ty theo hướng phẳng với hai phần là phần tĩnh và phần động. Phần tĩnh bao gồm các nhóm sản xuất hoạt động theo khách hàng và phần động là các nhóm sinh hoạt dưới dạng không gian chia sẻ tri thức hay câu lạc bộ.
Cấu trúc của NAL
Với cấu trúc như vậy, các hoạt động được thực hiện theo role, một cá nhân sẽ hành động khác nhau khi đứng vào các role khác nhau.
“Hoạt động Agile diễn ra ở nhiều cấp độ khác nhau, từ việc thiết lập tầm nhìn cho đến xây dựng chiến lược phát triển, triển khai sản xuất và đồng bộ công việc hằng ngày” – anh Lân chia sẻ.
Hình thức tổ chức các nhóm phát triển như vậy là khác so với hình thức tổ chức các nhóm theo dự án khá phổ biến ở nhiều công ty. Ở các nhóm dự án, khi bắt đầu một dự án mới thì công ty sẽ huy động nhân lực từ những nơi khác nhau để thành lập một nhóm phục vụ dự án đó. Sau khi dự án kết thúc thì nhóm đó cũng kết thúc sứ mệnh của mình và các thành viên sẽ tham gia vào các nhóm dự án khác. Mô hình các nhóm phát triển ổn định thì hoạt động theo cách khác, các nhóm này tương đối ổn định về mặt nhân sự và tồn tại lâu dài mà không phụ thuộc vào vòng đời của các dự án. Khi có dự án mới thì nó sẽ được đẩy về cho một nhóm nào đó phù hợp chứ không thành lập một nhóm mới. Mô hình này có nhiều ưu điểm so với mô hình cũ, quan trọng nhất đó là nó duy trì sự ổn định lâu dài ở các nhóm, từ đó đảm bảo được hiệu quả sản xuất của nhóm.
Song song với việc chia sẻ tình hình hiện tại của công ty, co-founder của NAL cũng không ngần ngại khi nói đến những bài học mà mình đã trải qua.
Những bài học của NAL khi áp dụng Agile
Sai lầm lớn nhất theo lời của anh Lân đó là “tiềm thức của lãnh đạo cho rằng việc thúc đẩy Agile chỉ diễn ra ở đâu đó, là việc của một ai đó chứ không phải là do mình”. Trong khi đó, trên thực tế cách tiếp cận tốt nhất và thuận lợi nhất chính là có được quyết tâm của lãnh đạo trong việc thực hiện chuyển đổi. Thiếu đi yếu tố quan trọng này thì việc chuyển đổi sẽ gặp rất nhiều khó khăn, nếu không muốn nói là nguy cơ thất bại gần như là đã biết trước được.
Ngoài ra, theo như Ken Schwaber và Jeff Sutherland đề cập trong cuốn “Software in 30 days” thì việc chuyển đổi Agile ở cấp độ tổ chức đòi hỏi phải có nguồn lực, quyết tâm và đặc biệt là cam kết của lãnh đạo. Chẳng hạn như trong trường hợp của Microsoft hoặc Salefore.com.
Một sai lầm nữa mà NAL đã mắc phải đó là cho rằng đã là Agile thì không cần kỷ luật, Agile tức là linh hoạt, có nghĩa là thế nào cũng được. Đây quả là một sự lầm tưởng tai hại, mà cho đến nay vẫn có rất nhiều người đang lầm tưởng như vậy. Trên thực tế, khả năng linh hoạt trong Agile không phải tự nhiên mà có, mà đó là kết quả của việc tuân thủ kỷ luật để đảm bảo guồng máy hoạt động một cách thông suốt và ổn định nhất.
Thực ra, các “quy tắc” của Agile/Scrum không nhiều, nếu không muốn nói là khá ít. Và bởi vì ít như vậy cho nên việc tuân thủ các quy tắc đó là điều cần thiết để đạt được hiệu quả. Ví dụ như, việc đóng khung 15 phút của buổi Scrum Hằng ngày là quan trọng và cần phải tuân thủ để không mất nhiều thời gian của nhóm và đạt được mục đích là cập nhật và đồng bộ công việc. Để làm được điều đó thì cần tuân thủ nội dung của buổi Scrum Hằng ngày đơn giản chỉ là trả lời 3 câu hỏi: (1) “Tôi đã làm được gì?”, (2) “Tôi sẽ làm gì?”, và (3) “Tôi gặp phải những khó khăn nào?”.
Và cũng bởi vì có ít quy tắc cho nên việc tuân thủ chúng cũng không phải là quá khó khăn. Điều quan trọng là cần phải hiểu rõ mục đích thực sự của từng quy tắc/kỹ thuật để thực hiện đúng cách. Tiếp theo đó là biến chúng thành thói quen để việc tuân thủ diễn ra một cách tự nhiên, không mất nhiều công sức.
Cũng theo chia sẻ của anh Lân, một sai lầm nữa mà NAL mắc phải đó là xem nhẹ việc đo đạc trong tất cả các hoạt động. Đây có lẽ là điểm yếu của rất nhiều công ty, nhất là ở những công ty mà việc đưa ra các quyết định là chủ yếu dựa trên các nhận định mang tính cảm tính của lãnh đạo.
Một cách tiếp cận khoa học hơn trong việc ra các quyết định đó là dựa trên dữ liệu (data-driven), tức là phải đo đạc rất nhiều, tìm cách đánh giá các hoạt động theo các tiêu chí có thể đo được. Đối với Agile/Scrum, điều này là thực sự cần thiết bởi vì Agile/Scrum thực ra là hoạt động điều chỉnh liên tục, mà muốn điều chỉnh được tốt thì chúng ta phải đo đạc để có đầy đủ những dữ liệu cần thiết về các hoạt động của mình. Chẳng hạn, năng suất làm việc của nhóm thì đo như thế nào? Chất lượng của sản phẩm thì đo như thế nào? Độ hài lòng của khách hàng thì đo như thế nào? Độ hài lòng của nhân viên thì đo như thế nào? v.v…
Và cuối cùng, một sai lầm nữa ở NAL được nêu ra đó là ở giai đoạn đầu họ áp dụng Agile/Scrum một cách mang tính hình thức. Tức là cố gắng tổ chức các nhóm, triển khai các sự kiện theo mô tả của Scrum nhưng không thực sự hiểu và đạt đến được mục đích thực sự của các kỹ thuật đó. Do không có sự am hiểu về ý nghĩa của từng hoạt động được triển khai nên chúng chỉ mang tính bề nổi, không mang lại hiệu quả thực sự để giải quyết vấn đề của nhóm. “Tưởng có Nhóm Scrum thì đã là Scrum rồi, tưởng gọi tên là Agile thì đã là Agile rồi” – anh Lân nói. Và cũng xuất phát từ tư duy đó, NAL đã tốn rất nhiều thời gian và tài nguyên dành cho việc mở rộng các Nhóm Scrum, “cố gắng xây dựng các nhóm 20 người, hơn 20 người, và nhanh chóng xây dựng được nhiều Nhóm Scrum”, trong khi đó lại không tập trung vào xây dựng chất lượng cho các nhóm ngay từ đầu, không chú trọng vào việc “làm thế nào để Agile cho được tốt”.
Và những kết quả đạt được ban đầu
Mặc dù đã gặp phải nhiều khó khăn, nhưng có thể nói là NAL đã bước đầu đạt được những thành công nhất định trong quá trình chuyển đổi của mình.
Cụ thể nhất đó là việc thúc đẩy được tính tự chủ của các cá nhân và đội nhóm trong công việc. Đây là tiền đề cần thiết để xây dựng được những nhóm tự tổ chức hoạt động hiệu quả cao.
Cùng với đó, mô hình các không gian học tập, chia sẻ tri thức đã bắt đầu phát huy hiệu quả, thúc đẩy tinh thần học tập trong từng cá nhân, đội nhóm và trong cả tổ chức. Đây là bước đầu tiên trong lộ trình “hướng đến xây dựng một tổ chức học tập” – như lời chia sẻ của anh Lân.
Một thành quả nữa của NAL đã đạt được đó là xây dựng được một lộ trình phát triển nghề nghiệp cho nhân viên, kèm với việc tư vấn và hỗ trợ các cá nhân tự quyết định hướng phát triển của mình. Đây là một chiến lược rất đúng đắn và phù hợp khi hướng sự quan tâm đến một nhân tố cốt lõi của một tổ chức đó là “con người”. Đây cũng là yếu tố được nhắc đến đầu tiên trong bản Tuyên ngôn Agile.
Câu chuyện Agile của NAL đã đóng góp thêm cho chúng ta một góc nhìn nữa về giai đoạn đầu của quá trình chuyển đổi Agile ở một công ty phần mềm – với đặc thù outsourcing khá phổ biến hiện nay. Hy vọng trong tương lai chúng ta sẽ có thêm nhiều chia sẻ nữa từ những nơi khác cũng đang tiến hành sự chuyển đổi mang tính chất chiến lược này.
