Kesalahan Populer saat Menulis Scrum di Proposal

Tulisan ini akan membantu Anda menyelamatkan proyek/inisiatif Anda—mulai dari proposalnya.

Sepengamatan saya, banyak implementasi Scrum yang sudah bermasalah sejak dalam kandungan. Um, maksudnya, sejak dalam proposal.

Kita semua tahu, baik di hubungan kerja klien-vendor eksternal ataupun lintas divisi internal, semua inisiatif dimulai dari proposal. Proposal memicu pembahasan proses kerja (baca: cara berkomunikasi & berkoordinasi). Semua pihak berdiskusi mencari win-win solution. Hingga akhirnya disahkan di kontrak kerja.

Scrum sendiri—sebagaimana sebuah proses kerja—tentu harus dibahas & disepakati implementasinya di awal.

Berikut dua kesalahan populer saat menjelaskan Scrum di proposal—dilanjutkan dengan solusinya.

1. Tidak Detail Karena Berasumsi Semua Orang Membaca Scrum Guide

Bila melihat proposal yang bagian metode kerjanya hanya berisi:

• Pernyataan bahwa pengembangan akan memakai Scrum,
• Definisi Scrum yang dikutip dari Scrum Guide: “Scrum (kb): Sebuah kerangka kerja dimana orang-orang dapat mengatasi masalah kompleks adaptif, dimana…”,
• Tautan ke Scrum Guide (buku resmi yang menjelaskan Scrum),

maka proposal tersebut masuk ke kategori ini. Kemungkinan besar, akan ada miskom yang pelik di implementasi nanti.

Bergantung pada kalimat “kan saya sudah menulis ‘Scrum berdasarkan Scrum Guide’ di proposal & kontrak bermaterai, kalau mereka tidak mau menerapkan ya salah mereka”, adalah langkah yang naif. Di banyak kasus, orang bukannya tidak mau menerapkan sebuah aturan di Scrum, tapi memang tidak bisa. Keterbatasan-keterbatasan inilah yang harusnya diangkat di awal, sehingga bisa dicari cari jalan keluarnya. Ini seringkali luput karena detail Scrum tidak ada di proposal, sehingga tidak dibahas.

Scrum Guide memang hanya 17 halaman A4, tapi dia bukan jenis dokumen yang semua orang bisa langsung baca & paham.

2. Detail Tapi Salah Karena Tidak Tahu / Belum Paham Isi Scrum Guide

Ada yang mendetailkan tapi salah. Bisa itu berarti kurang lengkap, atau juga tidak tepat. Penyebabnya, tentu karena penulis proposal belum paham Scrum Guide dan Tiga Pilar Agile.

Solusi: Inti-Inti Scrum-nya Detail & Mudah Dicerna

Dengan problem di atas, kita bisa rangkum ciri-ciri proposal yang bagus.

1. Bisa mengedukasi orang awam tentang apa itu Scrum yang benar.
2. Cukup singkat dan sederhana untuk dibaca bersama-sama di meja makan.
3. Bisa memicu semua pihak untuk mendetailkan hak/kewajiban masing-masing—sehingga akhirnya tertuang di kontrak.

Artinya, di proposal, cukup ada poin-poin penting dari Scrum Guide & harus dijelaskan dengan bahasa yang sederhana.

Seperti apa contohnya? Baca di tulisan berikut ini.