Facebook đến Microsoft: Agile Theo Cách Riêng

Vào giữa những năm 2000, Agile trở thành một làn sóng bùng nổ trong giới công nghệ. Các doanh nghiệp ở mọi quy mô đều cử đội ngũ đi đào tạo Scrum, cải tổ quy trình làm việc để áp dụng sprint, stand-up và user story. Tuy nhiên, một hiện tượng lạ đã xuất hiện: những công ty công nghệ hàng đầu thế giới như Facebook, Apple, Amazon, Netflix, Google và Microsoft lại không triển khai rộng rãi các framework Agile như phần lớn các doanh nghiệp khác.

Điều này không phải vì họ thiếu hiểu biết hay cố chấp. Thực tế, các công ty này đã sớm xây dựng được văn hóa kỹ thuật, quy trình làm việc và cấu trúc tổ chức riêng biệt, vốn đã đạt được những mục tiêu cốt lõi của Agile, thậm chí còn vượt xa mà không cần phải áp dụng một cách chính thức các khuôn khổ của Agile.

Trong khi vô số công ty nỗ lực “trở nên Agile hơn”, thì những gã khổng lồ công nghệ lại là những ngoại lệ nổi bật.

Một khảo sát nội bộ tại Microsoft từ 2012 - 2018 tiết lộ rằng “mặc dù chịu áp lực lớn từ thị trường, tốc độ áp dụng Agile tại Microsoft vẫn chậm hơn kỳ vọng”. Tại nhiều công ty công nghệ lớn, các đội ngũ vẫn có thể deliver sản phẩm nhanh chóng mà không cần phải tự xưng là đang làm Agile.

Facebook: Đi nhanh ở quy mô lớn (mà không cần Sprint)

Ngay từ những ngày đầu, phương châm của Facebook là “Move fast and break things”. Tốc độ chính là lợi thế cạnh tranh, và quy trình kỹ thuật của Facebook được phát triển để tối đa hóa tốc độ phát triển của lập trình viên. Điều thú vị là Facebook chưa bao giờ triển khai các team Scrum chính thức trên toàn công ty.

Không có các sprint hai tuần đồng bộ toàn tổ chức, cũng không có việc các Product Manager ngồi viết Jira ticket cho kỹ sư. Ngược lại, các kỹ sư gần như tự quản lý công việc của mình trong một luồng làm việc liên tục (continuous flow). Một cựu Product Manager của Facebook từng chia sẻ: “Chúng tôi cũng không dùng sprint… Kỹ sư tự chịu trách nhiệm quản lý dự án và tự tạo ra đầu việc của mình.” (blog.pragmaticengineer.com)

Facebook đạt được khả năng delivery nhanh và tăng dần nhờ vào một hệ thống CI/CD (Continuous Integration/Continuous Deployment) mạnh mẽ, chứ không phải nhờ vào các quy trình Scrum.

Thực tế, trong nhiều năm, Facebook đẩy code lên site ba lần mỗi ngày, hoàn toàn khác biệt với nhịp điệu Scrum “mỗi hai tuần có một bản có thể deliver (shippable increment)”. Kỹ sư commit code lên nhánh master, hệ thống tự động sẽ chạy hàng ngàn bài test. Nếu mọi kiểm tra đều vượt qua, code sẽ được đẩy ra production trong một trong các đợt phát hành trong ngày. Đến năm 2016, Facebook thậm chí còn tiến thêm một bước: chuyển sang mô hình triển khai gần như liên tục (quasi-continuous deployment), code được đẩy trực tiếp từ master đến người dùng nhiều lần mỗi ngày.

Với hạ tầng như vậy, các team tại Facebook có thể điều chỉnh linh hoạt theo thời điểm. Họ không cần phải lên kế hoạch 10 ngày làm việc rồi “khóa cứng” vào một sprint, họ triển khai bất cứ khi nào code đã sẵn sàng.

Nói cách khác, Facebook thể hiện sự “agile” (chữ a thường) thông qua văn hóa và công cụ, chứ không cần đến Scrum Master hay story point để tăng tốc. Họ đã xây dựng một hệ thống mà tốc độ và khả năng lặp lại là kết quả tự nhiên của cách làm việc.

Apple: Văn hoá lấy sản phẩm làm trung tâm đã vượt khỏi Agile

Apple nổi tiếng với sự kín tiếng và tinh thần tập trung cao độ vào việc tạo ra những sản phẩm tuyệt vời. Dù ít có tài liệu công khai nào mô tả quy trình phát triển nội bộ của Apple (họ không có blog kỹ thuật hay case study về Agile), nhưng những gì chúng ta biết cho thấy Apple có một cấu trúc tổ chức rất khác biệt so với phần lớn các công ty khác.

Apple tổ chức theo cấu trúc chức năng (functional) thay vì theo phòng ban (division), nghĩa là các chuyên gia dẫn dắt chuyên gia, và các nhóm dự án liên chức năng sẽ được hình thành xoay quanh từng sản phẩm cụ thể. Đồng thời, trong văn hoá của Apple tồn tại sự hoài nghi sâu sắc đối với bất kỳ điều gì làm phân tâm khỏi chất lượng sản phẩm, điều này có thể bao gồm cả những quy trình nặng nề như Agile.

Cá nhân tôi rất tâm đắc với triết lý trên, tôi thường xuyên áp dụng sự hoài nghi sâu sắc nếu chất lượng sản phẩm không được đảm bảo.

Steve Jobs, đồng sáng lập quá cố của Apple, từng cảnh báo về việc sùng bái quy trình mà quên mất kết quả. Trong một cuộc phỏng vấn, ông nói: “Mọi người dễ bị nhầm lẫn… họ bắt đầu tin rằng có điều kỳ diệu nào đó nằm trong quy trình… rồi dần dần họ đánh đồng quy trình chính là điều quan trọng nhất. Chúng tôi từng có rất nhiều người giỏi quản lý quy trình… nhưng họ lại hoàn toàn không hiểu giá trị cốt lõi mà sản phẩm cần có. Và chính điều đó mới làm nên một sản phẩm tuyệt vời. Không phải quy trình. Mà là giá trị thực sự bên trong.”

Quy trình chỉ hữu ích nếu nó giúp người giỏi tạo ra sản phẩm tốt hơn; còn nếu không, quy trình không phải là giải pháp thần kỳ.

Phong cách phát triển sản phẩm tại Apple phản ánh đúng triết lý đó. Các team vận hành giống như một startup đang theo đuổi tầm nhìn lớn (ví dụ: thế hệ iPhone hoặc macOS mới), hơn là những team Scrum đang thực thi từng tính năng nhỏ theo sprint. Công việc tại Apple thường được điều phối bởi những “DRI” (Directly Responsible Individuals - Người chịu trách nhiệm trực tiếp), một cơ chế đảm bảo rõ ràng trách nhiệm cho từng đầu việc hoặc quyết định. Thay vì daily stand-up hay backlog, phần lớn sự phối hợp tại Apple diễn ra qua những buổi design session chuyên sâu và review sản phẩm với các cấp lãnh đạo.

Apple cũng nổi tiếng với việc liên tục prototype và lặp đi lặp lại trên cả phần cứng lẫn phần mềm, cho đến khi đạt độ hoàn thiện cực cao, quá trình này có thể kéo dài hàng năm, chứ không giới hạn trong các sprint hai tuần. Tất cả đều diễn ra dưới mức độ bảo mật rất nghiêm ngặt, và chỉ được công bố khi sản phẩm đã sẵn sàng ra mắt ấn tượng.

Họ chẳng cần “sửa” điều gì cả, vì cách làm của họ đã vượt trội so với đối thủ, tập trung tuyệt đối vào chất lượng kết quả, thay vì hình thức quy trình.

Netflix: Tự do và Trách nhiệm thay cho Quy trình

Netflix lại chọn một con đường khác nhưng cũng hiệu quả không kém: xây dựng một văn hóa mạnh đến mức quy trình chính thức gần như không còn cần thiết. Bộ slide văn hóa nổi tiếng của Netflix – “Freedom & Responsibility” đã nêu rất rõ: Netflix cố gắng tuyển người giỏi nhất, trả lương cao nhất thị trường, định hướng họ theo tầm nhìn cấp cao của công ty, rồi để họ tự làm phần việc của mình. Nếu triết lý của Agile là tin tưởng vào team và cá nhân, thì Netflix có lẽ đã đưa tinh thần đó đến cực điểm.

Một trong những giá trị cốt lõi tại Netflix là: “Con người hơn Quy trình” (People over Process). Chính Netflix từng tuyên bố: “Kết quả sẽ tốt hơn khi nhân viên có đủ thông tin và sự tự do để tự ra quyết định.”

Trong thực tế, các kỹ sư và PM tại Netflix vận hành với quyền tự chủ rất lớn. Không có framework quản lý dự án chuẩn mực nào bắt buộc áp dụng cho tất cả nhóm. Một số nhóm sử dụng quy trình tương tự Kanban, nhóm khác có thể chạy sprint nhẹ, nhưng nhìn chung, Netflix ưu tiên phát hành liên tục (continuous delivery). Netflix chính là nơi khởi xướng khái niệm “full-cycle developers”, kỹ sư không chỉ viết code mà còn chịu trách nhiệm triển khai, theo dõi, và vận hành trực tiếp code đó trong môi trường production. Điều này loại bỏ nhu cầu chuyển giao giữa các bộ phận hay các hình thức lên kế hoạch phức tạp.

Theo blog kỹ thuật của Netflix, mục tiêu của mô hình full ownership này là “tối ưu hóa thời gian tạo ra giá trị (time to value)” , tức là biến ý tưởng thành sản phẩm có ích cho khách hàng nhanh nhất có thể. Đây cũng chính là mục tiêu của Agile, nhưng Netflix đạt được điều đó nhờ văn hóa, không cần quy trình bắt buộc.

Nhờ đặt niềm tin vào đội ngũ nhân sự chất lượng cao, Netflix đạt được mức độ linh hoạt vượt trội, nơi các quyết định được đưa ra nhanh chóng và việc triển khai cũng diễn ra ngay lập tức. Khi có điều gì đó không hiệu quả, các nhóm tại Netflix không tổ chức những buổi retro phức tạp hay bổ sung thêm quy tắc ràng buộc. Thay vào đó, họ nhanh chóng điều chỉnh và chia sẻ lại kinh nghiệm với nhau một cách tự nhiên, cởi mở. Văn hóa “phân tích sau sự cố mà không đổ lỗi” cũng được áp dụng tại Google và một số công ty tiên phong khác, giúp Netflix học hỏi từ sai lầm mà không tạo ra thêm những rào cản khiến sáng tạo bị kìm hãm.

Nghe có thể hơi gây tranh cãi, nhưng có thể nói Netflix thành công vì họ “phản quy trình” (anti-process). Một tập đoàn truyền thống thiếu mật độ nhân tài và văn hóa có thể rơi vào hỗn loạn nếu cho quá nhiều tự do, nhưng ở Netflix, điều đó lại hiệu quả. Họ từng khẳng định: “Giảm thiểu quy tắc và quy trình, đồng thời trao quyền tự do cho nhân sự chất lượng cao, là công thức vượt trội hơn rất nhiều cho thành công lâu dài.”

Google: Mở rộng đổi mới thông qua văn hóa, không phải Scrum

Google, giống như các ông lớn công nghệ khác, đã tăng trưởng bùng nổ trong những năm 2000, nhưng nếu bạn bước vào Googleplex thời đó, sẽ hiếm thấy những bảng Scrum treo đầy tường. Thành công của Google được xây dựng dựa trên nền tảng kỹ thuật vững chắc (tuyển dụng lập trình viên xuất sắc, áp dụng quy trình kiểm tra và review code nghiêm ngặt) cùng một văn hóa khuyến khích đổi mới. Google đón nhận sự "linh hoạt" (agility) như một tính từ, chứ không phải một phương pháp chính thức.

Nhiều nhóm tại Google sử dụng OKRs (Objectives and Key Results) để đặt mục tiêu theo quý, công cụ này giúp duy trì sự tập trung mà không áp đặt cách làm cụ thể. Trong thực tiễn hằng ngày, quá trình phát triển sản phẩm của Google là sự pha trộn giữa quyết định dựa trên dữ liệu, thử nghiệm nhanh, và cải tiến liên tục.

Với Google, điều quan trọng là kết quả, lặp lại nhanh, hợp tác hiệu quả, triển khai nhanh, chứ không phải tên gọi của quy trình.

Văn hóa tại Google khuyến khích ý tưởng đi từ dưới lên: nhiều sản phẩm nổi tiếng bắt đầu từ dự án thử nghiệm hoặc sản phẩm phụ do kỹ sư tự nghĩ ra (Gmail và AdSense là ví dụ điển hình). Google mô tả họ có một “văn hóa tự chủ và đổi mới từ gốc rễ, nơi những người gần với vấn đề nhất là những người thúc đẩy ý tưởng mới.” Các nhóm có nhiều quyền tự quyết trong cách làm việc, miễn là họ mang lại kết quả. Có nhóm dùng Scrum hoặc Kanban, nhóm khác thì linh hoạt hơn. Nhưng chưa bao giờ có mệnh lệnh từ lãnh đạo yêu cầu “phải làm Agile đúng sách vở.”

Điều mà Google có là hệ thống công cụ nội bộ hàng đầu, giúp hiện thực hóa các nguyên tắc phát triển nhanh giống Agile. Toàn bộ codebase của Google nằm trong một repository đơn khối (monorepo), truy cập được bởi tất cả kỹ sư, kèm theo hệ thống build và test tự động (Blaze) chạy trên hàng ngàn máy. Hạ tầng như vậy cho phép kỹ sư liên tục tích hợp thay đổi và nhận phản hồi cực nhanh, từ lâu trước khi CI/CD trở thành tiêu chuẩn của ngành.

Google thực hiện đúng những điều mà Agile đề xuất (phát hành sớm và thường xuyên, thích nghi theo dữ liệu người dùng) nhưng không cần tự gọi mình là công ty Agile.

Một cuốn sách do chính các kỹ sư Google viết và xuất bản năm 2020 về quy trình kỹ thuật của công ty cũng gần như không nhắc đến Agile. Nội dung tập trung vào các chủ đề như testing, debugging, độ tin cậy, khả năng mở rộng, chứ hầu như không có Scrum. Với Google, việc phát triển phần mềm ở quy mô lớn là một bộ môn riêng biệt. Bất kỳ thực hành nào hữu ích thì được hấp thụ vào quy trình riêng, còn các từ khóa “thời thượng” thì được gạt sang một bên.

Trong triết lý của Google, sản phẩm luôn ở trạng thái “beta”, một thực thể sống động, không ngừng tiến hóa và thích nghi. Cách nghĩ này rất gần với Agile, nhưng Google đạt được nó thông qua văn hóa thử nghiệm được lãnh đạo khuyến khích.

Microsoft: Tiến hóa vượt khỏi Waterfall theo cách riêng

Không phải tất cả các công ty công nghệ lớn đều hoàn toàn từ chối Agile. Microsoft là một ví dụ điển hình cho việc chuyển mình có chọn lọc. Trong quá khứ, vào thập niên 1990 và đầu những năm 2000, Microsoft chủ yếu sử dụng mô hình phát triển có kế hoạch chặt chẽ (plan-driven), điển hình là các chu kỳ phát triển của Office và Windows kéo dài nhiều năm với hàng loạt tài liệu khổng lồ. Tuy nhiên, đến giữa thập niên 2010, dưới thời CEO Satya Nadella, Microsoft bắt đầu chuyển sang hành vi “agile” hơn, phát hành thường xuyên hơn (Windows 10 trở thành một dịch vụ cập nhật liên tục), thúc đẩy giao tiếp cởi mở và hình thành các team đa chức năng trong mảng cloud và DevOps.

Tuy vậy, hành trình của Microsoft vẫn không phải là một cuộc “cải đạo” toàn diện sang Scrum. Các nghiên cứu nội bộ từ những năm 2000 cho thấy mức độ tiếp nhận Agile rất không đồng đều. Như đã đề cập, khảo sát từ Microsoft Research cho thấy ngay cả những người ủng hộ và không ủng hộ Agile trong công ty đều thừa nhận rằng Agile vừa có lợi ích, vừa có điểm yếu, đặc biệt là ở các team quy mô lớn, nơi có nhiều lo ngại về khả năng mở rộng của Agile.

Bài học từ Microsoft cũng tương tự như các công ty công nghệ lớn khác: Khi bạn đã sở hữu hàng ngàn kỹ sư giỏi và một văn hóa kỹ thuật mạnh mẽ, bạn chọn lọc những điều hay từ Agile và tích hợp chúng vào hệ thống riêng của mình. Bạn không cần phải chạy theo Scrum chỉ vì nó đang là xu hướng.

Amazon: “Two-pizza team” và quyền tự chủ thay vì Agile

Sự phát triển thần tốc của Amazon, từ một hiệu sách trực tuyến thành một đế chế công nghệ, được thúc đẩy bởi tinh thần liên tục cải tiến quy trình nội bộ. Vào giữa những năm 2000, khi Amazon ngày càng lớn mạnh, họ bắt đầu gặp phải một vấn đề kinh điển về quy mô: càng nhiều người và dự án thì tốc độ thực thi càng chậm. Jeff Bezos quyết tâm không để Amazon rơi vào tình trạng trì trệ thường thấy ở các tập đoàn lớn. Giải pháp của ông không phải là áp dụng SAFe (Scaled Agile Framework) hay tuyển hàng trăm Scrum Master, mà là phân quyền triệt để, dẫn đến mô hình tổ chức mang tên: “Nhóm hai chiếc pizza”.

Bezos và các lãnh đạo Amazon nhận thấy rằng nhóm nhỏ di chuyển nhanh hơn và giao tiếp hiệu quả hơn. Trong triết lý vận hành chính thức của Amazon, “nhóm nhỏ giúp giảm thiểu luồng giao tiếp chồng chéo, giảm bớt gánh nặng quản trị và ra quyết định nhanh hơn.”

Nói cách khác, Amazon đạt được tính linh hoạt ở quy mô lớn bằng cách chia nhỏ tổ chức thành nhiều “startup mini”. Mỗi nhóm có một nhiệm vụ rõ ràng (thường là xoay quanh một tính năng hay dịch vụ cụ thể) và được toàn quyền xây dựng, triển khai bất cứ thứ gì cần thiết để hoàn thành mục tiêu.

Song song với đổi mới tổ chức, Amazon cũng đầu tư mạnh mẽ vào các công cụ nội bộ và kiến trúc hệ thống, để các nhóm có thể tiến nhanh và độc lập, điều mà một framework Agile đóng gói sẵn không thể cung cấp. Từ sớm, Amazon nhận ra rằng kiến trúc code đơn khối (monolith) làm chậm tốc độ phát triển, vì vậy họ tiên phong trong việc chuyển đổi sang microservices.

Kết hợp giữa kiến trúc kỹ thuật và cấu trúc nhóm, Amazon tạo ra một hệ sinh thái triển khai liên tục cực mạnh. Trên AWS, mỗi giây đều có code được đẩy ra môi trường thật, và các nhóm tự đánh giá hiệu suất bằng việc họ cải thiện cho khách hàng nhanh đến mức nào.

Điều đáng chú ý là, văn hóa của Amazon vẫn rất coi trọng dữ liệu, phản hồi từ khách hàng và thử nghiệm, rất gần với tinh thần của Agile, nhưng bằng cơ chế riêng.

Một phương pháp nổi tiếng của Amazon là “Working Backwards”: trước khi xây dựng bất kỳ sản phẩm nào, nhóm phải viết một thông cáo báo chí nội bộ và một bản FAQ, như thể sản phẩm đã ra mắt. Cách làm này buộc các nhóm làm rõ chính xác vấn đề nào của khách hàng họ đang giải quyết. Dù không nằm trong Scrum hay XP, phương pháp này tạo ra một tầm nhìn sản phẩm rõ ràng, để nhóm phát triển theo hướng lặp và thử nghiệm A/B liên tục.

Khi bạn có một tổ chức gồm những “builder được trao quyền”, như cách Bezos mô tả, những người hào hứng thức dậy mỗi ngày để giải quyết các bài toán hóc búa của khách hàng, thì việc thêm các buổi stand-up hàng ngày hay planning poker lại có thể khiến mọi thứ… chậm đi. Amazon đã chứng minh rằng bạn có thể đạt được các giá trị của Agile, gồm tốc độ, đổi mới, lấy khách hàng làm trung tâm, bằng cách thiết kế tổ chức hướng đến điều đó, thay vì áp dụng một phương pháp đóng gói cho tất cả.

Tư duy vượt qua Agile

Điểm chung giữa những công ty này là: họ xây dựng hệ thống phát triển riêng biệt, phù hợp với quy mô và tham vọng của chính họ.

Yếu tố khó sao chép nhất, nhưng lại là cốt lõi, chính là văn hóa đặt kết quả lên trên hình thức.

Kỹ sư không chỉ là người code, mà được kỳ vọng là người dẫn dắt giải pháp. Google yêu cầu kỹ sư đảm nhận nhiều khía cạnh kỹ thuật khác nhau, vượt khỏi vai trò chuyên biệt, từ đó hình thành một văn hóa ownership rộng và sâu, rất đồng điệu với giá trị của Agile, nhưng được nuôi dưỡng qua quy trình tuyển dụng và đào tạo, không phải danh sách checklist quy trình.

Tại Facebook, một trong những câu cửa miệng là: “Code thắng tranh luận” , tức là thay vì ngồi họp bàn, hãy làm prototype ngay (thường chỉ mất một, hai ngày) và đưa ra dữ liệu thực tế. Chính văn hóa như vậy mới tạo nên một tổ chức linh hoạt thật sự, bất kể có làm đúng Scrum hay không.

Tất cả các công ty trên, theo cách riêng của mình, đặt người dùng ở trung tâm:

• Amazon theo đuổi sự ám ảnh khách hàng (customer obsession),
• Netflix ra quyết định dựa trên dữ liệu hành vi người xem,
• Google thì thử nghiệm gần như mọi thứ,
• Facebook đo lường kỹ lưỡng mức độ tương tác của từng tính năng,
• Apple, dù bí mật, lại có một sự thấu hiểu kỳ lạ với nhu cầu người dùng và ám ảnh với từng chi tiết trải nghiệm.

Agile có còn phù hợp trong bối cảnh công nghệ hiện đại?

Agile vẫn là một phương pháp tuyệt vời để giúp các công ty nhỏ hoặc mới bắt đầu nâng cấp năng lực delivery. Rất nhiều team đã áp dụng Scrum, XP, hoặc Kanban và gặt hái thành công.

Những tên tuổi như Facebook, Apple, Amazon, Netflix, Google và Microsoft không phải đã bỏ qua Agile, mà họ đã vượt khỏi nó. Họ xây dựng một hệ thống còn Agile hơn cả Agile, được thiết kế riêng để phục vụ cho sứ mệnh lớn lao của mình.

Với phần còn lại của chúng ta, bài học là: Hãy tập trung vào kết quả, liên tục cải tiến cách mình làm việc, và xem các phương pháp Agile như một điểm khởi đầu, chứ không phải đích đến.

Tính linh hoạt thực sự không nằm trong todo list, mà nằm trong DNA của tổ chức, ở cách con người tư duy, giao tiếp, và cùng nhau hướng đến mục tiêu tạo ra giá trị.

Khi bạn làm đúng điều đó, bạn không cần phải “làm Agile” nữa, vì bạn đã là Agile rồi. Và đó mới chính là đích đến tối thượng.