Agile vs Waterfall: Miskonsepsi & Kapan Menggunakan Agile


Agile menurut saya menjadi sebuah kata yang banyak gaungnya akhir-akhir ini. Tidak hanya startup teknologi, bahkan pemerintah sekarang pun mulai sering menggunakan kata Agile.

Kembali kepada sejarah awal kata ini, Agile sebenarnya adalah metode baru manajemen proyek. Software developer pada tahun 2001, merasa kesulitan mengembangkan software dengan kompleksitas permintaan dari user. Mereka membangun cara baru untuk mengelola sebuah proyek — utamanya proyek software — agar lebih efisien dan terarah.

Perbedaan Agile vs Waterfall

Metode manajemen proyek “Waterfall” adalah pendekatan manajemen proyek yang sederhananya, memiliki prinsip-prinsip dasar:

  1. Memerlukan urutan pekerjaan yang jelas, dan memiliki fase-fase yang harus selesai per masing-masing urutan.
  2. Mengestimasi kebutuhan dan pekerjaan (sumber daya, waktu, dan biaya) untuk mencapai hasil seoptimal mungkin.
  3. Pengerjaan tiap fase pekerjaan harus berurutan — mungkin sulit dan mahal jika pekerjaan tahap sebelumnya harus dikerjakan kembali/salah.

Mari ambil contoh sederhana. Andaikata kita punya proyek “membersihkan toilet”. Jika kita menggunakan metode Waterfall, harus jelas fase-fase pekerjaannya: misalkan fase pertama adalah menguras bak mandi, kedua adalah menyikat lantai, ketiga adalah membersihkan wastafel. 

Semua itu pun harus berurutan pengerjaannya. Jika ternyata kita misalkan ceroboh melakukan pertama kali adalah meyikat lantai (dimana harusnya ini fase pekerjaan kedua), energi yang lo lakukan jadi lebih besar karena harus menyikat lantai dua kali — akibat harus membersihkan sisa-sisa kurasan bak mandi yg menempel di lantai (misalnya).

Mohon maaf saya ngga kepikiran analogi lain untuk menjelaskan hehe 🙏

Berbeda demikian halnya dengan Agile, prinsip dasarnya adalah:

  1. Memastikan untuk menyelesaikan pekerjaan yang bisa lakukan dalam kurun waktu tertentu.
  2. Iterasi terus hingga semua pekerjaan selesai, selagi pekerjaan atau kompleksitas baru muncul.

Kembali ke contoh membersihkan toilet, namun dengan tambahan kompleksitas waktu dan kondisi: misalkan ada tamu yang berkunjung — dan kita hanya bisa membersihkan toilet tiap lebih dari 1 menit — untuk mengantisipasi si tamu ingin menggunakan toilet.

Dalam kondisi ini dengan metode Agile, yang kita lakukan adalah: mengestimasi pekerjaan apa saja yang dapat selesai hanya 1 menit. Jika menit pertama kita harus menyikat lantai, maka selesaikan sikat lantai terlebih dahulu. Lakukan terus hingga beberapa kali, sampai toilet menjadi bersih — tidak peduli pekerjaan apa yang terduplikasi (dilakukan berulang), tidak peduli waktu total toilet menjadi bersih berapa lama.

Stacey Complexity Model

Dari kedua contoh tersebut, terlihat bahwa metode Agile lebih “ceroboh dan sporadis” ketimbang Waterfall. Sehingga muncul pertanyaan, kenapa metode ini bisa gue bilang lebih baik ketimbang Waterfall pada software development?

Dalam sebuah proyek, kita perlu sadar ada dua hal yang patut diperhitungkan: tingkat ketidakpastian kebutuhan, serta tingkat kesulitan teknis. Kedua hal ini digambarkan pada grafik Stacey Complexity Model ini.

Stacey Complexity Matrix (from Stacey, 2012) | Download Scientific Diagram

Sumbu Y [Requirements (“What”)] merepresentasikan tingkat ketidakpastian kebutuhan. Dari bawah keatas, semakin naik, maka proyek semakin tidak jelas kebutuhannya apa. Sumbu X [Technology (“How”)] merepresentasikan tingkat kesulitan teknis. Dari kiri ke kanan, semakin ke kanan, maka proyek semakin sulit untuk dikerjakan — diukur dari seberapa jelas detil tugas atau pekerjaan yang harus selesai duluan.

Intinya, semakin mudah pekerjaan dan jelas kebutuhan proyek — metode Waterfall (Predictive planning) akan lebih baik. Ambil contoh pekerjaan proyek gedung. Kebutuhannya sudah jelas: membuat bangunan untuk perkantoran/fungsi lain di lokasi X, kesulitan teknis pembangunan di lokasi X tersebut juga relatif terukur. Sehingga, proyek-proyek sipil dan bangunan sangat mungkin untuk lebih efisien dengan metode Waterfall ketimbang Agile.

Metode Agile akan lebih baik kita gunakan jika pekerjaannya sulit dan kebutuhannya samar (Adaptive planning). Nah, ambil contoh untuk software development aplikasi (bayangkan seperti Gojek). Bayangkan aplikasi dengan ribuan fitur, kebutuhan user-nya yang beraneka ragam, dan memperhitungkan resiko hacking dan lain sebagainya — sulit sekali  menggunakan konsep Waterfall — Agile terhitung lebih efisien walaupun dengan berbagai iterasi.

Miskonsepsi Mengenai Agile

1. Agile Adalah Metode Baru yang Lebih Baik Ketimbang Waterfall

Kalau asumsinya metode baru, iya benar. Kalau labelnya lebih baik, tergantung kondisi — as we discussed in earlier section. Metode baru Agile ini baru berkembang tahun 2001 untuk menyelesaikan masalah proyek dengan ketidakpastian kebutuhan dan kesulitan teknis yang tinggi.

2. Dalam Sebuah Proyek, Kita Harus Pilih Mau Gunakan Metode Agile atau Waterfall

Pada tatanan praktek, ada kalanya sebagian cakupan proyek memerlukan metode Waterfall, dan ada kalanya harus dengan Agile. Namun yang jelas, secara umum, akan ada metode utama yang dijadikan acuan umum untuk menyelesaikan proyek.

3. Agile Membuat Sebuah Proyek Lebih Minim Biaya dan Sumber Daya

Seperti penjelasan sebelumnya, karena basisnya adalah pekerjaan yang menggunakan Agile pasti sulit dan kompleks, sumber daya dan biaya yang diperlukan pasti besar. Saya belum menemukan penelitian atau referensi yang mengatakan metode Agile dapat memangkas biaya dan sumberdaya (and please let me know kalau ada ya).


Berikut penjelasan mengenai perbedaan Agile vs Waterfall. Hemat saya, kedua metode ini penggunaannya harus seperlunya dalam manajemen proyek — dan bukan untuk meniadakan satu sama lain.

Referensi

  1. Project Management Institute (2018). Agile Practice Guide. Jakarta: Republika Penerbit
  2. https://www.atlassian.com/agile