Kolom sebagai Status

Papan kanban membuat pekerjaan terlihat. Setiap bagian pekerjaan adalah kartu. Kartu bergerak dari kiri ke kanan melalui kolom yang mewakili status.

Kolom klasik adalah: Backlog → Selected → In Progress → Review → Done

Tetapi kolom yang tepat tidak penting. Yang penting adalah setiap kartu memiliki tepat satu status saat ini, & status itu terlihat oleh semua orang yang bekerja dalam sistem itu.

Apa yang diwakili kartu

Kartu mewakili unit pekerjaan yang dapat diselesaikan secara independen. Bukan proyek. Bukan tujuan. Sesuatu yang spesifik & terbatas dengan definisi penyelesaian yang jelas.

Kartu baik: Putar kunci SSH di server prod: selesai ketika semua server menunjukkan kunci baru dalam authorized_keys & kunci lama dihapus.

Kartu buruk: Tingkatkan keamanan. (Ini adalah proyek, bukan tugas. Pecah menjadi bagian-bagian.)

Batas WIP

Kolom In Progress dalam diagram menunjukkan batas WIP: 3. Ini berarti tidak lebih dari tiga kartu dapat In Progress pada waktu yang sama. Jika Anda ingin menarik kartu keempat, Anda harus menyelesaikan satu terlebih dahulu.

Ini terasa seperti kendala. Memang: dirancang demikian. Batas WIP memaksa Anda menyelesaikan apa yang Anda mulai sebelum memulai sesuatu yang baru. Lebih lanjut tentang mengapa hal ini penting di bagian selanjutnya.

Menjangkauan Kartu Pekerjaan

Keterampilan paling sulit dalam kanban bukan menggambar papan. Ini tentang menjangkauan kartu. Terlalu besar & kartu duduk In Progress selama berminggu-minggu, memblokir pekerjaan lain. Terlalu kecil & papan penuh dengan kebisingan.

Silo Bekerja Dengan Baik

Setiap operasi multi-disiplin memiliki pusat kerja fungsional: toko roti memiliki pastry, roti, savory, & counter depan. Studio produk memiliki desain, konten, build, & ops. Proyek konstruksi memiliki framing, pipa ledeng, listrik, & finishing. Pusat-pusat ini ada karena alasan bagus: spesialisasi mendalam memerlukan kepemilikan yang fokus.

Kanban tidak melarutkan divisi-divisi ini. Itu membuat handoff di antara mereka terlihat & eksplisit.

Kartu handoff

Ketika unit pekerjaan bergerak dari satu pusat kerja ke pusat kerja lain, katakanlah aset desain yang membutuhkan salinan tertulis sebelum builder dapat merakit halaman, kartu handoff bepergian bersama dengannya. Pusat hilir melihat kartu muncul di Backlog mereka. Mereka menariknya ketika mereka memiliki kapasitas. Tidak ada email yang diperlukan. Tidak ada pertemuan untuk mengkoordinasikan. Kartu adalah sinyal.

Apa yang ditunjukkan diagram

Tiket ★ dimulai di Design (In Progress: visual assets). Ketika Design menyelesaikan bagian mereka, kartu handoff dibuat & tiket ★ muncul di Backlog pusat Build. Build menariknya. Kemudian Ops menariknya. Setiap pusat memiliki papan sendiri. Setiap papan menunjukkan hanya pekerjaan saat ini pusat itu. Tetapi ★ bepergian melalui semuanya, & semua orang dapat melihat di mana itu.

Ini adalah wawasan supermarket yang diterapkan pada organisasi: setiap pusat kerja adalah rak. Kartu mengisi kembali rak hilir hanya ketika pekerjaan hulu ditarik & dikonsumsi.

Merancang Handoff

Kartu handoff adalah kontrak antara pusat kerja. Itu harus berisi cukup konteks agar tim penerima dapat bertindak tanpa pertemuan.

Berhenti Mulai. Mulai Selesaikan.

WIP singkatan dari Work In Progress. Batas WIP adalah topi pada berapa banyak kartu yang dapat berada di kolom tertentu pada waktu yang sama.

Ini terdengar seperti pembatasan. Memang. Itu intinya.

Mengapa batas membantu

Setiap kali Anda memulai tugas baru tanpa menyelesaikan yang sebelumnya, Anda membayar pajak penggantian konteks. Otak Anda memuat konteks tugas baru & sebagian membongkar yang lama. Ketika Anda kembali ke tugas lama, Anda memuat ulangnya. Untuk pekerjaan pengetahuan, menulis, debugging, merancang, meninjau, biaya reload ini diukur dalam jam, bukan detik.

Batas WIP mencegah akumulasi pekerjaan setengah selesai. Mereka juga melakukan sesuatu yang lebih berharga: mereka mengungkapkan hambatan.

Hambatan menjadi terlihat

Jika kolom Review memiliki batas WIP 2 & selalu pada 2, itu adalah sinyal: review lebih lambat dari produksi. Lebih banyak pekerjaan selesai In Progress daripada yang dapat dikonsumsi oleh Review. Tanpa batas WIP, papan penuh dengan kartu 'selesai-tetapi-menunggu-review' & hambatan tidak terlihat. Dengan batas WIP, kolom In Progress tidak dapat menerima kartu baru, & seluruh tim melihat kendala.

Ini bukan kegagalan. Ini adalah informasi. Sistem memberi tahu Anda untuk memperbaiki Review, mempekerjakan, memasangkan, mengurangi ukuran batch, daripada membabi-buta mendorong lebih banyak pekerjaan melalui.

Hukum Little (secara informal)

Lead time (berapa lama kartu memakan waktu dari awal hingga selesai) = Work In Progress ÷ Throughput (kartu selesai per unit waktu). Jika Anda ingin waktu lead yang lebih pendek tanpa mempekerjakan, kurangi WIP. Lebih sedikit hal dalam penerbangan berarti setiap hal selesai lebih cepat.

R = (W × C) + T

Batas WIP melindungi tiga variabel. Konsultan efisiensi Brian Tracy menamainya pada 1986.

R = (W × C) + T

- R: Hasil: hasil yang Anda inginkan

- W: Kejelasan tujuan: seberapa tepat Anda mengetahui apa yang Anda inginkan (0–10)

- C: Konsentrasi: intensitas upaya fokus (0–10)

- T: Waktu bekerja tanpa gangguan (jam tanpa gangguan)

Mengapa W & C mengalikan

Kejelasan & konsentrasi tidak independen. Konsentrasi tinggi pada tujuan yang tidak jelas menghasilkan gerakan cepat dalam arah yang salah. Kejelasan tujuan sempurna tanpa konsentrasi menghasilkan apa pun. Mereka berinteraksi: itulah mengapa Tracy menulisnya sebagai produk, bukan jumlah. 9/10 pada setiap memberikan R = 81 + T. 3/10 pada setiap memberikan R = 9 + T. Perbedaannya tidak aditif.

Mengapa T menambah

Setiap jam bebas gangguan menambah hasil secara linear. T tidak dapat menggandakan W & C: itu hanya dapat bertumpuk di atas produk. Ini menjelaskan mengapa langkah pertama selalu meningkatkan W & C, bukan bekerja lebih lama. Lebih banyak T pada produk (W × C) rendah masih hasil yang buruk.

Apa yang dilakukan papan kanban untuk setiap variabel

- W: Kartu terbatas dengan baik (judul jelas, kriteria penerimaan terukur, pemilik tunggal) menaikkan W sebelum pekerjaan dimulai. Kartu yang tidak jelas menurunkannya secara otomatis.

- C: Batas WIP memaksa konsentrasi. Satu kartu dalam Aktif berarti perhatian penuh pada satu masalah. Tiga kartu dalam Aktif berarti C dibagi tiga cara.

- T: Blok Pomodoro & perlindungan kalender menciptakan jam bebas gangguan yang T ukur. Timer papan bukan dekorasi: itu melacak T secara real time.

Tracy mengklaim masalah apa pun dapat diselesaikan dalam 30 menit ketika W, C, & T semuanya dioptimalkan. Papan kanban adalah instrumen untuk mengoptimalkan ketiga-tiganya secara bersamaan.

Membaca Papan

Praktik membaca hambatan dari status papan.

Bukan Agile. Bukan Waterfall.

Agile adalah metodologi. Waterfall adalah metodologi. Kanban adalah sistem.

Metodologi menentukan cara Anda bekerja. Sistem menjelaskan apa yang benar tentang pekerjaan. Kanban tidak memberitahu Anda untuk memiliki sprint dua minggu, daily standup, atau retrospektif. Itu memberitahu Anda satu hal: buat pekerjaan terlihat, batasi WIP, & tarik.

Masalah dengan metodologi

Agile bekerja baik untuk tim yang membangun produk secara iteratif, perangkat lunak, sebagian besar. Waterfall bekerja baik untuk proyek dengan persyaratan tetap & unknowns yang dikenal, konstruksi, manufaktur perangkat keras. Tidak satupun memetakan dengan bersih ke pekerjaan lintas-disiplin di mana tugas desain & tugas pemenuhan memiliki waktu siklus yang sepenuhnya berbeda & definisi 'selesai.'

Memaksa pusat desain & pusat ops ke ritme sprint yang sama adalah kesalahan kategori. Sprint dua minggu yang berfungsi untuk pembuatan konten menghasilkan urgensi buatan dalam pekerjaan logistik. Ritual standup yang dibangun untuk tim yang berlokasi bersama menciptakan overhead untuk solos independen.

Menemukan kesamaan pada pekerjaan yang harus dilakukan

Pendekatan un: temukan pekerjaan yang perlu dilakukan. Temukan orang atau mitra yang paling baik ditempatkan untuk melakukannya. Jangan menerapkan proses di atas itu: biarkan pekerjaan mengungkapkan proses aturannya sendiri melalui sistem visibilitas bersama.

Ini bukan ketiadaan proses. Ini adalah jumlah proses yang tepat: cukup untuk mengkoordinasikan, tidak cukup untuk menciptakan overhead koordinasi yang melebihi nilai pekerjaan.

Jangan bangun apa yang bisa Anda beli. Jangan beli apa yang bisa Anda tumbuhkan.

Sebelum kartu kerja apa pun dibuat, tanyakan: haruskah ini ada sama sekali? Setiap bagian pekerjaan yang Anda bangun, Anda memilikinya selamanya. Setiap SaaS yang Anda berlangganan, Anda bergantung selamanya. Setiap dependensi sumber terbuka yang Anda fork, Anda mempertahankan selamanya.

Pohon keputusan: Bisakah kami mengembangkan ini? Proses, keterampilan, hubungan yang menghasilkan kemampuan secara berkelanjutan, sukai ini. Jika pertumbuhan tidak layak: Bisakah kami membeli ini? Alat siap pakai yang menyelesaikan 80% masalah tanpa pekerjaan kustom, sukai ini. Jika membeli tidak layak: Bangunnya. & bangunnya mengetahui Anda sekarang memilikinya.

Sebagian besar organisasi membalikkan urutan ini. Mereka membangun infrastruktur kustom untuk masalah yang alat komoditas selesaikan dengan baik, lalu membabi buta mempertahankan apa yang mereka bangun. Kanban membuat ini terlihat: setiap kartu di Backlog Anda adalah sesuatu yang Anda pilih untuk dibangun. Pertanyaan jujur adalah apakah itu harus ada sama sekali.

Bangun / Beli / Tumbuhkan

Terapkan kerangka keputusan.

Desain Papan

Satukan. Anda akan merancang sistem kanban untuk skenario lintas fungsi tertentu.

Skenario

Studio kecil meluncurkan kembali produk mereka dengan merek baru. Pekerjaan melibatkan empat pusat:

- Design: logo baru, identitas visual, fotografi produk, tata letak halaman

- Content: deskripsi produk yang ditulis ulang, teks halaman landing, pengumuman email

- Build: situs web yang diperbarui, alur checkout baru, pengalihan dari URL lama

- Ops: pengaturan pemroses pembayaran yang diperbarui, briefing mitra pemenuhan, rekonfigurasi analytics

Peluncuran kembali memiliki tenggat waktu yang ketat: pameran perdagangan dalam 45 hari di mana merek baru menjadi publik.

Solos Tetap Silo

Di sebagian besar organisasi, kanban ada untuk membuat pekerjaan terlihat di seluruh hierarki manajemen. Manajer mengkoordinasikan antara silo. Kanban mengurangi overhead koordinasi.

Dalam model un, tidak ada manajer. Ada solos. Solo mengoperasikan perusahaan secara independen: solo desainer, solo builder, solo penulis, solo ops. Setiap solo, menurut definisi, adalah silo. Tidak ada org chart yang menghubungkan mereka. Tidak ada hubungan pelaporan. Tidak ada manajer untuk memaksa koordinasi.

Kanban menjadi lapisan koordinasi. Bukan dengan meratakan silo, solos tetap sepenuhnya independen, tetapi dengan membuat handoff antara mereka terlihat & eksplisit. Solo tidak mengirim email atau menjadwalkan pertemuan untuk menyerahkan pekerjaan. Mereka meletakkan kartu di papan bersama. Solo penerima menariknya ketika mereka memiliki kapasitas.

Ini menjelaskan mengapa kanban sesuai dengan model un lebih baik daripada agile atau waterfall: itu tidak memerlukan ritme bersama, tidak ada retros gabungan, tidak ada perencanaan tersinkronisasi. Setiap solo menetapkan batas WIP mereka sendiri, waktu siklus mereka sendiri, definisi penyelesaian mereka sendiri. Koordinasi terjadi di tingkat kartu, bukan tingkat proses.