Kanban'da Sık Yapılan Hatalar: Sahte WIP Sınırları, Yanlış Yorumlanan Metrikler ve Akışı Bozan Gizli Alışkanlıklar

Kanban'da En Sık Görülen Dört Tuzak

Kanban basit görünür ama yanlış uygulandığında ekip 'Kanban yapıyoruz' derken aslında eski itme sistemini panoya taşımış olur. Bu derste dört sinsi hatayı ve bunları nasıl fark edeceğinizi öğreneceksiniz.

Hata 1: Sahte WIP Sınırı — Kartı İkiye Bölme

Senaryo: 'Geliştirme' sütununun WIP sınırı 4 ve sütun dolu. Yeni bir acil iş geldiğinde ekip üyesi şunu yapar: mevcut kartlardan birini 'Geliştirme-1' ve 'Geliştirme-2' olarak ikiye böler, böylece sütunda '5 kart' değil '4+bir alt kart' görünür ve yeni işi sığdırır. Sayı kuralına uyulmuş gibi görünür ama gerçek devam eden iş miktarı artmıştır.

• Neden tehlikeli: WIP sınırının amacı bağlam değiştirmeyi (context switching) azaltmaktır; kart bölünse de kişinin zihninde iki iş birden döner.
• Nasıl fark edilir: Bir kartın son 2 haftada kaç kez alt parçaya bölündüğünü sayın. Sık bölünme, sınırın gerçekte ihlal edildiğinin işaretidir.
• Doğru yaklaşım: WIP sınırı doluyken yeni iş gelirse, ekip önce 'hangi mevcut işi bitirip çıkaracağız' sorusunu sormalı — kartı bölmek değil, gerçek bir işi tamamlamak veya bekletmek gerekir.

Hata 2: Ortalama Döngü Süresinin Yanıltması

Senaryo: Bir ekip son 20 iş kaleminin döngü süresi ortalamasının 3 gün olduğunu raporluyor ve 'akışımız iyi' diye düşünüyor. Ama bu 20 işin 17'si 1-2 gün sürmüş, 3'ü ise 15-20 gün sürmüş (uzun süre bloke kalmış). Ortalama bu uç değerleri gizler.

Doğru alışkanlık: Ortalama yerine döngü süresi dağılımını (histogram veya scatter plot) inceleyin. Uzun kuyruktaki (outlier) her kart için 'neden bu kadar sürdü' sorusunu ayrı ayrı sorun.

Hata 3: Her İşin 'Acil' Etiketiyle Girmesi

Senaryo: Hizmet sınıfları tanımlanmış (Standart, Sabit Tarihli, Acil, Beklemede) ama 3 ay içinde panodaki işlerin büyük çoğunluğu 'Acil' etiketiyle girmeye başlamış. Herkes kendi işini öncelikli görmek istediği için etiket anlamını yitirmiş.

• Belirti: Acil sınıfının kullanım oranı sürekli artıyor, Standart sınıf neredeyse boş kalmış.
• Kök neden: Genelde 'Acil' etiketi koymanın bir maliyeti/onayı yok; herkes kendi kendine karar veriyor.
• Çözüm: Her hizmet sınıfına net giriş kriteri ve bir onay adımı koyun (ör. 'Acil' sadece ürün sahibi onayıyla girer) ve panoda sınıf başına kota belirleyin (ör. aynı anda en fazla 1 acil iş).

Hata 4: Günlük Toplantının Durum Raporuna Dönüşmesi

Senaryo: Günlük Kanban toplantısında herkes sırayla 'ben dün şunu yaptım, bugün şunu yapacağım' diyor — tıpkı klasik statü toplantısı gibi. Ama kimse panodaki tıkanan kartlara, WIP sınırı aşımlarına veya bloke işaretli kartlara bakmıyor.

Doğru format: Toplantı kişi kişi değil, kart kart ilerlemeli — sağdan sola, bitmeye en yakın işten başlanarak. Her kartta sorulacak tek soru: 'Bu kartı bir sonraki sütuna taşımak için bugün ne engelliyor?' Bu basit değişiklik toplantıyı statü raporundan akış yönetimine çevirir.

Gerçekten İyileşiyor Muyuz? Bakılması Gereken Üç Gösterge

Yanlış İnanış: 'Her Darboğaz Kötüdür'

Aslında sistemde her zaman bir darboğaz vardır — Kısıtlar Teorisi'nin de söylediği gibi, darboğazın kendisi sorun değildir; sorun onu görmezden gelmek veya rastgele başka yerlere kaynak aktarmaktır. Amaç darboğazı yok etmek değil, onu bilinçli şekilde yönetmek ve akışın geri kalanını ona göre ayarlamaktır.

Üst Seviyeye Taşıyan İpucu

Metrikleri asla kişi veya ekip performansını yargılamak için kullanmayın (ör. 'Ahmet'in döngü süresi uzun, yavaş çalışıyor'). Metrikler sistemi konuşmak içindir: 'Bu sütunda neden birikme oluyor', 'bu hizmet sınıfı neden bu kadar sık kullanılıyor'. Metrik kişiselleştirildiği an ekip verileri gizlemeye, kartları manipüle etmeye başlar — tam da bu derste anlatılan hataların kök nedeni budur.