Pilar Pertama Agile Software Development: Rilis yang Segera

Navigasi esai: Intro & Pilar 1 · Pilar 2 · Pilar 3


Di esai sebelumnya, kita belajar bahwa Agile Software Development benar-benar berbeda dengan cara lama. Terlebih, banyak perubahan yang berada di level organisasi. Maka, penyebab utama kegagalan adalah pimpinan yang tidak paham & mendukung.

Timbul pertanyaan: memang dukungan konkrit apa saja yang dibutuhkan?

Banyak.

Untungnya, semua bisa dirangkum ke tiga pilar ini:

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

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

Valid?

Tunggu, tunggu, memang siapa sih Rizky Syaiful itu? Kenapa saya harus mendengar pendapat dia? Ini kan pilar; sesuatu yang fundamental. Harusnya saya mendengar dari pakar terkenal!

Meski Rizky sudah lima tahun jadi trainer Scrum, tiga pilar di atas bukan opini dia. Melainkan dari…

Satu. Scrum, dkk.

Silahkan lihat sendiri Scrum, Kanban, & XP (eXtreme Programming) — dan pelbagai cara kerja Agile Software Development lainnya. Aturan mereka semua berputar-putar di tiga pilar itu.

Scrum & Kanban fokus pada pilar pertama (rilis) & pilar kedua (BML). Pilar ketiga (kualitas teknis) dianjurkan, tapi tidak ada tuntunan detail dari mereka berdua. XP mengisi kekosongan dengan mendetailkan pilar ketiga.

Mereka bertiga menyuruh melakukan Build-Measure-Learn dari sisi produk. Tapi tidak ada satupun yang mendetailkan bagaimananya. Akibatnya, bingkai kerja Design Sprint diciptakan, untuk mengisi kekosongan — meski jelas belum cukup.

Dua. Artikel-artikel populer dari salah dua ‘pencipta’ manifesto Agile Software Development di tahun 2001, Dave Thomas (Agile Sudah Mati) & Ron Jeffries (Developer Bagusnya Mengabaikan Agile).

Berdasarkan dua artikel tersebut, banyak pelaku industri yang merobohkan satu (bahkan dua atau tiga) pilar Agile Software Development. Menurut Dave Thomas, mayoritas terjebak dalam kotak-kotak mekanik bingkai kerja. Dia mengajak orang untuk fokus ke esensinya, yaitu pilar kedua. Menurut Ron Jeffries, kepopuleran Scrum justru membuat pilar ketiga diabaikan. Sebuah masalah besar buat Ron — seorang pendukung XP.

Jadi, jelas ya sekarang, tiga pilar tersebut bukanlah opini pribadi Rizky Syaiful semata. Tiga pilar tersebut valid.

Mari kita lihat mereka satu-per-satu. Mudahnya, dari sudut pandang masalah.

Pilar 1: Rilis yang sesegera mungkin & sering

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

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.

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.

Masalah d: Sulit Rilis Secara Teknis

“Fitur sudah dirancang keciiiil sekali, tapi kok kita masih butuh satu bulan ya untuk menyelesaikan sebuah fitur?”

Kadang, masalahnya ada di sisi teknis: developer yang kurang berpengalaman; butuh banyak langkah untuk deploy; testing yang lama — karena masih manual.

Solusi:

  • belajar;
  • pekerjakan pelatih teknis.

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

Selanjutnya: pilar kedua.

Product Manager dari Learn.AgileCampus.org