Salah Implementasi Scrum, Harus Bagaimana?
Sudah baca artikel saya sebelumnya tentang hambatan dalam menjalani Scrum? Banyak penyebabnya telah diulas di artikel tersebut, salah satunya yang paling sering terjadi adalah adanya kesalahan dalam implementasi Scrum.
Kalau bingung apa itu Scrum, boleh cek di tulisan ini ya:
Beberapa hari lalu, saya sempat diskusi dengan seorang teman lama. Dia merupakan seorang Scrum Master di salah satu perusahaan digital di Indonesia. Dia berpendapat bahwa beberapa kesalahan implementasi Scrum tersebut memang valid terjadi, terutama pada tim yang baru beradaptasi dengan framework Scrum.
So, what? Apa yang perlu kita lakukan?
Kali ini, saya mau cerita nih, bagaimana caranya Codex bisa memperbaiki implementasi Scrum di timnya. Codex sendiri yang notabene merupakan tim yang baru beradaptasi dengan Scrum, akhirnya bisa keluar dari permasalahan tersebut.
Ada beberapa kunci penting bagi tim yang sedang beradaptasi dengan Scrum. Check this out.
1. Peran Product Owner
Product Owner bukanlah customer dari tim Scrum, namun merupakan bagian dari kesatuan tim Scrum itu sendiri. Tugas umum seorang Product Owner adalah menerjemahkan dan mengomunikasikan visi dan misi produk, membangun prioritas, dan yang paling penting adalah menerima suara dari pelanggan.
Secara praktik di dalam tim Scrum, Product Owner secara fisik harus duduk bersama tim setiap hari dan terus bekerja untuk menyampaikan visi produk pada tim Development. Dengan begitu, mereka dapat memperoleh pemahaman yang jelas tentang gambaran besar produk dan dapat membuat keputusan produk yang lebih intuitif.
Sebaliknya, tim Development harus terus-menerus menjelaskan aspek teknis produk sehingga Product Owner dapat memperoleh pemahaman yang jelas tentang kemampuan teknologi, keterbatasan, dan kelayakannya. Jika Product Owner diperlakukan sebagai pelanggan, hal tersebut bisa mengurangi ikatan emosional di dalam tim dan mengurangi kepercayaan dalam pengembangan produk, sehingga menciptakan kesenjangan pemahaman dan komunikasi.
2. Peran Scrum Master
Secara umum, Scrum Master bertugas untuk memfasilitasi aktivitas Sprint dan membantu mengurangi hambatan yang terjadi dalam pelaksanaan Sprint. Namun, pada tim Scrum yang sukses, Scrum Master adalah seorang Coach dan Mediator, yang tugasnya adalah menjamin tim terintegrasi dengan baik, berkomunikasi dengan jelas, mencari pemahaman masalah yang tepat, meredam konflik, berkomitmen pada prinsip Scrum, dan memacu eksperimentasi untuk perbaikan yang berkelanjutan.
Namun pada praktiknya, Scrum Master hanya bertugas untuk mengatur waktu Scrum Event diadakan, mulai dari Sprint Planning, Daily Standup, Sprint Review, hingga Retrospective. Padahal, Scrum Event dapat berjalan lancar ketika bisa diagendakan bersama.
Scrum Master adalah kunci dalam membangun tim yang agile; yang matang dari sisi kapabilitas, pemahaman terhadap masalah, serta bisa mengelola kompetensi masing-masing anggota tim dalam ketercapaian pengembangan produk.
3. Sprint Planning
Tujuan adanya Sprint Planning adalah menjamin semua pekerjaan prioritas, telah terdefinisikan dengan jelas dan dapat dieksekusi oleh tim, serta memiliki kriteria keberhasilan yang dipahami bersama. Tujuan dari Sprint Planning bukanlah untuk berkomitmen pada ukuran produktivitas yang ketat dan cepat, namun untuk menilai seberapa baik sebuah tim dalam memikirkan dan mendefinisikan sebuah tugas.
Di sisi lain, Story Point sebenarnya bukanlah ukuran usaha, melainkan ukuran kompleksitas. Diberikan Story Point sebesar 3 apabila semua variabel telah diketahui dan pekerjaan yang akan dilakukan cukup sederhana. Diberikan Story Point 8 apabila variabel belum jelas dan pekerjaan cukup rumit. Begitu pula dengan Story Point lainnya.
Tim lah yang bertanggung jawab untuk menentukan Story Point sendiri, sesuai dengan kompetensi yang dimiliki.
4. Daily Standup
Daily Standup adalah salah satu Scrum Event yang cukup penting. Tujuannya untuk melakukan update harian, sehingga kendala setiap anggota tim bisa diketahui, serta menjadi media untuk mendapatkan bahan diskusi berikutnya.
Namun pada praktiknya, Daily Standup hanya dijadikan acara formalitas untuk melakukan update personal, tanpa mempertimbangkan pekerjaan anggota tim yang lain. Padahal, sangat memungkinkan adanya pekerjaan yang serupa dengan anggota tim lain, sehingga setiap orang harus membuat strategi bagaimana semua pekerjaan bisa selesai tanpa menghambat pekerjaan anggota tim lainnya.
Jadi, tim dituntut harus menyelesaikan permasalahan yang didapat saat Daily Standup, dan solusinya harus sudah didapat sebelum Daily Standup berikutnya.
5. Retrospective
Retrospective merupakan seremonial terpenting dalam seluruh proses Scrum. Jika tim tidak melakukan Retrospective dengan sungguh-sungguh di akhir setiap Sprint, maka tim tersebut telah mengabaikan prinsip dasar dalam pengembangan produk yang agile.
Dalam Retrospective, tim dituntut untuk mengidentifikasi apa yang berfungsi dan yang tidak, dalam proses yang sudah berjalan. Selain itu, Retrospective juga merupakan kesempatan untuk bertukar pikiran, serta berkomitmen untuk mencoba hal baru.
Dalam praktiknya, banyak tim yang mengabaikan Retrospective. Mereka justru memanfaatkan momen tersebut untuk berdiskusi mengenai fitur maupun produk. Padahal, apabila mereka telah bertemu dengan pelanggan yang menanggapi fitur atau produk, mereka cenderung mempermasalahkan apa yang salah dari produk tersebut, tanpa mempertimbangkan cara kerja hingga solusinya.
Model standar dari Retrospective adalah Start, Stop dan Continue. Ini adalah cara untuk memecah dan menganalisis komunikasi dalam tim.
Selain itu, momen ini juga merupakan peluang untuk mengidentifikasi masalah dalam proses kerja yang mengakibatkan inefisiensi, serta berguna untuk merancang eksperimen dalam mengatasinya.
Contohnya “Kita harus berhenti memaksa Sprint untuk segera dimulai setelah menyelesaikan Sprint sebelumnya, dan melakukan tugas yang terlalu kompleks. Kita harus mulai menetapkan ekpektasi bahwa Sprint Planning akan memiliki satu atau dua output menarik untuk produk kita, dan diadakan setelah semua kekurangan telah dicatat dengan baik. Hanya dengan demikian, kita akan benar-benar dapat berkomitmen pada Sprint dan mengeksekusi secara efektif.”
Jadi kalau kalian merasa tidak ada bedanya antara cara lama dan ketika implementasi Scrum, mungkin beberapa tip di atas bisa memberikan inspirasi untuk memperbaiki tim menjadi lebih baik.
If you can’t solve a problem, then manage it.
Jadi, semua itu pasti ada harapan buat jadi lebih baik kok :).
Tunggu tulisan saya berikutnya ya.
