Program Studi Bisnis Digital • FEB

Manajemen Proyek Digital

Pertemuan 9 — Agile, Scrum, dan Hybrid dalam Proyek Digital

Mengapa proyek digital butuh cara kerja yang berbeda dari konstruksi jalan tol — dan bagaimana Agile, Scrum, serta pendekatan Hybrid menjawab kebutuhan itu di lapangan Indonesia.

RPS minggu 10 · 2x50 menit

Selamat pagi/siang, Anda semua. Dua pertemuan terakhir kita membahas bagaimana ruang lingkup proyek bisa berubah di tengah jalan — scope creep — dan bagaimana perubahan itu harus didokumentasikan lewat change request agar tidak merusak anggaran maupun jadwal. Hari ini kita masuk ke jantung cara kerja proyek digital modern: pendekatan Agile, kerangka kerja Scrum, dan pendekatan Hybrid yang menggabungkan keduanya dengan Waterfall. Bayangkan Anda menjadi project manager di tim pengembang aplikasi seperti yang dipakai Tokopedia atau Gojek, di mana kebutuhan pengguna berubah setiap minggu karena kompetitor meluncurkan fitur baru; cara kerja proyek konstruksi yang kaku jelas tidak akan bertahan di lingkungan seperti itu. Sepanjang dua jam ke depan, Anda akan memahami mengapa Waterfall gagal untuk konteks ini, bagaimana Scrum bekerja sehari-hari, dan kapan justru pendekatan Hybrid menjadi pilihan paling realistis, termasuk latihan menghitung kecepatan tim dan alokasi kapasitas secara konkret.

Bagian 1 dari 3

Dari Waterfall ke Agile: Mengapa Proyek Digital Butuh Cara Baru

Mengapa pendekatan proyek tradisional yang kaku sering gagal menghadapi kebutuhan digital yang cepat berubah, dan apa gagasan dasar di balik Agile.

Kilas Balik dan Tujuan Pembelajaran Hari Ini

Minggu Lalu (Pertemuan 8)

Scope creep: perubahan ruang lingkup yang tidak terkendali
Change request: dokumen formal untuk menyetujui perubahan
Dampaknya ke jadwal, anggaran, dan kepuasan klien

Setelah Pertemuan 9, Anda Mampu

Menjelaskan mengapa Waterfall rentan gagal di proyek digital
Menguraikan peran, event, dan artefak dalam Scrum
Menghitung velocity tim dan alokasi kapasitas Hybrid
Memilih pendekatan yang tepat untuk konteks proyek nyata

Benang merah: perubahan ruang lingkup yang kita bahas minggu lalu justru adalah alasan utama mengapa banyak tim proyek digital beralih dari Waterfall ke Agile — karena Agile dirancang untuk menerima perubahan, bukan menghindarinya.

Waterfall: Ampuh di Konstruksi, Rapuh di Proyek Digital

Ciri Waterfall

Linear, satu arah, requirement dikunci di awal — cocok untuk proyek dengan spesifikasi tetap seperti pembangunan gedung.

Risiko di Proyek Digital

Aplikasi/situs harus merespons perilaku pengguna dan kompetitor yang berubah cepat; menunggu 1 tahun untuk rilis pertama berarti kalah bersaing.

Perhatikan diagram di layar: pendekatan Waterfall bergerak satu arah, dari requirement ke desain, ke pengembangan, ke pengujian, baru rilis — tidak ada jalan mundur tanpa biaya besar. Pendekatan ini pernah sangat sukses di industri konstruksi dan manufaktur karena spesifikasinya memang tidak berubah setelah gedung mulai dibangun. Masalahnya, bayangkan tim pengembang aplikasi perbankan digital seperti Jenius atau Livin mengikuti pola ini: mereka akan menghabiskan enam bulan menyusun requirement dan desain sebelum satu baris kode pun ditulis, padahal kompetitor sudah meluncurkan fitur baru setiap bulan. Ketika akhirnya produk dirilis, kebutuhan pasar sudah bergeser dan uang yang diinvestasikan berisiko sia-sia. Inilah alasan utama mengapa industri digital mencari pendekatan yang memungkinkan rilis lebih sering dan umpan balik lebih cepat, yang akan kita bahas pada slide berikutnya.

Agile: Empat Nilai Inti dari Manifesto 2001

Agile bukan satu metode tunggal, melainkan filosofi kerja yang lahir dari Agile Manifesto (2001) — disepakati 17 praktisi software untuk menjawab kegagalan Waterfall.

Lebih Diutamakan

Individu & interaksi daripada proses & alat
Perangkat lunak yang berjalan daripada dokumentasi lengkap
Kolaborasi dengan klien daripada negosiasi kontrak
Merespons perubahan daripada mengikuti rencana kaku

Artinya untuk Tim Anda

Rilis kecil & sering, bukan satu rilis besar di akhir
Umpan balik pengguna dikumpulkan tiap 1–4 minggu (iterasi)
Perubahan kebutuhan dianggap wajar, bukan kegagalan proses
Komunikasi tatap muka/langsung diutamakan atas dokumen tebal

Penting: nilai di kolom kiri bukan berarti proses, dokumentasi, atau kontrak ditiadakan — hanya diberi bobot lebih rendah dibanding hal di sebelah kanannya.

Agile Manifesto ditulis tahun 2001 oleh tujuh belas praktisi perangkat lunak yang lelah melihat proyek Waterfall gagal berulang kali, dan mereka merumuskan empat nilai inti yang tampak di layar. Perhatikan kata kuncinya adalah "daripada", bukan "menggantikan sepenuhnya" — tim Agile tetap memakai proses, dokumentasi, dan kontrak, hanya saja mereka memprioritaskan interaksi manusia, produk yang benar-benar berjalan, kolaborasi dengan klien, dan kesiapan merespons perubahan. Contohnya, tim pengembang di startup seperti Bukalapak dulu memilih merilis fitur checkout versi sederhana lebih dulu untuk diuji pengguna, dibanding menghabiskan waktu berbulan-bulan menyempurnakan dokumen spesifikasi sebelum kode ditulis. Filosofi inilah yang kemudian diterjemahkan menjadi berbagai kerangka kerja praktis, dan yang paling populer digunakan industri adalah Scrum, yang akan kita bedah tuntas mulai bagian berikutnya.

Cara Kerja Agile: Iteratif dan Inkremental

Iteratif

Mengerjakan produk berulang-ulang dalam siklus pendek (1–4 minggu), menyempurnakan bagian yang sudah ada berdasarkan umpan balik.

Inkremental

Setiap siklus menambahkan potongan fungsi baru (increment) sehingga produk tumbuh sedikit demi sedikit, bukan sekaligus di akhir.

Lihat ilustrasi di layar: aplikasi e-commerce sederhana dibangun bukan dengan menunggu semua fitur selesai sekaligus, melainkan lewat tiga iterasi kecil — login dulu, lalu keranjang belanja, lalu pembayaran — dan setiap iterasi menghasilkan bagian produk yang benar-benar bisa dicoba pengguna. Dua istilah penting di sini: iteratif berarti tim mengulang siklus kerja secara berkala, dan inkremental berarti setiap siklus menambah nilai baru pada produk yang sudah ada, bukan mengulang dari nol. Bayangkan tim developer Traveloka mengembangkan fitur pemesanan tiket: mereka tidak menunggu fitur pembayaran, notifikasi, dan refund selesai bersamaan, tetapi merilis pemesanan dasar dulu, mengumpulkan masukan pengguna, baru menambahkan fitur lain secara bertahap. Cara kerja iteratif dan inkremental inilah fondasi dari kerangka kerja Scrum yang akan kita pelajari detail perannya, event-nya, dan artefaknya pada bagian berikutnya.

Bagian 2 dari 3

Scrum: Kerangka Kerja Agile Paling Banyak Dipakai

Peran, pertemuan rutin (event), dan dokumen kerja (artefak) yang membuat Scrum bisa dijalankan sehari-hari oleh tim proyek digital.

Kalau Agile adalah filosofi, Scrum adalah cara paling konkret dan paling populer untuk mempraktikkannya — menurut survei industri, mayoritas tim pengembang perangkat lunak di dunia, termasuk banyak perusahaan teknologi Indonesia, menggunakan Scrum sebagai kerangka kerja utama mereka. Pada bagian kedua ini, Anda akan mempelajari tiga peran yang wajib ada dalam tim Scrum, empat pertemuan rutin yang menjaga ritme kerja tim, dan tiga dokumen kerja yang menjadi sumber kebenaran bersama. Kita juga akan berhenti sejenak untuk menghitung dari nol berapa kecepatan kerja sebuah tim berdasarkan data nyata, sehingga Anda tidak hanya memahami konsepnya tapi juga bisa mengaplikasikannya sebagai calon project manager. Siapkan perhatian penuh Anda karena bagian ini menjadi inti praktis dari pertemuan hari ini.

Tiga Peran dalam Tim Scrum

Product Owner

Pemilik visi & prioritas produk
Menyusun & mengurutkan Product Backlog
Mewakili suara klien/pengguna ke tim

Scrum Master

Menjaga tim menjalankan proses Scrum
Menyingkirkan hambatan (impediment)
Bukan atasan — fasilitator & pelindung tim

Development Team

Tim lintas fungsi (desainer, programmer, penguji)
Self-organizing: mengatur cara kerja sendiri
Bertanggung jawab kolektif atas Increment

Bandingkan dengan pertemuan 5: kickoff meeting membentuk tim proyek secara umum; Scrum menegaskan peran spesifik yang berulang setiap sprint, bukan sekali di awal proyek saja.

Tiga peran ini adalah fondasi Scrum, dan penting bagi Anda untuk tidak mencampuradukkannya dengan struktur organisasi biasa. Product Owner ibarat "suara klien" di dalam tim, bertugas menentukan fitur apa yang paling bernilai untuk dikerjakan lebih dulu, misalnya pada aplikasi ojek online, Product Owner memutuskan apakah fitur split bill lebih prioritas dibanding fitur jadwal booking. Scrum Master sering disalahpahami sebagai manajer proyek biasa, padahal perannya lebih ke fasilitator yang melindungi tim dari gangguan eksternal dan memastikan proses Scrum berjalan disiplin, bukan memberi perintah teknis. Development Team sendiri bersifat self-organizing, artinya merekalah yang memutuskan bagaimana caranya menyelesaikan pekerjaan, bukan menunggu instruksi detail dari atasan, mirip seperti tim developer di Gojek yang bebas menentukan siapa mengerjakan bagian backend atau frontend selama target sprint tercapai.

Empat Pertemuan Rutin (Event) dalam Satu Sprint

Ikuti alur satu sprint dua minggu berikut, langkah demi langkah:

Tahap	Yang Terjadi	Durasi Umum
1. Sprint Planning	Tim memilih item dari Product Backlog untuk dikerjakan dalam sprint ini	~2–4 jam
2. Daily Scrum	Tim sinkronisasi singkat: apa yang dikerjakan kemarin, hari ini, dan hambatan apa	15 menit/hari
3. Sprint Review	Tim mendemokan Increment ke Product Owner & stakeholder untuk umpan balik	~1–2 jam
4. Sprint Retrospective	Tim merefleksikan proses kerja sendiri: apa yang perlu diperbaiki sprint depan	~1 jam

Siklus ini berulang setiap sprint (biasanya 2 minggu) — bukan sekali di awal proyek seperti kickoff meeting yang Anda pelajari di pertemuan 5.

Perhatikan bahwa keempat event ini bukan terjadi sekali saja, melainkan berulang setiap sprint, sehingga tim punya ritme kerja yang konsisten dan bisa diprediksi. Sprint Planning adalah titik awal, mirip rapat kickoff tapi berskala kecil dan berulang, di mana tim developer aplikasi kesehatan misalnya memutuskan akan mengerjakan fitur rekam medis digital dalam dua minggu ke depan. Daily Scrum yang hanya lima belas menit ini sering disalahartikan sebagai laporan ke atasan, padahal tujuannya adalah sinkronisasi antar anggota tim agar hambatan cepat terlihat, seperti developer yang butuh bantuan API dari tim lain. Sprint Review mengundang stakeholder eksternal untuk melihat hasil nyata, sementara Sprint Retrospective murni untuk internal tim mengevaluasi proses kerja mereka sendiri, dua hal yang sering tertukar oleh mahasiswa saat pertama belajar Scrum.

Tiga Artefak Scrum: Sumber Kebenaran Bersama

Product Backlog

Daftar SELURUH fitur/kebutuhan produk
Diurutkan Product Owner berdasar prioritas
Terus berkembang selama proyek berjalan

Sprint Backlog

Subset item yang dipilih untuk 1 sprint
Hasil kesepakatan di Sprint Planning
Dipecah jadi tugas harian oleh tim

Increment

Bagian produk yang selesai & siap pakai
Ditambahkan tiap akhir sprint
Ditunjukkan saat Sprint Review

Contoh nyata: Product Backlog aplikasi kasir UMKM berisi 50 fitur; Sprint Backlog sprint ke-3 hanya berisi 8 fitur (mis. cetak struk & laporan harian) yang disepakati bisa selesai dalam 2 minggu.

Ketiga artefak ini menjawab pertanyaan yang berbeda: Product Backlog menjawab "apa saja yang mungkin dikerjakan sepanjang proyek", Sprint Backlog menjawab "apa yang kita komit selesaikan dua minggu ini", dan Increment menjawab "apa yang benar-benar sudah jadi dan bisa dipakai". Bayangkan startup yang membangun aplikasi kasir digital untuk UMKM: Product Backlog mereka mungkin berisi lima puluh calon fitur, mulai dari pencatatan stok sampai integrasi QRIS, tetapi tidak semuanya dikerjakan sekaligus. Product Owner kemudian memilih dan mengurutkan mana yang paling mendesak, misalnya fitur cetak struk dan laporan harian penjualan, untuk dimasukkan ke Sprint Backlog sprint berjalan. Ketika sprint selesai, kedua fitur itu menjadi Increment yang sudah bisa langsung dipakai pedagang, dan Product Backlog diperbarui lagi untuk sprint berikutnya berdasarkan umpan balik yang diterima saat Sprint Review.

Hitung dari Nol: Velocity Tim & Estimasi Sisa Sprint

Tim developer aplikasi kasir UMKM "Warung Digital" punya total Product Backlog 120 story point. Berikut hasil 3 sprint pertama:

Langkah	Perhitungan	Nilai
1. Story point selesai sprint 1–3	18 SP + 22 SP + 20 SP	60 SP
2. Rata-rata velocity per sprint	60 SP ÷ 3 sprint	20 SP/sprint
3. Total Product Backlog	diketahui dari awal proyek	120 SP
4. Sisa backlog yang belum dikerjakan	120 SP − 60 SP	60 SP
5. Estimasi jumlah sprint tersisa	60 SP ÷ 20 SP/sprint	3 sprint
6. Estimasi waktu tersisa (2 minggu/sprint)	3 sprint × 2 minggu	6 minggu

Hasil Akhir

6 minggu

Estimasi realistis untuk menyelesaikan sisa backlog "Warung Digital"

Velocity adalah salah satu alat estimasi paling penting dalam Scrum, dan mari kita hitung bersama langkah demi langkah agar Anda benar-benar memahami logikanya, bukan sekadar menghafal rumus. Kita mulai dari data historis: tim menyelesaikan 18 story point di sprint pertama, 22 di sprint kedua, dan 20 di sprint ketiga, sehingga totalnya 60 story point dalam 3 sprint, dan rata-rata velocity mereka adalah 20 story point per sprint. Karena total Product Backlog aplikasi ini 120 story point dan sudah 60 story point selesai, sisa pekerjaan adalah 60 story point lagi. Dengan velocity rata-rata 20 story point per sprint, tim membutuhkan sekitar 3 sprint tambahan, dan karena setiap sprint berdurasi 2 minggu, project manager bisa memberi tahu klien dengan percaya diri bahwa aplikasi diperkirakan selesai dalam 6 minggu ke depan. Perhitungan velocity seperti ini jauh lebih kredibel dibanding menebak-nebak, dan menjadi salah satu skill wajib seorang project manager digital.

Coba Sendiri: Proyeksikan Sisa Sprint dari Velocity

Ubah story point yang selesai tiap sprint dan amati bagaimana rata-rata velocity serta estimasi sisa sprint ikut berubah.

Sprint Board: Memvisualkan Progres Harian Tim

Sprint board (fisik/digital via Trello atau Jira) membuat progres sprint terlihat semua orang setiap hari, mendukung Daily Scrum agar singkat dan fokus.

Sprint board seperti yang tampak di layar adalah alat visual paling sederhana namun paling berpengaruh dalam Scrum, karena mengubah pekerjaan yang tadinya abstrak menjadi kartu-kartu yang bisa dipindah dari kolom ke kolom. Setiap kartu mewakili satu item Sprint Backlog, misalnya "cetak struk" atau "integrasi QRIS", dan posisinya menunjukkan sejauh mana progresnya: To Do artinya belum dikerjakan, In Progress sedang dikerjakan, Review sedang diperiksa kualitasnya, dan Done berarti sudah selesai dan siap menjadi Increment. Banyak tim digital di Indonesia, dari startup kecil sampai divisi IT bank besar, menggunakan alat seperti Trello atau Jira untuk mengelola papan ini secara digital agar bisa diakses tim yang bekerja jarak jauh. Papan ini juga membuat Daily Scrum lebih efisien karena setiap anggota tim tinggal menunjuk kartu yang sedang mereka kerjakan, alih-alih menjelaskan panjang lebar, dan siapa saja bisa langsung melihat kalau ada penumpukan pekerjaan di satu kolom yang menandakan hambatan.

Bagian 3 dari 3

Hybrid: Ketika Agile Murni Tidak Cukup

Mengapa banyak proyek digital di Indonesia menggabungkan Agile dengan elemen Waterfall, dan bagaimana memilih pendekatan yang tepat untuk konteks Anda.

Setelah memahami Scrum secara mendalam, penting bagi Anda menyadari bahwa dunia nyata jarang sesederhana teori buku teks: banyak proyek digital di Indonesia, terutama yang melibatkan instansi pemerintah atau kontrak fixed-price, tidak bisa sepenuhnya menerapkan Agile murni karena ada persyaratan dokumentasi dan kepastian anggaran di awal. Pada bagian ketiga ini, kita akan membahas pendekatan Hybrid yang menggabungkan kekuatan Waterfall di tahap perencanaan dengan fleksibilitas Agile di tahap eksekusi. Anda juga akan berlatih menghitung alokasi kapasitas tim secara konkret, melihat studi kasus perusahaan Indonesia, dan yang terpenting, mempelajari kriteria memilih pendekatan mana yang paling cocok untuk proyek yang akan Anda kelola kelak. Bagian ini menutup rangkaian materi hari ini sebelum latihan kelompok di akhir sesi.

Kapan Pendekatan Hybrid Lebih Realistis daripada Agile Murni?

Ikuti kasus berikut: sebuah dinas pemerintah kota menggunakan APBD untuk membangun sistem perizinan online.

Langkah 1 — Kendala Kontrak

Kontrak pengadaan pemerintah (APBD) mensyaratkan ruang lingkup, jadwal, dan anggaran DITETAPKAN DI MUKA sebelum tanda tangan — ciri khas Waterfall, bukan Agile murni yang fleksibel.

Langkah 2 — Kebutuhan Fleksibilitas Teknis

Namun tim pengembang tetap perlu menguji tampilan formulir perizinan dengan pengguna secara bertahap agar tidak salah desain — ini butuh iterasi ala Agile.

Langkah 3 — Solusi Hybrid

Fase perencanaan & kontrak memakai Waterfall (dokumen KAK, RAB, jadwal fixed), sedangkan fase pengembangan internal memakai sprint Agile untuk membangun fitur secara iteratif.

Prinsip: pilih Hybrid saat ADA kendala eksternal (regulasi, kontrak, audit) yang menuntut kepastian di muka, TAPI pekerjaan teknisnya sendiri tetap butuh iterasi.

Mari kita telusuri kasus ini langkah demi langkah agar Anda memahami logika di balik pilihan Hybrid, bukan sekadar menghafal definisinya. Pertama, proyek pengadaan pemerintah yang dibiayai APBD, seperti sistem perizinan online di Dinas Penanaman Modal, secara hukum mewajibkan ruang lingkup, anggaran, dan jadwal disepakati di kontrak sebelum pekerjaan dimulai, sehingga sifatnya sudah condong ke Waterfall sejak awal. Kedua, meski kontraknya kaku, tim teknis di dalamnya tetap menghadapi risiko yang sama seperti proyek digital lain: desain formulir yang salah sejak awal bisa berakibat fatal, sehingga mereka tetap perlu menguji purwarupa dengan calon pengguna secara bertahap. Solusinya adalah Hybrid: fase kontrak dan perencanaan tetap mengikuti disiplin Waterfall demi kepatuhan administrasi, sementara di dalam fase pengembangan, tim membagi pekerjaan menjadi sprint-sprint Agile untuk menjaga kualitas dan fleksibilitas teknis, sebuah pola yang sangat umum ditemukan pada proyek pemerintah maupun perusahaan dengan kontrak fixed-price di Indonesia.

Dua Model Hybrid yang Umum Digunakan

Dua model Hybrid ini paling sering ditemukan dalam praktik industri digital, dan penting Anda bisa membedakannya. Water-Scrum-Fall, seperti tampak di diagram, menempatkan Waterfall di dua ujung proyek yaitu tahap requirement dan tahap deployment yang memang butuh dokumentasi formal dan persetujuan resmi, sementara bagian tengahnya yaitu proses pengembangan dijalankan dengan sprint Agile agar tim tetap fleksibel merespons perubahan detail teknis. Model ini sangat cocok untuk proyek enterprise besar seperti sistem inti perbankan di bank BUMN, yang butuh kepastian regulasi dan audit di awal serta prosedur rilis yang ketat di akhir. Model kedua, Scrumban, adalah gabungan disiplin Scrum dengan visualisasi papan Kanban tanpa sprint yang kaku waktunya, cocok untuk tim yang menangani pekerjaan pemeliharaan atau dukungan pelanggan yang datang tidak terjadwal, misalnya tim IT support yang menangani keluhan pengguna aplikasi perbankan setiap hari. Memahami kedua model ini membantu Anda memilih kombinasi yang paling sesuai dengan sifat pekerjaan, bukan sekadar mengikuti tren.

Hitung dari Nol: Alokasi Kapasitas Tim Hybrid

Proyek sistem perizinan Dinas Kota (kontrak fixed-price, 12 minggu) beranggotakan 10 orang, masing-masing bekerja 40 jam/minggu.

Langkah	Perhitungan	Nilai
1. Total kapasitas tim per minggu	10 orang × 40 jam	400 jam/minggu
2. Alokasi fase Waterfall (dok. & compliance) 25%	25% × 400 jam	100 jam/minggu
3. Alokasi fase Agile (sprint pengembangan) 75%	75% × 400 jam	300 jam/minggu
4. Jumlah sprint (2 minggu) dalam 12 minggu	12 minggu ÷ 2 minggu	6 sprint
5. Total jam Agile selama proyek	300 jam/minggu × 12 minggu	3.600 jam
6. Kapasitas Agile per sprint	3.600 jam ÷ 6 sprint	600 jam/sprint

Hasil Akhir

600 jam/sprint

Kapasitas pengembangan Agile yang bisa direncanakan Product Owner tiap sprint

Sekarang mari kita berlatih menghitung alokasi kapasitas pada proyek Hybrid, keterampilan yang sangat berguna saat Anda menjadi project manager yang harus menjelaskan rencana kerja ke klien pemerintah. Tim beranggotakan 10 orang dengan masing-masing bekerja 40 jam per minggu, sehingga total kapasitas tim adalah 400 jam per minggu. Karena proyek ini terikat kontrak fixed-price yang mensyaratkan dokumentasi dan kepatuhan administrasi, kita alokasikan 25 persen kapasitas untuk fase Waterfall yaitu 100 jam per minggu, sedangkan sisanya 75 persen atau 300 jam per minggu dialokasikan untuk fase pengembangan Agile. Proyek berdurasi 12 minggu dengan sprint 2 mingguan berarti ada 6 sprint total, sehingga total jam Agile sepanjang proyek adalah 300 jam dikalikan 12 minggu sama dengan 3.600 jam, dan bila dibagi rata ke 6 sprint, setiap sprint punya kapasitas pengembangan 600 jam kerja tim yang bisa direncanakan Product Owner bersama Scrum Master.

Studi Kasus: Pendekatan Berbeda di Konteks Indonesia

Organisasi	Pendekatan	Alasan Utama
Startup fintech/e-commerce (mis. tim internal Tokopedia)	Scrum/Agile murni	Kompetisi cepat, kebutuhan pengguna berubah tiap minggu, tidak ada kendala kontrak eksternal
Bank BUMN (sistem inti/core banking)	Water-Scrum-Fall	Wajib patuh regulasi OJK & audit ketat di awal/akhir, tapi pengembangan fitur digital tetap iteratif
Proyek Dinas Pemda (APBD, kontrak fixed-price)	Hybrid (Waterfall + Agile internal)	Kontrak pengadaan mengunci ruang lingkup & anggaran di muka, teknis tetap perlu iterasi
Tim IT support/maintenance aplikasi UMKM	Scrumban	Permintaan datang tidak terjadwal, butuh visual Kanban tanpa sprint kaku

Tidak ada pendekatan yang "paling benar" secara universal — yang ada adalah pendekatan yang paling sesuai konteks organisasi, regulasi, dan sifat pekerjaan.

Tabel ini merangkum bagaimana pendekatan yang sama sekali berbeda bisa sama-sama tepat, tergantung konteks organisasinya, dan ini penting agar Anda tidak terjebak berpikir bahwa Agile selalu lebih baik daripada Waterfall atau sebaliknya. Startup teknologi seperti tim pengembang internal Tokopedia cenderung memakai Scrum murni karena mereka tidak terikat kontrak eksternal yang kaku dan harus merespons perubahan pasar secepat mungkin. Bank BUMN yang mengelola sistem inti perbankan wajib mematuhi regulasi OJK dan menjalani audit ketat, sehingga mereka memilih Water-Scrum-Fall agar kepatuhan tetap terjaga tanpa kehilangan fleksibilitas teknis di tengah proses. Proyek dinas pemerintah daerah yang dibiayai APBD terikat aturan pengadaan barang/jasa yang mengunci ruang lingkup dan anggaran sejak kontrak ditandatangani, sehingga Hybrid menjadi pilihan realistis, sementara tim dukungan teknis aplikasi UMKM yang menerima keluhan kapan saja lebih cocok memakai Scrumban karena sifat pekerjaannya yang tidak terjadwal rapi.

Kriteria Memilih Pendekatan yang Tepat

Cenderung Agile/Scrum Murni

Requirement belum pasti & sering berubah
Klien/pengguna bisa terlibat memberi umpan balik rutin
Tidak ada kontrak fixed-price yang mengunci ruang lingkup
Tim kecil, lintas fungsi, dan self-organizing

Cenderung Hybrid/Waterfall Sebagian

Ada regulasi/audit/kontrak pengadaan yang kaku
Anggaran & jadwal harus disetujui di muka (mis. APBD/APBN)
Stakeholder eksternal sulit terlibat rutin tiap 2 minggu
Ada bagian pekerjaan berisiko tinggi yang butuh dokumentasi lengkap

Pertanyaan kunci sebagai project manager: "Seberapa pasti requirement saya, dan seberapa kaku kontrak/regulasi yang mengikat proyek ini?" — jawabannya menentukan pendekatan.

Setelah melihat berbagai studi kasus, sekarang kita rangkum menjadi kriteria praktis yang bisa langsung Anda gunakan sebagai calon project manager. Pertanyaan pertama yang harus Anda ajukan adalah seberapa pasti kebutuhan proyek ini: kalau requirement masih sangat mungkin berubah, seperti aplikasi konsumen yang bersaing di pasar dinamis, Agile murni jauh lebih masuk akal. Pertanyaan kedua adalah seberapa kaku ikatan kontrak atau regulasi eksternal proyek tersebut; proyek dengan dana APBD/APBN atau proyek yang diaudit ketat oleh regulator seperti OJK cenderung membutuhkan elemen Waterfall di bagian perencanaan dan pelaporan. Pertanyaan ketiga menyangkut keterlibatan stakeholder: Scrum idealnya butuh Product Owner dan pengguna yang bisa memberi umpan balik setiap dua minggu, dan kalau itu tidak memungkinkan karena birokrasi, pendekatan murni Agile akan sulit dijalankan secara konsisten. Dengan tiga pertanyaan ini, Anda punya kerangka berpikir yang jelas untuk memilih pendekatan, bukan sekadar mengikuti tren industri tanpa mempertimbangkan konteks proyek Anda sendiri.

Latihan Kelompok: Tentukan Pendekatan untuk Kasus Anda

Instruksi (20 menit, kelompok 4–5 orang):

Pilih salah satu kasus: (a) aplikasi belajar online untuk startup edutech baru, (b) sistem e-tilang untuk Kepolisian Daerah dengan dana APBN, atau (c) fitur baru marketplace UMKM yang sudah berjalan.
Tentukan pendekatan yang paling tepat: Scrum murni, Water-Scrum-Fall, Hybrid penuh, atau Scrumban.
Jelaskan alasan Anda memakai 3 kriteria dari slide sebelumnya (kepastian requirement, kekakuan kontrak/regulasi, keterlibatan stakeholder).
Siapkan 1 slide/kertas ringkasan untuk dipresentasikan singkat (2 menit per kelompok).

Dosen akan berkeliling membantu — jangan ragu bertanya bila kasusnya ambigu (memang disengaja, karena dunia nyata pun sering ambigu).

Sekarang saatnya Anda mempraktikkan langsung apa yang sudah dipelajari melalui latihan kelompok kecil ini. Silakan bentuk kelompok empat sampai lima orang, lalu pilih salah satu dari tiga kasus yang tersedia di layar, mulai dari startup edutech yang baru berdiri, sistem e-tilang kepolisian yang dibiayai APBN, sampai fitur baru pada marketplace UMKM yang sudah berjalan lama. Tugas kelompok Anda adalah menentukan pendekatan mana yang paling masuk akal digunakan, lalu menjelaskan alasannya menggunakan tiga kriteria yang baru saja kita bahas: kepastian requirement, kekakuan kontrak atau regulasi, dan kemudahan keterlibatan stakeholder. Saya sengaja membuat beberapa kasus ini terasa ambigu, karena di dunia nyata pun keputusan semacam ini jarang hitam-putih, dan justru diskusi tentang trade-off itulah yang paling berharga; saya akan berkeliling selama dua puluh menit ke depan untuk mendengarkan pemikiran tiap kelompok dan memberi masukan.

Ringkasan dan Jembatan ke Pertemuan Berikutnya

Yang Sudah Kita Pelajari

Waterfall rentan gagal pada proyek digital yang requirement-nya berubah cepat
Agile: filosofi merangkul perubahan lewat iterasi & increment
Scrum: peran (PO, Scrum Master, Dev Team), event, dan artefak konkret
Hybrid (Water-Scrum-Fall, Scrumban) untuk konteks berkontrak/beregulasi kaku
Cara menghitung velocity tim & alokasi kapasitas Hybrid

Pertemuan 11: Tim Lintas Fungsi & Manajemen Konflik

Bagaimana peran Scrum Master menangani konflik antar-anggota tim
Koordinasi desainer, developer, dan tim konten dalam satu sprint
Studi kasus konflik prioritas antara Product Owner & tim teknis

Tugas mandiri: refleksikan hasil latihan kelompok Anda hari ini — simpan sebagai bahan diskusi lanjutan minggu depan.

Mari kita tutup pertemuan hari ini dengan merangkum benang merahnya. Kita mulai dari mengapa Waterfall kesulitan menghadapi proyek digital yang kebutuhannya cepat berubah, lalu memahami Agile sebagai filosofi yang merangkul perubahan tersebut melalui kerja iteratif dan inkremental. Kita lanjutkan dengan Scrum secara mendalam, mulai dari tiga peran, empat event rutin, tiga artefak, sampai dua latihan hitungan konkret yaitu velocity tim dan alokasi kapasitas Hybrid, dan terakhir kita bahas kapan Hybrid lebih realistis dibanding Agile murni lewat studi kasus Indonesia yang beragam. Minggu depan pada pertemuan 11, kita akan masuk ke tantangan mengelola tim lintas fungsi yang terdiri dari desainer, developer, dan tim konten sekaligus, termasuk bagaimana peran Scrum Master menangani konflik yang muncul di antara mereka. Simpan hasil diskusi kelompok Anda hari ini karena kita akan mengaitkannya dengan materi manajemen konflik minggu depan; sampai jumpa dan selamat berlatih.