Kanban Nedir? Toyota'dan Yazılıma ve Board'dan Fazlası

Sürüm notu: Bu yazı The Kanban Guide'ın 2025.5 sürümünü (ProKanban.org, Mayıs 2025) esas alır; Kanban Method için Kanban University'nin resmi rehberine bakılmıştır.

Önce Tahmin Et

Bookstore'da beş kişilik bir ekip var: iki .NET geliştirici, bir Angular geliştirici, bir full-stack geliştirici ve bir tester. Ekibin işi iki parçalı. Bir yanda küçük feature'lar (wishlist paylaşımı, yayınevi filtresi), öbür yanda hiç bitmeyen destek işi: iade talepleri, yanlış içeri alınmış kitap fiyatları, "kartla ödeme çalışmıyor" alarmları. Ekip iki haftalık Sprint'lerle çalışmayı denemiş, ama Sprint'in üçüncü gününde gelen acil bir iade hatası planı her seferinde bozmuş.

Takım lideri bir pazartesi sabahı Jira'da yeni bir board açıyor: To Do, In Progress, Done. Sprint yok, kartlar sağa doğru akıyor. Herkes rahatlıyor. "Artık Kanban yapıyoruz" diyorlar.

Üç soru: Bu ekip gerçekten Kanban mı yapıyor? Board'u açmak ile Kanban'a geçmek arasındaki fark nedir? Bir de şunu düşün: altı hafta sonra In Progress kolonunda 14 kart birikmişse, bunun sebebi board mu, yoksa board'un söylemediği bir şey mi?

Toyota'dan Gelen Fikir: Kart, Pull ve Süpermarket

"Kanban" Japoncada kabaca "görsel kart, tabela" demek. Fikir, Taiichi Ohno'nun 1950'lerde Toyota'nın üretim hattında geliştirdiği ve sonradan TPS (Toyota Production System) diye anılan sistemin bir parçası. Ohno'nun çözmek istediği sorun stoktu: her istasyon elinden geldiğince çok parça üretip bir sonrakine itiyordu ve hattın arasında devasa ara stoklar birikiyordu. Bu stok hem para bağlıyordu hem de hataları saklıyordu; hatalı bir parça fark edildiğinde arkasında yüzlercesi üretilmiş oluyordu.

Çözüm üretimi tersinden düşünmekti. Bir istasyon, bir sonraki istasyon ondan parça "çektiğinde" üretir. Çekme sinyali de kanban kartıdır: bir kutu parça tükendiğinde kutunun üzerindeki kart önceki istasyona geri döner ve "bundan bir kutu daha üret" der. Dolaşımdaki kart sayısı sınırlı olduğu için hattın arasındaki stok da sınırlıdır. Ohno'nun ilham kaynağı olarak anlattığı süpermarket rafı da aynı mantıkla çalışır: raf boşaldıkça doldurulur, kimse "belki alırlar" diye rafın önüne ürün yığmaz.

Bu hikâyeden yazılıma taşınan iki fikir var. Birincisi push yerine pull: iş, birisi elindekini bitirip kapasite açıldığında çekilir. İkincisi sınırlı ara stok: yazılımda buna WIP (Work in Progress, başlanmış ama bitmemiş iş) denir ve WIP'in sınırlanması Kanban'ın kalbidir. Kartın kendisi, yani duvardaki post-it, hikâyenin en önemsiz kısmıdır.

Yazılıma Geçiş: Microsoft, Corbis ve David Anderson

Kanban'ın yazılım ekiplerine taşınması büyük ölçüde David J. Anderson'ın adıyla anılır. Anderson 2004'te Microsoft'ta, bakım işleri yapan ve sürekli geç kalan bir sustaining engineering ekibinde pull sistemini ve WIP sınırını denedi; ekip board bile kullanmadan teslim süresini belirgin biçimde kısalttı. 2006–2007'de Seattle'daki Corbis'te bu fikir bugün tanıdığımız fiziksel board'la, kolonlarla ve kolon bazında WIP limit'leriyle birleşti. The Kanban Guide da bilgi işinde bugün Kanban denen pratiklerin Corbis'teki bir ekipte, 2006'da ortaya çıktığını yazar. Anderson bu deneyimi 2010'da "Kanban: Successful Evolutionary Change for Your Technology Business" kitabında topladı.

Bu tarihçe önemli, çünkü sana Kanban'ın neden "board'la başlayan" bir şey olmadığını gösteriyor. Microsoft'taki ilk denemede board yoktu; WIP sınırı ve pull vardı. Board sonradan, sistemi görünür kılmak için geldi.

Bugün İki Kanban Var: Kanban Method ve The Kanban Guide

"Kanban" dediğinde bugün iki farklı topluluğun iki farklı tarifinden birini kastediyor olabilirsin. İkisini de bilmek, okuduğun bir blog yazısının veya aldığın bir eğitimin hangi koldan konuştuğunu anlamanı sağlar.

Kanban Method, Kanban University'nin resmi rehberinde bir "yöntem" ya da framework değil, mevcut çalışma biçiminin üzerine uygulanan bir yönetim yaklaşımı olarak tanımlanır. Change management tarafında "bugün ne yapıyorsan oradan başla, kademeli ve evrimsel değiş, her seviyede liderliği teşvik et" der. Service delivery tarafında müşterinin ihtiyacına odaklanmayı, insanları değil işi yönetmeyi ve servis ağını düzenli gözden geçirmeyi ister. Altı genel pratiği şunlardır: visualize, limit WIP, manage flow, make policies explicit, implement feedback loops, improve collaboratively/evolve experimentally.

The Kanban Guide ise 2020'de ProKanban.org tarafından yayımlandı (önce 2020.7, sonra 2020.12) ve Mayıs 2025'te 2025.5 sürümüyle güncellendi. Kısa olması bilinçli bir tercih: yalnız minimumu söyler, gerisini ekibe bırakır. Bu serinin omurgası Guide; ama Kanban Method'un cadence'leri ve servis bakışı 06. yazıda yeri gelince karşına çıkacak. İki koldan birini "asıl Kanban" ilan etmek yerine şöyle düşün: Guide sana flow'u ölçen ve yöneten kemik yapıyı verir, Method bu yapıyı bir organizasyona yerleştirirken nasıl değişim yöneteceğini anlatır.

Kanban Guide'ın Tanımı: Flow, Value ve Üç Pratik

Guide Kanban'ı bir süreç içinden value akışını optimize eden bir strateji olarak tanımlar. Bu cümlede üç kavram var ve üçü de seri boyunca sürekli karşına çıkacak.

Flow, potansiyel value'nun sistemin içinden hareketidir. Bookstore için bir work item'ın, Fix VAT rounding on invoice PDF diye açılan bir bug kaydının, geliştirmeye alınıp production'a çıkana kadar geçtiği yol bir flow'dur. Value ise bu işin müşteriye ya da şirkete sağladığı faydadır; Guide value'yu ekibin bağlamına göre tanımlanacak bir şey olarak bırakır. Guide'a göre iyi flow üç hedefi dengeler: effectiveness (paydaşın istediğini istediği zaman teslim etmek), efficiency (kaynakları iyi kullanmak) ve predictability (makul bir belirsizlikle ne zaman teslim edeceğini söyleyebilmek).

Guide Kanban'ın teorik dayanağı olarak systems thinking, lean prensipleri, queueing theory, variation (değişkenlik) ve kalite kontrolünü sayar. Uygulama tarafı ise birlikte çalışan üç pratikten oluşur:

• Workflow'u tanımlamak ve görselleştirmek: ekibin Definition of Workflow'unu (DoW) açık hâle getirip bir Kanban board'da göstermek.
• Item'ları aktif olarak yönetmek: WIP'i kontrol etmek, item'ların gereksiz yere yaşlanmasını önlemek, tıkanan işi açmak.
• Workflow'u iyileştirmek: sistemi sürekli incelemek ve gerektiğinde DoW'u değiştirmek, bunun için resmî bir toplantıyı beklememek.

Bu üç pratik dört flow metric'le ölçülür: WIP, Throughput, Work Item Age ve Cycle Time. Guide bu dördünü minimum kabul eder; ekip adlarını değiştirebilir (Cycle Time'a "flow time" demek gibi), ama Guide'ın tarif ettiği şekilde kullanmak zorundadır. Bu metric'leri 04. yazıda bir CSV (Comma-Separated Values) export'undan C# ile kendimiz hesaplayacağız.

2025.5 sürümü 2020.12'ye göre birkaç şeyi değiştirdi ve Guide'ın sayfası bunları kendisi listeliyor: temel terimler için bir "conventions" bölümü eklendi, SLE (Service Level Expectation) DoW bölümünün içine taşındı, WIP kontrolü daha az kuralcı hâle getirildi (illa kolon başına sayı yazmak zorunlu değil), birden fazla DoW ve variation konusu netleştirildi, "Kanban Measures" başlığı "Flow Metrics" oldu ve Guide'ın değiştirilemez olduğuna dair ifade kaldırıldı.

Kanban Board ≠ Kanban

Şimdi baştaki soruya dönelim. To Do, In Progress, Done kolonlarından oluşan bir board, Guide'ın diliyle yalnız bir görselleştirmedir. Board'un Kanban olması için arkasında bir DoW olması gerekir ve Guide'a göre DoW en az şunları içerir: work item'ın ne olduğu, işin ne zaman başlamış ve ne zaman bitmiş sayılacağı, bu iki nokta arasındaki state'ler, WIP'in nasıl kontrol edileceği, item'ların state'ler arasında nasıl hareket edeceğini söyleyen explicit policy'ler ve bir SLE.

Bookstore ekibinin board'unda bunlardan hiçbiri yok. "In Progress" kolonuna kaç kart girebileceği belli değil, yani WIP kontrol edilmiyor. Bir kartın ne zaman Done sayılacağı belli değil: merge olunca mı, test ortamına çıkınca mı, production'a deploy edilince mi? Dolayısıyla altı hafta sonra In Progress'te biriken 14 kart board'un suçu değil; board yalnızca olanı gösteriyor. Sorun, ekibin bir sınır koymamış olması ve herkesin elindeki iş beklemeye düşünce yeni bir işe başlaması.

WIP kontrolü olmadan board bir pull sistemi değil, bir push sistemidir: iş, kapasite açıldığı için değil, birisi istediği için başlar. Guide'ın deyişiyle WIP'i kontrol etmek bir pull sistemi yaratır; yeni iş ancak açık bir kapasite sinyali olduğunda başlar. Bu sinyal tam olarak Ohno'nun kartıdır. 03. yazıda bunun neden cycle time'ı kısalttığını Little's Law ve küçük bir simülasyonla göreceğiz.

Bookstore Destek Ekibi: Sprint'e Sığmayan İş

Peki bu ekip Scrum'ı neden bıraktı ve bıraktığında ne kaybetti? Ekibe haftada ortalama yedi sekiz iş geliyor, bunların üçte biri aynı gün bakılması gereken destek talepleri. Scrum serisinin Sprint Planning yazısında anlatıldığı gibi Sprint, bir Sprint Goal etrafında planlanmış bir taahhüttür. Gelen işin büyük kısmı önceden bilinmiyorsa Sprint Goal her hafta bozulur ve ekip ya Sprint'i sürekli yeniden planlar ya da "acil işler için %30 boşluk" gibi tahminlere sığınır.

Kanban bu ekibe Sprint yerine sürekli bir akış önerir: iş geldikçe Ready kolonuna girer, bir geliştirici elindekini bitirince en üstteki işi çeker. Ama bunun karşılığında ekibin kendine üç disiplin yüklemesi gerekir. Kaç işi aynı anda yürüteceğine bir sınır koymak, işin başlangıç ve bitiş noktalarını tanımlamak ve "ne zaman biter" sorusuna tahminle değil veriyle cevap vermek. Scrum'ın Sprint sınırının sağladığı ritmi Kanban'da WIP sınırı ve flow metric'leri sağlar. Bu disiplinler olmadan ekip Scrum'dan Kanban'a değil, Scrum'dan yapısızlığa geçmiş olur.

Kanban'ın Scrum'a alternatif olmak zorunda olmadığını da baştan söyleyelim. Scrum ekipleri de flow metric'lerini kullanabilir; Scrum.org'un Kanban Guide for Scrum Teams rehberi tam olarak bunu anlatır ve serinin son yazısının konusu bu.

Üretimde Dikkat

Kanban'a geçen bir ekibin ilk haftalarında ölçmesi gereken şey hız değil, sistemin kendisidir. Board'u kurduğun gün her kartın hangi tarihte hangi kolona girdiğini kaydetmeye başla. Jira ve GitHub Projects bu geçmişi tutar, ama standart CSV export'ları çoğu zaman yalnız güncel durumu ve created/resolved tarihlerini verir; state geçiş tarihleri için aracın geçmiş verisine (Jira'da issue changelog'u gibi) erişmen gerekir. Bu veri olmadan 04. ve 05. yazılardaki metric'lerin hiçbirini hesaplayamazsın.

İkinci dikkat noktası sınırın kendisi. İlk WIP limit'ini bugünkü ortalama WIP'ten başlatıp yavaşça düşürmek, "kişi başına bir iş" gibi bir ideali ilk gün dayatmaktan daha güvenlidir; limit aşılınca kimsenin bir şey yapmadığı bir board'da sayı yalnız süs olur. Üçüncüsü, acil işin kuralı: destek ağırlıklı bir ekipte acil işler her zaman gelir. Bunları board'da ayrı bir şerit ve açık bir policy ile yönetmek, limit'i sessizce delmekten iyidir; bunu 06. yazıda expedite policy'si olarak konuşacağız.

Sık Düşülen Tuzaklar

En yaygın tuzak baştaki hikâye: board'u açıp Kanban'a geçtiğini sanmak. Board bir araçtır, Kanban ise board'un arkasındaki kurallar ve o kuralları ölçen metric'lerdir.

İkinci tuzak Kanban'ı "plansızlık" ya da "deadline'sız çalışma" olarak okumak. Kanban'da Sprint yoktur ama plan vardır: Ready kolonunun nasıl ve hangi sıklıkla doldurulacağı (replenishment), işin hangi sırayla çekileceği ve ne zaman biteceği bir policy ile ve veriyle cevaplanır. "Ne zaman biter?" sorusuna Kanban'ın cevabı 05. yazıdaki olasılıklı tahmindir; bu cevap "bilmiyoruz, akışta" cümlesinden çok daha bağlayıcıdır.

Üçüncü tuzak, iki Kanban kolu arasında taraf tutup diğerini yanlış ilan etmek. Kanban University'nin eğitimini almış biriyle ProKanban'ın Guide'ını okumuş biri aynı board önünde farklı kelimeler kullanabilir; ikisi de WIP'i sınırlamayı, işi görünür kılmayı ve flow'u iyileştirmeyi ister. Terimleri karşılaştırarak konuşmak, hangisinin "doğru" olduğunu tartışmaktan daha verimli.

Dördüncüsü, Kanban'ı yalnız destek ekiplerine uygun bir şey sanmak. Guide Kanban'ın endüstri ve ölçek fark etmeksizin uygulanabileceğini söyler; ürün geliştiren bir Scrum ekibi de, birden fazla ekibi kapsayan bir portföy de bir DoW tanımlayıp flow'unu ölçebilir.

Küçük Bir Deneme

★☆☆ Kendi ekibinin board'unu aç ve Guide'ın DoW için saydığı altı parçayı tek tek ara: work item tanımı, başlangıç ve bitiş noktası, state'ler, WIP kontrolü, explicit policy'ler, SLE. Kaçı yazılı, kaçı yalnız insanların kafasında?

★★☆ Son iki haftada "In Progress" kolonunda duran kart sayısını her gün not et (Jira'da board'un geçmişinden ya da her sabah bir ekran sayımıyla). Ortalama WIP'in ekipteki kişi sayısına oranı kaç? 1'in çok üstündeyse, kişi başına kaç işin aynı anda açık durduğunu ekibinle konuş.

★★★ Kanban University'nin Kanban Method rehberini ve The Kanban Guide'ı yan yana okuyup tek sayfalık bir karşılaştırma çıkar: hangi kavram ikisinde de var, hangisi yalnız birinde? Bu yazıdaki tabloya kendi ekibin için önemli bir satır ekle.

Bir sonraki yazıda Bookstore ekibinin board'unu sıfırdan tasarlayacağız: Definition of Workflow'un parçalarını tek tek yazacak, işin nerede başlayıp nerede bittiğine karar verecek ve queue state'leri ile active state'leri birbirinden ayıracağız.