Model tim Squad milik Spotify adalah sebuah kegagalan
(jeremiahlee.com)"Spotify sendiri pun tidak menggunakan 'the Spotify model'. Jadi, jangan pakai itu juga."
Whitepaper Spotify yang terkenal pada 2012, "Scaling Agile", hanyalah sebuah aspirasi dan tidak pernah diimplementasikan sepenuhnya.
Whitepaper itu berbeda dari kenyataan, tetapi tetap dibiarkan karena berguna untuk perekrutan, dan penulis mencatat ini setelah keluar dari perusahaan untuk meluruskannya.
Sebuah tulisan yang menjelaskan secara rinci apa yang salah dari model tersebut, apa yang bisa dipelajari dari kesalahan Spotify, dan model alternatif yang direkomendasikan.
Salah satu penulis whitepaper itu dan para Agile coach di Spotify sebelumnya memang pernah mengatakan kepada orang luar agar tidak menirunya.
"Bahkan saat kami menulis whitepaper itu, kami sudah tidak melakukannya. Itu hanya ambisi parsial dan perkiraan. Orang-orang bersusah payah meniru sesuatu yang sebenarnya tidak pernah benar-benar ada."
Mengapa itu tidak berjalan dengan baik?
- Manajemen matriks menyelesaikan masalah yang salah (Wrong Problem)
Tim agile full-stack bekerja dengan baik. Tetapi manajemen berbentuk matriks justru menciptakan lebih banyak masalah.
→ Tim-tim Spotify berstruktur jangka panjang, sehingga keuntungan karena tidak perlu mengganti manajer saat pindah ke tim lain sangat terbatas.
→ Manajer engineering hanya bertanggung jawab pada level pengembangan karier, dan tidak bisa membantu orang mempelajari keterampilan relasional antarmanusia dan sejenisnya.
→ Tidak ada satu manajer tunggal yang menangani para engineer di tiap tim. Product manager yang berperan seperti mini-CEO tidak memiliki padanan seperti mini-CTO. Artinya, tidak ada orang yang bertanggung jawab atas dukungan untuk tim teknis atau yang bisa menegosiasikan prioritas. Jika terjadi perbedaan pendapat di dalam tim teknis, product manager harus bernegosiasi dengan semua engineer. Jika itu tidak berhasil, mereka harus bernegosiasi setidaknya dengan tiga manajer engineering backend/web/mobile, atau melakukan eskalasi ke pimpinan engineering departemen.
[ Yang bisa dipelajari dari kesalahan Spotify ]
→ Dalam tim produk-desain-teknologi, jumlah engineer biasanya lebih banyak, jadi perlu ada manajer yang menangani seluruh engineer agar tersedia jalur eskalasi saat terjadi konflik pendapat dalam tim.
→ Product manager perlu memiliki rekan setara untuk mendiskusikan masalah teknis, seperti hubungan CEO dan CTO.
- Bergantung pada otonomi tim
Saat perusahaan masih kecil, tiap tim menangani pekerjaan dengan cakupan yang beragam, dan tim yang memegang kendali pun sering berganti.
Ketika perusahaan membesar, fungsi-fungsi yang tumpang tindih di tiap tim digabungkan menjadi tim baru demi efisiensi.
Ketika jumlah tim bertambah, pergantian kepemimpinan jadi lebih jarang, dan tim bisa berpikir jangka panjang tentang masalah yang harus mereka selesaikan.
→ Spotify tidak mendefinisikan proses bersama untuk kolaborasi antar tim. Karena tiap tim ikut serta dengan caranya sendiri, produktivitas organisasi secara keseluruhan menurun.
→ "Spotify model" dirumuskan ketika perusahaan masih jauh lebih kecil. Seharusnya ada versi lanjutan yang diperbarui, tetapi itu tidak pernah muncul. Pembahasannya berhenti di otonomi, dan bagian tentang kolaborasi antar tim tidak pernah benar-benar selesai.
[ Yang bisa dipelajari dari kesalahan Spotify ]
→ Otonomi memerlukan alignment. Prioritas perusahaan harus ditentukan oleh pimpinan. Otonomi bukan berarti tim bebas melakukan apa pun yang mereka mau.
→ Proses kolaborasi antar tim itu wajib ada. Otonomi bukan berarti membiarkan setiap tim menyelesaikan semua masalah sendirian.
→ Cara menilai keberhasilan juga harus ditetapkan oleh pimpinan agar koordinasi bisa dilakukan saat menentukan prioritas kolaborasi antar tim.
→ Otonomi menuntut akuntabilitas. Product Management harus bertanggung jawab atas nilai produk. Tiap tim punya tanggung jawab untuk benar-benar menuntaskan bagian yang ditambahkan. Tim yang matang harus membenarkan independensinya dengan menunjukkan langkah terbaik untuk nilai bisnis, risiko, pembelajaran, dan tahap berikutnya.
"Kalau saya harus memilih hanya satu hal yang ingin saya perbaiki dari Spotify, itu adalah seharusnya kami tidak terlalu menekankan otonomi." - Joakim Sunden, mantan Agile Coach di Spotify
- Kolaborasi hanyalah kompetensi yang diasumsikan
Spotify memang memberi keleluasaan bagi tiap tim untuk mengendalikan cara kerjanya, tetapi banyak orang tidak memiliki pemahaman dasar tentang agile.
Akibatnya, tiap tim harus berusaha mencari kombinasi yang pas dengan terus mengulang perbaikan proses demi meningkatkan output.
Tidak ada bahasa bersama untuk secara efisien membahas masalah proses, solusi, atau evaluasi hasil. Pada praktiknya, itu bahkan bukan agile, melainkan sekadar "Not-Waterfall".
Spotify memiliki 'Agile coach' yang bertugas mengajarkan dan menyarankan perbaikan proses kepada tiap tim. Niatnya baik, tetapi jumlah coach tidak cukup untuk membantu semua tim.
Waktu yang bisa dialokasikan tiap coach untuk tiap tim tidak cukup untuk membantu sampai proyek selesai dan hasilnya dievaluasi. Karena itu, mereka tidak benar-benar memikul tanggung jawab apa pun.
[ Yang bisa dipelajari dari kesalahan Spotify ]
→ Kolaborasi adalah keterampilan yang membutuhkan pengetahuan dan latihan. Manajer tidak boleh berasumsi bahwa orang-orang sudah memahami praktik-praktik agile yang ada.
→ Ketika perusahaan cukup besar, tiap tim memerlukan organisasi pendukung agar bisa merencanakan di dalam tim sekaligus memungkinkan kolaborasi antartim. Program Management harus bertanggung jawab atas proses perencanaan. Program Manager yang berdedikasi harus membuat tim bekerja sebagaimana Product Manager dan Engineering Manager menjalankan peran masing-masing sambil tetap berkolaborasi.
- Mitos sulit diubah
Agile Scrum memperkenalkan istilah seperti burndown/sprint karena dibutuhkan nama saat mengenalkan konsep baru.
Spotify memperkenalkan istilah baru seperti Missions, Tribe, Squads, dan Chapter Lead, yang menanamkan "ilusi bahwa kita telah menciptakan sesuatu yang menuntut pilihan istilah khusus".
Jika sinonim-sinonim yang tidak perlu ini dihapus, model Spotify sebenarnya hanya kumpulan "Cross-Functional Team" dengan otonomi yang berlebihan dan struktur manajemen yang lemah.
Seandainya Spotify menyebut gagasan dalam model ini dengan nama-nama aslinya, maka ketika model itu gagal, mereka mungkin akan menilainya bukan sebagai perubahan identitas budaya, melainkan sebagai upaya mencari proses internal yang bekerja lebih baik.
[ Yang bisa dipelajari dari kesalahan Spotify ]
→ Sebagian besar bisnis hanya mampu mempertahankan beberapa area inovasi. Jarang sekali inovasi proses internal menjadi pembeda perusahaan di pasar. Dengan mempelajari masa lalu, bisnis bisa menemukan area yang lebih baik untuk berinovasi.
→ Optimalkan pemahaman. Untuk menjaga produktivitas organisasi, nilai manfaat dari setiap hal baru yang harus dipelajari anggota organisasi.
*** Sebagai gantinya, lakukan ini. ( tentu saja tidak ada jalan pintas. )
Jika Anda mencari model Spotify, kemungkinan itu karena Anda ingin membangun struktur tim Anda. Jangan berhenti di sini; pelajari lebih jauh.
Perusahaan-perusahaan yang telah teruji lebih lama daripada Spotify sudah menulis lebih banyak tentang ini.
Spotify pada 2012 belum menemukan cara mempertahankan kecepatan dan kelincahan tim kecil di dalam organisasi besar.
Mereka sendiri melihat ke luar untuk menemukan jawaban yang lebih baik daripada model purba ini, dan Anda juga sebaiknya begitu.
Rekomendasi penulis tentang cara kerja lain
-
Apakah organisasi produk-pengembangan-desain Anda memiliki lebih dari 200 orang? Saat saya di Fitbit, "Scaled Agile Framework" bekerja dengan baik.
-
Untuk organisasi dengan 200 orang atau kurang, saya merekomendasikan "Shape Up By Basecamp". Startup saya berikutnya akan menggunakan struktur seperti ini.
-
Cobalah membaca buku "Essential Scrum" dan "Team Topologies".
4 komentar
Terima kasih untuk artikelnya yang bagus.
Di perusahaan saya sekarang juga sempat mengadopsi model tim squad dari Spotify sekitar 2 tahun lalu, tetapi karena kekurangan-kekurangan yang disebutkan dalam artikel, banyak bagiannya akhirnya terpaksa diperbaiki.
Sejak awal tahun ini kami mengikuti Shape Up dari Basecamp, dan hasilnya kami bisa memberikan kualitas produk yang lebih baik.
Betul juga. Selain kisah sukses, kisah kegagalan juga penting.
Saya kaget saat pertama kali membaca dan membagikan whitepaper "Scaling Agile" ini ketika dirilis, bahkan sempat menulis tentangnya di blog.. tulisan yang mengejutkan ya T_T
Salah satu rekomendasi penulis, "Shape Up" dari Basecamp, pernah diperkenalkan di GeekNews. Untuk organisasi kecil, saya juga merekomendasikan ini.
Shape Up - cara organisasi kecil bekerja dengan sangat baik [PDF] https://id.news.hada.io/topic?id=427
Reaksi para karyawan Spotify terhadap tulisan ini
Saya bekerja di sana selama 6 tahun, dan ini 100% akurat. https://twitter.com/solomonjames/status/1258930064441425920
Saya keluar pada 2019, dan alasan besar saya keluar adalah masalah-masalah yang ada di tulisan ini. https://twitter.com/ayyyylo/status/1253658456621539328
Reaksi orang lain yang meniru lalu gagal
Zalando menirunya pada 2016, dan dengan cepat menyadari bahwa ini tidak bekerja dengan baik. https://twitter.com/chilicoder/status/1253429837185691656
Typeform juga sempat mencoba meniru ini lalu gagal. https://twitter.com/jharmn/status/1252229296522842121
Begitu Spotify menuliskannya di blog, kami langsung mencoba menirunya, dan hasilnya adalah bencana. https://twitter.com/braedon/status/1256122236424957953