Bài viết này là phần 2/2 về phương pháp làm việc ở Spotify (xem phần 1). Tôi sẽ tiếp tục ghi lại lý do tôi yêu cách làm việc này (và tin rằng khi bạn đọc/ hiểu về nó, bạn cũng sẽ thích).
Spotify là công ty 100% Agile, và họ bắt đầu với Scrum sau đó chuyển sang mô hình Tiểu Đội (Squad). Trong Spotify, mọi kỹ sư đều làm việc với nhau trong các Tiểu Đội - là các nhóm có tính định hướng mạnh và tính lệ thuộc yếu vào đội khác (Loosely coupled, tightly aligned squads).
Thất bại
Chúng ta định sẽ thất bại nhanh hơn bất cứ bố con thằng nào khác!
Ý tưởng ở đây là qua các vòng lặp phát triển sản phẩm (trong môi trường biến đổi & bất định như ngày nay), chúng ta không thể trách được thất bại. Vậy tại sao không thất bại nhanh hơn? Mỗi thất bại cũng là 1 cơ hội để học và kiểm nghiệm những thứ đã học. Vì vậy, thất bại nhanh chính là chiến lược để thành công dài hạn.
Đứng dậy nhanh > Tránh ngã
Spotify coi trọng việc bình phục nhanh hơn là tránh để không bị ốm. Bình phục sẽ tăng sức đề kháng - còn nếu thất bại mà chả học được gì thì đó vẫn chỉ là... thất bại. Với quan điểm đó, 1 số Đội có Bảng Thất bại (Fail Wall) để chia sẻ những thất bại của họ để mọi người học hỏi.
Spotify: Môi trường thân thiện với thất bại
- Đừng hỏi Ai có lỗi; Hãy xem điều gì đã xảy ra.
- Ta đã học được gì?
- Và sẽ thay đổi gì?
Thất bại nhanh ➡ Học hỏi nhanh ➡ Cải tiến nhanh!
Quy trình khám nghiệm
Là quy trình, thường được thực hiện khi kết thúc dự án, để tìm ra và mổ xẻ các điểm thành công và thất bại, rút ra bài học và cải tiến để giảm thiểu rủi ro tương lai.
"Sửa quy trình, đừng chỉ sửa sản phẩm"
Issue (vd issue trên Jira hay 1 vấn đề được đưa ra trên kênh Chăm sóc khách hàng) CHƯA được đóng lại khi vấn đề đã được giải quyết - mà chỉ đóng khi ta đưa ra được các bài học để tránh cho vấn đề tương tự xảy ra trong tương lai.
Cải tiến liên tục
Các Đội đều có buổi Hồi tưởng (retrospective) mỗi vài tuần để nói về những gì đã làm tốt và những gì cần cải tiến. Việc cải tiến liên tục được thực hiện từ dưới lên và được hỗ trợ từ trên xuống.