>>Triển khai Agile quy mô lớn tại Spotify phần 2
Trong một tổ chức phát triển sản phẩm, việc đối mặt với việc tham gia giữa nhiều nhóm luôn là một thử thách!
Spotify là một ví dụ ấn tượng nhất mà chúng tôi biết trong việc giữ được tư duy Agile cho dù có quy mô lên đến 30 nhóm nằm ở 3 thành phố khác nhau.
Spotify là một công ty thú vị đang thay đổi nền công nghiệp âm nhạc. Công ty mới thành lập được 6 năm nhưng đã có hơn 15 nghìn người sử dụng thường trực, trong số đó có 4 nghìn người đang trả phí. Bản thân sản phẩm được ví như là “ một ứng dụng chơi nhạc thần kì mà ở đó bạn có thể tìm được và phát ngay lập tức bất kì một bản nhạc nào trên thế giới”.
Alistair Cockburn (một trong những “cha đẻ” của Phát triển Phần mềm Linh hoạt) đã đến thăm Spotify và nói rằng: “Hay – tôi đã tìm kiếm một ai đó sẽ thực hiện mô hình ma trận này từ năm 1992) cho nên tôi vô cùng vui mừng khi đã tìm thấy.”
Vậy Spotify được quản lý như thế nào?
Chúng tôi đã tham gia nhiều hội nghị và các cuộc thảo luận để chia sẻ về phong cách làm việc tại Spotify, cũng như cách công ty áp dụng Agile cho hàng trăm nhà phát triển. Vì nhiều người bày tỏ sự quan tâm, nên chúng tôi quyết định viết một bài về vấn đề này.
Đính chính: Chúng tôi không phát minh ra mô hình này. Spotify (cũng như bất kì một công ty Agile vận hành tốt nào) đang phát triển rất nhanh. Bài viết này chỉ là một minh họa về cách làm việc hiện nay của chúng tôi – một hành trình đang diễn ra, chứ chưa kết thúc. Khi bạn đọc được bài viết này, mọi thứ có thể đã thay đổi.
Các Squad (đội)
Đơn vị phát triển cơ bản trong Spotify là Squad.
Squad giống như một Nhóm Scrum, và được thiết kế như là một startup-nhỏ. Những người có đủ những kỹ năng và công cụ cần thiết để thiết kế, phát triển, kiểm thử và phát hành sản phẩm, sẽ ngồi lại với nhau. Họ là nhóm tự tổ chức và quyết định cách làm việc riêng – có thể dùng các Sprint trong Scrum, Kanban hoặc sự kết hợp của cả hai phương pháp.
Mỗi Squad có một nhiệm vụ dài hạn kiểu như xây dựng và cải tiến ứng dụng trên Android, tạo ra trải nghiệm radio trên Spotify, mở rộng hệ thống backend, hoặc cung cấp các giải pháp thanh toán. Hình ảnh dưới đây minh họa những trách nhiệm mà Squad phải đảm nhận ở các phân đoạn khác nhau của quá trình trải nghiệm người dùng.
Các Squad được khuyến khích áp dụng những nguyên tắc Lean Startup như MVP (minimum viable product) và validated learning. MVP có nghĩa là phát hành sớm và thường xuyên, trong khi là validated learning là sử dụng các số liệu và kiểm thử A/B để tìm ra cái gì thực sự hiệu quả, cái gì không. Điều này được đúc kết trong khẩu hiệu “Hãy nghĩ, hãy xây dựng, hãy chuyển giao, hãy cải tiến”.
Do mỗi Squad gắn với một nhiệm vụ và một phần của sản phẩm trong một thời gian dài nên họ trở thành các chuyên gia trong lĩnh vực đó – ví dụ tạo nên một trải nghiệm radio thú vị.
Phần lớn các squad có một không gian làm việc tuyệt vời bao gồm khu vực làm việc và khu vực “lộn xộn” cá nhân. Gần như tất cả các bức tường ở đây là bảng trắng. Chúng tôi chưa bao giờ thấy một không gian cộng tác tuyệt vời đến vậy!
Vâng, đó chính là một con cá mập bay, hoàn toàn bình thường thôi
Nhằm đẩy mạnh việc học hỏi và cải tiến, mỗi Squad đc khuyến khích dành khoảng 10% thời gian cho các “hack day”. Vào những ngày này, họ có thể làm bất kì việc gì họ muốn, thường là thử những ý tưởng mới và chia sẻ về chúng với đồng nghiệp. Một số nhóm sẽ tổ chức hack day hai tuần một lần hoặc cũng có những nhóm sẽ dành hẳn một “hack week”. Hack day không chỉ vui mà cũng là cách để cập nhật những công cụ và kỹ thuật mới và đôi khi còn mang đến những cải tiến sản phẩm quan trọng!
Squad không có một người lãnh đạo chính thức được chỉ định, nhưng có một Product Owner. Product Owner sẽ chịu trách nhiệm ưu tiên hóa các công việc được thực hiện bởi nhóm, nhưng sẽ không quyết định cách thức thực hiện chúng. Product Owner của các Squad khác nhau sẽ hợp tác để duy trì tài liệu lộ trình cấp cao thể hiện hướng đi của toàn thể Spotify và từng PO sẽ chịu trách nhiệm duy trì một Product Backlog tương ứng cho Squad của mình.
Squad cũng có một Agile coach (huấn luyện viên Agile), sẽ giúp họ hình thành và phát triển phương pháp làm việc hiệu quả. Các huấn luyện viên thực hiện các phiên họp cải tiến, Lập kế hoạch Sprint và huấn luyện 1-1, v.v…
Theo lý thuyết, mỗi Squad hoàn toàn tự chủ trong việc liên lạc trực tiếp với các bên liên quan, mà không bị cản trở hay phụ thuộc vào các Squad khác. Cơ bản giống như là một startup-nhỏ. Nhưng với hơn 30 nhóm, đó lại là một thử thách! Tuy chúng tôi đã đi được một chặng đường dài, nhưng rất ít cải tiến được thực hiện.
Để cải thiện việc này, chúng tôi tiến hành những cuộc khảo sát theo quý cho từng Squad. Việc này giúp tập trung mọi nỗ lực để cải tiến và tìm ra cách thức hỗ trợ cần thiết. Dưới đây là hình ảnh tổng kết một trong những cuộc khảo sát như vậy, với 5 Squad trong một Tribe:
Hình tròn chỉ trạng thái hiện tại, mũi tên là xu hướng. Ví dụ chúng ta có thể thấy một khuôn mẫu mà ở đó cả ba Squad báo cáo có khó khăn trong việc phát hành và không có dấu hiệu cải thiện – khu vực cần sự chú ý đặc biệt! Chúng ta cũng thấy rằng tình hình của Squad 4 cũng thấy không ổn với sự trợ giúp của huấn luyện viên Agile, nhưng điều đó đang được cải thiện.
- Product Owner – Squad có một Product Owner dành riêng, người luôn chịu trách nhiệm ưu tiên hóa các công việc và luôn cân nhắc cả giá trị kinh doanh và những khía cạnh kỹ thuật.
- Huấn luyện viên Agile – Squad có một huấn luyện viên Agile giúp họ xác định các trở ngại và huấn luyện họ liên tục cải tiến quá trình.
- Influencing work – Mỗi thành viên Squad có thể tác động đến công việc của họ, đóng vai trò là phần tích cực trong việc lên kế hoạch và lựa chọn công việc mình sẽ thực hiện. Mỗi thành viên Squad nên dành 10% thời gian cho các hack day.
- Dễ dàng phát hành – Squad có thể (thực tế là có) có những rắc rối và động bộ tối thiếu.
- Quy trình phù hợp với nhóm – Squad cảm nhận được làm chủ đối với quy trình và cải tiến liên tục nó.
- Nhiệm vụ – Thành viên Squad luôn nhận thức và quan tâm đến nhiệm vụ chung và hướng các User story trong backlog theo nhiệm vụ này.
- Sự hỗ trợ từ tổ chức – Squad biết rõ nên tìm sự hỗ trợ từ ai khi gặp khó khăn với những vấn đề kỹ thuật cũng như các vấn đề “mềm” khác.
Các Tribe (nhóm)
Tribe là một tập hợp các squad làm việc trong những lĩnh vực có liên quan – như là âm nhạc hay cơ sở hạ tầng backend.
Tribe có thể được coi như một “vườn ươm” cho những mini-startup Squad, có chừng mực trong việc tự do và tự chủ. Mỗi Tribe có một Tribe Lead chịu trách nhiệm cung cấp môi trường tốt nhất có thể cho các Squad thành viên. Tất cả các Squad thường ở trong cùng một văn phòng, có vị trí ngay cạnh nhau, với những khu vực xung quanh được thiết kế ra để thúc đẩy sự hợp tác giữa các Squad.
Các Tribe được lập nên dựa trên khái niệm “Số Dunbar”, khái niệm này phát biểu rằng phần lớn mọi người không thể duy trì mối quan hệ xã giao với nhiều hơn 100 người (con số này sẽ lớn hơn đối với các nhóm đang phải chịu áp lực sinh tồn cường độ cao, điều này thực sự không đúng với trường hợp tại Spotify, tin hay không…). Khi các nhóm trở nên quá lớn, chúng ta có thể nhận thấy nhiều vấn đề khác như là các quy định bị giới hạn, quan liêu, vấn đề về chính trị, những tầng quản lý bổ sung và những lãng phí khác.
Vì vậy các Tribe được thiết kế với số lượng không vượt quá 100 người.
Tribe tổ chức các buổi họp mặt thường kỳ, mang tính chất phi chính quy mà ở đó họ chia sẻ với phần còn lại của Tribe (hoặc bất cứ ai tham giá) về những công việc mà họ đang làm, những gì họ đã chuyển giao và mọi người có thể học được điều gì từ đó. Bao gồm các bản chạy thử tốt của phần mềm, những công cụ, kỹ thuật mới và những dự án thú vụ cho hack-day, v.v…
Tác giả: Henrik Kniberg & Anders Ivarsson | Nguồn:blog.crisp.se
