---

Sertifikasi Scrum Master yang Ekonomis: Panduan Langkah demi Langkah

Kami bangga mengumumkan bahwa artikel ini ditampilkan...
DI SINI di LinkedIn >>>

Sejak kerangka scrum menjadi salah satu cara terbaik untuk mengembangkan dan menyampaikan perangkat lunak, semua orang tampaknya memiliki sasaran yang sama.

Bangun pagi, membuka laptop, dan merasakan ketenangan menyenangkan karena memiliki hal seperti ini:

Sertifikasi Scrum master.

Itulah impiannya, bukan?

Memberikan perangkat lunak yang hebat kepada pemberi kerja dan klien.

Memiliki karier luar biasa yang didukung keterampilan dan pengetahuan proses scrum serta sertifikasi scrum master Anda.

Bagi kebanyakan orang, sertifikasi scrum master merupakan awal perjalanan mereka dengan kerangka scrum.

Dalam artikel ini, untuk pertama kalinya saya ingin membagikan panduan bertahap yang mendalam dan terperinci untuk membantu Anda meraih sertifikasi scrum master.

Ekonomis, cepat, online, dan tanpa kerumitan!

Hanya dalam empat langkah mudah, Anda dapat menjadi profesional scrum yang unggul dengan sertifikasi scrum master Anda.

Tujuan artikel ini adalah menunjukkan cara Scrum mendukung karier dan meningkatkan efektivitas profesional Anda. Juga alasan Anda perlu terus mengembangkan keterampilan dan kemampuan Scrum Master sesegera mungkin.

Definisi - Apa Itu Sertifikasi Scrum Master?

Anda dapat menemukan definisi terbaik tentang sertifikasi scrum master Anda di International Scrum Institute™milik Scrum Master Accredited Certification™.

Sertifikasi scrum master adalah bukti kompetensi Anda dalam proses pengembangan dan penyampaian perangkat lunak Scrum. Sertifikasi scrum master mengakui pengetahuan yang Anda tunjukkan dan keahlian luar biasa dalam kerangka Scrum setelah evaluasi formal melalui ujian pilihan ganda.

Proses pengembangan perangkat lunak Scrum hingga kini telah memberi manfaat besar kepada jutaan profesional. Karena itu, tidak ada alasan Anda tidak bergabung dengan para pria dan wanita sukses yang meningkatkan karier serta keterampilan berkat kerangka scrum.

Jika Anda masih ragu, saya ingin meyakinkan Anda bahwa karier yang berkembang tidak lagi dapat dibayangkan tanpa sertifikasi scrum master. Apa pun peran, jabatan, dan pengalaman Anda dalam ekosistem Teknologi Informasi (TI) tersebut.

Anda bahkan tidak harus menjadi profesional TI untuk memahami apa itu scrum, bagaimana cara kerjanya, dan meraih sertifikasi scrum master.

Apa pun pekerjaan Anda, terlepas dari apakah Anda bagian departemen TI, ada fakta penting yang tidak terbantahkan. Tugas dan nilai bisnis profesional yang Anda berikan bagi organisasi bergantung pada serta saling terkait dengan TI, perangkat lunak, dan proses dan prinsip agile scrum.

Selain itu, berkat pergeseran model bisnis tradisional menjadi bisnis berbasis perangkat lunak sebagai layanan (SaaS) atau yang disebut gerakan digitalisasi, mendapatkan sertifikasi scrum master bukan lagi keputusan sukarela bagi profesional di dalam maupun di luar departemen TI. Kini, meraih sertifikasi scrum master merupakan suatu keharusan.

Anda mungkin baru memulai karier atau sudah menjadi profesional TI berpengalaman. Tidak masalah. Anda perlu meraih sertifikasi scrum master.

Peran Anda mungkin mencakup kegiatan manajemen orang dan fungsi, mungkin juga tidak. Itu pun tidak masalah; Anda tetap perlu memiliki sertifikasi scrum master.

Anda mungkin memiliki jabatan seperti:

• analis bisnis,
• arsitek perangkat lunak,
• arsitek enterprise,
• perancang perangkat lunak
• perancang pengalaman pengguna (UX),
• perancang antarmuka pengguna (UI),
• pengembang perangkat lunak,
• manajer pengembangan perangkat lunak,
• insinyur pengujian,
• spesialis otomatisasi pengujian,
• manajer pengujian,
• spesialis operasi sistem TI,
• administrator Unix/Linux,
• insinyur keamanan informasi (InfoSec),
• insinyur jaringan TI,
• administrator basis data (DBA),
• manajer proyek,
• manajer program,
• manajer produk,
• pemimpin tim, manajer, direktur, atau eksekutif,
• atau jabatan lain yang belum saya sebutkan di sini.

Anda sebaiknya mempelajari kerangka pengembangan perangkat lunak scrum dan menjadi scrum master hari ini dengan memperoleh sertifikasi scrum master Anda.

3 Unsur Kekacauan dan Frustrasi Sebelum Proses Agile Scrum dan Sertifikasi Scrum Master

Agar lebih memahami dampak kerangka scrum pada praktik rekayasa perangkat lunak dan bisnis, ada baiknya kita melihat sehari dalam kehidupan (atau sebuah proyek perangkat lunak).

Karena itu, saya ingin membahas secara singkat sebuah proyek perangkat lunak masa lalu, sebelum kami mengadopsi kerangka pengembangan dan penyampaian perangkat lunak scrum di organisasi.

Beberapa hari sebelum menulis ini, saya makan siang dengan mantan rekan yang bekerja bersama saya hampir 20 tahun lalu. Pria bernama Marcus ini telah meraih sertifikasi scrum master dan scrum product owner dari International Scrum Institute™.

Kini ia bekerja sebagai scrum master di salah satu perusahaan perangkat lunak terkemuka dalam bidang perangkat lunak manajemen proyek agile.

Sebagai scrum master, Marcus kini mendukung tim agile Scrum yang anggotanya tersebar secara geografis di seluruh dunia.

Saat makan siang, Marcus mengakui banyak tantangan umum pada tim agile scrum terdistribusi. Beberapa masalah yang secara khusus ia sebutkan terkait susunan proyek perangkat lunaknya adalah:

• Perbedaan gaya kerja antaranggota tim scrum,
• Perbedaan zona waktu,
• Ketidakcocokan budaya, dan
• Keterbatasan bahasa.

Meskipun ada kesulitan tersebut, Marcus menambahkan bahwa menjalankan proyek perangkat lunak dengan proses agile scrum lebih menyenangkan, produktif, dan memperkaya pengalaman dibanding cara kami bekerja 20 tahun lalu. Dibanding masa ketika kami bekerja tanpa proses pengembangan dan penyampaian perangkat lunak scrum.

Pernyataan Marcus benar-benar merupakan pengakuan besar atas keunggulan kerangka scrum dari seorang manajer, scrum master, dan product owner yang sangat sukses serta berpengalaman.

Terima kasih, Marcus!

Lalu saya menceritakan salah satu proyek perangkat lunak saya sebelum mengenal kerangka scrum. Saya yakin banyak scrum master akan melihat kemiripannya dengan proyek mereka sebelum mendapat sertifikasi scrum master.

Pada akhir 1990-an, saya bergabung dengan kelompok rekayasa perangkat lunak untuk membangun sistem berbasis kartu pintar infrastruktur kunci publikberbasis kartu pintar. Kartu pintar melindungi kunci privat anggota infrastruktur secara aman, sedangkan kunci publik terkait serta sertifikat pembungkusnya disebarkan terbuka (sesuai istilah publik).

Saat itu, proyek TI ini cukup kompleks dan memerlukan beberapa tim rekayasa perangkat keras serta perangkat lunak yang saling bergantung. Kami harus melakukan banyak penelitian dan pengembangan (R&D) untuk membangun sistem perangkat keras serta perangkat lunak yang berfungsi sepenuhnya.

Ingat, itu sebelum adanya produk layak minimum (MVP) untuk bereksperimen, membuat, belajar, dan bereksperimen kembali.

Jika ingin mempelajari lebih lanjut cara membangun MVP dengan metodologi Agile, silakan baca artikel dari Cleevio yang memberi gambaran lebih baik mengenai proses kompleks ini.

Membangun infrastruktur secanggih itu tanpa scrum, dengan banyak elemen perangkat keras dan perangkat lunak, merupakan tantangan nyata.

Berikut tiga kendala besar yang kami hadapi tanpa scrum master dan tanpa seorang pun dalam tim yang memiliki sertifikasi scrum master.

Unsur Kekacauan dan Frustrasi ke-1 Tanpa Sertifikasi Scrum Master: Kami Harus Merencanakan Seluruh Proyek Sebelum Memahami Proyek Itu Sebenarnya

Tanpa scrum, tim kami membangun dan menyampaikan produk perangkat lunak serta perangkat keras yang sama sekali keliru dan tidak memenuhi kebutuhan klien.

Dalam kehidupan profesional, pernah ada perusahaan pihak ketiga yang mendikte cara kami seharusnya membangun produk atau layanan perangkat lunak.

Capability Maturity Model (CMM), ISO 9001:2008 dan turunannya mencoba membantu perusahaan memastikan kami membangun perangkat lunak yang tepat dengan cara yang tepat.

Seberapa berhasilnya tidak termasuk pembahasan artikel ini. Artikel ini berfokus pada proses scrum dan manfaat sertifikasi scrum master, bukan menganggap standar manajemen mutu serta perbaikan proses sebagai alternatif Scrum yang sudah punah.

Namun, perlu saya tambahkan bahwa sebelum kerangka rekayasa perangkat lunak scrum, kerangka perbaikan proses ini diterapkan pada proyek melalui pendekatan bertahap. Kami menggunakan pendekatan rekayasa perangkat lunak bertahap yang disebut model rekayasa perangkat lunak waterfall.

Dengan model waterfall, setiap proyek perangkat lunak dimulai dari analisis kebutuhan, ketika kami berupaya memahami kebutuhan dan keinginan klien.

Lalu kami merancang kebutuhan tersebut, mengimplementasikan, menguji (memverifikasi), dan memeliharanya di lingkungan produksi perangkat lunak. Akhirnya, kami mencapai akhir siklus hidup rekayasa perangkat lunak.

Namun, kenyataannya tidak berjalan demikian!

Dampak buruk keterlambatan tak terduga pada suatu fase model waterfall tidak dapat dihindari oleh fase rekayasa perangkat lunak berikutnya.

Begitulah kehidupan sebelum kerangka Scrum.

Memindahkan perangkat lunak bolak-balik antartim tanpa bimbingan profesional bersertifikasi scrum master membuat pekerjaan birokratis, kompleks, dan tidak produktif.

Pada akhirnya, bukan hanya produk yang menderita, semangat karyawan dan komitmen terhadap misi organisasi juga terganggu sepenuhnya.

Unsur Kekacauan dan Frustrasi ke-2 Tanpa Sertifikasi Scrum Master: Kurangnya Komitmen, Manajemen Perubahan, dan Disiplin Kerja Sama Antartim

Kelemahan terbesar kerangka perbaikan proses sebelum Scrum adalah: Mereka terutama berfokus pada tuntutan organisasi yang melayani kepentingan pimpinan sendiri.

Sebagian tuntutan ini adalah pemantauan, kepatuhan, dan prediktabilitas. Sama sekali tidak ada fokus melayani klien dengan baik atau meningkatkan semangat karyawan.

Karena itu, tim manajemen perangkat lunak serta pemangku kepentingan internal dan eksternal lain berusaha menetapkan tenggat tetap proyek penyampaian perangkat lunak dan memantau kemajuan tahap rekayasa dengan mudah.

Mereka menghukum orang jika pekerjaan keluar dari rencana dan berharap memperbaiki masalah sebelum tanggal penyelesaian proyek yang dijadwalkan.

Selain itu, silo independen menjalankan fase rekayasa perangkat lunak yang sepenuhnya terpisah. Misalnya, tim pengembang sama sekali terpisah dari tim pengujian (verifikasi). Sebagian besar orang yang seharusnya bekerja untuk misi bisnis yang sama bahkan tidak saling mengenal nama.

Dapatkah Anda menebak penyebab pola pikir silo ini, alih-alih fokus pada misi bisnis dan kematangan profesional (bisnis) karyawan?

Penyebabnya sederhana, yaitu manajemen matriks. Manajemen matriks adalah struktur pengelolaan organisasi dan karyawan yang hadir dalam bisnis sejak 1970-an. Sekilas, gagasan pembeda organisasi atau manajemen matriks tampak cerdas.

Pimpinan membentuk struktur organisasi dengan mengelompokkan karyawan yang memiliki keterampilan fungsional dan teknis serupa dalam silo yang sama, atau paling baik dalam silo berdekatan.

Dahulu, “Pusat Kompetensi” cukup lazim di perusahaan, dengan setiap pusat menjadi silo independen dan otonom.

Satu silo pengembang C++, silo lain administrator basis data, dan silo penjaminan kualitas yang sepenuhnya terpisah di luar negeri, dan seterusnya. Coba bayangkan!

Tantangan terbesar struktur organisasi matriks adalah: untuk menyampaikan proyek perangkat lunak tanpa kerangka scrum dan scrum master, manajer proyek harus meminjam karyawan dari silo untuk sementara.

Para karyawan itu bahkan tidak ditempatkan secara fisik bersama tim proyek; mereka tetap berada di ruang pusat kompetensi masing-masing.

Setelah proyek selesai, tim sementara dibubarkan dan peserta proyek beralih ke penugasan berikutnya untuk proyek lain.

Karena itu, nilai bisnis sasaran proyek perangkat lunak yang berjalan tidak pernah menjadi prioritas tertinggi silo mandiri ini.

Mereka cenderung melihat pekerjaan sebagai kotak centang yang ditandai untuk proyek di sini dan proyek lain di sana.

Kepemimpinan serta model matriks tidak mengajarkan cara profesional berkomitmen pada bisnis untuk meningkatkan hasil akhir, termasuk penjualan, pendapatan, dan laba.

Artikel McKinsey Quarterly oleh McKinsey & Company juga dengan jelas menggambarkan ilusi optimalisasi biaya di balik organisasi matriks ini.

Artikel sumber mengutip perkiraan Gartner mengenai angka tahunan di seluruh dunia menghabiskan 600 miliar USD untuk memulihkan sistem TI dari pekerjaan pemeliharaan tak terjadwal dan cacat.

Sekarang mari sejenak membayangkan bagaimana manajemen perubahan dan penanganan hambatan proyek perangkat lunak berlangsung. Bagaimana hal itu berlangsung dalam susunan proyek dengan model waterfall, organisasi matriks, dan tanpa proses scrum.

Ya, Anda benar. Manajemen dan karyawan memperlakukan manajemen perubahan, hambatan, dan penanganan kesalahan seolah semuanya pengecualian buruk yang seharusnya tidak pernah terjadi.

Karena itu, perubahan dalam proyek perangkat lunak menjadi sinonim keterlambatan. Perubahan biasanya menimbulkan efek domino keterlambatan berantai. Tim membutuhkan orang untuk disalahkan atas cacat dan hambatan.

Terakhir, karena silo tidak memiliki mekanisme untuk memproses, memperbaiki, dan belajar dari kesalahan, mereka terus mengulangi kesalahan sama.

Selain itu, mereka terus menambah jumlah utang teknis sambil secara pasif berusaha mengatasi masalah.

Unsur Kekacauan dan Frustrasi ke-3 Tanpa Sertifikasi Scrum Master: Keputusan Otoriter Mengalahkan Keputusan Demokratis

Steve Jobs pernah berkata:

"Tidak masuk akal mempekerjakan orang cerdas lalu memberi tahu mereka apa yang harus dilakukan. Kami mempekerjakan orang cerdas agar mereka dapat memberi tahu kami apa yang harus dilakukan."

Namun, ini justru berlawanan dengan cara kebanyakan pemimpin arus utama mengambil keputusan sebelum era scrum.

Sebelum organisasi kami menggunakan proses scrum, keputusan otoriter para pemimpin mengalahkan kecerdasan gabungan tim mereka.

Mereka meniadakan kemampuan pengambilan keputusan demokratis kelompok yang bertanggung jawab melakukan pekerjaan nyata. yang mencakup seluruh siklus rekayasa perangkat lunak, dari konsepsi hingga operasinya.

Semakin jauh keputusan dipindahkan dari unit kerja (tim) yang terdampak, semakin sulit membuat keputusan kritis yang tepat.

Penilaian pemimpin biasanya impulsif, kurang dipikirkan matang, sering terlambat dan tentatif, tetapi terkadang bahkan terlalu awal.

Berbagai keputusan otokratis yang dipaksakan dari atas membuat karyawan merasa kurang dihargai. Keputusan ini sepenuhnya menghambat kemampuan organisasi menciptakan solusi kreatif serta inovatif bagi tantangan persaingan bisnis dan perangkat lunak.

Selain itu, mereka melemahkan semangat tim rekayasa perangkat lunak untuk memberikan masukan ketika diminta berkontribusi pada keputusan.

Itulah gambaran singkat cara kami mengembangkan dan menyampaikan layanan perangkat lunak serta produk layanan sebelum mengadopsi kerangka scrum. Sekarang mari lihat cara kami mengatasi unsur kekacauan dan frustrasi tersebut dengan bantuan proses scrum.

Apa itu Scrum?

Pertama, saya ingin menekankan bahwa bagian artikel ini tidak dimaksudkan sebagai rujukan utama untuk menjawab semua pertanyaan tentang kerangka scrum. Namun, pembahasan ini akan memberi awal yang mendalam bagi kebanyakan profesional scrum tingkat pemula dan menengah.

Namun, bagi yang mencari panduan lebih mendalam tetapi tetap praktis untuk mempelajari kerangka scrum dengan cepat, kami juga menyiapkannya. Saya sarankan Anda mengunduh panduan kerangka scrum kami melalui tautan di sini.

Apa itu Scrum? Tanpa membuatnya terlalu rumit, kerangka scrum dapat didefinisikan sebagai berikut:

Scrum adalah kerangka ringan untuk menghasilkan nilai melalui solusi adaptif bagi masalah kompleks. Pengembangan perangkat lunak iteratif dan inkremental merupakan salah satu penerapan pentingnya.

Meskipun perangkat lunak menjadi fokus utama kerangka scrum, proses scrum yang iteratif dan agile dapat dan sudah diterapkan di luar industri perangkat lunak.

Kebanyakan orang di industri TI percaya istilah “Scrum” diciptakan pada awal 2000-an, sejalan dengan munculnya tren pengembangan dan penyampaian perangkat lunak agile. Informasi itu keliru!

Artikel Harvard Business Review Januari 1986 menjelaskan pendekatan pengembangan produk yang mendahului kerangka Scrum berikutnya. Hirotaka Takeuchi dan Ikujiro Nonaka menulis artikel berjudul The New New Product Development Game. (Ya, ada dua kata New)

Anda sebaiknya membaca "The New New Product Development Game" untuk melihat bagaimana semua tentang Scrum bermula!

Ketika industri TI membahas kerangka scrum, kita sering mendengar istilah “Agile Scrum” bersama “Scrum”. Ini membuat sebagian dari kita memikirkan dan mencari perbedaan antara kedua istilah tersebut.

Kabar baiknya, istilah “Agile Scrum” dan “Scrum” merujuk pada hal yang sama. Keduanya merujuk pada proses rekayasa perangkat lunak scrum. Lalu mengapa terkadang kata “Agile” ditempatkan sebelum “Scrum”?

Karena kerangka scrum sepenuhnya menerima dan menanamkan Manifesto Agile (Manifesto Pengembangan Perangkat Lunak Agile) ke dalam proses inti, prinsip, dan filosofi dasarnya. Karena itu, kita perlu lebih memahami manifesto agile dan nilai proses scrum sebelum mendalami aspek teknisnya.

Manifesto Agile (Manifesto Pengembangan Perangkat Lunak Agile)

Nilai manifesto agile:

• Individu dan interaksi lebih diutamakan daripada proses dan alat,
• Perangkat lunak berfungsi lebih diutamakan daripada dokumentasi lengkap,
• Kolaborasi pelanggan lebih diutamakan daripada negosiasi kontrak,
• Merespons perubahan lebih diutamakan daripada mengikuti rencana.

Meskipun faktor di sebelah kanan tetap memiliki nilai penting, manifesto agile lebih menghargai dan memprioritaskan faktor di sebelah kiri.

Elemen yang diutamakan telah diuji waktu dan dipilih dengan cermat untuk:

• Melayani klien dan pemangku kepentingan lebih baik serta menciptakan nilai dengan perangkat lunak,
• Meningkatkan profesi rekayasa perangkat lunak, apa pun peran, jabatan, dan tingkat karier Anda.

Nilai-Nilai Kerangka Scrum

Saya sudah menyebutkan bahwa kerangka scrum bukan hanya proses rekayasa perangkat lunak. Kerangka ini juga memiliki prinsip dasar yang kuat.

Sebagian besar bidang bisnis profesional dapat menerapkan prinsip tersebut.

Meraih sertifikasi scrum master saja tidak cukup untuk sangat sukses dengan scrum. Anda perlu memahami nilai scrum secara kuat agar berhasil.

agar menghasilkan pekerjaan dan perangkat lunak luar biasa yang disukai pelanggan serta pemberi kerja. Sekarang saya akan menjelaskan lebih jauh prinsip proses scrum tersebut.

Keberanian

Ada saat ketika melakukan hal yang benar demi nilai dan manfaat terbaik bagi klien bukanlah pilihan termudah. Dalam situasi ini, scrum master, scrum product owner, dan anggota tim perlu mengingat tugas serta kewajibannya.

membangun produk serta layanan terbaik dalam bidang bisnis dan TI mereka. Untuk melampaui hasil biasa, tim scrum cepat atau lambat harus menghadapi keputusan sulit yang tidak akan menyenangkan semua orang dalam ekosistem pemangku kepentingannya.

Untuk menghadapinya, semua anggota tim harus mengingat pelajaran dari pelatihan sertifikasi scrum master.

Mereka harus ingat untuk berani, serta menguasai pengambilan keputusan dan tindakan yang berani.

Fokus

Dalam kerangka scrum, ketika mendengar nilai fokus, pikirkan dua hal:

• Mengidentifikasi pekerjaan yang tepat: Tugas apa yang diperlukan untuk mencapai sasaran sprint? Apa yang penting untuk mengembangkan produk dan layanan perangkat lunak terbaik bagi klien agar mereka puas dengan pekerjaan saya?
• Prioritas: Tugas apa yang harus saya kerjakan berikutnya?

Setiap saat, ada satu pertanyaan penting yang harus dijawab seluruh tim scrum, termasuk scrum master dan product owner. Pertanyaannya: “Apa hal terpenting yang harus kita lakukan sekarang untuk memenuhi alasan pemberi kerja merekrut kita sejak awal?”

Kerangka scrum memiliki beberapa acara (ritual) bawaan untuk memastikan user story dan tugas diprioritaskan secara wajar. Menurut proses scrum, prioritas user story dan tugas terkait perlu mendapat perhatian berkelanjutan.

Dengan demikian, tim scrum mengerjakan hal yang tepat dalam urutan yang benar. Acara Scrum formal dan praktik penyempurnaan terkait membantu kita menginspeksi fokus dan mengadaptasi pekerjaan:

• Rapat Scrum Grooming: Penyempurnaan memperjelas, memecah, dan menentukan ukuran item Product Backlog mendatang serta membantu pengurutannya. Rapat hanyalah salah satu cara melakukan aktivitas berkelanjutan ini.
• Rapat Sprint Planning: memperjelas dependensi dan urutan pekerjaan untuk menyerahkan cerita.
• Rapat Daily Scrum: Rapat Daily Scrum (Daily Stand-Up) membantu menentukan arah hari kerja berikutnya. Kita harus memusatkan perhatian di tempat yang paling membutuhkan.
• Rapat Sprint Review: Rapat Sprint Review secara tidak langsung menunjukkan arah fokus tim agar tinjauan masa depan lebih berhasil.
• Rapat Sprint Retrospective: Rapat-rapat ini membantu tim memprioritaskan aspek proses rekayasa yang harus diperbaiki terlebih dahulu.

Di bagian ini, saya hanya membahas ritual scrum dari sudut pandang fokus. Penjelasan lebih rinci tentang acara scrum dapat Anda temukan nanti dalam artikel ini.

Setelah membaca semuanya, kini pasti jelas betapa pentingnya prioritas dan fokus bagi kerangka scrum.

Komitmen

Tanpa komitmen scrum master, scrum product owner, dan tim scrum, tidak mungkin memberikan hasil luar biasa melalui perangkat lunak.

Dalam dunia proses pengembangan perangkat lunak scrum, kebanyakan orang memaknai komitmen sebagai kesepakatan dan keterikatan pada sasaran hasil kerja sprint tertentu.

Meski masuk akal, pemahaman itu belum sempurna. Ketika mendengar “komitmen” dalam konteks nilai scrum, penulis memakai kata “obsesi” untuk menekankan dedikasi. Dalam definisi Scrum, komitmen menyangkut sasaran tim dan dukungan timbal balik; bukan kewajiban bekerja berlebihan atau kepastian setiap item prakiraan.

Agar sukses dalam rekayasa perangkat lunak, kehidupan, dan bisnis, Anda perlu sangat berdedikasi pada sasaran. Jadi dalam konteks proses scrum, berobsesilah menciptakan perangkat lunak menakjubkan yang memecahkan masalah pelanggan.

Mengapa komitmen dan dedikasi kuat pada sasaran scrum penting? Tanpa itu terhadap misi tim membangun dan menyampaikan perangkat lunak hebat, setiap hambatan yang tidak sepele akan memperlambat dan menghentikan pekerjaan.

Lalu scrum master dan tim mulai membuat penjelasan untuk membenarkan kepada scrum product owner mengapa mereka tidak dapat mencapai sasaran sprint. Alasan tidak boleh lagi mendapat tempat jika sasaran Anda adalah menjadi tim scrum di atas rata-rata.

Hanya dengan dedikasi yang sangat tinggi, memecahkan masalah klien serta membantu dan membangun nilai bagi mereka melalui perangkat lunak akan terasa lebih mudah dan memuaskan.

Rasa Hormat

Apa pun usia, gender, ras, keyakinan, pengalaman, kompetensi, pendapat, dan kinerjanya, semua anggota tim scrum harus saling menghormati serta mengandalkan.

Rasa hormat ini tidak terbatas dalam tim. Setiap pemangku kepentingan TI maupun bisnis, internal atau eksternal, yang berinteraksi dengan tim juga sepenuhnya dihormati dan disambut.

Anggota berpengalaman harus berhati-hati agar tidak mematahkan kemauan berkontribusi dari anggota yang kurang berpengalaman.

Sangat penting menerima dan menjawab dengan baik pendapat berlawanan yang tidak disetujui mayoritas kelompok.

Keterbukaan

Nilai scrum “keterbukaan” sering menjadi pembeda utama tim biasa dan tim berkinerja tinggi. Bayangkan kemampuan keterbukaan tim scrum seperti kekuatan besar sekumpulan orang berpikiran terbuka.

Mereka kreatif, inovatif, intelektual, jujur, lugas, dan rendah hati. Dalam proses rekayasa dan penyampaian perangkat lunak scrum, orang harus dapat mendiskusikan tantangan serta pandangan berbeda secara terbuka. Keterbukaan tidak menjadikan setiap keputusan atau tindakan tepat: rasa hormat, kualitas, dan sasaran tim tetap penting.

Syaratnya hanya mereka harus transparan dan bertujuan berkontribusi pada misi bersama tim scrum.

Ini tidak berarti setiap keputusan dan tindakan harus mempercepat hasil tim serta menghasilkan kisah sukses besar.

Berkat nilai keterbukaan dan keberanian, kelompok pengembangan perangkat lunak scrum tidak takut membuat kesalahan. Kesalahan dan hasil kurang optimal menjadi peluang penting meningkatkan produktivitas serta kualitas secara bermakna.

Komponen Utama Kerangka Scrum

Scrum Team terdiri dari satu Product Owner, satu Scrum Master, dan Developers, dengan tiga akuntabilitas berbeda. Istilah “Scrum Team Member” sebelumnya dalam artikel ini merujuk kelompok pengembang, bukan akuntabilitas keempat atau Scrum Team utuh yang terpisah.

Selain program lain bagi peserta didik di seluruh dunia, International Scrum Institute™ menyediakan tiga program pelatihan serta sertifikasi utama bagi ketiga peran ini.

Program-program ini adalah Scrum Master Accredited Certification™ (SMAC™), Scrum Product Owner Accredited Certification™ (SPOAC™), dan Scrum Team Member Accredited Certification™ (STMAC™).

Organisasi scrum yang baik harus memiliki orang dengan ketiga kelompok keterampilan tersebut secara memadai. Ini sangat penting agar berhasil dengan kerangka pengembangan perangkat lunak scrum.

Setiap akuntabilitas Scrum harus dipenuhi. Tanggung jawabnya tetap berbeda; Product Owner atau Scrum Master juga dapat berkontribusi sebagai Developer ketika mengerjakan Sprint Backlog, tanpa kehilangan tanggung jawab akuntabilitas lainnya.

Beberapa Scrum Team pada satu produk berbagi satu Product Owner, Product Goal, dan Product Backlog. Setiap tim memiliki akuntabilitas Scrum Master dan memerlukan dukungan efektif; Scrum tidak menetapkan satu orang hanya boleh mendukung satu tim.

Jangan meremehkan pentingnya memahami tujuan dan fungsi peran ini serta mengisinya dengan talenta memadai. Kami sering melihat akar kesulitan tim adalah peran tersebut tidak dipahami atau diisi orang yang tidak tepat.

Sekarang mari bahas ketiga peran tersebut.

Tiga Peran Scrum - Peran Scrum Product Owner

Scrum product owner mengurutkan Product Backlog untuk memaksimalkan nilai produk serta bekerja dengan pemangku kepentingan dalam keputusan produk dan rilis. Developers memilih pekerjaan yang mereka prakirakan untuk Sprint; pengaturan rilis bergantung pada konteks produk. Ia mewakili kebutuhan fungsional dan nonfungsional pengguna akhir.

Peran Product Owner jauh lebih luas daripada peran tradisional pengelolaan proyek, manajer program, atau pengelolaan produk.

Peran itu menyatukan tugas manajemen produk dan proyek serta terintegrasi erat dengan pengembangan dan penyampaian perangkat lunak.

Tugas penting scrum product owner adalah:

• Mengelola serta memperjelas persyaratan proyek,
• Memandu rilis serta memastikan pengembalian investasi (ROI),
• Bekerja erat dengan tim scrum,
• Mengelola pemangku kepentingan.

Tiga Peran Scrum - Peran Anggota Tim Scrum

Tim scrum mengimplementasikan perangkat lunak. Developers memilih jumlah pekerjaan yang diprakirakan dapat diselesaikan selama Sprint. Sprint adalah acara berdurasi tetap; hasil produk yang dapat digunakan selama periode itu adalah Increment yang memenuhi Definition of Done.

Tim scrum berkinerja tinggi umumnya memiliki sebagian besar keterampilan rekayasa perangkat lunak. Pengembang, arsitek, penguji, administrator basis data, dan anggota dari semua peran lainnya bekerja bersama.

Mereka bersama-sama membangun dan menghasilkan perangkat lunak hebat yang dibayar klien.

Anggota tim scrum tidak lagi menjadi bagian silo fungsional organisasi matriks. Pengembang tidak lagi menjadi bagian pusat kompetensi pengembangan, penguji tidak lagi menjadi bagian pusat kompetensi pengujian, dan seterusnya.

Apa pun posisi sebelumnya di organisasi, anggota tim scrum menjadi bagian proyek scrum mereka. Kini tugasnya membangun perangkat lunak terbaik untuk memenuhi kebutuhan scrum product owner.

Karakteristik tim scrum adalah:

• Diberdayakan,
• Otonom,
• Lintas fungsi,
• Mengatur diri sendiri,
• Kecil,
• Peserta memiliki ketersediaan waktu yang memadai (partisipasi penuh waktu merupakan pilihan organisasi yang lazim),
• Mampu berkolaborasi erat, baik di lokasi yang sama maupun tersebar,
• Satu untuk semua, semua untuk satu.

Tiga Peran Scrum - Peran Scrum Master

Scrum master melayani semua peserta proyek dan pemangku kepentingan eksternal untuk memahami serta menerapkan kerangka scrum dengan benar. Ia mendukung tim menjalankan proses dengan sukses serta terus meningkatkan produktivitas dan kinerja.

Peran scrum master adalah membangun proses scrum serta cara berpikir dan bertindak yang baru.

Selain itu, scrum master bertindak sebagai agen perubahan. Ia melatih tim mengembangkan norma dan standar baru. Ia tetap mudah dihubungi tim; kedekatan fisik dapat membantu tetapi bukan persyaratan Scrum.

Tanggung jawab penting Scrum Master mencakup:

• Membangun scrum dalam ekosistem bisnis dan TI,
• Melatih tim memahami dan menghayati nilai scrum,
• Memastikan kolaborasi erat antara scrum product owner dan tim scrum,
• Menyingkirkan hambatan,
• Memimpin dengan melayani,
• Mendukung acara Scrum yang efektif dan memfasilitasi bila diperlukan, sambil menjaga kepemilikan Daily Scrum oleh Developers.

Backlog Produk (Scrum Backlog)

Product Backlog (Scrum Backlog) atau Scrum Product Backlog merupakan elemen utama untuk mengelola semua kebutuhan proyek scrum yang diketahui.

Isinya mencakup semua kebutuhan pelanggan dan item kerja untuk menjalankan serta menyelesaikan proyek yang berhasil. Kebutuhan meliputi kebutuhan fungsional, nonfungsional, dan fitur lain yang terkait pengalaman pengguna dan antarmuka pengguna desain.

Product backlog memuat permintaan fitur dan gambaran tingkat tingginya cerita pengguna. Ini juga dapat mencakup kebutuhan proyek prasyarat atau pelengkap, seperti membangun lingkungan pengujian dan pengembangan. User story lain untuk mengatasi bug yang diketahui, mengurangi utang teknis, atau memperbaiki fitur tertentu juga memiliki tempat di product backlog.

Setiap produk memiliki Product Backlog sendiri. Scrum product owner bertanggung jawab membuat, memelihara, dan menyempurnakannya. Product backlog tidak dan tidak seharusnya menjawab bagaimana kebutuhan tersebut akan dikembangkan serta disampaikan.

Itu tugas tim scrum. Tim menentukan dan mendokumentasikan tugas yang diperlukan untuk memenuhi kebutuhan tersebut dalam sprint backlog. Perhatikan bahwa Product Backlog dan Sprint Backlog merupakan artefak berbeda, tidak harus berupa dokumen atau alat yang terpisah secara fisik, meskipun item product backlog mengarahkan isi sprint backlog.

Product backlog adalah dokumen yang terus berkembang. Seperti perangkat lunak yang meningkat secara bertahap, Product Backlog berubah seiring pembelajaran tim, termasuk penambahan, penghapusan, dan pengurutan ulang. Kerangka scrum tidak secara khusus memerlukan proses manajemen perubahan terpisah. Scrum product owner membuat versi awal product backlog berdasarkan pemahaman awal terbaiknya tentang produk.

Sambil mengamati produk berkembang dari sprint ke sprint dan menambah pengetahuan kebutuhan klien, ia menambahkan, menghapus, serta menyempurnakan kebutuhan product backlog.

Scrum product owner memprioritaskan kebutuhan di product backlog. Semakin tinggi prioritas item product backlog, semakin rinci isinya. Dengan demikian, tim mudah memahami kebutuhan prioritas tinggi dan membuat tugas untuk membangunnya.

Selain itu, dengan pendekatan estimasi seperti story point, tim scrum secara rutin mengestimasi kebutuhan product backlog. Estimasi user story prioritas tinggi perlu disempurnakan dan diperbaiki agar siap untuk sprint planning.

Sprint

Dalam kerangka scrum, semua aktivitas implementasi kebutuhan berlangsung selama sprint. Sprint adalah siklus kegiatan kerja untuk mengembangkan Increment produk atau layanan perangkat lunak yang siap dikirim. Sprint terkadang juga disebut iterasi.

Bayangkan sprint sebagai proyek mikro. Sesuai istilah “Sprint”, durasinya tidak lama, satu bulan atau kurang. Sprint empat minggu adalah contoh yang umum, bukan batas maksimum kalender yang tepat dalam kerangka ini.

Berbeda dengan lomba lari, pada akhir sprint tim scrum tidak seharusnya kehabisan napas dan tenaga. Sebaliknya, tim harus tetap segar dan memulai sprint berikutnya dengan penuh energi.

Kerangka pengembangan dan penyampaian perangkat lunak scrum tidak bertujuan memberi tekanan atau stres pada anggota tim. Orang bekerja paling baik ketika fokus, tenang, dan tidak terganggu. Jika diterapkan dengan benar, itulah yang dibantu oleh sprint.

Setiap sprint dimulai dengan Pertemuan Sprint Planning. Dalam rapat sprint planning, tim scrum menentukan kebutuhan apa dan berapa banyak yang akan diimplementasikan pada sprint tersebut. Selanjutnya, tim mulai menjalankan aktivitas untuk memenuhi kebutuhan itu.

Daily Scrum (Rapat Daily Scrum) berlangsung setiap hari kerja dalam Sprint pada waktu dan tempat yang sama. Developers menggunakannya untuk menginspeksi kemajuan menuju Sprint Goal dan mengadaptasi rencana hari berikutnya. Anggota tim juga dapat meminta bantuan scrum master untuk menyingkirkan hambatan yang berpotensi memperlambat atau menghalangi kemajuan sprint.

Tim scrum mengakhiri sprint dengan rapat Sprint Review dan Sprint Retrospective. Rapat Sprint Review memungkinkan Scrum Team dan pemangku kepentingan utama menginspeksi hasil Sprint serta kemajuan menuju Product Goal, lalu mendiskusikan adaptasi selanjutnya. Ini sesi kerja, bukan gerbang persetujuan Product Owner.

Selama Rapat Sprint Retrospective, tim scrum merefleksikan cara bekerja bersama, penggunaan kerangka Scrum, dan cara memperbaikinya.

Dengan demikian, tim bersama-sama mempertimbangkan peluang perbaikan dan umpan balik ini dalam Sprint Planning berikutnya. Sprint memungkinkan siklus umpan balik tersebut dalam periode singkat dengan kelompok pekerjaan kecil. Inilah salah satu alasan penting mengapa dan bagaimana kerangka kerja Scrum membantu tim serta organisasi terus memperbaiki diri.

Inspeksi dan Adaptasi Scrum

Inspeksi dan Adaptasi Scrum adalah konsep yang mudah dipahami, tetapi paling sulit diterapkan dan dikuasai dengan benar.

Perusahaan akhirnya menyadari bahwa tidak ada manajer proyek yang mampu sepenuhnya memprakirakan gambaran besar sistem kompleks. Mereka tidak mampu membuat perencanaan menyeluruh yang andal. Jelas mereka perlu mencoba sesuatu yang berbeda.

Bersama dengan manufaktur lean (juga dikenal sebagai gerakan lean), perusahaan perlu mengembangkan proses yang memberdayakan mereka secara strategis. Mereka memerlukan prosedur operasi standar untuk membantu belajar dan memperbaiki arah tindakan selama menjalankan proyek, bahkan operasi sehari-hari.

Itulah awal lahirnya Toyota Improvement Kata, yang menjadi perbandingan berguna bagi inspeksi dan adaptasi Scrum. Pendekatan ini memiliki tujuan terkait, tetapi Toyota Improvement Kata bukan sekadar nama lain pilar empiris Scrum. Menurut “Inspeksi dan Adaptasi Scrum”:

• Langkah 1. Inspeksi: Kami berusaha sebaik mungkin memahami status proyek berdasarkan tingkat pengetahuan dan pemahaman saat ini.
• Langkah 2. Adaptasi: Kami menentukan arah dan visi langkah proyek berikutnya, lalu menyusun strategi dan menjalankan visi tersebut.
• Langkah 3. Belajar: Kami mengamati dengan saksama, belajar, dan saling mengajar selama bekerja. Kami terus mencatat hal yang berhasil dan tidak berhasil.
• Langkah 4. Mulai Ulang: Mulai kembali dari Langkah 1.

Empat langkah di bawah merupakan analogi pembelajaran, bukan definisi acara Scrum yang berpadanan satu per satu. Inspeksi, adaptasi, dan pembelajaran berlangsung sepanjang Sprint.

• Langkah 1. Inspeksi dianalogikan dengan rapat Sprint Review dan Sprint Retrospective.
• Langkah 2. Adaptasi dianalogikan dengan rapat Sprint Planning.
• Langkah 3. Belajar dianalogikan dengan rapat Daily Scrum.
• Langkah 4. Mulai Ulang dianalogikan dengan akhir sprint dan awal sprint baru.

Pengaturan Diri

Tim scrum mengatur dirinya sendiri. Anggotanya menyepakati tugas yang perlu dilakukan untuk mencapai sasaran sprint. Tim yang mengatur diri sendiri tidak memerlukan manajer atau pemimpin tim.

Pengaturan diri dalam kerangka scrum sangat disiplin.

Sprint Backlog dan Rapat Daily Scrum mendukung pengelolaan diri. Sebuah Grafik Sprint Burndown merupakan salah satu pilihan untuk memperlihatkan kemajuan.

Bagi kebanyakan tim, mengatur pekerjaan sendiri memerlukan fase belajar. Scrum master kompeten yang memiliki sertifikasi mendukung tim agar cepat unggul dalam pengaturan diri.

Pengaturan diri juga mencakup kemampuan bekerja bersama meskipun berbeda pendapat dan mungkin terjadi konflik antaranggota. Ini memerlukan kepatuhan serta kepercayaan pada proses pengambilan keputusan bersama.

Proses pengambilan keputusan dalam scrum mencakup, tetapi tidak terbatas pada, perencanaan, estimasi, implementasi, pelaporan, dan peninjauan pekerjaan yang menjadi tanggung jawab bersama tim.

Acara Scrum dan Penyempurnaan Backlog Berkelanjutan

Acara Scrum 1. Sprint Planning (Mengapa, Apa, dan Bagaimana)

Selama Pertemuan Sprint Planning, tim Scrum menyusun Sprint Backlog yang layak, yang menentukan kebutuhan yang akan diimplementasikan selama Sprint.

Tugas berbagai peran Scrum selama Sprint Planning adalah sebagai berikut:

• Product Owner mengusulkan alasan Sprint dapat memberi nilai. Seluruh Scrum Team berkolaborasi menetapkan Sprint Goal, dan Developers memilih item Product Backlog yang diprakirakan dapat diselesaikan.
• Scrum Team mengidentifikasi tugas dan estimasi yang diperlukan. Berdasarkan kinerja sebelumnya, kapasitas, serta Definition of Done, Developers menentukan item apa dan berapa banyak yang diprakirakan dapat diselesaikan dalam Sprint.
• Scrum Master memoderasi rapat dan memastikan pengaturan diri serta kemampuan pengambilan keputusan otonom Scrum Team tetap terjaga.

Kehadiran Scrum Product Owner wajib dalam rapat Sprint Planning. Dengan demikian, ia dapat menjawab pertanyaan tim dan memperjelas kebutuhan serta kriteria penerimaannya.

Scrum Team dapat mengundang orang lain, seperti pengguna akhir atau manajer, ke Sprint Planning untuk memberi saran. Kontributor yang diundang memberi saran tanpa mengambil alih keputusan Developers tentang cara mengerjakan pekerjaan.

Acara Scrum 2. Rapat Daily Scrum (Rapat Daily Stand-up)

Komponen ini Pertemuan Daily Scrum adalah rapat maksimal 15 menit. Rapat berlangsung setiap hari kerja pada waktu dan tempat yang sama. Sebaiknya rapat dilakukan dengan akses langsung ke Sprint Backlog dan Grafik Sprint Burndown. Dengan demikian, Scrum Team dapat mengarahkan Daily Scrum berdasarkan fakta dan kemajuan yang terlihat oleh seluruh anggota.

Daily Scrum bertujuan mendukung pengorganisasian mandiri Scrum Team dan mengidentifikasi hambatan secara sistematis.

Daily Scrum diperuntukkan bagi Developers. Product Owner atau Scrum Master yang mengerjakan item Sprint Backlog berpartisipasi sebagai Developer. Pengaturan partisipasi lainnya harus menjaga fokus serta pengelolaan diri Developers; Scrum tidak mewajibkan semua peran atau pemangku kepentingan hadir.

Developers memilih struktur yang berguna dengan fokus pada Sprint Goal dan rencana yang dapat ditindaklanjuti. Tiga pertanyaan berikut merupakan format opsional yang umum, bukan pertanyaan wajib Scrum saat ini.

• Rapat Daily Scrum - Pertanyaan #1. Kegiatan apa yang telah saya lakukan sejak Daily Scrum terakhir?
• Rapat Daily Scrum - Pertanyaan #2. Kegiatan apa yang saya rencanakan hingga Daily Scrum berikutnya? Apa rencana tindakan saya?
• Rapat Daily Scrum - Pertanyaan #3. Apakah saya menghadapi atau memperkirakan hambatan yang dapat memperlambat atau menghalangi kemajuan pekerjaan?

Developers menjalankan Daily Scrum mereka. Scrum Master membantu Developers memahami tujuan dan efektivitasnya bila diperlukan. Acara tetap berdurasi 15 menit; format tiga pertanyaan bersifat opsional.

Tujuan Daily Scrum tidak mencakup pengambilan keputusan yang menyita waktu atau pemecahan masalah. Untuk menyelaraskan keputusan dan memecahkan masalah, tim dapat mengadakan rapat terpisah sesuai kebutuhan. Rapat yang berfokus pada keputusan atau masalah ini biasanya dilakukan setelah Daily Scrum.

Scrum Master mencatat hambatan yang ditemukan beserta tanggalnya pada log, flip chart, atau laporan terpisah yang dapat diakses tim. Menurut saya, memperbarui status hambatan terbuka dengan cepat pada akhir Daily Scrum sangat bermanfaat.

Acara Scrum 3. Rapat Sprint Review

Komponen ini Pertemuan Sprint Review berlangsung pada akhir sprint. Review satu hingga dua jam dapat sesuai bagi sebagian tim; batas maksimum formal adalah empat jam untuk Sprint satu bulan, dan acara lebih singkat biasanya cocok untuk Sprint lebih pendek. Bergantung pada jenis perangkat lunak dan infrastruktur, rapat dapat berlangsung di ruang rapat, laboratorium, atau ruang tim.

Tujuan Sprint Review adalah meninjau Increment produk siap dikirim yang dibangun selama sprint dan membuat proses pengembangan produk transparan.

Tim menunjukkan hasil kerjanya. Scrum Team dan pemangku kepentingan membahas hasil yang dicapai serta perubahan lingkungan. Mereka menginspeksi hasil dan mempertimbangkan langkah berikutnya; Review bukan pemeriksaan kepatuhan terhadap daftar tetap tugas yang dijanjikan.

Sprint Review memungkinkan tim dan pemangku kepentingan menginspeksi hasil produk serta mengadaptasi Product Backlog. Seluruh Scrum Team selanjutnya berkolaborasi menetapkan Sprint Goal berikutnya. Karena itu, Sprint Review merupakan penerapan formal dan praktis “inspeksi dan adaptasi”.

Peserta Sprint Review adalah tim Scrum, Scrum Product Owner, dan Scrum Master. Pemangku kepentingan lain seperti pengguna akhir, klien, dan perwakilan bisnis dapat ikut secara opsional.

Dalam Sprint Review, mereka diperbolehkan menyampaikan umpan balik tentang Increment produk yang didemonstrasikan. Dengan demikian, tim berkesempatan mendapat masukan langsung tanpa penyaringan dari pemangku kepentingan yang akan menggunakan perangkat lunaknya.

Acara Scrum 4. Rapat Sprint Retrospective

Komponen ini Rapat Sprint Retrospective mengikuti Sprint Review dan menutup Sprint. Durasi maksimalnya tiga jam untuk Sprint satu bulan; pada Sprint yang lebih pendek, biasanya lebih singkat.

Tujuan Sprint Retrospective adalah meningkatkan kerja sama anggota tim dan penerapan proses Scrum.

Karena itu, Sprint Retrospective meningkatkan produktivitas, kinerja anggota tim, serta kualitas perangkat lunak.

Sprint Retrospective pada dasarnya merupakan evaluasi mini untuk menetapkan potensi perbaikan dan menghilangkan hambatan proses. Beberapa contoh peluang perbaikan yang sering kami lihat dalam proyek:

• Penerapan praktik pengembangan perangkat lunak agile seperti extreme programming (XP) atau pengembangan berbasis pengujian (TDD).
• Identifikasi norma dan prinsip tim baru atau
• Peningkatan ketersediaan Scrum Product Owner.

Tanpa pengecualian, tim mengadakan Sprint Retrospective pada akhir setiap sprint. Hanya dengan cara ini, rapat memungkinkan tim mengadaptasi dan meningkatkan penggunaan proses scrum secara sistematis sesuai kekhususan proyek.

Praktik Terkait: Penyempurnaan Product Backlog (Grooming)

Scrum Rapat Penyempurnaan Backlog (Grooming) bertujuan menjaga Product Backlog tetap mutakhir. Dengan demikian, Product Backlog mencerminkan pengetahuan dan pemahaman terbaik tim Scrum tentang proyek Scrum yang sedang berjalan.

Penyempurnaan dapat dilakukan sesuai kebutuhan atau dalam diskusi terjadwal. Dua sesi 30 menit per minggu adalah salah satu contoh praktis, bukan frekuensi wajib atau batas maksimum. Product Owner dan Developers berkolaborasi, dengan Scrum Master serta kontributor lain dilibatkan sesuai manfaatnya.

Dalam rapat Penyempurnaan Backlog Scrum, peserta menyempurnakan Product Backlog melalui tindakan berikut:

• Menambahkan cerita pengguna baru berdasarkan persyaratan yang baru ditemukan.
• Menghapus cerita pengguna yang tidak lagi diperlukan untuk produk.
• Menyempurnakan estimasi cerita pengguna.
• Memperbarui prioritas cerita pengguna.
• Memecah cerita pengguna yang sangat besar menjadi cerita lebih kecil yang mudah ditangani dan memprioritaskannya sesuai kebutuhan.

Empat Langkah Mudah Meraih Sertifikasi Scrum Master

Cara meraih sertifikasi scrum master sangat sederhana, cepat, dan sepenuhnya online.

Berkat International Scrum Institute™, kini Anda dapat meraih sertifikasi scrum master lebih cepat dan ekonomis daripada sebelumnya.

Empat langkah mudah meraih sertifikasi scrum master Anda tanpa membuang waktu, uang, atau mengalami kerumitan adalah sebagai berikut.

• Langkah #1. Daftar Online

  Daftarkan sertifikasi scrum master Anda secara online melalui Halaman Pendaftaran Scrum Master Accredited Certification™.

  Setelah pendaftaran, International Scrum Institute™ langsung memberikan kode akses ujian secara online.

  Dari tautan berikut, Anda dapat Mendaftar Program Sertifikasi Scrum Master Anda.

• Buka Gambar Ukuran Penuh ↗

  Langkah #2. Belajar Online

  Belajarlah untuk sertifikasi scrum master secara online menggunakan Panduan Belajar Scrum, The Scrum Framework™.

  The Scrum Framework™ dirancang sepenuhnya berorientasi praktik. Isinya membantu Anda menangani tantangan harian pekerjaan dan karier sebagai scrum master berbakat. Buku ini penuh studi kasus serta contoh praktis untuk menunjukkan keseharian scrum master paling sukses.

  Dari tautan berikut, Anda dapat Minta Salinan Gratis The Scrum Framework™ Anda.

• Langkah #3. Ikuti Ujian Sertifikasi Scrum Master Online

  Setelah membaca, mempelajari, dan memahami Panduan Belajar Scrum, The Scrum Framework™, dengan saksama, Anda seharusnya sudah siap! Kini Anda dapat sepenuhnya percaya diri untuk lulus ujian sertifikasi scrum master.

  Dari tautan berikut, Anda dapat Akses Ujian Sertifikasi Scrum Master Anda.

• Langkah #4. Dapatkan Sertifikasi Scrum Master Anda

  Begitu Anda lulus ujian, kami langsung mengirimkan sertifikasi scrum master Anda.

  Pemberi kerja dan klien dapat memvalidasi keaslian sertifikasi Anda menggunakan Alat Validasi Sertifikasi Scrum untuk Pemberi Kerja. Dari tautan berikut, Anda dapat Mengakses Alat Validasi Sertifikasi Scrum untuk Pemberi Kerja.

Kesimpulan Saya tentang Sertifikasi Scrum Master

Sekarang waktunya merangkum. Jika belum sempat membaca seluruh panduan bertahap menjadi scrum master ini, izinkan saya menjabarkan pemikiran saya. Berikut pendapat saya tentang kelebihan dan kekurangan sertifikasi scrum master.

Kelebihan

Kelebihan bagi Karyawan, Pekerja Lepas, Coach, dan Pelatih

• Sertifikasi scrum master mengakui kompetensi dan pengetahuan terkini Anda dalam bidang Scrum.
• Sertifikasi scrum master membantu Anda melampaui rekan yang berhenti mengembangkan diri. Ini membantu Anda mendapatkan pekerjaan impian sebagai scrum master bersertifikasi dan berprestasi.
• Sertifikasi scrum master memperluas perspektif serta membuka pikiran untuk terus belajar. Ini membantu Anda mendapat tanggung jawab lebih besar dan peluang karier luar biasa.
• Sertifikasi scrum master memberi perangkat keterampilan baru untuk menyampaikan produk dan layanan hebat yang disukai klien serta pemberi kerja.

Kelebihan bagi Organisasi dan Pemberi Kerja

• Sertifikasi scrum master mengurangi biaya dengan meningkatkan efisiensi tim, aktivitas, dan proses.
• Sertifikasi scrum master membantu Anda memenangkan proyek yang sebelumnya tidak dapat diraih melalui karyawan terlatih dan terampil.
• Sertifikasi scrum master meningkatkan kepuasan dan komitmen karyawan dengan mendorong pelatihan serta pengembangan keterampilan.
• Sertifikasi scrum master meningkatkan kualitas hasil kerja, kepuasan pelanggan, dan akhirnya keberhasilan serta profitabilitas organisasi.

Kekurangan

• Sertifikasi scrum master tidak boleh menghentikan pembelajaran Anda. Jangan lupa, meraih sertifikasi hanyalah langkah pertama.

  Dalam semangat “inspeksi dan adaptasi” yang Anda pelajari dari kerangka Scrum, terus bereksperimen, mengamati, dan belajar tetap menjadi tugas serta kewajiban Anda.

• Tidak ada solusi yang cocok untuk semua organisasi di dunia. Kerangka pengembangan dan penyampaian perangkat lunak Scrum tidak terkecuali.

  Pengamatan kami menunjukkan bahwa kebanyakan organisasi yang tidak mampu memperoleh kinerja terbaik dari scrum memiliki karakteristik sama: mereka gagal menyesuaikan Scrum dengan ekosistem bisnis dan TI sendiri.

  Karena itu, sekali lagi dengan semangat “inspeksi dan adaptasi”, jangan memandang kerangka scrum sebagai resep keberhasilan dengan jaminan 100%. Jangan meremehkan kemampuan berpikir Anda untuk menyesuaikannya dengan dinamika bisnis dan TI sendiri. Sebagai profesional yang dibayar, memang itulah yang perlu dilakukan agar memperoleh throughput dan hasil bisnis terbaik melalui scrum.

• Scrum tidak menyelesaikan seluruh masalah departemen TI kami. Teruslah mengembangkan diri melalui proses pengembangan dan penyampaian perangkat lunak baru seperti DevOps.

  Untuk lebih memahami kelemahan kerangka Scrum yang diketahui dan cara DevOps menanganinya, bacalah artikel unggulan ini nanti: Apa 6 Perbedaan UTAMA antara DevOps dan Scrum?

Kesimpulannya, sertifikasi scrum master merupakan cara yang sangat baik untuk memulai praktik pengembangan dan penyampaian perangkat lunak agile.

Menurut studi Gartner "Menjadi Scrum Master yang Lebih Baik" dalam artikel yang terbit pada 2019, prakiraan untuk 2023 menyebut bahwa 92% perusahaan di dunia dan 96% perusahaan di Amerika Serikat akan mengadopsi praktik agile Scrum. Ini merupakan prakiraan yang dilaporkan artikel asli, bukan tingkat adopsi terkini yang terukur.

Karena itu, tidak ada waktu lebih baik daripada sekarang untuk

• Mulailah mempelajari kerangka Scrum secara gratis dan
• Raih sertifikasi scrum master dengan biaya sangat terjangkau dari International Scrum Institute™.

Pertanyaan yang tersisa hanyalah, kapan Anda akan memulai?