Scrumban: Menggabungkan Scrum dan Kanban

Scrumban adalah hasilnya ketika Anda berhenti memaksakan pilihan antara Scrum dan Kanban. Tim yang membutuhkan perencanaan terstruktur tetapi tidak mampu menanggung sprint yang kaku biasanya beralih ke scrumban lebih dulu.

Apa Itu Scrumban?

Scrumban adalah framework agile hibrida yang menempatkan mekanisme continuous-flow milik Kanban di atas disiplin perencanaan milik Scrum. Pekerjaan bergerak melalui board berbasis pull dengan batas Work in Progress (WIP), tetapi event perencanaan dijalankan sesuai kebutuhan, bukan berdasarkan jam sprint yang tetap.

Corey Ladas mencetuskan istilah ini dalam sebuah esai tahun 2008 dan kemudian mengembangkannya lebih lanjut dalam bukunya Scrumban: Essays on Kanban Systems for Lean Software Development. Argumen inti Ladas: Scrum adalah kerangka penyangga yang baik untuk tim yang baru mengenal agile, tetapi seiring matangnya tim, mereka sebaiknya melepas seremoni yang tidak memberi nilai tambah dan mempertahankan yang memang berguna. Model flow milik Kanban mengisi kekosongan tersebut. Hasilnya adalah framework yang cukup fleksibel untuk pekerjaan maintenance, antrean support, dan operasi marketing, yang semuanya tidak cocok dipetakan ke dalam sprint dua mingguan.

Fakta penting

• Laporan State of Agile ke-17 (2023) menemukan bahwa 9% responden menggunakan hybrid Scrum/Kanban sebagai pendekatan delivery utama mereka, naik dari 6% dua tahun sebelumnya.
• Tim yang menerapkan batas WIP bersama pull system biasanya melihat penurunan cycle time sebesar 20-40%, menurut data flow-improvement yang dikutip dalam buku Donald Reinertsen Principles of Product Development Flow (2009).
• Scrumban tetap mempertahankan event perencanaan tetapi memicunya berdasarkan ukuran antrean, bukan kalender, sehingga upaya perencanaan tetap sebanding dengan volume pekerjaan yang sebenarnya.

Scrum vs Kanban vs Scrumban

Ketiga framework ini berbagi board dan backlog yang sama, tetapi cepat berbeda dalam hal ritme, peran, dan cara pekerjaan masuk ke dalam sistem.

Jika tim Anda sudah menjalankan Scrum tetapi terus-menerus melenturkan aturan sprint untuk menangani permintaan mendesak, Anda sebenarnya sudah setengah jalan menuju scrumban. Dan jika Anda menjalankan Kanban tetapi merasa tidak pernah berhenti untuk refleksi atau perencanaan, model scrumban yang terstruktur-ketika-diperlukan memberi Anda alasan untuk berhenti sejenak.

Bagaimana Scrumban Bekerja

Mekanisme scrumban bertumpu pada empat gagasan yang saling terkait.

Pull system. Pekerjaan tidak didorong kepada engineer. Pekerjaan ditarik. Ketika seseorang menyelesaikan sebuah task, mereka menarik item berikutnya dari antrean siap ke kolom mereka. Ini mencegah pekerjaan menumpuk di jalur satu orang dan membuat bottleneck langsung terlihat.

Batas WIP. Setiap kolom board memiliki jumlah maksimum. Kolom Doing mungkin hanya boleh menampung tiga kartu sekaligus. Ketika kolom sudah penuh, tim fokus menyelesaikan pekerjaan sebelum memulai yang baru. Batas WIP adalah pengungkit paling ampuh untuk memangkas cycle time di sistem manapun yang berasal dari kanban.

Antrean siap (ready queue). Di antara backlog dan kolom kerja aktif terdapat antrean siap, sebuah buffer kecil berisi item yang sudah di-groom, diprioritaskan, dan benar-benar siap ditarik. Antrean siap ini memisahkan perencanaan dari eksekusi. Perencanaan bisa dilakukan dalam satu sesi terfokus, lalu tim menarik dari antrean sesuka hati tanpa perlu ada perencana yang hadir di ruangan.

Pemicu perencanaan sesuai kebutuhan. Alih-alih merencanakan setiap dua minggu apa pun yang terjadi, scrumban memicu event perencanaan ketika antrean siap turun di bawah ambang batas yang ditetapkan, misalnya dua item per developer. Ini berarti upaya perencanaan menyesuaikan dengan kebutuhan yang sebenarnya. Minggu yang sepi hanya perlu pengisian ulang singkat; minggu yang sibuk mungkin sama sekali tidak memerlukan perencanaan.

Cumulative flow diagram adalah alat pelacakan alami untuk scrumban karena memvisualisasikan ukuran antrean, WIP, dan throughput dalam satu tampilan. Jika sebuah pita mulai melebar, itu tandanya pekerjaan menumpuk lebih cepat daripada yang bisa diselesaikan.

Manfaat Scrumban

Flow tanpa kekacauan. Model continuous flow milik Kanban menjaga pekerjaan tetap bergerak. Scrumban menambahkan struktur yang cukup untuk mencegah backlog berubah menjadi kuburan tiket yang tak tersentuh.

Perencanaan sesuai keinginan Anda. Tim yang kesulitan dengan seremoni sprint planning yang menghabiskan waktu seharian hanya untuk dua jam keputusan yang benar-benar berarti akan langsung merasakan perbedaannya. Perencanaan terjadi ketika antrean perlu diisi ulang, bukan karena kalender mengatakan demikian.

Overhead lebih rendah untuk tim yang sudah stabil. Begitu sebuah tim tahu apa yang mereka lakukan, seremoni Scrum yang masuk akal saat masa ramp-up mulai terasa berlebihan. Scrumban membiarkan tim melepas apa yang tidak berguna dan mempertahankan apa yang berguna.

Menangani jenis pekerjaan yang beragam. Sebagian besar tim nyata menangani baik pekerjaan yang terencana (fitur baru, proyek) maupun pekerjaan yang tidak terencana (bug, permintaan, insiden). Scrum kesulitan menangani pekerjaan tak terencana karena mengganggu sprint. Scrumban menyerapnya karena board selalu punya ruang untuk menarik item baru ke antrean siap di luar siklus grooming normal.

Visibilitas. Board tetap hidup setiap saat. Siapa pun bisa melihat apa yang sedang dikerjakan, apa yang terhambat, dan seberapa dekat antrean siap untuk memicu perencanaan. Tidak perlu menunggu sprint review untuk mengetahui kondisi sistem.

Kelemahan Scrumban

Scrumban bukan solusi universal. Ia membawa mode kegagalannya sendiri.

Tanpa peran berarti tanpa akuntabilitas. Peran-peran yang didefinisikan dalam Scrum ada karena seseorang perlu memiliki backlog, seseorang perlu memfasilitasi, dan seseorang perlu melindungi tim dari scope creep. Scrumban secara default melepas peran-peran ini. Tim yang melewatkan struktur tersebut sering kali berakhir dengan backlog yang tidak ter-groom, rapat perencanaan yang tidak dipersiapkan siapa pun, dan board yang tidak diperbarui siapa pun.

Batas WIP memerlukan disiplin. Begitu seorang manajer meminta tim untuk "menambahkan satu hal lagi saja," batas WIP diam-diam digeser. Begitu batas menjadi sekadar saran, mekanisme flow runtuh. Scrumban hanya berhasil jika tim memperlakukan batas WIP sebagai batasan yang mutlak.

Kurang ideal untuk pekerjaan discovery yang besar dan kompleks. Jika Anda sedang membangun sesuatu yang benar-benar belum diketahui, ritme sprint milik Scrum memaksa refleksi dan perencanaan yang dibutuhkan pekerjaan eksploratif. Perencanaan sesuai kebutuhan milik scrumban bisa membuat tim berjalan terlalu lama tanpa berhenti sejenak untuk bertanya apakah mereka membangun hal yang tepat.

Sulit mengukur velocity. Karena tidak ada sprint tetap, metrik velocity dalam agile tradisional tidak berlaku secara langsung. Tim beralih ke throughput (jumlah item yang diselesaikan per minggu) dan cycle time sebagai gantinya. Ini adalah ukuran yang lebih baik pada sebagian besar kasus, tetapi memerlukan perubahan cara berpikir.

Cara Menerapkan Scrumban

Langkah 1: Mulai dari board yang sudah ada

Jangan merancang ulang semuanya sekaligus. Baik Anda berasal dari Scrum atau Kanban, pertahankan kolom dan format kartu yang sudah ada. Perubahan pertama bersifat tidak kasat mata: Anda beralih dari mentalitas push (menugaskan pekerjaan kepada orang) ke mentalitas pull (membiarkan orang menarik dari antrean saat mereka siap).

Langkah 2: Tambahkan batas WIP pada kolom aktif

Pilih angka yang konservatif untuk setiap kolom in-progress, biasanya satu sampai dua per anggota tim. Anda akan menyesuaikannya setelah satu atau dua minggu. Tujuannya bukan memilih angka yang sempurna, melainkan membuat masalah flow terlihat jelas.

Langkah 3: Buat antrean siap

Tambahkan kolom "Ready" di antara backlog dan kolom aktif pertama Anda. Item hanya berpindah ke Ready ketika sudah di-groom: didefinisikan, diestimasi, dan benar-benar bisa ditindaklanjuti. Ini adalah hasil dari perencanaan Anda. Tim menarik dari Ready secara bebas tanpa perlu ada perencana yang hadir.

Langkah 4: Tetapkan ambang batas pemicu perencanaan

Putuskan seberapa rendah antrean siap boleh turun sebelum Anda menjalankan sesi perencanaan. Titik awal yang umum: rencanakan ketika Ready turun di bawah pasokan dua hari. Tuliskan ini. Pemicunya harus berupa angka yang nyata, bukan "ketika terasa rendah."

Langkah 5: Jalankan retrospektif yang ringan

Bahkan tanpa sprint tetap, tim tetap perlu berhenti sejenak dan bertanya apa yang berjalan baik. Jadwalkan retrospektif singkat setiap dua sampai empat minggu, atau setelah sejumlah item tertentu selesai dikirim. Buat sesingkat mungkin, 30 sampai 45 menit, dan fokus pada flow: apa yang memperlambat kami, apa yang membantu, dan satu hal apa yang akan kami ubah berikutnya.

Setelah beberapa siklus, Anda akan memiliki data throughput yang nyata. Gunakan data itu untuk menyempurnakan batas WIP, menyesuaikan pemicu perencanaan, dan mengidentifikasi jenis pekerjaan mana yang bergerak paling cepat melalui board. Itulah loop peningkatan berkelanjutan yang menjadi inti dari metodologi agile.

Contoh Scrumban Berdasarkan Jenis Tim

Praktik Terbaik

Jaga board tetap jujur. Perbarui status kartu begitu berubah, bukan saat standup, bukan di akhir hari. Board yang basi lebih buruk daripada tidak ada board sama sekali karena menciptakan rasa percaya diri yang keliru.

Perlakukan batas WIP sebagai kontrak tim. Sepakati bersama, tuliskan di board, dan saling ingatkan satu sama lain. Ketika seseorang ingin melampaui batas, itu harus jadi bahan diskusi, bukan keputusan sepihak.

Pisahkan pekerjaan mendesak dari pekerjaan terencana. Tambahkan baris "Fast Lane" kecil di board untuk keadaan darurat yang sesungguhnya. Batasi hanya satu item pada satu waktu. Ini memberi jalur bagi insiden tanpa mengacaukan flow utama.

Visualisasikan pekerjaan yang terhambat. Gunakan flag atau tag warna untuk kartu yang terhambat, alih-alih membiarkannya tetap di in progress. Pekerjaan terhambat yang diam-diam duduk di dalam batas WIP adalah pemborosan yang tidak terlihat.

Ukur cycle time, bukan velocity. Lacak berapa lama item menghabiskan waktu dari Ready sampai Done. Cycle time menunjukkan seberapa dapat diprediksi delivery Anda. Meningkatkannya adalah tujuan utama dari pull system.

Kaitkan kembali dengan apa itu Scrum dan apa itu Kanban secara berkala. Scrumban meminjam dari keduanya, dan ketika sesuatu tidak berjalan baik, membantu untuk kembali ke prinsip aslinya. Sering kali jawabannya sudah ada di sana.

Jika tim Anda sedang menjajaki framework yang lebih luas untuk skala yang lebih besar, Scaled Agile Framework (SAFe) mengatasi ketegangan serupa pada tingkat portofolio. Dan bagi tim yang menginginkan lebih sedikit seremoni daripada scrumban, Extreme Programming (XP) mengambil arah yang berbeda: lebih banyak praktik engineering, lebih sedikit penyangga proses.

Pertanyaan yang Sering Diajukan

Apakah Scrumban memiliki sprint?

Tidak secara default. Scrumban menggantikan sprint tetap dengan perencanaan sesuai kebutuhan yang dipicu oleh ukuran antrean. Meski begitu, beberapa tim tetap mempertahankan ritme perencanaan dua mingguan yang longgar sebagai forcing function sambil menggunakan mekanisme flow untuk pekerjaan sehari-hari. Framework ini cukup fleksibel untuk memasukkan sprint jika itu berguna bagi tim.

Apakah ada peran yang didefinisikan dalam Scrumban?

Tidak. Scrumban melepas peran Product Owner, Scrum Master, dan Dev Team yang diwajibkan oleh Scrum. Tim memutuskan sendiri siapa yang memiliki backlog, siapa yang memfasilitasi perencanaan, dan siapa yang memelihara board. Banyak yang tetap mempertahankan peran product owner yang ringan karena tetap ada yang perlu memprioritaskan. Tetapi framework ini tidak mewajibkannya.

Apakah Scrumban baik untuk tim maintenance?

Ini salah satu kecocokan terbaik. Pekerjaan maintenance tidak terprediksi, datang dengan ukuran yang bervariasi, dan tidak cocok dipetakan ke siklus sprint planning. Pull system dan perencanaan sesuai kebutuhan memungkinkan tim maintenance menangani apa pun yang muncul tanpa terus-menerus menegosiasikan ruang lingkup terhadap batas sprint.

Bagaimana Scrumban berbeda dari sekadar "menjalankan Kanban"?

Perbedaan utamanya adalah struktur. Kanban murni tidak memiliki seremoni wajib, tidak ada pemicu perencanaan, dan tidak ada loop refleksi bawaan. Scrumban menambahkan antrean siap, ambang batas pemicu perencanaan, dan retrospektif opsional. Ini adalah Kanban dengan pagar pengaman untuk tim yang merasa flow murni menyerahkan terlalu banyak hal pada kebetulan.

Metrik apa yang harus dilacak tim Scrumban?

Cycle time (waktu dari Ready sampai Done), throughput (item yang diselesaikan per minggu), dan ukuran antrean adalah tiga metrik inti. Cumulative flow diagram memetakan ketiganya dalam satu tampilan dan membuat bottleneck menjadi jelas terlihat. Hindari melacak velocity kecuali Anda sudah memperkenalkan sprint, karena velocity adalah ukuran berbasis sprint.

Scrumban terus berkembang seiring tim menemukan kombinasi baru antara seremoni Scrum dan alat flow Kanban. Daya tahan framework ini berasal dari gagasan sederhana: optimalkan proses untuk pekerjaan yang sebenarnya, bukan sebaliknya. Mulai dari board Anda yang sudah ada, tambahkan batas WIP, dan lihat apa yang diungkap oleh batasan-batasan tersebut.

Bacaan Terkait

• What is Scrum
• What is Kanban
• Scrum vs Kanban
• WIP Limits
• Cumulative Flow Diagram
• Sprint Planning
• Velocity in Agile
• What is Agile Methodology
• Extreme Programming
• Scaled Agile Framework (SAFe)