KANBAN NEDİR? WIP LİMİT, FLOW VE SÜREÇ TIKANIKLIKLARINI AÇMAK

Bir işin “devam ediyor”a düşmesi kolay, oradan çıkması ise çoğu ekipte şaşırtıcı derecede zor. Kanban, işi başlatmayı değil bitirmeyi merkeze alan yaklaşımıyla bu döngüyü kırar: akışı görünür kılar, kapasiteyi dengeler ve tıkanıklıkların üstünü örten sis perdesini dağıtır.

Bu yazıda Kanban’ın ne olduğuna, WIP limit mantığının neden sadece bir “kural” değil, akışın emniyet kemeri olduğuna; flow metrikleriyle performansın nasıl ölçülebileceğine ve süreç tıkanıklıklarının nasıl açılacağına odaklanacağız. Amaç, duvara bir pano asıp kart taşımaktan öte; sürdürülebilir bir teslimat ritmi kurmak.

İster yazılım geliştirme, ister pazarlama, ister operasyon olsun; işin doğası “talep” ve “kapasite” arasında gidip gelir. Kanban, bu iki kuvveti aynı resme koyar. Eğer ekibinizin teslimatı öngörülebilir kılmak ve beklemeleri azaltmak gibi bir hedefi varsa, temel çerçeveyi burada bulacaksınız. Detaylı uygulama ve pratik için Kanban eğitimi sayfasına da göz atabilirsiniz.

Kanban nedir ve neyi çözer?

Kanban, işi bir akış olarak ele alan görsel bir yönetim yöntemidir. “İşi gör” prensibi basit görünür; fakat asıl değer, işin hangi adımda beklediğini ve neden beklediğini görünür kılmasında yatar. Bu sayede ekip, “çok şey yapıyoruz” hissi yerine “doğru şeyi bitiriyoruz” disiplinine yaklaşır.

Kanban’ın çözdüğü tipik problemler:

• Çok sayıda paralel iş nedeniyle odak kaybı ve bitmeyen işler
• Beklemeler yüzünden uzayan teslim süreleri (lead time)
• Gizli kuyruklar, onay beklemeleri, bağımlılıklar ve belirsiz sorumluluklar
• “Acil” etiketinin her şeyi yutması ve planın sürekli bozulması

Çekme sistemi (pull) ile itme sistemi (push) farkı

Push yaklaşımında iş, “sıradaki kişiye” itilir; kişi hazır olsun olmasın. Pull yaklaşımında ise bir adım, ancak kapasitesi olduğunda yeni işi çeker. Pull mantığı, kuyrukları azaltır ve ekip içi hizalanmayı güçlendirir.

Görselleştirme: Pano sadece başlangıçtır

Kanban panosu, kolonlar ve kartlardan ibaret değildir; asıl hedef, süreçteki adımları ve karar noktalarını yalın biçimde temsil etmektir. “Geliştiriliyor” gibi tek bir kolon yerine “Analiz”, “Geliştirme”, “Kod İnceleme”, “Test”, “Yayına Hazır” gibi daha anlamlı duraklar, beklemeyi görünür hale getirir.

WIP limit nedir ve neden kritik?

WIP (Work In Progress) limit, bir adımda aynı anda kaç işin “devam ediyor” olabileceğini sınırlar. Bu sınır, üretkenliği düşürmez; aksine çoklu görev maliyetini azaltıp işleri hızla bitirmeyi teşvik eder. WIP limit, kapasiteye dayalı net bir sinyal verir: “Bu adım doluysa, yeni iş başlatma.”

WIP limitin etkisi iki yerde görünür: Birincisi, ekip davranışında. İnsanlar yeni işe koşmak yerine mevcut işi tamamlamak için yardımlaşma eğilimi gösterir. İkincisi, sistem davranışında. Limitler, darboğazların yerini ortaya çıkarır; sorunlar gizlenemez hale gelir.

WIP limit belirleme yaklaşımı

Başlangıç için mükemmel sayıyı bulmak yerine, ölçerek ilerlemek daha sağlıklıdır. Pratik bir yaklaşım:

1. Her adımda ortalama aynı anda kaç iş olduğunu gözlemle
2. Bu sayıyı küçük bir oranla azaltarak limit belirle
3. 2–3 hafta boyunca akış metriklerini izle
4. Bekleme ve blokajlar artıyorsa adım tasarımını veya kapasite dağılımını gözden geçir

WIP dolduğunda ne yapılır?

WIP dolduğunda “yapacak iş kalmadı” değil, “iyileştirme için fırsat var” mesajı ortaya çıkar. Tipik hamleler: blokaj çözmek, test yükünü paylaşmak, bağımlılığı kaldırmak, tanımı netleştirmek veya bir işi parçalara bölmek. Bu yaklaşım, teslimat ritmini korurken kaliteyi de destekler.

Flow nedir? Akışı ölçmeden iyileştirmek zor

Flow, işin sistem içinde hareket etme biçimidir: ne kadar iş giriyor, ne hızla tamamlanıyor, nerede bekliyor ve değişkenlik hangi noktada artıyor? Kanban’ın “akış yönetimi” vurgusu, ölçülebilir bir iyileştirme dili sunar. Böylece tartışmalar “hissettiğim kadarıyla” değil, metriklerin işaret ettiği yere doğru akar.

Lead time ve cycle time: teslimat süresinin iki yüzü

Lead time, bir işin talep edildiği andan teslim edildiği ana kadar geçen toplam süredir. Cycle time ise işin aktif çalışmaya alındığı andan tamamlandığı ana kadar geçen süreyi ifade eder. Eğer lead time uzun ama cycle time kısa ise genellikle kuyruklar ve beklemeler sorumludur.

Throughput ve WIP ilişkisi

Throughput, belirli bir zaman diliminde tamamlanan iş sayısıdır. WIP ile birlikte düşünüldüğünde sistemin dengesini anlatır. WIP artıp throughput aynı kalıyorsa, sistem sadece daha fazla iş biriktiriyor demektir. Burada Little’s Law gibi yaklaşımlar, kabaca öngörü üretmeye yardımcı olur; fakat asıl amaç, değişkenliği azaltıp tahmin edilebilirliği artırmaktır.

Süreç tıkanıklıklarını açmak: darboğazları görünür kılma

Tıkanıklık, işin bir adımda sistematik biçimde birikmesi ve bekleme sürelerinin artmasıdır. Kanban’da darboğazı “bulmak” çoğu zaman kolaydır; çünkü WIP limitler ve kuyruklar ipucu verir. Zor olan, tıkanıklığın nedenini doğru yerde aramaktır: kapasite mi, yetkinlik mi, bağımlılık mı, kalite sorunu mu, yoksa yanlış tasarlanmış bir akış mı?

Blokaj politikası ve “blocked” sinyali

Bir işin ilerleyemediği durumları saklamak, sistemin kendini düzeltmesini engeller. Blokajları ayrı bir işaretleme ile görünür kılmak, çözüme odaklanmayı hızlandırır. Blokaj politikasında “ne zaman blocked sayılır, kim bilgilendirilir, maksimum bekleme süresi nedir” gibi net kurallar, ekip içi sürtüşmeyi azaltır.

Tıkanıklık için kök neden çalışması

Tıkanıklığı açmak, sadece bir kolonun limitini artırmak değildir. Çoğu zaman bu, sorunu büyütür. Daha etkili bir yaklaşım, tekrar eden beklemeleri sınıflandırmak ve kök neden üzerinde çalışmaktır: onay süreçleri, gereksinim belirsizliği, test otomasyonu eksikliği, dış bağımlılıklar veya öncelik karmaşası gibi.

// Örnek: Basit bir Kanban akış konfigürasyonu (kolonlar, WIP limitleri, blokaj kuralı)
const board = {
  columns: [
    { name: "Backlog", wipLimit: null },
    { name: "Analiz", wipLimit: 4 },
    { name: "Geliştirme", wipLimit: 6 },
    { name: "Kod Inceleme", wipLimit: 3 },
    { name: "Test", wipLimit: 4 },
    { name: "Tamamlandi", wipLimit: null }
  ],
  policies: {
    blockedDefinition: "24 saatten uzun bekleyen veya dis bagimliligi olan is",
    expediteClass: "Sadece 1 adet; WIP limitlerin disina ciksa bile gorunur"
  }
};

Politikalar, hizmet sınıfları ve öncelik yönetimi

Kanban’da “politikalar” görünmez kararları görünür hale getirir. Bir işin hangi koşullarda bir kolondan diğerine geçeceği, neyin “hazır” sayıldığı, kalite kapıları, onay adımları ve kabul kriterleri netleştiğinde akış hızlanır. Burada amaç katı bürokrasi değil; belirsizliği azaltan netlik üretmektir.

Definition of Done ve giriş/çıkış kriterleri

Her adım için giriş/çıkış kriterleri belirlemek, özellikle “yarım iş” kaynaklı geri dönüşleri azaltır. Örneğin “Test” kolonuna geçiş için minimum otomasyon koşulu veya “Yayına Hazır” için performans kontrolü gibi kriterler, kaliteyi akışın doğal parçası yapar.

Hizmet sınıfları: her iş aynı değil

Her talep aynı aciliyette değildir. Hizmet sınıfları (ör. standart, hızlandırılmış, sabit tarihliler, risk azaltıcılar) iş türlerine farklı akış politikaları tanımlar. Örneğin hızlandırılmış işlerde sınırlı sayıda istisna tanımak, sistemi “acil kültürü”ne teslim etmeden kritik ihtiyaçları karşılamayı sağlar.

Ritüeller ve sürekli iyileştirme: Kanban cadences

Kanban, ritimlerle güçlenir. Günlük senkron, replenishment (yeni iş seçimi), delivery planning ve service delivery review gibi cadences, sistemi düzenli olarak kalibre eder. Bu toplantılar “rapor verme” değil; akışı korumaya ve iyileştirmeye yönelik karar noktalarıdır.

Replenishment: doğru işi doğru zamanda çekmek

Backlog’un dolu olması, sistemin sağlıklı olduğu anlamına gelmez. Replenishment, sıraya girecek işin boyutunu, belirsizliğini ve bağımlılıklarını kontrol ederek akışa uygun bir paket oluşturur. Böylece “başladık ama takıldık” döngüleri azalır.

Service delivery review: akış metrikleriyle gerçeklik kontrolü

Belirli aralıklarla lead time dağılımı, throughput trendi ve blokaj nedenleri gözden geçirilir. Amaç, tekil olaylara tepki vermek yerine sistemin davranışını anlamaktır. Bu yaklaşım, ekip içinde güven üretir; çünkü teslimat vaadi, ölçülen kapasite ve değişkenlik üzerine kurulur.

// Örnek: Cycle time hesaplama (aktif çalışmaya alınan tarihten tamamlanana kadar gün)
function daysBetween(a, b) {
  const ms = Math.abs(new Date(b) - new Date(a));
  return Math.ceil(ms / (1000 * 60 * 60 * 24));
}

const item = { startedAt: "2026-01-10", doneAt: "2026-01-16" };
const cycleTimeDays = daysBetween(item.startedAt, item.doneAt);

console.log("Cycle time (gun):", cycleTimeDays);

Kanban panosu tasarımı: kolonlar, swimlane’ler ve blokaj alanları

Pano tasarımı, sistemin aynasıdır. Çok fazla kolon, karar vermeyi zorlaştırır; çok az kolon ise beklemeyi gizler. Dengeli bir tasarım, işin doğal adımlarını temsil eder ve en sık tıkanan bölgeleri özellikle görünür kılar.

Swimlane ile iş türlerini ayırma

Swimlane’ler, farklı hizmet sınıflarını veya iş türlerini ayrıştırmak için kullanılır. Örneğin “operasyonel iş”, “ürün geliştirme” ve “teknik borç” gibi ayrımlar, öncelik çatışmalarını netleştirir. Böylece tek bir sırada her şeyin birbirini ezmesi yerine, akış politikaları korunur.

Blokaj alanı ve yaşlanan işler

Uzayan işler (aging work items) genellikle risk sinyalidir. Panoda yaşlanan işleri işaretlemek, “bitirmeye yakın” varsayılan işlerin aslında ne kadar zamandır sistemde olduğunu görünür kılar. Bu görünürlük, tıkanıklıklar büyümeden müdahale şansı yaratır.

Sık yapılan hatalar ve pratik öneriler

Kanban’ın gücü, basitliğinde gizlidir; fakat bu basitlik, yanlış uygulandığında hayal kırıklığına dönüşebilir. En yaygın tuzak, Kanban’ı “kart taşıma” aktiviteleriyle sınırlamaktır. Oysa Kanban, karar verme biçimini ve işin akışını dönüştürür.

• WIP limiti koyup ihlal etmek: Limitlerin “gerçek” olmadığı sistemlerde davranış değişmez.
• Kolonları insanlara göre düzenlemek: Akış adımları yerine rol bazlı tasarım kuyrukları artırır.
• Her şeyi “acil” yapmak: İstisna çoğalırsa sistem standart hale gelir ve öngörü kaybolur.
• Ölçmeden iyileştirmek: Flow metrikleri olmadan yapılan değişiklikler sonuç üretmeyebilir.

Başlangıç için küçük, sürdürülebilir adımlar

İlk günden mükemmel pano beklemek yerine, en kritik akış adımlarını çıkarıp basit bir yapı kurmak daha etkilidir. Ardından WIP limitleriyle sistemi “nazikçe” sıkıştırmak, tıkanıklıkları açmak için gerekli gerçekliği üretir. İyileştirmeleri küçük iterasyonlarla yapmak, ekipte direnç yerine katılım yaratır.

Sonuç: Daha hızlı değil, daha akıcı teslimat

Kanban’ın vaadi sadece hız değildir; akış ve öngörü üretmektir. WIP limitleriyle kapasiteyi koruyan, flow metrikleriyle gerçeği izleyen ve tıkanıklıkları sistematik biçimde açan ekipler, daha sakin bir tempoda daha güvenilir teslimat yapar. Eğer bir sonraki adım olarak uygulamayı derinleştirmek isterseniz, pratik vaka ve atölye kurguları için Kanban eğitimi içeriği iyi bir başlangıç noktası olabilir.