Agile'ın Evrimi: Manifesto'dan Modern Agile'a ve Ölçeklendirme Tartışmasına

Sürüm notu: Bu yazı Kasım 2026 itibarıyla yayında olan kaynakları esas alır: modernagile.org, Alistair Cockburn'ün Heart of Agile yazıları, Agile Fluency Model'in 2018 güncellemesi, framework.scaledagile.com'daki SAFe 6.0, less.works, Scrum.org'un Nexus rehberi ve Henrik Kniberg'in Spotify modeli üzerine 2015 tarihli notu.

Önce Tahmin Et

Bookstore büyüdü: altı ekip, yaklaşık 45 kişi, tek bir ürün. Ekipler birbirini bekliyor, sprint review'lar altı ayrı toplantıya dönüştü ve bir feature'ın production'a çıkması için üç ekibin aynı sprint'te aynı işi bitirmesi gerekiyor. Yönetim bir çözüm buldu: bir ölçeklendirme framework'ü satın alınacak, danışmanlar gelecek ve bir çeyrek içinde "kurumsal çeviklik" sağlanacak.

Tahmin et: framework'ü satın almak ekipler arasındaki bekleme sorununu çözer mi? Yoksa sorun, hangi framework seçilirse seçilsin, ekiplerin nasıl bölündüğünde mi?

2001'den Sonra: Manifestonun Etrafında Büyüyen Dünya

Snowbird toplantısından sonra 2001'in sonunda Agile Alliance kâr amacı gütmeyen bir organizasyon olarak kuruldu ve yıllık konferanslarıyla Agile topluluğunun buluşma noktası oldu. Sonraki yirmi beş yıl iki ters yönlü hareket getirdi. Bir yanda Agile kurumsallaştı: sertifikalar, framework'ler, araçlar ve danışmanlık pazarı büyüdü. Diğer yanda bu büyümeye tepki olarak, manifestonun özüne dönmeye çalışan sadeleştirme önerileri çıktı.

Bu dönemde iki büyük akım Agile'la birleşti. 2009'da başlayan DevOps hareketi, Agile'ın kısalttığı geliştirme döngüsünü production'a kadar uzattı; bu hikâye SDLC (Software Development Life Cycle) serisinin beşinci yazısında. Scrum ise 2010'da ilk resmî Scrum Guide'ı yayımladı; Guide 2011, 2013, 2016, 2017 ve 2020'de güncellendi, Haziran 2025'te de Ralph Jocham, John Coleman ve Jeff Sutherland tarafından isteğe bağlı bir tamamlayıcı olarak Scrum Guide Expansion Pack çıktı. Scrum'ın bu evrimi Scrum serisinin son yazısının konusu.

Sadeleştirme Dalgası: Heart of Agile ve Modern Agile

Manifestonun yazarlarından Alistair Cockburn, 2015-2016 civarında Agile'ı dört kelimeye indirdiği Heart of Agile'ı tanıttı: Collaborate, Deliver, Reflect, Improve. Fikir, framework'lerin ve sertifikaların altında kaybolan özü yeniden görünür kılmak: birlikte çalış, küçük parçalar hâlinde teslim et, sonuçlara bak, iyileştir. Cockburn'e göre her biri ayrıca derinleştirilebilir, ama başlangıç noktası bu dört kelime.

Joshua Kerievsky 2016'daki Agile konferansında Modern Agile'ı dört rehber ilkeyle sundu: Make People Awesome, Make Safety a Prerequisite, Experiment & Learn Rapidly ve Deliver Value Continuously. Modern Agile'ın manifestoya göre en belirgin farkı, psikolojik güvenliği açıkça bir ön koşul yapması ve "müşteri memnuniyeti" yerine insanları, yani kullanıcıyı da ekibi de, başarılı kılmayı merkeze alması.

Serinin dördüncü yazısında gördüğümüz Dave Thomas'ın "agility" önerisi de aynı dalganın parçası. Üçünün ortak noktası, Agile'ı bir süreç paketinden çok bir dizi alışkanlık olarak tarif etmek.

Agile Fluency Model: Olgunluk Değil, Seçim

James Shore ve Diana Larsen'in 2012'de yayımladığı ve 2018'de önemli ölçüde güncellediği Agile Fluency Model, ekiplerin Agile'dan beklediği faydaları dört bölgede (zone) toplar. Focusing bölgesindeki bir ekip işini iş değeri açısından görünür kılar ve yönü değiştirildiğinde hızla uyum sağlar. Delivering bölgesindeki ekip düşük hata oranıyla, istediği zaman ve sık release yapabilir. Optimizing bölgesindeki ekip ürün kararlarını kendisi verir ve pazardan öğrendikçe yönünü değiştirir. Strengthening bölgesi ise ekiplerin öğrendiklerinin organizasyonun karar biçimine yansımasıyla ilgilidir.

Modelin en önemli vurgusu, bunun bir olgunluk modeli olmaması. Her bölge kendi başına tam ve geçerli bir seçimdir; bir ekip Focusing'de kalmayı bilinçli olarak seçebilir. Her bölgenin bir de bedeli var: Delivering için ekibin beceri kazanırken geçici olarak yavaşlamayı kabul etmesi, test ve operasyon becerilerini ekibe katması gerekir; Optimizing için organizasyonun ekibe iş uzmanlığı ve gerçek karar yetkisi vermesi gerekir. Yönetimin "hepiniz Optimizing olun" demesi, o bölgenin yatırımını yapmadan sonucunu istemektir.

Ölçeklendirme Tartışması

Agile'ın küçük ekipler için tasarlandığı açık; manifesto ölçek hakkında bir şey söylemez. Birden fazla ekibin aynı ürün üzerinde çalıştığı durumlar için 2010'larda birkaç framework öne çıktı.

SAFe (Scaled Agile Framework), Dean Leffingwell tarafından geliştirildi; ilk sürümü 2011'de çıktı ve framework.scaledagile.com bugün hâlâ Mart 2023'te tanıtılan SAFe 6.0'ı güncel sürüm olarak gösteriyor. SAFe birden fazla ekibi bir ART (Agile Release Train) altında toplar ve bu ekipler belirli aralıklarla birlikte planlama yapar. Ekipten portföye kadar roller, event'ler ve artifact'ler tanımlayan kapsamlı bir framework. Eleştirisi de bu kapsamdan gelir: çok sayıda rol ve katman, yukarıdan aşağıya bir uygulama biçimi ve Fowler'ın "Agile Industrial Complex" diye andığı danışmanlık ekosistemiyle sıkı bağ.

LeSS (Large-Scale Scrum), Craig Larman ve Bas Vodde'nin çalışmalarından doğdu. Temel LeSS 2-8 ekip için, LeSS Huge sekizden fazla ekip için tasarlandı. Yaklaşımı SAFe'in tersi: yeni roller ve katmanlar eklemek yerine organizasyonu sadeleştirmek. Tek bir ürün, tek bir Product Owner, tek bir Product Backlog ve uçtan uca feature geliştiren ekipler. Eleştirisi, organizasyonda derin yapısal değişiklik istemesi; birçok kurum için bu, framework satın almaktan çok daha zor.

Nexus, Ken Schwaber ve Scrum.org tarafından 2015'te tanıtıldı ve aynı ürün üzerinde çalışan 3-9 Scrum ekibi için Scrum'ın üzerine ince bir katman ekler. En belirgin eklentisi, ekipler arasındaki entegrasyon sorunlarından sorumlu Nexus Integration Team. Yaklaşımı Scrum'a sadık ve hafif; eleştirisi, Scrum dışındaki ihtiyaçlara, örneğin portföy yönetimine, cevap vermemesi.

"Spotify modeli" ise aslında bir framework değil. Henrik Kniberg ve Anders Ivarsson 2012'de Spotify'ın o günkü organizasyonunu squad, tribe, chapter ve guild kavramlarıyla anlatan bir makale yayımladı. Kniberg 2015'teki bir notunda bunun genel bir framework ya da model olarak tasarlanmadığını, yalnız bir şirketin belirli bir andaki çalışma biçiminin örneği olduğunu yazdı. Spotify'da çalışmış bir Agile koçu olan Joakim Sundén de 2020'de bu modelin Spotify'da artık uygulanmadığını söyledi. Bir şirketin anlık fotoğrafını kopyalamak, o fotoğrafı üreten kültürü ve deneme pratiğini kopyalamak anlamına gelmiyor.

Framework Satın Almak Agile Olmak Değil

Yazının başındaki soruya dönelim. Bookstore'un altı ekibi birbirini bekliyor, çünkü ekipler katmanlara göre bölünmüş: bir frontend ekibi, iki backend ekibi, bir veritabanı ekibi, bir test ekibi ve bir platform ekibi. Her feature üç ekipten geçmek zorunda. Hangi ölçeklendirme framework'ü seçilirse seçilsin, bu yapıda koordinasyon ihtiyacı ortadan kalkmaz; framework yalnız bu koordinasyonu yönetecek toplantılar ve roller ekler.

Daha etkili ilk adım, ekipleri uçtan uca feature geliştirebilecek şekilde yeniden düzenlemek: checkout ekibi, katalog ekibi, sipariş ve iade ekibi. Bu, LeSS'in feature team fikri ve Mimariye Giriş serisinin "Conway's Law: Ekip Yapısı Mimariyi Nasıl Şekillendirir?" yazısının ana teması: ekip yapısı ile mimari birbirini şekillendirir. Bağımlılıkları azalttıktan sonra hâlâ ekipler arası koordinasyon gerekiyorsa, Nexus gibi hafif bir katman ya da SAFe gibi kapsamlı bir framework o zaman değerlendirilebilir.

Ekibin İçin Kısa Bir Self-Check

Agile Fluency Model'in bölgelerinden esinlenen bu sorular bir değerlendirme aracı değil, ekip içi bir konuşma başlatıcısı. Her soruya ekip olarak "evet", "kısmen" ya da "hayır" de:

• Focusing: Ekip, üzerinde çalıştığı her işin hangi iş değerine hizmet ettiğini söyleyebiliyor mu ve öncelik değiştiğinde bir hafta içinde yön değiştirebiliyor mu?
• Focusing: Ekip, işini düzenli aralıklarla iş tarafına gösteriyor ve aldığı geri bildirimi planına yansıtıyor mu?
• Delivering: Ana branch her an release edilebilir durumda mı ve production'a çıkış tek bir otomatik pipeline'la mı yapılıyor?
• Delivering: Production'da çıkan hata sayısı ekibin planlarını bozmayacak kadar düşük mü?
• Optimizing: Ekip, hangi feature'ın yapılacağına kullanıcı verisine bakarak kendisi karar verebiliyor mu?
• Strengthening: Ekibin öğrendikleri diğer ekiplere ve organizasyonun çalışma biçimine yansıyor mu?

Cevaplar, hangi bölgenin yatırımını yapmanın değerli olduğunu konuşmak için bir başlangıç. Delivering sorularına "hayır" diyen bir ekibin ölçeklendirme framework'ünden önce CI (Continuous Integration), test otomasyonu ve deploy pipeline'ı gibi temel mühendislik pratiklerine ihtiyacı var; bunların karşılığı serinin üçüncü yazısındaki XP (Extreme Programming) pratikleri.

Üretimde Dikkat

Ölçeklendirmeden önce sadeleştir. Ekipler arası bağımlılıkları bir tabloya dök: hangi ekip hangi ekibi, ne sıklıkla bekliyor? Bağımlılıkların çoğu ekip sınırlarının yanlış çizilmesinden geliyorsa, çözüm koordinasyon katmanı değil, yeniden organizasyon.

Bir framework seçilecekse, onu bir deney olarak başlat. Tek bir ürün alanında, ölçülebilir bir hedefle (örneğin change lead time'ı yarıya indirmek) ve belirli bir değerlendirme tarihiyle. Framework'ü bütün organizasyona tek seferde yaymak, Dave Thomas'ın tarif ettiği küçük adım döngüsünün tam tersi.

Fluency bölgesini ekip seçsin. Yönetimin rolü, ekibin seçtiği bölgenin yatırımını yapmak: zaman, eğitim, yetki.

Sık Düşülen Tuzaklar

Framework satın almayı Agile olmakla karıştırmak en yaygın tuzak. Framework'ün rollerini ve event'lerini kurup ekip yapısını ve mühendislik pratiklerini değiştirmemek, serinin dördüncü yazısındaki cargo cult'un ölçeklendirilmiş hâli.

İkincisi, başka bir şirketin modelini kopyalamak. Spotify'ın 2012 fotoğrafı, Spotify'ın kendisi için bile bir ara durumdu.

Üçüncüsü, Agile Fluency Model'i bir olgunluk merdiveni gibi kullanmak ve ekipleri bölgelerine göre sıralamak. Model bunu açıkça reddediyor.

Dördüncüsü, sadeleştirme önerilerini yeni birer framework'e çevirmek. Heart of Agile'ın dört kelimesi bir süreç değil; onları da sertifikalı bir programa dönüştürmek, tepki gösterdikleri şeyi tekrar etmek olur.

Küçük Bir Deneme

★☆☆ Heart of Agile'ın dört kelimesini (Collaborate, Deliver, Reflect, Improve) al ve ekibinin son sprint'inde her biri için bir örnek bul. Hangisinde örnek bulmakta zorlandın?

★★☆ Self-check listesini ekibinle birlikte doldur. Cevaplarda en çok ayrıştığınız soru hangisi ve neden?

★★★ Organizasyonundaki ekipler arası bağımlılıkları bir tabloya dök: her satırda bekleyen ekip, beklenen ekip ve son bir ayda kaç kez beklendiği. Bağımlılıkları yarıya indirecek bir ekip yapısı öneriyor musun, yoksa bir koordinasyon framework'ü mü gerekiyor?

Agile Mindset serisi burada bitiyor: manifestonun dört değeri, 12 prensibi, XP'nin mühendislik pratikleri, yaygın yanlışlar, gerçek dünyayla sürtünme ve 2001'den bugüne evrim. Bu değerlerin günlük bir ekipte nasıl bir çalışma biçimine dönüştüğünü görmek için sıradaki adım Scrum ve Kanban serileri; ikisi de buradaki "neden"in üzerine "nasıl"ı kuruyor.