Pilar Pertama Agile Software Development: Rilis yang Segera

Navigasi esai: | Intro & Pilar 1 | Pilar 2 | Pilar 3 (bagian 1) | Pilar 3 (bagian 2)


Semua orang memulai Scrum/Kanban/XP/SAFe/Less/dll dengan harapan hidupnya akan jadi lebih baik.

Kadang, kenyataan berkata lain: Mana ‘estimasi yang lebih akurat’ itu? Kenapa developer saya tetap banyak yang keluar? Produk lebih sering dirilis, tapi jumlah pengguna masih stagnan.. 

Di titik itu, biasanya kita mulai curiga: Jangan-jangan ada yang salah di pemahaman saya akan Scrum/Kanban. Sebagian dari kita mulai datang ke meetup, sebagian bahkan langsung mengundang trainer ke kantor. Berharap bisa ditunjukkan jalan yang lurus mengenai Agile Software Development.

Rangkaian artikel tiga pilar ini, memiliki tujuan yang sama: menunjukkan jalan lurus penerapan Agile Software Development.

Saya berharap semua Agile Coach, Scrum Master, Product Owner, dan Developer yang membaca, bisa mengecek kesehatan & ketangkasan timnya.

Untuk CEO dan investor yang membaca tulisan ini, saya berharap inisiatif produk/proyek apapun di dalam benak bapak/ibu statusnya ‘belum dimulai’. Jika ternyata sudah, dan ternyata ada yang berseberangan dengan idealnya Agile Software Development, saya berdoa agar bapak/ibu masih bisa mengubah arah inisiatif. Karena jelas, jika inisiatif gagal, semua pihak merasakan kerugiannya.

Agar berjalan lancar, tegakkan tiga pilar berikut:

  1. Rilis yang sesegera mungkin & sering.
  2. Build-Measure-Learn, baik di level produk maupun proses.
  3. Kualitas teknis yang tinggi & terjaga.

Mereka adalah Tiga Pilar Agile Software Development©. Karena pilar, ketiganya wajib ada.

Seperti cermin, tiga pilar tersebut membantu kita menilai kondisi. Dengan bertanya:

  1. “Seberapa cepat & sering kita merilis sesuatu ke pengguna?”
  2. “Seberapa rutin kita mendengar keluhan pengguna & anggota tim, lalu menindaklanjutinya?”
  3. “Seberapa minim bug, dan seberapa tinggi kualitas kode, saat kita menegakkan pilar 1 & 2?”

Daftar Pustaka

Untuk menguji keabsahan opini saya terkait tiga pilar ini, sembari membaca, teman-teman bisa:

  1. Membandingkannya dengan aturan-aturan di bingkai kerja Agile Software Development (Scrum, Kanban, eXtreme Programming, SAFe, Less).
  2. Mendengar keluhan salah dua ‘pendiri’ Agile Software Development, akan fenomena banyaknya Fake Agile: mengaku Agile tapi tidak melakukan praktik-praktik fundamentalnya. (Dave Thomas: Agile Sudah Mati, Ron Jeffries: Developer Bagusnya Mengabaikan Agile)

Pilar 1: Rilis yang sesegera mungkin & sering

“Cepat belum tentu tangkas, tapi lambat sudah pasti tidak tangkas.”

Navigasi masalah:

Masalah a: Rencana yang Terlalu Besar

Berikut adalah keunggulan seorang visioner: berpikir besar. Kelemahannya: bertindak terlalu besar.

Ketika sebuah inisiatif produk atau fitur besar digulirkan pertama kali, sering kali kita mendengar atasan / klien berpendapat: “Fitur A, B, C, & D harus ada sebelum rilis. Ini penting, karena nanti kita butuh segera merilis E & F. Dengan fitur F, produk kita akan mengguncang dunia persilatan!!!”

Padahal di mata kita sudah jelas, cukup fitur A, B, & C, produk kita sudah cukup berbeda. Karena kebanyakan kompetitor cuma punya fitur A & B. Terlebih, mereka dibebani pula oleh fitur P, Q, R yang mubazir & malah membuat berat.

Sayang, pemimpin inisiatif tidak rela untuk rilis dengan fitur A, B, & C saja. Dia benar-benar jatuh cinta dengan fitur F. Alhasil, pengembangan pun digulirkan dengan target pengerjaan A, B, C, D. Di atas kertas, estimasi pengerjaan adalah 6 bulan. Realitanya, molor ke satu tahun.

Setelah D selesai, pemimpin inisiatif berubah pikiran. Beliau hanya mau rilis sampai F beres. Akhirnya pengembangan diperpanjang, F beres — setelah 5 bulan berkerja keras. Produk lalu diluncurkan. Ternyata…

Fitur F tidak disukai penguna. Fitur C jarang yang pakai. Harusnya pimpinan merilis A, B, & C, sebelum mengembangkan fitur lanjutan.

Solusi:

Pimpinan inisiatif — yang berkerja berdasarkan Agile Software Development — wajib menyunat target rilis sekecil mungkin, sedemikian sehingga bisa secepat mungkin memvalidasi nilai manfaat sebuah ide produk/fitur.

Dalam Scrum, idealnya paling lama setiap satu bulan ada versi terbaru untuk dirilis. Di lapangan banyak yang tiap satu atau dua minggu.

Kalau Anda di posisi vendor yang mengerjakan pesanan klien, beranikan diri untuk minta klien memperkecil lingkup proyek, sehingga bisa segera rilis. Edukasi mereka akan pentingnya memperkecil asumsi. Rezeki Anda memang berkurang sementara. Tapi peluang klien puas dan Anda dipanggil lagi jadi meningkat.

Masalah b: Birokrasi yang Memaksa Besar

Kadang, kendalanya ada di birokrasi.

“Proyeknya harus di atas 750 juta Pak, supaya bisa masuk anggaran tahun depan.”

Alhasil, kita jadi tergoda membuat rencana besar. Menumpuk banyak fitur-fitur (baca: asumsi-asumsi) di proposal, lalu jatuh cinta sendiri dengan mereka.

Solusi:

  • Ubah peraturan;
  • Gabung beberapa inisiatif kecil yang terpisah ke satu proyek, sehingga berada di payung anggaran yang sama.

Masalah c: Birokrasi yang Mempersulit Rilis

“Di sini, kalau rilis fitur baru, harus dapat dulu tanda tangan tiga lapis pimpinan.”

“Sudah peraturan di sini Bu, rilis hanya saat menjelang tutup proyek. Setelah serah terima antara vendor & klien.”

Semakin lama kita menunggu validasi manfaat sebuah fitur, semakin besar peluang untuk tidak melakukannya sama sekali.

Solusi:

  • Ubah peraturan;
  • Tidak ada hukumnya bahwa rilis harus ke semua pengguna — umpan balik itu tidak mesti dari semua pengguna. Pelajari cara rilis untuk pengguna terbatas (Canary Release, Beta User). Jadi, tidak ada alasan untuk bilang “hardware atau embedded system tidak bisa Agile”.

Masalah d: Tim Developer yang Masih Hijau

“Fitur sudah dirancang keciiiil sekali, tapi kok kita masih butuh satu bulan ya untuk menyelesaikan sebuah fitur? Estimasinya juga sering meleset. Kenapa ya?”

Kadang, masalahnya ada di sisi teknis: tim developer yang kurang kompeten. Fenomena yang dimaklumi akibat kelangkaan programmer.

Solusi:

Masalah a, b, c, d di atas hanyalah beberapa contoh. Terpikir masalah lain yang menghambat rilis yang cepat & sering? Atau punya pengalaman pribadi? Tulis kotak komentar di bawah ya… 🙂


Selanjutnya: pilar kedua.

Product Manager dari Learn.AgileCampus.org

Ada pertanyaan atau pendapat?