Mengapa Kanban Berhasil — dan Cara Mengetahui Apakah Tim Anda Siap Menggunakannya

Kebanyakan tim mengadopsi Kanban karena seseorang membaca sebuah artikel blog. Pertanyaan yang lebih cerdas adalah apakah masalah yang diselesaikan Kanban benar-benar masalah yang dimiliki tim Anda.

Ada satu momen yang dikenali kebanyakan tim, biasanya ketika anggotanya sudah lebih dari delapan atau sembilan orang. Pekerjaan berjalan — email terkirim, fitur dirilis, klien terlayani — tetapi tak seorang pun punya gambaran jelas tentang apa yang dikerjakan orang lain. Proyek menumpuk. Janji dibuat lalu diam-diam terlupakan. Anda menghabiskan dua puluh menit sebelum setiap rapat hanya untuk mencari tahu di mana sebenarnya sebuah pekerjaan berada. Jawabannya, biasanya, "di suatu tempat."

Itulah masalah yang dirancang untuk diselesaikan Kanban. Bukan masalah menetapkan strategi, merekrut orang yang tepat, atau membangun budaya — melainkan masalah operasional yang spesifik dan melelahkan: mengetahui apa yang sedang dikerjakan tim dan apa yang menghambatnya.

Alat ini ternyata sangat bersahaja untuk sesuatu yang begitu menyita perhatian. Kanban tidak mengklaim dapat memperbaiki organisasi Anda. Ia hanya membuat pekerjaan terlihat. Dan ternyata visibilitas, jika diterapkan secara konsisten, mengubah sangat banyak hal di hilir.

Dari mana Kanban sebenarnya berasal

Kata ini berasal dari bahasa Jepang — artinya "papan penanda" atau "papan reklame" — dan sistemnya dikembangkan oleh Toyota pada akhir 1940-an untuk mengelola persediaan di pabrik-pabrik manufakturnya. Idenya sederhana: alih-alih memproduksi komponen menurut jadwal tetap, pabrik hanya memproduksinya ketika stasiun di hilir memberi sinyal bahwa mereka membutuhkannya. Sebuah kartu fisik — kanban — bergerak kembali ke hulu lini sebagai permintaan. Tak ada yang dibuat secara spekulatif. Tak ada yang menumpuk tanpa perlu.

Wawasan yang dimiliki Toyota, dan kemudian dipinjam oleh tim perangkat lunak, adalah bahwa sebagian besar inefisiensi dalam sebuah sistem bukan berasal dari orang yang bekerja terlalu lambat, melainkan dari pekerjaan yang salah dikerjakan pada waktu yang salah. Terlalu banyak hal dimulai sekaligus. Bottleneck yang tak disadari siapa pun sampai terlambat. Pekerjaan yang sudah selesai menganggur di satu tempat sementara langkah berikutnya kewalahan di tempat lain.

Para pengembang perangkat lunak, terutama di perusahaan seperti Microsoft pada awal 2000-an, mulai mengadaptasi gagasan ini untuk pekerjaan berbasis pengetahuan. Kartu menjadi tugas. Stasiun pabrik menjadi tahap dalam alur kerja. Dan papan penanda menjadi papan — awalnya fisik, kemudian digital — tempat siapa pun di tim dapat melihat sekilas apa yang sedang dikerjakan, apa yang menunggu, dan apa yang sudah selesai.

Apa yang sebenarnya ditunjukkan papan Kanban

Papan Kanban dasar memiliki tiga kolom: To Do, In Progress, dan Done. Itu sudah cukup untuk banyak tim kecil dan titik awal yang baik. Namun nilai sesungguhnya muncul ketika Anda mulai menyesuaikan tahap-tahap itu dengan cara pekerjaan Anda benar-benar mengalir — bukan cara yang Anda inginkan.

Tim konten mungkin menggunakan: Ide, Brief, Draf, Review, Terjadwal, Terbit. Tim perangkat lunak mungkin memecah "In Progress" menjadi kolom terpisah untuk pengembangan, code review, dan QA. Tim konsultan mungkin melacak Discovery, Proposal, Aktif, Menunggu Klien, dan Selesai. Tahap-tahap itu harus mencerminkan serah terima yang nyata dan waktu tunggu yang nyata — tempat pekerjaan berpindah tangan, atau tertahan sampai sesuatu yang lain terjadi.

Perhatikan kartu di kolom tengah — laporan audit gudang, sudah delapan hari berjalan, ditandai terblokir. Dalam sistem tanpa papan, tugas itu bisa saja menganggur dua minggu lagi sebelum ada yang sadar bahwa ia tidak bergerak. Seseorang sedang menunggu pihak ketiga. Atau dibutuhkan keputusan dari seorang manajer yang tidak tahu bahwa dialah penghambatnya. Papan membuat hambatan itu terlihat. Itulah sebagian besar pekerjaannya.

Aturan yang membuatnya berhasil: batas WIP

Jika ada satu konsep yang membedakan tim yang menggunakan Kanban dengan benar dari tim yang hanya punya daftar tugas yang lebih cantik, itulah batas work-in-progress — disingkat batas WIP. Idenya, setiap kolom memiliki jumlah maksimum item yang boleh berada di sana pada saat yang sama. Ketika sebuah kolom penuh, Anda tidak bisa menambah pekerjaan sampai ada yang keluar.

Ini terasa berlawanan dengan intuisi. Bukankah bisa mengerjakan lebih banyak tugas sekaligus berarti lebih banyak yang selesai? Tidak. Yang sebenarnya terjadi saat orang mengerjakan terlalu banyak hal bersamaan adalah semuanya memakan waktu lebih lama. Pergantian konteks itu mahal. Pekerjaan setengah jadi menciptakan beban koordinasi. Dan ketika sepuluh hal berstatus "sedang dikerjakan," sangat sulit membedakan mana yang benar-benar bergerak dan mana yang hanya macet tanpa tanda.

Batas WIP tiga pada kolom In Progress berarti ketika hal keempat tiba di meja seseorang, seseorang di tim harus mengambil keputusan: tugas yang sudah ada mana yang diselesaikan lebih dulu? Ini memaksa prioritisasi. Ini memaksa percakapan. Dan ini cenderung menghasilkan penyelesaian item individual yang lebih cepat, meskipun laju memulai item baru melambat.

Kanban versus Scrum: pertanyaan yang selalu diajukan tim

Jika Anda pernah bersinggungan dengan tim perangkat lunak atau pola pikir operasional modern, Anda hampir pasti pernah menjumpai Scrum — kerangka kerja yang mengatur pekerjaan dalam sprint dua mingguan yang tetap, lengkap dengan sesi perencanaan, retrospektif, dan peran tertentu seperti Scrum Master dan Product Owner. Banyak tim memperlakukan Scrum dan Kanban sebagai metodologi yang bersaing dan merasa harus memilih. Perbedaannya sebenarnya lebih sederhana dari itu.

Banyak tim — terutama yang bukan tim rekayasa perangkat lunak murni — merasa seremoni Scrum berat dan struktur sprint tetapnya canggung diterapkan pada pekerjaan operasional yang berkelanjutan. Tim marketing, tim customer success, tim operasional, dan pendiri yang mengurus segalanya sekaligus jarang memiliki pekerjaan yang pas dengan siklus dua minggu. Model aliran berkelanjutan Kanban cenderung lebih cocok untuk mereka.

Meski begitu, banyak tim menggabungkan keduanya. Mereka memakai siklus perencanaan ala sprint untuk pengembangan produk sambil menjalankan papan Kanban untuk pekerjaan operasional dan dukungan yang masuk terlepas dari sprint mana yang sedang berjalan. Itu hibrida yang sangat masuk akal.

Tiga pertanyaan yang harus bisa dijawab papan Anda dalam tiga puluh detik

Papan Kanban paling berguna ketika Anda bisa melihatnya dan, tanpa berbicara dengan siapa pun, menjawab tiga pertanyaan ini dengan cepat: Apa yang sedang dikerjakan tim saat ini? Di mana pekerjaan tersendat? Adakah sesuatu yang seharusnya dikerjakan tetapi belum dimulai?

Jika Anda tidak dapat menjawab ketiganya dalam tiga puluh detik setelah melihat papan, kemungkinan papan itu tidak dirawat dengan benar. Pola kegagalan yang paling umum adalah papan tempat tugas dibuat tetapi tak pernah dipindahkan — ia berubah menjadi kuburan niat baik, bukan peta hidup pekerjaan yang sebenarnya. Papan yang tidak mutakhir lebih buruk daripada tidak punya papan, karena ia menciptakan rasa visibilitas yang semu.

Disiplin yang dibutuhkan untuk merawat papan itu nyata. Tugas harus berpindah saat pekerjaan berpindah. Item yang terblokir harus ditandai begitu macet, bukan dua minggu kemudian. Kartu harus punya pemilik yang jelas, dan pemilik harus memperbarui kartunya. Semua ini tidak memerlukan banyak waktu — praktik Kanban yang dijalankan dengan baik mungkin hanya memakan lima sampai sepuluh menit per orang per hari — tetapi membutuhkan konsistensi. Tim yang paling diuntungkan Kanban adalah mereka yang memperlakukan papan sebagai sumber kebenaran, bukan sebagai kegiatan pencatatan tambahan.

Apa yang tidak dilakukan Kanban

Kanban bukan alat strategi. Ia tidak akan membantu Anda menentukan apa yang harus dikerjakan — hanya membantu mengelola apa yang sudah Anda putuskan untuk dikerjakan. Jika organisasi Anda punya masalah prioritisasi, atau masalah mandat yang tidak jelas, atau masalah "kita memulai terlalu banyak proyek sebelum menyelesaikan yang lama" yang berakar pada perilaku kepemimpinan dan bukan proses, papan Kanban akan mengungkap masalah itu tetapi tidak menyelesaikannya.

Ia juga bukan pengganti manajemen yang baik. Papan tidak menggantikan sesi one-on-one, pendelegasian yang bijak, atau komunikasi yang jelas tentang mengapa pekerjaan tertentu penting. Tim terkadang mengadopsi alat proses dengan harapan prosesnya akan mengerjakan pekerjaan relasional dan organisasional yang sebenarnya tugas manajer. Itu tidak akan terjadi.

Yang akan dilakukannya adalah mengurangi ketidakpastian yang menyelimuti dan memperlambat kebanyakan tim. Pertanyaan "siapa mengerjakan apa," "apakah ini sudah selesai," dan "apa yang sebaiknya saya ambil berikutnya" menghasilkan komunikasi bernilai rendah dalam jumlah besar di organisasi yang tidak punya sistem bersama yang terlihat. Kanban menghilangkan sebagian besar noise itu. Dan bagi tim yang noise itu adalah masalah utamanya, perbedaannya signifikan.

Cara memulai — tanpa lokakarya tiga hari

Implementasi Kanban terbaik yang pernah saya lihat dimulai dari kecil lalu berkembang. Yang terburuk melibatkan seorang konsultan, offsite dua hari, dan papan berdesain indah yang tak dipakai siapa pun pada minggu ketiga.

Mulailah dengan tim Anda apa adanya, dengan pekerjaan yang benar-benar Anda miliki. Buat tiga kolom: Backlog, In Progress, Done. Habiskan tiga puluh menit bersama tim untuk menaruh setiap pekerjaan yang sedang berjalan ke dalam sebuah kartu. Sepakati satu aturan: saat Anda memulai sesuatu, letakkan di papan. Saat ia berpindah, pindahkan kartunya. Jangan lakukan hal lain selama dua minggu.

Setelah dua minggu, lihat papan bersama-sama. Di mana pekerjaan menumpuk? Apa yang tetap di Backlog padahal semua orang bilang itu prioritas? Apa yang bergerak lebih cepat dari dugaan? Apa yang macet dan mengapa? Gunakan hasil pengamatan itu untuk menyempurnakan kolom dan menambah kekhususan. Mungkin "In Progress" perlu dipecah menjadi "In Progress" dan "Menunggu Pihak Eksternal." Mungkin Anda butuh kolom bernama "In Review" karena langkah itu terus terlewat. Biarkan papan berkembang sebagai respons terhadap apa yang diungkap pekerjaan Anda yang sebenarnya, bukan terhadap bentuk yang dikatakan buku metodologi.

Permainan jangka panjang: metrik aliran

Setelah sistem Kanban berjalan, ia menghasilkan data yang tak pernah dimanfaatkan kebanyakan tim. Lead time — total waktu sejak tugas dibuat hingga selesai — adalah yang terpenting. Jika rata-rata lead time untuk tugas tipikal Anda dua belas hari, dan Anda ingin lima hari, kini Anda punya angka untuk dikejar dan papan yang akan menunjukkan ke mana perginya tujuh hari ekstra itu.

Cycle time hanya mengukur periode kerja aktif, tanpa waktu tugas berada di backlog. Throughput mengukur berapa banyak item yang diselesaikan tim Anda per minggu. Tak satu pun metrik ini membutuhkan perangkat lunak khusus jika Anda disiplin mencatat kapan kartu dibuat dan kapan ditutup. Dan bersama-sama, metrik itu memberi gambaran kapasitas tim Anda yang jauh lebih jujur daripada proses perencanaan berbasis estimasi mana pun.

Kebanyakan tim kecil dan menengah tak pernah sampai ke sini. Mereka menggunakan Kanban sebagai alat visibilitas — yang bernilai dengan sendirinya — dan tidak melangkah lebih jauh. Itu tidak masalah. Namun jika Anda ingin membuat komitmen kepada pemangku kepentingan tentang kapan sesuatu akan selesai, atau ingin memahami mengapa sebagian pekerjaan memakan waktu tiga kali lebih lama dari perkiraan, metrik itu tersedia saat Anda membutuhkannya.