Penyebab Utama Kegagalan Agile dan Solusinya (bag. 2)

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

Di tulisan bagian sebelumnya, Penyebab Utama Kegagalan Agile, kita telah mengetahui: pemahaman akan Agile & dukungan penuh pemimpin perusahaan adalah kunci.

Sekarang, mari kita fokus pada solusi. Upaya apa yang perlu dilakukkan, agar pimpinan paham akan Agile & mendukung penuh?

Penyebab Pimpinan Sulit Paham & Dukung Agile

Jadi apa penyebabnya?

Antipati.

Sentimen negatif sudah disematkan kepada Agile. Hasilnya: ketidakpedulian, salah tangkap, pemahaman yang tidak lengkap, keengganan untuk mengimplementasi, atau 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 ideal itu terlalu utopis. Apalagi di Indonesia, mana bisa!? Ambil mekanik Agile-nya aja: rapat-rapatnya, backlog-backlognya, tidak lupa post-it-post-it-nya.”

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.

Dua pernyataan yang berujung ke: software harus segera dirilis sehingga requirement bisa diubah; requirement yang harus diriset ke pengguna sebelum sampai ke tim developer; tim developer boleh mengestimasi sendiri lama kerja mereka; tim developer yang dibebaskan mengatur diri sendiri asal transparan. Sesuatu yang super aneh.

Ada banyak yang harus mereka ubah. Berubah sedikit saja melelahkan dan berat buat manusia. Apalagi kalau banyak?

Bagaimana bisa mereka tidak antipati?

Agile? Makhluk apa ini!?

Saat kepercayaan lama 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 tulisan pertama adalah bukti. Mereka lucu karena memang — sedihnya — terjadi di dunia nyata.

Mereka terkurung oleh antipati mereka terhadap Agile.

Solusi

Pertama-tama, harus kita akui, ini berat. Karena kita bicara tentang kegiatan mengubah-perspektif-manusia.

Tapi harus diakui juga, ini tidak mustahil. Karena pada dasarnya, perspektif manusia bisa digeser oleh bukti. Seorang terdakwa bisa bebas, saat akhirnya muncul bukti bahwa dia tidak bersalah.

Untuk orang yang tidak/belum antipati, banyak bukti yang bisa dipilih: kisah nyata perusahaan sebelah, statistik kesuksesan organisasi yang Agile, dll. Buat yang sudah antipati, bisa jadi hal tersebut kurang: “itukan satu kasus saja”; “paling jualan baru orang Agilist”; “Tuh kan, Version One & Standish Group yang membuat survei adalah perusahaan swasta juga. Mau jualan Agile juga paling tuh.”

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.

Mindmap tentang isi buku Peopleware. Karya Hannah Hazi.

Dari pujian-pujian di atas saja, kita bisa lihat sekilas hubungan Peopleware dengan 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.

Ring a bell? 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 menghasilkan 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 ‘keanehan-keanehan’ di Agile Software Development.
5. Agar tidak antipati dan mau menerapkan, mereka perlu menganggap ‘keanehan-keanehan’ di Agile Software Development tidak aneh.
6. Mereka akan lebih mudah menerima, jika mendengar bukti-bukti nyata dari pihak di luar Agile Software Development.
7. Kandidat terbaiknya 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. Konsistenlah sampai pimpinan mendengar & ikut membaca.
• Kalau buku Peopleware masih terlalu berat, video rangkuman ini bisa jadi alternatif.