Scrum vs Kanban: Perbedaan Utama dan Kapan Menggunakan Masing-masing

Keduanya adalah agile. Keduanya menggunakan board. Namun tim yang mencampuradukkan Scrum dengan Kanban berakhir dengan kekakuan Sprint di saat mereka membutuhkan aliran berkelanjutan, atau kelonggaran Kanban di saat mereka membutuhkan perencanaan terstruktur. Perbedaan utama di sini adalah ritme: satu berbasis waktu, yang lain mengalir seperti sungai.

Apa perbedaan antara Scrum dan Kanban?

Scrum berbasis waktu: pekerjaan berjalan dalam Sprint tetap (biasanya satu hingga empat minggu), dengan peran yang ditentukan dan ritme perencanaan yang wajib. Kanban adalah aliran berkelanjutan: pekerjaan bergerak melalui board tanpa reset keras, dibatasi bukan oleh waktu melainkan oleh batas Work in Progress (WIP) di setiap kolom.

Kedua kerangka kerja ini muncul dari pemikiran agile dan lean. Namun tujuannya berbeda. Scrum dirancang untuk pekerjaan produk yang tidak dapat diprediksi dan kaya akan penemuan, di mana tim membutuhkan loop Feedback terstruktur. Kanban, yang berakar pada Toyota Production System (TPS) tahun 1940-an, dirancang untuk optimasi aliran di mana tujuannya adalah throughput yang stabil dan bottleneck minimal, bukan Velocity Sprint.

Key Facts

• Panduan Scrum pertama kali dikodifikasikan oleh Jeff Sutherland dan Ken Schwaber pada tahun 1995 dan paling baru direvisi pada tahun 2020. Revisi 2020 menyederhanakan kerangka kerja dan mengganti "Tim Pengembangan" dengan "Developer."
• Kanban untuk pekerjaan pengetahuan secara resmi dikodifikasikan oleh David J. Anderson dalam bukunya tahun 2010 "Kanban: Successful Evolutionary Change for Your Technology Business" (Blue Hole Press), meskipun asal-usul manufakturnya dapat ditelusuri ke Toyota Production System Taiichi Ohno pada tahun 1940-an.
• Menurut Laporan Tahunan State of Agile ke-17 (2023), 87% responden menggunakan Scrum atau hibrida Scrum sebagai metode utama mereka, sementara 56% menggunakan Kanban, dan 9% menggunakan Scrumban. Banyak tim melaporkan menggunakan lebih dari satu pendekatan.

Sekilas: 10 perbedaan terbesar

Berikut cara tercepat untuk melihat bagaimana kedua kerangka kerja ini benar-benar berbeda:

Ritme dan perencanaan

Sprint Scrum tidak dapat dinegosiasikan. Tim menyepakati tujuan, mengambil serangkaian item dari Backlog, dan tidak mengubah ruang lingkup itu di tengah Sprint. Ini menciptakan mekanisme pemaksaan: setiap satu hingga empat minggu, tim mengirimkan sesuatu, meninjau bersama pemangku kepentingan, dan menyesuaikan arah. Itu adalah ritme yang dapat Anda rencanakan.

Kanban tidak memiliki Sprint. Pekerjaan datang, diprioritaskan, dan mengalir melalui board seiring kapasitas tersedia. Perencanaan bersifat ringan: meeting pengisian untuk mengisi bagian atas antrian. Tidak ada komitmen terhadap "apa yang akan kita selesaikan minggu ini." Komitmen terjadi pada tingkat item individual, dilacak berdasarkan cycle time (berapa lama satu item membutuhkan dari mulai hingga selesai?).

Dalam praktiknya, tim Scrum sering berjuang dengan "Sprint theater" di mana upacara terjadi tetapi tujuan Sprint bersifat fiktif. Tim Kanban sering berjuang dengan kebalikannya: semuanya sedang dalam proses, batas WIP diabaikan, dan board menjadi tempat parkir. Kedua masalah adalah masalah disiplin, bukan masalah kerangka kerja.

Peran dan upacara

Scrum memiliki tiga peran dan lima acara:

Peran: Product Owner (memiliki Backlog, mendefinisikan prioritas), Scrum Master (melatih proses, menghilangkan hambatan), Developer (membangun sesuatu). Ketiganya diperlukan agar Scrum berfungsi sebagaimana dirancang.

Acara: Sprint Planning, Daily Scrum (standup 15 menit), Sprint Review, retrospektif Sprint, dan Sprint itu sendiri. Ini bukan opsional, meskipun tim secara rutin mencoba melewatkan retrospektif.

Kanban tidak memerlukan peran sama sekali. Tidak ada Kanban Master, tidak ada padanan Product Owner dalam spesifikasinya. Tim sering memiliki flow manager atau service delivery manager dalam praktiknya, tetapi itu adalah pilihan organisasi, bukan persyaratan kerangka kerja. Ritme opsional mencakup meeting pengisian (isi antrian), perencanaan pengiriman, tinjauan pengiriman layanan, dan retrospektif. Tidak ada yang diwajibkan.

Inilah mengapa Kanban lebih mudah diperkenalkan ke tim yang sudah ada. Anda tidak meminta orang mengubah jabatan mereka. Anda hanya membuat Workflow terlihat dan menambahkan batas WIP.

Metrik: Velocity vs cycle time

Scrum mengukur Velocity: berapa banyak Story Point (atau satuan serupa) yang diselesaikan tim per Sprint? Velocity berguna untuk Sprint Planning dan perkiraan kapasitas kasar. Ini tidak berguna untuk memprediksi kapan item tertentu akan dikirimkan.

Kanban mengukur cycle time (berapa lama item membutuhkan dari "dimulai" hingga "selesai"?) dan throughput (berapa banyak item yang diselesaikan tim per satuan waktu?). Ini lebih prediktif untuk hasil kerja individual: jika cycle time rata-rata Anda adalah 3 hari dengan variansi rendah, Anda dapat memberi tahu pemangku kepentingan "item ini kemungkinan akan selesai pada Kamis" dengan keyakinan nyata.

Diagram cumulative flow adalah grafik khas Kanban: menunjukkan volume pekerjaan di setiap tahap dari waktu ke waktu, membuat bottleneck terlihat sebagai pita yang melebar. Burndown chart Scrum menunjukkan pekerjaan yang tersisa dalam sebuah Sprint. Keduanya berguna; keduanya mengukur hal yang berbeda.

Kapan menggunakan Scrum vs Kanban: pohon keputusan

Jawaban jujurnya: pilih berdasarkan bagaimana pekerjaan Anda benar-benar datang, bukan berdasarkan kerangka kerja mana yang terdengar lebih bergengsi.

Gunakan Scrum ketika:

• Pekerjaan Anda memiliki tujuan produk yang dapat ditemukan dan mendapat manfaat dari siklus penemuan terstruktur.
• Tim dapat berkomitmen pada ruang lingkup Sprint tanpa semuanya menjadi "darurat."
• Loop pembelajaran penting: Anda mengirimkan sesuatu, belajar darinya, dan mengkoreksi arah sebelum membangun lebih banyak.
• Pemangku kepentingan mendapat manfaat dari checkpoint tinjauan yang teratur dan dapat diprediksi.
• Anda membangun produk dengan Roadmap, bukan memproses antrian tiket.

Gunakan Kanban ketika:

• Pekerjaan datang secara tidak dapat diprediksi: tiket dukungan, permintaan operasional, pekerjaan pemeliharaan.
• Optimasi throughput lebih penting daripada Velocity Sprint.
• Tim tidak dapat berkomitmen pada ruang lingkup tetap karena interupsi adalah bagian dari pekerjaan.
• Anda ingin titik masuk dengan upacara rendah ke dalam manajemen Workflow terstruktur.
• Anda meningkatkan proses yang sudah ada daripada menemukan produk baru.

Gunakan Scrumban ketika:

• Anda sudah melampaui kekakuan Scrum tetapi masih menginginkan ritme perencanaan tertentu.
• Anda memiliki campuran pekerjaan produk terencana dan pekerjaan dukungan tidak terencana dalam tim yang sama.
• Sprint Anda sebagian besar hanya mengubah nama tiket yang sama, dan retrospektif tidak menghasilkan perubahan.

Heuristik yang berguna: jika struktur rincian kerja tim Anda dapat didefinisikan dua minggu sebelumnya dengan keyakinan yang wajar, Scrum cocok. Jika tidak, Kanban lebih cocok. Dan jika Gantt chart Anda sebagian besar fiksi karena ruang lingkup terus bergeser, lihat apa sebenarnya kegunaan Gantt chart sebelum berkomitmen pada salah satunya.

Mitos dan kesalahpahaman umum

Tim sering mengadopsi kerangka kerja yang salah karena merespons mitos daripada situasi nyata mereka:

• "Kanban tidak memiliki aturan." Memiliki lebih sedikit upacara, tetapi aturannya nyata. Batas WIP bukan saran. Melanggarnya menandakan masalah sistemik yang perlu diselesaikan, bukan batas WIP yang perlu dihapus.
• "Scrum lebih matang atau profesional." Kematangan tidak relevan. Netflix beroperasi dengan manajemen aliran yang dipengaruhi Kanban. Tim produk perangkat lunak di Amazon menggunakan pendekatan berbasis Sprint. Alat yang tepat bergantung pada pekerjaan, bukan pada prestise.
• "Anda tidak bisa mencampurnya." Scrumban ada justru karena tim menemukan nilai dalam menggabungkan elemen keduanya. Kerangka kerja ini bukan agama.
• "Board Kanban adalah board Scrum." Board hanyalah alat visualisasi. Board Scrum direset setiap Sprint dan menampilkan status Sprint. Board Kanban bersifat persisten, menampilkan tahapan Workflow, dan menegakkan batas WIP. Furnitur yang sama, ruangan yang berbeda.
• "Daily standup adalah Kanban." Daily Scrum adalah upacara Scrum. Kanban tidak memerlukan daily standup, meskipun banyak tim Kanban mengadopsinya. Jangan mencampuradukkan upacara dengan kerangka kerja.
• "Scrum cocok untuk perangkat keras." Bisa, tetapi metode jalur kritis dan diagram PERT sering lebih cocok untuk pengembangan perangkat keras karena perangkat keras memiliki ketergantungan sekuensial sejati yang tidak berubah oleh reset Sprint.

Scrumban: menggabungkan keduanya

Corey Ladas menggambarkan Scrumban dalam makalah tahun 2008 sebagai cara untuk mentransisikan tim dari Scrum ke Kanban. Dalam praktiknya, Scrumban berkembang menjadi hibridnya sendiri: tim mempertahankan beberapa ritme perencanaan seperti Sprint (sebuah "pemicu" yang aktif ketika Backlog turun di bawah ambang batas) sambil menggunakan batas WIP dan metrik aliran Kanban di board itu sendiri.

Ini sangat berguna untuk tim yang setengah produk, setengah dukungan. Pekerjaan produk mendapat manfaat dari tujuan Sprint dan siklus tinjauan. Pekerjaan dukungan tidak bisa menunggu batas Sprint. Scrumban memungkinkan Anda memproses item mendesak tanpa merusak komitmen Sprint.

Risikonya: Scrumban juga bisa menjadi alasan untuk menghindari disiplin salah satu kerangka kerja. Jika Anda menyebutnya Scrumban tetapi batas WIP Anda selalu 10 dan tujuan Sprint Anda selalu "apa pun yang masuk minggu ini," Anda tidak memiliki Scrum maupun Kanban. Anda hanya memiliki papan tulis berlabel.

Pertanyaan yang sering diajukan

Apakah Kanban metodologi atau alat?

Ini adalah metodologi. "Board Kanban" adalah salah satu artefak dari metode Kanban, tetapi Kanban itu sendiri adalah sekumpulan praktik untuk mengelola dan meningkatkan aliran: visualisasikan pekerjaan, batasi WIP, kelola aliran, buat kebijakan proses eksplisit, implementasikan loop Feedback, dan tingkatkan secara kolaboratif. Board adalah bagian yang paling terlihat, tetapi batas WIP dan metrik aliran adalah yang menjadikannya metode daripada kebiasaan sticky note.

Bisakah tim beralih dari Scrum ke Kanban di tengah proyek?

Ya, tetapi lakukan dengan sengaja. Transisi paling umum terjadi selama retrospektif tim ketika tim sepakat bahwa siklus Sprint tidak menambah nilai. Langkah praktisnya: berhenti merencanakan Sprint, buat batas WIP eksplisit di board yang sudah ada, mulai melacak cycle time daripada Velocity, dan jalankan tinjauan aliran daripada Sprint Review. Jangan menjalankan Sprint dan Kanban secara bersamaan selama transisi. Pilih tanggal dan beralih.

Apakah Anda memerlukan Scrum Master dalam Kanban?

Tidak. Kanban tidak memiliki peran yang diwajibkan. Beberapa organisasi menggunakan "flow manager" atau "service delivery manager" untuk menjalankan meeting pengisian dan melindungi batas WIP, tetapi ini tidak diamanatkan oleh metode Kanban. Tim yang mengadopsi Kanban dari Scrum sering mempertahankan Scrum Master mereka dalam peran pelatihan, dan itu baik-baik saja. Pastikan saja bahwa peran tersebut sekarang opsional daripada diperlukan.

Mana yang lebih mudah untuk dimulai: Scrum atau Kanban?

Kanban lebih mudah untuk dimulai bagi sebagian besar tim karena tidak memerlukan reorganisasi peran atau komitmen pada kalender upacara baru. Anda dapat memperkenalkan Kanban dengan cukup membuat Workflow yang ada terlihat di board dan menyepakati batas WIP. Scrum memerlukan kejelasan peran (siapa Product Owner?) dan komitmen upacara (kami akan melakukan Sprint Planning setiap dua minggu) sebelum berfungsi sebagaimana dirancang. Meski begitu, ritme terstruktur Scrum sering kali menjadi keunggulan bagi tim yang membutuhkan mekanisme pemaksaan untuk melakukan pengiriman secara teratur. Jika tim Anda memiliki riwayat "kami akan merilis ketika sudah siap" tanpa batas waktu yang jelas, tekanan Sprint Scrum bisa menjadi persis yang Anda butuhkan.

---

Sebagian besar tim menghabiskan waktu berdebat tentang kerangka kerja mana yang "lebih baik" padahal seharusnya bertanya mana yang cocok dengan cara pekerjaan mereka sebenarnya datang. Scrum memberi Anda loop Feedback terstruktur setiap satu hingga empat minggu. Kanban memberi Anda kejelasan aliran dan keterprediksiaan di tingkat item individual. Keduanya lebih baik daripada bekerja dengan spreadsheet bersama dan doa. Mulailah dengan yang cocok dengan pola kerja Anda, ukur dengan jujur, dan lakukan iterasi dari sana.

Untuk tim yang membangun rencana proyek terstruktur di samping pekerjaan agile mereka, matriks RACI dapat memperjelas kepemilikan keputusan di seluruh tim Sprint. Dan jika latar belakang metodologi waterfall Anda menarik Anda ke arah perencanaan sekuensial, struktur Sprint Scrum biasanya merupakan jembatan yang lebih baik daripada langsung melompat ke aliran berkelanjutan Kanban.