Agile vs Scrum vs Kanban: beda filosofi, bukan cuma ritual
Isi
Banyak tim bilang "kami Agile" padahal yang mereka lakukan cuma Scrum tanpa filosofi — daily standup jadi laporan status ke bos, sprint review jadi demo kosong, retro jadi sesi curhat yang gak ngubah apa-apa.
Beda mendasar:
Agile = payung nilai, bukan framework. Empat poin Manifesto Agile (2001): individu & interaksi > proses & tool; software jalan > dokumentasi lengkap; kolaborasi klien > negosiasi kontrak; respons perubahan > ikut rencana. Perhatikan: yang kanan tetap bernilai — cuma yang kiri lebih diprioritaskan. Agile gak nyuruh apa pun secara operasional.
Scrum = framework dengan iterasi tetap (sprint 1-2 minggu) dan peran eksplisit (PO, SM, Dev). Asumsinya: masalah cukup kompleks sampai butuh siklus pendek untuk belajar. Scrum memaksa komitmen waktu-box.
Kanban = metode aliran kontinu tanpa time-box. Inti cuma tiga: visualisasikan kerja, batasi WIP, ukur lead time. Gak ada sprint, gak ada peran wajib. Asumsinya: kerja datang terus-menerus (support, ops, maintenance) dan bottleneck-nya ada di kapasitas, bukan di perencanaan.
| Aspek | Scrum | Kanban |
|---|---|---|
| Ritme | Sprint time-box | Aliran kontinu |
| Perubahan scope | Dikunci dalam sprint | Boleh kapan saja |
| Metrik utama | Velocity, burndown | Lead time, throughput, WIP |
| Peran | PO, SM, Dev wajib | Tidak ada peran wajib |
| Cocok untuk | Produk dengan prioritas berubah cepat | Support, ops, kerja campur-aduk |
| Risiko utama | Ritual tanpa substansi | WIP meledak, gak ada batas |
Realita lapangan — anti-pattern yang paling sering
- Scrum-but — "kami Scrum, tapi gak ada retro / PO gak ada / sprint gak pernah selesai". Namanya Scrum, isinya chaos.
- Daily standup jadi status report — tiap orang lapor ke SM/manajer, bukan koordinasi antar-dev. Tanda: orang ngomong ke atas, bukan ke samping.
- Sprint sebagai deadline mini — manajemen pakai sprint buat menekan, bukan buat belajar. Efek: tim inflate estimasi, sprint jadi teater.
- Velocity dipakai sebagai KPI produktivitas — ini fatal. Velocity itu alat perencanaan internal, bukan alat penilaian. Begitu jadi KPI, angka naik, kerja gak.
- Retro tanpa action item — retro yang gak menghasilkan 1-2 perubahan konkret dengan owner + deadline = buang waktu 1 jam. Aturan simpel: maksimal 2 action, masing-masing ada nama.
- Kanban tanpa WIP limit — papan visual tanpa batas WIP cuma papan cantik. Kolom "In Progress" isi 14 kartu = gak ada aliran, cuma antrean.
- Sprint 0 / hardening sprint / "sprint" untuk bug — tanda tim sebenarnya gak sanggup deliver increment tiap iterasi.
- Estimasi story point diperlakukan sebagai jam — "1 poin = 4 jam" itu bukan estimasi relatif lagi, itu jam kerja dengan nama lain.
Yang biasanya lebih penting dari pilihan framework
- Definisi "done" yang eksplisit. Tanpa ini, "selesai" artinya beda-beda per orang.
- Ukuran batch kecil. Item besar = feedback lambat. Pecah kerja jadi potongan yang bisa selesai dalam hitungan hari, bukan minggu.
- Satu sumber prioritas. Kalau ada 3 orang yang bisa bilang "ini urgent", gak ada prioritas.
- Retro yang mengubah satu hal. Tim yang ubah 1 hal per 2 minggu, setahun = 26 perbaikan. Tim yang ubah 10 hal sekaligus = 0.
Kanban sering jadi titik masuk lebih jujur: kamu gak bisa bohong soal WIP dan lead time. Scrum lebih jujur soal prioritas dan scope, tapi lebih gampang dipalsukan lewat ritual.
Satu hal yang bisa langsung dipakai
Hari ini, hitung jumlah kartu di kolom "in progress" tim kamu. Kalau lebih dari jumlah orang, pasang WIP limit = jumlah orang, dan larang ambil kerja baru sebelum ada yang keluar dari kolom itu. Efeknya biasanya kelihatan dalam 1-2 minggu: lead time turun karena context switching berkurang.
Takeaway
Framework cuma wadah. Kalau ritualnya jalan tapi gak ada yang berubah, yang kamu punya bukan Agile — cuma kalender yang lebih rapi.