<< Kembali ke daftar layanan AgileCampus.org

Crash Couse (kb): materi edukasi yang membahas kulit satu topik secara menyeluruh, namun sesingkat mungkin sehingga cocok untuk pemula.

Scrum (kb): sebuah bingkai kerja untuk membantu orang-orang menangani masalah yang kompleks & adaptif, sembari secara produktif dan kreatif menghantarkan produk dengan nilai manfaat tertinggi (Scrum Guide, 2013).

Tentang penulis: Rizky Syaiful adalah satu dari sedikit pelatih di Indonesia yang memiliki dua sertifikasi internasional dari Scrum.org. Setelah satu tahun ikut melatih klien-klien perusahaan edukasi Scrum berskala Asia Pasifik, Rizky menulis buku “Filosofi Agile & Panduan Scrum” (linkedin). 

Lingkup

Pertama-tama, mari kita bahas lingkup-lingkup dari Scrum.

Scrum adalah salah satu bingkai kerja dari keluarga besar agile software development.

Sebagai bingkai kerja, domain Scrum adalah manajemen, atau lebih tepatnya, manajemen pengembangan software (beberapa menyebutnya project management). Fokus Scrum adalah pengelolaan kebutuhan bisnis & pembagian pengerjaan teknisnya. Kebetulan Scrum juga tidak mengatur sisi teknologi dari pengembangan.

Sebagaimana yang Scrum Guide definisikan, Scrum hanya membatasi diri pada masalah kompleks & adaptif. Artinya, meski belum umum, Scrum sebenarnya juga bisa diterapkan di proses pengembangan non-software—selama produk itu cukup kompleks & adaptif.

Komunitas pengembang software sendiri sepakat: mayoritas pekerjaan mereka adalah masalah yang kompleks.

Gambar 1: Scrum Guide mengambil istilah dari teori Cynefin. Di masalah complicated, solusi tinggal ditanyakan ke pakar atau buku. Di masalah kompleks, solusi terungkap perlahan, sedikit demi sedikit, sebagai akibat dari proses implementasi tiap solusi kecil sebelumnya (emergent). Entrepreneurship adalah contoh lain masalah kompleks.

Gambar 2: Pembuatan software jarang sebuah pekerjaan yang berulang. Kebutuhan software sulit dibayangkan penuh di awal, teknologi pembuatannya juga luas dan cukup sering memerlukan riset. Faktor-faktor tersebut menyebabkan dia masuk ke masalah kompleks.

Manfaat

Sebelum mengadaptasi sesuatu yang baru, tentu kita selalu mencoba menghitung ROI (return on investment)-nya. Begitu juga dengan adaptasi Scrum.

Saya tidak akan menyebutkan satu per satu manfaat-manfaat Scrum—karena bisa sangat kontekstual. Mudahnya, sepanjang crash couse ini, akan

1. saya ceritakan kasus ekstrim di mana Scrum akan membantu,
2. saya ceritakan kasus ekstrim di mana Scrum tidak akan membantu,
3. saya ceritakan secara apa itu Scrum dalam gambaran besar, lalu,
4. silahkan bayangkan sendiri kasus yang terjadi di lapangan Anda & bagaimana Scrum bisa membantu.

Cukup adil, efektif, & efisien menurut saya—yang bahkan menawarkan jasa training Scrum. So, stay tuned with the crash course.

Kapan Scrum akan bermanfaat?

Saat orang bisnis (baca: calon pengguna / periset desain software) lebih memilih untuk menjabarkan keinginannya yang (seringnya) luas bin ambigu, lalu menghilang, dan muncul lagi menjelang deadline.

Di tengah waktu menghilangnya orang bisnis, pengembang software sendiri (termasuk bos-bos mereka) tidak berinisiatif menghubungi orang bisnis. Mereka memilih untuk berkerja berdasarkan jabaran keinganan yang luas bin ambigu itu. Pengembang software yang belum profesional, biasanya juga membuat asumsi akan hal-hal yang tidak didetailkan orang bisnis.

Alasan pengembang software menghindari orang bisnis adalah karena mereka takut diminta ini-itu: hal-hal yang di luar / belum didetailkan di saat deal pengerjaan di awal. Kenapa takut?

1. Takut pekerjaan baru itu dikerjakan tanpa dibayar / perpanjangan deadline.
2. Takut mengganggu konsentrasi pengerjaan yang sedang berlangsung.

Awalnya, bos-bos cukup khawatir dengan pola kerja pengembang software. Mengingat waktu ‘menghilangnya orang bisnis’ rata-rata bisa 2 bulan, sifat pengembang software yang suka santai di awal (baca: prokrastinasi) membuat para bos garuk-garuk kepala. Prokrastinasi juga dirasa salah satu faktor kenapa pengembang software sulit terbuka menceritakan presentase pengembangan. Setelah mencoba berbagai cara untuk mengubah sifat tersebut, akhinya para bos menyerah. Sifat tersebut diakali dengan menggilir berbagai inisiatif pengembangan software, sedemikian rupa sehingga selalu ada deadline dalam waktu dekat. Tentu trik ini hanya bisa dilakukan saat inisiatif pengembangan cukup banyak mengantri.

Setelah berpisah cukup lama, akhirnya orang bisnis dan pengembang software bertemu kembali. Software yang sudah dikerjakan ditunjukkan ke orang bisnis.

Ada kemungkinan orang bisnis merasa kecewa, merasa yang dibuat tidak seperti yang dia maksud di awal. Ada kemungkinan mereka puas. Yang lebih pasti, dengan sudah adanya software di tangan, orang bisnis jadi terpikir ide-ide baru untuk software. Ide-ide itu kadang bukan hanya penambahan, tapi bisa berupa perubahan dari apa yang sudah dikerjakan. Perubahan itu membuat sedih pengembang software. Tentu karena mereka sudah kurang tidur beberapa hari untuk mengejar deadline.

Umumnya setelah pertemuan dengan orang bisnis akan dihasilkan rencana pengerjaan baru. Orang bisnis biasanya akan mencoba agar rencana pengerjaan baru tersebut jadi bagian dari komitmen di awal (baca: hutang pekerjaan). Dengan begitu, mereka bisa meminta tambahan pekerjaannya diselesaikan sesegera mungkin dan—yang paling penting—tanpa biaya tambahan. Pihak pengembang software tentu menentang hal tersebut. Setelah ditemukan titik tengah, siklus serupa kembali berulang.

Kapan Scrum tidak bermanfaat?

Saat orang bisnis sudah cukup dekat dengan pengembang software, baik secara fisik maupun emosional.

Sebelum proses pengerjaan dimulai, semua pihak-pihak kunci (orang bisnis, tim UI/UX, pakar dari luar, dan pengembang software yang cukup senior) duduk bersama untuk merancang desain software yang akan dibuat, secara detail, namun fokus.

Jangan bayangkan desain software yang besar. Mereka hanya mendesain potongan kecil fitur baru, guna menyelesaikan masalah nyata pengguna, yang paling penting dan mendesak. Prinsip seperti itu selalu mereka tegakkan, bahkan sejak hari ke-0, sejak software hanyalah sebuah ide belaka. Desain software untuk rilis pertama mereka amat minimalis, dan hanya fokus di fungsi dasar (MVP—minimum viable product).

Bagi yang sudah lebih profesional, desain software didetailkan dalam bentuk hi-fidelity prototype. Warnanya, bentuk tombolnya, ruang kosong, semua elemen visual dan interaksi dibuat identik dengan software sebenarnya. Bahkan tidak hanya sisi visual yang statik, prototype juga dapat dijalankan di smartphone / tab / browser, bisa diklik dan berinteraksi persis seperti software asli. Dengan hi-fidelity prototype, desain software benar-benar bisa dimatangkan—sebelum menulis satu barispun kode. Mereka umumnya melakukan beberapa iterasi desain, yang bahkan telah divalidasi oleh sampel pengguna nyata di lapangan.

Nyaman dengan desain potongan kecil fitur yang sudah diiterasi dan divalidasi secara bisnis, fokus selanjutnya adalah para pengembang software. Karena setidaknya ada perwakilan pengembang software ikut dalam fase desain, sudah terkonfirmasi kalau memang hi-fidelity prototype-nya bisa dibuat secara teknis. Terkait berapa lama waktu yang dibutuhkan untuk pengerjaannya, semua dipercayakan ke para pengembang. Orang bisnis sadar secara penuh kalau mereka tidak tahu domain teknis.

Tentu pengembang software ditanyai estimasi lama pengerjaan. Menariknya, bagi orang bisnis, estimasi tidak jadi deadline. Tidak ada pinalti jika pengerjaan melewati estimasi. Orang bisnis paham betul Cone of Uncertainty yang di software engineering bisa sampai skala 4—waktu pengerjaan jadi 400% dari waktu estimasi (Boehm 1981, divalidasi oleh NASA tahun 1990). Dengan kepercayaan tersebut, pengembang software mendapatkan kenyamanan untuk “ship the code, only when it’s ready”. Kenyamanan tersebut membuat para pengembang software tidak merasa takut untuk terbuka terkait status pengembangan mereka—termasuk masalah-masalah yang muncul di tengah jalan. Para pengembang software memang terus memperbaiki manajemen kerja internal mereka. Mereka diberi kebebasan untuk memperbaiki performa dan transparansi mereka.

Orang bisnis bukannya buta terhadap resiko saat pengembangan potongan fitur kecil tersebut. Mereka tentu punya proyeksi best case dan worst case kapan dia selesai. Apa yang membuat orang bisnis cukup merasa aman adalah: (1) pengalaman berkerja dengan para pengembang software, (2) komunikasi yang intens dan transparan, (3) budaya kerja pengembang software yang memang terlihat dan dirasa bagus, (4) kecilnya potongan fitur yang dikerjakan.

Umumnya, setelah kode siap untuk dirilis, hi-fidelity prototype fitur kecil selanjutnya sudah siap untuk dikerjakan para pengembang software.

Scrum

Scrum memang ringan, namun bukan berarti sisi mekaniknya bisa dijelaskan secara penuh dalam waktu satu menit (ingat: crash course bukan tempat penjelasan yang detail).

Setiap kali dapat kesempatan menjelaskan Scrum secara singkat, saya selalu memastikan kalau setidaknya bisa menyampaikan tiga hal ini: (1) Product Backlog, (2) Sprint, (3) Perbedaan Product Owner & Scrum Master. Oleh karenanya, mari kita pahami Scrum lewat tiga pintu tersebut.

Product Backlog

Tumpukan Dinamis Pekerjaan dalam Bahasa Bisnis

Scrum, sebagaimana manajemen pengembangan software pada umumnya, kebanyakan adalah tentang komunikasi kebutuhan bisnis dengan pengembangan software.

Di Scrum, tulang punggung komunikasi tersebut ada di Product Backlog. Di gaya Waterfall (sebelum ramai agile software development di tahun 90-an), Product Backlog mungkin setara dengan Software Requirement Specification, sebuah dokumen yang menulis semua kebutuhan pekerjaan yang fungsional maupun non-fungsional, dari proyek pengembangan software.

Bayangkan Software Requirement Specification yang pekerjaan-pekerjaannya diurutkan berdasarkan prioritas dari sisi bisnis. Pengembang software diharapkan menyelesaikan pekerjaan berdasarkan urutan-urutan tersebut. Dengan begitu, versi terpenting dari software bisa tersedia lebih awal—sebelum semua pekerjaan selesai dikerjakan—dan langsung digunakan oleh pengguna.

Bayangkan juga tumpukan pekerjaan-pekerjaan yang belum selesai tersebut fleksibel diubah di tengah pengembangan: (1) baik sekedar diubah urutannya, (2) dikurangi pekerjaan di tumpukan, (3) ditambah pekerjaan baru ke tumpukan, (4) diubah deskripsi detail dari pekerjaan.

Sprint

Iterasi dengan Lama Waktu Tetap

Sprint adalah satu masa di mana pengembang fokus mengerjakan potongan kecil software sampai siap-rilis (frontend, backend, semua berfungsi dan sudah dites). Potongan kecil software-nya sendiri harus diambil dari pucuk paling atas Product Backlog.

Tidak ada jeda antar sprint. Hal ini berarti, di sepanjang pengembangan, sprint selalu ada. Lama waktu Sprint sendiri maksium satu bulan dan tidak berubah sepanjang pengembangan.

Salah satu faktor penting yang membuat Scrum umumnya lebih cepat dari waterfall, adalah lebih banyaknya ‘deadline-deadline’ kecil. Mereka terepresentasi di sprint-sprint.

Kenapa saya menggunakan tanda kutip? Karena di Scrum, ‘deadline’ ditentukan oleh tim pengembang sendiri. Waktu Sprint memang selalu tetap, tapi besar potongan yang akan dikerjakan dalam satu Sprint adalah hak prerogatif pengembang software secara kolektif. Ini penting, karena Scrum banyak disalahgunakan sebagai alat peras pengembang software.

Di Scrum, ‘deadline’ ditentukan oleh tim pengembang sendiri … Ini penting, karena Scrum sering disalahgunakan sebagai alat peras pengembang software.

Tidak seperti Product Backlog, yang umumnya ada di hampir semua bingkai kerja agile software development lain, sprint adalah ciri khas Scrum.

Product Owner & Scrum Master

Duet Project Management

Di Waterfall, terdapat satu peran pemimpin pengembangan. Tugasnya adalah membuat pengembangan jadi ‘on time, on scope, on budget’. Nama umumnya adalah Project Manager.

Di Scrum, peran tersebut dipecah ke Product Owner & Scrum Master. Scrum menganggap, digabungnya dua peran tersebut adalah salah satu penyebab utama beratnya beban hidup pengembang software.

Product Owner bertugas memaksimalkan nilai bisnis dari software dengan segala sumber daya yang tersedia. Product Owner memimpin perancangan software. Menemukan ‘right scope’ adalah tanggung jawab dia, dan riset pasar adalah pekerjaan rutin dia. Kebutuhan bisnis, juga harus bisa dia terjemahkan menjadi arahan software yang tertuang dalam Product Backlog. Betul, Product Backlog adalah wilayah kekuasaan Product Owner—meski bukan berarti dia yang harus menulis.

Berbagai pihak juga bisa bertanya ke Product Owner, “kapan fitur X bisa dirilis?”, atau, “4 bulan lagi kira-kira kita sudah selesai apa saja?”. Product Owner memang harus memantau laju pengembangan dan memberikan waktu estimasi dengan ‘error rate’ yang cukup aman ke pihak-pihak luar. Waktu dan dana memang sumber daya yang perlu Product Owner kelola demi nilai bisnis software yang maksimal.

Menariknya, Product Owner tidak punya akses untuk mengelola pengembang software. Scrum melarang Product Owner, dengan cara apapun, mendikte jumlah pekerjaan pengembang software.

Di situ letak peran Scrum Master.

Bukan, bukan Scrum Master boleh mendikte jumlah pekerjaan. Tapi Scrum Master bertanggung jawab pada budaya kerja tim pengembang software. Melihat peran Product Owner di atas, nampaknya masuk akal kalau kepercayaan Product Owner terhadap performa pengembang software (secara kolektif) adalah harga mati.

Sebagai jangkar budaya kerja tim, tentu Scrum Master pertama-tama harus diterima dan dihargai oleh pengembang software. People skill is a must for a Scrum Master. Salah satu hal yang membuat Scrum Master mudah diterima, adalah fakta bahwa dia tidak mengurus hal-hal di wilayah Product Owner. Dengan begitu, makin kecil kemungkinan pengembang software melihat Scrum Master hanya sebagai kepentingan Product Owner.

Ada aturan Scrum yang melindungi pengembang software dari eksploitasi. Ada aturan Scrum yang membuat Product Owner bisa fokus terhadap pekerjaannya. Scrum Master memang bertugas menegakan aturan-aturan tersebut.

Sumber Gambar