2 Haftalık Sprint Döngülerinden, Günlük Sprint’lere
Danışmanlığa ilk başladığım zamanlarda Scrum çerçevesinin tüm kurallarının uygulanması gerektiğini özellikle savunuyor ve hatta bir kural koyucu gibi sonuna kadar uygulatmaya çalışıyordum.
2010 yılında bu bakış açım bugüne kadar destek olduğum en “Agile” takımın Sprint koşmadığını gördüğümde tamamen değişmişti. Aynı anda sadece bir iş maddesine odaklanıp, onu canlıya alana kadar da başka hiçbir şey ile odaklarını dağıtmayan bir işbirliği modeli kurgulamışlardı. Odaklandıkları işin büyüklüğüne göre günlük, yarım günlük hatta saatlik Sprint’ler koşuyorlardı. O zaman asıl çevikliğin yöntemin koyduğu kurallar değil, temel prensiplerde olduğunu fark etmiştim. Bugün ürün geliştirme süreçlerinde devrimsel bir yolculuktan geçiyoruz. Kuralların baştan yazıldığı, çalışma yöntemlerinin yeniden tasarlandığı, rollerin evrimleştiği ve takım yapılarının tekrar şekillendiği bir dönem. Bu değişim aynı benim danışmanlık kariyerimin başlangıcında iş yapış şekillerine şahit olduğum bu en “Agile” takımı hatırlatıyor.
Bir Product Owner’ın sabah 9’da ofise geldiğinde takımın gece boyunca yazdığı, test ettiği ve uç senaryoları işaretlediği bir özelliği incelediği bir senaryo çok uzak değil. Bu senaryoda takım gece mesai yapmadı ama yine de hiç ara vermeden çalıştı. Özellikle son 1 senedir bu tip senaryolar üzerinde düşünüyor ve böyle bir sistemin nasıl oluşabileceğini uygulanabilir pratik bir yaklaşım haline getirmeye çalışıyorum. McKinsey de Mayıs 2026’da yayınladığı "Rewiring Software Delivery for the Agentic Era" başlıklı raporuna bu senaryo ile başlıyor. Bu, sanırım yaşadığımız değişimi en güzel özetleyen örneklerden birisi. Rapora göre öncü organizasyonlar, insan ve ajanların 24 saat boyunca birlikte çalışabildiği bir operasyon modeline geçerek 3 ila 5 kat verimlilik artışı elde ediyor. Takımdaki kişi sayılarının da azaldığı, ancak ajanların arttığı bir operasyon modeli bu.
Bu yazıda uzun süredir yaptığım çalışmalarla paralel olarak, birkaç benzer raporun da bu değişime nasıl yaklaştığını ve bu değişimin Agile yaklaşımları nasıl etkilediğini açıklamaya çalışacağım.
İteratif Döngüler (Sprint, İterasyon vb.): 2 Haftadan 24 Saate!
Agile yaklaşımların tamamı döngüsel çalışma aralıklarına dayanıyor. Bu döngülerin yakın gelecekte akış odaklı bir perspektif kazanacağını düşünüyorum. Yani Sprint’ler yerini, Flow tabanlı bir yaklaşıma bırakacak. Ancak buraya ulaşabilmek için ilk adımın direkt Flow tabanlı bir çalışma modeline geçmeden AI-Native Sprint modelini deneyimlemek ve ajanlarla çalışmaya geçişi güvenli deneyimleyecek bir ara adım olacağını da söylemem gerekir.
McKinsey raporunda da düşüncemi doğrular şekilde Sprint temposunun en radikal değişikliklerden birisi olacağını belirtiyor. Geleneksel (Agile yöntemler için bu kelimeyi kullanmak biraz garip hissettiriyor) 2 haftalık Sprint döngüsü yerini, “Günlük Sprint” modeline bırakıyor. Akşamları 16 saatlik çalışma süresinde ajan takım üyeleri gereksinimleri netleştiriyor, mimari kararlar alıyor, kod geliştirip test süreçlerini işletiyor ve insan takım üyelerinin incelemesi için bir rapor hazırlıyor. Gündüzleri 8 saatlik çalışma süresinde insan takım üyeleri, ajan takım üyelerinin ürettiği artifact’leri inceliyor, çıktıları gözden geçiriyor, belirsizlikleri çözüyor, mimari kararları doğruluyor, gerekli olduğu durumda bu kararları düzeltiyor. Sonunda da bir sonraki akşam çalışma saatleri için gerekli girdileri hazırlıyor.
Raporun vurguladığı kritik nokta şu: bu model yalnızca dört temel ön koşul sağlandığında işliyor -net bir iş hedefi/yol haritası, standart ve tutarlı bir teknoloji altyapısı, gereksinimden koda standart bir akış ve sürecin tamamında sabit kalan paydaşlar. Bu koşullar sağlanmazsa, raporun ifadesiyle, ajan çıktısı "parçalı ve güvenilmez" hale geliyor. Son maddedeki “sabit kalan paydaşlar” önermesi, şu anki değişim hızını göz önüne aldığımızda değişmez kalması bana mantıklı gelmese de diğer maddelerin olmazsa olmaz olduğu konusunda hemfikiriz.
Roller de Dramatik Biçimde Değişiyor: Üretimden Stratejik Karar Almaya!
Aynı raporda rollerdeki değişime de dikkat çekilmiş. 8-12 kişilik insanlardan oluşan takımlar (Product Owner, İş Analisti, Tech Lead, Yazılım Mühendisleri, Test Mühendisleri vb.) yerini 3-4 kişilik, daha küçük takımlara bırakıyor. Rapora göre artık sadece Product Owner, Tech Lead ve “AI-Enabled Engineer” yer alacak. McKinsey bu durumu kişi-yıl bazında yaklaşık %50, ortalama takım büyüklüğünde ise yaklaşık %60 bir küçülme olarak ölçümlemiş. Burada özellikle “İş Analisti ve Test Mühendisi gibi roller ortadan kalkarken, bu sorumluluklar nasıl evrilecek?” sorusu önem kazanıyor. Google’ın yayınladığı “The New SDLC With Vide Coding” yazısı bu boşluğu doldurmak için bir öneri yapıyor. Bu yazıya göre geliştiricilerin rolü iki ayrı moda ayrılıyor:
Conductor: Gerçek zamanlı, IDE içinde kod satır satır yazılırken AI’ı yönlendiren takım üyeleri
Orchestrator: Asenkron, görevleri ajanlara devreden, sonuçları gözden geçiren takım üyeleri
Bu ayrım, aslında klasik bir Agile takımdaki “kendi kendini organize eden takım kavramının AI çağındaki yeni hali gibi okunabilir. Rollerin değişimi konusunda yine benzer şekilde bir ara geçiş aşamasının olması gerektiğini düşünüyorum. AI-Native Sprint Modeli’nde tanımladığım bu ara geçiş formuna “AI-Native Roles (Product Owner, Scrum Master, Developers)” ismini verdim. Tamamen “AI-Enabled Engineer” olabilmek için AI kullanımının yapısal bir süreç haline gelmesinin önemli olduğu görüşündeyim.
Sprint içi Etkinlikler: “Vide Coding” mi, “Agentic Engineering” mi?
Google raporunda Scrum uygulayıcıları için çok kullanışlı bir ayrım sunuyor. Andrej Karpathy'nin 2025'te popülerleştirdiği "vibe coding" kavramı -geliştiricinin doğal dilde bir istek yazıp AI çıktısını sorgulamadan kabul etmesi- ile "agentic engineering" -spesifikasyonlar, otomatik test/eval setleri, guardrail'ler ve mimari üzerinde insan denetimiyle disiplinli bir yaklaşım- arasındaki fark, raporun kendi ifadesiyle "AI kullanıp kullanmadığınız değil, AI çıktısının etrafını ne kadar yapı, doğrulama ve insan muhakemesinin sardığı" sorusuna dayanıyor.
Bu ayrım Sprint Review ve Definition of Done tartışmalarına doğrudan yansıyor: bir Increment'in "Done" sayılabilmesi için artık sadece fonksiyonel testlerin değil, ajanın izlediği yolun (trajectory eval) da doğrulanması gerekiyor. Rapor bunu açıkça söylüyor: "fluent ama doğrulama adımlarını atlamış bir çıktı, görünür hatası olan bir çıktıdan daha tehlikelidir." Bu, Daily Scrum'da artık "ne yaptım, ne yapacağım" yerine "ajan ne üretti, ben neyi doğruladım" sorusunun konuşulacağı anlamına geliyor.
Raporda, Sprint mekaniklerinin yapısal formunun bozulmadan korunacağı varsayımı ile öngörü yapılmış. Ancak Sprint mekaniklerinin de benzer şekilde yıkıcı bir dönüşüm yaşayacağını öngörüyorum. Örneğin Sprint Planning aktivitesi plan yapmaktan çok, ajanların önereceği plan önerilerinden hangisinin seçileceği kararının alınacağı bir yapıya kavuşacak. Burada da yine AI-Native Sprint Model’ine referans vermem gerekir, çünkü bu değişim de bugünden yarına olmayacak.
Organizasyonların Adaptasyonu için Olmazsa Olmaz Ön Hazırlıklar:
Guardrail Komiteleri
Burada bahsettiğim değişimler için birçok raporun ortak noktası şu: AI-First süreçleri tasarlarken geniş katılımlı paydaşlardan da görüş alınması kritik. Hatta onları da sürecin ana parçası haline getirmek gerekiyor. Bu paydaşlar arasında Risk, Hukuk, Tedarik, Test vb. destek/ uyum fonksiyonları bulunuyor. Ben burada “Guardrail Komitesi” adını verdiğim bir yönetişim mekanizması önerisini getiriyorum. Bu yapı ile birlikte ajanların kurumsal olarak belirli bir çerçeve içerisinde hareket etmesini sağlamak mümkün olabilir.
Mühendislik Kültürü
Google da özellikle konunun teknik kısmına vurgu yapmış durumda. “AI sizin mühendislik kültürünüzü güçlendirir. Güçlü test pratiği, net mimari standartlar ve sağlıklı kod gözden geçirme süreçleri olan organizasyonlar AI’dan çok daha fazla değer elde edecek.” AI hem güçlü hem de zayıf yanları büyütüyor. Dolayısı ile sağlam mühendislik kültürü olan şirketler kazanırken, bu kültürü güçlendirmek isteyen organizasyonlar için de büyük bir fırsat doğuyor. Agile pratikler açısından okursak, Sprint Retrospective’ler artık sadece takım dinamiklerini değil, “Context Engineering” (guardrail, eval setleri vb.) kalitesinin de gözden geçirilmesi gerektiği bir etkinlik halini alıyor. Bu konular altyapı olarak değerlendirilmediğinde, ajan davranışları takım ve organizasyon genelinde tekrarlanamaz hale gelecektir.
Yönetim Yetkinliği
Yukarıda bahsettiğim takımlardaki kişi sayısının azalması, hemen hemen okuduğum tüm raporlarda benzer şekilde tariflenmiş. Ancak bu durum sorumlulukların azalması değil, aksine farklı sorumlulukların da takımlara devredilmesi anlamı taşıyor. Dolayısıyla takımlarda yeni yetkinlikler de geliştirilmek zorunlu. İnsan - Ajan Hibrit takımlarda, insan takım üyeleri en az 1 insan olmayan (ajan) takım üyesini yönetecek. Dolayısı ile insan takım üyelerinin tamamının yönetici gibi düşünmeyi öğrenmesi gerekecek. Bu sorumluluk ve yetkinliklerin değişmesi, aynı zamanda kültürel de bir değişimi işaret ediyor. Tabii bu durum 1-1 ilişkiden daha çok 1-n ilişki halinde olacak. Tahminimizden daha kültürel bir süreç önümüzde olabilir. Agile perspektifinden baktığımızda Scrum açısından bunun pratik karşılığı, artık Sprint Planning'in, ajanların plan önerilerinden hangisinin uygun olacağına karar vermekle birlikte, McKinsey'in deyimiyle "Agentic Budgeting" mantığıyla "hangi ajan kadrosuna, hangi bütçe ve yetki ayrılacak" sorusunu da içerebileceği.
Sonuç olarak, Agile pratikler yok olmuyor, ama her biri yeniden kalibre ediliyor. Hatta Agile mühendislik pratikleri çok daha önemli hale geliyor. Sprint döngüleri kısalıyor ve insan-ajan ritmine göre yeniden tasarlanıyor; Product Owner ve Tech Lead'in yanına "AI-enabled engineer" giriyor; Definition of Done'a trajectory doğrulaması ekleniyor; Retrospektif kapsamı insan dinamiklerinden ajan altyapısına genişliyor. Ancak bunlar için kesinlikle AI-Native Sprint Model’ini baz alan ara bir geçiş süreci önemli.
Bu dönüşümü "hız" meselesi olarak görmek yanıltıcı olur. Asıl belirleyici disiplin, yani spesifikasyon kalitesi, test/eval kapsamı ve insan muhakemesinin nerede devreye girdiği olacaktır. Scrum Master ve Agile Koçlar için önümüzdeki dönemin en kritik sorusu, takımların "vibe coding" rahatlığından "agentic engineering" disiplinine ne kadar hızlı geçebileceği olacak.
Kaynaklar:
- McKinsey & Company, "Rewiring Software Delivery for the Agentic Era" (Mayıs 2026, Jared Moon, Rory Walsh, Vito Di Leo, Adam Thelwall ile) — https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/rewiring-software-delivery-for-the-agentic-era
- Google, "The New SDLC With Vibe Coding: From Ad-Hoc Prompting to Agentic Engineering" (Mayıs 2026, Addy Osmani, Shubham Saboo, Sokratis Kartakis) https://www.kaggle.com/whitepaper-the-new-SDLC-with-vibe-coding
Yorumlar