Belakangan ini lagi mikir-mikir ulang soal Scrum dan role Scrum Master, dari pengalaman beberapa tahun kerja jadi developer yang sehari-hari make Scrum sebagai tools development.
Jujur, pertama kali kantor pindah dari waterfall ke Scrum itu rasanya berantakan. Buang-buang waktu, ga konsisten, dan menurut gue pribadi waktu itu ya emang buruk secara keseluruhan. Tapi belakangan gue sadar itu bukan salah Scrum-nya, tapi karena setiap orang di tim — stakeholder, PO, developer — belum benar-benar ngerti how, why, what to do-nya. Stakeholder ngerasa agile itu berarti bisa berubah semaunya kapan aja. Developer ngerasa semua Scrum event cuma buang waktu doang. Ya jelas berantakan, semua orang mainnya masih pake asumsi masing-masing.
Yang bikin akhirnya membaik itu waktu itu ada Scrum Master yang emang bagus. Dan dari situ gue baru ngeh, peran Scrum Master itu sebenernya bukan soal "menjalankan aturan Scrum" doang. Lebih ke fasilitator — atau istilah bakunya servant leader. Analoginya kayak polisi, sebenernya ada buat kebaikan masyarakat, bukan buat maksa-maksa doang. Pas Scrum Master nyuruh tim retro, atau nyuruh isi story point di backlog, itu bukan formalitas kosong — itu ada gunanya buat ngukur velocity tim dan bikin proses development lebih kebaca.
Satu hal lain yang kepikiran, soal daily standup. Banyak yang bilang standup itu udah berubah jadi "status report ke manager" dan dianggap buruk. Tapi menurut gue itu bukan sepenuhnya salah — namanya juga transparansi. Yang penting esensinya tetep ke arah situ: kasih tau progress, kalau ada hambatan yang bisa dibantu ya dibahas (di luar standup biar ga molor), dan itu ngebangun rasa memiliki ke product-nya juga.
Soal sprint planning yang suka molor, dari pengalaman gue biasanya itu bukan karena planning-nya sendiri yang salah, tapi karena grooming sebelumnya kurang detail. Kalau backlog udah jelas dan udah didiskusiin sama PO dan stakeholder dari awal, planning-nya jadi lebih soal jadwalin doang, bukan debat panjang soal apa yang mau dikerjain.
Yang paling nempel sih soal gimana caranya masuk ke tim yang udah jalan lama tanpa bikin orang defensif. Intinya jangan jadi "threat". Perubahan itu defaultnya emang bikin orang was-was, tapi kalau dibawain dan dijelasin dengan cara yang baik, itu bisa diminimalisir. Makanya kalau misalnya masuk ke tim baru, langkah pertama itu bukan langsung ubah-ubah proses, tapi kenalan dulu sama orang-orangnya, ngerti existing procedure-nya, baru pelan-pelan integrasi.
Overall, makin ke sini makin ngerasa Scrum — atau agile secara umum — itu cuma alat. Kalau dipakein sama orang yang paham kenapa alat itu dipakai, hasilnya bisa jauh lebih baik daripada sekadar ngikutin checklist. Dan kayaknya itu insight yang paling kepake buat gue sekarang dari pengalaman kerja sehari-hari.