Pilar Pertama Agile Software Development: Rilis yang Segera

Kenapa Tiga Pilar Agile Harus Ada dan Populer?

Singkatnya, karena dia adalah solusi bagi implementasi bingkai kerja Agile yang bermasalah. Berikut elaborasi lengkapnya…

Semua orang memulai sebuah bingkai kerja Agile (Scrum/Kanban/XP/SAFe/Less/dll) dengan harapan hidupnya akan jadi lebih baik.

Kadang, kenyataan berkata lain. Setelah belajar dan coba mempraktikkan, pertanyaan-pertanyaan berikut tetap muncul:

  • Mana ‘estimasi yang lebih akurat’ itu?
  • Kenapa developer saya tetap banyak yang keluar?
  • Produk lebih sering dirilis, tapi jumlah pengguna kok masih stagnan?
  • Semua aturan Scrum1 sudah dijalankan berbulan-bulan, apakah Agile itu cuma seperti ini saja?

Di titik itu, yang cukup bijak biasanya mulai curiga:

  • “Jangan-jangan ada yang salah di pemahaman saya akan Scrum?”
  • Jangan-jangan ada yang salah di tempat/cara belajar dulu?

Sementara yang cukup bijak menunda ambil kesimpulan, sisanya, langsung menghakimi bahwa Agile hanyalah minyak ular jualan terbaru kaum konsultan.

Sebagian dari yang bijak mulai datang ke meetup-meetup, demi mencari guru yang mumpuni. Sebagian bahkan langsung mengundang trainer Agile ke kantor—saya salah satunya. Berharap bisa ditunjukkan jalan yang lurus mengenai Agile Software Development. Sepenglihatan saya dari luar, mayoritas dari mereka akhirnya menemukan pencerahan, yaitu:

  1. Definisi & implementasi Scrum/Kanban/XP yang sesuai dengan yang dibuat penciptanya.
  2. Pemahaman bahwa Agile bukanlah sekedar Scrum/Kanban/XP. Agile adalah pola pikir—bahkan budaya.
  3. Pemahaman bahwa benefit yang dijanjikan di awal tulisan ini, akan didapat jika semua anggota di organisasi sudah memahami dan menghidupi budayanya—bukan sekedar memenuhi checklist Scrum/Kanban/XP.

Intinya, Agile itu adalah budaya. Menjalankan Scrum/Kanban/XP sebelum menghidupi budayanya, adalah resep dari kegagalan.

Kenapa tidak banyak yang menyadari ini? Dari sisi meetup gratis, selain sifatnya yang tidak berkelanjutan, topik ini masih jarang diangkat. Di sisi training berbayar:

  1. Terlalu fokus pada satu bingkai kerja (Scrum). Sehingga kurang zoom-out untuk melihat budaya Agile-nya.
  2. Masih sedikit trainer-nya. Sehingga tidak semua orang orang bisa teredukasi
  3. Biayanya cukup berat kalau tidak dibayarkan kantor. Kenapa? Karena hukum supply-demand. Scrum populer sementara trainer-nya masih sedikit.

Bagaimana dengan sekolah formal? Apakah lulusan-lulusan baru sudah memahaminya? Jawabannya, sulit. Bukan karena di kurikulum mereka belum ada materi pengembangan software Agile, tapi lebih karena format kegiatan belajar-mengajar. Umumnya, di sekolah/kampus, siswa tidak bisa fokus mengembangkan aplikasi—yang sedang aktif dipakai pengguna—selama minimal satu tahun. Sementara budaya Agile hanya bisa terasa di pengembangan yang fokus dan berorientasi pada pengguna.

Entah itu meetup, training atau sekolah, belum ada yang bisa menyebarkan pentingnya budaya Agile ke publik luas.

Maka, mari kita mempopulerkan Tiga Pilar Agile. Kalau bukan sekarang, kapan lagi?

Jadi, Apa itu Tiga Pilar Agile?

Untuk menghidupi budaya Agile, pastikan tiga hal berikut dihidupi:

  1. Rilis secepat-cepatnya & sesering-seringnya.
  2. Build-Measure-Learn pada produk & proses kerja.
  3. Haramkan burnout & hutang teknis.

Mereka adalah Tiga Pilar Agile.

Seperti cermin, tiga pilar tersebut membantu kita menilai budaya kerja, dengan bertanya:

  1. “Seberapa cepat & sering kita merilis sesuatu ke pengguna?”
  2. “Seberapa rutin kita mendengar keluhan pengguna & anggota tim, lalu menindaklanjutinya?”
  3. “Seberapa disiplin kita untuk menjaga performa pengembangan di masa depan tidak turun?”

Dinamakan ‘pilar’, karena ketiganya wajib ada. Kalau satu saja hilang/lemah, budaya Agile akan terancam.

Untuk Siapa Tiga Pilar Agile Itu?

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.

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.

  1. Kenapa hanya Scrum yang disinggung? Itu karena popularitasnya jauh mengalahkan yang lain

Product Manager dari Learn.AgileCampus.org

Ada pertanyaan atau pendapat?