Waterfall vs Agile vs Scrum: Perbedaan dan Contoh Implementasi

1. Memahami Posisi Waterfall, Agile, dan Scrum

Pertanyaan “mana yang lebih baik?” sering muncul karena ketiganya ditempatkan dalam satu tabel seolah-olah merupakan tiga metode sejenis. Dari sudut Software Engineering, perbandingan yang lebih tepat dimulai dari tingkat abstraksi. Waterfall menggambarkan alur pengembangan yang cenderung berurutan antar-fase. Agile memberi nilai dan prinsip yang menuntun cara tim bekerja dan beradaptasi. Scrum adalah framework ringan yang mendefinisikan akuntabilitas, event, artefak, dan komitmen untuk membantu tim mengelola pekerjaan kompleks.

Artinya, organisasi bisa membandingkan predictive development dengan adaptive development, kemudian memilih Scrum sebagai salah satu cara melaksanakan pendekatan adaptif. Agile bukan sinonim Scrum, dan menggunakan board tugas saja tidak cukup untuk menyebut sebuah tim menerapkan Scrum.

2. Waterfall: Pengembangan Bertahap dan Terkendali

Waterfall mengorganisasi pengembangan perangkat lunak ke dalam rangkaian fase yang biasanya mencakup analisis kebutuhan, desain, implementasi, integrasi dan pengujian, deployment, serta pemeliharaan. Keunggulan utamanya adalah keterlacakan dokumen dan kejelasan titik persetujuan (stage gate). Pendekatan seperti ini masuk akal ketika kebutuhan telah relatif stabil, ada regulasi ketat, dan perubahan harus ditangani secara formal.

Namun Waterfall tidak berarti mustahil melakukan umpan balik atau perubahan. Bahkan pembahasan sejarah tulisan Winston W. Royce (1970) menunjukkan kritik terhadap pola sekali jalan yang terlalu sederhana. Karena itu, dalam praktik modern kita perlu membedakan Waterfall sebagai representasi fase dari proyek yang benar-benar menerapkan siklus tinjauan ulang.

Artefak Waterfall yang lazim

Pada awal pengembangan, tim menyepakati dokumen kebutuhan atau SRS. Kebutuhan itu diturunkan menjadi arsitektur, rancangan data, antarmuka, dan rencana pengujian. Setiap kebutuhan harus dapat ditelusuri sampai fitur yang dibangun dan pengujian yang membuktikannya. Contohnya, kebutuhan REQ-03 “penghuni dapat melaporkan kerusakan” ditelusuri ke rancangan formulir laporan, endpoint backend, serta test case TC-03.

3. Agile: Nilai, Prinsip, dan Kemampuan Beradaptasi

Agile berakar pada Manifesto for Agile Software Development (2001), yang menempatkan interaksi manusia, perangkat lunak yang bekerja, kolaborasi dengan pelanggan, dan respons terhadap perubahan sebagai nilai yang diprioritaskan. Ini bukan berarti rencana, kontrak, dokumentasi, atau tools harus dihapus. Maknanya adalah tim tidak boleh mengorbankan nilai produk demi proses administratif yang tidak membantu.

Prinsip Agile menekankan penyampaian perangkat lunak bernilai secara rutin, kualitas teknis, pengembangan yang berkelanjutan, dan refleksi berkala. Proses implementasinya dapat berbeda-beda: ada tim yang memakai Scrum, Kanban, XP, atau kombinasi praktik yang dirancang sesuai kebutuhan. Siklus plan–build–test–review–adapt pada ilustrasi adalah penyederhanaan untuk belajar, bukan prosedur tunggal yang diwajibkan Agile Manifesto.

4. Scrum: Framework dengan Akuntabilitas, Event, dan Artefak

Menurut Scrum Guide 2020, Scrum menggunakan pendekatan empiris yang bertumpu pada transparansi, inspeksi, dan adaptasi. Scrum Team memuat tiga akuntabilitas: Product Owner, Scrum Master, dan Developers. Tim bekerja menuju Product Goal melalui Sprint berdurasi tetap satu bulan atau kurang. Untuk tutorial ini, kita memakai Sprint dua minggu sebagai keputusan contoh, bukan aturan wajib.

Scrum memiliki lima event: Sprint, Sprint Planning, Daily Scrum, Sprint Review, dan Sprint Retrospective. Daily Scrum berdurasi 15 menit, tetapi tidak harus menjadi laporan satu arah kepada manajer. Tujuannya adalah memeriksa kemajuan menuju Sprint Goal dan menyesuaikan rencana untuk hari berikutnya. Scrum juga mempunyai tiga artefak: Product Backlog, Sprint Backlog, dan Increment, masing-masing terkait Product Goal, Sprint Goal, dan Definition of Done.

5. Perbandingan Mendalam dari Sudut Software Engineering

Pemilihan pendekatan sebaiknya mempertimbangkan ketidakpastian kebutuhan, besarnya risiko perubahan, kemampuan pengguna memberi umpan balik, kebutuhan audit, kapasitas tim, dan arsitektur sistem. Tabel berikut berfungsi sebagai panduan keputusan kontekstual, bukan aturan bahwa Waterfall selalu lambat atau Scrum selalu paling unggul. Kedua pola dapat gagal apabila requirements, desain, testing, atau komunikasi dikelola buruk.

6. Studi Kasus Terpadu: Aplikasi KosKu

Bayangkan sebuah tim Software Engineering ditugaskan membuat KosKu, aplikasi untuk memantau tagihan sewa, mengirim laporan kerusakan, dan melihat status penanganan. Kebutuhan awalnya mencakup autentikasi, dashboard, tagihan, pelaporan, dan notifikasi. Setelah wawancara, calon pengguna meminta status laporan yang lebih transparan. Pertanyaannya: bagaimana tiga pendekatan tersebut mengorganisasikan pekerjaan yang sama?

Untuk menjaga perbandingan, kita menggunakan ruang lingkup dan kapasitas awal yang identik: 8 minggu pengembangan, empat orang tim inti, serta target MVP yang sama. Seluruh tanggal dan skor di bawah merupakan ilustrasi agar perhitungan mudah diikuti. Dalam proyek nyata, setiap angka harus berasal dari estimasi dan pengukuran aktual.

7. Implementasi KosKu dengan Waterfall

Dalam ilustrasi Waterfall, tim memulai dengan memformalkan seluruh kebutuhan, menurunkannya menjadi desain, lalu membangun dan mengintegrasikan fitur. Jadwal berikut bukan pembagian fase wajib bagi semua proyek Waterfall, melainkan contoh baseline yang dapat diubah menurut kompleksitas sistem. Pekerjaan pengujian keamanan dan review kebutuhan dapat dimulai lebih awal, walaupun tabel menunjukkan fase dominan.

8. Implementasi KosKu dengan Prinsip Agile

Agile tidak mewajibkan satu pola event, sehingga ilustrasi ini memakai empat iterasi dua minggu. Tim memulai dari hipotesis nilai produk, membangun increment kecil, lalu meninjau hasil berdasarkan masukan pengguna. Target utamanya bukan hanya menyelesaikan aktivitas, melainkan belajar apakah fitur benar-benar memecahkan masalah penghuni kos.

Pada akhir iterasi kedua, misalnya tiga dari lima partisipan uji masih bingung mencari riwayat laporan. Tim lalu menggeser prioritas: status laporan ditempatkan pada iterasi ketiga, sedangkan forum komunitas ditunda. Keputusan ini mencerminkan adaptation based on evidence. Perhatikan bahwa “tiga dari lima” dalam contoh tersebut hanyalah data simulasi, bukan hasil riset lapangan.

9. Implementasi KosKu dengan Framework Scrum

Jika tim memilih Scrum, empat periode dua minggu di atas menjadi empat Sprint dengan Sprint Goal yang jelas. Product Owner mengurutkan Product Backlog berdasarkan nilai, Developers memilih pekerjaan yang dapat mendukung Sprint Goal, dan Scrum Master membantu tim menerapkan framework. Setiap Sprint harus menghasilkan Increment yang memenuhi Definition of Done, bukan hanya slide kemajuan.

9.1 Product Backlog KosKu

Story point di sini adalah teknik estimasi relatif yang dapat membantu perencanaan, bukan elemen wajib dari Scrum Guide. Angka 5, 8, dan seterusnya tidak bermakna jumlah hari yang pasti. Tim perlu membangun pemahaman bersama mengenai kompleksitas dan ketidakpastian pekerjaan.

9.2 Contoh Sprint 1: Planning sampai Review

10. Perhitungan dan Evaluasi: Bagaimana Membaca Kemajuan?

Metrik tidak boleh digunakan secara sembarangan untuk mengklaim bahwa satu model pasti lebih unggul. Pengukuran Waterfall sering menekankan kepatuhan jadwal dan cakupan pengujian, sedangkan pengembangan adaptif dapat menambahkan lead time, kualitas Increment, dan outcome penggunaan. Scrum tidak mewajibkan velocity, burn-down chart, atau story points; metrik tersebut boleh dipakai sebagai alat bantu forecast jika dipahami keterbatasannya.

10.1 Contoh penyelesaian backlog

Misalnya empat Sprint KosKu masing-masing menyelesaikan 13, 8, 10, dan 8 story point sesuai kesepakatan tim. Velocity rata-rata simulasi:

Velocity rata-rata = (13 + 8 + 10 + 8) / 4
                    = 39 / 4
                    = 9,75 story point per Sprint

Nilai ini hanya membantu tim yang sama memperkirakan kapasitas relatif di pekerjaan mendatang. Velocity tidak menggantikan Sprint Goal dan tidak boleh dijadikan peringkat produktivitas antarindividu atau antartim.

10.2 Contoh task success rate

Dalam pengujian ilustratif, lima partisipan diberi satu tugas: “Laporkan keran kamar mandi rusak dan temukan status laporan Anda.” Bila empat berhasil tanpa bantuan dan satu gagal:

Task success rate = (4 / 5) × 100%
                  = 80%

Angka 80% menunjukkan keberhasilan pada lima sesi uji contoh tersebut, bukan estimasi yang dapat langsung digeneralisasi ke seluruh populasi pengguna. Catatan observasi perlu digunakan untuk mengetahui penyebab kegagalan.

10.3 Contoh perubahan jadwal Waterfall

Asumsikan baseline selesai minggu ke-8 dan CR-01 memerlukan tambahan 16 jam pekerjaan. Dengan kapasitas efektif satu developer 20 jam/minggu khusus fitur tersebut, estimasi tambahan durasi teoritis:

Tambahan durasi = 16 jam / (20 jam/minggu)
                = 0,8 minggu

Angka 0,8 minggu bukan otomatis penambahan durasi kalender proyek. Dampak sebenarnya tergantung apakah pekerjaan berada di jalur kritis, dapat dijalankan paralel, dan memerlukan siklus review tambahan. Perbedaan inilah yang harus dijelaskan saat mengelola change request.

11. Bagaimana Memilih Pendekatan yang Tepat?

Tidak ada metode yang unggul untuk semua konteks. Sebuah proyek integrasi sistem regulasi dengan spesifikasi kontraktual dan audit ketat mungkin memerlukan baseline formal dan stage gate yang kuat. Sebaliknya, aplikasi konsumen yang perilaku penggunanya belum dipahami akan diuntungkan oleh rilis bertahap dan validasi sering. Scrum berguna ketika tim dapat bekerja lintas fungsi, mempunyai Product Owner yang benar-benar berwenang, dan mampu menghasilkan Increment bernilai di tiap Sprint.

Contoh hybrid: tim menjaga jadwal persetujuan infrastruktur dan keamanan yang formal, sementara tim aplikasi mengembangkan UX melalui Sprint. Hybrid harus dibentuk berdasarkan pembagian risiko dan koordinasi nyata, bukan sekadar memberi nama “Agile” pada rapat mingguan di dalam proyek Waterfall.

12. Miskonsepsi dan Praktik Baik

13. FAQ: Pertanyaan yang Sering Diajukan

14. Referensi Resmi dan Materi Pendamping

Pembahasan dalam artikel ini mengutamakan sumber primer. Ilustrasi proses merupakan penyederhanaan pedagogis; untuk definisi Scrum yang mengikat, gunakan Scrum Guide resmi. Beberapa pernyataan kontekstual tentang pemilihan model adalah penalaran Software Engineering dan tidak merupakan klaim keunggulan empiris.

1. Beck, K., dkk. (2001). Manifesto for Agile Software Development.
2. Agile Manifesto Authors. Prinsip-prinsip di balik Manifesto Agile (Bahasa Indonesia).
3. Schwaber, K. & Sutherland, J. (2020). The Scrum Guide.
4. Fowler, M. (2019). Waterfall Process.
5. Royce, W. W. (1970). Managing the Development of Large Software Systems. WESCON.

Kesimpulan: Waterfall membantu mengelola alur berfase dengan baseline dan keterlacakan, Agile memberi prinsip agar tim mengirim nilai serta beradaptasi, sedangkan Scrum menyediakan struktur empiris untuk menghasilkan Increment melalui Sprint. Keputusan terbaik tidak dimulai dari popularitas istilah, melainkan dari karakteristik kebutuhan, risiko, kapasitas tim, dan bukti hasil pengguna.

Kembali ke awal artikel ↑