---

Apa Penyebab Kekacauan dan Frustrasi Sebelum Kerangka Kerja Scrum? Ini Mungkin Mengejutkan Anda!

Untuk memahami dampak Scrum pada praktik rekayasa perangkat lunak serta bisnis, mari kita melihat satu hari kehidupan proyek perangkat lunak.

Saya ingin membahas singkat proyek masa lalu sebelum kami menerapkan kerangka pengembangan serta penyampaian perangkat lunak Scrum dalam organisasi.

Beberapa hari sebelum menulis ini, kami makan siang dengan mantan rekan yang bekerja bersama kami hampir 20 tahun lalu.

Marcus memperoleh sertifikasi Scrum Master dan sertifikasi Scrum Product Owner dari International Scrum Institute™. Kini ia menjadi Scrum Master di salah satu perusahaan perangkat lunak terkemuka dalam bidang perangkat lunak pengelolaan proyek agile.

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

Saat makan siang, Marcus mengakui banyak tantangan umum tim Scrum agile terdistribusi. Beberapa masalah khusus dalam konfigurasi proyeknya adalah:

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

Meskipun menghadapi kesulitan ini, Marcus menambahkan bahwa menjalankan proyek perangkat lunak dengan proses Scrum agile lebih menyenangkan, produktif, dan memperkaya daripada cara kerja kami 20 tahun lalu. Dibandingkan masa ketika kami bekerja tanpa proses pengembangan serta penyampaian perangkat lunak Scrum.

Pernyataan Marcus merupakan kesaksian besar bagi keunggulan Scrum dari manajer, Scrum Master, serta Product Owner yang sangat berprestasi dan berpengalaman.

Terima kasih, Marcus!

Lalu kami menjelaskan salah satu proyek perangkat lunak sebelum menerapkan Scrum. Saya yakin banyak Scrum Master mengenali pengalaman serupa pada proyek sebelum memperoleh sertifikasi Scrum Master.

Pada akhir 1990-an, kami menjadi bagian kelompok rekayasa perangkat lunak untuk membangun 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.

Dalam proyek tersebut, kami belum menggunakan konsep produk layak minimum (MVP) untuk bereksperimen, membuat, belajar, dan bereksperimen kembali.

Tanpa Scrum, membangun infrastruktur canggih dengan banyak unsur perangkat keras serta perangkat lunak merupakan tantangan nyata.

Berikut tiga kendala besar yang kami hadapi tanpa Scrum Master atau orang bersertifikasi Scrum Master dalam tim.