Top 5 faktor kegagalan implementasi Scrum di Indonesia
Baru-baru ini saya bertemu dengan CEO salah satu perusahaan ternama di Indonesia yang menanyakan kepada saya: “Apa top 5 faktor kegagalan Agile transformation menggunakan Scrum di Indonesia?”. Hingga hari itu saya belum pernah mendapatkan pertanyaan seperti itu dari seorang CEO. Menurut saya ini adalah pertanyaan yang bagus dan perlu ditanggapi karena alasan CEO tersebut ingin mengtahui jawabannya adalah karena dia tidak ingin mengulangi kesalahan yang sama yang dilakukan oleh perusahaan lain dan memastikan proses transformasi di perusahaan dia berakhir dengan mendapatkan manfaat yang maksimal.
Hingga hari ini saya cukup banyak (kalau bukan yang terbanyak) melihat implementasi Scrum di Indonesia mulai dari perusahaan startup hingga korporasi yang masuk bursa saham, dari perusahaan lokal maupun perusahaan asing. Dan belakangan ini saya banyak membantu perusahaan-perusahaan ternama dalam Agile transformation menggunakan Scrum. Saya pun berpikir untuk mendokumentasikan pengalaman saya agar dapat menjadi pembelajaran bagi yang saat ini juga sedang transisi dari manajemen proyek tradisional menuju Scrum.
1. Tidak ada dukungan dari manajemen
Faktor kegagalan pertama adalah tim menjalankan Scrum tanpa dukungan dari manajemen. Tim seperti ini menjalankan Scrum dalam stealth mode. Menggunakan Scrum dalam stealth mode di Indonesia tidak akan bertahan lama mengingat gaya kepemimpinan yang diadopsi di banyak perusahaan di Indonesia masih kental dengan otoriter. Di dalam budaya egaliter, dimana posisi manajemen sama rata dengan staff, kebutuhan akan blessing dari manajemen tidak setinggi di perusahaan yang berada dalam budaya otoriter. Perusahaan yang menggunakan Scrum dalam budaya otoriter implementasi Scrumnya tidak akan sustain dalam jangka waktu lama dan Scrum tidak sampai menjadi sebuah budaya kerja di kantor. Berdasarkan pengamatan saya tim yang menggunakan Scrum dalam budaya otoriter akan memiliki tingkat keberhasilan yang rendah.
Berdasarkan pengalaman saya untuk konteks Indonesia blessing harus sampai ke C-Level, bahkan kalau perlu jangan hanya sampai CIO atau CTO tapi harus sampai tingkat CEO karena saya pernah mengalami dimana CIO memberi dukungan penuh terhadap penggunaan Scrum namun CEO menghapus penggunaan Scrum hanya karena dia tidak memahami apa itu Scrum. Dalam institusi pemerintahan atau Badan Usaha Milik Negara (BUMN) yang masih tergolong ortodoks dan masih takut mencoba hal baru, peranan pimpinan di level paling tinggi sangatlah penting.
Tidak adanya dukungan dari manajemen juga bisa dalam bentuk manajemen yang memiliki pemahaman sendiri mengenai Scrum, contoh:
- Scrum adalah mini-deadline, dimana ruang-lingkup pekerjaan setiap Sprint dan waktu sudah dikunci dan tidak bisa dinegosiasi oleh orang-orang yang memiliki kekuatan politik tertinggi.
- Scrum artinya boleh merubah fitur dan prioritas kapanpun stakeholder inginkan. Dan tidak jarang mereka beranggap bahwa dengan segala perubahan tersebut, deadline tidak berubah.
- Tidak peduli dengan proses dan tidak ada fanatisme terhadap kualitas, yang penting cepat selesai.
- Tidak sabar menunggu tim berevolusi menjadi tim Scrum yang hebat, hanya mau instan dan melihat perubahan dalam sekejap.
Perusahaan dimana pimpinannya memiliki pemahaman sendiri mengenai Scrum yang tidak sesuai dengan Scrum Guide akan berisi orang-orang yang membenci Scrum dan mempertanyakan kenapa mereka tidak kembali kerja dengan cara tradisional saja.
Saat ini kalau saya diminta untuk membantu Agile transformation, setidaknya saya mau bertemu dan berbicara dengan C-Level, minimal saya harus mendapatkan dukungan dari CIO atau CTO karena saya tahu kemungkinan besar Agile transformation akan gagal tanpa ada toleransi terhadap kegagalan dari pimpinan tertinggi di perusahaan. Bahkan saya pernah beberapa kali mengatakan kepada CEO kalau tim Scrum dia akan gagal selama 4 Sprint kedepan, namun di 4 Sprint itulah mereka paling membutuhkan dukungan paling tinggi dari CEO dan bukan justru disalahkan.
Manajemen yang tidak memberikan toleransi terhadap kegagalan dari Agile transformation justru akan mendapatkan kegagalan. Dan hal tersebut bisa dilihat dari kualitas produknya dan tingkat kebahagiaan timnya.
Tulisan terkait:
2. Tidak ada pembelajaran
Faktor kedua terbesar yang menyebabkan Agile transformation dengan Scrum gagal di tengah jalan adalah tidak adanya pembelajaran. Scrum sendiri setidaknya memiliki 3 kesempatan untuk pembelajaran yakni pada saat Daily Scrum, Sprint Review dan Sprint Retrospectives. Namun dari 3 event pembelajaran ini yang paling penting adalah Sprint Retrospectives.
Banyak tim yang menggunakan Scrum saya temukan tidak menjalankan Sprint Retrospectives. Hal ini seringkali membuat saya kaget karena ini adalah event yang paling penting dalam Scrum karena lewat event inilah tim bisa menjadi semakin baik menuju greatness dari Sprint ke Sprint. Tim Scrum yang tidak menjalankan Sprint Retrospectives mengulangi kesalahan yang sama dari Sprint ke Sprint, akhirnya mereka gagal dan menemukan kalau Scrum tidak jauh lebih baik daripada metode manajemen proyek tradisional. Padahal kalau setiap permasalahan yang ditemukan di Sprint Retrospectives langsung di follow-up kemungkinan mereka bisa menghindari diri mereka dari kegagalan.
Berdasarkan pengamatan saya, alasan utama banyak tim Scrum di Indonesia tidak menjalankan Sprint Retrospectives adalah:
- Nyaman dengan status quo. Hal ini sering sekali saya temukan di institusi pemerintahan dan Badan Usaha Milik Negara (BUMN).
- Tidak ada yang bisa memfasilitasi Sprint Retrospectives dengan baik. Dalam Scrum event ini biasanya bisa difasilitasi oleh Scrum Master. Tidak jarang Scrum Master-nya tidak kreatif dalam memfasilitasi Sprint Retrospectives dan tim tidak menemukan ada masalah sama sekali dalam mereka menjalankan Scrum.
- Tidak ada yang melakukan follow-up terhadap ide untuk improvement yang diajukan oleh development team pada saat Sprint Retrospectives. Hal ini disebabkan oleh masalah yang ditemukan pada saat Sprint Retrospectives adalah permasalahan organisasi yang membutuhkan kekuatan politik yang cukup tinggi untuk memperbaikinya. Misal: CEO yang langsung merubah-ubah ruang-lingkup tanpa lewat Product Owner atau CEO yang memberlakukan Sprint sebagai mini-deadline.
Sprint Retrospectives adalah event favorit saya karena di event ini saya tahu tim dapat menjadi lebih baik dari sebelumnya. Dan terkadang bukan hanya tim yang menjadi lebih baik namun organisasi dimana mereka berada bisa menjadi lebih baik juga. Dalam proses Agile transformation, saya cukup religius melakukan event ini karena tim akan belajar untuk tidak mengulangi kesalahan yang sama. Tidak melakukan Sprint Retrospectives secara regular setiap Sprint adalah resep untuk gagal dalam Agile transformation.
Tulisan terkait:
3. Scrum Master yang tidak master dalam Scrum
Scrum Master yang tidak master dalam Scrum biasanya:
- Tidak memiliki coaching and facilitation skill yang baik.
- Berperilaku seperti manajer proyek atau technical leader atau dari sekretaris pribadi tim.
Menjadi seorang yang master dalam Scrum memerlukan paradigma dan karakter yang berbeda. Peran Scrum Master tidaklah sesederhana mengkonversi seorang manajer proyek atau technical leader menjadi Scrum Master. Peran Scrum Master sangat pivotal dalam Agile transformation karena menurut Scrum Guide Scrum Master bertanggung-jawab untuk memberikan coaching kepada:
- Development Team
- Product Owner
- dan organisasi atau perusahaan dimana dia berada
Saya temukan kebanyakan Scrum Master di Indonesia hanya fokus untuk mengurusi Development Team, beberapa mau memberikan coaching kepada product owner namun hanya sebagian kecil yang memberikan coaching kepada orang-orang lain di dalam perusahaan, seperti marketing, people & culture, bahkan sampai ke C-Level. Oleh karena itu tim melihat kalau Scrum Master tidak lebih dari sekretaris pribadi tim. Berdasarkan pengalaman saya kebanyakan permasalahan atau gangguan untuk lancarnya implementasi Scrum justru ada di luar tim Scrum itu sendiri.
Menjadi seorang Scrum Master memerlukan keahlian yang berbeda. Scrum Master memiliki compassion terhadap orang-orang di dalam perusahaan karena dia ingin adanya perubahan dari cara orang-orang mengembangkan software. Scrum Master juga menekankan profesionalisme dalam mengembangkan software. Selain membutuhkan keahlian yang berbeda, menjadi seorang Scrum Master juga memerlukan nyali yang cukup besar untuk dapat merubah cara berpikir orang-orang di dalam organisasi.
Kalau memiliki seorang Scrum Master yang tidak master dalam Scrum merupakan resep untuk gagal dalam Agile transformation maka tidak memiliki Scrum Master sama sekali adalah pilihan yang lebih buruk lagi karena Scrum Master adalah seorang catalyst perubahan.
Tulisan terkait:
4. Terfokus pada mekanik
Menurut saya pribadi Scrum bukan hanya kerangka kerja yang dapat membantu organisasi develop better software tetapi lewat Scrum organisasi juga terbantu dalam develop happier software developer. Kebanyakan perusahaan yang menggunakan Scrum terfokus pada mekanikanya saja tanpa mempedulikan kebahagiaan software developer dan Scrum core values. Organisasi yang menggunakan Scrum seharusnya lebih fokus terhadap people daripada process bukan sebaliknya karena proses terbaik dihasilkan oleh orang-orang yang dibina dengan baik.
Banyak perusahaan yang terfokus pada mekanika Scrum karena mereka berangkat dari pemahaman kalau Scrum tidak lebih dari metodologi software development daripada sebuah kerangka kerja. Scrum Guide sendiri menuliskan bahwa Scrum dibangun di atas 5 nilai dasar yakni: commitment, focus, respect, openness dan courage. Scrum core values masuk ke dalam satu paket Scrum. Banyak perusahaan di Indonesia yang gagal dalam mendapatkan manfaat dari Scrum karena mereka tidak menanamkan core values, mereka suka dengan sifat iteratif dari Scrum namun mereka tidak bersedia untuk meninggalkan paradigma lama jauh-jauh di lautan yang dalam.
Perusahaan yang hanya fokus pada mekanik daripada core values tidak menitik-beratkan penanaman core values terlebih dahulu ke dalam tim. Hal ini dikarenakan perusahaan yang hanya fokus pada mekanik berpikir kalau:
- Scrum adalah pertemuan berdiri setiap pagi.
- Scrum tidak lebih dari penggunaan JIRA atau Trello.
Dan biasanya perusahaan ini lebih banyak meributkan:
- bagaimana melakukan capacity planning dan estimasi yang akurat;
- bagaimana agar dalam Scrum project tidak ada scope creep;
- bagaimana menulis user story yang detail;
- bagaimana mengukur produktifitas software developer.
Mereka hampir tidak pernah mempertanyakan bagaimana membuat developer lebih bahagia dari sebelumnya ketika menggunakan manajemen proyek tradisional. Mereka tidak memiliki compassion terhadap software developer karena bagi mereka Scrum tidak lebih dari Waterfall yang diperpendek dan dilakukan berulang-ulang. Bagi mereka software developer tidak lebih dari buruh pabrik yang produktifitasnya harus dimaksimalkan. Mereka hampir tidak pernah menggunakan tingkat kebahagiaan developer sebagai metrik sukses namun lebih peduli dengan on-time dan on-budget sebagai metrik sukses walaupun software developer harus menderita karena banyak lembur atau karena pekerjaan yang sering bertambah pada saat Sprint sedang berjalan.
Kebahagiaan software developer dari sudut pandang Scrum sangatlah penting karena: happy developer → productive developer → quality product → profit.
Organisasi yang hanya fokus terhadap mekanik Scrum tidak akan mendapatkan hasil yang maksimal dari penggunaan Scrum dan tidak jarang kembali ke cara kerja lama. Organisasi yang hanya fokus pada mekanik Scrum ketika gagal akan menyalahkan Scrum. Organisasi yang fokus pada Scrum core values akan mendapatkan hasil yang lebih dari penggunaan Scrum karena ketika gagal mereka akan kembali merefleksikan diri mereka kepada Scrum core values.
Tulisan terkait:
5. Tidak ada kepedulian terhadap technical excellence
Banyak tim Scrum di Indonesia yang tidak memiliki Definition of Done yang transparan untuk keseluruhan produk. Atau memiliki Definition of Done tetapi tidak dijalankan secara religius oleh Development Team. Kalau kita baca di Scrum Guide, Definition of Done adalah hal yang wajib dimiliki oleh tim Scrum karena ini adalah definisi dari standard kualitas produk. Tanpa adanya Definition of Done yang jelas maka arti dari selesai menjadi ambigu dan kualitas dari produk dipertanyakan.
Banyak tim Scrum di Indonesia yang cukup religius untuk berdiri setiap pagi namun mereka tidak religius dalam melakukan modern engineering practices. Berdasarkan pengamatan saya ada 4 alasan utama kenapa banyak tim Scrum tidak peduli terhadap modern engineering practices:
- keahlian software developer yang belum mumpuni;
- software developer yang belum terbiasa dengan melakukannya;
- software developer yang memang tidak memiliki kemauan untuk melakukannya;
- atasan yang hanya asal mau cepat jadi — tidak fanatik terhadap kualitas.
Menggunakan Scrum bukan berarti mengabaikan kualitas. Menggunakan Scrum bukan berarti tidak menulis dokumentasi. Menggunakan Scrum bukan berarti cowboy coding. Dengan menggunakan Scrum kualitas produk dan proses seharusnya meningkat. Kualitas dan sustainabilitas produk sangat ditekankan dalam Scrum karena produk yang berkualitas dan sustainable bernilai tinggi untuk pengguna. Dalam Scrum definisi mengenai kualitas software ada di dalam Definition of Done.
Faktor lainnya penyebab implementasi Scrum gagal adalah tidak adanya penggunaan modern engineering practices selama software development. Kualitas kode jorok yang menyebabkan software sulit di-maintain dan tidak stabil. Dan tidak adanya automated test yang menyebabkan fitur dari satu Sprint menimbulkan defect dari fitur yang dikembangkan menyenggol fitur yang dikembangkan di Sprint sebelumnya. Tidak adanya modern engineering practices artinya tim menimbun technical debt. Technical debt tidak bisa dilihat secara kasat mata oleh manajemen. Namun seiring dengan waktu technical debt akan muncul ke permukaan yang menunjukkan kerapuhan sistem. Technical debt hanya merupakan bom waktu yang dapat meledak dan merugikan perusahaan sewaktu-waktu.
Tulisan terkait:
Itulah top 5 faktor kegagalan implementasi Scrum di Indonesia yang saya sering temukan di lapangan. Semoga 5 poin di atas dapat menjadi pembelajaran bagi kita semua yang sedang dalam proses transformasi menuju Agility.
Jangan lupa untuk melihat slide berikut:
Kalau anda dalam proses transisi dari manajemen proyek tradisional menuju Scrum dan menemukan artikel ini membantu anda untuk menghindari kesalahan yang sama yang dilakukan oleh perusahaan lain jangan lupa untuk menekan tombol 💚 di bawah.
Belum membaca buku “Manajemen Modern dengan Scrum” hingga hari ini? Apakah anda adalah manajer atau pimpinan perusahaan yang ingin membuat perubahan di perusahaan anda? Beli buku ini karena buku ini ditulis untuk anda para manajer dan pimpinan perusahaan. Dapatkan buku ini di toko buku terdekat untuk mendapatkan gambaran lebih menyeluruh mengenai Scrum.
