4 Penyebab Terhambatnya Sprint di Codex
Terhitung sejak awal September 2018, tim Codex telah menggunakan metode Scrum dalam melakukan pengembangan produk. Tentang apa yang kami lakukan dan bagaimana kami bekerja, sudah dijelaskan oleh rekan saya pada artikel ini. Pastinya dalam beberapa Sprint yang telah berlangsung, sudah banyak ide-ide baru yang dihasilkan.
Di sisi lain, banyak juga kegagalan yang kami alami ketika menjalani Sprint. Mulai dari tidak tercapainya tujuan dalam Sprint, ketidaksesuaian hasil dengan harapan Product Owner, hingga gagal mendefinisikan backlog dengan baik.
Sebenarnya, apa saja sih hambatan Sprint di Codex? Kali ini saya akan mencoba berbagi pengalaman, mengapa hal tersebut bisa terjadi.
1. Kurangnya dedikasi untuk Skuat
Faktor hambatan pertama yaitu beberapa talenta di tim, tidak berdedikasi sepenuhnya untuk Codex. Kasus ini banyak dialami oleh talenta yang berasal dari internal Telkom. Banyak agenda di luar Codex yang menyebabkan tim tidak bisa berdedikasi penuh di Codex.
Beberapa anggota tim Codex bahkan juga masuk ke dalam Satuan Tugas atau Skuat lainnya. Padahal secara aturan, talenta yang telah masuk ke satu Skuat harus berdedikasi penuh di dalam Skuat tersebut.
Jadi bisa dibilang dedikasi penuh pada Skuat adalah barang yang mahal dan langka untuk diimplementasikan saat ini.
Apa akibatnya? Talenta tersebut menjadi tidak bisa fokus mengerjakan pekerjaan di dalam Skuat-nya, terutama untuk mengerjakan setiap Sprint. Meski sudah dipertimbangkan bobot bebannya, masih saja banyak permintaan mendadak yang dapat memecah dedikasi talenta tersebut. Apalagi jika talenta tersebut memiliki lebih dari satu kapabilitas dan sudah menjadi ahli di bidangnya, akan semakin diandalkan oleh pihak di luar Codex untuk mengerjakan pekerjaan lainnya. Efeknya, ada proses pemindahan pekerjaan yang tidak berjalan lancar, dan review jadi semakin mundur karena tidak ada backlog yang selesai.
2. Ketergantungan dengan arahan
Pada artikel sebelumnya yang bertajuk “How to Work at Codex”, disebutkan bahwa perubahan cara kerja dilakukan melalui perubahan struktur organisasi, hierarchical vs flat. Nyatanya, mentalitas lama seorang karyawan terkadang masih terbawa dalam tim.
Pada awal pembentukan Codex, talenta cenderung hanya menunggu perintah dari Product Owner.
Padahal dalam model Skuat, tim memiliki otonomi yang tinggi dalam pekerjaan sesuai visi di Skuat masing-masing. Tim dituntut untuk memahami pekerjaan sesuai dengan kemampuan mereka masing-masing.
Apa akibatnya? Tim menjadi kurang mandiri dalam mengelola pekerjaannya, terutama melakukan estimasi ketercapaian target pengembangan produk. Namun, hal ini tidak berlangsung lama. Ketika lingkungan menuntut tim untuk bekerja secara otonomi, lama-kelamaan akan terbiasa.
3. Penjabaran masalah kurang detil
Karena tim dituntut mengelola sendiri pekerjaannya, kadang kita tidak memahami secara mendalam permasalahan yang akan diselesaikan. Sehingga masalah tidak terdefinisi secara rinci.
Backlog dengan lingkup masalah yang begitu besar, akan memperlambat proses pemindahan pekerjaan, baik itu ke bagian review maupun ke backlog lain yang memerlukan hasil informasi dari backlog tersebut.
Penjabaran masalah yang rinci dan lebih spesifik akan mempermudah proses pemindahan pekerjaan dan lebih jelas apa yang akan dihasilkan dari setiap backlog. Dengan begitu, jika ada yang perlu diperbaiki, akan lebih cepat perbaikannya. Semua itu diperlukan agar konsep agile bisa berjalan, bukan?
4. Ketergantungan pada Third-party
Banyak pekerjaan yang terlalu bergantung pada pihak ketiga (third-party). Karena itu, ketika mesin (misalnya yang berbasis API) dari third-party yang kita gunakan sedang bermasalah, tim tidak bisa bergerak leluasa untuk memperbaikinya. Hal tersebut otomatis menghambat target waktu penyelesaian backlog.
Hambatan-hambatan di atas saya temukan dari hasil pelaksanaan serangkaian Sprint, mulai dari Sprint Planning, Daily Standup, Sprint Review hingga Sprint Retrospective. Dengan menemukan hambatan-hambatan tersebut, saya harap tim bisa langsung mencari solusi untuk menyelesaikannya, atau minimal menguranginya, agar tidak mengganggu keberlangsungan dan ketercapaian tujuan Sprint.
