Mengapa Kanban Berfungsi — dan Cara Mengetahui Apakah Tim Anda Siap untuk Itu

Sebagian besar tim mengadopsi Kanban karena seseorang membaca posting blog. Pertanyaan yang lebih cerdas adalah apakah masalah yang Kanban selesaikan benar-benar adalah masalah yang dimiliki tim Anda.

Ada saat yang dikenali sebagian besar tim, biasanya sekitar waktu mereka memiliki lebih dari delapan atau sembilan orang. Pekerjaan sedang dilakukan — email dikirim, fitur dikirim, klien dikelola — tetapi tidak ada orang yang memiliki pemahaman jelas tentang apa yang dikerjakan semua orang lain. Proyek menumpuk. Hal-hal dijanjikan dan kemudian tenang terlupakan. Anda menghabiskan dua puluh menit sebelum setiap pertemuan mencari tahu di mana pekerjaan sebenarnya berada. Jawabannya, biasanya, adalah "di suatu tempat."

Itu adalah masalah yang dirancang Kanban untuk dipecahkan. Bukan masalah menetapkan strategi, atau merekrut orang yang tepat, atau membangun budaya — tetapi masalah operasional yang spesifik dan menggiling tentang mengetahui apa yang dikerjakan tim Anda dan apa yang menghalangi.

Ini adalah alat yang secara mengejutkan rendah hati untuk sesuatu yang telah menarik begitu banyak perhatian. Kanban tidak mengklaim untuk memperbaiki organisasi Anda. Ini hanya membuat pekerjaan terlihat. Dan ternyata visibilitas, diterapkan secara konsisten, mengubah jumlah hal yang luar biasa di hilir.

Dari mana Kanban sebenarnya berasal

Kata itu adalah bahasa Jepang — berarti "papan tanda" atau "billboard" — dan sistem dikembangkan oleh Toyota pada akhir 1940-an sebagai cara untuk mengelola inventaris di pabrik manufaktur mereka. Idenya sederhana: daripada memproduksi suku cadang sesuai jadwal tetap, pabrik akan memproduksinya hanya ketika stasiun hilir menandakan bahwa diperlukan. Kartu fisik — kanban — akan berjalan kembali ke atas garis sebagai permintaan. Tidak ada yang dibuat secara spekulatif. Tidak ada yang menumpuk tanpa perlu.

Wawasan yang dimiliki Toyota, dan yang kemudian dipinjam oleh tim perangkat lunak, adalah bahwa sebagian besar inefisiensi dalam sistem berasal tidak dari orang yang bekerja terlalu lambat, tetapi dari pekerjaan yang salah dilakukan pada waktu yang salah. Terlalu banyak hal dimulai sekaligus. Hambatan yang tidak diketahui siapa pun sampai terlambat. Pekerjaan yang selesai di satu tempat sementara langkah berikutnya kewalahan di tempat lain.

Pengembang perangkat lunak, khususnya di perusahaan seperti Microsoft pada awal 2000-an, mulai mengadaptasi ide-ide ini untuk pengetahuan kerja. Kartu menjadi tugas. Stasiun pabrik menjadi tahap dalam alur kerja. Dan papan tanda menjadi papan — fisik pada awalnya, kemudian digital — di mana siapa pun di tim dapat melihat, sekilas, apa yang sedang berlangsung, apa yang menunggu, dan apa yang dilakukan.

Apa yang sebenarnya ditunjukkan papan Kanban kepada Anda

Papan Kanban dasar memiliki tiga kolom: Untuk Dilakukan, Sedang Berlangsung, dan Selesai. Itu cukup untuk banyak tim kecil dan tempat yang baik untuk memulai. Tetapi nilai sebenarnya muncul ketika Anda mulai menyesuaikan tahapan itu sesuai dengan bagaimana pekerjaan Anda benar-benar mengalir — bukan bagaimana Anda menginginkannya mengalir.

Tim konten mungkin menggunakan: Ide, Brief, Dalam Draf, Dalam Tinjauan, Dijadwalkan, Diterbitkan. Tim perangkat lunak mungkin memecah "Sedang Berlangsung" menjadi kolom terpisah untuk pengembangan, tinjauan kode, dan QA. Tim konsultasi mungkin melacak Penemuan, Proposal, Aktif, Menunggu Klien, dan Ditutup. Tahapan harus mencerminkan tangan yang nyata dan waktu menunggu yang nyata — tempat di mana pekerjaan berubah tangan, atau di mana ia duduk sampai sesuatu yang lain terjadi.

Perhatikan kartu di kolom tengah — laporan audit gudang, delapan hari masuk, ditandai sebagai diblokir. Dalam sistem tanpa papan, tugas itu mungkin duduk selama dua minggu lagi sebelum siapa pun menyadari itu tidak bergerak. Seseorang menunggu pihak ketiga. Atau keputusan diperlukan dari manajer yang tidak tahu mereka adalah pemblokir. Papan membuat penyumbatan terlihat. Itu sebagian besar pekerjaan.

Aturan yang membuatnya berfungsi: batas WIP

Jika ada satu konsep yang memisahkan tim yang menggunakan Kanban dengan benar dari tim yang hanya memiliki daftar tugas yang lebih cantik, itu adalah batas work-in-progress — batas WIP singkatnya. Idenya adalah bahwa setiap kolom memiliki jumlah maksimum item yang diizinkan berada di sana sekaligus. Ketika kolom penuh, Anda tidak dapat menambahkan lebih banyak pekerjaan sampai sesuatu bergerak keluar.

Ini terasa berlawanan dengan intuisi. Pastinya dapat menempatkan lebih banyak tugas yang sedang berlangsung berarti lebih banyak yang diselesaikan? Itu tidak. Apa yang sebenarnya terjadi ketika orang bekerja pada terlalu banyak hal secara bersamaan adalah bahwa semuanya membutuhkan waktu lebih lama. Beralih konteks mahal. Pekerjaan setengah jadi menciptakan overhead koordinasi. Dan ketika sepuluh hal "sedang berlangsung," sangat sulit untuk mengetahui yang mana sebenarnya bergerak dan yang mana hanya terjebak tetapi tidak ditandai.

Batas WIP tiga pada kolom Sedang Berlangsung Anda berarti bahwa ketika hal keempat tiba di meja seseorang, seseorang di tim harus membuat keputusan: tugas mana yang sudah ada yang selesai terlebih dahulu? Itu memaksa prioritas. Itu memaksa percakapan. Dan cenderung menghasilkan penyelesaian item individual lebih cepat, bahkan jika tingkat memulai item baru melambat.

Kanban versus Scrum: pertanyaan yang selalu ditanyakan tim

Jika Anda telah menghabiskan waktu di sekitar tim perangkat lunak atau pemikiran operasi modern, Anda mungkin pernah menemui Scrum — kerangka kerja yang mengatur pekerjaan menjadi sprint dua minggu tetap, dengan sesi perencanaan, retrospektif, dan peran yang ditentukan seperti Scrum Master dan Product Owner. Banyak tim memperlakukan Scrum dan Kanban sebagai metodologi bersaing dan merasa mereka harus memilih. Perbedaannya sebenarnya lebih sederhana dari itu.

Kanban cocok untuk Anda jika:

• Pekerjaan tiba secara tidak terduga atau berkelanjutan
• Tugas yang berbeda memiliki ukuran yang sangat berbeda
• Tim Anda mencakup beberapa fungsi
• Anda ingin memulai ringan dan berkembang proses
• Kecepatan item individu paling penting

Scrum cocok untuk Anda jika:

• Pekerjaan dapat direncanakan dalam batch tetap
• Tim Anda terutama fokus pada teknik
• Kecepatan pengiriman yang dapat diprediksi adalah prioritas
• Anda memiliki kapasitas fasilitasi proses khusus
• Pemangku kepentingan memerlukan pembaruan terstruktur reguler

Banyak tim — terutama yang bukan tim rekayasa perangkat lunak murni — menemukan upacara Scrum berat dan struktur sprint tetapnya sulit diterapkan pada pekerjaan operasional berkelanjutan. Tim pemasaran, tim keberhasilan pelanggan, tim operasi, dan pendiri yang mengelola semuanya jarang memiliki pekerjaan yang cocok dengan rapi ke dalam siklus dua minggu. Model aliran berkelanjutan Kanban cenderung lebih cocok untuk mereka.

Yang mengatakan, banyak tim menggabungkan keduanya. Mereka menggunakan siklus perencanaan gaya sprint untuk pengembangan produk sambil menjalankan papan Kanban untuk pekerjaan operasional dan dukungan yang mengalir terlepas dari sprint apa yang Anda gunakan. Itu adalah hibrid yang cukup masuk akal.

Tiga pertanyaan yang harus dijawab papan Anda dalam tiga puluh detik

Papan Kanban paling berguna ketika Anda dapat melihatnya dan, tanpa berbicara dengan siapa pun, menjawab tiga pertanyaan dengan cepat: Apa yang sedang dikerjakan tim? Di mana pekerjaan terjebak? Apakah ada sesuatu yang harus dilakukan yang belum dimulai?

Jika Anda tidak dapat menjawab ketiga pertanyaan dalam tiga puluh detik setelah melihat papan, kemungkinan itu tidak dipertahankan dengan benar. Mode kegagalan paling umum adalah papan di mana tugas dibuat tetapi tidak pernah dipindahkan — itu menjadi makam niat baik daripada peta langsung dari pekerjaan nyata. Papan yang tidak terkini lebih buruk daripada tidak ada papan, karena menciptakan rasa visibilitas palsu.

Disiplin yang diperlukan untuk mempertahankan papan itu nyata. Tugas perlu bergerak ketika pekerjaan bergerak. Item yang diblokir perlu ditandai saat mereka mandek, bukan dua minggu kemudian. Kartu memerlukan pemilik yang jelas, dan pemilik memerlukan kartu update mereka. Tidak ada ini memerlukan banyak waktu — praktik Kanban yang dijalankan dengan baik mungkin membutuhkan lima sampai sepuluh menit per orang per hari — tetapi memerlukan konsistensi. Tim yang paling bermanfaat dari Kanban adalah tim yang memperlakukan papan sebagai sumber kebenaran, bukan sebagai latihan pencatatan catatan tambahan.

Apa yang Kanban lakukan

Kanban bukan alat strategi. Ini tidak akan membantu Anda mencari tahu apa yang harus dikerjakan — hanya membantu Anda mengelola apa yang telah Anda putuskan untuk dikerjakan. Jika organisasi Anda memiliki masalah prioritas, atau masalah mandat yang tidak jelas, atau masalah "kami memulai terlalu banyak proyek sebelum menyelesaikan yang lama" berakar dalam perilaku kepemimpinan daripada proses, papan Kanban akan mengungkapkan masalah itu tetapi tidak menyelesaikannya.

Ini juga bukan pengganti manajemen yang baik. Papan tidak menggantikan satu-ke-satu, atau delegasi yang bijaksana, atau komunikasi yang jelas tentang mengapa pekerjaan tertentu penting. Tim terkadang mengadopsi alat proses dengan harapan proses akan melakukan pekerjaan relasional dan organisasi yang sebenarnya adalah pekerjaan manajer. Ini tidak akan.

Apa yang akan dilakukan adalah mengurangi ketidakpastian sekitar yang memperlambat sebagian besar tim. Pertanyaan "siapa yang mengerjakan apa," "apakah itu selesai," dan "apa yang harus saya ambil selanjutnya" menghasilkan sejumlah besar komunikasi bernilai rendah di organisasi yang tidak memiliki sistem bersama yang terlihat. Kanban menghilangkan sebagian besar kebisingan itu. Dan untuk tim di mana kebisingan itu adalah masalah dominan, perbedaannya signifikan.

Cara memulai — tanpa workshop tiga hari

Implementasi Kanban terbaik yang saya lihat dimulai kecil dan berkembang. Yang terburuk melibatkan konsultan, offsite dua hari, dan papan yang dirancang dengan indah yang tidak digunakan siapa pun pada minggu ketiga.

Mulai dengan tim Anda seperti sebenarnya, dengan pekerjaan yang sebenarnya Anda miliki. Buat tiga kolom: Backlog, Sedang Berlangsung, Selesai. Habiskan tiga puluh menit dengan tim Anda menempatkan setiap item kerja saat ini pada kartu. Setuju dengan satu aturan: ketika Anda memulai sesuatu, itu masuk di papan. Ketika bergerak, Anda memindahkan kartu. Jangan lakukan apa pun lagi selama dua minggu.

Setelah dua minggu, lihat papan bersama-sama. Di mana hal-hal menumpuk? Apa yang tetap di Backlog yang semua orang katakan adalah prioritas? Apa yang bergerak lebih cepat dari yang diharapkan? Apa yang mandek dan mengapa? Gunakan apa yang Anda amati untuk menyempurnakan kolom dan menambahkan spesifikasi. Mungkin "Sedang Berlangsung" perlu dibagi menjadi "Sedang Berlangsung" dan "Menunggu Eksternal." Mungkin Anda memerlukan kolom yang disebut "Dalam Tinjauan" karena langkah itu terus hilang. Biarkan papan berkembang sebagai respons terhadap apa yang diungkapkan pekerjaan nyata Anda, bukan sebagai respons terhadap apa yang dikatakan buku metodologi.

Permainan yang lebih lama: metrik aliran

Setelah sistem Kanban berjalan, ia menghasilkan data yang sebagian besar tim tidak pernah gunakan. Lead time — total waktu dari saat tugas dibuat sampai selesai — adalah yang paling penting. Jika rata-rata lead time Anda untuk tugas khas adalah dua belas hari, dan Anda menginginkannya lima, Anda sekarang memiliki angka untuk bekerja melawan dan papan yang akan menunjukkan kepada Anda di mana tujuh hari ekstra itu pergi.

Waktu siklus mengukur hanya periode kerja aktif, tidak termasuk waktu tugas duduk di backlog. Throughput mengukur berapa banyak item yang diselesaikan tim Anda per minggu. Tidak ada metrik ini memerlukan perangkat lunak khusus jika Anda disiplin tentang mencatat kapan kartu dibuat dan kapan ditutup. Dan bersama-sama, mereka memberi Anda gambaran yang jauh lebih jujur tentang kapasitas tim Anda daripada proses perencanaan berbasis perkiraan apa pun.

Sebagian besar tim kecil dan menengah tidak pernah sampai di sini. Mereka menggunakan Kanban sebagai alat visibilitas — yang bernilai dengan sendirinya — dan tidak pergi lebih jauh. Itu baik-baik saja. Tetapi jika Anda menemukan diri Anda ingin membuat komitmen kepada pemangku kepentingan tentang kapan sesuatu akan selesai, atau ingin memahami mengapa beberapa pekerjaan membutuhkan waktu tiga kali lebih lama dari yang diharapkan, metrik ada di sana ketika Anda membutuhkannya.