Mô hình đội Squad của Spotify là một thất bại
(jeremiahlee.com)"Ngay cả Spotify cũng không dùng 'the Spotify model'. Bạn cũng đừng dùng nó."
Bản whitepaper "Scaling Agile" nổi tiếng của Spotify năm 2012 chỉ là kỳ vọng của họ và chưa bao giờ được triển khai trọn vẹn.
Bản whitepaper khác với thực tế, nhưng vì hữu ích cho tuyển dụng nên nó vẫn được giữ nguyên; tác giả ghi chép lại sau khi rời công ty để đính chính điều này.
Bài viết trình bày chi tiết những điểm sai của mô hình đó, những gì có thể học từ sai lầm của Spotify, và các mô hình khác được khuyến nghị.
Đồng tác giả của bản whitepaper đó và các Agile coach tại Spotify từ trước cũng đã từng nói với người ngoài rằng đừng làm theo nó.
"Ngay cả vào thời điểm chúng tôi viết whitepaper, chúng tôi cũng không làm như vậy. Đó chỉ là một phần tham vọng và suy đoán. Mọi người đã vất vả làm theo thứ thực ra không hề tồn tại."
Vì sao nó không vận hành tốt?
- Quản lý ma trận giải quyết sai vấn đề (Wrong Problem)
Các đội agile full-stack vận hành tốt. Nhưng quản lý theo ma trận lại tạo ra nhiều vấn đề hơn.
→ Các đội của Spotify có cấu trúc tồn tại lâu dài, nên lợi ích là không cần đổi quản lý khi chuyển sang đội khác thực ra rất hạn chế.
→ Engineering manager chỉ chịu trách nhiệm ở mức phát triển sự nghiệp, không thể hỗ trợ việc rèn luyện kỹ năng quan hệ giữa con người v.v.
→ Không có một quản lý duy nhất phụ trách các kỹ sư trong từng đội. Product manager vốn đóng vai mini-CEO lại không có ai đóng vai mini-CTO tương ứng. Tức là không có ai chịu trách nhiệm hỗ trợ khối kỹ thuật hoặc đàm phán ưu tiên. Khi có bất đồng trong nội bộ nhóm kỹ thuật, product manager phải đàm phán với tất cả các kỹ sư. Nếu không xong thì lại phải đàm phán với ít nhất 3 engineering manager của backend/web/mobile, hoặc escalte lên người đứng đầu kỹ thuật của bộ phận.
[ Bài học từ sai lầm của Spotify ]
→ Trong đội sản phẩm-thiết kế-kỹ thuật thường số kỹ sư nhiều hơn, nên cần có một quản lý phụ trách toàn bộ kỹ sư để tạo ra tuyến escalation khi có xung đột quan điểm trong đội.
→ Product manager nên có một peer ngang hàng để trao đổi về kỹ thuật, giống như CEO và CTO.
- Phụ thuộc vào tính tự chủ của đội
Khi công ty còn nhỏ, mỗi đội xử lý phạm vi công việc đa dạng và đội nắm vai trò dẫn dắt cũng thường xuyên thay đổi.
Khi công ty lớn lên, các chức năng trùng lặp giữa các đội được gom lại thành đội mới để tăng hiệu quả.
Khi số đội tăng lên, việc đổi vai trò dẫn dắt xảy ra ít hơn và các đội có thể suy nghĩ dài hạn về những vấn đề mình phải giải quyết.
→ Spotify không định nghĩa một quy trình chung cho hợp tác liên đội. Mỗi đội tham gia theo cách riêng nên năng suất của toàn tổ chức bị giảm.
→ "Spotify model" được hệ thống hóa khi công ty còn nhỏ hơn nhiều. Lẽ ra phải có tài liệu tiếp nối được cập nhật, nhưng điều đó đã không xảy ra. Chỉ nói đến tự chủ, còn phần hợp tác liên đội thì chưa bao giờ hoàn thiện.
[ Bài học từ sai lầm của Spotify ]
→ Tự chủ cần có sự thống nhất định hướng. Ưu tiên của công ty phải do ban lãnh đạo xác định. Tự chủ không có nghĩa là các đội muốn làm gì thì làm.
→ Quy trình hợp tác liên đội là thứ bắt buộc phải có. Tự chủ không có nghĩa là để mỗi đội tự giải quyết mọi vấn đề một mình.
→ Cách đánh giá thành công cũng phải do ban lãnh đạo đặt ra thì mới có thể điều phối khi quyết định ưu tiên cho hợp tác liên đội.
→ Tự chủ đòi hỏi trách nhiệm. Product Management phải chịu trách nhiệm về giá trị sản phẩm. Mỗi đội phải chịu trách nhiệm hoàn thành phần được bổ sung. Một đội trưởng thành phải biện minh cho sự độc lập của mình bằng cách cho thấy bước đi tối ưu cho giá trị kinh doanh, rủi ro, học hỏi và các bước tiếp theo.
"Nếu phải chọn đúng một thứ tôi muốn sửa ở Spotify, thì đó là lẽ ra chúng tôi không nên nhấn mạnh tính tự chủ quá mức." - Joakim Sunden, cựu Agile Coach của Spotify
- Hợp tác chỉ được xem như một năng lực mặc định sẵn có
Spotify cho phép mỗi đội kiểm soát cách làm việc của mình, nhưng nhiều người không có hiểu biết nền tảng về agile.
Vì vậy, mỗi đội phải tự thử nghiệm nhiều cách kết hợp bằng cách lặp lại cải tiến quy trình để nâng cao đầu ra.
Không có ngôn ngữ chung để đánh giá hiệu quả các vấn đề quy trình, cách giải quyết hay kết quả. Trên thực tế, đó cũng không phải agile, mà chỉ là "Not-Waterfall".
Spotify có các "Agile coach" để dạy và đề xuất cải tiến quy trình cho từng đội. Ý định thì tốt, nhưng không có đủ coach để hỗ trợ tất cả các đội.
Thời gian mỗi coach phân bổ cho từng đội là không đủ để giúp đội hoàn thành dự án và đánh giá kết quả. Vì vậy họ không chịu trách nhiệm về bất cứ điều gì.
[ Bài học từ sai lầm của Spotify ]
→ Hợp tác là một kỹ năng cần kiến thức và thực hành. Quản lý không nên giả định rằng mọi người đều đã hiểu các thực hành agile hiện có.
→ Khi công ty đủ lớn, mỗi đội cần có tổ chức hỗ trợ để lập kế hoạch trong nội bộ đội và tạo điều kiện cho hợp tác liên đội. Program Management phải chịu trách nhiệm về quy trình planning. Các Program Manager chuyên trách phải giúp đội vận hành sao cho Product Manager và Engineering Manager vừa phát huy năng lực riêng vừa có thể cộng tác với nhau.
- Một huyền thoại rất khó thay đổi
Agile Scrum đưa ra các từ như burndown/sprint vì khi giới thiệu khái niệm mới thì cần có tên gọi.
Spotify lại giới thiệu các từ mới như Missions, Tribe, Squads, Chapter Lead, và điều này tạo ra "ảo tưởng rằng người ta chỉ có thể tạo ra thứ gì đó nếu chọn những từ ngữ đặc biệt".
Nếu loại bỏ những từ đồng nghĩa không cần thiết này, mô hình Spotify chỉ còn là tập hợp các "Cross-Functional Team" với quá nhiều tự chủ và một cấu trúc quản lý yếu.
Nếu Spotify gọi những ý tưởng trong mô hình này bằng các tên gốc, thì khi mô hình thất bại, có lẽ họ đã không xem đó là thay đổi bản sắc văn hóa mà là đi tìm một quy trình nội bộ vận hành tốt hơn.
[ Bài học từ sai lầm của Spotify ]
→ Phần lớn doanh nghiệp chỉ có thể duy trì một vài lĩnh vực đổi mới. Đổi mới trong quy trình nội bộ hiếm khi là thứ tạo khác biệt cho công ty trên thị trường. Nghiên cứu quá khứ có thể giúp doanh nghiệp tìm ra những lĩnh vực tốt hơn để đổi mới.
→ Hãy tối ưu cho sự thấu hiểu. Để duy trì năng suất của tổ chức, cần đánh giá giá trị của mọi điều mới mà các thành viên trong tổ chức phải học.
*** Thay vào đó hãy làm thế này. ( Tất nhiên không có đường tắt nào cả. )
Lý do bạn tìm đến mô hình Spotify có lẽ là để thiết kế cấu trúc đội ngũ. Đừng dừng lại ở đây, hãy tìm hiểu thêm.
Nhiều công ty đã vượt qua thử thách của thời gian lâu hơn Spotify cũng đã viết ra nhiều tài liệu hơn.
Spotify của năm 2012 đã không tìm ra cách duy trì tốc độ và sự linh hoạt của các đội nhỏ trong một tổ chức quy mô lớn.
Họ đã nhìn ra bên ngoài để vượt qua mô hình khai mở ban đầu này và tìm câu trả lời tốt hơn, và bạn cũng nên như vậy.
Các khuyến nghị của tác giả về những cách làm việc khác
-
Tổ chức sản phẩm-phát triển-thiết kế của bạn có hơn 200 người không? Khi tôi ở Fitbit, "Scaled Agile Framework" đã rất phù hợp.
-
Với dưới 200 người, tôi khuyến nghị "Shape Up By Basecamp". Startup tiếp theo của tôi sẽ dùng cấu trúc này.
-
Hãy đọc các cuốn "Essential Scrum" và "Team Topologies".
4 bình luận
Cảm ơn bạn vì bài viết hay.
Ngay tại công ty tôi hiện nay cũng đã áp dụng mô hình đội squad của Spotify vào khoảng 2 năm trước, nhưng vì những nhược điểm được nêu trong bài nên nhiều phần đã buộc phải được cải thiện.
Từ đầu năm nay, chúng tôi đang làm theo Shape Up của Basecamp, và kết quả là đã có thể cung cấp chất lượng sản phẩm tốt hơn.
Đúng vậy. Các trường hợp thất bại cũng quan trọng không kém gì các trường hợp thành công.
Khi bài viết trắng "Scaling Agile" này lần đầu được công bố, tôi đã rất ngạc nhiên khi đọc nó nên đã chia sẻ và còn viết cả trên blog nữa.. Đúng là một bài viết gây sốc huhu
Một trong những đề xuất của tác giả, "Shape Up của Basecamp", cũng đã từng được giới thiệu trên GeekNews. Với các tổ chức nhỏ, tôi cũng khuyên dùng cách này.
Shape Up - Cách để một tổ chức nhỏ làm việc xuất sắc [PDF] https://vi.news.hada.io/topic?id=427
Phản ứng của nhân viên Spotify về bài viết này
Tôi đã ở đó 6 năm và nội dung này chính xác 100%. https://twitter.com/solomonjames/status/1258930064441425920
Tôi nghỉ vào năm 2019, và một lý do lớn khiến tôi rời đi chính là những vấn đề được nêu trong bài này. https://twitter.com/ayyyylo/status/1253658456621539328
Phản ứng của những người khác đã bắt chước và thất bại
Zalando đã làm theo vào năm 2016, và nhanh chóng nhận ra rằng cách này không hoạt động tốt. https://twitter.com/chilicoder/status/1253429837185691656
Typeform cũng đã thử làm theo cách này nhưng thất bại. https://twitter.com/jharmn/status/1252229296522842121
Chúng tôi đã thử làm theo ngay khi Spotify viết về nó trên blog, và đó là một thảm họa. https://twitter.com/braedon/status/1256122236424957953