Disclaimer: saya bukan praktisi apalagi ahli SCRUM, saya cuman banyak membaca tulisan tentang SCRUM dan ngobrol dengan temen praktisi SCRUM.

Kemarin, ketika mengikuti acara BaperGramer dengan tema “Road to SCRUM” yang diisi oleh senior saya di HMTI UDINUS mas R. Gesit Prasasti Alam, ada cerita menarik yang menurut saya harus di-share secara bebas. Konon cerita ini adalah cerita nyata hasil pengalaman beliau menebarkan benih SCRUM di seluruh pelosok nusantara, namun cerita ini sengaja saya modifikasi tanpa menghilangkan esensinya untuk menyamarkan identitas.

Di suatu ketika ada sebuah perusahaan yang memiliki struktur tim software development yang cukup komplit, mulai dari project manager, analyst, programmer, hingga tester. Tahu dong kurang lebih peran dari masing-masing struktur tersebut, sederhananya PM bagian dealing project dan estimasi awal, analyst bagian pengumpul requirement dan membuat perancangannya, developer bagian koding, dan tester bagian yang nyoba ngancurin aplikasi.

Sebelum menggunakan SCRUM, metode pengembangan yang digunakan pada perusahaan tersebut adalah metode paling keren dan terbukti paling banyak digunakan di seantero nusantara yaitu DDD (you know what lah, kalo nggak tahu tanya di komentar ya). Alur kerjanya kurang lebih sebagai berikut:

• PM ketemu stake holder (kepala bagian / unit lain) untuk dealing project dengan sekup waktu let’s say 3 bulan.
• Kemudian, PM rapat sama tim development dan baru nyadar kalau sebenernya waktu yang diperlukan harusnya minimal 5 bulan, tapi karena udah telanjur DEAL, ya mbuh nggak tahu gimana caranya tetep harus selesai 3 bulan.
• Selanjutnya bagian analyst yang kerja, mereka rapat dengan stake holder untuk memetakan kebutuhan dan bikin perancangan.
• Selesai rapat analyst menyampaikan ke programmer / coder, dan ternyata baru ketahuan kalau ada detail yang cukup krusial dan masih kurang. Akhirnya si analyst balik lagi ke stake holder menanyakan detail yang tercecer tadi.
• Sambil nunggu requirement yang kurang, Programmer eksekusi koding secepet-cepetnya dan sebisa-bisanya, meskipun agak semrawut dikit nggak apa-apa karena cita-citanya koding tersebut akan dibersihkan nanti aja setelah kerjaan kelar.
• Setelah komponen aplikasi selesai diuji oleh tester, ternyata betul banyak bug di sana-sini sehingga dilapokan dan dikembalikan ke programmer untuk direvisi lagi.
• Programmer bingung harus ngerjain yang mana dulu antara ngerjain fitur selanjutnya, benerin bug, atau ngerapiin kode, dan akhirnya tinggal main Mobile Legend dulu aja. Ketika deadline udah semakin dekat, akhirnya programmer lemburan untuk menyelesaikan aplikasi, yang penting selesai fitur yang diminta dan agak mengabaikan bug.
• Bulan ketiga aplikasi tambal sulam selesai diserahkan ke stake holder dan tentu saja banyak yang error dan nggak jalan.
• Stake holder nggak mau tahu  aplikasinya dikembalikan ke development team untuk dibenerin. Dan guess what estimasi buat benerin aplikasi itu kurang lebih 6 bulan (lebih lama dari estimasi waktu di awal).
• Ketika baru berjalan setengah bulan ngerjain revisi, PM sudah datang kembali membawa proyek yang baru lagi.

Familiar dengan alur kerja seperti di atas?

Kemudian datanglah seorang SCRUM Master untuk merubah struktur organisasi dan alur kerja. Bukan hanya itu, SCRUM Master juga membawa serangkaian mindset baru yang dapat membuat tidak hanya membuat perusahaan memiliki software yang lebih valid dan berkualitas, tapi juga mampu merubah hidup developer menjadi lebih indah dan tidur mereka menjadi lebih nyenyak.

Cerita tentang sepak terjang SCRUM master berlanjut ke postingan berikutnya….