Apa itu Scrum ?

Scrum adalah pendekatan gesit untuk mengembangkan produk dan layanan inovatif. Gambar 1.1
menunjukkan pendekatan pengembangan yang sederhana, generik, dan gesit. Dengan pendekatan
yang gesit, Anda mulai dengan membuat jaminan produk — daftar fitur dan kemampuan lain yang
diprioritaskan untuk mengembangkan produk yang sukses. Dipandu oleh jaminan produk, Anda
selalu mengerjakan item yang paling penting atau prioritas tertinggi terlebih dahulu. Saat Anda
kehabisan sumber daya (seperti waktu), pekerjaan apa pun yang tidak selesai akan menjadi prioritas
lebih rendah dari pekerjaan yang selesai.

Pekerjaan itu sendiri dilakukan dalam iterasi pendek, timebox, yang biasanya berkisar dari satu
minggu hingga satu bulan kalender. Selama setiap iterasi, tim lintas-fungsi yang mengatur diri sendiri
melakukan semua pekerjaan — seperti merancang, membangun, dan menguji — diperlukan untuk
menghasilkan fitur kerja yang lengkap dan bisa dimasukkan ke dalam produksi.

Biasanya jumlah pekerjaan dalam jaminan produk jauh lebih besar daripada yang bisa diselesaikan
oleh tim dalam satu iterasi durasi pendek. Jadi, pada awal setiap iterasi, tim merencanakan subset
yang mana dari prioritas tinggi dari produk yang akan dibuat dalam iterasi yang akan datang. Pada
Gambar 1.1, misalnya, tim telah sepakat bahwa ia dapat membuat fitur A, B, dan C. Pada akhir
iterasi, tim meninjau fitur yang sudah selesai dengan para pemangku kepentingan untuk
mendapatkan umpan balik mereka. Berdasarkan umpan balik, pemilik produk dan tim dapat
mengubah apa yang mereka rencanakan untuk dikerjakan selanjutnya dan bagaimana tim berencana
untuk melakukan pekerjaan tersebut. Misalnya, jika pemangku kepentingan melihat fitur yang
lengkap dan kemudian menyadari bahwa fitur lain yang tidak pernah mereka pertimbangkan juga
harus dimasukkan dalam produk, pemilik produk dapat dengan mudah membuat item baru yang
mewakili fitur tersebut dan memasukkannya ke dalam jaminan simpanan produk dengan benar.
untuk dikerjakan dalam iterasi masa depan. Pada akhir setiap iterasi, tim harus memiliki produk yang
berpotensi dapat dikirim (atau penambahan produk), yang dapat dirilis jika sesuai. Jika melepaskan
setelah setiap iterasi tidak sesuai, satu set fitur dari beberapa iterasi dapat dirilis bersamaan.
Why Scrum?

Jadi apa yang membuat pendekatan gesit seperti Scrum pilihan yang baik untuk Genomica? Pertama,
jelas bahwa pendekatan Genomica sebelumnya untuk pengembangan tidak berhasil. Itu adalah
berita buruk; kabar baiknya adalah kebanyakan orang setuju. Genomica beroperasi dalam domain
kompleks di mana lebih banyak yang tidak diketahui daripada diketahui.

Kami membangun produk yang belum pernah dibangun sebelumnya. Fokus kami adalah pada
platform informatika penemuan mutakhir yang terus berkembang, terus berkembang, mutakhir
yang akan digunakan para ilmuwan penelitian untuk membantu menemukan molekul blockbuster
berikutnya. Kami membutuhkan cara

pengembangan yang akan memungkinkan kita untuk dengan cepat mengeksplorasi ide-ide dan
pendekatan baru dan belajar dengan cepat solusi mana yang layak dan mana yang tidak. Kami
memiliki mitra korporat strategis yang kepadanya kami perlu menunjukkan hasil kerja setiap
beberapa minggu atau lebih untuk mendapatkan umpan balik, karena produk kami harus
berintegrasi dengan garis inti sekuensing DNA.

Kebutuhan akan eksplorasi dan umpan balik yang cepat ini tidak sesuai dengan perencanaan awal
yang kami lakukan. Kami juga ingin menghindari desain arsitektur besar di muka. Upaya sebelumnya
untuk menciptakan generasi berikutnya dari produk inti Genomica telah membuat organisasi
menghabiskan hampir satu tahun melakukan pekerjaan yang hanya menggunakan arsitektur untuk
menciptakan platform bioinformatika besar dan terpadu. Ketika aplikasi nyata yang menghadap
ilmuwan ditempatkan di atas arsitektur itu, dan kami akhirnya memvalidasi keputusan desain yang
dibuat berbulan-bulan sebelumnya, itu

butuh 42 detik untuk tab dari satu bidang di layar ke bidang berikutnya. Jika Anda berpikir pengguna
biasa tidak sabar, bayangkan seorang ahli biologi molekuler dengan gelar Ph.D. harus menunggu 42
detik! Itu adalah bencana. Kami membutuhkan pendekatan desain yang berbeda dan lebih
seimbang, yang mencakup beberapa desain di muka dikombinasikan dengan dosis sehat dari desain
yang baru muncul. Kami juga ingin tim kami menjadi lebih lintas fungsional. Secara historis Genomica
beroperasi seperti kebanyakan organisasi. Pengembangan akan memberikan pekerjaan kepada tim
uji hanya setelah itu selesai sepenuhnya. Kami sekarang memiliki keinginan agar semua anggota tim
sering melakukan sinkronisasi — setiap hari adalah tujuannya. Di masa lalu, kesalahan diperparah
karena isu-isu penting sedang dibahas terlambat dalam upaya pembangunan. Orang-orang di
berbagai daerah tidak cukup sering berkomunikasi. Untuk alasan ini, dan yang lainnya, kami
memutuskan bahwa Scrum akan cocok untuk Genomica
Organisasi-organisasi ini berulang kali memuaskan pelanggan mereka dengan memberi mereka apa
yang sebenarnya mereka inginkan, bukan hanya fitur yang mungkin mereka tentukan pada hari
pertama ketika mereka tahu paling sedikit tentang kebutuhan mereka yang sebenarnya. Mereka
juga melihat pengembalian investasi yang lebih baik dengan memberikan rilis yang lebih kecil, lebih
sering. Dan, dengan tanpa henti mengungkap disfungsi dan pemborosan organisasi, organisasi-
organisasi ini mampu mengurangi biaya. Fokus Scrum dalam memberikan fitur yang berfungsi,
terintegrasi, teruji, bernilai bisnis setiap iterasi mengarah pada hasil yang disampaikan dengan cepat.
Scrum juga sangat cocok untuk membantu organisasi berhasil di dunia yang kompleks di mana
mereka harus cepat beradaptasi berdasarkan tindakan yang saling berhubungan dari pesaing,
pelanggan, pengguna, badan pengawas, dan pemangku kepentingan lainnya. Dan Scrum
memberikan lebih banyak kegembiraan bagi semua peserta. Tidak hanya pelanggan senang, tetapi
juga orang-orang yang melakukan pekerjaan benar-benar menikmatinya! Mereka nikmati kolaborasi
yang sering dan berarti, yang mengarah pada peningkatan hubungan interpersonal dan rasa saling
percaya yang lebih besar di antara anggota tim

Scrum Framework

Scrum bukanlah proses standar di mana Anda secara sistematis mengikuti serangkaian langkah
berurutan yang dijamin untuk menghasilkan, tepat waktu dan sesuai anggaran, produk berkualitas
tinggi yang menyenangkan pelanggan. Sebaliknya, Scrum adalah kerangka kerja untuk mengatur dan
mengelola pekerjaan. Kerangka kerja Scrum didasarkan pada serangkaian nilai, prinsip, dan

praktik-praktik yang memberikan fondasi di mana organisasi Anda akan menambahkan

penerapannya yang unik dari praktik-praktik rekayasa terkait dan pendekatan spesifik Anda untuk
mewujudkan praktik-praktik Scrum. Hasilnya akan menjadi versi Scrum yang unik milik Anda. Untuk
lebih memahami konsep kerangka kerja, bayangkan bahwa kerangka kerja Scrum seperti
fondasi dan dinding bangunan. Nilai-nilai, prinsip, dan praktik Scrum akan menjadi komponen
struktural utama. Anda tidak dapat mengabaikan atau secara fundamental mengubah nilai, prinsip,
atau praktik tanpa risiko runtuh. Namun, yang dapat Anda lakukan adalah menyesuaikan di dalam
struktur Scrum, menambahkan perlengkapan dan fitur hingga Anda memilikinya sebuah proses yang
bekerja untuk Anda. Scrum adalah kerangka kerja sederhana yang berfokus pada orang-orang
berdasarkan nilai-nilai kejujuran, keterbukaan, keberanian, rasa hormat, fokus, kepercayaan,
pemberdayaan, dan kolaborasi.

Scrum Role
Pemilik produk bertanggung jawab atas apa yang akan dikembangkan dan dalam urutan apa.
ScrumMaster bertanggung jawab untuk memandu tim dalam menciptakan dan mengikuti prosesnya
sendiri berdasarkan kerangka kerja Scrum yang lebih luas. Tim pengembang bertanggung jawab
untuk menentukan bagaimana menyampaikan apa yang diminta oleh pemilik produk

Product Owner

Pemilik produk adalah titik sentral dari kepemimpinan produk yang diberdayakan. Dia adalah
otoritas tunggal yang bertanggung jawab untuk memutuskan fitur dan fungsionalitas mana yang
akan dibangun dan urutan pembuatannya. Pemilik produk memelihara dan berkomunikasi dengan
semua peserta lain visi yang jelas tentang apa yang ingin dicapai oleh tim Scrum. Dengan demikian,
pemilik produk bertanggung jawab atas keberhasilan keseluruhan solusi yang sedang dikembangkan
atau dipelihara.

ScrumMaster

ScrumMaster membantu semua orang yang terlibat memahami dan merangkul nilai-nilai, prinsip,
dan praktik Scrum. Dia bertindak sebagai pelatih, memberikan proses kepemimpinan dan membantu
tim Scrum dan seluruh organisasi mengembangkan sendiri kinerja tinggi mereka, pendekatan Scrum
khusus organisasi. Pada saat yang sama, ScrumMaster membantu organisasi melalui proses
manajemen perubahan yang menantang yang dapat terjadi selama adopsi Scrum.

Development team

Pendekatan pengembangan perangkat lunak tradisional membahas berbagai jenis pekerjaan, seperti
arsitek, pemrogram, penguji, administrator basis data, perancang UI, dan sebagainya. Scrum
mendefinisikan peran tim pengembangan, yang merupakan kumpulan beragam fungsi lintas tipe
orang yang bertanggung jawab untuk merancang, membangun, dan menguji produk yang
diinginkan.

Scrum Activity
Product backlog

Menggunakan Scrum, kami selalu melakukan pekerjaan yang paling berharga terlebih dahulu.
Pemilik produk, masukan dari tim Scrum dan pemangku kepentingan lainnya, pada akhirnya
bertanggung jawab untuk menentukan dan mengelola urutan pekerjaan ini dan
mengkomunikasikannya dalam bentuk daftar prioritas (atau dipesan) yang dikenal sebagai jaminan
produk (lihat Gambar 2.4). ). Pada pengembangan produk baru, item jaminan simpanan produk pada
awalnya adalah fitur diperlukan untuk memenuhi visi pemilik produk. Untuk pengembangan produk
yang sedang berlangsung, simpanan produk mungkin juga mengandung fitur baru, perubahan pada
fitur yang ada, cacat yang perlu diperbaiki, peningkatan teknis, dan sebagainya. Pemilik produk
berkolaborasi dengan pemangku kepentingan internal dan eksternal untuk mengumpulkan dan
menentukan item simpanan produk. Dia kemudian memastikan bahwa item jaminan produk
ditempatkan dalam urutan yang benar (menggunakan faktor-faktor seperti nilai, biaya,
pengetahuan, dan risiko) sehingga item bernilai tinggi muncul di bagian atas jaminan produk dan
item bernilai lebih rendah muncul ke arah bagian bawah.
Tumpukan produk adalah artefak yang terus berkembang. Item dapat ditambahkan, dihapus, dan
direvisi oleh pemilik produk ketika kondisi bisnis berubah, atau seiring pemahaman tim Scrum
tentang produk tumbuh (melalui umpan balik pada perangkat lunak yang dihasilkan selama setiap
sprint). Secara keseluruhan aktivitas membuat dan menyempurnakan item jaminan simpanan
produk, memperkirakannya, dan memprioritaskannya dikenal sebagai perawatan

Sprints

Dalam Scrum, pekerjaan dilakukan dalam iterasi atau siklus hingga satu bulan kalender yang disebut
sprint (lihat Gambar 2.7). Pekerjaan yang diselesaikan dalam setiap sprint harus menciptakan
sesuatu yang bernilai nyata bagi pelanggan atau pengguna. Sprint adalah kotak waktu sehingga
mereka selalu memiliki tanggal mulai dan berakhir yang tetap, dan umumnya mereka semua
memiliki durasi yang sama. Sprint baru segera mengikuti selesainya sprint sebelumnya. Sebagai
aturan, kami tidak mengizinkan perubahan lingkup atau personel yang mengubah tujuan selama
sprint; namun, kebutuhan bisnis terkadang membuat kepatuhan terhadap aturan ini menjadi tidak
mungkin

Sprint Planning

Tumpukan produk mungkin mewakili pekerjaan berminggu-minggu atau berbulan-bulan, yang jauh
lebih banyak daripada yang bisa diselesaikan dalam satu sprint pendek. Untuk menentukan subset
paling penting dari item tumpukan produk untuk dibangun di sprint berikutnya, pemilik produk, tim
pengembangan, dan ScrumMaster melakukan perencanaan sprint (lihat Gambar 2.8).

Selama perencanaan sprint, pemilik produk dan tim pengembangan menyepakati tujuan sprint yang
menentukan apa yang seharusnya dicapai sprint. Dengan menggunakan tujuan ini, tim
pengembangan meninjau backlog produk dan menentukan item prioritas tinggi yang dapat dicapai
secara realistis oleh tim dalam sprint mendatang sementara bekerja dengan kecepatan yang
berkelanjutan — kecepatan di mana tim pengembang dapat bekerja dengan nyaman untuk jangka
waktu yang lama.

Untuk mendapatkan kepercayaan pada apa yang bisa dilakukan, banyak tim pengembangan
memecah setiap fitur yang ditargetkan menjadi serangkaian tugas. Pengumpulan tugas-tugas ini,
bersama dengan item jaminan simpanan produk terkait, membentuk jaminan simpanan kedua yang
disebut sprint backlog (lihat Gambar 2.9). Tim pengembang kemudian memberikan perkiraan
(biasanya dalam jam) dari upaya yang diperlukan untuk menyelesaikan setiap tugas. Memecah item
jaminan produk menjadi tugas adalah bentuk desain dan perencanaan tepat waktu untuk cara
menyelesaikan fitur. Sebagian besar tim Scrum yang melakukan sprint selama dua minggu hingga
sebulan mencoba menyelesaikan perencanaan sprint dalam waktu sekitar empat hingga delapan
jam. Sprint satu minggu harus diambil tidak lebih dari beberapa jam untuk merencanakan (dan
mungkin kurang). Selama ini ada beberapa pendekatan yang bisa digunakan. Pendekatan yang paling
sering saya gunakan mengikuti siklus sederhana: Pilih item jaminan produk (bila memungkinkan,
item paling penting berikutnya seperti yang didefinisikan oleh pemilik produk), pecah item ke dalam
\ tugas, dan tentukan apakah item yang dipilih akan cukup masuk dalam sprint (dalam kombinasi
dengan item lain yang ditargetkan untuk sprint yang sama). Jika cocok dan ada lebih banyak
kapasitas untuk menyelesaikan pekerjaan, ulangi siklus sampai tim kehabisan kapasitas untuk
melakukan pekerjaan lagi.
Suatu pendekatan alternatif bagi pemilik produk dan tim untuk memilih semua item jaminan produk
target pada satu waktu. Tim pengembang sendiri melakukan tugas untuk memastikan bahwa ia
benar-benar dapat memberikan semua item jaminan produk yang dipilih

Sprint Execution

Setelah tim Scrum menyelesaikan perencanaan sprint dan menyetujui konten dari sprint berikutnya,
tim pengembangan, dipandu oleh pelatihan ScrumMaster, melakukan semua pekerjaan tingkat
tugas yang diperlukan untuk menyelesaikan fitur (lihat Gambar 2.10), di mana “selesai” berarti ada
tingkat kepercayaan yang tinggi bahwa semua pekerjaan yang diperlukan untuk menghasilkan fitur
berkualitas baik telah selesai.

Tugas apa yang harus dilakukan oleh tim tentu saja tergantung pada sifat pekerjaan (misalnya,
apakah kita membangun perangkat lunak dan jenis perangkat lunak apa, atau apakah kita
membangun perangkat keras, atau apakah ini pekerjaan pemasaran?). Tidak ada yang memberi tahu
tim pengembang dalam urutan apa atau bagaimana melakukan pekerjaan tingkat tugas dalam
tumpukan sprint. Sebagai gantinya, anggota tim mendefinisikan pekerjaan tingkat tugas mereka
sendiri dan kemudian mengatur diri sendiri dengan cara apa pun yang mereka rasa paling baik untuk
mencapai tujuan lari cepat.

Daily Scrum

Setiap hari sprint, idealnya pada saat yang sama, anggota tim pengembangan memegang scrum
harian (15 menit atau kurang) setiap hari (lihat Gambar 2.11). Aktivitas inspeksi dan adaptasi ini
kadang-kadang disebut sebagai stand-up harian karena praktik umum setiap orang yang berdiri
selama pertemuan untuk membantu mempromosikan keringkasan.

Pendekatan umum untuk melakukan scrum harian adalah memfasilitasi ScrumMaster dan setiap
anggota tim bergiliran menjawab tiga pertanyaan untuk kepentingan anggota tim lainnya:

Apa yang saya capai sejak scrum harian terakhir?

Apa yang saya rencanakan untuk dikerjakan oleh scrum harian berikutnya?

Apa saja hambatan atau hambatan yang menghalangi saya untuk membuat kemajuan?

Dengan menjawab pertanyaan-pertanyaan ini, semua orang memahami gambaran besar tentang
apa yang terjadi, bagaimana mereka maju ke arah tujuan sprint, modifikasi apa pun yang ingin
mereka buat pada rencana mereka untuk pekerjaan hari mendatang, dan masalah apa yang perlu
ditangani. Scrum harian sangat penting untuk membantu tim pengembangan mengelola aliran kerja
yang cepat dan fleksibel dalam sprint. Scrum harian bukanlah kegiatan pemecahan masalah.
Sebaliknya, banyak tim memutuskan untuk membicarakan masalah setelah scrum harian dan
melakukannya dengan sekelompok kecil orang yang tertarik. Scrum harian juga bukan pertemuan
status tradisional, terutama pertemuan semacam itu secara historis dipanggil oleh manajer proyek
sehingga mereka bisa mendapatkan pembaruan tentang status proyek. Namun, scrum harian dapat
berguna untuk mengomunikasikan status item sprint backlog di antara anggota tim pengembangan.
Terutama, scrum harian adalah inspeksi, sinkronisasi, dan kegiatan perencanaan harian adaptif yang
membantu tim yang mengatur dirinya sendiri melakukan tugasnya dengan lebih baik.
Done

Dalam Scrum, kami merujuk pada hasil sprint sebagai peningkatan produk yang berpotensi dapat
dikirim (lihat Gambar 2.12),

yang berarti bahwa apa pun yang disetujui tim Scrum untuk dilakukan benar-benar dilakukan sesuai
dengan definisi yang telah disepakati untuk dilakukan. Definisi ini menentukan tingkat kepercayaan
bahwa pekerjaan yang diselesaikan memiliki kualitas yang baik dan berpotensi dapat dikirim.
Misalnya, ketika mengembangkan perangkat lunak, definisi minimal yang dilakukan harus
menghasilkan sepotong fungsionalitas produk lengkap yang dirancang, dibangun, terintegrasi, diuji,
dan didokumentasikan. Definisi agresif yang dilakukan memungkinkan bisnis untuk memutuskan
setiap sprint jika ingin mengirim (atau menyebarkan atau melepaskan) apa yang dibuat untuk
pelanggan internal atau eksternal. Untuk menjadi jelas, "berpotensi dikirim" tidak berarti bahwa apa
yang dibangun harus benar-benar dikirimkan. Pengiriman adalah keputusan bisnis, yang sering
dipengaruhi oleh hal-hal seperti "Apakah kita memiliki cukup fitur atau alur kerja pelanggan yang
cukup untuk membenarkan penyebaran pelanggan?" Atau "Bisakah pelanggan kita menyerap
perubahan lain mengingat kita hanya memberi mereka rilis dua?" beberapa minggu yang lalu?
”Berpotensi berpaling lebih baik dianggap sebagai keadaan percaya diri bahwa apa yang dibangun
dalam sprint sebenarnya dilakukan, artinya tidak ada pekerjaan yang dibatalkan secara material yang
penting (seperti pengujian atau integrasi penting dan sebagainya) yang perlu diselesaikan sebelum
kami dapat mengirimkan hasil dari sprint, jika pengiriman adalah keinginan bisnis kami. Secara
praktis, seiring waktu beberapa tim dapat memvariasikan definisi selesai. Misalnya, pada tahap awal
pengembangan game, memiliki fitur yang berpotensi dapat dikirim mungkin tidak layak secara
ekonomi atau diinginkan (mengingat eksplorasi sifat pengembangan game awal). Dalam situasi ini,
definisi yang tepat untuk dikerjakan mungkin adalah sepotong fungsionalitas produk yang cukup
fungsional dan dapat digunakan untuk menghasilkan umpan balik yang memungkinkan tim untuk
memutuskan pekerjaan apa yang harus dilakukan selanjutnya atau bagaimana melakukannya.
Sprint Review

Di akhir sprint ada dua kegiatan inspeksi dan adaptasi tambahan. Satu disebut tinjauan sprint (lihat
Gambar 2.13).

Tujuan dari kegiatan ini adalah untuk memeriksa dan mengadaptasi produk yang sedang dibangun.
Yang penting untuk kegiatan ini adalah percakapan yang terjadi di antara para pesertanya, yang
meliputi tim Scrum, pemangku kepentingan, sponsor, pelanggan, dan anggota tim lain yang
berminat. Percakapan difokuskan pada meninjau fitur yang baru saja selesai dalam konteks upaya
pengembangan secara keseluruhan. Setiap orang yang hadir mendapatkan visibilitas yang jelas ke
dalam apa yang terjadi dan memiliki kesempatan untuk membantu memandu pengembangan yang
akan datang untuk memastikan bahwa solusi yang paling sesuai dengan bisnis dibuat.

Tinjauan yang berhasil menghasilkan aliran informasi dua arah. Orang-orang yang tidak termasuk
dalam tim Scrum dapat menyinkronkan upaya pengembangan dan membantu memandu arahnya.
Pada saat yang sama, anggota tim Scrum mendapatkan apresiasi yang lebih dalam untuk sisi bisnis
dan pemasaran produk mereka dengan sering mendapatkan umpan balik tentang konvergensi
produk terhadap pelanggan atau pengguna yang senang. Oleh karena itu, sprint review merupakan
peluang yang dijadwalkan untuk memeriksa dan mengadaptasi produk. Sebagai praktik, orang-orang
di luar tim Scrum dapat melakukan ulasan fitur intra-sprint dan memberikan umpan balik untuk
membantu tim Scrum lebih baik dalam mencapai tujuan sprint-nya.

Sprint Retrospective

Aktivitas inspeksi dan adaptasi kedua pada akhir sprint adalah sprint retrospective (lihat Gambar
2.14). Kegiatan ini sering terjadi setelah ulasan sprint dan sebelum perencanaan sprint berikutnya.
Sementara tinjauan sprint adalah waktu untuk memeriksa dan mengadaptasi produk, sprint
retrospektif adalah kesempatan untuk memeriksa dan mengadaptasi proses. Selama sprint
retrospektif, tim pengembang, ScrumMaster, dan pemilik produk berkumpul untuk membahas apa
yang bisa dan tidak bekerja dengan Scrum dan praktik teknis terkait.

Fokusnya adalah pada perbaikan proses berkelanjutan yang diperlukan untuk membantu tim Scrum
yang baik menjadi hebat. Pada akhir retrospektif sprint, tim Scrum seharusnya mengidentifikasi dan
berkomitmen pada sejumlah tindakan praktis proses perbaikan yang akan dilakukan oleh tim Scrum
dalam sprint berikutnya. Lihat Bab 22 untuk perincian tentang sprint retrospective. Setelah
retrospeksi sprint selesai, seluruh siklus diulangi lagi — dimulai dengan sesi perencanaan sprint
berikutnya, diadakan untuk menentukan set nilai tertinggi saat ini yang menjadi fokus tim.