Agile, Scrum ve Kanban Farkı Nedir?

Yazılım mühendisliği tarihinde projelerin bütçeyi aşması, aylarca süren analiz dokümanlarının kodlama bittiğinde güncelliğini yitirmesi ve müşterinin gerçekte ne istediğinin ancak ürün canlıya çıktığında anlaşılması en büyük başarısızlık nedenleriydi. Geleneksel Waterfall (Şelale) modelinin bu katı ve doğrusal yapısına bir tepki olarak 2001 yılında yayınlanan Çevik Yazılım Geliştirme Manifestosu (Agile Manifesto), yazılım dünyasında çalışma kültürünü kökten değiştirdi. Ancak günümüzde pek çok teknoloji organizasyonunda Agile (Çeviklik), Scrum ve Kanban kavramları birbirine karıştırılmakta; günlük ayaküstü toplantılar (Daily Stand-up) mikro-yönetim seanslarına dönüşmekte ve Story Point tahminleri mühendislerin performans karnesi gibi yanlış kullanılmaktadır. Modern uygulama ve yazılım geliştirme ekiplerinde gerçek çevikliği yakalamak, bu çerçevelerin ritüellerini ezbere uygulamaktan değil, arkasındaki kuyruk teorisi (queueing theory), ampirik süreç kontrolü ve mühendislik metriklerini doğru anlamaktan geçer.

Bu kapsamlı rehberde; bir felsefe olarak Agile ile birer uygulama çerçevesi olan Scrum, Kanban ve Scrumban arasındaki mimari farkları, Scrum'daki zaman kutulu (time-boxed) Sprint döngüsünü, Kanban'daki Work-In-Progress (WIP) limitlerini ve Little Yasası'nı, Story Point tahminlemesinin neden saat veya gün hesabına dönüştürülmemesi gerektiğini ve mühendislik verimliliğini bilimsel olarak ölçen DORA Metriklerini (Deployment Frequency, Lead Time for Changes, Change Failure Rate, MTTR) tüm detaylarıyla inceliyoruz.

1. Agile Bir Metodoloji Değildir: Felsefe ve Çerçeve Ayrımı

Kavramsal netliği sağlamak için en temel kuralı en başta koymak gerekir: Agile (Çeviklik) bir metodoloji veya süreç şablonu değil, bir değerler ve ilkeler bütünüdür. Agile Manifestosu; süreçler ve araçlar yerine bireyler ve etkileşimleri, kapsamlı dokümantasyon yerine çalışan yazılımı, sözleşme pazarlıkları yerine müşteriyle işbirliğini ve bir plana sıkı sıkıya bağlı kalmak yerine değişime yanıt vermeyi önceliklendirir.

Scrum, Kanban, Extreme Programming (XP) ve Scrumban ise bu çevik felsefeyi günlük mühendislik operasyonlarına tercüme eden somut çerçeveler (frameworks) ve yöntemlerdir. Dolayısıyla "Biz Agile mı kullansak yoksa Scrum mı?" sorusu mimari açıdan hatalıdır; doğru soru "Bizim ürünümüzün belirsizlik düzeyine ve ekip yapımıza çevik şemsiye altındaki Scrum çerçevesi mi, yoksa Kanban akış modeli mi daha uygundur?" olmalıdır.

2. Scrum Çerçevesi: Ampirik Süreç Kontrolü ve Sprint Döngüsü

Scrum, karmaşık ürün geliştirme süreçlerini Şeffaflık (Transparency), Denetim (Inspection) ve Uyarlama (Adaptation) olmak üzere üç ampirik sütun üzerine inşa eder. Belirsizliğin yüksek olduğu yeni ürün ve özellik geliştirme çalışmalarında, sonsuz bir yol haritasında kaybolmak yerine işi 1 ila 4 haftalık (endüstri standardı genellikle 2 hafta) sabit zaman kutularına (time-box) böler. Bu döngülere Sprint adı verilir.

Scrum'daki 3 Sorumluluk (Accountabilities) ve 5 Etkinlik

• Product Owner (Ürün Sahibi): Ürün İş Listesinin (Product Backlog) tek sorumlusudur. Müşteri ihtiyaçlarını, pazar dinamiklerini ve kullanıcı deneyimi ve dönüşüm optimizasyonu (CRO) hedeflerini iş değerine (business value) göre sıralar; "Ne yapılacağına ve neden yapılacağına" karar verir.
• Developers (Geliştiriciler): Her Sprint sonunda kullanılabilir ve "Bitti Tanımı"na (Definition of Done - DoD) uygun bir ürün artımı (Increment) üretmekten sorumlu çapraz fonksiyonel (cross-functional) mühendislik ekibidir; "Nasıl yapılacağına" karar verir.
• Scrum Master: Ekibin yöneticisi değil, süreç kolaylaştırıcısı ve engel kaldırıcısıdır (servant leader). Darboğazları çözer, ekibi dış müdahalelerden korur ve çevik pratiklerin olgunlaşmasını sağlar.

Scrum ritmi beş resmi etkinlikle (Events) işler: Sprint hedefinin ve kapsamının belirlendiği Sprint Planning, her gün 15 dakikayı aşmayan ve "Sprint hedefine ulaşmak için bugün neyi senkronize etmeliyiz?" sorusuna odaklanan Daily Scrum, Sprint sonunda çalışan yazılımın paydaşlara sunulduğu Sprint Review ve ekibin kendi çalışma biçimini, araçlarını ve iletişimini iyileştirmek için aksiyon aldığı Sprint Retrospective.

3. Kanban Metodu: Sürekli Akış, WIP Limitleri ve Little Yasası

Kökeni Toyota Üretim Sistemi'ne (Lean / Yalın Üretim) dayanan ve David J. Anderson tarafından yazılım mühendisliğine uyarlanan Kanban, sabit zamanlı Sprint'ler veya zorunlu rol değişiklikleri dayatmaz. Kanban'ın temel felsefesi "Şu an yaptığın işi görselleştir, aynı anda devam eden iş sayısını (WIP) sınırla ve akışı (flow) yönet" ilkesine dayanır.

Neden WIP (Work-In-Progress) Limitleri Hayati Önem Taşır?

Bir yazılım geliştiricinin aynı anda 4 farklı görevi (ticket) "In Progress" sütununda tutması üretkenlik değil, ağır bir bağlam değiştirme maliyeti (context switching penalty) yaratır. Araştırmalar, bir mühendisin paralel yürüttüğü her ek görevde toplam zamanının %20'sini bağlam değiştirmeye (farklı kod dalına geçme, farklı iş mantığını hatırlama, ortam ayağa kaldırma) kaybettiğini göstermektedir.

Kanban bu sorunu kuyruk teorisinin temel denklemi olan Little Yasası (Little's Law) ile çözer:

Ortalama Çevrim Süresi (Cycle Time) = Devam Eden İş Sayısı (WIP) / Ortalama Çıktı Hızı (Throughput)

Bu matematiksel formül bize çok net bir gerçeği söyler: Bir ekibin kod yazma hızını (Throughput) bir gecede iki katına çıkaramazsınız; ancak bir görevin başlangıcından canlıya çıkmasına kadar geçen süreyi (Cycle Time) yarıya indirmek istiyorsanız yapmanız gereken tek şey Devam Eden İş Sayısını (WIP) yarıya indirmektir! Kanban panosunda örneğin "Code Review" sütununa WIP Limit: 3 koyduğunuzda ve orada 3 kart biriktiğinde, geliştiriciler yeni bir iş alıp kod yazmaya devam edemez; önce incelemede bekleyen işleri eriterek darboğazı açmak zorundadır. Buna "Başlamayı bırak, bitirmeye başla!" (Stop starting, start finishing!) prensibi denir.

4. Story Point Tahminlemesi: Neden Saat Değil Göreli Karmaşıklıktır?

Çevik yazılım yönetiminde en çok yanlış anlaşılan konuların başında Story Point (Hikaye Puanı) kavramı gelir. Pek çok organizasyonda yöneticiler "1 Story Point = 4 saat, 2 Story Point = 1 gün" gibi hatalı bir dönüşüm tablosu kurmaya çalışır. Oysa zaman bazlı tahminleme, kıdemli (Senior) bir mühendisin 3 saatte yazacağı bir modülü genç (Junior) bir mühendisin 2 günde yazacak olması nedeniyle toplantılarda sonsuz tartışmalara yol açar.

Story Point, bir işin kaç saat süreceğini değil; o işin Göreli Büyüklüğünü (Relative Sizing) ölçer ve genellikle değiştirilmiş Fibonacci dizisi (1, 2, 3, 5, 8, 13, 21) kullanılarak Planning Poker yöntemiyle tahminlenir. Bir Story Point değeri şu üç bileşenin bileşkesidir:

1. Teknik Karmaşıklık (Complexity): Algoritmik zorluk, etkilenen mikroservis veya bileşen sayısı, mimari bağımlılıklar.
2. Harcanacak Efor / Hacim (Effort & Volume): Karmaşık olmasa bile yazılması gereken tekrarlı kod, migrasyon veya test miktarı.
3. Belirsizlik ve Risk (Uncertainty & Risk): İlk kez kullanılacak bir üçüncü parti API, belirsiz gereksinimler veya eski (legacy) kodda çıkabilecek sürprizler.

Altın Kural: Eğer bir kullanıcı hikayesi (User Story) 13 veya 21 Story Point olarak tahminleniyorsa, o iş bir Sprint içinde tamamlanamayacak kadar büyüktür ve belirsizlik içeriyordur. Bu durumda görev kodlanmaya başlanmadan önce mutlaka dikey dilimleme (vertical slicing) yöntemiyle 2, 3 veya 5 puanlık daha küçük, bağımsız teslim edilebilir alt hikayelere bölünmelidir.

5. Scrum, Kanban ve Scrumban Karşılaştırma Tablosu

Hangi mühendislik ekibinin hangi çevik çerçeveyi seçmesi gerektiğini netleştirmek için Scrum, Kanban ve her ikisinin hibrit birleşimi olan Scrumban'ı temel parametreleriyle karşılaştırıyoruz:

Karşılaştırma Kriteri	Scrum Çerçevesi	Kanban Metodu	Scrumban (Hibrit Model)
Çalışma Ritmi (Cadence)	Sabit süreli iterasyonlar (1-4 haftalık Sprint döngüleri)	Sürekli akış (Continuous Flow - Sprint kavramı yoktur)	İhtiyaca göre planlama (On-demand planning) + düzenli Retrospektif
Görev Sınırlandırma Mekanizması	Sprint kapasitesi / Velocity (Sprint boyunca toplam Story Point)	Sütun bazlı açık WIP (Work-In-Progress) limitleri	Hem akış sütunlarında WIP limiti hem de kısa döngü hedefleri
Kapsam Değişikliği Esnekliği	Sprint başladıktan sonra Sprint hedefini tehlikeye atacak iş eklenemez	Çok yüksek (Boş kapasite açıldığı anda en öncelikli yeni iş çekilir)	Yüksek (WIP limiti aşılmadığı sürece acil işler akışa dahil edilebilir)
Roller ve Sorumluluklar	Product Owner, Scrum Master ve Developers rolleri zorunludur	Zorunlu rol yoktur; mevcut ekip organizasyonu üzerine kurulur	Esnek (Genellikle Product Owner ve ekip yapısı korunur)
Temel Takip Metrikleri	Velocity (Hız), Sprint Burndown / Burnup Chart	Lead Time, Cycle Time, Throughput, Cumulative Flow Diagram (CFD)	Cycle Time ve Akış Verimliliği (Flow Efficiency)
En Uygun Ekip / Proje Tipi	Yeni ürün geliştirme, net özellik yol haritasına sahip ürün takımları	DevOps, SRE, L3 Destek, Siber Güvenlik ve sürekli operasyon ekipleri	Hem yeni özellik geliştiren hem de canlı sistem bakımını yürüten ekipler

6. DORA Metrikleri ile Yazılım Mühendisliği Verimliliğini Ölçmek

Story Point hızı (Velocity) yalnızca tek bir ekibin kendi içindeki kapasite tahmin aracıdır; ekiplerin birbirini kıyaslamak için kullanılamaz ve mühendislik kalitesini göstermez. Google Cloud DevOps Research and Assessment (DORA) ekibinin binlerce yazılım organizasyonu üzerinde yaptığı araştırmalar, yüksek performanslı (Elite) yazılım ekiplerini diğerlerinden ayıran dört bilimsel metriği ortaya koymuştur:

1. Deployment Frequency (Canlıya Çıkış Sıklığı): Ekibin üretim ortamına (production) ne sıklıkla başarılı kod dağıttığını ölçer. Elit ekipler ayda bir dev sürüm çıkmak yerine, CI/CD otomasyonu ve Feature Flag mimarisiyle günde birden fazla kez (on-demand) küçük ve düşük riskli dağıtımlar yapar.
2. Lead Time for Changes (Değişiklik Teslim Süresi): Bir geliştiricinin kodu ana dala (trunk/main) commit etmesinden, o kodun canlı ortamda çalışmaya başlamasına kadar geçen süredir. Otomatik test boru hatları ve yapay zeka destekli kod inceleme ve test araçları sayesinde elit ekiplerde bu süre 1 saatin altındadır.
3. Change Failure Rate (Değişiklik Hata Oranı): Canlıya yapılan dağıtımların yüzde kaçının üretim ortamında bir kesintiye, acil yamaya (hotfix) veya geri almaya (rollback) neden olduğunu ölçer. Hızın kaliteyi feda etmediğini kanıtlayan en önemli denge metriğidir (Hedef: %0 - %15 arası).
4. Mean Time to Recovery / Failed Deployment Recovery Time (MTTR): Üretim ortamında bir arıza veya hatalı dağıtım meydana geldiğinde, servisin tamamen normal çalışma durumuna döndürülmesi için geçen ortalama süredir. Gelişmiş gözlemlenebilirlik (observability), otomatik rollback ve kesintisiz kurumsal entegrasyon mimarileri ile bu süre dakikalar seviyesine indirilir.

7. Çevik Dönüşümde En Sık Yapılan 4 Anti-Pattern (Sahte Çeviklik)

Bir şirketin Jira veya Linear kullanması, haftalık Sprint açması ve sabahları 15 dakika toplantı yapması o şirketi "Agile" yapmaz. Endüstride "Cargo Cult Agile" veya Water-Scrum-Fall (Sahte Çeviklik) olarak adlandırılan şu dört tuzaktan mutlaka kaçınılmalıdır:

• Daily Scrum'ın Durum Raporlama Toplantısına Dönüşmesi: Geliştiricilerin sırayla Scrum Master'a veya takım liderine "Dün şunu yaptım, bugün bunu yapacağım" diyerek hesap verdiği toplantılar Daily Scrum değildir. Günlük toplantı ekip üyelerinin birbirleriyle senkronize olduğu, "Bugün hangi PR'ı birlikte inceleyelim, hangi API sözleşmesinde tıkanıklık var?" diye konuştuğu mini bir taktik planlamadır.
• Velocity (Hız) Enflasyonu: Üst yönetim ekiplere "Geçen Sprint 40 puan yaptınız, bu Sprint 55 puan yapmalısınız" diye baskı kurduğunda, geliştiriciler bir sonraki planlamada daha önce 3 puan verdikleri işe 5 veya 8 puan vermeye başlar (Goodhart Yasası). Kağıt üzerinde puanlar artar ancak teslim edilen gerçek iş değeri sabit kalır.
• Sprint Sonunda Test Sıkışması (Mini-Waterfall): 10 günlük Sprint'in ilk 8 günü sadece kod yazılıp son 2 günü tüm işlerin QA/Test mühendislerinin üzerine yıkılması Scrum değildir. Çapraz fonksiyonel ekipte test otomasyonu ve kalite kontrol Sprint'in birinci gününden itibaren her hikaye için paralel yürütülür.
• Aksiyonsuz Retrospektifler: Her Sprint sonunda aynı sorunların konuşulup hiçbir somut teknik veya süreçsel iyileştirme görevinin bir sonraki Sprint Backlog'una alınmaması, ekipte öğrenilmiş çaresizlik yaratır.

Sıkça Sorulan Sorular (SSS)

1. Yeni kurulan bir yazılım ekibi Scrum ile mi yoksa Kanban ile mi başlamalıdır?

Eğer ekip sıfırdan yeni bir ürün geliştiriyorsa, ürün yol haritası özellik bazlı planlanabiliyorsa ve ekibin düzenli bir teslimat disiplinine (planlama, demo, retrospektif) alışması gerekiyorsa 2 haftalık Scrum ile başlamak en sağlıklı yapısal çerçeveyi sunar. Ancak ekip ağırlıklı olarak canlı sistem hatalarını (bug-fix) çözüyor, müşteri destek taleplerini karşılıyor veya DevOps/Altyapı taleplerini yönetiyorsa 2 haftalık plan yapmak imkansız olacağından doğrudan Kanban tercih edilmelidir.

2. Bir Sprint devam ederken çok kritik bir üretim hatası (Production Bug) gelirse Scrum'da ne yapılır?

Scrum kuralları üretim ortamındaki yangınları görmezden gelmeyi söylemez. Kritik bir P0/P1 canlı arızası geldiğinde ekip derhal müdahale eder. Ancak mühendislik kapasitesi sabit olduğundan, Product Owner ile konuşularak acil hatanın aldığı efor kadar düşük öncelikli bir iş Sprint kapsamından çıkarılır veya her Sprint'te beklenmedik destek işleri için kapasitenin %10-15'lik kısmı tampon (buffer) olarak ayrılır. Eğer gelen değişiklik tüm Sprint hedefini geçersiz kılıyorsa, Product Owner Sprint'i iptal edip yeniden planlama başlatma yetkisine sahiptir.

3. Teknik borç (Technical Debt) ve Refactoring işleri Sprint'te nasıl puanlanmalıdır?

Kullanıcıya doğrudan görünür bir ekran sunmayan ancak sistemin ölçeklenebilirliği, güvenliği veya kod kalitesi için zorunlu olan teknik görevler (Technical Enablers / Refactoring) kesinlikle gizli iş (shadow work) olarak yapılmamalıdır. Bu görevler de Product Backlog'da şeffaf şekilde yer almalı, efor ve karmaşıklık açısından tahminlenmeli ve sağlıklı bir mühendislik ekibinde her Sprint kapasitesinin ortalama %15 ila %20'si teknik borç azaltımı ve mimari modernizasyona ayrılmalıdır.

4. "NoEstimates" (#NoEstimates) yaklaşımı nedir ve Story Point yerine kullanılabilir mi?

Olgunlaşmış çevik ekiplerde uygulanan #NoEstimates hareketi, saatlerce süren Planning Poker toplantılarında görevlere 3 mü 5 mi puan verileceğini tartışmanın israf (waste) olduğunu savunur. Bunun yerine ekip tek bir kural uygular: "Her kullanıcı hikayesini 1-2 günde tamamlanabilecek kadar küçük ve benzer boyutta parçalara böl." Tüm görevler yaklaşık aynı atomik boyuta indirgendiğinde, Story Point toplamak yerine doğrudan haftalık tamamlanan görev sayısını (Throughput / Item Count) takip etmek ve Monte Carlo simülasyonlarıyla teslim tarihi tahminlemek istatistiksel olarak çok daha doğru sonuç verir.

5. Bitti Tanımı (Definition of Done - DoD) ile Kabul Kriterleri (Acceptance Criteria) arasındaki fark nedir?

Kabul Kriterleri (Acceptance Criteria), yalnızca tek bir kullanıcı hikayesine özgü olan işlevsel gereksinimlerdir (Örneğin: "Kullanıcı şifresini 3 kez yanlış girdiğinde hesap 15 dakika kilitlenmeli ve e-posta gitmelidir"). Bitti Tanımı (Definition of Done - DoD) ise Backlog'daki istisnasız tüm işler için geçerli olan evrensel mühendislik kalite kontrol listesidir (Örneğin: "Birim testleri yazıldı ve kapsama %80 üzerinde, Code Review onaylandı, SAST güvenlik taraması temiz geçti, dokümantasyon güncellendi ve Staging ortamında doğrulandı").