Penyebab Utama Kegagalan Agile dan Solusinya

Tulisan ini pertama kali dipublikasikan di Medium Organisasi Agile. Langgan publikasi tersebut untuk membaca tulisan Rizky lebih awal dari yang lain.

Ya, Agile memang aneh — dan manjur. Buku yang ditulis tahun 1987 telah menjelaskan kenapa.

Kenapa Agile?

Tepat saat esai ini ditulis, warga Indonesia sedang berada di atas ombak transformasi digital: pembayaran online. Promo Gopay & OVO ada di mana-mana. Cukup scan QR code, pembayaran beres. Transfer dana cukup pakai nomor telepon.

Tujuan akhirnya, akan seperti yang Dahlan Iskan rasakan saat bayar ke pedangan kaki lima di Cina: bayar dengan uang cash dianggap aneh.

Ombak transformasi digital ini bukan yang pertama & terakhir. Sebelum perihal pembayaran, ada Whatsapp dengan grupnya, ada Gojek & Grab dengan kemudahan transportasinya. Setelah pembayaran, entah apa lagi yang akan didigitalisasi.

Sekarang, cara hidup kita bisa berubah drastis dalam hitungan 1–2 tahun. Sebagaimana masyarakat Inggris di akhir abad 18 & awal abad 19 terhadap kemunculan mesin uap, kita sedang jadi saksi hidup sebuah revolusi peradaban.

Karena potensinya yang luar biasa, perusahaan berlomba-lomba menelurkan produk digital yang inovatif. Baik untuk penggunaan pelanggan mereka di luar, maupun pegawai mereka di dalam, proses kerja dibuat lebih ringkas & bermanfaat.

Pertanyaan selanjutnya — bagi para pemilik perusahaan yang ingin membuat produk digital inovatif — adalah “bagaimana cara terbaiknya”? Jika mereka tanya teman mereka, atau jika mereka googling, Agile Software Development adalah jawaban paling mungkin muncul.

Survei-survei dari VersionOne (2013), Scott Ambler (2012), Microsoft (Begel & Nagappan, 2006), dan Dan Rico (2008), menunjukan bahwa mengembangkan dengan cara Agile, membuat software dipakai lebih cepat, lebih fleksibel terhadap perubahan, dan berkualitas tinggi.

Apa bumbu rahasia ampuhnya Agile Software Development?

1. Agile Software Development menjadikan umpan balik pengguna & iterasi singkat sebagai penentu arah produk ke depannya. Akibatnya, konsep “requirement”, “deadline”, “kontrak”, dan “blueprint” di manajemen proyek software klasik seperti dijungkirbalikkan. Muncul pula konsep antah berantah seperti “minimum viable product”.
2. Agile Software Development juga menekankan bahwa para pekerja akan lebih produktif jika diberikan otonomi, dibanding dikontrol penuh oleh atasan.

Kegagalan Agile di Beberapa Perusahaan

Bagi yang baru mendengar, pengembangan software yang Agile memang aneh.

Selain keanehannya, ada masalah kedua: Agile Software Development tidak diajarkan di semua sekolah atau perguruan tinggi. Institusi-institusi yang sudah mengajarkanpun, belum tentu sepakat akan materi ajarnya. Harap maklum, di tanah kelahirannya sendiri, dia baru menyebar di awal tahun 2000-an.

Saya kuliah sarjana Ilmu Komputer dari Universitas Indonesia. Di tahun 2011, Agile Software Development hanya disinggung singkat di dua pertemuan mata kuliah Rekayasa Perangkat Lunak.

Agile Software Development itu aneh & baru.

Alhasil, di antara perusahaan-perusahaan belajar & menjalankan Agile Software Development, beberapa berhasil, dan banyak yang salah paham. Atau misalpun tidak salah paham, dia gagal diterapkan.

Penyebab Utama Kegagalan Agile

Kenapa gagal?

Menurut survei yang dilakukan Version One (2018), lima penyebab utama kegagalan sebuah inisiatif Agile Software Development adalah:

1. Filosofi dan budaya perusahaan berseberangan dengan nilai-nilai agile.
2. Organisasi secara luas tidak ingin berubah.
3. Kurangnya dukungan manajemen & pimpinan.
4. Kurangnya pengalaman terhadap metode-metode agile.
5. Kurangnya program pelatihan.

Untuk poin keempat dan kelima, cukup jelas, penyebabnya adalah karena Agile Software Development itu baru. Solusinya juga jelas, segera coba sendiri dan/atau segera konsultasi dengan yang lebih berpengalaman.

Yang menarik adalah poin pertama sampai ketiga. Mereka semua berhubungan. Semuanya bisa dirangkum menjadi:

“Ketidakpahaman pimpinan akan apa itu Agile & dampak-dampaknya”.

Kenapa? Sederhana. Perubahan prilaku level organisasi harus didukung dulu oleh pimpinan organisasi. Filosofi & budaya baru perusahaan juga harus digaungkan & dicontohkan dulu oleh pimpinan — baik level direktur maupun manajer.

Survei berkata: menjalankan Agile Software Development ternyata membutuhkan organisasi yang Agile. Dan kita semua tahu, di semua transformasi level organisasi, dukungan & contoh pimpinan adalah syarat yang pertama & utama.

Jadi apa penyebab kegagalan inisiatif Agile Software Development? Sekali lagi: “Ketidakpahaman pimpinan akan apa itu Agile & dampak-dampaknya”.

Kenapa tidak paham? Bukankah tinggal googling, baca Wikipedia, atau menonton video Youtube? Betul, itu semua cukup untuk tahu.

Sayangnya, tahu belum tentu setuju. Setuju belum tentu melakukan & menjiwai. Ingat, Agile adalah filosofi/budaya/pola-pikir, bukan sebuah ilmu atau metode.

Mengutip Ramot Stephanus, CEO Agile Campus:

“Karyawan tidak akan bisa Agile selama pimpinan belum Agile.”

Penyebab Pimpinan Sulit Paham & Dukung Agile

Jadi apa penyebabnya?

Antipati.

Sentimen negatif sudah disematkan kepada Agile. Hasilnya: ketidakpedulian, salah tangkap, keengganan untuk mengimplementasi, dan serangan balik.

Tahu dari mana? Pengalaman pribadi. Jujur, saya belum menemukan hasil survei yang mendasarinya. Data saya adalah data pribadi selama 5 tahun menjadi pelatih Scrum. Orang-orang yang menolak Agile, biasanya mengeluh dengan bermacam variasi dari kalimat-kalimat berikut:

“Ah, Agile hanya bungkus baru jualan kaum konsultan.”

“Ah, Agile hanya teknik manajemen untuk mengatur pekerja dengan post-it. Biar orang dapur saja yang urus.”

“Ah, Agile terlalu utopis. Apalagi di Indonesia, mana bisa!?”

Mari kita berempati. Amat wajar banyak dari mereka antipati. Buat mereka, Agile benar-benar seekor binatang baru.

Pola pikir & kebiasaan yang berpuluhan tahun terbukti manjur, harus dihadapkan dengan dua pernyataan aneh ini?

1. Pengambilan keputusan harus didasari data empirik, kekuasaan jabatan tidak lagi cukup.
2. Pekerja harus diberikan otonomi dalam transparansi, bukan lagi sebagai mur dan baut sebuah mesin.

Bagaimana bisa mereka tidak antipati?

Solusi

Saat kepercayaan seorang diserang, respon pertamanya adalah langsung menutup diri.

Antipati dari awal → langsung menutup diri dari segala hal yang berlabel “Agile”.

Tidak heran kalimat berikut muncul: “Ah, Agile hanya bungkus baru jualan kaum konsultan.” Tidak heran banyak yang salah atau tidak utuh saat memahami Agile Software Development. Tidak heran, meski sudah tahu, kadang mereka tidak mau menerapkan beberapa anjuran di Agile Software Development. Munculnya komik-komik Dilbert di atas adalah bukti. Mereka lucu karena memang — sedihnya — terjadi di dunia nyata.

Maka, solusinya adalah dengan memberikan bukti, yang sama sekali tidak ada kaitan dengan Agile — sumber antipati mereka.

Antipati dari awal → langsung menutup diri dari segala hal yang berlabel “Agile” → butuh bukti-bukti nyata yang tidak ada satupun label “Agile”.

Bukti-bukti tersebut ada di buku Peopleware: Productive Projects and Teams. Buku manajemen proyek software yang edisi pertamanya dirilis tahun 1987. Saat itu, belum ada metode Agile Software Development yang dieksperimenkan.

Jadi, jika dihadapkan Peopleware, orang akan sulit bilang “ah, ini cuma propaganda baru orang-orang Agile.”

Peopleware ditulis oleh Tom DeMarco (lahir 1940) & Timothy Lister (lahir 1949). Keduanya adalah veteran konsultan pengembangan software — bisa dilihat dari kunonya website mereka. Riset penulisan Peopleware sendiri berlangsung 10 tahun. Dengan penulis yang punya otoritas dan persiapan yang serius, tidak heran Peopleware menjadi salah satu buku klasik.

Dirilis tahun 1987, apakah artinya justru sudah kedaluwarsa? Kalau Peopleware adalah buku teknologi, tentu iya. Tapi Peopleware adalah buku tentang pentingnya sisi manusia di sebuah proyek software. Justru, dengan makin kompleks dan besarnya proyek software — ingat tahun 1987 internet masih dalam kandungan — anjuran-anjuran di buku Peopleware malah makin relevan. Persis yang juga dibilang Joel Spolsky:

“Wajib baca, minimal satu tahun sekali… puluhan tahun setelah buku ini ditulis, Peopleware justru makin relevan.” ~ Joel Spolsky

Joel Spolsky bukan orang sembarangan di dunia proyek software. Dia adalah salah satu pendiri dari Stackoverflow & Trello. Mantan programmer Microsoft. Blogger populer di bidang rekayasa software.

Joel membaca Peopleware saat magang di Microsoft sebagai mahasiswa. Manajer-manajer di Microsoft saat itu membaca Peopleware. Perlu dicatat, Joel resmi bekerja di Microsoft tahun 1991 — saat metode-metode Agile Software Development mungkin masih dieksperimenkan para penciptanya. Jadi, penilaian Joel terhadap buku Peopleware juga tidak terkontaminasi kepopuleran Agile Software Developement.

Berikut beberapa pujian untuk buku Peopleware:

“Buku ini benar-benar mengajarkan saya cara menjalankan proyek. Saya belajar tentang mitos kerja lembur, pentingnya penutup & seremoni, bagaimana kelahiran tim yang kompak…” ~ Kevin Kelly, pendiri Cool Tools.

“Ini buku yang hebat, umurnya sudah 20 tahun tapi masih relevan. …rekomendasi mereka (Tom & Tim) untuk memberikan tempat kerja yang sunyi menyentuh saya.” ~ Mitch Fincher, blogger di dunia programming.

“Kalau kamu pernah melihat tim olahraga mega-bintang yang melemah karena pelatih yang buruk, kamu akan mengapresiasi buku ini. …Kalau kamu ingin benar-benar jadi ‘pemimpin tim’ yang bukan sekedar jabatan, miliki buku ini.” ~ Jeff Atwood, pendiri Stackoverflow, blogger populer di dunia pembuatan software.

“Buku ini mencengkram kamu dari awal, saat penulisnya menjelaskan tentang masalah kantor yang familiar di telinga semua orang — politik — dan apa yang kita bisa lakukan terhadap masalah tersebut.” ~ Hannah Hazi, programmer di grabCAD.com.

Dari pujian-pujian di atas saja, kita bisa lihat sekilas hubungan Peoplewaredengan Agile Software Development.

• Tempat kerja yang sunyi: pentingnya fokus & perlindungan Scrum Master dari gangguan luar
• Bahaya kerja lembur: estimasi hanya boleh dilakukan tim developer
• Pentingnya penutup & seremoni: sprint yang pendek & pemecahan requirement yang kecil serta modular
• Tim yang kompak: otonomi tim produk dan tim developer
• Masalah politik: pentingnya komunikasi yang baik, disiplin, dan melibatkan semua pihak — inti dari semua bingkai kerja Agile Software Development

Selain itu Peopleware, juga mengajarkan:

• Hasil penelitian dari University of New South Wales, yang menunjukkan jika developer yang mengestimasi sendiri lama pekerjaan mereka, proyek akan lebih cepat selesai.
• Pentingnya membiarkan tim developer menentukan sendiri standar kualitas kode mereka, juga tim produk menentukan sendiri standar kualitas software mereka. Tim & Tom memberikan contoh nyata manfaat praktik tersebut.
• Pentingnya membiarkan pekerja merancang tempat kerja mereka sendiri, demi fokus yang maksimal.
• Pentingnya menghitung resiko bisnis sebuah proyek/inisiatif software.

Deja vu? Betul sekali. Semua poin itu ada di Agile Software Development!

Rangkuman

1. Agar lebih kompetitif, perusahaan ingin lebih inovatif.
2. Perusahaan ingin mempraktikkan Agile Software Development — karena sudah terbukti mengahasilkan produk-produk inovatif.
3. Beberapa gagal, alasan utamanya adalah ketidakpahaman pimpinan akan apa itu Agile & segala dampak-dampaknya.
4. Mereka gagal paham karena lebih dahulu antipati terhadap Agile Software Development — akibat ‘keanehan-keanehannya’.
5. Agar tidak antipati dan mau menerapkan, mereka perlu sepakat terlebih dahulu terhadap ‘keanehan-keanehan’ yang dibawa Agile Software Development.
6. Mereka akan lebih mudah menerima, jika mendengar bukti-bukti nyata dari pihak di luar Agile Software Development.
7. Kandidat terbaik adalah Peopleware: Productive Projects and Teams — buku manajemen proyek software populer yang ditulis di tahun 1987.

Ya, Agile memang aneh — dan manjur. Buku yang ditulis tahun 1987 telah menjelaskan kenapa.

Panggilan untuk Beraksi (Call to Action)

Ada beberapa pilihan. Silahkan pilih satu, beberapa, atau semuanya:

• Beli & baca buku Peopleware. Hapalkan poin-poin penting di dalamnya. Utarakan setiap kali diperlukan di kantor. Pinjamkan Peopleware ke rekan-rekan yang mulai berminat.
• Beli ulasan Peopleware dari Agile Campus. Rizky menjelaskan poin-poin menarik di buku Peopleware, dari sudut pandang Agile Software Development. Bisa langsung beli di laman Tokopedia kami atau lihat-lihat learn.agilecampus.org dulu.
• Undang Rizky Syaiful untuk berbicara tentang Peopleware di kantor di waktu makan siang. Gratis. Karena Agile Campus sedang memberikan program The Peopleware Tour. Segera isi borang Google Form di sini, agar tidak kehabisan slot.